티켓에 대한 풀 리퀘스트 리뷰하기
풀 리퀘스트가 준비되기 전 마지막 관문입니다. 이는 하나의 질문 — 이 diff가 아키텍처 내에서 티켓을 제대로 구현했는가? — 에 답하며, 리뷰어의 개인적 취향보다 우선하는 두 가지 소스, 즉 수용 기준과 참조 아키텍처를 기준으로 답변합니다.
이 리뷰는 읽고 보고합니다. 수정하지 않습니다: 발견한 내용을 수정하는 리뷰는 무엇이 잘못되었는지에 대한 증거를 파괴하며, 아무도 패턴을 배우지 못합니다.
TICKET-ANALYSIS.md와 IMPLEMENTATION-PHASE.md 다음의 마지막 세 번째 단계입니다. WORKFLOW.md는 이들이 어떻게 함께 작동하는지와 설치 방법을 설명합니다.
목차
1. 리뷰할 diff 확인
브랜치를 저장소의 실제 기본 브랜치와 비교하여 diff를 확인하세요. 어떤 브랜치인지 추측하지 마세요. 변경된 모든 파일을 리뷰하세요; 지루해 보여서 건너뛴 파일에 설정 변경이 숨어 있을 수 있습니다.
diff가 티켓에서 언급되지 않은 부분을 무엇을 건드리는지 기록하세요. 그 목록은 §2와 §5의 입력값이며, 아직 발견 사항은 아닙니다.
2. 수용 기준 우선
수용 기준을 하나씩 가져와 각각에 대해 그것을 충족하는 코드와 그것을 증명하는 테스트를 명명하세요. 둘 다 있어야 충족된 것입니다.
- 코드만 있고 테스트가 없는 기준은 입증되지 않았습니다.
- 테스트만 있고 코드가 없는 기준은 프레임워크를 단언하는 테스트입니다.
- 전혀 찾을 수 없는 기준이 가장 중요한 발견 사항이며, 리뷰의 모든 스타일 관찰보다 우선합니다.
그런 다음 반대 방향으로: 뒤에 기준이 없는 변경 사항. 일부는 정당합니다 — 변경 중인 코드 내부의 수정(IMPLEMENTATION-PHASE.md §2). 나머지는 범위 확장이며, 출시 후 설명하는 것보다 여기서 명명하는 것이 비용이 적게 듭니다.
3. 아키텍처 검토
diff가 건드리는 계층에 대한 준수 체크리스트를 살펴보세요. 가장 가치 있는 발견 사항은 성공적인 빌드로는 보여줄 수 없는 것들입니다:
- P2 — 공유 커널에 추가된 도메인 형태의 모든 것: 엔티티, DTO, 열거형, 시드 데이터셋, 가격 상수, 사용자 대상 문자열.
- P3 — 컨텍스트 간 읽기 또는 쓰기; 소유 서비스의 데이터베이스에 접근하는 두 번째 서비스.
- P4 — 마이그레이션 없이 변경된 스키마, 또는 공급자 이식이 불가능한 마이그레이션.
- P5 — 소스, 설정 또는 주석에 있는 비밀, 키 또는 연결 문자열; 환경 외부에서 읽는 설정.
- P8 — 시작 시 저하(degrade)되지 않고 실패하는 새 종속성, 또는 상태 엔드포인트와 시작 배너에 없는 종속성.
- P9 / P10 —
Program.cs에 인라인으로 작성된 와이어링; DI에 등록된 인터페이스가 아닌 기본 클래스로 추가된 확장 지점. - P11 — 변환되지 않은 외부 형태가 도메인에 도달.
- P15 — 트레이스, 메트릭 또는 로그가 없는 새 경로.
SERVICE-API-PATTERNS.md— 신뢰 그룹 외부의 엔드포인트, 클램핑되지 않은 목록, 비균일 오류 본문, 명시적 타임아웃이 없는 아웃바운드 호출, 재시도된 비결정적 쓰기.- 보안 — 새로 공개 노출되는 모든 것은 출시 전에
SECURITY-REVIEW.md검토를 받아야 하며, 이후가 아닙니다.
풀 리퀘스트가 이유와 함께 결정으로 기록한 이탈(deviation)은 발견 사항이 아닙니다. 동일한 이탈이지만 기록되지 않은 경우 발견 사항입니다 — 이 구분이 P14의 역할입니다.
4. 테스트 검토
테스트 본문을 읽으세요. 테스트 개수, 파일 개수 및 폴더 구조는 아무것도 증명하지 않습니다; 2026-08-14의 447개 테스트 스위트 감사에서 약 45%가 플레이스홀더이거나 어떤 것도 단언하지 못하도록 보호된 상태였으며, 이 중 어느 것도 외부에서 보이지 않았습니다(P13).
- 각각의 새 테스트가 로직을 보유한 계층에 있습니까, 아니면 브라우저가 검증기를 대신하고 있습니까?
- 결과(outcome) 를 단언합니까, 아니면 버튼이 클릭되었다는 것을 단언합니까?
- diff가 건드리는 각 기존 경로에 대한 회귀(regression) 테스트가 있습니까, 아니면 새 분기에 대한 테스트만 있습니까?
- 테스트별 기준을 충족합니까 — 독립적,
data-testid, 슬립(sleep) 없음, 프로덕션 자격 증명 없음(TESTING-STRATEGY.md§6)? - 새로운 테스트 진입점이 CI 컨텍스트(§9)에 의해 실행됩니까?
5. 심각도 및 판정
모든 발견 사항에 순위를 매기고, 설명하기 쉬운 정도가 아니라 결과에 따라 순위를 매기세요:
| 수준 | 의미 |
|---|---|
| 차단(Blocking) | 수용 기준이 충족되지 않았거나 입증되지 않음; 기록된 결정 없이 원칙 위반; 비밀 노출; 통과를 위해 테스트가 약화되거나 삭제됨 |
| 수정 권장(Should fix) | 올바르지만 패턴에서 벗어남: 잘못된 테스트 계층, 누락된 회귀 커버리지, 기록되지 않은 가정, 변경으로 인해 거짓이 된 문서 |
| 고려(Consider) | 진정으로 선택 사항. 이 섹션은 짧게 유지하세요 — 긴 섹션은 처음 두 가지를 묻어버립니다 |
다이어그램의 게이트가 필요로 하는 판정으로 마무리하세요: 이 풀 리퀘스트가 티켓을 전달하며 아키텍처 내에 있습니까? 세 가지 답변 중 하나 — 검증됨; 나열된 비차단 발견 사항과 함께 검증됨; 또는 차단 발견 사항이 명명된 채 검증되지 않음. "좋아 보임, 몇 가지 코멘트"는 판정이 아닙니다.
6. 실패 모드
| 증상 | 원인 |
|---|---|
| 리뷰가 요구 사항을 놓친 diff를 승인함 | 코드에서 시작했지 수용 기준에서 시작하지 않음 |
| 리뷰가 스타일 의견 목록임 | 빌드가 통과했기 때문에 아키텍처 및 테스트 검토를 건너뜀 — 이것이 정확히 그것들이 확인하는 것임 |
| 통과한 스위트가 증거로 취급됨 | 테스트 본문을 읽지 않았고, 대신 개수와 구조를 신뢰함 |
| 모든 발견 사항이 동일한 가중치로 보고됨 | 심각도 순위가 없어서 차단 발견 사항이 명명 사소한 문제 아래에 묻힘 |
| 동일한 위반이 여러 풀 리퀘스트에 걸쳐 반복됨 | 리뷰어가 발견 사항을 보고하지 않고 수정하여 패턴을 배우지 못함 |
| 이미 작성자가 정당화한 이탈이 보고됨 | 리뷰 전에 풀 리퀘스트의 기록된 결정을 읽지 않음 |
7. 체크리스트
- 저장소의 실제 기본 브랜치와 diff 비교; 변경된 모든 파일 읽음
- 각 수용 기준을 충족하는 코드 및 이를 증명하는 테스트에 매핑
- 뒤에 기준이 없는 변경 사항 식별 및 분류
- diff가 건드리는 모든 계층에 대한 준수 체크리스트 살펴봄
- 기록된 결정을 먼저 읽어서 정당화된 이탈이 발견 사항으로 보고되지 않도록 함
- 새로 공개된 모든 것에 보안 검토 수행
- 테스트 본문을 읽음(개수 아님); 계층, 결과 단언, 회귀 커버리지 및 테스트별 기준 확인
- 발견 사항을 차단 / 수정 권장 / 고려로 순위 매김
- 티켓에 대한 명시적 판정 제공
- 리뷰 중 아무것도 수정하지 않음
docs/delivery/PR-REVIEW.md에서 scripts/build-marketplace.mjs에 의해 생성됨. 이 파일을 편집하지 마십시오: 소스 문서 또는 catalog/marketplace.catalog.json의 항목을 변경하고 생성기를 다시 실행하십시오.