[23.08.06] 부트캠프 리뷰어의 자세

어느덧 회사를 제외한 여러 학습 기관(우아한테크코스, NEXTSTEP)에서 몇 번의 리뷰어 경험을 얻었다. 처음엔 단순히 업무 외 남는 시간에 소일거리 삼아 참여했던 일이 나름 또 성취감도 있어 꾸준히 기회가 될 때마다 참여하는 중이다. 리뷰어를 진행하며 그동안 느꼈던 감정들과 내가 추구하는 리뷰어의 자세에 대해 짧게나마 남겨두면 어떨까 생각만 하다가, 미뤄두면 또 잊어버릴 것 같아 이렇게 글을 적는다.

 

우선 나의 관점으로 보았을 때, 회사의 코드 리뷰와 학습 기관의 코드 리뷰는 목적이 약간 다르다. 회사에서 이루어지는 코드 리뷰는 제품을 정해진 기한 안에 최대한 안정적으로 배포하는 것을 목표로 한다. 그렇기 때문에 동료가 올린 PR에서는 1) 요구사항이 잘 동작하는지, 2) 코드의 변경으로 버그를 유발할 수 있는 side effect는 없는지, 3) 전반적인 컨벤션과 클린 코드를 준수하고 있는지 등 주로 제품에 초점이 한정되어 있다.

 

반면, 학습 기관에서 진행되는 코드 리뷰의 목적은 리뷰이의 성장이다. 제출한 과제가 완벽하지 않더라도 그 과정에서 리뷰이가 성장했다면 소기의 목적은 달성한 셈이다. 반대로 리뷰이의 어떠한 성장 없이 완성된 과제만 남았다면 그것은 목적에 부합하지 않다. 이것이 모순적이게 보일 수 있겠으나, 흔히 부트캠프에서 진행하는 페어 프로그래밍에서 뛰어난 한쪽이 대부분 코드의 주도권을 잡거나 리뷰이 본인의 고민 없이 외부의 코드만 긁어와 과제를 완성한 상황에서 이러한 경우를 쉽게 볼 수 있다. 따라서 리뷰어는 Pull Request + 여러 외부 소통으로 리뷰이의 상황을 가늠하고 더 나은 방향을 제시해 줄 수 있어야 한다.

 

이러한 역할을 수행하기 위해 스스로 몇가지 마인드셋 + 원칙을 정해두었는데, 이는 다음과 같다.

 

1. 리뷰이는 리뷰어의 리뷰를 선택적으로 수용할 권리가 있다

리뷰도 결국엔 리뷰이라는 ‘클라이언트’에게 제공하는 인적 서비스라고 생각한다. 물론 수강료 없이 지원을 받으며 학습할 수 있는 부트캠프도 존재하지만, 리뷰어 입장에서는 어느 경로든 리뷰에 대한 대가를 받으니 피차일반이다. 그리고 이걸 바꿔 말하면 리뷰이는 클라이언트로서 주어진 서비스를 선택적으로 수용할 수 있음을 의미한다. 만약 리뷰어가 경험이 많다는 이유만으로 무조건 반영해야 하는 리뷰라면 그것은 좋은 리뷰라고 할 수 없다.

 

리뷰이가 리뷰를 받아들이지 않는 것 같다면 거기엔 주로 두 가지 이유가 있다. 첫 번째로 리뷰어와 리뷰이가 알고 있는 수준의 갭이 커서 리뷰 몇 번으로는 코드 적용까지 무리인 경우다. 나는 이럴 때 당장의 코드 수정을 바라기보다 힌트가 될 수 있는 키워드를 건넨 뒤, 리뷰이 본인의 의견 혹은 이해한 방식으로 작은 예시 코드를 작성하여 코멘트를 주길 당부한다. 무조건 소스 코드를 더 좋게 만드는 것보다 먼저 찾아보고 이해한 무언가를 남에게 설명하는 경험이 성장에 중요하다고 보기 때문이다.

 

두 번째로 리뷰이가 리뷰를 이해하긴 했지만 본인이 추구하는 구현 방향이 있어서 리뷰 반영을 거부하는 경우다. 리뷰어의 의견이 정답에 가깝다 해서 그걸 받아들이지 못하는 리뷰이의 수준을 폄하할 필요는 없다. 코드 제어를 주도적으로 하고 싶은 마음은 개발자라면 응당 가질 수 있기에, 리뷰어가 얘기한 문제 상황을 직접 겪지 않는 이상 본인의 의도가 담긴 코드 베이스를 그대로 유지하고 싶을 수 있기 때문이다. 그래서 나는 리뷰이에게서 이런 뉘앙스를 느낄 때 현재 돌아가는 기능에 큰 영향이 있지 않다면 의견을 대체로 존중하는 편이다.

2. 마감 기한을 지키는 것은 생각보다 더 중요하다

보통 리뷰이는 과제 마감 기한에 쫓기는 경우가 부지기수다. 부트캠프라면 그 특성상 커리큘럼이 빡셀 수 있고 단순 강의라 할지라도 현업과 병행하며 과제를 제출하는 리뷰이도 있기 때문이다. 현업에서는 흔히 어떤 업무를 완료하는 데 이해관계가 많아지면 업무의 속도는 현저히 낮아진다. 만약 마감 기한이 있는 데도 이렇다면 결국에 가장 큰 부담을 지는 건 끝단의 업무를 담당하는 사람일 확률이 높다.

 

이를 학습 기관, 리뷰어, 리뷰이로 이루어진 관계로 빗대어보면 시간이 지체될수록 가장 부담을 안는 건 대체로 리뷰이다. 그렇기 때문에 리뷰어는 이러한 부분을 감안해서 리뷰 요청이 왔을 때 최대한 마감 기한을 맞출 수 있도록 하고 혹 시간이 늦어지더라도 리뷰이가 알 수 있게끔 소통하는 것이 중요하다.

 

그렇지만 사실 마감 기한이 중요하다는 건 다 안다. 내가 여기서 말하고 싶은 건, 마감 기한을 넘겨서라도 상세한 리뷰를 남겨 퀄리티를 높이느냐 vs 적당히 리뷰를 남기더라도 일단 마감 기한을 지키느냐의 맥락이다. 리뷰어 참여 당시 다른 리뷰어와 이야기를 종종 나눌 기회가 있었는데, 적지 않은 리뷰어가 '내 시간을 많이 투자해서 리뷰를 자세하게 남기면 리뷰이 입장에서 더 좋은 거 아닌가?'라고 생각했다. 반면 리뷰어에 대한 리뷰이의 평가를 살펴볼 땐 주로 '빠르게 리뷰를 해주는 리뷰어'가 더욱 좋은 평가를 많이 받았다.

 

물론 위와 같은 경험만으로 무조건 퀄리티보다는 마감기한을 생각하자! 라고 말하는 건 성급한 일반화다. 하지만 때때로 나의 관점에서만 바라보기보다 상대방이 원하는 부분을 파악하고 채워주려는 시도는 해봄직하다. 리뷰어는 본인의 시간을 좀 더 아끼고 리뷰이는 더 빠른 응답을 받게 되니 과제 마감에 쫓기지 않음과 더불어 잦은 핑퐁을 기대할 수 있어 서로에게 win-win을 이끌어낼 수 있다.

3. ChatGPT를 자처하진 말자

2번에서 이어지는 맥락인데, 상세한 리뷰를 자아내는 요인에 리뷰어의 재량, 성향 차이도 있지만 자칫 리뷰어가 자세히 답변할 수밖에 없는 질문들이 있다. 예를 들어 종종(보다는 좀 더 자주) 리뷰이에게서 다음과 같은 질문을 받기도 하는데,

 

- 리뷰어님은 A와 B 중에 어떤 것이 더 낫다고 생각하시나요?

- 이번에 A라는 개념을 알게 되어 코드에 도입을 해보았는데 이렇게 구현하는 게 맞을까요?

- 이렇게 하는게 맞는지 잘 모르겠습니다 ㅠㅠ (어떻게 하라는 걸까?)

 

위 질문들의 공통적인 문제는 질문의 범위가 넓고 직관적인 정답을 바란다는 것이다. 그렇기에 이런 질문에 답변을 잘 남겨보려다가 어느새 장문의 글이 뚝딱 완성되기도 한다. 물론 리뷰이 입장에서 쉽게 원하는 정답에 다가가기야 하겠지만, 리뷰어가 몸소 구글, ChatGPT를 대신한다고 리뷰이의 성장에 얼마나 도움이 될까? 나는 이런 질문을 받으면 잘 아는 내용이더라도 질문의 컨텍스트를 더 구체적으로 좁힐 수 있도록 유도하는 게 좋다고 본다.

 

리뷰이는 리뷰어에 비해 경험이 부족하기에 어떠한 답변이라도 바로 수긍하기 쉽다. 문제는 따로 정답이 존재하지 않는 영역에서도 리뷰어의 생각을 성급히 드러내면 그것이 리뷰이에게 정답으로 자리 잡을 수 있다는 것이다. 개발은 문제 해결을 위해 스스로 방법을 찾고 비교군을 검토하며 현재의 설계 구조에 적절히 녹아들 수 있는지 고민하는 과정이 반드시 수반된다. 그리고 이러한 능력을 키우기 위해서는 정답을 찾기 전에 좋은 질문을 만드는 훈련은 필요하다.

 

 

쓰다 보니 꽤 길어진 듯하다. 리뷰어를 계속하면서 글 쓰는 양이 늘었나 보다. 두서없이 막 쓰긴 했지만 내 생각이 모두 옳은 방향이라 단언하진 않는다. 더 좋은 방향이 있다면 얼마든지 적용해 봐야지.