코드 리뷰 마스터하기: 리뷰어와 작성자를 위한 가이드

주니어 개발자에게 무슨 일을 하냐고 물으면 "코드를 짭니다"라고 대답할 겁니다. 시니어 개발자에게 물으면 "문제를 해결합니다"라고 하겠죠. 하지만 스태프 엔지니어에게 묻는다면, 아마 "코드를 읽고 리뷰합니다"라고 대답할지도 모릅니다.

경력이 쌓일수록 코드를 작성하는 시간보다 읽는 시간이 더 많아집니다. 코드 리뷰는 코드 품질을 유지하고, 지식을 공유하며, 팀원을 멘토링하는 가장 중요한 메커니즘입니다.

하지만 코드 리뷰는 종종 불안의 원천이기도 합니다. 작성자는 비판을 두려워하고, 리뷰어는 갈등을 두려워하죠. 이 글에서는 코드 리뷰를 고통스러운 잡무에서 팀을 위한 슈퍼파워로 바꾸는 방법을 알아봅니다.

철학: 당신을 비난하는 게 아닙니다

코드 리뷰의 제1원칙은 이것입니다: 우리는 사람이 아니라 코드를 비평하는 것입니다.

나쁨: "너 때문에 빌드가 깨졌어."
좋음: "이 변경 사항 때문에 빌드 오류가 발생하는 것 같아요."

미묘한 말장난처럼 들릴 수 있지만, 이 차이가 대화의 분위기를 '비난'에서 '협업'으로 바꿉니다.

작성자를 위하여: 예술적인 PR 만들기

훌륭한 코드 리뷰는 PR을 열기 전에 시작됩니다. 여러분의 목표는 리뷰어의 일을 최대한 쉽게 만드는 것입니다.

1. 문맥이 왕이다 (Context is King)

절대로 빈 설명으로 PR을 열지 마세요. 최소한 다음 내용은 포함해야 합니다:

What: 이 변경 사항은 무엇을 하나요?
Why: 왜 필요한가요? (티켓/이슈 링크)
How: 어떻게 테스트했나요? (스크린샷, 영상, 또는 CLI 출력)

2. 골디락스 사이즈

Cisco Systems의 연구에 따르면, 한 번에 200~400줄 이상의 코드를 리뷰할 때 결함 발견율이 급격히 떨어진다고 합니다.

너무 작음: 오타 수정 (급한 게 아니라면).
너무 큼: "인증 시스템 전체 리팩토링" (2,000줄).
딱 좋음: 하나의 논리적 작업 단위 (예: "사용자 로그인 엔드포인트 추가").

PR이 너무 크다면, **스택(Stack)**하세요. 의존성이 있는 더 작은 PR들로 쪼개는 겁니다.

3. 셀프 리뷰 (Self-Review)

리뷰어를 지정하기 전에, 자신의 diff를 먼저 읽어보세요. console.log나 주석 처리된 코드 같은 사소한 실수를 스스로 얼마나 많이 발견하는지 놀라게 될 겁니다. 깨끗한 diff는 리뷰어의 시간에 대한 존중을 보여줍니다.

리뷰어를 위하여: 무엇을 봐야 할까

리뷰를 시작할 때, 단순히 빠진 세미콜론만 찾지 마세요. 레이어(Layer)별로 생각해야 합니다.

레이어 1: 아키텍처와 설계 (큰 그림)

이 변경 사항이 여기에 위치하는 게 맞나요?
확장 가능한가요?
기술 부채를 만들지는 않나요?
행동: 설계가 잘못되었다면, 세부 사항 리뷰를 멈추세요. 접근 방식부터 먼저 논의해야 합니다.

레이어 2: 기능과 버그

실제로 작동하나요?
엣지 케이스는 처리되었나요? (Null 체크, 빈 리스트, 에러 상태)
보안 취약점은 없나요? (SQL 인젝션, XSS)

레이어 3: 가독성과 유지보수성

변수명은 직관적인가요? (x vs userIndex)
로직이 너무 복잡하지 않나요? (중첩 루프, 거대한 함수)
6개월 뒤의 개발자가 이 코드를 이해할 수 있을까요?

레이어 4: 스타일과 닛픽 (자동화의 영역)

들여쓰기, 공백, 괄호.
프로 팁: 이건 Prettier나 ESLint에게 맡기세요. 사람이 쉼표 가지고 논쟁하느라 시간을 낭비해선 안 됩니다.

"닛픽(Nitpick)"의 함정

우리 모두 겪어봤을 겁니다. 복잡한 알고리즘을 구현해서 올렸는데, 리뷰어가 이런 코멘트를 남기죠: "파일 끝에 개행 문자 추가해주세요."

스타일도 중요하지만, 오직 사소한 것(Nits)에만 집중하는 건 사기를 꺾습니다. 자전거 보관소 논쟁(Bike-shedding)처럼 느껴지죠.

경험칙:
순수하게 주관적이거나 사소한 취향 차이라면, "Nit" 또는 **"Non-blocking"**이라고 명시하세요.

"Nit: 저는 여기서 const를 선호하지만, 무시하셔도 됩니다."

이는 작성자에게 이런 신호를 줍니다: "당신의 로직은 승인합니다. 이건 단지 더 좋게 만들기 위한 제안일 뿐이에요."

의견 차이 다루기

의견 차이는 건강한 것입니다. 사람들이 신경 쓰고 있다는 뜻이니까요. 하지만 잘못 다루면 독이 될 수 있습니다.

명령하지 말고 질문하세요:
- "이거 유틸리티 함수로 옮겨." (X)
- "재사용성을 높이기 위해 이걸 유틸리티 함수로 옮기는 건 어떨까요?" (O)
화상 통화를 하세요:
- 댓글이 3번 이상 오고 간다면, 타이핑을 멈추세요. 화상 통화를 하거나 자리로 찾아가세요. 텍스트는 뉘앙스를 전달하기에 최악의 매체입니다.
Disagree and Commit:
- 때로는 정답이 없을 수도 있습니다. 작성자에게 타당한 이유가 있고 치명적인 문제가 아니라면, 그들의 방식을 존중하세요. 100% 맞는 것보다 신뢰가 더 중요합니다.

결론

코드 리뷰는 코딩과 마찬가지로 하나의 기술(Skill)입니다. 공감, 명확성, 그리고 인내심이 필요하죠.

작성자: 문맥이 풍부한 PR을 작성하고 리뷰어의 시간을 존중하세요.
리뷰어: 아키텍처 문제를 먼저 보고, 친절하게 대하며, "꼭 고쳐야 할 것"과 "좋으면 좋은 것"을 구분하세요.

제대로 된 코드 리뷰는 더 나은 코드를 만들 뿐만 아니라, 더 나은 엔지니어를 만듭니다.