Peer Review를 성공하기 위한 요소들

얼마 전에 "코드리뷰 정착이 어려운 이유"라는 글을 올린 적이 있습니다.

그에 대해서 codeart 님께서 코드리뷰에 대한 일반적인 방법론에 대해서 궁금해 하시더군요. 하지만 이런 방법론은 알면 도움이 되지만, 이것을 안다고 코드리뷰를 성공하는데는 별로 도움이 안됩니다. 하지만 몇가지 성공 요소는 생각해 볼 수 있습니다. 

이제부터는 코드리뷰보다는 Peer Review라고 하겠습니다. 사실 코드만 리뷰를 하는 것이 아니고 스펙문서부터 소스코드등 개발 관련된 산출물들을 다 리뷰를 합니다. 그리고 동료들간에 검토를 해 준다는 것이 중요한 요소입니다.

그럼 Peer Review를 성공하기 위해서는 어떻게 해야 하는지 한번 보죠.

첫째, 개발자들끼리 으쌰으쌰 해서는 성공하기 힘듭니다. 회사에서 정책적으로 Peer Review를 추진해야 합니다. 개발잘들끼리 한번 해보려고 하는 것은 Peer Review를 너무 우습게 본 겁니다. 그냥 시간 좀 내서 서로 리뷰해주면 되지 뭐 그렇게 어려울게 있어? 라고 생각하면 오산이죠. 일단 많은 시간을 빼앗기는 것이 가장 큰 장애물입니다. 처음에는 의욕적으로 시작했다가, 금방 시들해지게 됩니다. 아직 Peer Review가 정착되지 않은 회사에서 개발자들끼리 한번 시도해보는 것은 거의 대부분 실패합니다. 따라서 회사에서는 Peer Review 담당자도 지정을 해주고, 제도와 자원을 지원해야 합니다.

둘째, 개발일정에 Peer Review를 포함해야 합니다. 그러면 더 시간이 오래 걸린다구요? Peer Review가 조금만 정착이되어도 결국은 이것이 훨씬 시간을 더 절약해준다는 것을 알아야 합니다. 테스트 시간이 절약되고, 유지보수 비용이 절약되고, 후배들이 빨리 성장하고 여기저기서 중복된 코드를 만드느라고 헛되이 보낸 시간이 절약됩니다. 이는 너무 뻔한 것이기 때문에 Peer Review가 개발 시간과 비용을 얼마나 절약하는지 증명하라고 하면 허탈하죠.

셋째, Peer Review는 동료와 하는 겁니다. 강사가 학생들을 가르치는 것도 아니고, 고객에게 설명을 하기 위한 것도 아니고, 서로 리뷰를 하면서 결함을 찾는 겁니다. 여기에 집중해야 합니다.

넷째, 자주해야 합니다. 프로세스에 따라서 빡빡하게 진행하기보다는 수시로 동료들과 리뷰를 하는 것이 좋습니다. 언제든지 "이것 좀 봐줘"하면서 부탁을 할 수 있고, 짧은 시간을 내서 흔쾌히 봐주면서 차츰 적응해 가야 합니다. 많은 양을 몰아서 리뷰를 하게 되면, 쉽게 질려서 포기하게 되고, 모든 코드와 문서를 모든 개발자가 다 리뷰를 해야 하는 것은 아니니 수시로 적당한 동료와 리뷰를 하면 좋습니다.

적어도 이 네가지만 지켜도 Peer Review를 지속하는데 약간의 도움은 될 겁니다.

그런데, 왜 Tool에 대한 설명은 없냐구요? Tool이 리뷰를 대신해주지는 않기 때문에 Tool을 그렇게 심각한 요소는 아닙니다. Tool이 도움이 될 수는 있지만, Tool이 없다고 리뷰를 못하지는 않습니다.

위 조건을 보면 일단 첫번째에서 막힐 수 있습니다. 설령 회사차원에서 Peer Review를 시행하더라도, 촉박한 일정에 쫓겨서 쉽게 포기해버리기 일쑤입니다. 이런 상황이라면 Peer Review가 정착하기는 어렵습니다. 회사도 단단한 의지가 없다면 Peer Review를 정착시키는 대단히 어렵습니다.

이렇게 만만한 일이 아니기 때문에 회사의 개발 성숙도에 따라서 적절한 계획이 필요합니다. 처음부터 욕심부리면 금방 포기하게 됩니다.