C레벨 명세서 발급 + 에스컬레이션 플로우

CEO가 프로젝트 스펙을 판단하고 C레벨에 명세서를 발급, C레벨이 하위 부서에 task를 분해 위임하는 계층형 의사결정 구조.

1. 전체 흐름

[CEO]
  │
  ├─ 프로젝트 스펙 판단 (CTO와 협의 가능)
  │
  ▼
[C레벨 명세서 발급]
  CEO → COO 명세서
  CEO → CTO 명세서
  CEO → CMO 명세서 (scale+)
  CEO → CFO 명세서 (scale+)
  CEO → CPO 명세서 (scale+)
  CEO → CISO 명세서 (scale+)
  │
  ▼
[C레벨 → 하위 task 분해]
  각 C레벨이 받은 명세서를 세분화하여
  산하 워커 에이전트에게 task 부여
  │
  ├─ 이슈 없음 → 병렬 실행
  │
  ├─ 부서 내 이슈 발생
  │     └─ [부서 내 토론] → 자율 해결
  │           └─ 해결 불가 → Level Up ↓
  │
  ├─ C레벨 결재 필요 이슈
  │     └─ [C레벨 간 토론] (CTO/CEO 포함)
  │           └─ 해결 불가 → Level Up ↓
  │
  └─ 회장 결재 필요
        └─ [회장 결재 대기 큐] → 회장 응답 후 재개

2. C레벨별 문서 체계

각 C레벨은 명세서 외에 대기업 표준 PM 문서를 동일하게 작성하며, 전체 문서는 Consigliere에 인덱싱되어 에이전트 검색 컨텍스트로 활용된다.

2.1 공통 문서 (전 C레벨)

2.2 C레벨별 추가 문서

2.3 디렉토리 구조

archi/{프로젝트명}/
  ├── specs/
  │   ├── cto-spec.md
  │   ├── cto-wbs.md
  │   ├── cto-gantt.md
  │   ├── cto-raci.md
  │   ├── cto-risk.md
  │   ├── cto-status.md       ← Evaluator 완료 시 자동 갱신
  │   ├── cto-adr.md
  │   ├── cto-tech-debt.md
  │   ├── coo-spec.md
  │   ├── coo-wbs.md
  │   ├── coo-gantt.md
  │   ├── coo-raci.md
  │   ├── coo-risk.md
  │   ├── coo-status.md
  │   ├── coo-sla.md
  │   ├── coo-playbook.md
  │   ├── ... (CMO, CFO, CPO, CISO)
  │   ├── tasks/
  │   │   ├── cto-tasks.md    ← 진행률 파싱 기준
  │   │   ├── coo-tasks.md
  │   │   └── ...
  │   └── progress.json       ← 서버 자동 갱신
  └── ...

2.4 문서 포맷 표준

WBS 예시 (cto-wbs.md):

# CTO WBS — StreamApp

## 1. iOS 개발
  ### 1.1 스캐폴딩
    - 1.1.1 프로젝트 구조 생성
    - 1.1.2 pbxproj 생성
  ### 1.2 핵심 기능
    - 1.2.1 로그인 화면
    - 1.2.2 영상 스트리밍 뷰
## 2. Android 개발
  ...

간트차트 예시 (cto-gantt.md):

# CTO 간트차트 — StreamApp

| Task | 담당 | W1 | W2 | W3 | W4 |
|------|------|----|----|----|-----|
| iOS 스캐폴딩 | ios_dev | ██ | | | |
| API 설계 | api_dev | ██ | ██ | | |
| Android 스캐폴딩 | android_dev | | ██ | | |
| 빌드 검증 | qa | | | ██ | |

RACI 예시 (cto-raci.md):

| Task | CTO | ios_dev | android_dev | api_dev | qa |
|------|-----|---------|-------------|---------|-----|
| 아키텍처 설계 | A | C | C | C | I |
| iOS 구현 | R | A | I | C | I |
| 빌드 검증 | I | C | C | I | A |

(R=Responsible, A=Accountable, C=Consulted, I=Informed)

3. 명세서 발급 규칙

2.1 발급 주체

2.2 명세서 구조

[SPEC-{C레벨}-{프로젝트명}-{날짜}]

목표: (1-2문장. 무엇을 달성해야 하는가)
범위: (담당 도메인. 다른 C레벨 영역 침범 금지)
제약:
  - 기술 제약 (예: iOS 14+, Android API 23+)
  - 예산/비용 제약 (CFO 협의 필요 시 명시)
  - 타임라인
우선순위: CRITICAL / HIGH / MEDIUM / LOW
의존성: (다른 C레벨 명세서와의 의존 관계)
결재 기준: (어떤 경우에 회장 결재가 필요한가)

2.3 명세서 저장 위치

archi/{프로젝트명}/specs/
  ├── cto-spec.md
  ├── coo-spec.md
  ├── cmo-spec.md   (scale+)
  ├── cfo-spec.md   (scale+)
  └── ...

3. 하위 task 분해

각 C레벨은 받은 명세서를 산하 워커에게 task로 분해하여 위임한다.

CTO 명세서 → CTO가 분해
  ├── sys_arch: "아키텍처 설계서 작성"
  ├── be_lead: "API 설계 + 백엔드 구현"
  ├── ios_dev: "iOS 클라이언트 구현"
  ├── android_dev: "Android 클라이언트 구현"
  └── qa: "빌드 검증 + 테스트"

분해 기준:

• 각 워커의 역할 경계를 명확히 지정
• 의존 순서가 있으면 명시 (A 완료 후 B 착수)
• 병렬 가능한 task는 병렬로 실행

4. 에스컬레이션 체계

Level 1 — 부서 내 토론 (자율 해결)

발동 조건: 워커 간 기술 의견 충돌, 구현 방식 이견

프로세스:

1. 해당 C레벨 주관으로 부서 내 debate 실행
2. 기존 SELF_DEBATE 인프라 재사용
3. 합의 도출 → 진행
4. 합의 실패 → Level 2 에스컬레이션

시간 제한: 2라운드 이내 합의 없으면 자동 에스컬레이션

Level 2 — C레벨 간 토론

발동 조건:

• 2+ C레벨 도메인에 걸친 결정
• 예산/보안/제품 방향 변경 수반
• 부서 내 토론 합의 실패

프로세스:

1. 관련 C레벨 소집 (최소 CTO 포함)
2. 기존 Multi-C레벨 토론 인프라 (I74) 재사용
3. 합의 도출 → DELEGATE 재조정 후 진행
4. 합의 실패 → Level 3 에스컬레이션

시간 제한: 3라운드 이내 합의 없으면 자동 에스컬레이션

Level 3 — 회장 결재 대기

발동 조건:

• C레벨 간 토론 합의 실패
• 초기 명세서 범위 초과 변경 필요
• 예산 초과 예상

프로세스:

1. 이슈 요약 + 선택지 2-3개 정리하여 회장에게 보고
2. 해당 task 일시 중단 (다른 병렬 task는 계속)
3. 회장 응답 수신 → 지정 선택지로 재개

보고 형식:

[회장 결재 요청]
이슈: (1-2문장)
배경: (왜 발생했는가)
선택지:
  A. (내용) → 예상 영향
  B. (내용) → 예상 영향
  C. (내용) → 예상 영향
권고: (C레벨 권고안, 있는 경우)

5. "진행" 바 연동

GameStatsBar의 진행 바는 이 명세서 발급 체계와 연동된다.

진행 = 발급 완료된 C레벨 명세서 수 / 현재 Phase 전체 C레벨 수

저장 위치: stats 테이블 issued_specs 컬럼 (서버가 증분)

6. 전체 작업량 백분율 계산

6.1 개념

전체 명세서 파일(C레벨 spec + 하위 task 파일)을 파싱하여 MVP 포함 전체 스케일업의 작업량을 백분율로 환산한다.

진행률(%) = 완료된 task 수 / 전체 task 수 × 100

6.2 파싱 대상

archi/{프로젝트명}/specs/
  ├── cto-spec.md          ← C레벨 명세서 (상위)
  ├── coo-spec.md
  ├── cmo-spec.md
  ├── tasks/
  │   ├── cto-tasks.md     ← C레벨이 분해한 워커 task 목록
  │   ├── coo-tasks.md
  │   └── ...
  └── progress.json        ← 서버가 자동 갱신하는 진행 상태

6.3 task 완료 판별 기준

task 파일은 마크다운 체크박스 형식 사용:

- [ ] iOS 로그인 화면 구현        ← 미완료
- [x] Android 스캐폴딩 생성       ← 완료
- [ ] API /auth/login 엔드포인트  ← 미완료

서버가 Evaluator 완료 시 해당 task를 [x]로 자동 마킹.

6.4 progress.json 구조

{
  "project": "StreamApp",
  "phase": "mvp",
  "updated_at": "2026-04-10T12:00:00Z",
  "total": 45,
  "completed": 12,
  "percent": 26.7,
  "by_clevel": {
    "cto": { "total": 28, "completed": 8 },
    "coo": { "total": 17, "completed": 4 }
  }
}

6.5 GameStatsBar "진행" 바 연동

iOS GameStatsBar의 진행 바:

value = progress.json.completed
max   = progress.json.total
표시  = "12/45" (26.7%)

서버 /api/stats 에서 progress.json 파싱 결과 포함 반환. 폴링: 60초 (작업 중일 때만 의미 있는 변화)

7. Consigliere 문서화 강제 집행

에이전트는 컨텍스트 한계로 인해 문서화를 건너뛸 수 있다. Consigliere가 능동적으로 각 에이전트에게 개별 문서화를 요청한다. 상세 설계: docs/spec/consigliere.md §12

7.1 발동 조건

7.2 요청 원칙

• 브로드캐스트 금지. 각 에이전트에게 개별 타겟 요청.
• 요청 내용: 역할에 맞는 문서 목록 특정 + 파일 경로 명시.
• 컨텍스트 부족 응답 시: 기존 문서 Top-3 주입 후 재요청.
• 3회 실패 시: 회장 수동 확인 요청.

7.3 누락 감지 체크리스트

각 C레벨마다 아래 문서 존재 여부 + 마지막 갱신 시각(24h 기준) 검사:

8. 구현 우선순위

변경 이력