About Pull Requests

코드 리뷰(Code Review)의 목적에 대해서 이야기해 본 적이 있다.^[각주:1] 코드 리뷰의 목적에 대해 말하면서 다음 번에는 코드 리뷰를 잘 하는 방법에 대해 이야기 하기로 했다. 그래서 코드 리뷰를 잘하기 위한 방법에 대해 공유해 보고자 한다. 가장 먼저 하고 싶은 이야기는 '숙제 검사 이야기'다.
 
코드 리뷰를 처음 접하는 사람들이 리뷰를 숙제 검사로 받아들이는 경우가 많았다. 어떤 일이 주어지면 그 것에 대한 기능을 개발하고나서 결과를 검사해 달라는 의미로 리뷰를 요청하였다. 보통 이런 경우는 몇 가지 특징이 있다. 예상 일정의 마감 직전에 풀 리퀘스트(PR; Pull Request)가 올라온다. 그리고 거기에는 꽤 많은 양의 코드가 포함되어 있다. 또한 코드에 대한 설명이 별로 없다. 보통 이런 코드 검토 요청은, 마치 '네가 시킨 일이 잘 동작하고 있는 지 알아맞춰봐' 라고 온 몸으로 말하는 것처럼 느껴진다. 이러한 방식은 건전한 코드 리뷰를 방해한다. 숙제 검사의 참여자들은 책임을 회피하려는 각자의 목적을 가지고 코드리뷰에 참여하기 때문이다. 코드 리뷰가 숙제 검사처럼 되었을 경우 각 참여자의 입장을 상상해보자. 검사자는 잘못된 점이나 부족한 부분을 찾으려고 할 것이다. 제출자는 최대한 헛점을 숨겨서 검사자에게 들키기 않으려고 노력할 것이다. 승인을 했다는 것은 책임을 지는 것으로 받아들이기 때문에 검사자는 승인을 최대한 미루거나 거부하려고 할 것이다. 동시에 승인 절차를 까다롭게 하는 것이 코드 품질을 높이는 방향이라고 생각하게되고, 내심 자신의 권력을 높이는 것이라고 느끼는 경우도 생긴다. 반면 제출자는 리뷰 승인에 따라 코드의 책임을 떠 넘길 수 있다고 생각하기 때문에 최대한 빨리 승인되기를 원한다. 그래서 코드에 댓글이 달리는 것을 싫어하는 경향을 보인다.
 
코드 리뷰의 목적에서 이야기했듯이 리뷰를 하는 것은 협업하기 위한 것이고 공동의 결과물을 잘 만들기 위한 것이며 공동의 결과물은 소비자에게 제공하기 위한 것이다. 따라서 소비자 중심의 생각을 갖는다면 건전한 코드 리뷰를 할 수 있다. 그러나 코드 리뷰를 숙제 검사로 인식하게 되면 코드의 주인공이 소비자가 아니라 개발자 (또는 작성자)^[각주:2]가 되며 코드 리뷰는 작성자의 실력을 시험하는 것이라고 받아들이거나 생계수단으로 주어진 과업을 단순히 수행한다는 인식을 갖게 돤다. 그렇게 되면 시키는 일만하게 되고 자기 방어적이 된다. 책임을 최대한 회피기 위하여 코드의 완성도를 높이기 위한다는 겸손의 말을 앞세워 마감전까지 코드를 공유하지 않는다. 이 것은 작은 병을 크게 키우는 것과 같는 행동이다.
 
따라서 좋은 코드 리뷰를 하기 위한 방법 중 가장 첫 걸음은 코드 리뷰에 대한 인식의 변화라고 말할 수 있다. 목적지를 설정하는 것이 여행의 기술 중 가장 중요한 시작점인 것처럼 좋은 코드 리뷰를 위해서는 다음과 같은 인식의 변화가 필요하다. 리뷰 요청이란, 자신이 작업한 결과물에 대해 설명하고 설득하는 과정이다. 작성자가 어떤 의도와 목적 그리고 어떤 방법을 사용해서 코드를 개선했는 지 발표하는 것이기도 하다. 때론 다른 사람들에게 자신의 지식을 상품화하여 영업하는 것이기도 하다. 풀 리퀘스트는 이름에서 알 수 있듯이, '당겨가는 것'^[각주:3]을 요청하는 것이다. 개발자 또는 작업자가 자신의 저장소에서 작업하고 그 결과물에 대해 가져가 달라고 요청하는 것이다. 이를테면 세일즈(Sales), 영업하는 것과 같다. 자신이 변경한 작업내용이 필요하다면 가져가도 좋다고 자신감있게 말하는 것일 수 있다. 또는 자신의 작업물이 다른 사람들에게도 꼭 필요하니 제발 가져가 써달라고 애원하는 것일 수 있다. 어떤 상황과 어떤 의도였든지 풀 리퀘스트는 자신의 것을 다른 사람에게 전달하는 과정이다. 다른 방식으로 비유해보자면, 자신이 만든 상품(코드)을 동료들에게 판매하기 위해 설득하는 과정이다. 자신이 만든 풀 리퀘스트가 병합되지 않았다는 것은 애석하게도 상품을 구매한 사람이 아무도 없다는 뜻이다. 그리고 리뷰 승인이란, 소극적으로는 코드 작성자의 생각을 어느 정도 소화했다는 것을 뜻한다. 적극적으로는 코드가 어떻게 동작할 것인지, 앞으로 자신이 코드를 만든다면 어떻게 해야할 지 생각해봤다는 뜻이다.

---

 

1. Purpose of Code Review [본문으로]
2. 코드를 꼭 개발자만 만드는 것은 아니기 때문에 작성자라는 표현도 붙였다. 때론 디자이너가 간단한 코드를 직접 만들수도 있다. 하지만 코드를 만들었다는 것은 곧 개발자라는 뜻이기도 하다. 별로 중요한 이야기는 아니다. [본문으로]
3. 당겨가는 것 또는 가져가는 것, 깃(Git)에서 풀(Pull)은 저장소에 있는 커밋(Commit)들을 가져와서 반영하는 명령 [본문으로]