코드 리뷰어를 하며 저지른 실수 7가지

코드 리뷰는 조직의 상황에 따라 실행하는 목적도 방식도 목표도 다르다. 그렇기에 정답이 없다. 그래서 내가 코드리뷰에 관한 글을 시작하기 앞서 내가 처한 상황을 설명하지 않는다면, 읽는 사람도 글을 이해하기 쉽지 않을 것이다. 나와 함께 일하는 조직은 아래와 같았다.

• 열 명 이하로 구성된 개발 조직이었다.
• 대부분의 개발자가 신입 사원이거나 경력이 2년이 채 되지 않는 주니어 개발자였다.
• 간혹 10년~20년 경력의 시니어 개발자가 있었으나 코드 리뷰 경험이 없었다.
• 실력 있는 개발자를 채용하기 어려웠다.
• Git을 SVN(Subversion)처럼 쓰고 있었다.
• 이슈 기반의 개발을 하고 있지 않았다.

코드 리뷰어로서 내 목표는 세 가지였다.

• 최소한의 코드 품질 유지
• 개발 코칭을 통한 개발자 성장
• 코드를 함께 보고 소통하는 문화 전파

이 글은 내가 코드 리뷰어를 하며 겪었던 실수의 기록이다. 내 실수가 다른 상황에서 코드 리뷰를 하는 독자들에게 도움이 되었으면 한다.

1. 내가 좋다고 생각하는 방식을 강요했다

이슈 기반의 코드 리뷰는 내가 몇 년간 해왔던, 익숙하면서도 좋아하는 방식이다. 나는 확신으로 가득 차 이슈 기반 코드 리뷰를 다른 사람들에게 강요했다. 강요는 당장에는 효과가 있을 수 있겠지만 복종 아니면 반항 두 가지 선택지만 있기 때문에 장기적으로는 강한 반작용을 부른다.

신입 사원이나 주니어들은 내가 강요한 방식을 어쩔 수 없이 따라왔지만 시니어 개발자들은 리뷰를 꺼려 했다. 리뷰를 꺼려 한다면 대화하여 거부감이 발생하지 않도록 주의를 기울여야 했지만 그렇지 못했다. 심리학 연구*에 따르면 사람은 어떤 대안이든지 그것을 바꾸기 보다 그대로 유지하려고 한다고 한다. 시니어 개발자들은 20년 가까이 본인이 해오던 방식이 있는데 이를 갑자기 바꾼다는 것이 말처럼 쉽지 않은 것이다. 시간이 지나자 어찌어찌 따라왔던 주니어들조차도 본인들의 방식으로 리뷰를 하겠다고 내게 말해왔다. 강요가 부른 강한 반작용이다.

*책 <프레임>(21세기북스, 2021, 최인철 지음) 261 쪽

요즘 나는 하고 싶어 하는 사람을 찾고 원하는 사람과 시작한다. 본인이 원하지 않는다면 내가 어떤 접근 방식을 쓴다 한들 절대 성공적으로 도움을 줄 수 없는 것이다. 시작은 원하는 사람을 찾는 것이다. ‘하고 싶어 하는 사람’을 나는 ‘긍정적 이탈자’*라고 부른다. 문화를 만드는 힘은 ‘밈(meme)’이다. 쉽게 말하면 따라 하는 것이다. 잘난 사람 몇 명이 억지로 강요한다고 되는 것이 아니다. 조직을 지탱하는 사람들 하나하나가 바뀌어야 하는데 그 핵심은 같은 상황 속의 동료(긍정적 이탈자) 중심으로 확산 시켜야 한다고 나는 믿는다.

*책 <긍정적 이탈>에서 나오는 말이다. 이 책에서 말하는 '긍정적 이탈'이란 특정 집단 안의 난제에 대해서 '분명 누군가는 이 문제를 극복한다.'는 가정에서 출발하며, 전문가가 직접 답을 내놓지 않고 집단 내부에 있는 특별한 소수를 발굴하여 그들의 방식을 집단 내에 확산시켜 문제를 근본적으로 해결하는 것이다. 

그렇다면 리뷰를 하지 않는 사람들의 최소한의 코드 품질과 코드를 함께 보는 것은 어떻게 할 수 있을까? 내 선택은 일주일 한 번씩 본인이 작성한 코드를 설명해 달라고 부탁하는 것이었다. 코드 리뷰가 아니라 공유를 제안하는 것이다. 여기서 주의할 점은 중요한 한두 가지만 의견을 말하는 것이다. 그렇지 않으면 강압적인 분위기가 될 수 있고 부정적으로 받아들여 공유조차도 꺼리게 될 것이기 때문이다.

내가 좋다고 다른 사람도 좋은 것이 아니다. 리뷰를 받는 개발자 스스로 자신이 도움이 된다고 인식해야 변화할 수 있다.

2. 맥락을 보지 않고 코드만 보았다

10년 이상 지난 전자 상거래 시스템을 개선하는 프로젝트에 참여한 적이 있다. 프로젝트 초반 내 역할은 현재 작성된 코드를 평가하는 것이었다. 당시 나는 다른 사람이 작성한 코드만 보고 일반적인 기준을 들이대며 비판하기 일쑤였다. 시간이 지나 프로젝트 후반에는 평가자가 아닌 주문(Order) 시스템 개발자로 복잡한 업무 코드를 직접 작성할 수 있는 기회(?)를 얻었고, 그 덕에 나는 중요한 깨달음을 얻을 수 있었다.

코드가 이렇게 작성된 데에는 그럴만한 이유가 있었구나.

텍스트(Text)에 깔린 서브텍스트(Subtext)를 읽지 못했고 이것들을 감싸는 컨텍스트(Context)를 읽지 못했다. 눈이 보이는 텍스트(코드)만 보았던 것이다.

함께 일하는 동료는 내게 “사연 없는 코드는 없다”라고 말했다. 그런 코드를 작성할 수밖에 없었던 상황이 있는 것이다. 물론 코드 작성이 서투른 사람이 있을 수 있으며, 관심이 없는 사람이 있을 수 있다. 하지만 그런 사람들도 상황에 영향을 받는다.

코드 리뷰는 대화다. 맥락이 없는 대화는 이해하기 어렵고 오해하기 쉽다. 아래 그림에서 보는 것과 같이 성공적인 대화의 핵심은 상대방과의 교집합을 만드는 것, 즉 맥락을 나누는 것이다.

코드만 보며 즉각적으로 비판하기보다는 그렇게밖에 행동할 수 없었던 맥락을 보려 노력할 때 우리는 조금 더 관대해지며, 코드를 정확하게 볼 수 있다.

3. 묻지 않고 내 말만 했다

새롭게 조직에 합류한 개발자가 내 리뷰 기록을 보더니 이렇게 말했다.

영모 님 코드 리뷰 댓글에는 마침표가 너무 많아요.

미처 인지하지 못한 부분이었다. 그 말을 듣고 내가 남긴 댓글을 다시 보니 빨간펜 선생님처럼 행동하고 있었다. 채점하듯 내 의견을 일방적으로 전달하고 있었다. 코드 리뷰는 토론할 수 있고 코드 리뷰어가 작성한 내용은 지시가 아니라 의견일 뿐이다. 내 말만 하는 것이 대화를 막는 원인이었다.

또한 하나의 리뷰 요청에 너무 많은 의견을 남기고 있었다. 상대방은 배려하지 않은 채 이렇게 의견을 많이 남겼다며 혼자 뿌듯해했다. 너무 많은 의견이 코드 작성자를 힘들게 할 수 있다는 점과 리뷰를 부정적으로 받아들이게 만들 수 있다는 점을 깨달았다.

요즘 나는 의견을 남길 때 상대의 의견을 이끌어내기 위해 되도록이면 물음표로 끝내려 한다. 질문은 대체로 폐쇄형과 개방형 두 가지 중 하나에 속한다고 한다. 

폐쇄형 질문은 그렇다, 아니다 또는 단답형의 대답을 듣게 된다. 신속하게 정보를 구할 때  유용하다.(중략) 폐쇄형 질문은 질문자나 응답자의 사고를 자극하지 않는다. 대화가 계속 이어지지  않는다.

* 보고서를 끝냈습니까?
* 제품이 얼마나 많이 필요한가요? 
(중략) 

만일 대화를 계속하고 싶다면 개방형 질문을 해야 한다. 개방형 질문은 사람들로 하여금 생각을 하게 만들고 토의를 이끌어 낸다.

* 어떻게 그런 결정을 내리게 되었나요?
* 이 일을 좀더 잘하려면 어떤 점을 바꿔야 할까요?
- 책 <질문의 7가지 힘> 43~45쪽

효과적인 대화를 위해 폐쇄형 질문과 개방형 질문을 적절히 섞어 사용해야 한다. 폐쇄형 질문만 하다 보면 상대방에게 심문하는 느낌을 줄 수 있기 때문이다. 그리고 ‘너무 많은 의견’은 꼭 고쳐하는 부분을 2~3개 정도만 의견을 남기려고 하고 나머지 부분은 리팩토링(Refactoring)을 유도하려고 한다.

“모르는 것을 아는 척하기는 쉽지만 아는 것을 모르는 척하기 어렵다.”라는 말이 있다. 내가 아는 것을 토해내듯 말했다. 글을 시작하며 코드 리뷰 목표 중 하나가 ‘개발 코칭을 통한 주니어들의 성장’이라고 언급했는데 일방적인 피드백은 상대를 성장시키기 어려웠다.

내가 두 아이를 키우며 배운 것이 있다. 삶의 경험 많은 부모 입장에서 아이의 시도를 가로막는 것이 아이 성장에 결코 도움이 되지 않는다는 것이다. 우리는 직접 해보면서 깨닫고 배운다. 먼저 해보았다고 상대방에게 하지 말라고 하면 반발심만 커진다. 그리고 항상 내가 옳은 것도 아니다. 본인이 스스로 깨달을 수 있도록 충분히 시간을 주어야 한다. 내가 알고 있다고 가로막으면 상대는 학습의 기회를 잃는다.

4. 원격 그리고 비동기 소통만을 고집했다

내가 리뷰어로 참여하는 프로젝트는 일주일이 2번 정도만 오프라인(Offline)으로 만났기에 리뷰는 자연스럽게 원격/비동기로 진행했다. 이 방식을 채택한 이유 중 하나는 내가 코로나19가 시작되기 몇 년 전부터 원격으로 일하는 것이 익숙했기 때문이다.

온라인 코드 리뷰는 글로 의견을 나누며 소통한다. 하지만 글말은 입말처럼 억양이 보이는 것이 아니다. 그러다 보니 내 의도를 전달하기가 쉽지가 않아 상대가 오해하는 일도 왕왕 일어났다. 별 의미 없이 썼던 의견이 의도치 않게 상처를 주기도 했다.

어떤 고객이 “당신이 아직 나의 주문을 처리하지 못했다고 생각하는데요”라는 메일을 보내왔다면 그가 빈정대는 것일까, 화를 내는 것일까, 당신이 얼마나 바쁜지 잘 알고 있다는 의미일까 고민하게 된다. 이 때 의미 파악에 단서가 되는 목소리를 들을 수 없는 경우에는 최악의 의도를 추측하기 쉽다. - 책 <우주인들이 인간관계로 스트레스받을 때 우주 정거장에서 가장 많이 읽은 대화책> 82 쪽

이에 더해 내가 의견을 쓰면 코드 작성자가 본인의 의견을 거의 말하지 않고 지시처럼 받아들이는 것을 보며 “의견이 없는 것인가?”라는 생각이 들었는데 의견이 없는 것이 아니라 자신의 생각을 글로 표현하는 것을 어려워한다는 사실도 깨달았다.

어떤 경우에는 얼굴을 보며 대화해야 좋을 때가 있다. 사람의 눈빛과 얼굴 표정 그리고 말의 억양에는 생각보다 많은 것이 담겨 있기 때문이다. 그리고 내 경험상 얼굴을 보며 대화할 때 더 많은 정보를 준다. 또한 사람은 얼굴을 보고 말할 때 좀 더 관대해진다.

요즘 나는 내가 생각하는 방식과 코드가 너무 많이 다를 때 혹은 오해가 발생한다고 느끼면 바로 화상을 요청한다. 일일이 지적하는 것이 아니라 얼굴을 보며 의견을 나누는 것이다. 이에 더해 오프라인으로 만날 때에는 지난 코드 리뷰를 함께 보며 당시 내가 놓친 맥락을 찾으려 한다.

5. 공유하지 않았다

리뷰를 하며 개발자는 다르지만 비슷한 내용의 의견을 반복해서 쓰는 나 자신을 발견했다. 개발 조직 안에서 자신의 코드 리뷰를 결과를 서로 공유하지 않는다는 의미였다. 그것도 그럴 것이 개발자는 코드를 작성하고 코드 리뷰를 거치며 고치는 것에 집중할 수밖에 없었던 것이다. 리뷰 결과가 전파되지 않는 것은 리뷰어로서의 내 문제였다. <요즘 IT>에 번역된 ‘"자바스크립트는 자리에서 물러날 때입니다" JSON 창시자 인터뷰’에서 더글러스 크록포드(Douglas Crockford)는 아래와 같이 말했다.

더글러스: 영화 제작에서는 아침마다 전날 촬영한 영상을 검토하는 '데일리스dailies'라는 시간이 있습니다. 모두가 앉아서 영화를 보며 시간을 낭비하는 것처럼 보이지만, 문제를 조기에 발견하고 제품의 품질을 확실히 하는 데 매우 중요한 시간이죠. 저는 프로그래밍에서도 그렇게 해야 한다고 생각합니다. 저희는 매일 아침 팀원들이 모여 전날 개발한 모든 코드와 디자인을 검토하는 시간을 갖습니다.

더글러스가 말하는 ‘데일리스’처럼 코드 리뷰 과정에서 나온 의견을 공유했어야 했다. 공유 주기는 조직에 상황에 따라 달라질 수 있는데 나는 일주일은 넘기지 않는 게 좋다고 생각한다. 그 이유는 기억을 유지하려는 노력을 하지 않으면 시간이 지남에 따라 빠르게 잊거나 왜곡되기 때문이다. 다른 사람에게 본인이 작성한 코드를 설명해 달라고 부탁해 보면 며칠 전에 작성한 코드는 왜 이렇게 작성했는지 잘 기억하는 반면 일주일이 지난 코드는 왜 그렇게 작성했는지 머뭇거리며 골똘히 생각하는 것을 나는 많이 관찰했다. 마르테 오텐 네덜란드 암스테르담대 심리학과 교수 연구팀에 따르면 사람은 불과 몇 초 전에 발생한 일에 대해서도 기억을 왜곡해 저장할 수 있다는 연구 결과가 나왔다. 불과 몇 초도 이럴진대 일주일이 넘은 코드는 어떻겠는가?

더불어 코드를 공유하는 자리의 분위기가 중요하다. 비웃거나 비난하지 않는 편하게 말할 수 있는 분위기를 만들어 주어야 한다. 내가 ‘당신이 성장하지 못하는 이유’에서 언급한 심리적 안정감이 필요한 것이다.

요점은 학습할 수 있는 환경을 만들어 주어야 하고, 새로운 시도에서 실수가 드러났을 때 괜찮다는 심리적 안정감(Psychologial Safety)을 주어야 한다는 것이다. 그렇다면 심리적 안정감은 구체적으로 어떻게 만들어질까? 나는 개발자 B와의 대화에서 사례를 찾을 수 있었다. 개발자 B는 개발 주기가 끝나면 회고 자리를 가졌는데, 이 회고에서 실수를 공유하더라도 아무도 비판하지 않아 심리적 안정감을 느꼈다고 한다. 즉, 실수를 말할 수 있는 자리와 분위기를 만들어주고 실수를 말할 때 비웃거나 비난하지 않았던 것이다.

6. 리뷰 규칙을 합의하지 않았다

리뷰를 요청하는 사람은 바로바로 리뷰가 진행되기를 원한다. 개발 일정이 정해져 있기 때문이다. 리뷰어로서 최대한 빨리 코드를 보려 하지만 나를 둘러싼 상황을 완전히 통제할 수 있는 것은 아니기에 종종 늦는 경우가 있다. 개발자는 개발 일정에 민감할 수밖에 없다. 코드 리뷰가 개발 속도를 느리게 만든다고 생각한 어느 개발자는 내가 아닌 팀 안의 동료와 코드 리뷰를 하겠다고 말했다.

리뷰 시기를 합의했어야 했다. 예를 들면 아래와 같은 식이다.

• 최대 반나절 안에 리뷰를 진행하겠다. 그게 안된다면 별도로 알려 주겠다.
• 긴급 건인 경우 리뷰에 댓글을 적어 준다면 바로 진행할 수 있다.

리뷰가 언제쯤 시작하고 끝나는지 얼마나 걸릴지 예측 가능해야 개발자가 일정을 어느 정도 맞출 수 있다. 시기 말고도 단순한 코드 리뷰 규칙을 합의할 필요가 있는데 '코드 리뷰 이야기(1)’에서 언급된 내용은 참고할 만하며 나 역시 이 방식을 따르고 있다.

규칙으로서 합의하기는 어렵지만 중요한 것이 있다. 바로 코드량이다. ‘코드 리뷰에 켄트 벡의 아이디어 접목하기’에서는 PR(Pull Request 혹은 Merge Request) 크기와 출시 속도를 언급하며 코드 리뷰의 경제성에 대해 말하고 있다.

한편, 켄트 벡의 글에 굉장히 흥미로운 도식이 등장합니다. 악순환을 표현한 그림이죠. (중략) PR 크기가 커진다는 말은 한 번에 검토해야 할 코드의 양이 많다는 말입니다. 그렇게 되면 자연스럽게 지연이 발생하고 팀 전체의 출시 속도를 늦출 수 있습니다. 여기서 출시 속도의 중요성을 강조하고 싶습니다. 소프트웨어의 빠른 출시는 현대 비즈니스 환경에서 개발팀의 가장 중요한 경쟁력입니다. 이를 받아들이고 나서 다시 위의 그림을 보면 한 가지 중요한 단서를 얻을 수 있습니다. PR 크기를 줄일 수 있다면 혹은 PR 크기가 큰 일이나 개발자의 문제를 팀이 이해하게 되면 지연을 줄이고 팀의 출시 속도를 늘릴 수 있는 기회가 생긴다는 것입니다.

리뷰가 길어지지 않게 리뷰어가 시기나 의견의 수도 신경 써야 하겠지만 놓치지 말아야 할 것이 바로 PR 크기인 것이다.

PR 크기는 합의하기가 매우 어려운 부분이다. 개발자에게 PR 크기를 작게 해달라고 요청할 수 있겠지만 작업을 작게 나누어 하는 것이 익숙지 않은 개발자는 실천하기 어렵다. 어떤 기준으로 나누어 할지 잘 모르기 때문이다. 그래서 나는 의도적으로 개발 작업을 만들 때 참여하여 작업을 작게 나누는 것을 코칭 한다. 작업을 작게 나누면 자연스럽게 PR 크기 역시 작아지기 때문이다.

7. 따뜻함이 부족했다

사람은 망각의 동물이라고 했던가. 내가 리뷰를 요청하는 입장에서 리뷰어의 따뜻한 한마디가 큰 힘이 되었다는 사실을 잊고 살아왔다. 리뷰어로서 나를 뒤돌아 보니 문제를 지적하는 의견이 대부분이었다는 것을 깨달았다. 코드를 보면 못한 부분만 있는 것이 아니라 잘한 부분도 있는데도 말이다.

따뜻함은 당장의 효과를 내지 못하지만 장기적으로는 긍정적인 효과를 준다는 연구 결과들이 많다. 김창준의 이글루스에 발행된 글 '혹독한 조언이 나를 살릴까?'*에서도 이를 잘 보여준다.

*2023년 6월 16일 이글루스 서비스가 종료되어 현재는 김창준의 글을 찾아볼 수 없다. 아래 인용문은 작가가 이전에 기록해둔 내용에서 발췌한 것이다.

글로리아를 비난하는 조언은 그녀를 성장시키지 못했습니다. (중략) 심리상담학이 수십년 연구를 통해 결론을 내린 것이 하나라도 있다면 그것은 내담자를 존중하지 않는 방식은 장기적으로 효과가 없거나 부정적이었다는 것이고, 동시에 내담자들은 이 방식에 현혹될 수도 있다는 것이지 않을까 합니다.

또한 미국 UNC 케난 플래글러 경영대학원의 오벌 셀저 교수는 <하버드 비즈니스 리뷰>에 기고한 ‘Don’t Underestimate the Power of Kindness at Work’ 에서 친절함이 관대함을 만들고 관용과 도움, 칭찬은 높은 생산성과 낮은 퇴사율로 나타난다고 말했다.

요즘 나는 이전 리뷰에서 언급했던 것이 이번 리뷰에 반영하는 조그마한 변화라도 있다면 응원의 댓글을 달려고 한다. 또한 별도의 의견이 없더라도 ‘’좋아요’ 표시를를 달아 상대방에게 관심을 표현하려 한다.

마치며

소프트웨어는 ‘사람’이 만든다. 그리고 ‘함께’ 만든다. 리뷰어로서 지난 몇 년을 뒤돌아 보니 이 사실을 잊고 있었다는 생각이 들었다. 의지가 앞서 내 생각을 강요했고 맥락을 제대로 나누지 못했으며, 묻지 않고 내 말만 하기 바빴다. 이런 방식으로는 내가 원하는 것을 얻을 수 없었다.

내가 원하는 것을 얻기 위해서는 ‘함께’해야 한다. ‘함께’의 핵심은 내 생각을 자제하고 다양성을 인정하며 변화의 기회를 주고 기다려 주는 것이다. 그리고 그 밑바탕에는 사람에 대한 존중이 있다. 물론 쉽지 않은 일이다. 그래서 문화를 만드는 것이 아주 어려운 것이다. 나는 다른 사람들을 돕고 싶었다. 시행착오를 거쳐 깨달은 것이 있다면 ‘다른 사람을 돕는다는 것’의 핵심은 기술적 코칭이 아니라 인간적 배려라는 것이다.

마지막으로 켄트 벡의 책 <익스트림 프로그래밍>에 나오는 문장을 인용하며 마친다.

나는 나 자신을, 그리고 다른 사람들을 인간적으로 대할수록 모든 사람의 생산성이 더 높아진다는 사실을 깨닫기 시작했다. 성공의 열쇠는 자신에게 고생을 강요하는 것에 있지 않으며, 사람 대 사람의 사업에서 우리 모두 사람이라는 사실을 인정하는 것에 있다. - 26쪽

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.