리뷰! not 설명회

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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