팀의 이상적인 크기

최소의 비용으로 최고의 프로그래밍을 원한다면, 가능한 한 최고의 프로그래머들을 구하고 그들에게 최소한의 인원으로도 문제가 없을 만큼 충분한 시간을 주어야 한다. 이것이 프로그래밍 팀의 크기와 구성에 대해 언제나 통용되는 기본 원칙이다. – 제랄드 M. 와인버그, <프로그래밍 심리학>

Adding manpower to a late software project makes it later. – Frederick P. Brooks, Jr., <The Mythical Man-Month>

저는 팀의 적절한 크기가 어느 정도인지 가끔 생각해 봅니다. 생각에 생각을 거듭한 결과, 제가 마지막으로 정리한 생각은 최소한의 크기가 좋다는 것입니다. 그 주장의 근거를 아래에 적어 보겠습니다.

작은 팀의 가장 큰 장점은 의사소통이 쉽다는 것입니다. 의사소통이 쉬우면 불필요한 절차가 줄어들고 결정이 빨라집니다. 또 의사소통이 쉽고 다른 사람의 작업을 파악하기 쉬우므로 파벌이나 불신이 생길 여지도 줄어들고 투명성이 높아집니다.

작은 팀은 효율적입니다. 한 사람이 할 수 있는 일을 두 사람이 나눠서 하게 되면, 서로 의사소통을 하느라 시간을 소비하게 되고, 자신이 잘 모르는 부분에 대한 잘못된 이해 탓에 문제가 생길 가능성도 큽니다. 또 팀의 크기가 커지면 묻어가거나 오히려 문제를 만드는 사람이 생기고, 그 사람 때문에 팀의 생산성은 급격히 떨어지게 됩니다. 하지만 작은 팀에서는 그런 일이 생기지 않습니다.

작은 팀은 동기 부여도 잘 됩니다. 팀에서 개인이 맡는 역할이 커져야 동기 부여도 되고 성취감도 커집니다. 그런데, 일거리가 많은 것보다 하나의 일이라도 제대로 하는 것을 원하는 사람에게는 오히려 안 좋을 수도 있겠습니다.

작은 팀의 가장 큰 단점은 작업 규모의 한계입니다. 팀의 크기가 작을수록 생산성이 높아지지만, 개발을 하다 보면 소수 인원만으로는 해결할 수 없는 일이 많습니다. 흔히 소프트웨어 개발을 할 때엔 뭔가 좀 더 효율적인 방법을 동원해 막노동을 줄일 수 있을 것으로 생각하지만, 실제로는 그것도 한계가 있습니다. 게다가 효율적인 방법을 찾고자 들어가는 시간도 무시할 수 없습니다. 따라서, 소수 인원만으로 안정되고 기능도 풍부한 제품을 빠르게 만들 수는 없습니다. 대개는 기능을 줄이고 일정에 맞추는 게 현실적입니다.

작은 팀의 보이지 않는 문제점 중 하나는 업무와 관계없는 부분을 공부할 시간이 적어지게 된다는 것입니다. 개인이 각자 중요성을 인식하고 노력한다면 모르겠지만, 대다수 사람은 일을 힘들게 하고 나면 자기 계발에 시간을 많이 투자하려 하지 않는 경향이 있습니다.

이렇듯 작은 팀엔 장단점이 있지만, 팀의 크기를 키우기보다는 기능을 줄이거나 개발 기간을 늘리는 게 더 나은 것 같습니다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중