===== ===== =====
Peer Review는 동료 평가로 번역이 되지만, 동료 평가보다는 ‘피어 리뷰’로 쓰는편이 저의 느낌상 더 나아보입니다. 이 글에서는 피어 리뷰로 쓰니 이해해 주세요.구글이 성공하는 데 피어 리뷰 문화가 절대적이었다고 생각합니다. 피어 리뷰 문화가 구글의 핵심인 채용, 성과 평가 그리고 코딩에 실제로 어떻게 적용되었는지 알아보겠습니다.
피어 리뷰는 학계에서는 일반적인 프로세스
피어 리뷰는 학계 특히 과학/공학 분야에서는 일반적인 프로세스입니다. 논문을 컨퍼런스나 저널에 싣기전에 해당 분야의 다른 연구자들이 논문을 리뷰하고 필요한 경우 수정/보완하여 논문을 최종 출판합니다. 피어 리뷰는 해당 분야의 수준과 신뢰성을 유지하는 중요한 프로세스입니다.http://en.wikipedia.org/wiki/Peer_review
코드 리뷰
코드를 작성하고 코드 베이스(소스 코드를 저장하는 저장소)에 체크인하기 전에 반드시 동료로부터 코드 리뷰를 받아야 합니다. 팀 분위기에 따라 다소 차이는 있지만 코드 리뷰를 매우 철저하게 합니다. 시스템의 전체적인 구조에서부터 성능 향상을 위한 조언, 적절한 라이브러리의 사용, 유닛 테스트 그리고 공백의 개수와 주석의 오타까지 모두 리뷰를 합니다. 리뷰어는 한번에 많게는 수십여개에 이르는 개선 사항을 알려주고 리뷰를 받는 사람은 리뷰어가 보낸 의견에 대해 개선을 하거나 자기 의견을 달아 다시 리뷰어에게 보내는 식으로 몇 번을 주고 받은 후에야 비로소 체크인이 가능한 상태가 됩니다.코드 리뷰과정은 시간도 많이 소요되고 상당한 에너지가 소모되는 작업입니다. 그렇지만 그런 과정을 거쳐서 신뢰할 수 있는 코드를 작성할 수 있고, 리뷰를 받는 쪽이나 리뷰를 하는 쪽이나 새로운 기술을 배울 수 있으며, 코드의 작성자가 사정상 부재중일 때에도 그 코드를 리뷰했던 동료들이 무리없이 코드를 유지보수할 수 있게 됩니다.
회사 전체를 놓고 보면 코드 리뷰를 통해 코딩 스타일과 문화가 전체 구성원에게 전파됩니다. 구글의 소스코드는 중앙집중화된 코드베이스에 모두 저장되어 있는데 다른 사람 또는 다른 팀에서 작성한 코드도 모두 같은 라이브러리를 사용하고 같은 코딩 스타일을 가지고 있기 때문에 쉽게 이해할 수 있습니다.
구글에는 유닛 테스트, continuous build system, coding style checker, dependency monitor 등 다 헤아리기 힘든 소스코드 관리 기술과 시스템이 있습니다. 그리고 그런 자동화된 시스템위에 피어 리뷰를 기반으로는 하는 코드 리뷰 프로세스가 있었기 때문에 신뢰성있고 확장가능한 소프트웨어를 제공할 수 있습니다.
성과 평가
매년 정기적으로 이뤄지는 성과 평가때는 함께 일했던 동료들이 저를 평가하고 저 또한 동료들을 평가해줍니다. 피어 리뷰가 필요한 성과 평가는 보통 6개월 또는 1년 단위로 할 수 있습니다. 성과 평가에는 평가 대상자가 진행했던 프로젝트에 대해서 기여도, 결과, 프로젝트의 중요성 등을 적고, 대상자의 직무상 강점 그리고 좀 더 개발해야 할 영역에 대해서 정확하게 평가합니다.성과 평가 기간에는 제가 저를 평가해 줄 리뷰어를 선택하고, 요청을 받은 리뷰어들이 저에 대해 정직하게 평가해줍니다. 이때 리뷰어 중에는 요청을 받고 이런 저런 사정으로 거절하는 경우도 있습니다.
보통 매니저는 피어 리뷰에서 그리 큰 역할을 하지는 않는 것처럼 보이나 현실적으로는 피어 리뷰 결과를 가지고 다른 매니저들을 설득해야 하므로 성과 평가 체계에서 여전히(아니면 당연히) 중요합니다.
성과 평가 기간에는 부담이 많이 되지만 서로에 대해서 정직하고 정확하게 평가를 해줍니다. 상당한 시간과 에너지가 소요됩니다. 제가 했던 일에 대해 정확히 아는 동료들이 평가를 하기 때문에 신뢰할 수 있습니다. 또 제 작업 내용을 정확히 아는 동료들이 제가 노력해야 할 부분에 대해서 알려주기 때문에 수긍하면서 저를 발전시켜나갈 수 있습니다.
그리고 평소에도 동료들과 함께 하는 일에 최선을 다하게 됩니다. 저를 평가할 사람들이니까요.
피어 리뷰 기반의 성과 평가 체제의 장점은 실무적 수준에서 제대로 된 업무 평가와, 수직적 보고 체계가 아닌 수평적 동료 체계에서의 피드백이 가능하다는 점인데요. 회사 전체를 놓고 보면 코드 리뷰와 마찬가지로, 누가 일을 잘하는지 또는 누가 보상을 받아야 하는지에 대한 평가 표준이 피어 리뷰를 통해 전체 구성원에게 전파됩니다.
채용
회사는 사람이 움직이는 것이니 좋은 사람을 뽑는 것이 회사를 운영하는 데 첫째되고 가장 중요한 일입니다. 피어 리뷰 문화는 사람을 뽑는 데에도 적용됩니다.구글에 지원하는 사람들을 면접하는 면접관들은 그 후보자가 채용이 되었을 때 같이 일하게 될(같은 팀이 되는 것은 아니고 같은 부문에서 일하게 될) 사람들입니다. 예를 들어, 엔지니어 면접은 엔지니어가 직접 합니다. 한 두명의 엔지니어만 면접을 하는 것이 아니라 보통 대여섯명의 엔지니어가 차례로 면접을 합니다. 면접이 끝나면 해당 후보자와 같이 일하고 싶은지에 대해서 상세하게 적어서 채용위원회에 보고합니다. 채용위원회 또한 대부분 엔지니어들로 구성됩니다. 레쥬메부터 면접 결과까지 모든 것을 종합해서 함께 일하고 싶은지를 판단합니다.
후보자가 입사했을 때 함께 일할 사람들이 전문성을 가지고 판단하기 때문에 채용과정을 훨씬 신뢰할 수 있습니다. 그리고 여러 사람이 함께 결정을 하기 때문에 어떤 면에서 책임을 나눠진다고 볼 수 있습니다.
함께할 동료를 테스트하는 인터뷰 과정에서 (엔지니어의 경우) 기술적인 질문을 하지만 근본적으로 나보다 똑똑하고 내가 보지 못한 다른 세상을 보여줄 사람인지 점검합니다. 채용위원회도 입사후보자가 회사에 채용될 경우 뛰어난 엔지니어로 성장할 수 있는 잠재력이 있는지 검토합니다. 그 후에도 검토 절차가 더 남아 있지만 동료가 될 사람들이 후보자를 평가한 결과가 핵심적인 영향을 미치게 됩니다.
따라서, 채용 절차에서도 함께 일하고 싶은 인재상이 인사부서의 일방적인 결정이 아닌 동료들이 공유하는 문화로서 회사 전체에 자연스럽게 녹아들게 됩니다.
완벽한 시스템은 없다
구글이 이렇게 성공한 데에는 피어 리뷰 문화가 핵심적이었다고 말할 수 있습니다. 회사의 규모와 영향력이 십몇년만에 이 정도로 클 수 있었던 것도, 이 정도 규모에서도 독특한 문화와 신뢰성을 유지할 수 있는 것도 모두 피어 리뷰의 공입니다. 그러나 세상에 완벽한 것은 없다고 피어 리뷰 문화에도 문제점이 있습니다. 문제점이라기 보다는 문제가 될 여지가 있습니다.느리고 방어적인 프로세스
프로세스가 느려지고 의사결정이 보수적 또는 방어적이 될 가능성이 있습니다. 단기적으로 프로세스가 느려지는 것은 어쩌면 피할 수 없는 현상입니다. 장기적으로 신뢰성 있는 시스템을 만든다는 이득이 있으므로 감내할만하지요. 그런데 의사결정이 방어적으로 변하는 것은 조심해야 합니다. 특히 채용과정을 예로 들면, 여러명이 모여서 동등한 입장에서 의사결정을 하게 되므로 누군가 한 사람이라도 반대를 하는 후보자는 보통 떨어집니다. 채용의 과정이야 조금이라도 의심스러운 사람은 뽑지 않는 것이 좋다는 철학으로 설명할 수 있지만, 때로는 몇 가지 문제가 있더라도 결정을 내려야 할 때가 있습니다. 누군가가 책임을 지고 실행에 옮기는 것이, 다같이 동의하고 아무것도 안 하는 것보다 좋을 때가 있습니다.위기 대응 능력
데이터로 예측할 수 없는 상황에서 빠르게 의사결정을 해야할 때 피어 리뷰가 발목을 잡을 수 있습니다. 불확실한 상황에서 의사결정을 해야 하는 극단적인 예로 위기상황의 비행조종사들을 들 수 있습니다. 비슷한 수준의 조종사들이 에어버스를 조종하다 회복할 수 있는 결정적 순간들을 놓치고 결국 추락한 사례가 있습니다.https://plus.google.com/106545388800257341911/posts/UkZxDff7FNQ
절체절명의 순간에는 누군가 절대 권력과 무한의 책임감을 가지고 결단을 내려야 추락하는 비행체를 구할 기회가 있습니다. 나는 이렇게 생각하는 데 너는 어떻게 생각해? 추락하는 비행기 안에서 이런 토론은 무의미합니다.
다행히 제가 경험했던 구글은 위기때마다 잘 대처해 왔습니다. 그리고 위기를 극복하고 난 후에 사후검토(Postmortem)를 철저히 하여 무엇이 문제였고 어떻게 대처해야 했는지 기록하고 그 기록 또한 피어리뷰를 받도록 하여 조직 전체가 배울 수 있도록 했습니다.
옹고집은 어디에나 있다
워낙 똑똑한 사람들을 모아서 그럴까요? 아니면 똑똑한 사람들을 모아도 그 중에는 반드시 이런 사람 저런 사람이 발생하는 것일까요? 예를 들어, 코드 리뷰를 진행하면서 답답한 일들이 발생하는데요. 코드의 동작이나 속도 그리고 가독성에 아무 상관이 없는 사소한 것들을 가지고 몇 일동안 논쟁을 벌이는 경우가 가끔 있습니다. 서로 자기가 맞다고 생각하는 것에서 한치도 물러서지 않는 것이죠.피어 리뷰의 약점은 수평적인 분위기에서는 옹고집이 왕노릇하기 쉽다는 것입니다.
자, 지금까지 피어 리뷰의 빛과 어둠을 살펴보았는데요. 저의 의견을 물으신다면 저는 피어 리뷰 시스템이 좋습니다. 제가 워낙 실수가 많아서 동료들을 많이 의지하기 때문에요. 원래 피어 리뷰의 단점중에는 저 같은 실수쟁이들이 동료들을 시간을 뺐는다가 포함이 되어야 하지만 의도적으로 뺐습니다. 동료들의 희생으로 저 같은 사람이 빛을 발할 수 있으니까요. ^^;; (동료에게 항상 진심으로 감사하고 있습니다.)
댓글 없음:
댓글 쓰기