EventStorming 도입의 필요성과 기대효과

EventStorming 도입 검토

1. 개요

EventStorming은 Alberto Brandolini가 개발한 비공식 워크숍 기법으로, 복잡한 비즈니스 도메인을 이해하고 소프트웨어 아키텍처를 설계하기 위한 시각적 협업 도구입니다. 이 문서는 EventStorming 방법론의 사내 도입 필요성과 기대효과를 제시합니다.

2. EventStorming이란?

EventStorming은 다음과 같은 특징을 가진 워크숍 기법입니다:

2.1 기본 원리

이벤트 중심 모델링: 도메인에서 발생하는 비즈니스 이벤트를 중심으로 시스템을 이해
시각적 협업: 다채로운 포스트잇과 긴 벽면을 활용한 대규모 협업
빠른 피드백: 수 시간 내에 복잡한 도메인의 전체 그림을 그려낼 수 있음
경계 없는 소통: 개발자, 기획자, 도메인 전문가, 경영진이 동등한 위치에서 소통

2.2 주요 구성 요소

도메인 이벤트: “무엇이 발생했는가”를 나타내는 과거형 이벤트 (주황색 포스트잇)
명령: “무엇을 해야 하는가”를 나타내는 액션 (파란색 포스트잇)
액터: 시스템과 상호작용하는 사용자 또는 외부 시스템 (노란색 포스트잇)
애그리게이트: 이벤트를 생성하는 경계된 컨텍스트 단위 (연두색 포스트잇)
정책: 특정 이벤트에 반응하는 비즈니스 규칙 (보라색 포스트잇)

3. 도입의 필요성

3.1 현재 프로젝트에서의 문제점

요구사항 이해의 불일치

개발자와 기획자 간 요구사항 해석 차이로 인한 재작업 발생
도메인 전문가의 지식이 코드에 제대로 반영되지 않음
문서화된 요구사항과 실제 구현 간의 괴리

복잡한 도메인 관리의 어려움

비즈니스 로직이 복잡해질수록 전체 시스템 이해도 저하
서비스 간 의존성과 상호작용 파악의 어려움
시간 경과에 따른 요구사항 변화 추적의 어려움

협업 효율성 저하

긴 문서 작성과 검토 과정으로 인한 시간 소모
의사결정 과정에서의 불필요한 지연
팀 간 커뮤니케이션 비용 증가

3.2 EventStorming의 해결 방안

빠른 공유 이해 형성: 수 시간 내에 전체 도메인에 대한 공통 이해 도달
시각적 모델링: 복잡한 관계를 직관적인 포스트잇 맵으로 표현
실시간 피드백: 워크숍 중 즉각적인 질문과 답변으로 모호성 해소
협업 중심: 모든 이해관계자가 동등하게 참여하는 구조

4. 기대효과

4.1 단기 효과 (3-6개월)

개발 효율성 향상

요구사항 오해로 인한 재작업 비용 30-50% 감소
설계 리뷰 시간 단축 (문서 중심 → 시각적 모델 중심)
새로운 팀원의 온보딩 시간 단축

커뮤니케이션 개선

이해관계자 간 소통 품질 향상
도메인 전문가와 개발자 간 지식 공유 활성화
프로젝트 초기 단계의 목표 명확화

품질 향상

요구사항 누락 및 오해 방지
비즈니스 로직의 정확한 구현
도메인 모델의 일관성 확보

4.2 중장기 효과 (6개월 이상)

아키텍처 품질 개선

경계된 컨텍스트(Bounded Context) 명확화
마이크로서비스 경계 설계 개선
시스템 복잡도 관리 개선

조직 역량 강화

도메인 주도 설계(DDD) 문화 정착
팀 간 협업 문화 개선
지식 공유 문화 형성

비즈니스 가치 증대

시장 출시 시간 단축 (Time to Market)
제품-시장 적합도(Product-Market Fit) 향상
유지보수 비용 감소

5. 도입 방법

5.1 단계별 도입 계획

1단계: 파일럿 프로젝트 (1-2개월)

신규 프로젝트 또는 리팩토링 대상 프로젝트 선정
EventStorming 워크숍 2-3회 진행
효과 측정 및 개선점 도출

2단계: 팀 확대 (3-4개월)

파일럿 결과 공유 및 성공 사례 문서화
추가 팀에 EventStorming 도입
내부 파실리테이터 양성

3단계: 조직 전반 확산 (6개월 이상)

표준 프로세스 수립
교육 프로그램 운영
지속적인 개선 활동

5.2 필요한 리소스

인력

파실리테이터 1-2명 (초기에는 외부 또는 학습된 내부 인력)
프로젝트 이해관계자 5-15명 (워크숍 참여)

물리적 환경

넓은 벽면 또는 대형 화이트보드
다양한 색상의 포스트잇
마커 펜

시간

초기 워크숍: 4-8시간 (Big Picture EventStorming)
상세 모델링: 2-4시간 (Process Modeling)
정기적 리뷰: 월 1-2회

5.3 EventStorming 도구 추천

EventStorming은 원칙적으로 물리적인 포스트잇과 벽면을 사용하지만, 원격 협업이나 디지털 저장이 필요한 경우 디지털 도구를 활용할 수 있습니다. 각 도구의 특징과 장단점은 다음과 같습니다:

5.3.1 Miro

장점
- 풍부한 템플릿 라이브러리 (EventStorming 템플릿 포함)
- 강력한 실시간 협업 기능
- 다양한 통합 기능 (Slack, Jira, Confluence 등)
- 넓은 무제한 캔버스
단점
- 유료 플랜이 비교적 비쌈 (무료 플랜은 제한적)
- 초기 학습 곡선 존재
적합한 경우: 대규모 팀, 기업 환경, 다양한 통합이 필요한 경우

5.3.2 Mural

장점
- 직관적인 인터페이스
- 강력한 파실리테이션 기능 (타이머, 투표 등)
- EventStorming을 위한 전용 기능 제공
- 접근성 기능 우수
단점
- Miro 대비 템플릿이 상대적으로 적음
- 무료 플랜 제한이 많음
적합한 경우: 워크숍 파실리테이션에 중점을 두는 경우

5.3.3 FigJam (Figma)

장점
- Figma 사용자에게 친숙한 인터페이스
- 무료 플랜이 관대함 (최대 3개 보드)
- 가볍고 빠른 성능
- EventStorming 템플릿 제공
단점
- Figma 생태계와 밀접하게 연동
- 고급 기능이 Miro/Mural보다 제한적
적합한 경우: Figma를 이미 사용 중인 팀, 소규모 프로젝트

5.3.4 Excalidraw

장점
- 완전 무료 및 오픈소스
- 손으로 그린 듯한 자연스러운 스타일
- 빠르고 가벼움
- 오프라인 사용 가능
단점
- 협업 기능이 제한적
- 템플릿 부재
- 조직 관리 기능 부족
적합한 경우: 소규모 팀, 간단한 프로젝트, 예산 제약이 있는 경우

5.3.5 Lucidspark

장점
- Lucidchart와의 통합
- 강력한 아이디어 수집 기능
- 깔끔한 UI/UX
- 실시간 협업 지원
단점
- EventStorming 전용 기능이 상대적으로 적음
- 시장 점유율이 낮아 자료가 적음
적합한 경우: Lucidchart를 이미 사용 중인 조직

5.3.6 물리적 도구 (포스트잇 + 벽면)

장점
- EventStorming 원래 방법론
- 기술적 장벽 없음 (누구나 즉시 사용 가능)
- 자연스러운 대면 협업
- 비용이 거의 없음
단점
- 원격 협업 불가
- 디지털 저장/공유 어려움
- 공간 필요
적합한 경우: 오프라인 워크숍, 초기 도입 단계

5.3.7 도구 선택 가이드

상황	추천 도구
대규모 기업, 다양한 통합 필요	Miro
파실리테이션 중심 워크숍	Mural
Figma 사용 중인 팀	FigJam
예산 제약, 소규모 프로젝트	Excalidraw 또는 물리적 도구
오프라인 워크숍	물리적 도구 (포스트잇)
원격/하이브리드 팀	Miro, Mural, 또는 FigJam

권장 접근법: 초기 파일럿 프로젝트는 물리적 도구(포스트잇)로 시작하여 방법론을 익힌 후, 필요에 따라 디지털 도구로 전환하는 것이 효과적입니다.

5.4 예상 비용

워크숍 준비 및 진행 시간: 약 40-80인시/프로젝트
초기 교육 비용: 외부 파실리테이터 활용 시 (선택사항)
물품 구매 비용: 포스트잇, 마커 등 (최소 비용)

6. 성공 요소

6.1 핵심 성공 요소

경영진의 지원: 방법론 도입에 대한 명확한 지지
적극적인 참여: 모든 이해관계자의 적극적 참여 유도
실행 중심: 워크숍 결과를 실제 개발에 반영하는 문화
지속적인 학습: 방법론 개선을 위한 지속적인 리뷰와 학습

6.2 주의사항

과도한 기대 방지: EventStorming은 만능 해결책이 아닙니다
유연한 적용: 조직 문화에 맞게 방법론을 조정
지속성 확보: 일회성 워크숍이 아닌 지속적인 프로세스로 정착

7. 관련 이론 및 방법론

EventStorming은 다른 소프트웨어 설계 및 조직 설계 이론들과 깊은 연결점을 가지고 있습니다. 이러한 이론들을 함께 이해하고 적용할 때 시너지 효과를 얻을 수 있습니다.

7.1 DDD와 EventStorming

**Domain-Driven Design (DDD)**은 EventStorming의 이론적 기반을 제공합니다:

Bounded Context 식별: EventStorming을 통해 도메인을 탐색하면서 자연스럽게 Bounded Context의 경계를 발견할 수 있습니다
유비쿼터스 언어: EventStorming 워크숍에서 사용하는 용어가 코드와 문서로 이어져 일관된 언어를 형성합니다
전략적 설계와 전술적 설계: Big Picture EventStorming은 전략적 설계(Strategic Design)에, Process Modeling은 전술적 설계(Tactical Design)에 활용됩니다

7.2 Two-Pizza Team과의 정렬

Two-Pizza Team은 Amazon에서 제안한 팀 구조 원칙으로, 5-10명 규모의 작은 자율 팀을 의미합니다. EventStorming과 다음과 같은 점에서 잘 맞습니다:

7.2.1 최적 팀 크기의 일치

EventStorming Process Modeling: 5-10명 참가자가 적절함 (Two-Pizza Team 크기와 일치)
효과적인 협업: 작은 팀에서 모든 참가자가 적극적으로 참여할 수 있어 EventStorming의 효과가 극대화됩니다
빠른 의사결정: 작은 팀에서는 워크숍 중 결정사항을 빠르게 도출하고 실행할 수 있습니다

7.2.2 Bounded Context와의 정렬

1팀 = 1 Bounded Context: Two-Pizza Team이 하나의 Bounded Context를 소유하는 구조는 다음과 같은 이점을 제공합니다:
- 명확한 소유권: 팀이 자신의 도메인에 대한 전체적인 책임을 가집니다
- 독립적 진화: 각 팀이 자신의 Bounded Context 내에서 독립적으로 시스템을 진화시킬 수 있습니다
- 의사소통 오버헤드 감소: 팀 경계가 Bounded Context 경계와 일치하면 불필요한 인터페이스가 줄어듭니다

7.3 Conway’s Law와 Inverse Conway Maneuver

Conway’s Law (1968, Melvin Conway)는 “시스템 설계는 그것을 만드는 조직의 커뮤니케이션 구조를 반영한다”는 법칙입니다.

7.3.1 Inverse Conway Maneuver

의도적인 팀 구조 설계: 원하는 시스템 아키텍처를 얻기 위해 팀 구조를 먼저 설계하는 전략
Two-Pizza Team + Bounded Context: 팀 구조(Bounded Context 단위의 Two-Pizza Team)를 먼저 설계하면, 자연스럽게 마이크로서비스 아키텍처로 이어집니다
EventStorming의 역할: EventStorming을 통해 Bounded Context를 식별하면, 이에 맞춰 팀 구조를 설계할 수 있습니다

7.3.2 실전 적용

EventStorming → Bounded Context 식별 → Two-Pizza Team 구조 설계 → 시스템 아키텍처 형성

이 순환을 통해 조직 구조와 시스템 아키텍처가 일관되게 정렬됩니다.

7.4 Team Topologies

Team Topologies (Matthew Skelton, Manuel Pais)는 팀 구조를 최적화하는 프레임워크입니다. DDD와 EventStorming과 다음과 같이 연결됩니다:

7.4.1 Stream-Aligned Team과 Bounded Context

Stream-Aligned Team은 Team Topologies에서 정의하는 핵심 팀 타입으로, “비즈니스 도메인에 정렬된 연속적인 작업 흐름을 담당하는 팀”을 의미합니다.

Stream-Aligned Team의 특징

도메인 정렬: 특정 비즈니스 도메인이나 조직의 능력(capability)에 정렬되어 있음
End-to-End 책임: 요구사항 수집부터 배포까지의 전체 라이프사이클을 담당
자율성: 다른 팀에 의존하지 않고 독립적으로 가치를 전달할 수 있는 능력
적정 크기: 일반적으로 5-10명 규모 (Two-Pizza Team 원칙과 일치)
Cross-functional: 개발자, 디자이너, 도메인 전문가 등 다양한 역할 포함

Stream-Aligned Team과 Bounded Context의 정렬

1:1 매핑 원칙: 하나의 Stream-Aligned Team이 하나의 Bounded Context를 소유하고 관리합니다
명확한 경계: Bounded Context 경계가 팀의 책임 범위를 명확히 정의합니다
독립적 진화: 각 팀이 자신의 Bounded Context 내에서 독립적으로 시스템을 진화시킬 수 있습니다
EventStorming의 활용: EventStorming을 통해 식별한 Bounded Context에 맞춰 Stream-Aligned Team을 구성합니다

실전 적용

EventStorming 결과 분석: Big Picture EventStorming을 통해 도메인을 탐색하고 Bounded Context 경계를 식별
팀 구조 설계: 각 Bounded Context에 해당하는 Stream-Aligned Team 구성
Two-Pizza Team 규모 유지: Stream-Aligned Team의 크기를 5-10명으로 유지하여 효과적인 협업 보장

7.4.2 다른 팀 타입과의 협력

Enabling Team: EventStorming 방법론 자체를 전파하고 교육하는 역할
Platform Team: EventStorming 결과를 기반으로 한 Bounded Context 간 통신을 위한 플랫폼 제공
Complicated Subsystem Team: EventStorming에서 식별된 복잡한 기술 서브시스템 담당

7.5 이론적 시너지 효과

이러한 이론들을 함께 적용할 때 다음과 같은 시너지 효과를 얻을 수 있습니다:

7.5.1 조직-아키텍처 정렬

EventStorming → Bounded Context 식별
Bounded Context → Two-Pizza Team 구조
Two-Pizza Team → 독립적인 마이크로서비스
결과: 조직 구조와 시스템 아키텍처가 자연스럽게 정렬됨

7.5.2 확장 가능한 구조

작은 팀(5-10명) 단위로 독립적인 도메인 영역 관리
각 팀이 자신의 Bounded Context에서 EventStorming을 독립적으로 실행 가능
조직이 성장해도 동일한 패턴으로 확장 가능

7.5.3 지식 공유와 학습

EventStorming 워크숍을 통해 팀 내 지식 공유
Two-Pizza Team의 작은 크기로 모든 구성원이 도메인을 깊이 이해
Bounded Context 경계를 명확히 하여 팀 간 인터페이스가 명확해짐

7.6 실무 적용 가이드

이러한 이론적 배경을 바탕으로 다음과 같이 적용할 수 있습니다:

EventStorming으로 시작: Big Picture EventStorming으로 전체 도메인 탐색
Bounded Context 식별: EventStorming 결과에서 Bounded Context 경계 식별
팀 구조 설계: 각 Bounded Context에 Two-Pizza Team 할당 (Inverse Conway Maneuver)
지속적인 개선: 각 팀이 자신의 Bounded Context에서 Process Modeling EventStorming을 정기적으로 수행

8. 참고 자료

8.1 추천 도서

“EventStorming” – Alberto Brandolini
“Domain-Driven Design” – Eric Evans
“Implementing Domain-Driven Design” – Vaughn Vernon
“도메인 주도 설계로 시작하는 마이크로서비스 개발” – 한정헌, 유해식, 최은정, 이주영

8.2 온라인 자료

EventStorming 공식 웹사이트
DDD 커뮤니티 리소스
관련 블로그 및 컨퍼런스 발표 영상

9. 결론

EventStorming은 복잡한 비즈니스 도메인을 빠르고 효과적으로 이해하고, 이해관계자 간 공통된 비전을 형성하는 강력한 도구입니다. 특히 요구사항 불일치로 인한 재작업이 빈번하고, 도메인이 복잡한 우리 조직에서 다음과 같은 가치를 제공할 수 있습니다:

개발 효율성 향상을 통한 프로젝트 일정 단축
품질 개선을 통한 유지보수 비용 절감
협업 문화 개선을 통한 조직 역량 강화

파일럿 프로젝트를 통해 효과를 검증하고, 단계적으로 확산하는 것을 제안합니다. 이 과정에서 발생하는 학습과 개선을 통해 우리 조직에 최적화된 EventStorming 방법론을 정립할 수 있을 것입니다.