코드 리뷰(Code Review),,?

What is code review? How to do it? Could i do it?

Posted Dec 14, 2024 Updated Jan 3, 2025

By Gumraze

22 min read

코드 리뷰(Code Review),,?

시작하면서,,

우아한 프리코스 과정에서 각 주차의 미션 종료 후, 참여자들 간의 코드 리뷰를 요청하는 글들이 올라왔다.

미션에 참여하면서 다른 참여자들은 어떻게 미션에 접근하였는지? 어떤 테스트를 하였는지? 코드는 어떤 구조를 하고 있는지? 등이 궁금했다.

그런데,, 초보 개발자인 나는,, 코드 리뷰를 해본적이 없다..

It’s me,,

참여자들의 코드를 읽어보았는데, 솔직히 잘 이해가 안갔다. 구체적으로는 어떤 것부터 보아야 하는지 잘 모르겠다는 생각이 들었다.

모든 Commit을 다 읽어야하나?
어떤 것을 중점적으로 읽어야 하는거지?

최종적으로, 코드리뷰를 어떻게 하는거지?

그레서 구글에 코드 리뷰 관련 자료들을 찾아보았고, 이 자료들을 모두 천천히 읽어보았다.

개인이 작성한 글 부터 Google, GitHub, Microsoft, 네이버, 카카오, 뱅크샐러드, 우아한형제들 등의 대기업의 자료들이 있었다.

많은 자료들을 읽고 공부하면서 자료들은 “코드 리뷰를 잘 하기 위해서는 리뷰하기 좋은 코드를 작성하는게 중요하다” 라고 나에게 말하는 것 같았다. 따라서, 오늘은 코드를 리뷰하는 방법 뿐만아니라 리뷰하기 좋은 코드를 작성하는 방법까지 공부한 내용을 기록하고, 공유해보고자 한다.

출처에 작성된 글들을 참고하여 작성하였으나, 저의 주관적 의견도 담겨 있으므로 유의하여 읽어주시면 감사하겠습니다.

리뷰어(Reviewer)? 리뷰이(Reviewee)?

먼저 코드리뷰 관련된 용어를 정리했다.

리뷰어(reviewer): 코드 리뷰를 하는 사람.
리뷰이(reviewee): 코드 리뷰를 받는 사람. 즉, 코드의 목적, 구성 등을 파악하고 있는 사람.
코드 스타일(Code Style): 코드 작성 시, 사용되는 일관된 형식 및 표현 방식.
코드 컨벤션(Code Convention): 코드의 구조와 작명 규칙, 설계 원칙 등 코드를 작성하는 과정에서 따라야 하는 규칙.

코드 리뷰(Code Review)란?

코드 리뷰 관련하여 작성된 글들에 있는 내용을 종합적으로 정리해보았는데, 대략 코드 리뷰의 관점을 3가지로 정리할 수 있었다.

개발자가 작성한 코드를 다른 개발자가 정해진 방법으로 피드백을 주고받는 과정.
좋은 개발자가 되기 위해, 더 좋은 소프트웨어를 개발하기 위한 서로의 노력과 소통의 과정.
코드와 제품 품질을 유지하고 향상시키기 위한 과정.

간단히 말해서, 코드 리뷰는 소통을 통하여 개발자, 코드, 제품 품질을 향상시키기 위한 과정이라고 해석할 수 있다.

코드 리뷰의 목적과 효과

그렇다면, 코드 리뷰를 함으로써 얻고자 하는 목적과 효과는?

개발자 스스로 발견하지 못한 오류 또는 부작용을 코드 리뷰를 통해 발견할 수 있음.
코드 리뷰를 통해 작성자가 생각하지 못한 새로운 문제 해결 방법론을 적용할 수 있음.
코드 스타일(code style) 및 컨벤션(convention)을 유지하여 팀 또는 그룹의 코드 스타일의 일관성을 유지할 수 있음.
코드 리뷰 과정 자체를 통해 코드의 가독성이 늘어날 수 있음.
코드 리뷰를 통해 전반적인 코드 상태가 시간이 지남에 따라 개선되고 있는지 확인함.

코드 리뷰를 하는 방법

일반적으로 모든 회사가 동일한 방법으로 코드 리뷰를 하지 않는다. 따라서 본 내용은 나와 같은 초보 개발자들이 코드 리뷰를 어떻게 해야하는지? 어떤 것을 주목해야 하는지?를 집중적으로 다루고자 한다.

코드 리뷰를 다루는 많은 글에서 동일하게 강조하는 것이 있다.

By Reviewer

1. 낮은 문맥 의존성(저맥락, low context)

낮은 문맥 의존성(이하 저맥락)은 문화적 의사소통 스타일을 설명할 때 사용하는 개념이다. 저맥락 문화에서는 사람들이 명확하고 구체적으로 정보를 전달하려는 특성을 가지고 있다. 이는 주로 미국, 독일 등의 국가에서 사용되는 방식이다.

그런데, 이것이 코드를 리뷰하는데 왜 중요한 것일까?

코드 리뷰 시, 추상적, 주관적 표현을 사용하는 것을 지양해야한다 .

  
def find_max(numbers):
    max_value = numbers[0]
    for num in numbers:
        if num > max_value:
            max_value = num
    return max_value

# 좋지 않은 리뷰
- 파이썬 내장 함수 max()를 사용하세요. 

# 좋은 리뷰(저맥락)
- 파이썬 내장 함수는 표준 라이브러리에 포함되어 있어 테스트와 최적화가 이미 완료되어 있는 안정적인 코드입니다.
- 파이썬은 유지보수성과 가독성을 위해 파이썬 내장 함수를 활용하는 것을 지향합니다.
- 최댓값을 찾기 위해 내장 함수 max()를 사용하는 것이 Pythonic한 코드 스타일을 따를 수 있습니다.

추상적, 주관적 표현을 사용하게 된다면, 개선의 이유를 파악하기 어려우며, 결국 추가적인 의사소통으로 인해 의사소통 비용이 증가할 수 있다.

2. 리뷰를 위한 리뷰를 하지마라.

코드 리뷰를 처음 시도하는 나와 같은 초보 개발자들이 생각하고 있어야 하는 부분이라고 생각한다. 특히, 초보 개발자들은 남의 코드를 보고 리뷰하는 것이 매우 어렵다. 그러다 보면, 종종 리뷰를 위한 리뷰를 하고 있는 자신을 찾을 수 있다. 따라서 크게 리뷰할 내용일 없으면 아래와 같이 칭찬 또는 피드백을 하자.

코드량이 적당해서 읽기 편합니다.
많은 고민이 코드에서 보입니다.
성능에 유리한 코드라고 생각됩니다.
기존 코드 보다 훨씬 좋아진 것 같습니다.
예외 처리가 꼼꼼해서 좋습니다.
변수, 함수 명이 직관적이어서 좋습니다.
코드가 잘 설계되어 있네요.
코드가 필요 이상으로 복잡하지 않아서 좋습니다.
코드에 적절한 단위 테스트가 잘 작성되어 있어 좋습니다.
주석들이 분명하고 유용하며, 왜(why) 보다 (what)에 집중하고 있습니다.
코드들이 도큐멘트를 통해 충분히 설명되고 있어 좋습니다.
코드 스타일 가이드를 충실히 따르고 있어 일관성을 잘 유지하고 있습니다.

3. 전체 코드의 맥락을 살피면서 리뷰해라.

일반적으로 GitHub 등에서 지원하는 코드 리뷰 도구에서 제시하는 순서대로 코드를 리뷰하는 것이 가장 간단한 방법이다. 그러나, 초보 개발자가 작성한 코드일수록 commit 단위를 따라가면서 코드를 리뷰하는 것이 어려울 수 있다. 그럴 때는 가장 주요한 파일을 먼저 검토하고 점차 작은 단위로 코드를 검토하는 것이 좋다. 또는, 종종 테스트 코드부터 읽는 것이 유용한 경우가 있다. 그 이유는 변경 사항이 어떤 기능을 수행하려고 하는지에 대한 아이디어를 얻을 수 있기 때문이다.

By Reviewee

위 내용들은 리뷰어로서 코드 리뷰를 하는 방법에 대해 설명하였다.

다음 이어질 리뷰어로서의 코드 리뷰 내용은 코드 리뷰를 다루는 많은 글들에서 “리뷰를 하는 방법” 또는 “코드 리뷰에서 확인해야하는 사항”으로 설명되어 있는 내용이다. 그러나 나는 아래 이어질 내용을 읽으면서, 리뷰이로서 코드를 더욱 잘 작성할 수 있는 방법을 가르쳐 주는 내용이라고 생각이 된다.

따라서, 위 “시작하면서,,,” 에서 “코드 리뷰를 잘 하기 위해서는 리뷰하기 좋은 코드를 작성하는게 중요하다” 라고 했던 것이다.

그러므로, 나는 이 내용을 리뷰이가 리뷰를 요청하기 전에 노력해야하는 부분으로 다루고자 한다.

상대방(리뷰어)의 입장에서 생각해보자는 취지이다.

1. 코드 스타일(code style) & 컨벤션(convention) 준수하기.

그룹 및 팀 내의 코드 스타일 및 컨벤션을 준수해야한다고 하는 것은 코드 리뷰 관련 글에서 대부분 강조하고 있는 내용이다.

Google: The Standard of Code Review에서는 코드 스타일은 절대적인 권위를 가진다고 표현했다.

코드 스타일은 코드의 일관성과 가독성을 위해 필수적으로 준수해야한다. 또한 이는 리뷰의 생산성 그리고 최종적으로 코드 개발의 생산성을 향상시킬 수 있다.

코드를 제출하기 전에 사용하고 있는 코드 편집기에서 지원하는 코드 스타일 자동화 툴이 있는지 확인하고.
이를 활용하는 것이 가장 좋은 방법이다.
인간은 실수를 한다…

2. 문서(Document) 잘 작성하기.

리뷰어가 리뷰를 하기 편하기 하기 위해, 어떤 작업을, 왜 하였고, 어떻게 구현하였는지 구체적으로 문서를 작성해야한다. 각 브랜치의 README, PR(Pull Request)를 보낼 때, 문서에 설명을 구체적, 저맥락으로 작성해야한다. 좋은 문서는 코드를 리뷰하는 시간을 줄여주고 이는 리뷰어가 높은 집중도로 리뷰를 할 수 있게 도와준다.

필요하다면, 코드 리뷰 규칙 문서을 추가하여 리뷰가 필요한 항목을 스스로 요청하자.

3. PR(Pull Request) 또는 Commit 단위를 가능한 작게 유지하라.

리뷰어 입장에서 보았을 때, 너무 큰 PR 또는 Commit을 리뷰하라고 하면 리뷰어는 어떤 생각을 하게 될까? 만약, 내가 그러한 요청을 받았다면 흔쾌히 리뷰를 하겠지만, 한편으로 큰 숙제를 받게 된다고 생각이 들 것이다. 또한, 너무 큰 단위의 변화는 리뷰의 집중도를 떨어뜨려 “리뷰를 위한 리뷰” 또는 리뷰의 목적과 효과를 달성하는데 어려움이 있을 수 있다.

따라서, 작은 기능 단위의 PR과 commit을 할 수 있도록 하여 리뷰의 병목을 줄일 수 있도록 해야한다.

그럼에도 불구하고, 변화가 단순하지 않거나 큰 경우에는 어떻게 해야할까?
그런 경우에는 문서를 잘 활용하여 코드의 구조를 구체적으로 설명하거나, 라벨을 통해 리뷰할 내용의 순서를 미리 정해주는 것이 좋다. 또한, 구글에서는 PR이 필요이상을 복잡한 경우는 과도한 엔지니어링으로 개발자가 필요 이상으로 코드를 일반화 한 것 또는 현재 시스템에 필요하지 않은 기능을 추가하지 않았는지를 의심해보아야 한다고 표현했다.

4. 테스트(Tests)

대부분의 리뷰어는 코드가 이미 충분한 검토와 테스트를 수행했기를 기대한다. 리뷰 이전, 단위 테스트(Unit test), 통합 테스트(Integration test) 그리고 종단 간 테스트(End-to-End test)를 수행하는 것을 권장하고 있다.

단위 테스트(Unit test): 개발자가 작성한 코드의 작은 단위를 빠르고 자주 검증하는 테스트.
통합 테스트(Integration test): 시스템 구성 요소 간 상호작용을 테스트.
종단 간 테스트(End-to-End test): 실제 사용자가 애플리케이션을 사용하는 시나리오를 테스트.

리뷰이로서 테스트를 잘 수행하기 위해, 테스트가 정확하고, 합리적 그리고 유용한지 확인해야한다. 아래 내용을 통해 확인할 필요가 있다.

테스트 코드가 잘못되었을 때, 실제로 실패하는지 확인해야함(실패하는 테스트 코드 작성).
코드가 변경되었을 때, 테스트가 잘못된 성공(False Positive)을 발생시키는지 확인해야함.
테스트들이 서로 다른 테스트 메서드로 적절히 분리되어 있는지 확인해야함.

우아한 테크코스에서는 경험에 의한 테스트 케이스를 작성하는 것을 권장하였는데,
이것 또한 좋은 테스트를 작성하기 위한 방법이다.

5. 주석(Comments)

코드는 논리적 구조를 가진 언어라고 나는 생각한다. 그렇다면, 논리적 구조를 가진 언어에 주석이 필요한 경우는 언제인가?

일반적으로 주석은 코드가 존재하는 이유에 대해 설명할 때 유용하며, 어떤 코드가 어떤 논리구조를 가지는지에 대한 설명은 필요하지 않다.

이 말인 즉, 우리는 코드의 가독성을 높이기 위해 변수, 함수 등의 명명을 명확히 해야할 필요가 있다. 그리고 논리구조가 명확하다면 추가적인 논리구조에 대한 설명은 필요하지않다. 만약, 코드가 스스로 설명하기에 충분히 명확하지 않다면, 코드를 더욱 단순하게 만들어야한다.

대부분의 주석은 코드 자체에 포함될 수 없는 정보를 설명해야 하는 경우에만 작성한다.

3줄 요약

코드를 리뷰하는 방법에 대해 알아보고자 했는데, 리뷰하기 좋은 코드를 작성하는 방법을 배우게 되었다.
코드 스타일, 컨벤션은 절대적인 권위를 가졌다.
역지사지의 마음으로 코드를 짜자.

출처

Bootcamp CodeReview Review Study

This post is licensed under CC BY 4.0 by the author.