이벤트 스토밍은 포스트잇을 많이 붙이는 워크숍이 아닙니다. 복잡한 업무를 둘러싼 대화를 한 장의 흐름으로 꺼내 놓고, 그 안에서 어디서 의미가 갈리고 어디서 경계가 생기는지 빨리 드러내는 방법에 가깝습니다.
좋은 이벤트 스토밍의 핵심은 아이디어를 많이 내는 데 있지 않습니다. 같은 주문, 결제, 정산이라는 말을 서로 조금씩 다르게 쓰고 있었다는 사실을 드러내고, 그 차이를 설계 경계로 바꾸는 데 있습니다. 이번 글에서는 왜 도움이 되는지, 어떻게 도메인 대화가 설계 자산이 되는지, 언제는 유용하지만 언제는 워크숍 연극으로 끝나는지 실무 기준으로 정리하겠습니다.
이벤트 스토밍
공식 소개를 보면 이벤트 스토밍은 조직 개선, 새로운 서비스 탐색, 중요한 소프트웨어 설계까지 폭넓게 쓰입니다. 공통점은 하나입니다. 업무 흐름을 사건 중심으로 펼쳐 놓으면 사람마다 머릿속에 따로 있던 모델이 한 화면에 올라온다는 점입니다.
보통 회의에서는 각자가 자기 부서 언어로만 설명합니다. 운영팀은 예외 처리부터 말하고, 개발팀은 데이터 구조를 먼저 떠올리고, 기획자는 사용자 여정을 중심으로 말합니다. 이 상태에서는 모두가 고개를 끄덕여도 같은 그림을 보고 있다고 장담하기 어렵습니다. 이벤트 스토밍은 이 흐름을 시간 순서의 사건으로 세워서 대화를 맞춥니다. 그래서 누가 무엇을 안다고 생각했는지보다 실제로 어디서 일이 일어나는지가 먼저 드러납니다.
왜 빠를까
이벤트 스토밍이 빠른 이유는 정답을 미리 모델링하지 않기 때문입니다. 처음부터 엔티티, 테이블, API를 정교하게 그리면 논의가 금방 구현 세부사항으로 미끄러집니다. 반대로 사건을 중심으로 흐름을 세우면 도메인 대화가 훨씬 가벼워집니다. 주문이 생성된다, 결제가 승인된다, 재고가 확보된다, 정산이 확정된다는 식의 사건은 비교적 합의하기 쉽고, 그다음에야 누가 그것을 일으키고 어떤 정책이 붙는지를 볼 수 있습니다.
- 먼저 사건을 놓기 때문에 기술 취향 논쟁으로 새기 어렵다
- 흐름이 한 번 보이면 누락된 단계와 예외가 눈에 잘 띈다
- 용어 충돌이 말싸움이 아니라 모델 차이로 드러난다
- 경계 후보를 큰 비용 없이 여러 번 바꿔볼 수 있다
즉 빠르다는 말은 대충 한다는 뜻이 아닙니다. 복잡한 설계를 시작하기 전에 무엇이 정말 복잡한지 빨리 찾는다는 뜻에 가깝습니다.
경계가 드러나는 순간
이벤트 스토밍의 진짜 가치는 포스트잇이 아니라 경계가 갈라지는 순간을 잡는 데 있습니다. 같은 주문이라는 단어를 써도 주문팀에게 중요한 것은 생성, 변경, 취소일 수 있고, 정산팀에게 중요한 것은 매출 인식과 수수료 확정일 수 있습니다. 이름은 같아도 사건의 관심사와 규칙이 다르면 이미 다른 모델이 숨어 있는 것입니다.
DDD에서 말하는 Bounded Context는 바로 이런 차이를 다루는 개념입니다. 한 컨텍스트 안에서는 같은 단어가 같은 뜻으로 통하지만, 다른 컨텍스트로 가면 의미가 달라질 수 있습니다. 이벤트 스토밍은 그 차이를 회의실에서 빨리 눈으로 보이게 만들어 줍니다.
용어가 어긋날 때
어떤 팀은 고객을 주문자라고 부르고, 어떤 팀은 결제 주체를 고객이라고 부르고, 어떤 팀은 계정 소유자를 회원이라고 부릅니다. 평소에는 그냥 넘어가도 설계 단계에서는 이 미묘한 차이가 API, 상태값, 권한 규칙 충돌로 번집니다. 이벤트 스토밍은 이 어긋남을 조용히 숨기지 않고 드러냅니다.
정책이 갈릴 때
같은 주문 취소라도 주문팀은 배송 전 취소 가능 여부를 보고, 정산팀은 환불 수수료와 정산 확정 시점을 봅니다. 이벤트가 이어진 뒤 어느 순간부터 정책 질문이 달라진다면, 그 지점은 모델 경계를 의심해볼 만합니다.
변경 이유가 달라질 때
결제 수단 정책 변경 때문에 주문 핵심 모델까지 계속 흔들리고 있다면 경계가 섞였을 가능성이 큽니다. 반대로 경계를 잘 잡으면 한쪽 변경이 다른 쪽 대화와 코드를 덜 흔듭니다. Microsoft Learn이 서비스 경계를 business capability와 응집도로 보라고 하는 이유도 여기에 있습니다.
설계로 옮기는 법
이벤트 스토밍 결과를 바로 마이크로서비스 개수로 바꾸면 대부분 실패합니다. 먼저 해야 할 일은 대화에서 드러난 차이를 설계 질문으로 번역하는 것입니다. 누가 이 이벤트를 일으키는가, 어떤 정책이 필요한가, 어디까지 같은 언어로 설명할 수 있는가, 어떤 모델은 번역이 필요한가를 차례로 봐야 합니다.
- 사건 흐름에서 핵심 가치 전달 단계를 확인한다
- 각 단계에서 자주 등장하는 명사보다 중요한 정책 질문을 적는다
- 같은 단어가 다른 뜻으로 쓰이는 지점을 표시한다
- 그 차이가 한 모델 안에서 버틸 만한지, 경계를 나눠야 할지 판단한다
- 그다음에야 모듈, 서비스, API 책임으로 옮긴다
이 순서가 중요한 이유는 구조를 코드에서 찾지 않고 대화에서 찾기 때문입니다. 이 감각은 헥사고날 아키텍처나 레이어드 아키텍처를 적용할 때도 그대로 이어집니다. 경계가 먼저 서야 포트와 책임도 자연스럽게 정리됩니다.
언제 유용할까
- 여러 팀이 같은 흐름을 각자 다르게 이해하고 있을 때
- 기능보다 업무 규칙이 더 복잡한 도메인을 다룰 때
- 서비스 경계나 bounded context가 자꾸 흔들릴 때
- 기획, 운영, 개발의 설명이 계속 엇갈릴 때
- 프로세스 예외와 책임 소재를 같이 드러내야 할 때
특히 기존 시스템 개편, 주문-결제-정산처럼 부서마다 보는 화면이 다른 업무, 이벤트 기반 구조를 검토하는 팀에서 효과가 큽니다. 반대로 규칙이 단순한 CRUD 화면 몇 개를 만드는 수준이라면 굳이 큰 이벤트 스토밍이 필요 없을 수 있습니다.
연극이 되는 경우
이벤트 스토밍이 항상 좋은 것은 아닙니다. 겉보기에는 활기차지만 결과가 남지 않는 워크숍도 많습니다. 대개 공통된 실패 패턴이 있습니다.
포스트잇만 남을 때
이벤트를 많이 붙였지만 어떤 용어 충돌이 있었고 어떤 경계 후보가 나왔는지 정리하지 않으면 다시 원래 회의로 돌아갑니다. 산출물은 벽 사진이 아니라 합의된 질문과 경계 메모여야 합니다.
참가자가 비어 있을 때
개발자만 모여 도메인 대화를 하면 코드 구조 회의로 축소되기 쉽고, 반대로 현업만 모이면 설계 연결이 약해질 수 있습니다. 공식 사이트가 cross-discipline conversation을 강조하는 이유도 서로 다른 관점이 같은 장면에서 만나야 하기 때문입니다.
정답 찾기 회의가 될 때
처음부터 서비스 개수나 DB 분리안을 확정하려 들면 사람들이 방어적으로 변합니다. 이벤트 스토밍은 정답 발표 자리가 아니라 이해 차이를 발견하는 자리여야 합니다.
후속 설계가 없을 때
워크숍 뒤에 bounded context 후보, 번역 규칙, 책임 분리, API 경계 같은 후속 설계가 이어지지 않으면 일회성 행사로 끝납니다. 이벤트 스토밍은 시작점이지 완성품이 아닙니다.
작게 시작하기
처음부터 하루 종일 전사 워크숍을 열 필요는 없습니다. 가장 자주 꼬이는 한 흐름만 잡아도 충분합니다. 예를 들어 주문 생성부터 결제 승인까지, 혹은 장애 접수부터 복구 완료까지처럼 끝이 보이는 구간 하나만 선택해도 경계 감각을 얻기 좋습니다.
- 문제가 자주 생기는 흐름 하나를 고른다
- 그 흐름의 사건을 시간 순서대로 적는다
- 단어 뜻이 갈리는 지점과 예외를 표시한다
- 정책이 달라지는 지점에 경계 후보를 적는다
- 후속으로 용어집, API 책임, 모델 번역 규칙을 정리한다
이 정도만 해도 이벤트 스토밍은 충분히 값을 합니다. 중요한 것은 크게 시작하는 것이 아니라, 대화가 설계로 이어지는 습관을 만드는 것입니다.
정리
이벤트 스토밍은 포스트잇 놀이가 아니라 도메인 대화를 사건 흐름으로 바꾸고, 그 흐름에서 경계를 발견하는 빠른 방법입니다. 그래서 가치가 있습니다. 한 팀이 알고 있던 업무 지식과 다른 팀이 쓰던 언어가 같은 벽면 위에서 충돌할 때, 어디까지를 같은 모델로 볼지 판단할 단서가 생기기 때문입니다.
좋은 결과는 화려한 진행보다 선명한 후속 질문에서 나옵니다. 어떤 단어가 여기서부터 다른 뜻이 되는가, 어떤 정책이 이 지점에서 갈라지는가, 어디서부터는 번역이 필요한가를 잡아내면 그다음 설계는 훨씬 현실적이 됩니다. 더 이어서 읽고 싶다면 DDD의 Bounded Context란 무엇인가, 헥사고날 아키텍처란 무엇인가, 레이어드 아키텍처란 무엇인가를 함께 보는 것을 권합니다. 외부 참고 자료로는 EventStorming 공식 사이트, Martin Fowler의 Bounded Context, Ubiquitous Language, Microsoft Learn의 Domain Analysis가 도움이 됩니다.
