코드리뷰에 관하여

코드 리뷰를 처음 접한 건 5년 전 개발자로 처음 회사에 입사하던 때였다. 그전까지 내가 겪은 거라곤 대학교 프로젝트가 전부였던 터라 협업에 대한 경험이 부족했었고, git, github 같은 협업 툴도 사용해본 경험이 별로 없는 상태였다. 

 

처음 코드리뷰를 시작했을 때, 나는 굉장히 코드 리뷰에 어울리지 않는 사람이었다. 코드 PR을 요청하면 지적을 들을까 봐 스트레스를 받았고 상대 PR이 이해가 되지 않음에도 Approve 버튼을 누르곤 했다.

 

5년이 지난 지금, 코드리뷰는 일상이 되었으며 근거가 있는 어떠한 비판이나 지적도 열린 마음으로 받아들일 수 있다. 다른 사람의 코드도 구현하고자 하는 목표에 맞게 구현되었는지 볼 수 있게 되었다. 시간이 지나면 누구나 할 수 있는 것이 코드 리뷰인 것 같다. ('잘' 하느냐의 문제는 별개지만..)

 

코드 리뷰란?

코드 리뷰는 개발자가 개발한 내용을 다른 사람에게 공유하고 다른 사람이 그 내용을 이해하는 과정을 말한다.

github(필자가 주로 사용하기 때문에...)에서는 Pull Request를 통해 리뷰를 요청한다. 이때, 공유를 게시하는 사람을 Assignee, 리뷰를 진행하는 사람을 Reviewer라 한다.

 

Assignee

먼저, 코드를 게시하는 사람이 갖춰야 할 항목들이 있다. 

 

1. 열린 마음

 코드 리뷰는 일반적으로 게시된 코드의 잘못된 점, 혹은 보다 나은 방법으로 개선할 방향들을 제시하곤 한다. 이 과정에서 자신의 코드가 누군가에게 평가가 되고 코드의 잘잘못을 따지곤 한다. Assignee는 이를 편하게 받아들여야 한다. 물론, 근거가 없는 지적은 비난밖에 되지 않겠지만, 근거가 명확하다면 이를 받아들이고 내 것으로 만들 수 있어야 한다.

 처음에 코드 리뷰를 임하는 마음이 열리지 않아서 마음고생했던 것을 생각하면 아직도 아찔하다. 그땐 그 상황을 불평하고 불만을 가졌지만, 지금 돌이켜보면 모든 스트레스는 내가 마음을 열지 않았기 때문에 발생하지 않았을까?

 

2. 의문

 다른 개발자들과 함께 일을 하다가보면 실력의 격차가 발생한다. 내가 공유한 코드를 나보다 실력이 좋은 개발자가 리뷰를 하게 되는 상황이 발생하면 "당연히 이 사람말이 맞겠지?"라는 생각과 함께 코드 리뷰에 대한 반영에 수동적으로 변할 수 있다. 물론 자신보다 실력이 뛰어난 사람은 언제나 존재하지만 모든 리뷰가 옳은 방향이겠거니 생각하는 건 오류가 뒤따르는 법이다.

 

3. 명확한 개발 내용

 개발된 내용을 공유할 때 Reviewer가 내가 개발한 내용을 이해할 수 있게 하는 것이 중요하다. 할당받은 업무를 기능별, 목적별로 용도에 맞게 나누고 이에 대한 리뷰 요청을 각각 진행하는 것이 좋다. Reviewer는 나의 코드를 봐주기 위해 고용된 사람이 아니라, 본인의 업무를 진행하다가 시간을 내어 리뷰를 진행한다는 사실을 명심하는 것이 좋다. 

 또한, 내가 개발한 내용이 나중에 수정이나 개선될 때 꼭 내가 수정할 것이라는 보장은 없다. 다른 사람이 해당 업무를 할당받았을 때 코드만 보고 전반적인 구조와 기능을 파악할 수 있다면 가장 좋겠지만, 필요에 따라 Commit History를 보곤한다. 이때도 PR의 목적이 분명하다면 업무 파악이 용이할 것이다.

 

Reviewer

코드 리뷰는 Reviewer에게는 귀찮은 작업일 수 있다. 내가 해야할 일이 산더미처럼 쌓여있는데 다른 일이 생기는 것을 누가 좋아하겠는가. 그럼에도 리뷰를 해야한다. 이때 Reviewer가 조금 더 신경쓰면 좋은 항목들이 있다.

1. 근거, 대안

 비판과 비난의 차이는 잘못을 지적만 하느냐, 그 이유와 대안을 제시하느냐의 차이일 것이다. 코드 리뷰에서도 마찬가지다. 리뷰하고 있는 코드의 오점을 발견했을 때 근거나 대안과 함께 제시한다면 이는 비판이 될 것이고, 그렇지 않으면 그저 비난에 그치지 않는다.

 개발을 하다보면 함수나 변수의 이름을 고심하게 된다. 어떤 단어가 더 이해하기 쉬운 단어인지 여러 번 고민하고 PR을 올렸는데 "부적절한 단어인 것 같아요."라는 식의 리뷰를 받았던 경험이 있다. 나는 몇 번의 고민과 검색 끝에 내린 결론이 부적절하다니 당황스러울 뿐이다. 잘못된 것이라면 받아들이면 된다. 하지만 당시의 나는 무엇이 잘못되었는지 이해하지 못했다. Reviewer 조차 대안을 제시하지 않았다. 

 근거, 대안이 있는 리뷰는 Assigneee가 찾지 못한 길을 제시할 수 있다. Assignee는 그 길을 따라 어떤 점이 잘못되었는지, Reviewer의 의도가 무엇인지 파악할 수 있을 것이다.

2. 배려

 코드 리뷰도 결국엔 사람이 하는 행위이다. 사람과 사람이 같은 목적을 이루기 위해서 소통하는 방법 중에 하나이다. 다만, 게시하는 사람과 리뷰하는 사람이 나뉘어져 있을 뿐. 대화 속에서의 두 관계는 배려에 따라 길몽이 될지, 악몽이 될지 결정된다. 리뷰하는 중에 말 한마디를 신경쓴다면 Assignee에게 이번 코드 리뷰는 좋은 기억으로 남을 것이다.

 

 

 코드 리뷰는 중요하다고 생각한다. 개발자 입장에서는 내가 해야할 일에 추가되는 업무고 이것 저것 신경써야할 것이 늘어난다. 회사 입장에서도 코드 리뷰로 인해 정작 개발할 시간이 줄어들어 업무의 진도가 다소 늦어지기도 한다. 하지만 개발자 입장에서는 코드의 질, 동료의 업무 파악 등 실보다 득이 많은 게 사실이다. 회사 입장에서도 멀리보면 오류를 줄여 나중에 수정 및 개선 작업에 소요될 리소스를 줄이는 방법이기도 하다.

 꼭 해야하는 것이라면 어떤 마음가짐으로 임하느냐가 중요하다고 생각한다. 기왕 해야할 것이라면 보다 긍정적으로 감정이 상하지 않는 것이 중요하다. 코드 리뷰의 목적은 개발자간의 경쟁이나 감정 소모보다는 보다 좋은 코드를 작성하는 것이기 때문이다.