리뷰! not 설명회

소프트웨어를 개발할 때 가장 중요한 활동 중 하나가 리뷰다. 특히 Peer review다.

리뷰가 중요하다는 것은 소프트웨어 개발에 종사하는 사람들은 거의 다 알 것이다. 하지만 막상 리뷰를 어떻게 하고 있나 살펴보면 제대로 하고 있는 경우는 별로 없다.

우리나라에서 흔히 볼 수 있는 리뷰의 형태는 설명회 방식이다. Reviewee(리뷰를 받는 사람)가 내용을 하나씩 설명하면 Reviewer(리뷰를 하는 사람)들이 설명을 듣고 있다가 의견을 얘기하는 방식으로 진행하는 경우가 많다.

많은 Reviewer들은 사전에 리뷰자료를 읽지 않거나 훑어만 보고 참석해서 설명을 들으면서 의견을 얘기하곤 한다. 이런 형태의 리뷰는 문제가 많다.

일단 시간이 오래 걸린다. 웬만한 프로젝트의 스펙문서는 수백페이지에서 천페이지를 넘곤한다. 그런데 이런 설명회 방식의 리뷰로는 며칠이 걸릴지 짐작도 안된다. 모든 내용을 꼼꼼하게 훑으면서 리뷰를 하기도 어렵고 나중에는 시간에 쫓겨서 대충 끝내버리기도 한다.

또한 난상토론 방식으로 진행을 하다가 마무리를 못하기도 한다. 그렇게 다시 수정된 문서를 리뷰하게 되면 첫번째 리뷰보다 충실하게 진행되기 어렵다. Reviewer들도 이미 봤던 내용을 또 보기 때문에 대충 검토를 하게 된다.

이런 부실한 리뷰를 통해서 진행되는 소프트웨어 프로젝트는 수많은 난관을 만나기 마련이다.

설명회 방식의 리뷰는 지양해야 한다.

리뷰는 진짜 리뷰여야 한다. 리뷰의 목적은 여러 가지가 있지만 가장 중요한 목적은 여러 관점에서 전문가들이 검토를 해서 문제점을 찾아내서 고치는 것이다. 리뷰를 진행하다고 하면 Reviewer는 사전에 문서를 한글자, 한글자 빠짐없이 꼼꼼히 검토해서 의견을 제시해야 한다. 그래서 오프라인 리뷰 없이 온라인으로 진행하기도 한다.

하지만 오프라인 리뷰가 같이 의논을 할 수 있어서 더 효율적이다. 그렇게 여러 Reviewer들은 미리 완벽하게 검토를 해서 리뷰 자리에서는 문서를 한줄 한줄 같이 보는 것이 아니라 검토할 내용들만 빠르게 의논하고 결론을 내고 끝내는 것이다. 천페이지짜리 스펙문서가 2시간에 리뷰를 마치기도 한다.

이렇게 하기 위해서는 일단 문서가 잘 적혀야 한다. 웬만한 이슈들은 사전에 개별 담당자와 검토가 완료되었고 오프라인 리뷰를 요청할 때는 98% 정도 완성이 되었을 때 가능한 것이다.

그리고 리뷰는 한번에 끝내야 한다. 이렇게 Reviewer들이 많은 노력을 들여서 검토를 했는데 이런 리뷰를 여러 번 해야 한다고 하면 2, 3번째 리뷰는 제대로 진행이 되지 않는다.

리뷰를 한다는 의미는 공동 책임을 진다는 의미다. 그런데 설명회에 구경와서 한마디씩 툭 던지고 책임은 지지 않는 사람이 너무 많은 것 같다.

전문가도 아니면 윗사람이라고 툭툭 던지는 얘기가 프로젝트를 망치게 할 수도 있다. 경영자라면 스펙을 리뷰할 때 Product scope 부분의 Business Strategy, Corporate Goal 등의 내용을 심도 있게 검토하면 된다. 각자 전문분야가 다 있다.

하지만 노력이 많이 드는 리뷰는 원하지 않고 편하게 앉아서 설명해 주는 것을 듣기나 하겠다고 설명회를 원하는 경영진들은 권위의식과 귀차니즘에 빠져 있는 것이다.

MS에서 초기에 엑셀을 개발에서 스펙을 리뷰할 때 빌게이츠가 스펙 문서를 모두 읽고 와서 윤년 계산에 버그를 발견하여 리뷰 때 얘기를 했다는 일화는 유명하다. 빌게이츠는 당시 CEO였지만 Chief Architect의 역할로서 스펙을 모두 검토했던 것이다.

소프트웨어를 제대로 개발하고 싶다면 권위의식은 버리고 리뷰를 제대로 진행해야 한다. 개발자들도 건성건성 구경하러 가는 리뷰는 지양해야 한다. 리뷰에 참석했다는 의미는 공동으로 책임을 진다는 생각을 하고 철저히 검토를 해야 한다.

SW개발과 Teamwork, 그리고 Review

거의 모든 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를 갖추지 못한 개발팀에서는 아무리 뛰어난 개발자라고 하더라도 제대로 실력을 발휘할 수 없습니다.

프로세스가 창의성을 저해한다고?

개발 프로세스가 창의성을 저해한다고 싫어하는 개발자, 관리자, 경영자를 종종 만나게 됩니다. 이들이 프로세스를 싫어하는 이유는 과거에 개발 프로세스 도입에 대한 실패의 경험이 있거나 그런 얘기를 종종 전해 듣기 때문입니다.

이렇게 개발 프로세스 도입에 실패하는 이유는 현실성이 없는 이론적인 프로세스를 도입하거나 회사의 역량 수준에 맞지 않는 프로세스를 시도한 경우가 많습니다. 또 인터넷이나 책을 통해서 배우게 된 프로세스를 따라 하다 보면 그 Context를 다 알지 못하고 형태만 비슷하게 흉내 내다가 실패하기도 합니다.

그럼, 그렇다고 프로세스가 없다면 창의성이 샘솟을까요?

개발프로세스가 제대로 갖춰지지 않은 회사는 대부분 각 개발자들의 개인 역량에 따라서 적절히 개발이 이루어지며 개발자들은 역할의 구분 없이 만물박사 식으로 온갖 업무를 처리합니다. 이러다 보면 항상 바쁘고 새로운 기술을 조사한다거나 참신한 생각을 할 틈이 별로 없습니다. 또, 멋진 아이디어가 떠올라도 마땅하게 Follow up할 방법이 없어서 아이디어를 떠올린 개발자가 북치고 장구치고, 경영층도 설득하고, 프로토타입도 만들어보고 시장 조사도 해보고 해야 합니다. 안 그래도 바쁜 마당에서 짬을 내서 또 새로운 아이디어를 Follow up하기는 정말 어렵습니다. 누가 무슨 일을 얼마나 하고 있는지 잘 파악이 안되므로 또 이런 일을 벌여서 괜히 성과도 없이 평가만 안 좋아 질까봐 포기하기 십상입니다. 또 아이디어 낸 사람이 총대를 매야 하기 때문에 그렇다고 기존의 업무가 줄어들지 않기 때문에 공식적으로 이런 활동을 안하려고 합니다.

하지만, 개발 프로세스를 잘 갖추고 있는 회사는 아이디어를 내기만 하면 일단 회사의 System이 이를 Follow up합니다. 일단 아이디어는 수면 위로 떠올라서 여러 사람과의 Review를 통해서 더욱 Refine되고 정식 절차를 통해서 Prototype을 만들고 마케터는 시장 조사를 하고 영업은 고객들의 의견을 수집해 옵니다. 관리자는 해당 개발자가 아이디어를 발전시킬 수 있도록 정식으로 업무를 할당해서 시간을 빼줍니다. 한마디로 개발자는 기술적인 것만 Follow up해도 됩니다. 물론 모든 아이디어가 제품화 되는 것은 아니지만, 이런 아이디어들이 10개 100개 모여서 성공하는 제품이 나옵니다.

결국 프로세스가 창의성을 저해한다는 생각은 무지의 산물이거나 잘못된 경험의 결과입니다.

문제는 회사의 몸에 딱 맞는 개발프로세스를 갖추는 것이 어렵다는 것입니다. 현재 개발을 어떻게 하고 있는지 조사를 해보면 제각각 일겁니다. 이것부터 통일해 나가면서 조금씩 바꿔가는 것이 스스로 해볼 수 있는 최선의 방법입니다.