지속 가능하고 효율적인 코드 리뷰를 하는 방법

아마도 팀 단위의 프로젝트를 경험해본 개발자라면 코드 리뷰를 해본 경험이 있을 것이다. 코드 리뷰는 개발자가 작성한 코드를 다른 동료 개발자들이 검토하는 과정이다. 코드 리뷰는 잘 이루어진다면 코드의 품질을 향상시키고, 예기치 않은 에러를 방지하며, 팀원 간 지식 공유를 활성화하는 아주 유용한 문화가 될 수 있다.

 

그러나 코드 리뷰 문화를 잘 유지하는 것은 생각보다 쉽지 않다. 코드 리뷰는 시간과 자원이 많이 들 뿐만 아니라, 막상 어떤 부분을 리뷰해야 할지 막연할 수 있기 때문이다. 이런 상황이 계속된다면, 코드 리뷰는 서로 "수고하셨습니다"라는 댓글만 남기는 아무런 의미 없는 피상적인 행동으로 남게 된다.

 

이번 포스팅에서는 효율적이고 유용한 코드 리뷰 문화를 유지하기 위한 리뷰어와 리뷰이의 역할에 대해 내가 경험한 실제 프로젝트와 사례를 기반으로 설명해보고자 한다. 또한 코드 리뷰에 적절한 대안에 대해서도 논의를 해보고자 한다.

 

 

좋은 리뷰를 위한 리뷰어의 역할

리뷰어는 동료 개발자가 작성한 코드를 리뷰하는 사람을 뜻 한다. 소프트웨어 개발의 재미있는 점 중 하나는 동일한 문제에 대한 해결책이 작성자에 따라, 심지어는 같은 작성자라 해도 시간과 환경에 따라 달라진다는 것 이다. 즉 코드에 '정답'이 없다는 뜻이다. 물론 잘못된 코드도 때론 존재해 객관적인 리뷰가 가능하지만, 대다수의 리뷰는 주관적인 의견에 기반한다.

 

이러한 점은 리뷰를 어렵게 만든다. 자신의 주관적인 의견을 주장하는 것은 쉬워 보이지만, 훈련이 부족하면 생각보다 어려울 수 있기 때문이다. 여기서는 리뷰어로서 코드 리뷰를 진행할 때 어떤 부분을 집중적으로 리뷰해야 하는지 유형별로 분류하고, 어떤 점들을 피해야 하는지에 대해서도 살펴보도록 하겠다.

 

무엇을 리뷰해야 하는가?

 

1. 의도 파악하기

코드 리뷰 과정에서 필자가 가장 자주 질문하는 유형은 코드를 읽는 사람의 입장에서 볼 때, 의도가 명확히 드러나지 않아 이해하기 어려운 부분에 대해서 질문하는 것 이다. 좋은 코드는 도메인 지식이 부족해 세부 동작에 대한 이해가 어려운 경우에도, 추상화와 적절한 이름을 통해 '무엇'을 하는지 이해할 수 있어야 한다.

코드를 읽는 사람 입장에서 코드의 목적과 의도를 파악해본다

의도를 파악하기 힘든 이유는 추상화가 제대로 이루어지지 않거나, 데이터 중복과 같은 설계 상의 문제 때문인 경우가 대부분 이다. 따라서 아래와 같이 질문을 남기고 리뷰이와 소통을 통해 더 나은 설계로 이어지는 경우가 상당히 많다.

코드 리뷰를 통해 더 나은 설계로 이어졌다.

리뷰를 질문 형태로 남기는 것에 대한 의문이 있을 수 있는데, 그 이유는 다음과 같다. 먼저 내가 잘 이해하지 못한 경우가 있을 수 있고, 더 중요한 이유는 리뷰이가 한번 스스로 생각해볼 수 있도록 하기 위해서 이다.

 

2. 예상치 못한 오류 예방하기

리뷰를 하다보면 리뷰이보다 리뷰어가 해당 코드 영역에 대해 지식이 더 많은 경우가 있다. 이 경우 리뷰어는 리뷰이가 미쳐 생각하지 못한 오류를 발견할 수 있다.

코드 리뷰를 통해 예상치 못한 문제가 코드베이스로 흘러가기 전에 예방했다

스스로 회고해보면, 리뷰어가 실수한 것은 앞으로도 누구나 실수 할 수 있다고 생각한다. 따라서 리뷰어의 문제로만 보지 말고, 코드베이스에서 실수를 유발하는 부분이 있는지 점검하고, 같은 실수가 다시 일어나지 않도록 수정하는 기회로 삼도록 하자

 

3. 지식 공유하기

코드베이스는 팀원들의 문제에 대한 이해와 지식의 총 합이다. 리뷰이의 코드는 그들의 멘탈 모델이 투명하게 반영된다. 따라서 코드 리뷰는 팀원들 사이의 지식 공유에 매우 적합하다.

 

코드 리뷰를 통해 팀원이 문제를 이해하고 해결하는 방식, 장애물을 극복하는 방법, 그리고 새로운 기술을 사용하고 표현하는 방법을 배우도록 하자. 궁금한 점이 있으면 질문하고, 더 좋은 아이디어가 있다면 제안하고 논의하는 과정을 거치자

지식 공유하는 종종 회의로 이어지고 이러한 대화를 통해 일관성이 확보된다.

코드 리뷰를 이렇게 활용하면, 담당하지 않는 문제에 대한 이해도를 높일 수 있다. 이는 문제를 더 넓은 거시적인 관점에서 바라볼 수 있게 해준다. 또한 팀원들과 대화를 더욱 많이 나눌 수록 코드베이스의 일관성을 확보할 수 있고, 기존 지식을 확장하여 새로운 기술을 배울 수도 있다.

 

4. 더 나은 설계 제안하기

물론 리뷰이가 충분한 고민을 하고 코드를 작성했겠지만, 때로는 리뷰어가 리뷰이보다 더 좋은 설계에 대한 아이디어가 있을 수 있다. 이럴 때는 과감하게 리뷰를 남기자.

 

실제로 다른 사람들이 보았을 때, 리뷰이의 설계가 더 우수할 수도 있으며, 내가 한 제안이 반영되지 않을 수 있다. 그렇다고 하더라도 제안하는 것이 무의미한 것은 아니다. 지식 공유의 관점에서도 중요하며, 내 생각이 잘못되었다면 차라리 빠르게 제안하고 부셔지는 것이 나를 위해서라도 더 낫다.

더 나은 설계를 제안했다

리뷰이가 이미 작업한 내용을 새로운 설계로 다시 개발하라는 것은 물론 즐거운 일이 아닐 수 있다. 그러나, 정중한 태도로 제안하고, 함께 고민하겠다는 의도를 표현한다면, 리뷰이도 이것이 악의가 아닌 보다 나은 코드베이스를 만들기 위한 것임을 이해하고 적극적으로 참여할 것이다.

 

리뷰 대상이 아닌 것

 

개발자의 성향

리뷰가 주관적인 의견에 기반하더라도, 대부분의 사람들은 자신만의 좋고 나쁨에 대한 판단 기준과 논리가 있으며, 이를 바탕으로 리뷰를 작성한다. 그러나 때때로, 리뷰 대상이 좋고 나쁨을 판단할 수 없는 경우도 있다. 이때 내 스타일과 다르다고 해서 무작정 수정을 요청해서는 안된다.

// if/else 조건문
if (summer()) {
	charge = summerCharge();
} else {
	charge = regularCharge();
}

// 삼항연산자
charge = summer() ? summerCharge() : regularCharge();

위와 같은 조건문과 삼항 연산자의 사용이 대표적인 예시이다. 어떤 개발자는 if/else 조건문의 가독성이 더 좋다고 생각할 수 있고, 반면에 다른 개발자는 삼항 연산자의 가독성이 더 좋다고 생각할 수 있다. 이는 상당히 주관적인 부분이므로 개발자의 성향을 존중해야 한다.

 

그러나 코드베이스의 일관성이 중요하기 때문에, 이 경우에는 어떤 것을 컨벤션으로 정의할지 논의하는 안건을 제시하는 것은 바람직하다고 볼 수 있다.

 

 

좋은 리뷰를 위한 리뷰이의 역할

 

1. PR은 작은 단위로 자주 요청하자

리뷰어가 코드 리뷰를 위해 PR 페이지에 들어갔을 때, 파일 변경이 74개가 찍혀 있다면 무슨 생각을 할까? 코드 리뷰는 많은 장점을 가지고 있지만, 상당한 시간과 자원을 필요로 하는 작업이다. 이러한 이유로, 코드 리뷰를 지속적이고 경제성 있게 유지하기 위해서는 PR 단위를 작게 분할하는 것이 중요합니다.

 

사실, PR 단위를 작은 단위로 유지하려면 개발자 한 명의 노력뿐만 아니라 개발 문화 차원에서의 노력이 필요하다. 작은 반복주기와 피드백 루프, 트렁크 주도 개발, 신뢰성 있는 CI/CD 파이프라인 등 PR 단위를 작게 유지하기 위해 노력한다면 코드 리뷰의 질이 높아질 뿐만 아니라 변경에 더 유연하게 대처할 수 있다.

 

2. 리뷰어가 코드의 오류를 검사하게 하지 말자.

리뷰가 생산적으로 이루어지려면, 리뷰어는 코드의 품질과 지식 공유에 집중해야하며, 코드에 문제가 있는지 검사해서는 안된다. 따라서 코드의 오류는 컴파일러나 정적 분석기를 통해서 리뷰 이전에 수정되어야 한다. 예를들어 코딩 컨벤션은 리뷰를 요청하기 전 린트를 통해 사전에 검증하여 리뷰어가 코딩 컨벤션을 준수했는지 신경쓰지 않도록 해야한다.

 

이 부분은 자동화 가능한데, git hook을 사용하여 커밋 수준에서 검증하거나 PR 요청으로 올라온 코드에 대해 컴파일, 빌드, 정적 분석 등을 진행하는 검증 파이프라인을 만들어 적용할 수 있다.

 

3. PR 템플릿을 만들고 작성하자

코드만을 보고 그 의도와 내용을 파악하는 것이 이상적이지만, 현실적으로는 그것이 쉽지만은 않다. 또한 코드만으로 표현되지 않는 작업 중 문제와 그 해결 과정 등을 공유하고자 할 때도 있다. 이럴 때 PR 템플릿을 만들어 작성하면 리뷰어와 리뷰이 모두에게 좋다.

PR 템플릿을 통해 구체적으로 어떤 작업을 진행했는지, 작업을 진행하면서 만난어려움과 이를 해결하는 과정을 작성했다.

PR 템플릿을 잘 작성하면, 리뷰어의 리뷰 작업이 훨씬 수월해지고, 지식 공유도 더욱 활발하게 진행될 수 있다.

 

 

더 좋은 대안? 짝 프로그래밍(pair programming)

우리는 앞에서 코드 리뷰를 효율적으로 진행하는 방법에 대해 알아봤다. 그러나 코드 리뷰는 효율적으로 진행되어도 시간과 비용이 많이 소요되는 과정이다. 또한, 코드 리뷰는 작업의 병목의 원인이 되기도 하고, 개발이 완료된 후에 진행되므로 '더 좋은 설계 제안하기' 리뷰를 받을 경우 기존 작업을 제거하고 새로 작업해야하는 낭비가 발생할 수도 있다.

 

짝 프로그래밍은 코드 리뷰와 비슷한 효과를 가짐과 동시에 훨씬 경제적인 방법론입니다. 이는 개발 과정에서 진행되고, 코드 리뷰보다 훨씬 즉각적이고 반복적인 피드백 루프를 제공한다. 이를 통해 역동적이고 유연하게 작업을 진행할 수 있으며, 우수한 설계와 고품질의 코드를 생성하고 지식 공유를 더욱 효과적으로 할 수 있다는 장점이 있다.

 

필자가 생각하는 이상적인 개발 문화는 코드 리뷰에만 의존하지 않고, 적절한 수준에서 코드 리뷰와 짝 프로그래밍을 혼합하여 진행하는 것이 좋다고 생각한다. 코드 리뷰는 중요하지만, 조금 경직되고 정적인 면이 있다. 반면, 짝 프로그래밍은 동적이고 즉각적인 반응이 가능하며 경제적이므로, 코드 리뷰의 단점을 보완해줄 수 있기 때문이다.

 

좀 더 주관적인 생각을 말하자면, 애자일의 진정한 가치는 작은 반복 주기를 통한 피드백 루프에서 나온다. 짝 프로그래밍은 코드 리뷰보다 즉각적이고 반복적인 피드백 루프를 제공하므로, 좋은 설계와 코드 품질, 지식 공유에서도 더 큰 효과를 가져온다고 생각한다. 코드 리뷰가 짝 프로그래밍에 비해 장점이 있다면 문서화와 기록이 자동으로 이루어진다는 점이다.

 

따라서, 코드 리뷰도 좋지만, 개발자들이 짝 프로그래밍을 더 적극적으로 활용했으면 좋겠다는 생각을 한다. 내 주변 개발자들의 의견을 들어보면, 과거 우리나라의 경직된 조직 문화 때문인지 짝 프로그래밍에 대한 부담감을 가지고 꺼려하는 사람들이 많다. 분위기가 점점 나아지고 있긴 하지만, 좀 더 개방적인 마음으로 짝 프로그래밍을 받아들이면 전체적인 개발 문화에 큰 도움이 되지 않을까 생각한다.

 

 

마무리하며

이번 포스트에서는 프로젝트를 통해 얻은 경험을 바탕으로 실제 사례를 예로 들어 코드 리뷰에 대한 내 생각을 정리해봤다. 코드 리뷰는 이상적으로 보이지만, 생각보다 효과적으로 진행하는 것이 쉽지 않다. 나 또한 이에 대해 많이 고민했고, 그 고민한 내용을 이 포스트에 담았다.

 

개인적으로 코드 리뷰는 최선의 방법이 아니라 현실적인 방법이라고 생각한다. 따라서 가능하다면 짝 프로그래밍 같은 빠르고 많은 피드백을 제공하는 방법론을 적용하는 것이 좋다. 그러나 다른 방법론들은 도구나 환경상의 문제로 적용이 어렵다. 이럴 때 시간과 공간에서 자유롭고 다양한 도구를 제공하는 코드 리뷰가 현실적인 대안이 될 수 있다. 그러나 코드 리뷰는 여전히 느리고 정적이며, 낭비가 발생할 수 있으므로, 이를 고려하여 팀이 효율적으로 진행하려면 지속적으로 고민해야 한다.