무슨 이야기인가요
PR에 리뷰어가 붙으면 보통 그 한 사람이 처음부터 끝까지 다 봐요. 변수명도 보고, 로직도 보고, 테스트도 보고, 설계가 맞는지도 보죠. 그런데 이 방식이 생각보다 비효율적이라는 글이 나왔어요. 제목은 “One reviewer per layer”, 우리말로 하면 “층마다 리뷰어 한 명”이에요. 코드가 읽히는 방식에 따라 리뷰를 여러 층(layer)으로 나누고, 층마다 다른 리뷰어가 맡자는 아이디어예요.
요즘 이 고민이 특히 중요해진 이유가 있어요. AI 코딩 도구 덕분에 코드를 만드는 속도는 크게 빨라졌는데, 그 코드를 검토하는 사람의 시간은 그대로거든요. 리뷰가 팀 전체의 병목이 되기 쉬워서 “리뷰를 어떻게 더 똑똑하게 나눌까”가 많은 팀의 공통 고민이 됐어요.
‘코드가 읽히는 방식’으로 나눈다는 게 뭐예요?
코드는 사실 여러 높이에서 읽혀요. 건물에 비유하면 쉬운데요, 건축 심사를 할 때 구조 기술사, 전기 기사, 인테리어 담당이 각자 자기 분야만 보잖아요. 한 사람이 전부 보면 아무래도 덜 꼼꼼해지는 부분이 생기기 마련이고요.
코드에도 비슷한 층을 생각해 볼 수 있어요. 아래는 이 아이디어를 실무에 맞춰 제 식으로 풀어본 예시예요. 원문이 층을 정확히 어떻게 나누는지는 원문에서 확인해 보세요.
- 설계·경계 층: 이번 변경이 모듈 경계를 지키는지, 공개 API나 인터페이스가 바뀌는지, 데이터 모델이 적절한지를 봐요. 큰 그림을 아는 사람이 맡아요.
- 동작·로직 층: 비즈니스 로직이 맞는지, 엣지 케이스를 처리했는지, 동시성 문제는 없는지를 봐요. 해당 도메인을 잘 아는 사람이 맡아요.
- 표현·관례 층: 네이밍, 포맷, 언어 관용구, 팀 컨벤션을 봐요. 상당 부분은 린터나 AI 리뷰어에게 맡길 수 있어요.
단점도 있어요. 리뷰어가 늘어나면 승인을 기다리는 시간이 길어질 수 있어요. 또 여러 층에 걸친 문제는 아무도 책임지지 않는 사각지대가 되기 쉬워요. 예를 들어 설계 자체는 괜찮은데 그 설계 때문에 로직이 복잡해진 경우가 그래요.
업계에선 이미 비슷한 걸 하고 있어요
리뷰 책임을 나누는 것 자체는 새로운 얘기가 아니에요. 구글은 리뷰어의 정확성 승인(LGTM), 해당 디렉터리 소유자(OWNERS)의 승인, 언어별 가독성(readability) 승인을 따로 받는 문화로 잘 알려져 있어요. 한 사람이 세 가지를 모두 충족할 수도 있지만, 개념적으로는 이미 ‘관점별 리뷰’인 셈이죠. GitHub의 CODEOWNERS도 경로마다 리뷰어를 자동으로 지정한다는 점에서 비슷해요. 차이는 CODEOWNERS가 파일 위치를 기준으로 나눈다면, 이번 글은 읽는 관점을 기준으로 나눈다는 거예요. 같은 파일이라도 설계 관점과 로직 관점에서 서로 다른 사람이 볼 수 있다는 거죠.
최근 흐름과도 맞닿아 있어요. CodeRabbit, GitHub Copilot 코드 리뷰, Claude 같은 AI 리뷰어가 흔해지면서 많은 팀이 이미 “스타일과 뻔한 버그는 AI가, 설계 판단은 사람이” 하는 식으로 자연스럽게 층을 나누고 있거든요.
한국 개발자에게 주는 시사점
국내 팀들도 리뷰 문화를 다듬으려고 여러 시도를 해왔어요. 리뷰 코멘트에 P1~P5처럼 중요도를 붙이는 ‘Pn 룰’이 대표적이에요. Pn 룰이 코멘트의 무게를 나누는 방식이라면 이번 아이디어는 리뷰어의 역할을 나누는 방식이라서 둘을 같이 쓰기 좋아요.
당장 해볼 수 있는 건 이 정도예요.
1. PR 템플릿에 설계 변경 여부, 핵심 로직, 테스트 같은 체크 항목을 나눠 두고, 리뷰어가 자기가 맡은 층을 밝힌 뒤 승인하게 해보세요.
2. 스타일과 포맷은 린터와 AI 리뷰에 과감히 넘기고, 사람이 남기는 리뷰 코멘트에서는 빼는 규칙을 정해보세요.
3. 큰 PR이라면 코드를 짜기 전에 설계 리뷰부터 따로 받아보세요. 이미 다 짠 코드의 설계를 뒤집는 건 서로에게 괴롭거든요.
리뷰어를 여러 명 두기 어려운 작은 팀이라면 이렇게 응용할 수 있어요. 한 사람이 리뷰하더라도 층별로 나눠서 여러 번 훑는 거예요. 첫 번째엔 설계만, 두 번째엔 로직만 보는 식으로요.
마무리
한줄 정리: “누가 리뷰하나”보다 “무엇을 보는 리뷰인가”를 먼저 정하면 리뷰의 질과 속도를 함께 챙길 수 있어요.
여러분 팀은 코드 리뷰를 어떻게 나누고 있나요? 한 명이 다 보는 방식과 층별로 나누는 방식 중 어느 쪽이 더 현실적이라고 생각하세요?
🔗 출처: Hacker News