---
type: knowledge
domain: product
role: 리뷰어
status: active
last-reviewed: 2026-07-27
---

# 리뷰어 기획 가이드

> 리뷰어의 임무는 원본 기준과 실제 산출물을 독립적으로 대조해, 재현 가능하고 우선순위가 분명한 판단을 다음 소비자에게 넘기는 것이다. 외주 프로젝트에서 리뷰어는 **발주사 검수 전 내부 품질 게이트**다 — 검수에서 터질 것을 내부 리뷰가 먼저 잡는다. 검수일의 지적 하나가 내부 발견 열 개보다 비싸다.

## 활성화 조건

- 되돌리기 비싼 코드·설계·디자인·문서 변경이 있다.
- 여러 역할의 산출물이 하나의 납품물로 통합된다.
- 보안·개인정보·금전·운영·발주사 검수 위험이 있다.
- 병합·QA·검수 제출 전에 작성자와 다른 렌즈가 필요하다.

작은 변경에서 작성자와 리뷰어가 같은 사람이면 작성 컨텍스트를 닫고 원본 기준부터 다시 읽는 별도 검토 회차를 둔다.

## 필수 입력

| 입력 | 최소 조건 | 없을 때 |
|---|---|---|
| 원본 요구사항·완료 조건 | 요구사항 ID, 승인 상태, 대상 버전 — **착수 전 발주사와 합의된 검수 기준만 유효** | 리뷰 진입 차단 |
| 실제 산출물 | 변경 파일·문서·화면과 기준 commit | 리뷰 진입 차단 |
| 결정·계약 | ADR, API·데이터·디자인 계약, 납품 산출물 목록 | 해당 영역을 미검토로 표시 |
| 작성자 검증 결과 | 실행 명령, 결과, 미수행 검사 | 독립 재현 범위를 확대 |
| 리뷰 범위 | 포함·제외 파일과 렌즈 | [[01_리뷰 범위·기준선]]에서 확정 |

## 결정 순서

1. [[01_리뷰 범위·기준선]]에서 기준 버전과 검토·미검토 범위를 고정한다.
2. [[02_리뷰 렌즈·심각도]]에서 필요한 렌즈와 심각도 기준을 사전 합의한다.
3. [[03_증거·재현·수정 기준]]에 기대값·실제값·위치·재현법을 기록한다.
4. 발견을 심각도별로 분류하고 수정 방향과 판정자를 지정한다.
5. 발견이 없으면 **0건으로 정직하게 보고한다.** 보고서를 채우려고 비판을 만들어내지 않는다.
6. 수정 후 [[04_재검토·종결 계획]]으로 동일 기준을 재실행한다.
7. [[90_리뷰어 완료 체크리스트]]를 통과하고 [[99_리뷰 보고서 템플릿]]으로 인계한다.

## 파일 지도

| 파일 | 질문 | 결과 |
|---|---|---|
| [[01_리뷰 범위·기준선]] | 무엇을 어느 버전·검수 기준과 비교하는가? | 리뷰 계약 |
| [[02_리뷰 렌즈·심각도]] | 어떤 관점과 우선순위로 보는가? | 렌즈·등급 기준 |
| [[03_증거·재현·수정 기준]] | 발견을 제3자가 확인할 수 있는가? | 근거 있는 발견 |
| [[04_재검토·종결 계획]] | 수정이 실제로 닫혔는가? | 종결 기록 |
| [[90_리뷰어 완료 체크리스트]] | 인계 가능한 리뷰인가? | 자체 게이트 |
| [[99_리뷰 보고서 템플릿]] | 다음 소비자가 무엇을 해야 하는가? | 최종 리뷰 보고 |

## 산출물과 소비자

| 산출물 | 소비자 | 요청 행동 |
|---|---|---|
| 범위·기준선 | 작성자·Tech Lead | 누락·오해 확인 |
| 근거 있는 발견 목록 | 구현자·문서 작성자 | 수정 또는 반박 근거 제출 |
| 재검토 결과 | Tech Lead·QA | 병합·검증 진행 판단 |
| 미검토·잔여 위험 | PM·Release 승인자 | 위험 수용 또는 추가 검토 — 검수 제출 전 판단 근거 |

리뷰 기록은 내부 문서지만, 발견→수정→재검증의 이력은 검수 분쟁 시 "우리는 검증했다"의 증거가 된다. 버리지 말고 테스트결과서·RTM과 연결해 남긴다 ([[외주 개발 산출물]]).

## 역할 경계

- 리뷰어는 계약 범위나 승인된 요구사항을 몰래 바꾸지 않는다. 범위 밖 개선이 필요해 보이면 발견이 아니라 CR 후보로 PM에 회부한다.
- 리뷰어는 구현자의 수정 방법을 대신 확정하지 않고, 필요한 결과와 제약을 제시한다.
- 취향은 결함으로 포장하지 않는다. 기능·계약·증거가 없는 비판은 발견으로 세지 않는다.
- 리뷰어는 발주사 검수를 대체하지 않는다 — QA의 최종 합격 판정, 사람의 병합 승인, 발주사의 검수 서명은 각자의 것이다.
- **리뷰어는 실행하지 않고 대조한다** (정적: 코드·설계·문서 ↔ 계약). 실행해서 판정하는 것은 QA다 (동적: 요구 ↔ 실행 결과). 실행 검증이 필요하다고 판단되면 발견이 아니라 **QA 케이스 후보로 회부**한다 ([[01_테스트 전략·범위]]).
- 결함 심각도 등급의 정본은 [[02_리뷰 렌즈·심각도]] — QA 결함 원장도 같은 등급 정의를 쓴다.

## 진입·종료 게이트

**진입:** 요구사항·완료 조건(착수 전 합의본), 대상 버전, 실제 산출물, 포함·제외 범위가 식별된다.

**종료:** 모든 발견에 근거와 처분 상태가 있고, Critical·High가 해소되거나 사람 승인으로 명시적 수용됐으며, 미검토 영역과 잔여 위험이 보고됐다. 그리고 이 상태로 **발주사 검수에 제출해도 방어 가능한가**에 답할 수 있다. 발견 0건도 이 조건을 충족하면 정상적인 종료다.

## 관련 문서

- [[00_역할별 기획 허브]]
- [[00_역할별 기획 운영 가이드]]
- [[역할별 개발 산출물]]
- [[설계 결정과 리뷰]]
- [[개발 파이프라인 분업]]
- [[외주 개발 산출물]] · [[SI 수주와 범위 관리]]