solo-decision-tracker

의사결정 추적 스킬

이 스킬은 프로젝트의 모든 의사결정을 3단계 심각도 체계로 추적하고 관리합니다. 모든 의사결정은 기록되고, 확인되고, 반영됩니다.

---

1. 3단계 심각도 체계

1.1 심각도 정의 및 승인자

심각도	레벨	심각도 기호	승인자	영향 범위	소요 시간	예시
🔴 전략적	높음	🔴	PM (민수님)	프로젝트 전체	즉시	스코프 변경, 우선순위 조정, 일정 변경, 전략 방향
🟡 기술적	중간	🟡	PL (준호)	기술 영역	24시간	기술 스택 선택, 아키텍처 방향, 산출물 형식, 에이전트 배치
🟢 운영적	낮음	🟢	담당 에이전트	국소적	당일	조사 방법, 문서 구조, 코드 스타일, 파일명 규칙

1.2 심각도별 특징

🔴 전략적 의사결정 (PM 확인 필수)

특징:

• 프로젝트 전체에 영향
• PM의 최종 의사결정 필요
• 즉시 처리 필요
• 다른 의사결정에 우선

예시:

• "프로젝트 일정을 1개월 연장하기" (영향: Phase 계획 변경)
• "주요 기능 2개 스코프에서 제외" (영향: 요구사항 변경)
• "기술 스택 변경 (React → Vue)" (영향: 아키텍처, 개발 계획)
• "개발 팀 확대 (2명 → 4명)" (영향: 팀 구성)

처리 절차:

1. 상황 분석 및 선택지 정리
2. PL의 의견 및 권장안 작성
3. PM에게 의사결정 요청
4. PM 확인 후 decision_log.md에 기록
5. 영향받는 모든 에이전트에 공지

🟡 기술적 의사결정 (PL 판단 + 사후보고)

특징:

• 기술 영역의 핵심 결정
• PL의 전문 판단 기반
• 결정 후 PM에 사후보고
• 24시간 내 처리

예시:

• "데이터베이스는 PostgreSQL 사용" (기술 선택)
• "프론트엔드는 TypeScript 사용" (개발 규칙)
• "API 문서 형식은 OpenAPI 3.0" (산출물 형식)
• "에이전트 배치: 리서처 2명, 개발자 3명" (에이전트 구성)
• "로깅 레벨은 DEBUG" (개발 규칙)

처리 절차:

1. 문제 분석 및 선택지 정리
2. PL이 기술적으로 판단
3. decision_log.md에 기록
4. PM에 사후보고 (세션 종료 시)
5. decision_log.md에서 CLAUDE.md Section 9로 동기화

🟢 운영적 의사결정 (에이전트 자율)

특징:

• 국소적인 운영 사항
• 담당 에이전트가 자율 결정
• 결정 후 기록
• 당일 처리 가능

예시:

• "조사 방법: 온라인 문헌 조사 vs 인터뷰" (조사 방법)
• "문서 구조: 마크다운 vs 노션" (도구 선택)
• "코드 스타일: 2칸 vs 4칸 들여쓰기" (코딩 규칙)
• "파일 이름: snake_case vs camelCase" (이름 규칙)
• "테스트 프레임워크: Jest vs Mocha" (개발 도구)

처리 절차:

1. 담당 에이전트가 자율 결정
2. decision_log.md의 "운영 결정" 섹션에 기록
3. 관련 문서/가이드 업데이트

---

2. 의사결정 기록 절차

2.1 Step 1: decision_log.md 읽기

경로: docs/00_관리/decisions/decision_log.md
확인:
- 현재 최신 D-번호 확인
- 유사한 이전 결정사항 확인
- 상충하는 결정 여부 확인

2.2 Step 2: D-번호 부여

규칙: D-{01, 02, 03, ...}

현재 최신 D-번호가 D-05라면 → 새 의사결정은 D-06

예시:
- D-01: 프로젝트 시작 날짜
- D-02: 기술 스택 (React/Vue)
- D-03: 데이터베이스 (PostgreSQL)
- D-04: API 문서 형식
- D-05: 에이전트 배치 구성
- D-06: 추가되는 새로운 의사결정

2.3 Step 3: 의사결정 테이블에 행 추가

decision_log.md 메인 테이블 구조:

| D-번호 | 날짜 | 심각도 | 항목 | 상태 | 결정 내용 | 결정자 | 영향 범위 |
|--------|------|--------|------|------|---------|--------|---------|
| D-01 | 2026-03-20 | 🔴 | 프로젝트 시작 일정 | ✅ 완료 | 2026-03-23 시작 | PM | 전체 Phase 일정 |
| D-02 | 2026-03-21 | 🟡 | 프론트엔드 프레임워크 | ✅ 완료 | React 선택 | PL | FE 개발 환경 |
| D-XX | YYYY-MM-DD | 🔴/🟡/🟢 | {항목} | 진행/완료 | {결정 내용} | {PM/PL/에이전트} | {영향 범위} |

필드 설명:

필드	설명	예시
D-번호	의사결정 고유 ID	D-06
날짜	의사결정 발생 날짜	2026-03-23
심각도	🔴/🟡/🟢	🟡
항목	의사결정 주제	데이터베이스 선택
상태	진행/완료	✅ 완료 / ⏳ PM확인대기
결정 내용	최종 결정사항	PostgreSQL + TypeORM
결정자	누가 최종 결정	PL 준호
영향 범위	어디에 영향을 미치는가	BE 개발, DB 설계

2.4 Step 4: 의사결정 상세 기록 작성

의사결정의 맥락과 근거를 별도 섹션에 기록:

### D-06: 데이터베이스 선택

**발생 날짜**: 2026-03-23
**심각도**: 🟡 기술적 의사결정
**배경**:
BE 구현 시작 전에 데이터베이스를 선택해야 함.
요구사항: 관계형 데이터, 트랜잭션, 확장성

**선택지**:

A) **PostgreSQL + TypeORM**
- 장점: 성숙한 기술, 풍부한 기능, ORM 지원 좋음
- 단점: 셋업 복잡, 메모리 사용량 많음
- 권장: O

B) **MySQL + Sequelize**
- 장점: 설정 간단, 성능 좋음
- 단점: 기능 제한, 복잡한 쿼리 어려움
- 권장: X

C) **MongoDB (NoSQL)**
- 장점: 유연한 스키마, 빠른 개발
- 단점: 트랜잭션 미지원, 정규화 어려움
- 권장: X (현재 요구사항에 부적합)

**최종 결정**: PostgreSQL + TypeORM
**근거**: 요구사항의 관계형 데이터 처리에 최적, 팀의 PostgreSQL 경험
**결정자**: PL 준호 (기술 판단)
**영향 범위**:
- BE 개발 환경 설정
- DB 스키마 설계 (D-07)
- 개발 가이드 업데이트

**반영**:
- docs/03_설계/DB스키마/스키마_v1.md에 반영
- BE 개발자에게 공지 (session_2026-03-23_2)
- 개발 가이드 추가: DB 설정 방법

**동기화**:
- CLAUDE.md Section 9 (확정 의사결정)에 추가: ✅ 2026-03-23

---

3. PM 확인 요청 형식 (🔴 전략적)

의사결정이 🔴 심각도인 경우, PM에게 다음 형식으로 요청:

3.1 요청 형식

PM, 의사결정이 필요한 사항이 있습니다.

**[D-XX] {항목}**

### 배경
{왜 이 결정이 필요한지, 현재 상황, 긴급성}

### 선택지

**A) {선택지 1}**
- 장점: {장점 1}, {장점 2}
- 단점: {단점 1}, {단점 2}
- 구현 일정 영향: {구체적 영향}

**B) {선택지 2}**
- 장점: {장점 1}, {장점 2}
- 단점: {단점 1}, {단점 2}
- 구현 일정 영향: {구체적 영향}

### PL(준호)의 권장안
{PL이 기술적으로 판단한 권장안과 근거}

### 영향 범위
- {영역 1}: {구체적 영향}
- {영역 2}: {구체적 영향}

언제까지 확인이 필요한가요?
(예: "오늘 오후", "내일 오전", "즉시")

3.2 PM 응답 처리

PM의 의사결정이 도착하면:

1. decision_log.md 메인 테이블 업데이트

   • 상태: ⏳ 대기 → ✅ 완료
   • 결정 내용: PM의 선택 기록
   • 결정자: PM 민수님

2. 의사결정 상세 기록 업데이트

   • "최종 결정": PM의 선택
   • "결정자": PM 민수님
   • "결정 사유": PM의 설명 (있으면)
   • "반영": 어떻게 반영할 것인지

3. CLAUDE.md 동기화

   • Section 10 (미결) → Section 9 (확정)으로 이동

4. 영향받는 에이전트에게 공지

   • 해당 D-번호와 결정 내용 전파
   • 다음 세션 또는 즉시 반영

---

4. PL 판단 절차 (🟡 기술적)

의사결정이 🟡 심각도인 경우, PL이 기술적으로 판단:

4.1 판단 절차

1. 상황 분석

   • 왜 이 결정이 필요한지
   • 가능한 선택지는 뭔지
   • 이전 관련 결정사항 확인 (decision_log.md)

2. 기술적 검토

   • 각 선택지의 기술적 장단점
   • 프로젝트의 기술 스택과의 호환성
   • 팀의 기술 수준과 경험

3. 권장안 도출

   • 최적의 선택지 선정
   • 근거 명확히 기술

4. decision_log.md 기록

   • 즉시 메인 테이블에 추가 (상태: ✅ 완료)
   • 상세 기록 작성
   • "결정자": PL 준호

5. PM 사후보고 (세션 종료 시)

   • 세션 종료 보고에 포함
   • "🟡 PL 판단됨" 섹션에 나열

4.2 PL 판단 프롬프트 (자가 진행)

당신은 프로젝트의 PL(준호)입니다.

다음 의사결정을 기술적으로 판단해주세요.

**[D-XX] {항목}**

### 배경
{현재 상황과 왜 결정이 필요한지}

### 선택지
A) {선택지 1}
B) {선택지 2}
C) {선택지 3}

### 기술적 고려사항
{프로젝트 기술 스택, 팀의 경험, 요구사항}

### 결정
다음을 포함하여 결정해주세요:
1. 최종 선택지
2. 근거 (기술적, 전략적)
3. 영향 범위
4. 구현 방안
5. 잠재적 리스크

decision_log.md에 기록합니다.

---

5. 에이전트 자율 결정 (🟢 운영적)

의사결정이 🟢 심각도인 경우, 담당 에이전트가 자율 결정:

5.1 자율 결정 지침

**대상**: 🟢 운영적 의사결정
**결정자**: 해당 작업 담당 에이전트
**기록**: decision_log.md "운영 결정" 섹션

### 기록 형식

**D-XX: {항목}**
- 결정: {선택사항}
- 근거: {간단한 근거}
- 담당: {에이전트명}
- 날짜: YYYY-MM-DD

5.2 자율 결정 예시

D-10: 조사 방법 결정
- 배경: 시장 조사 필요
- 선택지: A) 온라인 문헌 조사, B) 인터뷰, C) 설문
- 결정: A) + B) 병행
- 근거: 시간 제약 내 최대 데이터 수집
- 담당: 리서처 지은

---

6. Pending → Confirmed 플로우

6.1 상태 전이

의사결정 발생
    ↓
[초기 상태]
- Section 10 (미결)에 기록
- decision_log.md: 상태 = "⏳ {대기 중}"

    ↓
    ↓ (🔴: PM 확인, 🟡: PL 판단, 🟢: 에이전트 결정)
    ↓

[최종 상태]
- Section 9 (확정)으로 이동
- decision_log.md: 상태 = "✅ 완료"
- 영향받는 에이전트에게 반영 지시

6.2 CLAUDE.md 동기화

Section 10 (미결 의사결정) → Section 9 (확정 의사결정)로 이동하는 시점:

• 🔴: PM이 의사결정을 확인한 후
• 🟡: PL이 기술적으로 판단한 직후
• 🟢: 에이전트가 자율 결정 직후

---

7. decision_log.md 템플릿

# 의사결정 로그

**프로젝트명**: {프로젝트명}
**프로젝트 시작**: YYYY-MM-DD
**마지막 업데이트**: YYYY-MM-DD

---

## 의사결정 요약 테이블

| D-번호 | 날짜 | 심각도 | 항목 | 상태 | 결정 내용 | 결정자 | 영향 범위 |
|--------|------|--------|------|------|---------|--------|---------|
| D-01 | 2026-03-20 | 🔴 | 프로젝트 시작 일정 | ✅ | 2026-03-23 시작 | PM | Phase 일정 |
| D-02 | 2026-03-21 | 🟡 | FE 프레임워크 | ✅ | React 선택 | PL | FE 개발 환경 |
| D-03 | 2026-03-22 | 🟡 | BE 프레임워크 | ✅ | Node.js + Express | PL | BE 개발 환경 |
| D-04 | 2026-03-23 | 🟡 | 데이터베이스 | ✅ | PostgreSQL | PL | DB 설계 |
| D-05 | 2026-03-23 | 🔴 | 팀 확대 여부 | ⏳ PM확인대기 | - | PM | 팀 구성 |

---

## 의사결정 상세 기록

### D-01: 프로젝트 시작 일정

**발생 날짜**: 2026-03-20
**심각도**: 🔴 전략적 의사결정

**배경**:
프로젝트 본격 시작 전 최종 일정 확인 필요. 모든 Phase와 마일스톤이 이 결정에 의존함.

**선택지**:

A) **2026-03-23 시작** (추천)
- 장점: 충분한 준비 시간, 리스크 낮음
- 단점: 일정 늘어남
- Phase 일정: 4개월 예상

B) **2026-03-20 즉시 시작**
- 장점: 빨리 시작
- 단점: 준비 불충분, 위험

**최종 결정**: A) 2026-03-23 시작
**결정자**: PM 민수님
**근거**: 충분한 준비 기간 확보

**영향 범위**:
- CLAUDE.md Section 1: 시작일 기록
- CLAUDE.md Section 8: 전체 Phase 일정 영향

---

### D-02: 프론트엔드 프레임워크

**발생 날짜**: 2026-03-21
**심각도**: 🟡 기술적 의사결정

**배경**:
FE 개발 환경 구축을 위해 프레임워크 선택 필수. 프로젝트의 기술 기초가 될 결정.

**선택지**:

A) **React** (추천)
- 장점: 생태계 풍부, 커뮤니티 크다, 팀 경험 있음
- 단점: 번들 사이즈 상대적으로 크다

B) **Vue**
- 장점: 러닝커브 낮음, 문서 좋음
- 단점: 팀 경험 부족

C) **Svelte**
- 장점: 최신 기술, 성능 좋음
- 단점: 생태계 작음, 팀 경험 전무

**최종 결정**: A) React
**결정자**: PL 준호 (기술 판단)
**근거**: 팀의 React 경험과 풍부한 생태계 활용

**영향 범위**:
- FE 개발 환경 (docs/04_개발/src/frontend/)
- 개발 가이드 작성
- FE 개발자 배치

---

### D-05: 팀 확대 여부

**발생 날짜**: 2026-03-23
**심각도**: 🔴 전략적 의사결정

**배경**:
요구사항 명세 완료 후 기능 규모가 예상보다 큼 (30개 기능).
현재 팀 (PL + PM + 3명)으로 일정 내 완료 가능한지 재검토 필요.

**선택지**:

A) **팀 유지 (현재: 5명)**
- 장점: 커뮤니케이션 효율, 비용 절감
- 단점: 일정 지연 가능, 품질 리스크

B) **팀 확대 (→ 7명: FE 1명 추가, 검증자 1명 추가)** (추천)
- 장점: 일정 확보, 품질 향상
- 단점: 커뮤니케이션 복잡, 비용 증가

**PL의 권장**: B) 팀 확대
- 근거: 기능 규모상 현재 인원으로는 위험, FE와 QA 병목 예상

**영향 범위**:
- CLAUDE.md Section 2: 팀 구성 변경
- CLAUDE.md Section 8: Phase 일정 재계획
- agent-dispatch: 새 에이전트 투입 계획

**상태**: ⏳ PM 확인 대기 중

**PM 확인 필요 항목**:
- 추가 비용 가능 여부?
- 추가 인원 투입 시기?
- 우선순위는?

---

## 미결 의사결정 (검토 중)

| D-번호 | 항목 | 심각도 | 대기 대상 | 예상 확인 일 |
|--------|------|--------|---------|-----------|
| D-05 | 팀 확대 여부 | 🔴 | PM | 2026-03-23 |
| D-06 | 스코프 우선순위 | 🔴 | PM | 2026-03-24 |

---

## 운영 결정

### D-20: 조사 방법 (🟢 에이전트 자율)
- 항목: 기술 조사 방법
- 결정: 온라인 문헌 조사 + 샘플 프로젝트 구성
- 담당: 리서처 지은
- 날짜: 2026-03-22

### D-21: 문서 형식 (🟢 에이전트 자율)
- 항목: 요구사항 명세 문서 형식
- 결정: 마크다운 + 구글 문서 (협업용)
- 담당: 기획자 한결
- 날짜: 2026-03-22

---

## 의사결정 통계

- 총 의사결정: {개수}
- 🔴 전략적: {개수} (완료: {개수}, 대기: {개수})
- 🟡 기술적: {개수} (완료: {개수})
- 🟢 운영적: {개수} (완료: {개수})

**평균 의사결정 시간**:
- 🔴: {시간}
- 🟡: {시간}
- 🟢: {시간}

---

## 의사결정 연관도

D-01 (시작일) ├─→ D-02 (FE 프레임워크) │ └─→ D-07 (FE 구현 방법) ├─→ D-03 (BE 프레임워크) │ └─→ D-08 (BE 구현 방법) ├─→ D-04 (데이터베이스) │ └─→ D-09 (DB 스키마) └─→ D-05 (팀 확대) └─→ D-06 (일정 조정)

---

## 의사결정 히스토리 (최근 5개)

1. D-04 (2026-03-23): 데이터베이스 선택 → PostgreSQL
2. D-03 (2026-03-21): BE 프레임워크 → Node.js + Express
3. D-02 (2026-03-21): FE 프레임워크 → React
4. D-01 (2026-03-20): 프로젝트 시작 일정 → 2026-03-23

---

8. 의사결정 트래킹 다이어그램

의사결정 필요 상황 발생
    ↓
[Step 1] 심각도 판단
    ├─ 🔴 (전략적) → PM 확인 경로로
    ├─ 🟡 (기술적) → PL 판단 경로로
    └─ 🟢 (운영적) → 에이전트 자율 경로로
    ↓
    ├─ [🔴 경로] PM에게 의사결정 요청서 발송
    │   ↓
    │   PM의 응답 도착
    │   ↓
    │   decision_log.md 업데이트 (상태: ✅)
    │
    ├─ [🟡 경로] PL이 기술적으로 판단
    │   ↓
    │   decision_log.md 업데이트 (상태: ✅)
    │   ↓
    │   세션 종료 시 PM에 사후보고
    │
    └─ [🟢 경로] 에이전트가 자율 결정
        ↓
        decision_log.md 기록
        ↓
        영향받는 팀원에 공지

    ↓
[Step 2] decision_log.md 메인 테이블 행 추가
    ↓
[Step 3] 상세 기록 작성
    ↓
[Step 4] CLAUDE.md 동기화
    ├─ Section 10 (미결) 에 추가
    └─ 확정 후 Section 9 (확정)으로 이동
    ↓
[Step 5] 영향받는 에이전트에게 공지
    ├─ agent-dispatch: 다음 에이전트 투입 시 decision_log 포함
    └─ 관련 가이드 업데이트

---

9. 의사결정 체크리스트

의사결정 기록 전

• decision_log.md 최신 상태 확인
• 유사한 이전 결정사항 있는지 확인
• D-번호 중복 없는지 확인
• 심각도 올바르게 판단했는지 확인

의사결정 기록 후

• decision_log.md 메인 테이블에 행 추가됨
• 상세 기록 작성됨
• 필요시 PM 또는 PL에 요청 발송됨
• CLAUDE.md Section 10에 항목 추가됨

의사결정 확정 후

• decision_log.md 상태 업데이트: ⏳ → ✅
• CLAUDE.md Section 10 (미결) → Section 9 (확정)으로 이동
• 영향받는 에이전트에게 공지됨
• 관련 문서 업데이트됨

---

10. PM 확인 요청 샘플

PM, 의사결정이 필요한 사항이 있습니다.

**[D-05] 팀 규모 확대**

### 배경
요구사항 분석 결과 기능이 30개(예상 대비 +50%).
현재 팀으로 4개월 내 완료 가능성 낮음.

프로젝트: 모바일 커머스 플랫폼
- 예상 기능: 20개
- 실제 기능: 30개
- 예상 일정: 4개월
- 현재 팀: 5명 (PL 준호, PM 민수님, 리서처, FE개발자, BE개발자)

### 선택지

**A) 팀 유지 (현재: 5명)**
- 일정: 5-6개월 소요 (1-2개월 지연)
- 품질: 높음 (충분한 검증 시간)
- 비용: 낮음
- 커뮤니케이션: 효율적

**B) 팀 확대 (→ 7명)** ⭐ PL 권장
- 추가 인원: FE개발자 1명, 검증자 1명
- 일정: 4개월 내 달성 가능
- 품질: 높음 (전담 QA)
- 비용: 중간 (단기 투입)
- 커뮤니케이션: 약간 복잡

**C) 스코프 축소 (→ 22개 기능)**
- 일정: 4개월 내 달성
- 품질: 높음
- 비용: 낮음
- 제약: 핵심 기능 8개 제외

### PL(준호)의 권장안
**B) 팀 확대** 권장
- 근거: 기능 규모상 현재 인원으로는 QA 및 FE 병목 예상
- A) 선택 시 지연 위험 높음
- C) 선택 시 스코프 축소로 인한 전략적 손실

### 영향 범위
- 팀 구성: CLAUDE.md Section 2 변경
- Phase 일정: 현재 계획 유지 가능
- 비용: 단기 추가 비용 발생
- 커뮤니케이션: 팀 규모 확대로 인한 오버헤드

### 결정 필요 기한
**2026-03-23 오후 중** (FE개발자 투입 계획과 연계)

---

11. 의사결정 트러블슈팅

상황 1: 같은 주제로 반복 의사결정

문제: D-02 (FE 프레임워크)에서 React를 결정했는데,
      D-09에서 다시 프레임워크 선택을 논의

해결:
1. decision_log.md 상호 참조 추가
   - D-09: "D-02 참고, 프레임워크는 확정됨"
2. decision_log.md 연관도 섹션 업데이트
3. 중복 결정 방지 규칙: 의사결정 전 D-번호 검색

상황 2: 의사결정 충돌

문제: D-03 (BE 프레임워크: Node.js)와
      D-04 (데이터베이스: GraphQL)가 충돌

해결:
1. 충돌 분석: GraphQL은 API 방식이지 DB가 아님
2. D-04 취소 및 D-05로 새로 등록 (API 방식: REST vs GraphQL)
3. decision_log.md에 "충돌 이력" 섹션 추가

상황 3: 의사결정 무시

문제: D-02 (React)를 결정했는데,
      개발자가 Vue로 구현 시작

해결:
1. 즉시 중단 지시
2. decision_log.md D-02 다시 공유
3. agent-dispatch에서 명시적으로 decision_log 포함
4. 향후 대책: 투입 시 "다음 D-번호들을 반드시 반영하세요" 강조

---

12. 의사결정 관리 팁

팁 1: decision_log.md는 단일 출처

• 모든 의사결정은 여기에 기록
• CLAUDE.md Section 9, 10는 동기화만 함

팁 2: 상태 필드를 정확히

• ⏳ 대기 중 (확인자 대기)
• ✅ 완료 (확정됨)
• ❌ 취소됨 (변경됨, 히스토리만 남김)

팁 3: 의사결정은 되돌릴 수 있음

• 필요하면 새 D-번호로 "변경" 결정 생성
• 이전 D를 "취소" 처리하기
• 연관도 섹션에서 변경 이력 기록

팁 4: PM과의 커뮤니케이션 정형화

• 요청 형식 일관성 유지
• PM이 빠르게 이해 가능
• 응답 시간 단축

팁 5: decision_log.md는 공개 문서

• 모든 에이전트가 참고해야 함
• agent-dispatch 투입 시 항상 최신 내용 포함
• session-protocol에서 매 세션 시작 시 읽기

---

관련 스킬: session-protocol (의사결정 동기화), agent-dispatch (의사결정 반영)