Post

시작하며

이전 포스트(도메인 전문가와 개발자의 대화법 - Domain Storytelling 소개)에서 Domain Storytelling의 개념과 필요성을 살펴봤습니다. 이번에는 실제로 Domain Story를 어떻게 그리고, 워크샵을 어떻게 진행하는지 구체적으로 알아보겠습니다.

Domain Storytelling의 표기법 (Pictographic Language)

Domain Storytelling은 세 가지 핵심 요소로 구성된 간단한 그림 언어를 사용합니다.

1. 액터 (Actors)

액터는 행동의 주체입니다. 사람, 조직, 시스템 등이 될 수 있습니다.

1
2
3
4
5
6

표기: [사각형 또는 아이콘]
예시: 
- [고객]
- [주문 관리 시스템]
- [배송 담당자]
- [결제 게이트웨이]

액터 선정 팁:

  • 도메인에 맞는 구체적인 이름 사용 (단순히 “사용자”보다는 “영업사원”, “고객”)
  • 시스템도 액터가 될 수 있음
  • 외부 시스템과 내부 시스템 구분 명확히

2. 작업 객체 (Work Objects)

작업 객체는 액터들이 주고받거나 처리하는 정보나 사물입니다.

1
2
3
4
5
6

표기: [직사각형 또는 문서 아이콘]
예시:
- <주문서>
- <재고 정보>
- <승인 요청>
- <송장>

작업 객체 선정 팁:

  • 도메인의 핵심 개념을 반영
  • 너무 기술적이지 않게 (DTO, JSON이 아닌 “주문 정보”, “고객 데이터”)
  • 같은 개념이라도 컨텍스트에 따라 다른 이름 사용 가능

3. 활동 (Activities)

활동은 액터와 작업 객체를 연결하는 화살표로, 동사로 라벨링됩니다.

1
2
3
4
5
6

표기: --동사-->
예시:
- --작성-->
- --승인-->
- --전송-->
- --조회-->

활동 명명 규칙:

  • 능동태 동사 사용
  • 도메인 언어 사용 (“CRUD”가 아닌 “등록”, “수정”, “조회”)
  • 구체적이고 명확하게

완전한 문장 만들기

이 세 요소를 조합하면 자연어처럼 읽히는 문장이 됩니다:

1
2
3

[영업사원] --작성--> <주문서> --제출--> [주문 관리 시스템]

읽기: "영업사원이 주문서를 작성하여 주문 관리 시스템에 제출한다"

문장 번호와 순서

Domain Story는 시간 순서대로 번호를 매깁니다:

1
2
3
4
5

1. [고객] --선택--> <상품>
2. [고객] --추가--> <장바구니>
3. [고객] --확인--> <주문 내역>
4. [고객] --결제--> <주문> --처리--> [결제 시스템]
5. [결제 시스템] --생성--> <영수증> --발송--> [고객]

표기법의 확장 요소

주석 (Annotations)

특정 활동이나 객체에 대한 부가 설명을 달 수 있습니다:

1
2
3
4
5

[고객] --결제--> <주문>
  📝 카드, 계좌이체, 포인트 중 선택

[시스템] --생성--> <송장>
  📝 세금계산서 포함

그룹핑 (Groups)

관련된 활동들을 논리적으로 묶을 수 있습니다:

1
2
3
4
5
6

╔═══════════════════════════╗
║  주문 검증                 ║
║  1. 재고 확인              ║
║  2. 가격 계산              ║
║  3. 배송 가능 여부 확인     ║
╚═══════════════════════════╝

반복 표현

정기적이거나 반복적인 활동을 표시:

1
2

[시스템] --전송--> <일일 리포트> --→ [관리자]
  ⟳ 매일 오전 9시

Domain Storytelling 워크샵 진행 가이드

워크샵 준비

1. 참여자 구성

필수 참여자:

  • 도메인 전문가 2-3명: 실제 업무를 수행하는 사람들 (여러 부서에서 선발)
  • 개발팀 2-4명: 시스템 이해가 필요한 개발자, 아키텍트
  • 모더레이터 1명: 워크샵을 진행하고 이야기를 기록하는 사람

이상적인 워크샵 인원: 5-8명

2. 환경 준비

오프라인 워크샵:

1
2
3
4
5

필요 도구:
✓ 화이트보드 (넓을수록 좋음)
✓ 포스트잇 (여러 색상)
✓ 마커 (굵은 것)
✓ Domain Storytelling 스티커 세트 (선택사항)

온라인 워크샵:

1
2
3
4

필요 도구:
✓ 화상회의 도구 (Zoom, Teams 등)
✓ 협업 도구 (Miro, Egon.io 등)
✓ 화면 공유 환경

3. 시간 배분

1
2
3
4
5
6

2시간 기본 워크샵 구성:
- 10분: 소개 및 Domain Storytelling 설명
- 15분: 첫 번째 이야기 식별
- 60분: 메인 Domain Story 작성 (2-3개)
- 20분: 검토 및 수정
- 15분: 다음 단계 논의 및 정리

워크샵 진행 프로세스

Step 1: 킥오프 (10분)

모더레이터의 역할:

1
2
3
4
5
6
7
8

1. Domain Storytelling 간단 소개
   "우리는 실제 업무 사례를 그림으로 그려볼 것입니다"

2. 표기법 간단 설명
   [액터] --활동--> <작업 객체>

3. 오늘의 목표 명확화
   "주문 접수부터 배송까지의 프로세스 이해"

Step 2: 이야기 시작하기 (15분)

핵심 질문으로 시작:

1
2
3
4
5

❌ 나쁜 질문: "주문 프로세스가 어떻게 되나요?"
✅ 좋은 질문: "지난주에 처리했던 주문 중 기억에 남는 것이 있나요?"

❌ 나쁜 질문: "일반적으로 어떻게 하시나요?"
✅ 좋은 질문: "어제 오전에 들어온 긴급 주문은 어떻게 처리하셨나요?"

모더레이터의 가이드 질문:

  • “누가 이 일을 시작하나요?”
  • “그 다음에는 무슨 일이 일어나나요?”
  • “어떤 정보를 사용하나요?”
  • “누구에게 전달하나요?”

Step 3: 이야기 기록하기 (60분)

실시간 시각화가 핵심입니다.

1
2
3
4

도메인 전문가: "고객이 전화로 주문을 하면..."
모더레이터: [화이트보드에 그리며] "이렇게 되는 건가요?"
             [고객] --전화 주문--> <주문 내역>
도메인 전문가: "네, 맞아요!"

모더레이터가 주의할 점:

  1. 도메인 전문가의 언어 사용
    1
2

    ❌ 나쁜 예: "사용자가 데이터를 입력한다"
✅ 좋은 예: "영업사원이 견적서를 작성한다"
  2. 속도 조절
    • 너무 빠르면 참여자들이 놓침
    • 너무 느리면 집중력 저하
    • 한 번에 3-5개 활동 정도 그린 후 확인
  3. 논쟁 중재 ``` 상황: 두 도메인 전문가가 다른 프로세스를 주장

대응: “두 경우 모두 일어나는 것 같네요. 먼저 A 상황을 그려보고, 그 다음에 B 상황을 별도 이야기로 그려볼까요?”

1
2
3
4
5

**Step 4: 이야기 재확인 (20분)**

완성된 이야기를 처음부터 다시 읽어봅니다:

모더레이터: “처음부터 확인해보겠습니다. 1번, 고객이 웹사이트에서 상품을 선택한다 2번, 고객이 상품을 장바구니에 추가한다 3번…”

참여자들: “잠깐요, 2번에서 재고 확인이 먼저 일어나지 않나요?”

1
2
3
4
5
6
7
8
9
10

**검증 질문:**
- "빠뜨린 단계가 있나요?"
- "순서가 잘못된 부분이 있나요?"
- "모든 도메인 전문가가 동의하시나요?"

**Step 5: 변형 케이스 식별 (15분)**

주석으로 표시된 변형 케이스들을 검토:

“재고가 부족할 때는?” → 별도 이야기로 그릴 만큼 중요한가? → 아니면 주석으로 충분한가?

1
2
3
4
5
6
7
8
9
10
11
12

**판단 기준:**
- 80% 이상 발생하는 일반 케이스: 메인 이야기
- 중요한 예외 케이스: 별도 이야기
- 드문 예외: 주석으로 처리

## 실전 워크샵 시나리오

### 사례: 온라인 쇼핑몰 주문 프로세스

**Step 1: 첫 번째 Domain Story - 정상 주문**

제목: “일반 고객의 정상 주문 처리”

  1. [고객] –검색–> <상품> --조회--> [쇼핑몰 시스템]
  2. [고객] –선택–> <상품> --추가--> <장바구니>
  3. [고객] –확인–> <장바구니> --조회--> [쇼핑몰 시스템]
  4. [쇼핑몰 시스템] –계산–> <총액> --표시--> [고객]
  5. [고객] –입력–> <배송 정보=""> --저장--> [쇼핑몰 시스템]
  6. [고객] –선택–> <결제 수단=""> --요청--> [결제 게이트웨이]
  7. [결제 게이트웨이] –승인–> <결제 결과=""> --전송--> [쇼핑몰 시스템]
  8. [쇼핑몰 시스템] –생성–> <주문> --전송--> [물류 시스템]
  9. [쇼핑몰 시스템] –발송–> <주문 확인="" 이메일=""> --→ [고객]

📝 주석:

  • 5번: 배송지는 기본 주소 또는 새로운 주소
  • 6번: 신용카드, 계좌이체, 간편결제 가능
  • 8번: 재고 차감 자동 처리 ```

Step 2: 두 번째 Domain Story - 재고 부족

워크샵 중 발견:

1
2
3

참여자 A: "재고가 부족하면 어떻게 되나요?"
참여자 B: "고객에게 대체 상품을 제안해요"
모더레이터: "그럼 이걸 별도 이야기로 그려봅시다"

1
2
3
4
5
6
7
8
9
10

제목: "재고 부족 시 대체 상품 제안"

1-3. [이전 이야기와 동일]
4. [쇼핑몰 시스템] --확인--> <재고> --부족 감지-->
5. [쇼핑몰 시스템] --검색--> <유사 상품> --추천--> [고객]
6. [고객] --선택--> <대체 상품> --추가--> <장바구니>
7-9. [정상 프로세스 계속]

📝 주석:
- 5번: 동일 카테고리, 유사 가격대의 상품 자동 추천

발견된 인사이트

워크샵 후 팀이 발견한 것들:

1
2
3
4
5
6
7
8
9
10
11
12

1. 숨겨진 요구사항 발견
   "재고 확인 타이밍이 명확하지 않았어요"
   → 장바구니 추가 시점과 결제 시점에 각각 필요

2. 부서 간 인식 차이
   물류팀: "주문은 바로 처리해요"
   CS팀: "결제 확인 후 30분 뒤에 처리돼요"
   → 실제 프로세스 재확인 필요

3. 시스템 경계 명확화
   [쇼핑몰 시스템]과 [물류 시스템]의 경계
   → 향후 Bounded Context 설계에 활용

모더레이터를 위한 실전 팁

1. 범위 제어

1
2
3
4
5

❌ 너무 넓음: "우리 회사의 모든 주문 프로세스"
✅ 적절함: "웹사이트에서 일반 상품 주문하는 과정"

❌ 너무 좁음: "재고 조회 API 호출"
✅ 적절함: "주문 시 재고 확인 및 예약"

2. 기술 용어 관리

도메인 전문가가 기술 용어를 사용할 때:

1
2
3
4

도메인 전문가: "시스템이 JSON으로 데이터를 보내요"
모더레이터: "어떤 정보를 보내나요?"
도메인 전문가: "주문 내역이요"
모더레이터: [그리며] <주문 내역> 이렇게 표시할게요"

3. 시간 관리

1
2
3
4

각 이야기당 20-30분 목표
- 10분: 이야기 듣고 그리기
- 5분: 검토 및 수정
- 5분: 변형 케이스 논의

30분이 넘어가면:

  • 범위가 너무 넓음 → 두 개로 분리
  • 너무 상세함 → 추상화 레벨 조정

4. 갈등 해결

1
2
3
4
5
6
7
8

상황 1: 부서마다 다른 프로세스
→ 각각 별도 이야기로 그리고 차이점 명확히

상황 2: 이상과 현실의 차이
→ As-Is와 To-Be를 명확히 구분

상황 3: 기술적 논쟁
→ "구현은 나중에, 지금은 업무 흐름만"

워크샵 후속 작업

1. 문서화

1
2
3
4
5

워크샵 결과물:
✓ Domain Story 다이어그램 (사진 또는 디지털 파일)
✓ 주요 용어 목록 (Ubiquitous Language 초안)
✓ 발견된 이슈 목록
✓ 후속 워크샵 주제

2. 공유 및 검증

1
2
3
4
5
6
7
8

1주일 이내:
- 참여자들에게 정리본 공유
- 추가 피드백 수집
- 미참여 이해관계자들에게 공유

2주일 이내:
- 발견된 이슈 해결
- 추가 Domain Story 작성 필요성 평가

3. 다음 단계로 진화

1
2
3
4

Domain Story → Bounded Context 식별
Domain Story → User Story 도출
Domain Story → 시스템 요구사항 정의
Domain Story → Event Storming 진행

자주 하는 실수와 해결책

실수 1: 너무 일찍 추상화

1
2

❌ "일반적으로 고객이 주문을 하면..."
✅ "어제 김 과장님이 긴급 주문을 처리할 때..."

실수 2: 기술 구현에 집중

1
2

❌ "REST API가 JSON을 리턴하고 React가 렌더링..."
✅ "시스템이 주문 결과를 고객에게 표시..."

실수 3: 모든 예외를 한 번에

1
2

❌ 첫 이야기에 모든 if-else 포함
✅ 일반 케이스 → 중요 예외를 별도 이야기로

실수 4: 도메인 전문가 소외

1
2

❌ 모더레이터와 개발자가 주도
✅ 도메인 전문가가 이야기하고 다른 참여자는 경청 및 질문

마치며

Domain Storytelling 워크샵은 도메인 전문가와 개발자가 함께 도메인을 탐험하는 여정입니다. 완벽한 문서를 만드는 것이 목표가 아니라, 서로의 이해를 확인하고 맞춰가는 과정이 핵심입니다.

다음 포스트에서는 디지털 도구인 Egon.io를 활용하여 Domain Story를 더 효율적으로 작성하고 관리하는 방법을 알아보겠습니다.

다음 글 예고

  • [Domain Storytelling #3] Egon.io 도구 활용 - 디지털 도구로 효율적으로 작업하기
  • [Domain Storytelling #4] DDD와의 통합 - Bounded Context와 Ubiquitous Language
  • [Domain Storytelling #5] 실전 적용 전략 - 다른 기법들과 함께 사용하기

참고자료

  • “Domain Storytelling” 책 Chapter 2: Pictographic Language
  • “Domain Storytelling” 책 Chapter 6: Workshop Format
  • Quick Start Guide

여러분의 첫 Domain Storytelling 워크샵 경험을 댓글로 공유해주세요!