📌 이벤트 스토밍(Event Storming)이란 무엇인가?

이벤트 스토밍은 사람들을 모으고 소프트웨어를 분할하는 것으로, 다양한 배경의 사람들이 같은 테이블에 모여 함께 모델링하며 비즈니스, 프로세스 디자인, 사용자 경험, 소프트웨어 등 다양한 관점을 동일한 기반 위에 설계하는 방법입니다

💡 이벤트 스토밍의 핵심 요소는 무엇인가?

• 도메인 이벤트: 과거 시제로 작성되며, 특정 시점의 상태 변화를 나타내고 다음 행동의 트리거 역할을 합니다

• 정책: 이벤트와 후속 조치 사이의 연결 고리 역할을 합니다

• 읽기 모델: 사용자가 특정 결정을 내리는 데 필요한 정보를 물리적으로 표현한 것입니다

이 컨텐츠는 이벤트 스토밍(event storming)이라는 방법론을 통해 복잡한 비즈니스 도메인을 이해하고 소프트웨어 설계를 개선하는 방법을 설명합니다. 이벤트 스토밍은 다양한 이해관계자들이 함께 모여 비즈니스 이벤트를 시간 순서대로 시각화함으로써 숨겨진 문제점과 바운디드 컨텍스트(Bounded Context)를 발견하고, 이를 통해 조직의 정렬과 핵심 문제 해결에 집중할 수 있도록 돕습니다. 이 방법은 특히 도메인 주도 설계(DDD)에서 효과적으로 활용될 수 있습니다.

1. 도메인 전문가와의 협업의 한계와 중요성

• 소프트웨어 개발에서 도메인 전문가와의 창의적 협업과 대화가 매우 중요함

  • 하지만 도메인 전문가가 항상 모든 지식을 갖고 있거나, 조직 전체를 이해하는 것은 아님

    • 각자 자신의 '사일로(분절된 영역)'에만 전문성을 가짐

    • 일부 영역은 아무도 모를 수 있음, 퇴사 등으로 지식이 사라지기도 함

  • 소프트웨어 개발자는 단순히 요구사항을 번역하는 역할이 아님

  • 문제 도메인에 대한 지식은 복잡하고, 바로 소프트웨어로 전환할 수 없음

• 조직 내 지식의 분절과 불일치가 존재함

2. 바운디드 컨텍스트와 지식 분절의 연결고리

• 바운디드 컨텍스트(경계가 명확한 모델의 영역)는 조직 내 지식의 분절과 밀접한 관련이 있음

  • 여러 모델이 협력하여 하나의 목표를 달성함

  • 바운디드 컨텍스트를 식별하는 것은 여전히 모호함

• 이 강연의 목적: 이 연결고리를 이해하고, 바운디드 컨텍스트의 실마리를 찾는 것

3. 복잡한 도메인에서의 진짜 문제: 빠른 이해

• 복잡한 도메인에서는 코딩 속도가 아니라, 문제의 복잡성을 빠르게 이해하는 것이 핵심

  • 빠른 코딩 도구는 많지만, '올바른 소프트웨어'를 빠르게 만드는 도구는 부족함

• Event Storming은 이 문제를 해결하는 데 도움을 줌

4. Event Storming의 다양한 레시피와 빅픽처 워크숍

• Event Storming은 하나의 방식이 아니라, 상황에 따라 다양한 레시피가 존재함

• 가장 큰 포맷: 빅픽처 워크숍

  • 다양한 이해관계자(비즈니스, IT, UX, 고객 등) 최대 20~30명(경우에 따라 70명까지) 참여 가능

  • 넓은 벽(15~18미터)에 무제한처럼 보이는 공간과 많은 마커, 스티커 사용

  • 전체 프로세스를 한눈에 볼 수 있도록 함

• 진행 방법

  • 왼쪽에서 오른쪽으로 시간의 흐름(타임라인) 설정

  • 도메인 이벤트(과거 시제, 주황색 스티커)로 모든 흐름을 모델링

    • 과거 시제를 쓰는 이유: 특정 시점의 상태 변화를 명확히 인식하게 함

  • 처음엔 혼란스럽고 조용하지만, 점차 참가자들이 자신의 관점을 벽에 붙이며 대화가 시작됨

    • 서로 다른 시각, 의견 충돌, 논쟁 등도 색깔, 코멘트 등으로 시각화

  • 공식 스토리와 코멘트, 마찰점 모두 모델의 일부

5. 구조화와 다양한 관점의 통합

• 참가자들이 더 많은 구조를 원할 때, 행위자(사람), 시스템 등 추가

  • 외부 시스템은 제약을, 다양한 사용자 유형은 논의의 깊이를 더함

  • 예: 기업 고객과 개인 고객의 행동 차이 등

• 탐색적(Discovery) 단계로, 어떤 대화가 나올지 예측 불가

• 실제 컨퍼런스 조직 예시: 키노트 연사, 초대 인사, 장소, 후원사, 물류 등 다양한 흐름이 한눈에 보임

• 결과: 크고, 화려하며, 하루 만에 많은 일이 시각화됨

6. 빅픽처 워크숍의 주요 효과

• 모든 프로세스가 가시화되어 숨겨진 부분이 없음

  • 12~18미터의 벽에 모든 것이 드러남

  • 18미터를 넘으면 조직이 자체 무게로 붕괴할 수 있음(비유)

• 사일로 간 이해 증진: 다른 부서의 복잡성을 처음 알게 되는 경우 많음

  • "내가 upstream에서 만든 작은 실수가 downstream에 큰 문제를 일으켰다"는 식의 인식

• 조직적 회고, 정렬, 합의 형성에 유용

  • 모두가 같은 '큰 페이지'에 올라감

• 핵심 문제에 대한 합의와 명확한 우선순위 도출

  • 범위를 제한하지 않고 전체를 탐색하여 병목, 핵심 문제를 도출

  • 조직 전체가 '지금 당장 해결해야 할 유일한 문제'에 합의

  • 기존 백로그, 추정치 등은 무의미해지고, 실질적 실험과 해결에 집중

  • 기존 관행이나 베스트 프랙티스가 해결하지 못한 문제에 도달할 수 있음

7. 바운디드 컨텍스트의 자연스러운 드러남과 정보 흐름

• 워크숍 중 각자 자신의 영역(바운디드 컨텍스트)에 대한 소유권이 드러남

  • 예: 상품을 카탈로그에 추가할 때, 한쪽은 체크리스트를 신경 쓰지만, 다른 쪽은 결과만 신경 씀

  • 서로 다른 모델이 필요함이 명확해짐

• 정보는 도메인 이벤트를 통해 다음 모델로 전달

• 워크숍 종료 시, 핵심 문제와 바운디드 컨텍스트 후보가 명확히 드러남

8. 프로세스 모델링과 소프트웨어 설계로의 확장

• 빅픽처 이후, 문제 영역을 좁혀 프로세스 모델링 워크숍 진행

  • 선택된 문제에 집중, 소수 인원이 해결책 탐색

  • 커맨드, 도메인 이벤트, 정책(Policy), 외부 시스템 등 다양한 요소로 모델링

• 정책(Policy): 이벤트와 다음 행동 사이의 '접착제' 역할

  • 예: 이메일 문의가 오면 답변하는 조직적 습관

  • '즉시(immediately)', '항상(always)'라는 질문으로 실제 정책을 명확히 함

• 가치(Value) 가시화: 프로세스에서 창출·소멸되는 가치를 명확히 드러냄

  • 예: 컨퍼런스 발표 제안 시, 수락/거절, 정보 제공, 평판 상승/스트레스 등 다양한 가치 흐름

• 다양한 배경의 사람들이 한 테이블에서 모델링

  • 고객 여정, 와이어프레임, 개발팀 등 분리하지 않고 함께 작업

• 합의와 솔루션 도출의 어려움: 설계 단계에서는 합의와 '자아 관리'가 더 어려워짐

  • 소프트웨어 설계에서는 '애그리게이트' 등 비즈니스와 무관한 개념이 등장할 수 있음

  • 비즈니스 담당자에게 기술적 개념을 강요하지 않도록 주의

• 모델링은 색깔 퍼즐처럼 단순하게, UML처럼 복잡하게 만들 필요 없음

9. 반복적 개선과 언어의 정제

• 처음 만든 모델에 집착하지 말고, 여러 번 다시 쓰고 개선

  • 첫날은 혼돈, 둘째 날은 세밀함과 정확성 강조

  • '처음 쓴 이벤트'는 미숙할 수 있으니, 재작성이 필수

• 전문가 간 논의에서 바운디드 컨텍스트의 분리와 소유권이 명확히 드러남

  • 핵심 정보가 명확히 가시화됨

10. 어려운 문제 해결을 위한 실험과 반복

• 어려운 문제는 명확한 해답이 없으며, 실험과 실패를 반복해야 함

  • 조직이 바보 같아서 문제가 남아있는 것이 아니라, 해결이 어려워서임

  • 다양한 시도와 도구의 활용이 필요함

11. 리드모델(Read Model)과 사용자 경험 중심 설계

• 리드모델: 사용자가 결정을 내리기 위해 필요한 정보를 제공하는 모델

  • 단순 데이터가 아니라, 실제 의사결정에 필요한 정보에 집중

  • 예: 가격, 이미지 등 감정적·이성적 요소 모두 고려

  • 리드모델은 결정이 일어나는 바운디드 컨텍스트에 위치

• 와이어프레임 등 다양한 도구와 결합 가능

12. 디자인 개선과 다양한 솔루션 탐색

• 디자인은 반복적으로 개선

  • 불만족스러운 부분(핫스팟, 코멘트 등)을 명확히 드러내고 하나씩 해결

• 단일 솔루션에 집착하지 말고, 여러 대안을 탐색

  • 두 가지 전략 중 선택이 어렵다면, 문제를 더 어렵게 만들어 명확한 우위를 찾음

• 모델링 종료의 기준: '브루스 리 상태'처럼, 더 많은 요구사항이 와도 자신감이 생길 때

13. Event Storming의 핵심 요약

• Event Storming은 단일 레시피가 아니라, 상황에 따라 다양한 방식으로 적용 가능

  • 피자에 다양한 토핑을 올리듯, 기본은 같고 응용이 다양함(비유)

• 도메인 이벤트 중심의 스토리텔링이 가장 효과적

  • 사람들은 이야기를 통해 자연스럽게 일관성을 유지함

• 핵심 메시지: "사람을 합치고, 소프트웨어를 분리한다"

  • 과거에는 사람을 분리하고, 소프트웨어(데이터베이스)를 합쳤으나, Event Storming은 그 반대

• 이벤트 중심의 타임라인이 비즈니스, 프로세스, 소프트웨어 설계 모두를 연결하는 공통 언어

  • 데이터 중심 아키텍처로는 불가능한 다양한 관점의 통합이 가능함

14. 결론 및 마무리

• 강연 종료 및 감사 인사

• (청중 박수)