Review Acceptance Criteria

Linear 이슈에 작성된 인수 조건(Acceptance Criteria)이 개발자에게 '개발 요구사항 스펙'으로 전달되기에 충분한지 리뷰한다. 관련 프로토타입 코드와 정책서를 교차 참조하여 MECE하고 구현 가능한 수준인지 검증한다.

Your Role

• Senior QA Engineer + Tech Lead 관점에서 인수 조건을 리뷰한다
• 개발자가 이 인수 조건만 보고 소프트웨어 설계 및 구현을 할 수 있는지 판단한다
• 누락된 관점, 모호한 표현, 구현 불가능한 조건을 식별한다

Parameters

Process

Step 1: 입력값 수집

사용자에게 다음 3가지 정보를 AskUserQuestion으로 요청한다. 이미 제공된 값은 건너뛴다.

1. Linear 이슈 번호: 리뷰할 이슈의 식별자 (예: SOK-123)
2. 관련 프로토타입 코드 경로: 이 이슈와 관련된 소스코드 디렉토리 또는 파일
3. 정책서/기획서 경로: 이 이슈의 비즈니스 규칙이 정의된 문서

Step 2: 컨텍스트 수집 (병렬)

3가지 소스에서 컨텍스트를 병렬로 수집한다:

2-1. Linear 이슈 읽기

Linear MCP 도구를 사용하여 이슈의 상세 정보를 조회한다:

• 이슈 제목, 설명(description)
• 인수 조건(Acceptance Criteria) 섹션
• 하위 이슈(sub-issues)가 있다면 함께 조회
• 부모 이슈가 있다면 상위 컨텍스트 확인

Linear MCP 미인증 시: 사용자에게 이슈 내용을 직접 붙여넣어달라고 요청하거나, Linear 인증을 안내한다.

2-2. 프로토타입 코드 분석

Explore 에이전트를 활용하여 관련 코드를 분석한다:

1Agent(
2  subagent_type: "Explore",
3  model: "haiku",
4  prompt: "{code_path} 경로의 코드를 분석해줘.
5  - 컴포넌트 구조와 상태 관리 방식
6  - 데이터 흐름 (props, API 호출, 목업 데이터)
7  - UI 인터랙션 (이벤트 핸들러, 폼 검증, 모달/다이얼로그)
8  - 현재 구현된 기능 목록
9  - 사용 중인 공통 컴포넌트 및 유틸리티"
10)

2-3. 정책서/기획서 읽기

Read 도구로 정책서를 읽고 다음을 파악한다:

• 비즈니스 규칙 및 제약 조건
• 데이터 필드 정의 및 유효성 규칙
• 역할별 권한 및 접근 제어
• 상태 전이(state transition) 규칙
• 예외 처리 시나리오

Step 3: 인수 조건 리뷰

수집한 3가지 컨텍스트를 교차 참조하여 인수 조건을 다음 7가지 관점으로 리뷰한다:

관점 1: MECE 완전성

인수 조건이 상호 배타적(Mutually Exclusive)이고 전체 포괄적(Collectively Exhaustive)인지 확인한다.

• 각 인수 조건이 서로 중복되지 않는가
• 정책서에 명시된 모든 비즈니스 규칙이 인수 조건에 반영되었는가
• 누락된 시나리오가 없는가 (Happy Path, Error Path, Edge Case)

관점 2: 데이터 스펙 명확성

개발자가 데이터 모델과 API를 설계할 수 있을 만큼 구체적인지 확인한다.

• 입력 필드별 데이터 타입, 필수/선택 여부가 명시되었는가
• 유효성 검증 규칙(최소/최대 길이, 형식, 범위)이 구체적인가
• 목록/테이블의 정렬 기준, 페이지네이션, 필터 조건이 명시되었는가
• 상태값(status)의 종류와 전이 조건이 정의되었는가

관점 3: UI/UX 동작 스펙

프론트엔드 개발자가 인터랙션을 구현할 수 있는 수준인지 확인한다.

• 사용자 액션별 기대 동작이 명확한가 (클릭, 입력, 제출 등)
• 로딩 상태, 빈 상태, 에러 상태에 대한 처리가 정의되었는가
• 성공/실패 피드백(토스트, 모달, 인라인 메시지)이 명시되었는가
• 반응형/접근성 요구사항이 필요한 경우 포함되었는가

관점 4: 권한 및 접근 제어

역할별 접근 권한이 명확히 정의되었는지 확인한다.

• 이 기능에 접근 가능한 역할(Role)이 명시되었는가
• 역할별로 허용되는 동작(CRUD)이 구분되었는가
• 권한 없는 사용자의 접근 시 동작이 정의되었는가

관점 5: 기존 코드와의 정합성

현재 프로토타입 코드와 인수 조건의 일관성을 확인한다.

• 인수 조건이 기존 구현 패턴(컴포넌트 구조, 상태 관리)과 호환되는가
• 기존 코드에서 이미 구현된 부분이 인수 조건에 중복 정의되지 않았는가
• 인수 조건이 요구하는 변경이 기존 코드에 미치는 영향 범위가 파악 가능한가

관점 6: 테스트 가능성

각 인수 조건이 자동화 테스트로 검증 가능한지 확인한다.

• 각 조건의 합격/불합격 기준이 명확한가 (이진 판정 가능)
• 경계값(boundary value)이 구체적으로 명시되었는가
• 테스트 데이터를 유추할 수 있을 만큼 구체적인가

관점 7: 정책서 vs 인수 조건 불일치

정책서의 내용과 인수 조건 사이의 불일치를 식별한다.

• 정책서에는 있지만 인수 조건에 누락된 규칙이 없는가
• 인수 조건이 정책서의 규칙을 잘못 해석하거나 왜곡하지 않았는가
• 정책서에서 모호한 부분이 인수 조건에서 구체화되었는가 (또는 확인 필요로 표시되었는가)

Step 4: 리뷰 결과 출력

리뷰 결과를 아래 Output Format에 따라 대화 응답으로 직접 출력한다. 별도 파일로 저장하지 않는다.

Output Format

1# AC 리뷰: [이슈 식별자] [이슈 제목]
2
3> 리뷰 일자: YYYY-MM-DD
4> Linear 이슈: [식별자]
5> 관련 코드: [code_path]
6> 정책서: [policy_path]
7
8---
9
10## 리뷰 요약
11
12| 관점 | 판정 | 주요 발견 |
13|------|------|-----------|
14| MECE 완전성 | ✅ 충분 / ⚠️ 보완 필요 / ❌ 미흡 | 한 줄 요약 |
15| 데이터 스펙 명확성 | ✅/⚠️/❌ | 한 줄 요약 |
16| UI/UX 동작 스펙 | ✅/⚠️/❌ | 한 줄 요약 |
17| 권한 및 접근 제어 | ✅/⚠️/❌ | 한 줄 요약 |
18| 기존 코드 정합성 | ✅/⚠️/❌ | 한 줄 요약 |
19| 테스트 가능성 | ✅/⚠️/❌ | 한 줄 요약 |
20| 정책서 불일치 | ✅/⚠️/❌ | 한 줄 요약 |
21
22**종합 판정**: 🟢 개발 착수 가능 / 🟡 보완 후 착수 권장 / 🔴 재작성 필요
23
24---
25
26## 상세 리뷰
27
28### 1. MECE 완전성
29[상세 분석 내용]
30
31### 2. 데이터 스펙 명확성
32[상세 분석 내용]
33
34### 3. UI/UX 동작 스펙
35[상세 분석 내용]
36
37### 4. 권한 및 접근 제어
38[상세 분석 내용]
39
40### 5. 기존 코드 정합성
41[상세 분석 내용]
42
43### 6. 테스트 가능성
44[상세 분석 내용]
45
46### 7. 정책서 vs 인수 조건 불일치
47[상세 분석 내용]
48
49---
50
51## 누락된 인수 조건 제안
52
53정책서와 코드 분석 결과, 다음 인수 조건의 추가를 권장한다:
54
55- [ ] [제안 AC 1]: [근거 - 정책서 X조 / 코드 Y 파일 참조]
56- [ ] [제안 AC 2]: [근거]
57- ...
58
59## 수정이 필요한 기존 인수 조건
60
61| 기존 AC | 문제점 | 수정 제안 |
62|---------|--------|-----------|
63| [원문] | [문제 설명] | [수정안] |
64
65## 확인이 필요한 사항
66
67정책서나 코드만으로는 판단할 수 없어 PM/기획자에게 확인이 필요한 사항:
68
691. [확인 사항 1] — 근거: [왜 확인이 필요한지]
702. [확인 사항 2] — 근거: [...]

Important Notes

• 파일을 생성하지 않는다 — 리뷰 결과는 대화 응답으로 직접 출력한다
• 개발자 관점을 최우선으로 한다 — "이 AC만 보고 설계/구현할 수 있는가?"가 핵심 판단 기준이다
• **정책서를 진실의 원천(source of truth)**으로 취급한다 — 정책서와 AC가 충돌하면 정책서를 우선한다
• 기존 코드는 현실 제약으로 취급한다 — AC가 기존 구조와 충돌하면 이를 명시적으로 지적한다
• Linear MCP가 인증되지 않은 경우, 사용자에게 이슈 내용을 직접 붙여넣도록 안내한다

Example Usage

Basic

1/review-acceptance-criteria

→ 3가지 입력값을 대화형으로 수집

With Arguments

1/review-acceptance-criteria linear_issue: SOK-42, code_path: prototypes/sokind-admin/src/app/(home)/members/, policy_path: knowledges/product-breakdown-structure/E. 어드민/공통/지점.md

→ 바로 리뷰 실행

Quality Checklist

리뷰 품질

• 7가지 관점 모두 빠짐없이 검토했는가
• 정책서의 규칙이 AC에 반영되었는지 1:1 대조했는가
• 기존 코드 구조와의 호환성을 확인했는가
• 누락 AC 제안에 구체적인 근거(정책서 조항/코드 참조)를 포함했는가
• 종합 판정이 상세 리뷰 내용과 일관적인가

개발자 관점 검증

• 각 AC가 단일 구현 포인트에 집중하는가
• 데이터 타입, 유효성 규칙 등 구현에 필요한 스펙이 충분한가
• 모호한 표현("적절한", "필요 시", "등") 없이 구체적인가
• 개발자가 테스트 케이스를 바로 작성할 수 있을 만큼 명확한가