---
task_id: task-1887
type: context
scope: task
created: 2026-04-16
updated: 2026-04-16
status: completed
---

# 맥락 노트: task-1887

**task**: task-1887

---

## 결정 근거

### 3 Step Why 자문 결과

**1st Why: "왜 이 설계가 필요한가?"**
→ A: 현재 Lv.3+ 작업에서 설계 검증이 셀프 QC와 외부 리뷰(Codex/Gemini)로 분리되어 있지만, "왜 이 접근인가?"에 대한 구조화된 자문 프로세스가 없다. 3 Step Why를 도입하면 설계 근거를 논리 체인으로 강제화하여 근거 없는 설계 결정을 방지한다.

**2nd Why: "왜 A가 최선의 접근인가?"**
→ B: 대안으로 (1) 별도 리뷰 도구 도입, (2) 체크리스트만 강화, (3) Agent 미팅 확대가 있었다. 3 Step Why는 기존 프롬프트/게이트 시스템에 자연스럽게 통합되며 추가 도구 없이 구현 가능하고, 비용이 최소화된다. 기존 인프라(context-notes.md, Codex 리뷰, 로키 레드팀)를 활용하므로 학습 비용도 낮다.

**3rd Why: "왜 B가 다른 대안보다 나은가?"**
→ C: 별도 도구는 유지보수 부담 증가, 체크리스트만 강화는 형식적 체크로 전락할 위험, Agent 미팅 확대는 Lv.3에 과도한 비용. 3 Step Why는 기존 게이트 프로세스에 질문을 삽입하는 방식이므로 비용 대비 효과가 최적이며, A-B-C 일관성 검증으로 형식적 체크 방지도 가능하다.

★ A-B-C 논리적 일관성: 확인됨 — A(구조화된 자문 부재 문제) → B(기존 인프라 활용의 비용 효율성) → C(대안 대비 최적의 비용/효과 비율) 논리 체인 일관.

### 수정 위치 결정

- team_prompts.py의 `_build_three_docs_section` 함수: Lv.3+ 프롬프트에 3문서 지침과 함께 자문 절차를 안내하는 가장 자연스러운 위치
- gate_instructions.py의 Lv.3 G1/Lv.4 G2: 각각 Codex 사전 리뷰/로키 레드팀 단계에 질문을 삽입하는 것이 게이트 흐름에 부합
- QC-RULES.md의 셀프 QC: 결과물 검증 단계에서 A-B-C 기록 여부를 확인하는 최종 게이트

## 참조 자료

- 아누 가이드: cross-verification-workflow Phase 3.5
- QC-RULES.md v4.1

## 주의사항

- Lv.2 이하에는 3 Step Why 적용되지 않음 (비용 대비 효과 부적절)
- context-notes.md에 A-B-C 기록이 없으면 QC 항목 12에서 차단됨