우아한테크코스 테코톡
링크의 이벤트 스토밍
https://youtu.be/J4Dps7LQvuM?si=cp7youYOeQm-ozy1
링크의 이벤트 스토밍
이벤트 스토밍(Event Storming): 도메인을 빠르게 이해하는 가장 강력한 방법
프로젝트를 시작할 때 가장 많이 발생하는 문제는 코드가 아니라 도메인 이해의 불일치다. 같은 기능을 이야기하면서도 서로 다른 용어를 쓰거나, 같은 용어를 다르게 이해하거나, 특정 도메인 지식이 일부 사람에게만 몰려 있는 상황이 자주 발생한다.
발표에서도 이 문제를 명확하게 짚는다. 같은 의미를 다른 단어로 표현하거나, 같은 단어를 다른 의미로 이해하면서 혼란이 생기고, 복잡한 기능일수록 특정 사람에게 지식이 집중되어 협업이 어려워진다. 결국 이런 문제의 본질은 도메인에 대한 이해도가 팀 내에서 일치하지 않기 때문이다.
이 문제를 해결하기 위한 강력한 방법이 바로 이벤트 스토밍(Event Storming)이다.
이벤트 스토밍이란 무엇인가
이벤트 스토밍은 도메인에서 발생하는 이벤트를 중심으로 비즈니스 흐름을 탐색하고 이해하는 설계 기법이다. 단순히 다이어그램을 그리는 작업이 아니라, 복잡한 도메인을 빠르게 학습하고 팀 전체의 이해를 맞추는 과정이다.
여기서 중요한 특징이 하나 있다. 이벤트 스토밍은 개발자만 참여하는 활동이 아니다. 기획자, 디자이너, 도메인 전문가 등 실제 문제 해결과 관련된 모든 사람이 함께 참여한다. 즉, “코드를 만드는 사람”이 아니라 “도메인을 이해해야 하는 사람”이 모두 참여하는 협업 방식이다.
발표에서도 이 점을 강조하며, 이벤트 스토밍을 “도메인 이해도를 일치시키는 과정”으로 설명한다.
왜 이벤트 스토밍이 필요한가
이벤트 스토밍이 필요한 이유는 생각보다 단순하다. 우리가 프로젝트를 진행할 때 겪는 대부분의 문제는 기술이 아니라 이해의 불일치에서 시작되기 때문이다.
예를 들어 누군가는 “책 정보를 제공해야 한다”고 말하고, 다른 사람은 “도서 조회 API를 만들면 되겠다”고 말한다. 겉보기에는 같은 이야기처럼 보이지만, 실제로는 서로 다른 개념을 떠올리고 있을 수도 있다. 또 다른 예로, “비밀번호 정책”을 이야기할 때 어떤 사람은 회원 기준으로 생각하고, 어떤 사람은 비회원까지 포함해 생각하면서 전혀 다른 방향의 논의를 하게 된다.
더 큰 문제는 지식이 분산되어 있을 때다. 특정 기능을 구현하려고 하면 A는 일부 도메인만 알고 있고, B는 다른 도메인을 알고 있고, C는 더 잘 알지만 자리에 없는 상황이 발생한다. 이런 구조에서는 기능 개발 속도보다 “누가 아는지 찾는 시간”이 더 오래 걸린다.
이벤트 스토밍은 이런 문제를 해결한다. 핵심은 단 하나다.
“모든 사람이 같은 사실을 보게 만든다.”
이벤트 스토밍은 어떻게 진행되는가
이벤트 스토밍은 의외로 매우 단순하게 시작한다. 커다란 공간(화이트보드, 종이, Miro 등)에 포스트잇을 붙이며 진행한다. 중요한 것은 도구가 아니라, 비즈니스 흐름을 이벤트 중심으로 표현하는 것이다.
전체 과정은 단계적으로 진행되며, 단계가 깊어질수록 설계가 점점 구체화된다.
1단계: 도메인 이벤트 정의
가장 먼저 시작하는 것은 도메인 이벤트(Domain Event) 다. 도메인 이벤트는 “비즈니스적으로 의미 있는 일”, 즉 상태가 변경된 사건을 의미한다.
여기서 중요한 규칙은 두 가지다.
첫째, 과거 시제로 작성한다. 둘째, 팀원들과 토론하지 않고 각자 생각나는 이벤트를 먼저 작성한다.
예를 들면 이런 식이다.
- 회원이 생성되었다
- 주문이 생성되었다
- 결제가 완료되었다
이 단계에서는 정확성보다 많이 뽑는 것이 중요하다.
이벤트 중복 제거와 타임라인 정렬
이벤트를 충분히 작성했다면, 그다음은 중복 제거다. 다만 여기서 중요한 점은 “같은 문장”이 반드시 같은 이벤트는 아니라는 것이다. 발표에서도 로그인 성공이라는 이벤트라도 “일반 로그인”과 “소셜 로그인”은 서로 다른 이벤트일 수 있다고 설명한다.
그다음 이벤트를 시간 흐름 기준으로 정렬한다.
- 왼쪽 → 오른쪽: 시간 흐름
- 위 → 아래: 병렬 흐름
이 과정을 거치면 비즈니스 프로세스가 한눈에 보이기 시작한다.
2단계: Hot Spot (문제 영역 표시)
이벤트를 정리하다 보면 자연스럽게 질문과 충돌이 발생한다.
- 이 정책은 어떻게 동작하지?
- 이 용어가 맞는 표현인가?
- 이건 취소인가, 환불인가?
이런 부분을 Hot Spot 으로 따로 표시한다. 중요한 포인트는 “지금 토론하지 않는다”는 것이다. 발표에서도 하나하나 논의하면 하루가 끝나버리기 때문에, 일단 붙여두고 나중에 해결하는 방식으로 진행한다고 설명한다.
이 단계의 목적은 해결이 아니라 문제 인식의 공유다.
3단계: External System, Actor
이제 이벤트를 조금 더 구체화한다.
External System은 외부 시스템이다. 예를 들어 이메일 발송 이벤트가 있다면 AWS SES 같은 외부 시스템을 연결해서 표시한다.
Actor는 이벤트를 발생시키는 주체다. 여기서 중요한 점은 “사용자” 같은 추상적인 표현보다 “구매자”, “판매자” 같은 구체적인 페르소나를 사용하는 것이 좋다는 것이다.
이 단계까지 오면 시스템 외부와 내부의 경계가 조금씩 보이기 시작한다.
4단계: Bounded Context와 유비쿼터스 언어
포스트잇이 쌓이다 보면 자연스럽게 영역이 나뉜다. 이것이 바로 Bounded Context다.
같은 용어라도 Context에 따라 의미가 달라질 수 있다. 발표에서는 “커피”라는 단어가 이탈리아에서는 에스프레소를 의미하고, 미국에서는 아메리카노를 의미하는 예를 든다. 이런 차이가 바로 컨텍스트 경계를 나누는 기준이다.
그리고 각 Context 내부에서 사용하는 공통 언어를 유비쿼터스 언어(Ubiquitous Language) 라고 한다. 이 언어가 정리되면, 개발자와 기획자, 디자이너가 같은 말을 같은 의미로 사용할 수 있게 된다.
이 단계는 DDD에서 매우 중요한 개념과 직접 연결된다.
5단계: Command, Read Model, Policy
이제 이벤트 중심 흐름을 시스템 동작 관점으로 확장한다.
Command는 이벤트를 발생시키는 원인이다. 예를 들어 “메일이 발송되었다”는 이벤트는 “메일 발송 요청”이라는 Command에서 시작된다.
Read Model은 Command를 수행하기 위해 필요한 데이터다. 주문 생성이라면 상품 목록, 배송 주소, 결제 수단 등이 여기에 해당한다.
Policy는 이벤트와 Command를 연결하는 규칙이다. 보통 “~할 때마다” 형태로 표현된다.
- 회원가입이 완료될 때마다 메일을 발송한다
이 단계까지 오면 시스템 흐름이 거의 코드 수준으로 내려온다.
6단계: Aggregate (일관성의 경계)
마지막은 Aggregate다. 쉽게 말하면 하나의 트랜잭션으로 묶여야 하는 일관성 단위다.
예를 들어 회원가입이 완료된 후, 정책에 따라 이메일을 발송하고, 발송 완료 이벤트까지 이어지는 흐름은 하나의 일관된 단위로 묶일 수 있다. 이를 회원 Aggregate라고 정의할 수 있다.
이 단계는 DDD 설계와 직접 연결되는 핵심 단계다.
이벤트 스토밍은 어디까지 해야 할까
발표에서 중요한 현실적인 조언이 나온다. 모든 단계를 다 할 필요는 없다. Hot Spot, Actor, External System 같은 빅픽처 단계만으로도 충분한 효과를 얻을 수 있다. 더 단순하게는 유비쿼터스 언어만 정리해도 큰 가치가 있다.
즉, 이벤트 스토밍은 “완벽하게 해야 의미 있는 것”이 아니라, 조금만 해도 효과가 나오는 도구다.
이벤트 스토밍의 본질
발표의 마지막 메시지가 굉장히 중요하다.
이벤트 스토밍은 사람들을 합치고, 소프트웨어를 분리하는 활동이다.
이 문장을 풀어보면 다음과 같다.
사람을 합친다는 것은 팀 전체가 같은 도메인 이해를 갖게 된다는 의미다. 소프트웨어를 분리한다는 것은 도메인 경계(Bounded Context)가 자연스럽게 드러난다는 의미다.
결국 이벤트 스토밍은 단순한 설계 기법이 아니라, 협업 문제와 아키텍처 문제를 동시에 해결하는 방법이다.
마무리
이벤트 스토밍은 복잡한 도메인을 이해하는 가장 빠른 방법 중 하나다. 코드 설계보다 먼저, DB 설계보다 먼저, “이 시스템에서 어떤 일이 일어나는지”를 이벤트 중심으로 풀어내는 과정이다.
정리하면 핵심은 이렇다.
- 도메인 이벤트를 통해 비즈니스 흐름을 드러낸다
- Hot Spot으로 문제와 불확실성을 시각화한다
- Actor, External System으로 시스템 경계를 파악한다
- Bounded Context와 유비쿼터스 언어로 도메인을 정리한다
- Command, Policy, Aggregate로 설계를 구체화한다
그리고 그 결과는 하나다.
팀 전체가 같은 그림을 보게 된다.
이게 바로 이벤트 스토밍이 강력한 이유다.
