결함을 일찍 잡음
운영에서 터지기 전에 리뷰에서 잡는 것이 가장 쌉니다. 다만 리뷰가 모든 버그를 잡는다는 기대는 비현실적입니다. 테스트와 역할을 나눕니다.
이 파트에서 다루는 내용
리뷰의 목적무엇을 볼까어떻게 말할까언제 승인할까
01
리뷰는 결함을 잡는 동시에 지식을 나누는 일입니다
코드리뷰의 목적을 잘못 잡으면 방향이 어긋납니다. 흠을 찾아내는 검문소로 여기면 서로 피곤해지고, 형식적으로 승인만 누르면 리뷰가 무의미해집니다.
리뷰는 두 가지를 동시에 합니다. 문제를 병합 전에 잡는 것, 그리고 코드베이스에 대한 이해를 팀에 퍼뜨리는 것입니다. 두 번째가 특히 중요합니다. 리뷰를 통해 신입은 배우고, 팀은 특정 코드를 한 사람만 아는 상태를 피합니다.
지식을 나눔
리뷰하면서 그 코드가 무엇을 하는지 알게 됩니다. 나만 아는 코드, 남만 아는 코드를 줄여 팀의 버스 팩터를 높입니다.
표준을 맞춤
리뷰를 거치며 팀의 관례가 자연스럽게 공유됩니다. 다만 취향 차원의 지적은 도구(포매터·린트)에 맡기고 사람은 판단이 필요한 곳에 집중합니다.
02
무엇을 지적하고 무엇을 넘길지 우선순위가 있습니다
모든 것을 같은 무게로 지적하면 정작 중요한 문제가 사소한 것에 묻힙니다. 리뷰에는 우선순위가 있습니다.
반드시 막을 것
- 동작 오류와 논리 결함
- 보안 문제, 비밀정보 노출
- 데이터 손상 가능성
- 요청 범위를 벗어난 위험한 변경
짚어야 할 것
- 예외·경계값 처리 누락
- 이해하기 어려운 구조
- 기존 관례와 어긋난 부분
- 테스트가 없는 핵심 로직
취향은 넘기거나 도구로
- 들여쓰기, 따옴표 같은 포맷 (포매터가 처리)
- 동등하게 타당한 이름·구조 선호
- 이번 범위와 무관한 개선점
제안과 필수를 구분
막아야 할 것과 그냥 제안을 명확히 구분해 표시합니다. 사소한 제안이라면 반영하지 않아도 승인한다는 뜻을 함께 밝힙니다.
판단 기준
이 지적이 막히면 운영에 문제가 생기는가를 물으면 우선순위가 정해집니다. 그렇다면 반드시 막고, 아니라면 제안으로 남깁니다. 취향 차원의 지적으로 리뷰를 오래 끄는 것은 팀 속도를 떨어뜨립니다.
03
코드를 지적하되 사람을 탓하지 않습니다
같은 지적도 표현에 따라 배움이 되기도 하고 방어를 부르기도 합니다. 리뷰이가 위축되면 질문을 안 하게 되고, 결국 리뷰의 지식 공유 기능이 죽습니다.
핵심은 사람이 아니라 코드를 두고 이야기하는 것입니다. Part 3에서 리뷰받는 쪽의 태도를 다뤘다면, 여기서는 리뷰하는 쪽의 표현을 다룹니다.
이유를 함께
이렇게 바꾸라가 아니라 왜 그게 나은지를 함께 적습니다. 리뷰이가 배우고, 다음부터 스스로 적용합니다. 근거 없는 지적은 취향 강요로 들립니다.
좋은 점도 언급
잘한 부분을 짚어 주면 무엇이 좋은 코드인지 기준이 공유됩니다. 리뷰가 지적만 있는 자리가 아니게 됩니다.
말로 푸는 게 빠를 때
논쟁이 길어지거나 설계 방향이 얽히면, 글로 주고받기보다 잠깐 대화하는 편이 빠릅니다. 결론은 다시 PR에 남겨 기록합니다.
표현을 바꾸면 전달이 달라집니다text
# 사람을 탓하는 표현
"왜 여기서 예외 처리를 안 했어요?"
"이렇게 짜면 안 되죠."
# 코드를 두고 이야기하는 표현
"이 경로에서 값이 null이면 예외가 날 것 같은데,
확인 부탁드려요."
"여기는 A 방식이 기존 관례와 맞는 것 같아요.
특별한 이유가 있었을까요?"
# 제안임을 명확히
"(제안) 이 부분을 메서드로 빼면 읽기 쉬울 것 같아요.
지금 반영 안 해도 승인입니다."질문형으로 쓰면 리뷰이가 맥락을 설명할 여지가 생깁니다. 내가 놓친 이유가 있을 수 있다는 태도가 리뷰를 대화로 만듭니다.
04
언제 승인할지 기준을 정합니다
완벽한 코드를 기다리면 아무것도 병합되지 않습니다. 반대로 대충 승인하면 리뷰가 의미를 잃습니다. 그 사이의 기준이 필요합니다.
승인해도 되는 때
반드시 막을 문제가 없고, 남은 것이 제안 수준이라면 승인합니다. 사소한 제안까지 다 반영될 때까지 붙들지 않습니다. 완벽이 아니라 지금보다 나은지를 봅니다.
막아야 하는 때
동작 오류, 보안 문제, 데이터 위험이 있으면 막습니다. 이해가 안 되는 코드도 막습니다. 리뷰어가 이해 못 한 코드는 팀이 유지보수할 수 없습니다.
빨리 보는 것도 리뷰
리뷰를 며칠 방치하면 리뷰이의 작업이 막히고 충돌이 쌓입니다. 완벽한 리뷰보다 빠른 리뷰가 팀 전체로는 이득인 경우가 많습니다. Part 3의 작은 PR과 이어집니다.
리뷰 규모의 한계
한 번에 수백 줄을 넘으면 사람은 집중력을 잃고 놓칩니다. 큰 PR은 제대로 리뷰가 안 된다는 점을 리뷰어도 인지하고, 작게 나눠 달라고 요청합니다.
정리
리뷰는 결함을 잡고 지식을 나누는 일입니다. 우선순위를 두어 중요한 것에 집중하고, 코드를 두고 이야기하며, 완벽이 아니라 지금보다 나은지로 승인합니다. 잘 리뷰하는 사람은 팀의 코드 품질과 성장 속도를 동시에 끌어올립니다.
체크