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

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

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