이슈 분석 명령
사용자 입력
text
$ARGUMENTS
사용자 입력이 비어있지 않다면 반드시 고려해야 합니다.
개요
- •
사용자 입력 파싱:
- •$ARGUMENTS에서 작업 설명 추출
- •작업명 생성 (2-4 단어, 영문, 하이픈 구분)
- •
문제 정의:
- •현재 상황, 해결할 문제, 목표 파악
- •
해결방안 조사:
- •2-4개 방안 조사
- •각 방안의 장단점 분석
- •코딩 원칙 기반 평가
- •
판단 확신도 평가 및 최종 선택:
- •모든 분석 완료 후, 판단 확신도 평가 (판단 솔직성 규칙 참조)
- •확정 선택 → 방안 선택, 반려 이유 명확화
- •권장 추천 → 방안 추천, 대안과 결정 요인을 사용자에게 제시
- •
역질문 생성:
- •불명확한 부분 최대 3개만 선별
- •나머지는 합리적 기본값 + 가정
- •
ADR 평가:
- •분석 완료 후, 결정이 ADR 기준(PRICE)에 해당하는지 평가
- •PRICE 기준 하나라도 해당 시, 문서에 ADR 평가 섹션 추가
- •
문서 작성:
- •
docs/work/{작업명}/analysis.md생성 (한글)
- •
핵심 규칙
📝 문서 작성 언어
중요: 모든 문서는 한글로 작성해야 합니다.
📝 작성 순서
분석 본문(문제 정의 ~ 해결방안 조사)을 사고에서 먼저 완성한 후, 결론(요약) 섹션을 마지막에 작성한다. 문서에서 결론이 최상단에 위치하더라도.
🎯 균형 잡힌 분석 원칙
- •문제 정의: 추상적 설명보다 구체적 시나리오 포함
- •해결방안: 사용자 관점과 기술적 타당성 모두 고려
- •구현 방법: 핵심 변경사항 간결히, 신규 의존성 명시
- •완료 조건: 기능 검증과 기술 구현 분리
- •가중 평가: 모든 장단점이 동등한 무게를 갖지 않는다. 이 문제에서 가장 중요한 평가 기준을 먼저 파악한 후 비교한다. 하나의 핵심 장점이 여러 사소한 장점보다 클 수 있다.
🎭 객관성 원칙 (매우 중요)
핵심: 솔직하게. 있는 건 숨기지 말고, 없는 건 만들지 말 것.
- •
분석 먼저, 결론은 나중에
- •모든 방안 분석 완료 후 선택
- •
사실대로 작성
- •A가 장점 5개, B가 1개면 그대로 (강제 균형 금지)
- •부작용 있으면 기술, 없으면 없다고 (숨기지도, 만들지도 말 것)
- •방안 반려 시 포기하는 이점도 인정
- •
중립적 언어
- •금지: "단순히", "명백히", "당연히", "그냥"
- •사용: "~할 수 있다", "~일 가능성"
- •
판단 솔직성 (매우 중요)
- •모든 분석 완료 후, 결론 작성 전에 판단 확신도를 평가한다
- •확정 선택 (단정적 선택) — 모든 조건 충족 시:
- •한 방안이 모든 평가 차원에서 동등 이상, 열등한 차원 없음 (파레토 우위)
- •또는 기술적/프로젝트 제약이 다른 방안을 제거
- •또는 명시적이고 모호하지 않은 프로젝트 컨벤션이 답을 결정
- •그리고 결정 요인이 AI가 모르는 사용자/팀 선호도나 비즈니스 컨텍스트에 의존하지 않음
- •권장 추천 (사용자에게 선택 위임) — 하나라도 해당 시:
- •방안들이 서로 다른 차원에서 장점을 가진 대등한 트레이드오프 (해당 차원 명시)
- •결정 요인이 주관적 선호 (예: 단순성 vs 유연성)
- •비즈니스/프로덕트 컨텍스트가 필요하나 AI가 갖고 있지 않음
- •리스크 허용도 또는 시간 지평이 결정 요인
- •방안 간 차이가 미미함
- •기본값은 "권장 추천"이다. "확정 선택"은 정당한 트레이드오프가 남아있지 않음을 증명해야 한다.
- •확신을 날조하지 말 것. 솔직한 판단이 "비슷하다"면 그렇게 말한다.
판단 유형 예시:
- •확정 선택: 프로젝트가 PostgreSQL을 사용, 방안 A는 PostgreSQL 기반, 방안 B는 MongoDB 전용 → 기술 제약으로 확정
- •권장 추천: 방안 A는 구현 간단하지만 확장성 제한, 방안 B는 복잡하지만 확장성 우수 → 향후 규모와 팀 선호에 따라 달라짐 → 권장 추천
확정 선택 시 추가 금지 표현:
- •"굳이 ~할 필요가 없다" (대안 무시)
- •"사실상 유일한 선택" (실제로 하나만 남지 않는 한)
- •"다른 방안은 현실적이지 않다" (구체적 근거 필요)
✅ 해야 할 것
- •결론 우선 (요약)
- •구체적 시나리오 포함 (문제 정의) - 이슈에 따라 1-4개
- •사용자 영향 설명 (해결방안) - 어떻게 사용하는가
- •기술적 타당성 평가 (해결방안) - 왜 적합한가
- •코딩 원칙 기반 해결방안 평가
- •확인 필요 사항은 최대 3개 - 나머지는 합리적 기본값 사용
❌ 하지 말아야 할 것
- •추상적 문제 정의만 (구체적 예시 없음)
- •과도한 기술 세부사항 (구현 레벨까지 들어가는 것)
- •사용자 관점 누락 (기술만 이야기)
- •당연한 것을 나열 (예: React state, JSON schema)
문서 템플릿
생성할 파일: docs/work/{작업명}/analysis.md (한글)
markdown
# [작업명] - 분석 결과
## 🎯 결론 (요약)
<!-- 확정 선택 시 이 형식 사용 -->
**판단 유형**: 확정 선택
**선택한 방안**: [방안 이름]
**핵심 이유**: [왜 이 방안을 선택했는가 1-2문장]
<!-- 권장 추천 시 이 형식 사용 -->
**판단 유형**: 권장 추천 (사용자 확인 필요)
**추천 방안**: [방안 이름]
**핵심 이유**: [왜 이 방안을 추천하는가 1-2문장]
**대안 검토 필요**: [어떤 상황이면 방안 M이 더 적합]
---
## 📋 문제 정의
**구체적 시나리오** (필요한 만큼):
- [케이스 1: 현재 어떤 상황에서 어떤 문제가 발생하는가]
- [케이스 2: 또 다른 구체적 상황]
**현재 문제**: [무엇이 불편하거나 불가능한가]
**목표**: [이 작업으로 달성하려는 것]
---
## 📦 범위
**포함**:
- [작업 범위 1]
- [작업 범위 2]
**제외**:
- [명시적으로 제외할 것]
---
## 🔍 해결방안 조사
### 방안 1: [이름]
**접근**:
- [어떻게 해결할 것인가 - 사용자 영향과 기술적 방법 포함]
**장점**:
- [왜 좋은가 - 사용자/기술 관점]
**단점**:
- [왜 문제가 될 수 있는가]
**부작용/위험** (있다면):
- [성공적으로 구현해도 발생할 수 있는 부정적 결과]
### 방안 2: [이름]
[동일 구조]
---
## ✅ 최종 선택
<!-- 확정 선택 시 이 형식 사용 -->
**판단 유형**: 확정 선택
**채택**: 방안 N
**확정 근거**: [충족된 기준 — 기술 제약 / 파레토 우위 / 프로젝트 컨벤션]
**감수하는 트레이드오프** (있다면):
- [다른 방안에서 얻을 수 있었던 이점이지만 포기]
**알려진 위험** (있다면):
- [무엇이 잘못될 수 있는가]
**선택 이유**:
- [왜 이 방안이 가장 적합한가]
**반려된 방안** (잃는 것도 함께 기술):
- 방안 X: [반려 이유] — 포기하는 이점: [잃는 것]
<!-- 권장 추천 시 이 형식 사용 -->
**판단 유형**: 권장 추천 (사용자 확인 필요)
**추천**: 방안 N
**유력 대안**: 방안 M
**핵심 차이 비교**:
| 요소 | 방안 N | 방안 M |
| --------------- | ------ | ------ |
| [핵심 차별점 1] | ... | ... |
| [핵심 차별점 2] | ... | ... |
**방안 N 추천 이유**:
- [추론 - 선호의 문제임을 인정]
**방안 M이 더 나은 상황**:
- [대안이 더 적합한 구체적 조건]
**선택 가이드**:
- [우선순위 A] 중시 → 방안 N
- [우선순위 B] 중시 → 방안 M
---
## 🛠️ 구현 방법
**핵심 변경사항**:
- [변경사항 1]
- [변경사항 2]
**신규 의존성**: [없음 / 이름]
---
## 🎯 완료 조건
**기능 검증**:
- [ ] [시나리오 1 검증 - 실제 사용 케이스 테스트]
**기술 구현**:
- [ ] [핵심 변경사항 구현]
- [ ] [단위 테스트 작성]
---
## ❓ 확인 필요
**현재 가정**:
- [가정 1]: [기본값]
**필요 시 확인**:
- [추가 확인이 필요한 사항 - 최대 3개]
---
## 📌 ADR 평가
<!-- PRICE 기준 하나라도 해당할 때만 이 섹션 포함 -->
<!-- 해당 없으면 섹션 자체를 생략 -->
**해당 PRICE 기준**: [P/R/I/C/E — 해당 항목과 간략한 이유]
**권장**: 계획 단계 진행 전 ADR로 기록
**ADR 제목 제안**: `NNNN-short-description`
> 생성하려면: `/adr [주제]`
---
## 🔍 객관성 자체 점검
- [ ] 사실대로 작성 (숨기지도, 만들지도 않았다)
- [ ] 반려 방안의 포기 이점 인정
- [ ] 중립적 언어 사용 ("~할 수 있다", "~가능성")
- [ ] 판단 확신도를 솔직하게 평가 (주관적 선택에 확정을 강제하지 않았다)
- [ ] **확정 선택인 경우**: 반대 의견을 가진 동료가 읽어도 납득할 수 있는가?
- [ ] **확정 선택인 경우**: 대안의 장점을 과소평가하지 않았는가?
실행
이제 위 지침에 따라 작업을 시작하세요.