리뷰가 시비걸기 대회로 변질되는 순간
최근 들어 코드 리뷰를 진행할 때마다 이상하게 팀 내 긴장감이 흐르는 것 같습니다. 코드 리뷰가 본래는 편안하게 의견을 나누고 코드 품질을 개선하는 자리인데도, 종종 미묘한 긴장감 속에 서로의 코드에 날카로운 지적이 오가는 모습을 보곤 합니다. 어느새 코드 리뷰가 '천하제일 시비걸기 대회'가 된 것 같은 느낌을 지울 수가 없습니다.
누군가의 코드가 지적받는 순간, 자존심이 살짝 상하는 순간이 반복되면 사람들은 점점 방어적인 자세로 리뷰에 참여하게 됩니다. 그리고 리뷰를 받는 사람은 자신도 모르게 더 공격적이거나 방어적인 태도를 보이면서, 결국 코드 리뷰가 서로를 평가하고 비판하는 자리로 변질되고 맙니다.
저 역시 종종 코드 리뷰를 하다 보면 자신도 모르게 감정이 앞설 때가 있습니다. 코드는 객관적인 결과물 같지만, 사실은 자신이 가진 업무 능력과 판단력을 그대로 드러내는 산물이기 때문에, 리뷰 과정에서 조금이라도 부정적인 피드백을 받으면 무의식적으로 방어적인 태도가 나올 수밖에 없습니다.
코드 작성 철학과 불필요한 방어 코드의 문제점
저는 개인적으로 코드를 작성할 때 한 가지 철학을 가지고 있습니다. 코드를 최대한 간결하고 명확하게 만들어서, 코드만 봐도 전체 흐름과 맥락을 쉽게 파악할 수 있도록 하는 것입니다. 이렇게 하면 굳이 불필요한 if-else 조건문과 같은 방어 코드를 추가하지 않아도 됩니다.
그런데 최근 코드 리뷰 과정에서 이런 코멘트를 본 적이 있습니다.
"혹시라도 나중에 다른 사람이 잘못 사용할 가능성이 있으니 미리 if-else 방어 처리를 했습니다."
겉으로 보면 타당한 이야기 같지만, 제 입장에서 이 말은 다르게 해석됩니다. 이 말은 사실상 "이 코드가 정확히 어떤 맥락과 흐름에서 쓰이는지 충분히 파악하지 못한 상태에서 작업했다"는 뜻으로 느껴지기 때문입니다. 이 코드를 호출하는 곳에서 Nullable하게 데이터를 주입해주는지 파악을 하지 않았다는 겁니다.
코드의 흐름과 맥락을 정확히 파악하면 불필요한 방어 코드가 줄어듭니다. 과도한 방어 처리는 결국 작성자가 코드를 명확하게 이해하지 못했거나, 나중에 다른 사람이 오해할 가능성을 염려한 나머지 지나치게 방어적인 자세로 코드를 작성했다는 신호입니다. 이러한 방어 코드들은 장기적으로 코드의 가독성과 유지보수성을 떨어뜨리는 원인이 됩니다.
// 간단한 CHECK 매크로 정의 예시
#include <iostream>
#include <cstdlib>
#define CHECK(cond) \
do { \
if (!(cond)) { \
std::cerr \
<< "Check failed (" #cond ") in " << __FILE__ \
<< ":" << __LINE__ << "\n"; \
std::abort(); \
} \
} while (0)
void processData(const Data* data) {
// 런타임에도 동작시키고 싶다면 assert 대신 이 매크로를 사용
CHECK(data != nullptr);
CHECK(!data->items.empty());
// 핵심 로직
for (auto& item : data->items) {
// …
}
}
코드 리뷰에서 발생하는 감정적 충돌의 원인
또 다른 문제는 코드 리뷰 과정에서 종종 기본적인 컴퓨터 과학 지식이나 프로그래밍 언어 문법과 같은 문제를 반복적으로 지적받는 경우입니다. 이런 상황이 반복되면 리뷰어는 허탈감을 느끼게 되고, 리뷰를 받는 사람은 점점 스트레스를 받으며 방어적인 태도로 리뷰를 받아들이게 됩니다.
이런 스트레스가 쌓이다 보면, 리뷰를 받는 사람은 자신도 모르게 방어를 넘어서 다른 팀원의 코드에 공격적으로 리뷰를 하거나 날카로운 지적을 하게 됩니다. 이로 인해 리뷰의 본래 목적인 코드 품질 향상보다는 개인적인 감정싸움으로 이어지게 되는 것입니다.
이런 악순환의 가장 근본적인 원인은 간단합니다. 바로 내가 모르는 사실을 인정하는 게 자존심의 문제로 연결되기 때문입니다. 코드 리뷰는 본래 모르는 것을 서로 인정하고 배우는 자리인데, ‘내가 모른다’는 사실을 받아들이기 어려워하는 순간부터 감정적인 갈등이 시작됩니다.
친절한 리뷰와 불친절한 리뷰의 차이점
예전에 업무 다면 평가에서 "설명이 불친절하다"는 평가 문구를 접한 적 있습니다. 제가 바라보는 당사자의 태도와는 매우 달랐기 때문에 당시에는 그 평가의 의미를 전혀 이해하지 못했지만, 시간이 지나고 돌이켜 보니 당연하다고 생각했던 내용을 상대방에게 충분히 설명하지 않아서 불만이었다는 것을 깨달았습니다.
코드 리뷰에서도 같은 상황이 벌어지곤 합니다. 리뷰어는 종종 자신에게 너무나도 당연한 내용을 생략하거나, 상대방도 이미 알고 있을 거라고 생각하고 충분한 설명을 하지 않는 경우가 있습니다. 리뷰를 받는 사람은 이로 인해 자신이 무시당하고 있다고 느끼거나, 리뷰 자체를 공격적으로 받아들일 수 있습니다.
좋은 리뷰는 상대가 모르는 것을 당연하게 여기고, 차근차근 친절하게 설명하는 리뷰라고 생각합니다. 좋은 리뷰는 상대방이 모르는 것을 편안하게 질문할 수 있게 만드는 리뷰입니다. 리뷰의 품질은 얼마나 기술적으로 뛰어난 지적을 했느냐가 아니라, 상대방과의 소통을 얼마나 편안하게 이끌어갔느냐에 따라 달라집니다.
좋은 코드 리뷰 문화를 위한 제안
결국 코드 리뷰는 사람과 사람 사이의 일입니다. 좋은 코드 리뷰 문화를 만들기 위해서는 리뷰 과정에서 서로를 존중하고, 상대가 모르는 내용을 자연스럽게 인정하고 설명할 수 있는 분위기가 필요합니다.
리뷰를 하는 사람은 상대방이 모르는 것을 충분히 친절하게 설명해줘야 합니다. 동시에 리뷰를 받는 사람 역시 모르는 내용을 부끄럽게 여기지 않고 자연스럽게 질문할 수 있는 분위기가 만들어져야 합니다.
이제 코드 리뷰가 더 이상 서로를 평가하거나 비판하는 ‘천하제일 시비걸기 대회’가 아니라, 서로 모르는 부분을 인정하고 편안하게 배우고 성장하는 ‘천하제일 성장하기 대회’가 되었으면 합니다.
앞으로 리뷰를 할 때 다음과 같은 질문을 자연스럽게 던질 수 있는 분위기가 만들어지면 좋겠습니다.
"이 부분이 정확히 이해가 가지 않는데, 조금만 더 설명해 주실 수 있을까요?"
"저는 이렇게 생각했는데 혹시 더 좋은 방법이 있다면 알려주시면 좋겠습니다."
이런 간단한 질문과 제안이 자연스럽게 오가는 리뷰 문화를 만든다면, 코드 리뷰는 다시 본래의 의미로 돌아가 팀 전체의 성장과 소통에 큰 도움이 될 것입니다.
최근 코드 리뷰의 긴장감을 완화하고 서로 편안하게 피드백을 주고받기 위해 '셀프 리뷰 코멘트' 방식을 시범적으로 도입해보고 있습니다. PR을 올릴 때 미리 제가 고민한 부분, 혹은 아직 확신하지 못한 부분을 먼저 코멘트로 달아놓는 것이죠. 이렇게 하면 리뷰어도 더 편하게 질문할 수 있고, 리뷰 과정이 평가가 아니라 서로 돕는 소통의 자리라는 분위기가 만들어질 것으로 기대하고 있습니다.
