기술 보다는 팀이 개발 정책을 세울 때 우선이 되어야 한다.

당연한 말이죠. 그런데 정말 이렇게 하고 계신가요?

오늘 “사람을 위한 자동화” 시리즈를 번역하다가 멋진 문장 하나를 발견했습니다. (번역을 하면 이게 좋습니다. 정독을 하게 되고, 정독을 하다보면 좋은 문장도 놓치지 않을 수 있죠.)

There are probably version-control systems that support parallel
development better than Subversion, but in my experience the policies
that teams adhere to when developing are much more important than how a
tool technically solves the problem.

병렬로 개발할 때 서브버전보다 더 좋은 툴도 있겠지만, 본인 경험상 개발을 할 때 기술 보다는 팀원에게 익숙한 정책을 세우는게 더 중요했다는 내용입니다.(아마도 GIT 같은 분산 SCM을 두고 말한거 같네요.)

저 한 문장이 저한테 참 많은 생각을 하게 합니다.

SI에 대한 (경험없고 몽매한 저의) 생각

실제 제품 코드 작성하는 개발자들이 자꾸 바뀌는 환경에서 저런게 가능한가? SI가 어쩌다 그런 구조가 됐을까? 팀 단위로 다니는 SI 업체에서는 가능할까? 그 사람들은 프로젝트에 가서 코딩만 하고 기술 선택에 대한 의사결정에 어떤 영향을 주고는 있는 건가? 그런 의사결정 권한이 있는 사람들은 코딩하는 개발자들을 팀으로 생각할까 아니면 종으로 생각하고 있을까? 일단 다 정해놓고 와서 코딩만 시키는거 아닌가? 어떻게 그렇게 개발을 하지? 고객과 개발자가 직접 만나서 일을 하면 안 되고 꼭 중간다리 역할을 하는 사람이 있어야 하나? 그 사람들이 실제로 코딩을 할 개발자들과 같이 개발을 할꺼면 상관없겠지만 그런 경우가 아니라 아예 업체도 다르고 개발할 사람들이랑 전혀 공감대도 없다면. 뭔가 잘못 된 거 아닌가? 개발자와 고객 사이를 막고서서 자기들의 입지를 만들고 개발자 의사소통 능력을 점점 쇠퇴시키는거 아닐까? 개발자는 왜 의사소통을 못한다고 생각하지? 못 하는게 아니라 안 하니까 퇴화 되는거 아닌가? 고객과 개발자가 직접 만나서 대화를 하면 오히려 중간 다리가 고객 – 인코딩 디코딩 – 개발자 – 디코딩 인코딩 – 고객 사이의 네 번의 인/디코딩 과정이 사라지니까 훨씬 좋은거 아닌가? 그래야 위와 같이 팀을 고려한 정책을 만들지 않을까?

나에 대한 내 생각

내가 공부하는 것들을 다른 사람들도 공부하고 있을까? 난 누구랑 일할 수 있는거지? 내가 좋아하는 기술을 포기하고 다른 사람들에 맞춰서 혹은 누군가 이미 다 정해놓은 틀 속에서 개발을 해야 하는건가? 어떻게 해야 되는거지.. 나도 팀 생활을 하고는 싶은데, 내가 사용하고 싶은 기술로는 팀 생활을 할 수가 없고.. 난 선택의 기로에 서있는 건가? 팀이냐 기술이냐 라는 선택인가?? 흠..아니야. 내가 쓰고 싶은 기술(스프링, 하이버, 스프링 DM, 메이븐, …)이 그렇게도 유별 난건 아니자나. 저 기술을 쓰면서 개발하는 곳이 정말 그렇게도 없을까? 지금도 어디선가는 저 기술로 개발하고 있을 텐데. 글치.. 한국에서도 조금 큰 회사에서 이미 저렇게 하고 있자나. 그래도 역시 혼자는 너무 외로워. 하지만 사실 나 혼자는 아니지. 사부님도 있고 고객도 있으니까. 고객이랑 놀지 뭐. 그러고 보면 다음 프로젝트 기술은 사부님이 기술 결정을 하니까 내가 좋아하는 기술도 써먹어 볼 수 있단 말이지. 딱 저 문구에 맞는 상태로 개발하는.. 즐거움. 팀이 좋아하고 팀에게 익숙한 기술을 사용하는 이 즐거움을 다른 많은 개발자들도 알고 있겠지?? 그래야 할텐데..

OSAF 공개에 대한 이 생각 저 생각

프로젝트 시작

사부님의 글 스프링과 하이버네이트를 이용한 RAD프레임워크 – OSAF(OpenSprout App. Framework) 공개에도 나와있지만, 이 프로젝트를 시작하게 된 시점과 여자친구에게 차인 시점이 교묘하게 일치합니다. 그리고 그 즈음에 경제가 막 악화 되면서 프로젝트가 연이어 연기 되거나 파토나는 상황이 이어졌습니다. 현재까지도 좀 그런 상태라 회사에 나와서 할 일이.. 딱히 없었습니다. 일이 없어도 워낙 하고 싶은 공부도 많고 번역할 꺼리도 많았기 때문에 심심하지는 않았는데.. 문제는 도태되는 느낌. 그리고 헤어짐에 대한 아픔. 그 두 가지는 무슨 일을 해도 해결할 수가 없었습니다. 집중할 것이 필요했습니다.

그래서 처음엔 일을 늘려나갔습니다. 번역과 스크린캐스팅을 늘려나갔습니다. 주말에도 일을 해야지 일정에 맞출 수 있을 정도로 말이죠. 그리고 취미를 만들었습니다. 사부님이 추천해준 큐브도 돌리고, 어렸을 때 배웠던 피아노가 생각나서 피아노 학원도 다니기 시작했습니다. 그런데도 기술적으로 도태되는 느낌과 시련의 아픔은 여전히 어떻게 할 수가 없었습니다. 그래서 OSAF를 시작했습니다.

내가 사용하는 이 프레임워크가 얼마나 좋은지 보여주고 싶었습니다. 그리고 그 당시는 그다지 잘 알고 있지도 않아서 더 알고 싶은 마음도 있었습니다. 대체 이 많은 태그는 어떻게 만들었으며 그리드가 어떻게 동작하는건지 말이죠. 저에겐 딱 좋다 싶었습니다. 공부도 되고, 집중도 할 수 있으니깐 말이죠.

프로젝트 진행

토비님이 거의 모든 핵심 코드를 작성했다고 봐도 무방합니다. 저는 그 코드에 살을 조금 붙이거나 공개를 위해서 수정을 했습니다. 주석을 달고, 사이트를 준비하고, 예제를 만들고, OSGi 서비스 기반으로 제공할까 하다가 실패를 해서 그냥 패키지 기반으로 전환, 그리드 태그 만들다가 DisplayTag가 적절치 않음을 발견, 그리드 태그 변환으로 인해 CRUD 형태가 기존과 달라짐, 덩덩덩. 여러 문제가 있었습니다.

하다보니, 예전에는 무심코 지나갔던 코드도 다시 들여다보게 되고, 공부할 것도 간간히 등장하더군요. 하지만, 공부할 것들이 너무 많아서 자칫 공부에 빠지면 공개를 못하겠다는 느낌이 들었습니다. 선택의 기로였죠. 공부냐 공개냐. 공부를 하자니 공개를 못하겠고, 공개를 하자니 공부를 못하겠고. 선택은 아시다시피 공개를 선택했습니다. 공부야 언제든 계속 하면 되는데, 지금 이렇게 시간 있을 때 공개 못하면 나중엔 더 힘들것 같았거든요. 그래서 공부를 좀 미루더라도 공개하기로 결정했습니다.

프로젝트 공개

공개하는 과정도 쉽지가 않았습니다. 일단 웹 사이트라도 있어야 하는데 그러려면 도메인이 있어야 하고, 서버도 있어야 되고, 그 서버에 위키, 이슈 트래커, CI 환경, 덩덩덩이 있어야 됐거든요. 근데 그런 귀찮을 일을 사부님 한테 맡길 순 없자나요. 그래서 제가 다 했습니다. 리눅스에 톰캣 깔고, 아파치랑 연동하고, 연동할 때 모르는거 물어보고, 개발 환경 제품들은 전부 Atlassian 제품들도 설치했습니다. 라이선스는 처음엔 그냥 임시 라이선스를 가지고 설치하고, 나중에 설치도 하고, 도메인 설정도 하고, 준비 중인 코드를 일단 올려서, 오픈 소스 라이선스를 신청했습니다. 근 2주 정도 뒤에 오더군요. 그걸로 라이선스를 바꿔서 이제 1년 간은 라이선스 걱정없이 사용 할 수 있게 됐습니다. 막바지에는 개발 해오던 프로젝트 구조와는 달리 멀티 프로젝트 구조의 메이븐 프로젝트로 변경해서 공개 했습니다.

프로젝트 3일 후

이제 공개 한 지 3일이 지났습니다. 일단은 후련합니다. 그리고 근 세달에 걸쳐 OSAF를 다듬고 수정하고 공개하는 시간을 지나면서 시련의 아픔도 차차 나아졌습니다. 지금도 사실 완치됐다고 느껴지지는 않지만 예전 보단 정말 많이 나아졌습니다. 그리고 두려움이 다가옵니다. 이렇게 세 달 동안 노력해서 공개한 프레임워크가 잘 살아갈 수 있을지 말이죠. 책임감이 느껴집니다. OSAF가 잘 살지 못하고 아무런 관심도 못 받고 아무도 사용하지 않고 묻혀버릴 거라면 내가 지금 괜한 일을 한 것 아닐까. OSAF라는 이름에 누를 끼치는 건 아닐까. 말이죠. 그래서 의무감이 생깁니다. 절대로 먼지가 쌓이지 않게 해야겠다. 계속 다듬어야겠다. 지금은 비록 많이 부족해도 언젠간 반짝 반짝 빛이 나도록 말이죠.

앞으로

OSAF는 최첨단 프레임워크가 될 예정입니다. 포기 했었던 OSGi 서비스 기반을 다시 시도하고, 이클립스 플러그인 개발을 해서 IDE로 코드 생성을 지원하고, 그리드 태그를 개선할 겁니다. 그리고 스프링 3.0이 출시되면 RESTful을 지원할 것이며, 스프링 Security 예제도 제공하고, 메이븐 아키타입으로 OSAF 기반 웹 애플리케이션 개발을 아주 쉽게 사용할 수 있도록 할 것입니다.

OSAF 관련 활동 말고, OpenSprout 활동으로는 스프링, 하이버 RI 프로젝트 및 OSGi 관련 프로젝트도 사부님과 구상 중입니다. 새로운 OpenSprout 멤버도 모집할 것 같습니다. 아직 구체적인 계획은 없지만, 아무래도 사람이 좀 더 있어야 하지 않을까 싶습니다.

끝으로

새싹아.. 무럭 무럭 자라거라. OpenFlower, OpenTree, OpenForest가 되는 날까지. ㄱㄱㅆ!!