Peer Review의 ‘검토’라는 의미에서 나오는 선입관때문에 많은 사람들이 거부감을 갖는다. 마치 내가 일을 잘못해서 조사받는다는 인상을 받기 때문이다.

물론 잘못된 것을 발견해서 고치는 것도 목적중의 하나이긴 하지만 근본적으로 Peer Review는 ‘어느 누구도 한 사람이 완벽할 수 없다’는 가정에서 출발한다.

소프트웨어는 근본적으로 완벽을 추구해야 한다. 시작부터 완벽을 추구하지 않고 대충 개발한 소프트웨어는 지뢰밭을 걸어가는 것이나 마찬가지다. 언젠가는 터지고 필연적으로 당도하는 ‘Fire Fighting’ 모드에 들어가서 터지는 문제의 해결에 많은 노력을 허비하게 된다. 그로 인해 발목이 잡히고 장기적으로 성공하기는 무척이나 어렵게 된다.

이 시나리오는 어느 정도 규모있는 소프트웨어를 개발해 본 경험이 있는 사람이면 쉽게 이해할 것이다. 성숙하지 못한 회사의 소프트웨어에서 발생하는 대부분의 중요한 문제는 사소한 개인의 결정에서 시작된다. 미리 검토만 한번 했더라면 이같은 문제가 애초에 생기지 않았을 텐데 하는 경우를 많이 본다.

Peer Review를 검토의 세밀함과 강도에 따라 세분해서 ‘Inspection’, ‘Review’, ‘Desk Check’ 등으로 두 종류나 세 종류로 구분하기도 한다. 이러한 분류에 따라 검토방식이 달라야 한다는 의미에서 세분화 했을지 모르나 검토의 목적을 명확히 이해하는 한 세분화하지 않더라도 얼마나 자세히 검토해야 하는 정도의 판단은 경험이 있는 사람이면 자율적으로 알아서 할 수 있다.

Peer Review는 부정적인 의미를 갖는 ‘검토’보다 사실은 ‘의논’이라고 하는 것이 더 가깝다. 의논없이 혼자의 능력을 과신하는 사람이 가장 위험하다. 그래서 혼자서 조용히 일하는 사람이 바로 요주의 인물이다. 천재라고 해도 소프트웨어에 관련한 방대하고 새로 생겨나는 모든 지식을 갖추기도 힘들고, 또 시간이 요구되는 직접경험을 소유하기도 힘들다. 그래서 다른 사람의 지식을 서로 빌리는 가장 좋은 방법이 Peer Review인 것이다.

Peer Review의 대상은 소프트웨어의 개발단계인 제품기획, 요구사양, 설계, 코딩, 빌드, 테스트 등에서 나오는 모든 산출물에 해당된다. Peer Review에서는 산출물의 내용만 검토하는 것이 아니라 어떤 산출물이 나와야 된다는 것도 토의되어야 한다.

개발방법론에서 명시한 수 많은 산출물 리스트는 가이드정도로 사용해야지 꼭 작성해야 한다고 생각하면 엄청난 비효율을 초래한다. 한 회사에서도 모든 프로젝트가 다 상이하다는 것을 고려하면 왜 산출물 리스트를 획일적으로 정하기 어려운 지 짐작할 수 있다. 많은 문서를 작성한다는 것은 그 만큼 미래에 변경이 필요할 때 많은 수정을 해야 한다는 것을 의미한다. 그리고 문서가 많다 보면 중복되는 정보가 여기저기 적히기 쉽다. 이런 것들을 여러 사람이 토의해서 가장 적절한 합의점을 끌어 내는 것이 중요하다.

Peer Review에서 여러 사람이 토의를 하게 되면 다양한 의견이 나오게 되는데 옳은 의견과 다수의 의견을 혼동하면 안 된다. 안건에 따라 어떤 방법이 적절한 지 선택해야 한다. 가장 쉬운 예로 코딩 방식 중에 괄호를 같은 줄에 적느냐 다음 줄에 적느냐 하는 것들은 많은 사람이 선호하는 다수결의 원칙을 따르는 것이 무난할 것이다.

하지만 대부분의 중요한 결정에서는 다수결의 방식이 부적절하다. 옳고 그르냐의 문제는 서로 의논을 해서 모두 이해시키고 설득해서 만장일치로 결정하는 것을 목표로 해야 한다. 모르는 사람을 적당히 설득해서 투표로 이기는 것은 좋은 결정이 될 수 없다는 것이다. 마지막 한 사람까지 진심으로 옳다고 생각하도록 노력해야 한다. 그래서 학습능력이 중요하다.

옳은 의견을 가지고 있다고 생각하는 사람이 다른 사람들을 확신시킬 수 있어야 하는데 다른 사람들을 확신시키지 못했다면 완전한 지식을 갖고 있지 못하거나, 안건이 너무 어렵거나 혹은 학습능력이 떨어지는 동료들일 수 있다. 어떠한 케이스이든 간에 이런 상황에 오게 된다는 것은 그리 바람직한 경우는 아니다. 서로 설득이 안 되는 경우 마지막 방법으로 투표를 하거나 ‘캐스팅 보트(Casting Vote)’를 가진 권위있는 사람이 결정할 수 밖에 없는데 투표를 하게 된다면 그 회사의 최고 전문가그룹에서 해야 한다.

많은 경우에 검토는 경험있고 지식있는 사람들이 이것 저것 물어도 보고 지적도 하면서 리드해 나가게 된다. 하지만 누구든지 완벽한 사람은 없기 때문에 여러 사람이 의견을 표출하고 그런 의견을 경청해 듣는 것도 중요하다. 이렇게 함으로써 치명적인 결함이 있을 수 있는 소수의 편견을 발견할 수 있게 된다.

아무리 완벽하게 작성했다고 생각하는 간단한 코드도 다른 사람이 보면 더 좋은 방법을 발견하는 것을 무수히 본다. Review를 받는 사람도 다른 사람이 Review를 한다고 생각하면 한번 더 쳐다보게 된다. 그럼으로써 생각하지 못했던 많은 부분이 수정되고 정리된다. 다시 볼 때 마다 더 좋은 방법이 끊임없이 생각나는 것이 필자의 경험이다.

효율적인 Review가 되기 위해서는 열등감을 없애야 한다. 어떠한 질문도 창피하다고 생각하지 않는 문화를 만들어야 한다. 어설프게 아는 사람이 열등감때문에 더 방어적이 되고 참여를 두려워 한다. 많이 아는 사람일수록 열등감이 없기 때문에 다른 사람의 의견을 스스럼없이 구하는 경우가 많다.

하지만 모두를 위해 긴장을 풀고 열린(Open) 분위기를 만들기 위해서는 모두가 바보 같은 질문을 하나씩 하는 것도 좋은 방법이다. 괜히 자존심 세우고 실수하지 않으려고 조용히 있는 것이 결국은 개인이나 회사나 경쟁에서 점점 더 뒤떨어지는 이유가 된다.