거의 모든 SW개발은 팀으로 진행됩니다. 종종 혼자서 기획하고 개발, 테스트, 영업까지 모두 다하는 경우도 있기는 하지만, 이는 워낙 작은 규모의 회사에서 있는 일이고, 대부분은 팀을 이뤄서 일을 해야 효과적으로 SW를 개발해 낼 수 있습니다.
그 팀의 규모는 2명에서부터 수천 명에 이르기까지 다양합니다.
하지만, 주변에서 대규모 프로젝트 팀을 보기란 그렇게 쉽지 않습니다. 5~6명 안팎의 소규모 팀은 아주 흔하게 볼 수 있고, Teamwork도 꽤 좋은 편입니다. 하지만, 규모가 몇 십 명만 넘어가도 효과적으로 관리를 해내지 못하는 경우가 흔합니다. 그래서 팀이 규모가 커지면 프로젝트가 오히려 늦어진다는 얘기도 있습니다.
이런 경우라면 소규모의 팀은 제대로 된 Teamwork를 갖춘 것이 아니라 워낙 작아서 서로 인간적으로 잘 통하고 서로 커뮤니케이션을 왕성하게 하면서 프로젝트를 진행하기 때문에 문제가 없는 것이고 수십 명 규모의 팀은 똑같은 방법으로 커뮤니케이션이 잘 되지 않기 때문에 문제가 많을 가능성이 더 높습니다.
팀을 이뤄서 소프트웨어를 개발할 때 가장 중요한 것은 Review입니다.
Review에 익숙하지 않은 개발자들이 모여서 개발을 하는 것은 서로 따로 개발하는 개발자들을 한데 모아 놓은 것과 별반 다르지 않습니다. 이런 팀은 개발을 하면서 서로 다른 목표를 가지고 개발을 하기도 하고, 아키텍처
에 대한 오해를 하고 통합 시 인터페이스가 안 맞고, 일정이 서로 어긋나곤 합니다.
물론 각 개발자들이 서로 개발하는 모든 내용을 다 Review하고 공유할 수는 없습니다. 프로젝트의 규모에 따라서 또, 서로의 역할에 따라서 Review하는 범위와 대상이 달라집니다. 그럼 소프트웨어 개발팀에서 리뷰를 해야
하는 것들은 어떤 것이 있는지 알아보겠습니다.
1. SRS(스펙) 작성 및 리뷰 (중요도 : 매우 높음)
제가 여러 차례 강조했지만 SRS는 SW개발에 있어서 가장 중요하며 프로젝트 기간을 단축하고 비용을 절약하는데 가장 핵심입니다. SRS작성시는 개발팀 뿐만 아니라 프로젝트의 모든 관련자와 수 차례 리뷰를 합니다. 모든 관련자가 SRS의 모든 항목을 다 리뷰하는 것이 아니고 본인들이 책임지는 부분만 리뷰를 하면 됩니다. 예들 들어 Marketer인 경우는 프로젝트 목표와 비전, 주요 기능 등과 같이 마케팅에 필요한 부분만 리뷰를 하면 됩니다. 이렇게 SRS를 철저히 리뷰를 해야 모든 관련자가 프로젝트에 대하여 동일한 생각을 가지게 되고 프로젝트가 끝
날 때까지 스펙 변경을 최소한으로 유지하게 됩니다. 또한 이런 SRS리뷰가 일상적으로 반복적으로 일어나야 자연스러운 관행으로 자리잡고, 개발자들의 분석 능력을 향상하는데도 도움이 됩니다. 참고로 SRS(스펙, 요구분서)는 SW개발에서 약 40%의 비중을 차지한다고 합니다.
2. SW아키텍처 리뷰 (중요도 : 높음)
웬만한 규모의 SW의 아키텍처는 한 명의 머리 속에 나올 수가 없습니다. 아키텍처는 정답이 있는 것이 아니라서 생각을 많이 할 수록 좋아 질 수 있습니다. 개발자들은 설계 단계에서 이런 아키텍처 리뷰를 여러 차례 반복하게 됩니다. 그러면서 아키텍처를 점점 구체화 해나가고 개량해나갑니다. 규모가 큰 SW인 경우에는 상,하위 아키텍
처를 구분해서 설계를 하기도 하고 각 컴포넌트간에는 인터페이스만 정하게 되고 그 내부는 또 각 개발자들이 설계를 하고 리뷰를 하게 됩니다. 이 때 UML을 사용하건, Flow chart를 사용하건, DFD를 쓰던 큰 상관은 없으며 각자 익숙한 툴로 현재의 아키텍처를 가장 잘 표현할 수 있는 것으로 작성하면 됩니다. 이러한 과정 또한 선배 개발자들이 후배 개발자들에게 지식과 경험을 전달할 수 있는 좋은 기회가 됩니다.
3. 소스코드 리뷰 (중요도 : 중간)
소스코드 리뷰가 중요하기는 하지만 SRS와 아키텍처리뷰보다 중요하지는 않습니다. SRS와 아키텍처가 잘못되면 엄청나게 많은 재 작업을 해야 하지만, 소스코드가 잘못된 것은 버그로 발견되고 또, 상대적으로 쉽게 고칠 수 있습니다. 그렇긴 하지만 소스코드 리뷰는 좋은 관행이며 꾸준히 노력해서 정착해야 합니다. 소스코드 리뷰 방법은 매우 다양하지만, 저는 가장 간단한 방법은 Peer desk check을 권합니다. 소스코드 관리시스템에 Commit하기 전에 동료와 같이 리뷰를 하는 겁니다. 간단히 Diff툴을 실행해서 바뀐 소스코드를 볼 수도 있습니다. 그리고 소스코드를 등록할 때 누가 리뷰를 했는지도 꼭 기록하게 하는 정책도 소스코드리뷰를 확산하는 좋은 방법 중 하나입니다.
소프트웨어 개발에 있어서 Teamwork은 서로 사이가 좋은 팀을 말하는 것은 아닙니다. Teamwork에 있어서 서로 간의 신뢰는 중요한 요소이지만 필요충분조건은 아닙니다. 각자 전문가로서의 자신의 일들을 제대로 수행하면서 리뷰 등의 커뮤니케이션이 적절히 원활하여 동일한 목표와 비전을 가지고 SW를 개발해야 합니다.
우리는 흔히 혼자서는 일을 정말 잘하는데 뭉쳐 놓으면 삐걱대는 개발자들을 많이 보아 왔습니다. 이는 그 개발자만의 탓도 아닙니다. 서로들 Teamwork이 부족한 것이지요. 즉, 팀을 이뤄서 일하는 방법에 서툰 것입니다. 가장 좋은 방법은 제대로 되어 있는 회사에서 몇 년 일해보는 것입니다. 그런 환경이 안 된다면 SRS(스펙)리뷰부터 조금씩 활성화 해나가는 것이 좋습니다. 제대로 된 SRS(스펙)을 써보지 않는 개발자들에게는 SRS(스펙)을 쓰는 것도 큰 도전이지만, 어차피 SW를 제대로 개발하기 위해서는 피해 갈 수 있는 것이 아니기 때문에 시도를 해봐야 합니다.
좋은 Teamwork를 갖추지 못한 개발팀에서는 아무리 뛰어난 개발자라고 하더라도 제대로 실력을 발휘할 수 없습니다.
