DDD Patterns - 08. 이벤트 스토밍

벽에 사건을 붙이는 탐정 — 이벤트 스토밍

경찰 드라마를 보면 탐정이 벽에 사건을 붙인다. 사진·메모·실을 연결해 사건의 전모를 재구성한다. 시간 순으로 나열하고, 인과관계로 이으면서 빈 부분(아직 모르는 사건)이 드러나면 거기를 파고든다. 코드를 한 줄도 안 쓰고 사건의 구조를 이해한다.

이벤트 스토밍(EventStorming)은 도메인을 이 탐정 보드처럼 다루는 워크숍 기법이다. Alberto Brandolini가 고안했고, 도메인 전문가와 개발자가 함께 벽에 포스트잇을 붙이며 비즈니스 흐름을 재구성한다. 코드를 짜기 전에, 혹은 코드를 고치기 전에 "이 비즈니스에서 무슨 일이 일어나는가"를 가시적으로 만드는 도구다.

도메인 이벤트로 시작한다

이벤트 스토밍의 출발점은 도메인 이벤트다 — "비즈니스에서 의미 있게 일어난 과거 사실". 주문 접수됨, 결제 완료됨, 배송 시작됨. 참가자들은 주황색 포스트잇에 이벤트를 적고 벽에 시간 순으로 나열한다. 왼쪽에서 오른쪽으로, 과거에서 미래로.

flowchart LR
    E1["주문 접수됨<br/>(주황)"] --> E2["재고 확인됨<br/>(주황)"]
    E2 --> E3["결제 완료됨<br/>(주황)"]
    E3 --> E4["배송 시작됨<br/>(주황)"]
    E4 --> E5["배송 완료됨<br/>(주황)"]
    C1["주문 하기<br/>(파랑)<br/>명령"] -.-> E1
    C2["결제 하기<br/>(파랑)"] -.-> E3
    A1["고객<br/>(노랑)<br/>행위자"] -.-> C1

이 과정에서 자연스럽게 빈 부분이 드러난다 — "결제 완료" 다음에 바로 "배송 시작"이 붙어 있으면, 누군가 "잠깐, 결제 완료 후 환불 가능 기간 체크가 있어야 하는 거 아닌가?"라고 묻는다. 빈 칸이 발견되고, 새 이벤트가 채워진다. 코드를 한 줄도 안 쓰고 도메인의 빈 부분이 가시화된다 — 이것이 이벤트 스토밍의 힘이다.

포스트잇 색이 언어다

Brandolini가 정의한 색 규약은 워크숍의 공유 언어다:

색	의미	예
주황	도메인 이벤트 (과거 사실)	주문 접수됨, 결제 완료됨
파랑	명령 (command, 의도한 행동)	주문하기, 결제하기
노랑	행위자 (actor, 누가)	고객, 관리자, 시스템
보라	정책 (policy, "~하면 ~하라")	결제 완료되면 배송 시작
분홍	제약 (constraint, 비즈니스 규칙)	환불은 7일 이내만
연두	읽기 모델 (read model)	주문 목록 화면

색 규약이 있으면, 포스트잇을 붙이는 것만으로 비즈니스 흐름이 그려진다. "결제 완료됨(주황) → 정책(보라): 결제 완료되면 배송을 시작한다 → 배송 시작됨(주황)"이라는 인과 사슬이 벽 위에 시각화된다.

Big Picture vs Design Level

Brandolini는 이벤트 스토밍을 두 단계로 나눴다. Big Picture는 전체 비즈니스 흐름을 조망하는 단계다 — 시작과 끝을 놓고, 주요 이벤트를 나열하며, 컨텍스트 경계(바운디드 컨텍스트)가 자연스럽게 드러나게 한다. 비개발자(기획자, 영업, 운영)도 참여한다.

Design Level은 한 바운디드 컨텍스트 안으로 줌인한다 — 이벤트에 대응하는 명령(command)을 붙이고, 애그리거트(명령이 처리되는 단위)를 식별하고, 제약과 정책을 달면서 구현 수준의 설계로 들어간다. 여기서 도메인 이벤트가 코드의 도메인 이벤트(02번에서 본 OrderPlaced)와 직결된다.

코드 없이 도메인을 가시화하는 이유

이벤트 스토밍의 가치는 코드를 안 쓴다는 데 있다. 도메인 전문가는 코드를 못 읽는다 — UML도, 클래스 다이어그램도, ERD도 못 읽는다. 하지만 포스트잇에 "주문 접수됨"이라고 적어 벽에 붙이는 건 누구나 한다. 개발자와 비개발자가 같은 벽 앞에서 같은 언어(포스트잇)로 대화하면서, 오해와 빈 부분이 그 자리에서 드러나고 수정된다.

이것이 보편 언어(01번)를 발견하는 가장 빠른 경로다 — 회의실에서 정의한 언어가 아니라, 도메인 전문가가 벽에 붙인 포스트잇에서 나온 언어가 진짜 보편 언어다. 코드에 들어갈 클래스명·이벤트명이 워크숍에서 결정된다.

탐정 보드는 끝나지 않는다

이벤트 스토밍은 한 번 끝내는 워크숍이 아니다. 비즈니스가 변하면 새 이벤트가 생기고, 기존 흐름이 바뀐다. 정기적으로 벽 앞에 서서 "지금 이 흐름이 맞는가, 빠진 사건이 있는가"를 묻는다 — 탐정이 사건이 진전되면 보드를 업데이트하듯, 도메인이 진화하면 스토밍 보드도 진화한다.

설계 사례 — 스토밍 보드에서 코드로

워크숍에서 벽에 붙은 포스트잇이 코드의 클래스로 어떻게 이어지는지, 주문·결제 흐름을 예로 본다. 포스트잇의 색과 내용이 곧 코드의 구조가 된다.

flowchart LR
    subgraph Board["스토밍 보드 (포스트잇)"]
        C1["주문하기<br/>(파랑: 명령)"]
        E1["주문 접수됨<br/>(주황: 이벤트)"]
        C2["결제하기<br/>(파랑: 명령)"]
        E2["결제 완료됨<br/>(주황: 이벤트)"]
        P1["결제 완료되면<br/>배송 시작<br/>(보라: 정책)"]
        E3["배송 시작됨<br/>(주황: 이벤트)"]
    end
    C1 --> E1
    E1 --> C2
    C2 --> E2
    E2 --> P1
    P1 --> E3

이 보드의 각 포스트잇이 코드로 직접 매핑된다. 주황색 이벤트(과거 사실)는 도메인 이벤트 record가 되고, 파란색 명령(의도된 행동)은 커맨드 객체와 메서드가 되며, 보라색 정책("~하면 ~하라")은 이벤트 구독 로직이 된다.

// (주황) 도메인 이벤트 — 보드의 "주문 접수됨" 포스트잇
public record OrderPlaced(OrderId orderId, CustomerId customerId, Money total, Instant occurredAt) {}

// (파랑) 명령 — 보드의 "주문하기" 포스트잇
public record PlaceOrderCommand(CustomerId customerId, List<OrderLine> lines) {}

// 도메인 — 명령을 받아 이벤트를 발생
public class Order {
    public OrderPlaced place(PlaceOrderCommand cmd) {
        // 주문 생성 로직...
        return new OrderPlaced(this.id, cmd.customerId(), this.total(), Instant.now());
    }
}

// (보라) 정책 — 보드의 "결제 완료되면 배송 시작"
// 이벤트를 구독하여 반응
public class ShippingPolicy {
    public void on(PaymentCompleted event) {   // 결제 완료 이벤트 구독
        shippingService.schedule(event.orderId());
        // → "배송 시작됨" 이벤트 발생
    }
}

이 매핑이 가진 가치는 워크숍의 산출물이 코드의 청사진이 된다는 것이다. 도메인 전문가가 벽에 붙인 "결제 완료되면 배송 시작"이라는 포스트잇이, 코드에서 ShippingPolicy.on(PaymentCompleted)라는 메서드로 직결된다. 보편 언어(01번)가 포스트잇에서 발견되고, 그 언어가 곧 코드의 클래스명·메서드명이 된다 — 회의실에서 정의한 언어가 아니라, 워크숍에서 발견한 언어가.

---

참고

• Brandolini, Alberto — "Introducing EventStorming" (2013), https://ziobrando.blogspot.com/2013/11/introducing-event-storming.html — 접근 2026-07-15
• Brandolini, Alberto — (Leanpub, 2018), https://leanpub.com/introducing_eventstorming — 접근 2026-07-15