dev-goraebap/bigpicture

bigpicture 스킬

ddd-workshop 파이프라인의 빅픽처 이벤트스토밍 단계. 클라이언트 시스템의 도메인 빅픽처 산출물을 1:1로 누적한다.

1. 정체성

빅픽처 이벤트스토밍의 1:1 분석 도구. 그룹 워크샵을 못 하는 환경(SI·소규모·1인)에서 빅픽처 정통 산출물을 한 사람이 만들고 진화시킬 수 있게 한다.

핵심 차별점:

| | 그룹 빅픽처 워크샵 | bigpicture (이 스킬) | |------|------------------|---------------------| | 매체 | 큰 벽 + 포스트잇 | 마크다운 파일 | | 참여자 | 도메인 전문가 + 개발자 + 운영 | 사용자 1명 + AI | | 도메인 지식 | 전문가가 가져옴 | 사전 학습(domain-classroom)에서 빌드업됨 | | 클라이언트 특수성 | 전문가 발화 | 클라이언트 자료 + 사용자 검증 | | 산출물 | 벽 사진·디지털 보드 | docs/eventstorming.md (구조화된 마크다운) |

2. 핵심 원칙

2.1 분석 도구이지 학습 도구가 아니다

학습은 이전 단계 domain-classroom에서 끝났다. 이 스킬은 이미 학습된 도메인을 클라이언트 시스템에 매핑하는 분석 도구.

• 페르소나 시점 서사 ❌ (그건 학습 톤)
• 챕터·장면 단위 ❌ (페이즈 단위로)
• 능동 회상 Q&A는 검증 차원에서만 가벼게 ("이 페이즈에 빠진 이벤트 있나요?")

2.2 빅픽처 정통과 정렬

권위 출처(Brandolini, Vaughn Vernon)의 빅픽처 정식 산출물만 다룬다:

| 산출물 | 빅픽처에 포함 | |--------|------------| | 시간순 도메인 이벤트 | ✅ | | 페이즈 (Phase) | ✅ | | Pivotal Events | ✅ | | 액터 | ✅ | | 외부 시스템 | ✅ | | 핫스팟 | ✅ | | 서브도메인 후보 (그림자) | 🟡 부록 임시 — 다음 스킬로 이전 | | BC 정식 설계 | ❌ Strategic Design 단계 | | Aggregate | ❌ Software Design 단계 | | Ubiquitous Language 정식 | ❌ Context Design 단계 (이벤트·액터에 자연 박힘) | | Command·Policy·Read Model | ❌ Process Modeling 단계 |

2.3 이벤트 표기 — 한국어 자연어 + Code Identifier 이중

권위 출처가 일관 강조: 이벤트는 과거형 + 도메인 전문가 자연어.

🟧 사원 사전 등록됨 `EmployeePreRegistered`
🟧 회원 등록됨 `MemberRegistered`

한국어 자연어가 1차, Code Identifier는 보조. 코드 식별자만 박는 건 Software Design 단계 표기.

2.4 도메인 이벤트 판별 4기준 (필수)

이벤트 표에 넣기 전 4기준을 통과해야 한다. UI/Telemetry/기술 이벤트 혼입 방지.

| # | 질문 | 통과 | |---|------|------| | 1 | 도메인 전문가가 관심 있어 하나? | 인사담당자가 신경 쓸 일인가? | | 2 | 비즈니스 상태가 영구 변했나? | DB 영구 변화? 외부 약속 발생? | | 3 | 법적·규제적 의미가 있나? | 개인정보·계약·결제 등 | | 4 | 다른 흐름의 트리거가 되나? | 후속 액터·시스템 행동 유발? |

2개 이상 ✅ = 도메인 이벤트. 1개 이하면 혼입 위험.

배제 예시:

• ❌ "회원가입 폼 진입함" — UI 이벤트 (분석·UX용)
• ❌ "유효성 검증 통과됨" — 기술 이벤트 (시스템 내부)
• ❌ "버튼 클릭됨" — UI 이벤트
• ✅ "회원 등록됨" — 비즈니스 사실
• ✅ "결제 승인됨" — 외부 약속 + 법적 의미

3. 언제 트리거하는가

• /ddd-workshop:bigpicture
• "이 도메인 빅픽처 만들어줘", "이벤트스토밍 정리"
• domain-classroom에서 학습 완료 후 자연스럽게 다음 단계
• 코드 작성 중·작성 후 빅픽처 갱신이 필요할 때 (Cycle 모드)

domain-classroom 산출물 없이 단독 사용도 가능 (자동 fallback). 다만 학습이 안 된 도메인은 핫스팟이 폭발할 수 있음.

4. 입력 정책

4.1 입력 우선순위

| # | 입력 | 활용 | |---|------|------| | 1 | domain-classroom 산출물 (docs/learning-notes/{도메인}-classroom.md) | 페이즈·일반 액터·법령 자동 추출 | | 2 | 클라이언트 자료 (RFP·요구사항정의서·기존 스키마) | 클라이언트 특수성·시스템 범위 | | 3 | 사용자 발화 | 위 둘에서 누락된 정보 |

4.2 자동 감지

• domain-classroom 산출물이 docs/learning-notes/ 아래 있으면 자동 읽기
• 없으면 사용자에게 "학습 단계 거치셨나요?" 물어보고, 없으면 단독 진행
• 클라이언트 자료가 명시 입력되면 도메인 식별·범위 좁히기·페이즈 우선순위에 활용

4.3 자료에서 무엇을 추출하는가

| 자료 | 추출 | |------|------| | domain-classroom | 보편 페이즈 목록 + 일반 액터 + 관련 법령·표준 | | 클라이언트 RFP | 시스템 범위 (예: "채용은 안 다룸") + 도입 동기 + 기존 시스템 마이그레이션 여부 | | 기존 스키마·코드 | 실제 사원/주문 같은 엔티티명, 기존 사용 용어 (UL 씨앗) |

5. 진행 절차

Step 1 — 산출물 모드 감지 (Initial / Update / Cycle)

| 모드 | 트리거 | 동작 | |------|--------|------| | Initial | docs/eventstorming.md 없음 | 새로 만들기 | | Update | 파일 있음 + 동일 세션에서 추가 입력 | 변경분 누적 | | Cycle | 파일 있음 + 시간 지난 후 다시 호출 (코드 작성 후 등) | 기존 파일 + 새 발견 사항 → 갱신 |

자동 감지. 사용자가 명시적으로 "새로 시작"을 요청하면 Initial로 강제 가능.

Step 2 — 도메인 윤곽 매핑 (Initial 모드만)

domain-classroom 산출물 + 클라이언트 자료를 읽어 다음을 정리:

• 도메인의 페이즈 후보 (학습 노트의 페이즈 메뉴 + 클라이언트 시스템 범위)
• 이 시스템이 다루는 페이즈 vs 다루지 않는 페이즈 (사용자 확인)
• 주요 액터 (보편 + 클라이언트 특수)
• 외부 시스템
• 관련 법령·표준 (학습 노트에서 가져옴)
• 도메인 윤곽 한 화면 요약

사용자 확인 후 다음 단계.

Step 3 — 페이즈 단위 누적

페이즈 하나씩 다음을 채운다:

### 페이즈 N: {페이즈명}

**한 줄 핵심**: {이 페이즈에서 일어나는 일 한 줄}

**시간순 이벤트** (도메인 이벤트 4기준 통과한 것만):
| # | 이벤트 (한국어, 과거형) | Code Identifier | 액터 | 비고 |
|---|----------------------|----------------|------|------|
| 1 | ⭐ 사원 사전 등록됨 | `EmployeePreRegistered` | 인사담당자 | 페이즈 시작점 |
| 2 | 🟧 ... | `...` | ... | |

**페이즈 핫스팟** (이 페이즈에 국한된 것만):
- H1 [확실: 노무] {핫스팟}
- H2 [추측] {핫스팟}

(절 분리 옵션 — 영속 흐름 vs 1회성 백필 같은 별도 흐름이면)
**절 A. {흐름 이름}**: ...
**절 B. {흐름 이름}**: ...

한 응답에 한 페이즈까지만. 검증 후 다음 페이즈.

Step 4 — 페이즈 검증 인터랙션

페이즈 끝에 사용자에게:

1. 빠진 이벤트가 있나요? (사용자 경험·관찰 기준)
2. 이게 정말 도메인 이벤트인가요? (UI/기술 이벤트 의심)
3. 새 핫스팟 추가할 게 있나요?
4. 다음 페이즈로 / 더 깊게 / 멈추기

답 안 해도 다음으로 진행 가능.

Step 5 — 횡단 정리 (페이즈가 2개 이상 누적되면)

페이즈 단위 정보가 누적되면 횡단 매트릭스를 갱신:

• 액터 매트릭스 (액터 → 등장 페이즈)
• 외부 시스템 매트릭스
• 누적 핫스팟 (전체 정렬, ID·페이즈·답할 위치·확신도)
• (부록) UL 메모 — 이벤트·액터에서 도출된 핵심 용어 (다음 스킬로 이전 예정)
• (부록) 서브도메인 후보 — 페이즈 클러스터링으로 자연 도출

Step 6 — 산출물 갱신 정책

각 페이즈 끝에 사용자에게 한 줄 확인:

"이번 페이즈를 docs/eventstorming.md에 갱신할까요? (y / 다른 경로 / 저장 안 함)"

자동 누적 — 파일 있으면 변경분 추가, 없으면 새로 생성.

Step 7 — Cycle 모드 (코드 작성 후 사이클)

코드 작성 후 다시 호출되면:

1. 기존 docs/eventstorming.md 읽기
2. 사용자에게 "어떤 변화가 있었나요?" 묻기
   • 새 이벤트?
   • 페이즈 분리·통합?
   • 핫스팟 해결·새 발견?
3. 변경분만 갱신
4. 변경 이력 자동 메모 (선택)

6. 산출물 구조

6.1 파일 위치

docs/eventstorming.md          ← 단일 파일 (빅픽처만 있을 때)

후속 스킬(process-modeling·software-design) 도입 시 자동 분리:

docs/eventstorming/
├── index.md                   ← 메타·진도·전체 요약
├── bigpicture.md              ← 이 스킬 산출물
├── process-modeling.md        ← 미래 (Process Modeling 스킬 추가 시)
└── software-design/           ← 미래
    └── ...

분리 트리거: process-modeling 스킬이 처음 실행될 때.

6.2 산출물 구조 (6섹션 + 부록)

# {도메인명} — Big Picture

> {도메인 1줄 요약}

> **소스 정책**: 이 문서가 도메인 진실. 코드는 판단 보조 용도.
> 두 곳이 충돌하면 빅픽처 합의를 우선하고 코드는 후속 작업으로 정렬.

## 1. 도메인 윤곽
- 페이즈 (시간축)
- 주요 액터 (보편 + 클라이언트)
- 외부 시스템
- 관련 법령·표준
- 도메인 특수성

## 2. 페이즈 맵 (시간선 한 줄)
[페이즈1] → [페이즈2] → [페이즈3] → ...

## 3. 페이즈별 상세
### 페이즈 1: {이름}
- 한 줄 핵심
- 시간순 이벤트 표 (이중 표기)
- 페이즈 핫스팟

### 페이즈 2: ...

## 4. 🟨 액터 매트릭스 (페이즈 횡단)
| 액터 | 시스템 정체 | 등장 페이즈 |

## 5. 🟥 외부 시스템 (페이즈 횡단)
| 시스템 | 용도 | 의존 강도 | 등장 페이즈 |

## 6. 🟪 누적 핫스팟 (검증·결정 필요)
| ID | 핫스팟 | 페이즈 | 답할 위치 | 확신도 |

---

## (부록) 다음 단계 이전 예정

> 빅픽처에 포함되지 않는 항목. 다음 스킬에서 정식 자리로 이전.

### A. UL 메모 (이벤트·액터에서 도출된 용어)
| 한국어 | Code Identifier | 의미 |
→ 향후 context-design 또는 Software Design 단계로 이전

### B. 서브도메인 후보 (페이즈 클러스터링)
- ...
→ 향후 subdomain-classifier 또는 Strategic Design 단계로 이전

7. Anti-patterns (절대 하지 말 것)

• 페르소나 시점 서사 — 학습 톤. 이 스킬은 분석. 페르소나 X
• 챕터·장면 단위 — 페이즈 단위가 정통
• UI/Telemetry/기술 이벤트 혼입 — 4기준 통과 필수 ("회원가입 폼 진입함" ✗ / "회원 등록됨" ✓)
• 현재형 이벤트 — 반드시 과거형 ("등록한다" ✗ / "등록됨" ✓)
• 코드 식별자만 — 한국어 자연어 1차, Code Identifier 보조
• UL·BC·Aggregate를 정식 섹션으로 — 다음 단계의 일. 부록으로만
• Command·Policy·Read Model 추가 — Process Modeling 단계
• 상태 머신·aggregate insert 같은 디자인 정보 — Software Design 단계
• 클라이언트 자료를 그대로 베끼기 — 도메인 이벤트로 변환해야 함
• 페이즈 한 응답에 여러 개 욱여넣기 — 한 응답 = 한 페이즈
• 사용자 확인 없이 산출물 갱신 — 페이즈 끝마다 한 줄 확인
• Initial 모드 강제 — 기존 파일 있으면 자동 누적이 기본

8. 사이클 정책 — 살아있는 산출물

빅픽처는 한 번 만들고 끝이 아니다. 코드 작성 중·후에도 사이클을 돈다:

• 빅픽처는 가장 적게 변함 — 큰 페이즈·핫스팟 발견될 때만 갱신
• 변경 사이클 트리거:
  • 새 비즈니스 요구사항 추가
  • 코드 작성 중 새 핫스팟 발견
  • 클라이언트 인터뷰에서 가정 검증 (확신도 [추측] → [확실])
  • 후속 단계(process-modeling·software-design)에서 빅픽처 모순 발견 → 역방향 갱신

각 사이클은 Update 모드로 진입. 사용자가 원하면 변경 이력을 산출물 끝에 자동 기록.

9. 짧은 예시 (호호컴퍼니 HR)

사용자: "/bigpicture"

→ Step 1: Initial 모드 감지 (eventstorming.md 없음)

→ Step 2: 도메인 윤곽 매핑
   - docs/learning-notes/hr-classroom.md 자동 읽기 (학습 완료 상태)
   - 사용자 클라이언트 자료 입력 받음 (RFP 또는 요구사항)
   - 페이즈 후보: 온보딩, 인사기록, 근태·휴가, 퇴직
   - 시스템 범위: 채용 X (외부), 급여 X (별도 시스템)
   - 사용자 확인 → 진행

→ Step 3: 페이즈 1 (온보딩)
   - 시간순 이벤트 (4기준 통과):
     ⭐ 사원 사전 등록됨 `EmployeePreRegistered`
     ⭐ 사원 활성화됨 `EmployeeActivated`
     🟧 사원 첫 로그인 완료됨 `EmployeeFirstLoggedIn`
     ...
   - 페이즈 핫스팟:
     H1 [추측: 운영] 초대 만료 정책

→ Step 4: 검증 — "빠진 이벤트 있나요?"
→ Step 6: 갱신 확인 → docs/eventstorming.md 생성

→ Step 3 (반복): 페이즈 2 (근태·휴가)
   ...

→ Step 5: 횡단 매트릭스 갱신 (페이즈 2개 누적된 시점)

→ ... 사이클 시작

10. 한 줄로 정리

빅픽처 이벤트스토밍을 1:1 환경에서 분석 도구로 운영. 학습은 domain-classroom에서 끝났고, 여기는 클라이언트에 매핑하는 곳. 페르소나·챕터·서사 없이, 페이즈와 이벤트 그리고 4기준만으로 정통과 정렬.