코드 리뷰에서 진짜 봐야 할 것 — 스타일 지적을 넘어 설계를 읽는 기술

주니어 시절, 코드 리뷰가 두려웠다. 변수명 하나, 줄바꿈 하나에 코멘트가 달리면 마치 내 능력이 부정당하는 기분이 들었다. 하지만 시니어가 되어 리뷰를 하는 입장이 되고 나서야 깨달았다. 스타일에 대한 지적은 리뷰의 가장 낮은 단계라는 것을.

좋은 코드 리뷰는 린터가 할 수 없는 것을 한다. 설계 의도를 파악하고, 숨겨진 가정을 드러내고, 미래의 문제를 예측하는 것이다.

코드 리뷰의 4가지 계층

코드 리뷰에서 확인해야 할 것들은 계층 구조를 이룬다. 가장 낮은 단계부터 순서대로 말하면, 스타일과 포매팅, 버그와 논리 오류, 설계와 아키텍처, 그리고 비즈니스 요구사항과의 정합성이다.

# 예시: 이 PR에서 진짜 봐야 할 것은?
def process_order(order):
    if order.status == "pending":
        # 결제 처리
        payment = charge_payment(order.total)
        if payment.success:
            order.status = "completed"
            send_email(order.user, "주문 완료")
            update_inventory(order.items)
            save_order(order)
        else:
            order.status = "failed"
            save_order(order)
    return order

스타일 수준의 리뷰라면 변수명이나 함수 길이를 지적할 것이다. 하지만 설계 수준의 리뷰는 다른 질문을 던진다. "send_email이 실패하면 어떻게 되는가?", "update_inventory와 save_order 사이에서 에러가 나면 데이터 정합성은?", "이 함수가 결제, 이메일, 재고, 저장까지 전부 담당해도 되는가?"

좋은 리뷰어가 던지는 질문들

질문 1: "이 변경의 영향 범위는 어디까지인가?" 코드 변경이 해당 파일에만 영향을 주는지, 아니면 다른 모듈이나 서비스에 파급효과가 있는지 파악해야 한다.

질문 2: "실패하면 어떻게 되는가?" 정상 경로만 테스트되었는지, 에러 처리가 충분한지, 부분 실패 시 롤백 전략이 있는지 확인해야 한다.

질문 3: "이 코드를 6개월 후에 이해할 수 있는가?" 암묵적인 가정이나 매직 넘버, 설명 없는 분기 로직이 있다면 미래의 유지보수를 어렵게 만든다.

질문 4: "더 간단한 방법은 없었는가?" 복잡한 솔루션이 항상 나쁜 것은 아니지만, 복잡성을 정당화할 수 있는 이유가 있어야 한다.

리뷰를 받는 사람의 자세

리뷰는 코드에 대한 피드백이지, 개인에 대한 평가가 아니다. 방어적으로 반응하기보다는 리뷰어의 관점을 이해하려고 노력해야 한다. "왜 이렇게 했는지"를 설명할 수 있다면, 그 자체가 설계 의사결정의 기록이 된다. 의견이 다르면 건설적으로 토론하되, 최종 결정은 팀의 합의를 따르면 된다.

코드 리뷰는 코드 품질이 아니라 팀 역량의 문제다

좋은 코드 리뷰 문화를 가진 팀은 코드 품질뿐 아니라 팀웠들의 성장 속도도 빠르다. 리뷰를 통해 다른 사람의 사고 과정을 배우고, 자신의 맹점을 발견하기 때문이다. 린터와 포매터로 스타일을 자동화하고, 리뷰에서는 설계와 의사결정에 집중하자. 그것이 코드 리뷰의 진짜 가치다.

---

함께 읽으면 좋은 글

• Next.js에서 use client를 남발하고 있었다
• else를 쓰지 않기로 했다 - 조건문을 줄이면 코드가 살아난다
• 코스닥150 ETF vs S&P500