Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.
RetroTech 팟캐스트 44BITS 팟캐스트

9개월차 웹개발자의 이런저런 딜레마(?)들....

웹표준...

얼마전에도 쓰긴했지만 웹표준에 대한 많은 고민이 있다. 난 이젠 웹표준 옹호론자이지만 웹표준을 구현하는데에는 어려움이 참 많다. 웹퍼블리셔나 UX개발자등이 슬슬 인기를 얻고 있지만 아직은 자리를 제대로 못잡은 것 같고 우리회사처럼 체계가 덜 잡힌 회사는 더욱 그렇다. 그렇기 때문에 여태 여러가지 프로젝트에 인볼브됐었지만 웹표준으로 개발하고자 할때는 아예 디자인팀은 배제하고 넘어간다.

물론 내 선을 넘어서서 결정된 디자인팀과 업무 협조가 이루어졌을때는 그냥 대충하지만 대개의 경우에는(우리팀이 떠밀려온 잔업이 많아서.) 디자인팀과 협조가 어렵기 때문에 그냥 팀내에서 알아서 해결하는 경우가 많은데 그냥 내가 하는게 차라리 편하다. 디자인팀은 일단 HTML에 큰 관심도 없기 때문에 요구하기도 어렵고 중간역할을 해줄 웹퍼블리셔를 뽑자고 윗선을 선택하기도 어렵다.

근데 웹표준을 하고 싶은 욕심에 직접 아이콘잘라내고 CSS하고 이것저것 연구하고 하기는 하는데 해본 사람은 알다시피 웹표준이란게 꽤나 시간과 노력이 많이 걸리기 때문에(경험이 적을수록...) 현실적으로 한계에 많이 부딪힌다. 왜냐하면 난 개발자이기 때문에 CSS랑 HTML만 붙잡고 있을수는 없기 때문에.... HTML, CSS를 아는 것 이상으로 난 Java를 할 줄 알아야 하는데 노력은 오히려 웹표준쪽에 더 많이 쏟아지는 딜레마가 있다.





프로젝트 기획...

내가 상상했던 개발과 기획은 좀 상극의 관계였다. 기획은 이런걸 요구하고 개발자는 그걸 어떨게 구현할지 고민하고 그러면서 의견충돌 나고...... 근데 현실은 그렇지 않았다. 우리 본부에도 이제 기획팀이 생기긴 했지만 난 여태 여러개의 프로젝트를 하면서 단 한번도 기획서를 보고 한적이 없었다.

그냥 주먹구구로 만들거나 동기랑 의논해서 어떻게 할지 정하고 인터페이스하고 페이지 만들면 그 다음에 그걸 캡쳐해서 스토리보드란걸 만든다. 그래서 난 기획서나 스토리보드에 어떤 내용이 있는지 잘 모른다. 막연히 개념은 알고 있지만 그걸 보면 어떤 내용이 들어 있는건지 그걸 보고 어떻게 개발해야하는건지...

몇달전에 기획팀 대리님이 나한테 어떤 사항에 대해서 스토리보드에 어떤식으로 작성해 주는게 나한테 편한지를 물었다. 좀 당황한뒤에 솔직히 대답했다. "스토리보드에 뭐가 써있는건지 몰라서 머가 필요한지도 모르겠다"고....

그리고 하나 더.... 다른 팀을 깎아 내리려는 것은 아니지만 일반적으로 좀 그런것 같다.(대기업들은 잘 모르겠지만...) 우리 본부에 기획팀이 신입위주로 구성되어서 그런지도 모르겠다.(그래도 난 그팀이 구성된게 얼마나 기쁜지 모르겠다.) 웹신기술이나 트랜드에 대해서 개발자가 기획자보다 앞서있다. 물론 내가 이런쪽에 취미에 가까울 정도로 관심이 많기 때문에 확실히 잡지식에 대해서는 앞서있다는 의식은 있지만 그런 부분을 논외로 하더라도 기획쪽에서 신기술이나 트랜드에 대한 인지가 부족하다는 느낌이 있다.

아무래도 개발자라는 성향상(모두 그런건 아니지만...) 그런 쪽에 관심을 많이 가지고 있기 때문에 자연히 그런쪽의 지식에서도 앞서가는 것 같다. 신기술이나 표준적인 부분에서 기획쪽에서 더 적극적으로(신기술이 무조건 좋다는 얘기는 아니지만 검토후에 결정이 되어야....) 도입이 되었으면 한다. 내 기대가 너무 큰걸까....





일반적인 개발방식

난 표준에 좀 집착하는 편이다. 웹표준도 그렇고 개발 관련되서는 남들하는대로 하고 싶어하는 경향이 매우 강하다. 남들이 WAS쓰면 나도 쓰고 싶고 프레임워크쓰면 나도 쓰고 싶고.... 그냥 따라만 하는 개발자가 되겠다는 것은 아니지만 많은 사람이 쓴다는 것은 그만큼 검증을 받았다는 것이고 그걸 애써 무시할 필요는 전혀 없다고 본다.

그리고 개발은 혼자하는게 아니고 평생 한회사에서 하는 것도 아니다. 그럼 다른 환경에서도 적응하려면 일반적인 방식으로 습관을 들여놔야 좋다는게 그동안의 내 지론이다. 툴은 이클립스 쓰고 서브버전으로 관리하고 WAS돌리고 Beans쓰고....

근데 내 현실은 그렇지 않다. 아무래도 SI의 특성상 시간에 쫓기는 경향이 많아서 새로운 걸 하고 싶어서 쉽사리 하지 못한다. 그건 이해하지만 그래도 할건 해야지 않나? JSP 사업이 80%인데 대부분은 톰캣을 쓰고 있고 모든 코드를 JSP에서 다 해결한다. "이게 속도가 빠른데 어쩔꺼냐?"라고 한다면 사업을 해야하는 기업입장에서 어쩔수 없지만 그렇게만 개발해서 나중에 자바 개발차라고 다른 회사로 이직할 수 있을까?

그리고 난 발전된 건 이용하자는 편이다. 공부하는 방법은 다 각자의 방식이 있긴 마련이지만 난 기본부터 쌓아서 올라가기 보다는 아예 중간부터 하면서 기본을 이해하는게 더 이해가 빨랐다. 지금 내가 가장 자신있다라고 한다면 자바스크립트를 들 수 있는데 내가 자바스크립트 책을 보면서 자바스크립트의 기본과 방식을 모두 이해한 다음에 그 다음 단계로 왔다면 지금 수준은 택도 없었다고 생각한다.

하지만 내가 자바스크립트에서 제일 먼저 만졌던건 prototype.js 프레임쿼크랑 AJAX부터였다. 그걸 보면서 필요하다보니 그 내부를 파보다 보니 기본도 알고 그 이상도 알게 되었다. 물론 가장 좋은 것은 기본을 다 익히고 그 위로 올라오는 것임은 인정한다. 위로 올라갈수록 기본의 충실함은 드러날 수밖에 없다. 하지만 기본만 붙잡고 있느라 시간을 다 보낼수는 없는 노릇이다.

이번에 다른 팀이랑 개발을 하는데 그쪽에 있는 동기가 그 윗분한테 개발을 배우는데 내 동기한테 "넌 이클립스 쓰지말고 일단 에디트+로 개발하라"고 했다고 했다. 난 그걸 이해못했다. 물론 command로 컴파일하는 걸 할 줄은 알아야 하지만 그렇다고 좋은 IDE가 있는데 안쓰고 있을 이유는 전혀 없다고 본다. code assist 기능은 실력이 없어서라기보다 편하고 실수를 줄이기 위해서라고 생각한다. 솔직히 그분 말고도 우리회사에선 자바개발을 대부분 에디트플러스나 울트라 에디트로 한다. 난 도저히 이해할 수 없다.





공부...

개발자의 길에 들어온 이상 평생 공부해야 한다. 그리고 그게 실지는 않다. 나의 잡식성 지식 습득에 대한 문제이기도 하지만 문어발식으로 공부한다는 느낌을 버릴 수가 없다. 어디가서 내 메인랭귀지라고 할만한게(자바로 생각중이지만...) 있어야 하는데 현실상 쉽지가 않다. 자바만 붙들고 있기가 쉽지 않다. 비단 회사일뿐만이 아니라 이것저것 알아야 할게 너무 많아서.....  올해내에 자바는 내가 만족할 수준까진 올라야 되는데... ㅜ..ㅜ





체계적인 프로젝트


협업이란 건 참 어려운 것 같다. 처음 개발공부를 하면서 학원에서 협업을 하다가 프로젝트를 한번 말아먹은 적이 없다. 합치는 과정에 와서야 설계자체가 개판인걸 알았다. 지금 생각하면 그땐 어떻게 그런게 돌아갈꺼라고 생각했는지 모르겠다. ㅋ 어쨌든 학원에서 프로젝트를 하면서 큰 고민중에 하나가 과연 협업은 어떻게 할까 하는 거였다. 일을 어떻게 나누고 어떻게 진행하고 어떻게 합치느냐가 나의 관심사였다.

그리고 회사에 들어왔다. 9개월이 지났건만 난 아직도 협업을 어떻게 하는지 모르겠다. 협업이라는 방식으로 일을 해보지 못해서... 이정도 규모에서 이렇게 해매는데 더 큰 규모로 가면 과연 어떻게 될까 하는 생각.....

지금은 그나마 프로젝트를 내 동기랑 둘이서만 구축하게 된 상황이 2번있었던 관계로 저번에 자연스럽게 진행된  한쪽이 JAVA 쪽을 맡고 한쪽이 JSP를 맡아서 진행하는 것이 그래도 가장 깔끔한 진행이었다. 여기서 한명 더 투입되면? 아직 대책없다.. ㅡ..ㅡ 형상관리 툴을 쓰긴 해야겠는데 일 배분은 어떻게 하지? 하는게 아직도 상당한 퀘스쳔 마크이다.
2008/04/07 23:56 2008/04/07 23:56