시작하며

IT 시스템 구축 프로젝트에서 가장 큰 어려움 중 하나는 도메인 전문가와 개발팀 간의 커뮤니케이션입니다. 요구사항을 수집하고 문서화하는 과정에서 서로 다른 언어를 사용하며, 결과적으로 잘못된 이해로 인한 재작업이 빈번하게 발생합니다.

이번 시리즈에서는 이러한 문제를 해결하기 위한 협업 모델링 기법인 Domain Storytelling에 대해 다룹니다. 첫 번째 포스트에서는 Domain Storytelling이 무엇이고, 왜 필요한지 알아보겠습니다.

Domain Storytelling이란?

Domain Storytelling은 도메인 지식을 효과적인 비즈니스 소프트웨어로 변환하기 위한 협업 모델링 기법입니다. 도메인 전문가와 개발팀이 함께 모여 비즈니스 프로세스를 “이야기”로 풀어내고, 이를 그림 언어(pictographic language)로 시각화합니다.

핵심 특징

1. 시나리오 기반 모델링

Domain Storytelling은 추상적인 프로세스 플로우가 아닌 구체적인 사례를 다룹니다. “일반적으로 어떻게 하나요?”가 아닌 “지난주 화요일에 김 과장님이 어떻게 처리하셨나요?”라는 질문으로 시작합니다.

1
2

잘못된 접근: "고객이 주문을 할 수 있고, 결제가 실패하면..."
올바른 접근: "어제 박 대리가 급한 주문을 처리할 때, 재고가 부족해서..."

2. 즉각적인 피드백 루프

모더레이터가 도메인 전문가의 이야기를 듣고 실시간으로 그림으로 기록합니다. 도메인 전문가는 화면이나 화이트보드에 그려지는 내용을 보면서 “네, 맞습니다” 또는 “아니요, 그게 아니라…“라고 즉시 피드백할 수 있습니다.

3. 자연어에 가까운 표현

그림으로 만들어진 문장들은 자연어처럼 읽힙니다.

1
2

"영업사원이 주문서를 작성하여 ERP 시스템에 등록한다"
→ [영업사원] --작성--> [주문서] --등록--> [ERP 시스템]

왜 Domain Storytelling인가?

전통적인 요구사항 분석의 한계

전통적인 요구사항 문서나 유스케이스 다이어그램은 다음과 같은 문제가 있습니다:

문제 1: 추상화의 함정

1
2
3
4

유스케이스: "주문 처리"
- 사용자가 주문을 생성한다
- 시스템이 재고를 확인한다
- 시스템이 결제를 처리한다

이 정도의 추상화로는 실제 업무에서 일어나는 다양한 상황을 제대로 파악할 수 없습니다. 재고가 부족할 때는? 결제가 실패할 때는? 급한 주문일 때는?

문제 2: 조기 의사결정의 위험

프로세스 플로우 다이어그램은 if-then-else 분기를 너무 일찍 도입합니다. 아직 도메인을 충분히 이해하지 못한 상태에서 모든 예외 상황을 다이어그램으로 표현하려다 보면 복잡도만 증가하고 핵심을 놓치게 됩니다.

문제 3: 일방향 커뮤니케이션

전통적인 방식은 대부분 개발자나 분석가가 듣고 기록한 후, 나중에 문서로 만들어 검토를 요청하는 형태입니다. 이 과정에서 오해가 발생해도 늦게 발견됩니다.

Domain Storytelling의 해결책

해결책 1: 구체적 사례로 시작

추상화는 나중에 합니다. 먼저 실제로 일어난 구체적인 사례들을 여러 개 모델링하고, 그 다음에 공통점과 차이점을 파악합니다.

1
2
3

이야기 1: "정상적인 주문 처리"
이야기 2: "재고 부족 시 대체품 제안"
이야기 3: "VIP 고객의 긴급 주문"

각 이야기를 개별적으로 그려본 후, 80%의 일반적인 케이스와 중요한 변형 케이스를 식별합니다.

해결책 2: 공동 창작

워크샵 참여자 전체가 이야기를 함께 만들어갑니다. 한 부서의 전문가가 말한 내용을 다른 부서 전문가가 보완하거나 수정하면서 진짜 프로세스가 드러납니다.

해결책 3: 점진적 정제

한 번에 완벽한 프로세스를 그리려 하지 않습니다. 대략적인 큰 그림(Big Picture) 이야기를 먼저 만들고, 필요한 부분을 더 상세한(fine-grained) 이야기로 나눠서 그립니다.

IT 시스템 구축 프로젝트에서의 활용

프로젝트 초기: 도메인 이해

프로젝트 초기에 Domain Storytelling 워크샵을 진행하면:

• 도메인 지식 전파: 개발팀이 도메인 전문가의 업무를 빠르게 이해
• 숨겨진 요구사항 발견: 문서로는 드러나지 않던 암묵지 파악
• 팀 간 언어 통일: Ubiquitous Language의 기반 마련

시스템 분석: 경계 식별

복잡한 도메인을 다룰 때 Domain Storytelling은 Bounded Context의 경계를 찾는 데 유용합니다. 이야기를 그리다 보면 자연스럽게 다음과 같은 경계 지표들이 나타납니다:

• 서로 다른 업무 리듬: 일 단위로 처리되는 업무와 실시간으로 처리되는 업무
• 다른 담당자: 부서나 역할이 바뀌는 지점
• 용어의 불일치: 같은 단어가 다른 의미로 사용되는 지점

As-Is / To-Be 분석

기존 시스템(As-Is)과 목표 시스템(To-Be)을 각각 Domain Story로 그려서 비교할 수 있습니다:

1
2

As-Is: "영업사원이 전화로 주문을 받아 수기로 작성한 후 팩스로 보낸다"
To-Be: "고객이 모바일 앱으로 직접 주문하고 실시간으로 확인한다"

이런 비교를 통해 새로운 시스템이 비즈니스 프로세스를 어떻게 변화시킬지 명확하게 보여줄 수 있습니다.

다른 기법들과의 비교

vs. UML Use Case Diagram

vs. BPMN

vs. Event Storming

두 기법은 상호 보완적입니다. Event Storming이 도메인 이벤트를 빠르게 발견하는 데 강점이 있다면, Domain Storytelling은 프로세스의 흐름과 맥락을 이해하는 데 유용합니다.

많은 팀이 Event Storming으로 전체 도메인 이벤트를 파악한 후, Domain Storytelling으로 구체적인 프로세스를 정리합니다.

실제 적용 사례

케이스 1: 영화관 티켓 예매 시스템

작은 아트하우스 영화관 Metropolis의 관리자 Matthew는 고객들이 온라인으로 티켓을 구매하길 원했습니다. Domain Storytelling 워크샵을 통해:

• 외국어 영화의 자막 처리 요구사항 발견
• 영화 상영 스케줄의 복잡성 이해
• 소규모 영화관의 특수한 요구사항 파악

처음에는 “간단한 예매 시스템”으로 생각했던 것이 실제로는 여러 복잡한 요소를 포함하고 있음을 발견했습니다.

케이스 2: 리스 회사 프로세스

Domain Storytelling 책에서 다루는 Alphorn 자동차 리스 회사 사례는 다음을 보여줍니다:

• 거시적 레벨(coarse-grained)의 전체 운영 프로세스
• 세부 서브도메인: 결제, 제안, 리스크 평가
• 각 레벨에서의 Bounded Context 식별

마치며

Domain Storytelling은 단순한 모델링 기법이 아니라 도메인 전문가와 개발자가 함께 도메인을 탐험하는 방법입니다.

다음 포스트에서는 Domain Storytelling의 구체적인 표기법과 워크샵 진행 방법에 대해 알아보겠습니다.

다음 글 예고

• [Domain Storytelling #2] 표기법과 워크샵 가이드 - 실제로 어떻게 그리고 진행하는가
• [Domain Storytelling #3] Egon.io 도구 활용 - 디지털 도구로 효율적으로 작업하기
• [Domain Storytelling #4] DDD와의 통합 - Bounded Context와 Ubiquitous Language
• [Domain Storytelling #5] 실전 적용 전략 - 다른 기법들과 함께 사용하기

참고자료

• domainstorytelling.org - 공식 웹사이트
• “Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software” by Stefan Hofer and Henning Schwentner
• Egon.io - 오픈소스 Domain Story 모델러

이 포스트는 Domain Storytelling 시리즈의 첫 번째 글입니다. 실무에서 Domain Storytelling을 적용해보신 경험이 있다면 댓글로 공유해주세요!