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

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

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

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, 메이븐, …)이 그렇게도 유별 난건 아니자나. 저 기술을 쓰면서 개발하는 곳이 정말 그렇게도 없을까? 지금도 어디선가는 저 기술로 개발하고 있을 텐데. 글치.. 한국에서도 조금 큰 회사에서 이미 저렇게 하고 있자나. 그래도 역시 혼자는 너무 외로워. 하지만 사실 나 혼자는 아니지. 사부님도 있고 고객도 있으니까. 고객이랑 놀지 뭐. 그러고 보면 다음 프로젝트 기술은 사부님이 기술 결정을 하니까 내가 좋아하는 기술도 써먹어 볼 수 있단 말이지. 딱 저 문구에 맞는 상태로 개발하는.. 즐거움. 팀이 좋아하고 팀에게 익숙한 기술을 사용하는 이 즐거움을 다른 많은 개발자들도 알고 있겠지?? 그래야 할텐데..