DDD(1) - 이벤트 스토밍

in DEV on DDD, Architecture, Event-storming


이 포스트에서는 효과적으로 지식을 공유하고, 공동의 이해를 구축하며, 소프트웨어를 설계하기 위한 저차원적인 워크샾인 이벤트 스토밍에 대해 알아본다.
이벤트 스토밍은 도메인 지식을 발견하고, 유비쿼터스 언어를 개발하는 과정을 간소화하는 활동이다.
이벤트 스토밍은 간단한 도구 또는 적은 비용으로 빠르고 쉽게 반복 수행하여 목적을 달성하는 접근법인 로우테크 모델링 과정이다.

  • 이벤트 스토밍의 진행 과정
  • 이벤트 스토밍 워크숍 진행 방법
  • 이벤트 스토밍을 활용하여 도메인 지식을 공유하고, 유비쿼터스 언어를 구축하는 방법

또한 다양한 성격 유형을 가진 사람들이 협업, 의사소통, 학습, 그리고 소프트웨어 혁신이라는 공통된 목표를 달성하려고 할 때, 어떻게 의사소통의 벽을 넘을 수 있는지에 대해 다룬다.
특히 실험과 발견 기반의 혁신을 추구하는 조직에서 사람들 간의 성격적 차이를 이해하고 극복하는 법은 매우 중요하다.

  • 외향인과 내향인을 구분하지 말 것
  • 소프트웨어에서 이벤트는 단지 발생한 일을 기록하는 것만이 아님
    • 이벤트는 다음 행동을 유발하는 트리거이며, 이에 따라 시스템이 진화하고 새로운 피드백 루프가 만들어짐
    • 따라서 이벤트 중심적 사고는 팀 간 소통과 실험을 이어나가는 핵심 메커니즘임
  • 실험은 조직이 빠른 학습 도구를 사용하여 빠르게 반복할 때 효과적임
    • 조직이 빠르게 학습하고 반복할 수 있는 유일한 방법은 빠르고 안전한 실험을 실행하는 것임
    • 실험은 실패해도 학습을 남기며, 이것이 곧 소프트웨어의 발전과 혁신을 이끄는 핵심 동력이 됨
  • 이벤트 스토밍에는 ‘도전적 평범함’이 필요함
    • 이벤트 스토밍 세션에는 단순히 기술적인 사람 뿐 아나리 명백한 질문에 답할 수 있는 사람, 기꺼이 평범한 가정을 뒤집을 자세가 되어있는 비즈니스 및 기술 전문가가 함께해야 함
    • 이렇게 구성된 팀은 기존의 관점을 넘어서 진정한 문제의 본질을 밝혀내고, 새로운 접근법을 도출할 수 있음
  • 새로운 사고방식이 필요함
    • 소프트웨어는 더 이상 수작업을 자동화하는 보조 수단이 아님
    • 이제는 조직의 핵심 전략, 즉 이익을 창출하는 수단이자 경쟁력을 좌우하는 자산으로 다뤄야 함
    • 소프트웨어를 비용 센터로 취급하지 말 것
    • 전략적 혁신이 곧 가시적인 결과를 만든다는 점을 인식할 것

목차

1. 이벤트 스토밍이란

이벤트 스토밍은 비즈니스 프로세스를 빠르게 모델링하고 도메인 지식을 팀 전체가 공유할 수 있도록 돕는 로우테크 협업 활동이다.

이벤트 스토밍의 핵심 목적은 비즈니스 전문가와 개발자가 공통 언어로 문제를 이해하고, 도메인을 시각화하는 것이다.
참가자는 도메인 이벤트를 포스트잇에 적고, 시간의 흐름에 따라 배열하여 진행한다.
이후 액터, 커맨드, 외부 시스템 등을 추가하며 모델을 점차 정교화한다.

최종 목표는 모델의 모든 구성 요소가 해당 도메인 프로세스를 설명할 수 있도록 만드는 것이다.

이벤트 스토밍을 통해 실수하고 그로부터 배우는 것은 저렴하다.
불필요한 포스트잇을 많이 만들었다가 제거하는 것이 너무 적게 상상하는 것보다 훨씬 낫다.

<이벤트 스토밍이 빠른 이유>

  • 로우테크 기반
    • 복잡한 도구 없이 포스트잇과 벽면만으로 진행 가능
  • 집단적 사고 유도
    • 각자 알고 있는 정보를 빠르게 공유하고, 간극을 시각화
  • 순차적 정제
    • 이벤트 → 커맨드 → 액터 → 시스템으로 점진적 확장

1.1. 원격 세션의 필요성과 한계

이벤트 스토밍은 원칙적으로 대면 활동이 효과적이지만 아래와 같은 경우엔 원격 세션이 필요할 수 있다.

  • 팀이 지리적으로 분산되어 있는 경우
  • 대면 회의가 불가능하거나 제한적인 상황
  • 지속적인 리모트 협업 환경에 최적화된 조직 구조

<원격 세션의 주요 장애 요인>

  • 통신 지연 및 실시간 협업의 품질 저하
  • 대형 디스플레이 장비의 부족
    • 전체 맥락을 보기 위해선 고해상도 디스플레이가 필요
    • 모든 참가자가 시야를 공유해야 의미있는 협업이 가능

1.2. 커맨드와 이벤트의 차이

  • 커맨드: ‘무엇을 하라’
    • 특정 작업을 수행하도록 요청하는 명령형 메시지
    • 일반적으로 동사 + 대상 형태 (SubmitPolicy, RegisterUser)
    • 사용자의 의도 또는 시스템의 요구를 표현
    • 미래 지향적: ‘무엇을 할 것이다’ 라는 목적을 가짐
    • 거부 가능: 시스템의 상태가 비즈니스 조건에 따라 거부될 수 있음
    • 트리거 역할: 하나 이상의 이벤트를 유발함
    • 예) 사용자가 보험 가입을 할 때 SubmitPolicyCommand 가 발행됨
  • 이벤트: ‘무엇이 일어났는가
    • 시스템 내에서 실제로 발생한 사실을 나타내는 불변의 기록
    • 일반적으로 과거 시제의 명사형 표현 (PolicySubmitted, UserRegistered)
    • 상태 변화의 결과를 기록하고, 다른 컴포넌트가 반응할 수 있도록 함
    • 과거 지향적: 이미 일어난 사건을 설명함
    • 불변성: 한 번 발생하면 변경되지 않음
    • 비동기적 후속 처리의 트리거로 활용됨
    • 예) 커맨드가 성공적으로 처리된 후, PolicySubmittedEvent 가 저장 및 발행됨
  • 대부분의 이벤트는 커맨드의 성공적인 실행 결과이다.
  • 하나의 커맨드는 0개 또는 다수의 이벤트를 발생시킬 수 있다.
  • 이벤트는 커맨드 없이도 발생할 수 있다. 예를 들어 시간 기반 스케쥴링은 커맨드없이 이벤트를 유발한다.
항목커맨드이벤트
방향성미래 지향과거 지향
목적작업 요청작업 결과 기록
거부 가능성있음없음 (이미 발생한 사실)
작동 시점명령 시결과 발생 후
예시SubmitOrderCommandOrderSubmittedEvent

2. 이벤트 스토밍을 통한 빠른 학습과 점진적 혁신

조직을 이루는 혁신의 깊이는 초기 목표의 질과 실행 문화에 따라 결정된다.
지식의 부족, 단기적 비전, 실패에 대한 두려움은 모두 미미한 개선 수준의 혁신에 머무르게 한다.
반면, 실험과 협업 중심의 환경은 작지만 반복 가능한 혁신의 기회를 만들어준다.

<실패에 관대한 조직이 만드는 학습 환경>

  • 우수한 조직은 실패를 즐기지 않지만, 실험을 부산물로 받아들인다.
  • ‘얼마나 많은 실패가 필요할까?’, ‘예산은 얼마나 들어갈까?’ 라는 질문은 실험 자체를 가로막는 요소이다.
  • 실제로 전구나 전화기와 같은 초기 발명조차도 계획된 실패라기보단 감수된 실패였다.
  • 핵심은 실패의 감지와 분석을 넘어, 학습과 재투자로 이어지는 구조를 조직화하는 것이다.

점진적 혁신의 사이클은 빠르고 “저렴하게 실험 → 작게 성공 → 더 큰 혁신으로 재투자” 이다.

  • 거창한 예산없이도 충분하다.
    • 소규모 파일럿 실행
    • 새로운 기술의 테스트 실행
    • 시뮬레이션을 통한 리스크 확인
  • 중요한 건 속도와 반복성이다.
    • 빠르게 학습하고, 곧바로 적용할 수 있어야 한다.

이벤트 스토밍은 협업 기반 학습 도구로, 시스템에서 발생하는 주요 사건(Event)을 시간 흐름에 따라 시각화하는 기법이다. 이 기법은 단순한 문서화가 아니라, 팀의 발견/소통/학습 활동 자체를 촉진하는 방식이다.

이벤트 스토밍은 별도의 고가 툴 없이도 실행이 가능하다. 시간 순서대로 정렬된 이벤트는 도메인 흐름을 자연스럽게 드러낸다. 팀 간 이해의 차이를 조기에 드러내고, 발견과 토론을 유도한다.

참여 대상은 역할 중심이 아닌 태도 중심의 참여가 중요하다.

  • 비전 또는 문제 의식이 있는 사람
  • 질문과 답변에 적극적으로 참여할 수 있는 사람
  • 알려지지 않은 미지를 함께 탐색할 의지가 있는 사람

이벤트 스토밍이 막히는 조직 문화의 신호는 아래와 같다.

  • 불통
    • 질문없는 회의, 대답없는 토론
  • 경쟁
    • 내부 팀 간 책임 떠넘기기
  • 적대
    • 실수를 지적하기만 하고 복구는 함께하지 않는 분위기 이러한 문화는 실험 기반 혁신을 정지시킨다.

3. 이벤트 스토밍 참석자

이벤트 스토밍 워크숍은 엔지니어, 도메인 전문가, 제품 소유자, 테스터, UI/UX 디자이너, 지원 담당자 등 누구나 참석 가능하다.
다양한 배경을 가진 사람이 많이 참여할수록 더 많은 지식이 발견된다.

단, 참가자의 규모가 너무 크면 모든 참가자가 과정에 기여하는 것이 어려워지므로 10명 이하로 하는 것을 권장한다.

  • 비전을 주도하고 추진하는 책임있는 사람
  • 중요한 비즈니스 또는 기술과 이해관계가 있는 사람
  • 탐색할 시스템에 대해 질문하거나 답변할 수 있는 사람
  • 알려진 지식과 알려진 미지를 이해하는 사람
  • 알려지지 않은 미지를 파헤치는 집념의 소유자
  • 습득한 지식을 활용해 평범함을 넘어선 성취를 얻으려는 사람

모든 사람은 마커가 있어야 하며, 포스트잇을 사용할 수 있어야 한다.

4. 이벤트 스토밍에 필요한 것

  • 모델링 공간
    • 종이로 덮인 벽 전체가 가장 좋음
  • 포스트잇
    • 색깔이 다양한 많은 양의 포스트잇
    • 모든 참가자가 자유롭게 메모를 추가할 수 있어야 함
    • 다양한 색상의 포스트잇을 구하기 어려울 수도 있으므로 각 모델 요소 유형에 대해 고유 아이콘을 정하는 것도 좋음
    • 커맨드: 하늘색
    • 이벤트: 주황색
    • 정책: 보라색
    • 애그리거트/엔티티: 옅은 노란색
    • 액터: 밝은 노란색
    • 읽기 모델: 짙은 녹색
    • 컨텍스트/외부 시스템: 밝은 분홍색
    • 기회: 연두색
      • 새로운 경쟁 우위를 활용하기 위해 탐색하고 실험할 수 있는 영역
    • 문제: 빨간색
      • 추가 탐색과 실험이 필요한 영역
    • 투표 화살표: 진한 파란색
      • 스토핑 세션이 끝난 후 모델러는 각각 2개의 진한 파란색 화살표 스티커를 붙여 모델의 기회나 문제를 가리킬 수 있음
      • 가장 많은 화살표가 가리키는 기회 또는 문제는 다음 세션에서 집중할 영역이 됨
    • 메모: 흰색
  • 마커
    • 포스트잇에 적을 때 쓸 마커
    • 너무 얇은 펜은 잘 안 보이고, 너무 굵은 펜은 잉크 번짐과 제한된 쓰기 공간으로 인해 글씨를 읽기 어려움
    • 추천은 샤피 파인 포인트 퍼머넌트 카머
  • 간식
    • 일반적으로 이벤트 스토밍은 2~4시간 정도 진행하므로 에너지 보충을 위한 간식이 필요함
  • 회의실
    • 넓은 회의실
    • 참가자가 자유롭게 이동하고 모델링 공간을 관망할 수 있도록 회의실 가운데 큰 테이블을 두지 않음
    • 참가자가 구석에 앉아있지 않고 활발하게 세션에 참여하고 지식을 공유할 수 있도록 의자도 가능하면 회의실 밖으로 치움

5. 빅픽처 모델링: 이벤트 스토밍 과정

이벤트 스토밍에서 빅필처 모델링은 탐색 중인 시스템의 전체 흐름을 발견하는 활동이다.

5.1. 1단계: 자유로운 탐색 (이벤트)

이벤트 스토밍은 탐색하려는 비즈니스 도메인에 관련된 도메인 이벤트를 브레인스토밍하는 것으로 시작한다.
도메인 이벤트는 이미 발생한 일을 설명하므로 과거형으로 작성한다.

이 단계에서 모든 참가자는 오렌지색 포스트잇에 무엇이든 떠오르는 도메인 이벤트를 적어서 모델링 공간에 붙인다.

이벤트를 많이 발견할수록 좋으며, 초기 단계에는 이벤트의 순서나 중복에 신경쓰지 않아도 된다.

새로운 이벤트가 추가되는 속도가 현저히 느려질 때까지 계속해서 도메인 이벤트를 생성한다.

자유로운 탐색

5.2. 2단계: 타임라인

생성된 도메인 이벤트를 읽어보고 비즈니스 도메인에서 발생하는 순서대로 정리한다.

정상 시나리오부터 시작하며, 정상 시나리오가 끝나면 다른 시나리오를 추가한다.
예) 에러 발생 시 경로, 다른 비즈니스 의사 결정 시

분기 흐름은 이벤트에서 2개의 흐름이나 또는 화살표로 표현한다.

분기 흐름

5.3. 3단계: 고충점: 기회와 문제

프로세스 전반에서 비효율적이거나 개선이 필요한 영역을 식별한다.
이러한 영역은 종종 병목, 중복, 불명확한 의사결정, 문서 부족 등으로 인해 문제를 일으킬 수 있다.

고충점은 2가지로 나뉠 수 있다.

  • 기회
    • 개선하거나 자동화할 여지가 있는 부분
  • 문제
    • 현재 명확히 인지된 위험이나 결함

<고충점을 식별하는 이유>

  • 문제를 조기에 드러내어 설계에 반영하기 위함
  • 전체 흐름을 시각화한 후, 팀의 경험과 직관을 활용하여 명확한 우선순위와 개선 지점을 도출
  • 향후 설계 논의에서 다시 쉽게 돌아올 수 있도록 명시적으로 기록

고충점 예시는 아래와 같다.

  • 병목 구간
    • 승인 단계에서 수작업 확인이 너무 오래 걸림
  • 자동화 기회
    • 매일 반복되는 리포트 생성 작업
  • 정보 부재
    • 특정 정책이 문서화되어 있지 않음
  • 책임 미정
    • 이벤트가 발생했지만 누가 대응해야 할 지 모호함

고충점은 핑크색 포스트잇을 돌려서 다이아몬드 형태로 표시한다.

<고충점과 모호함의 차이>

  • 고충점은 팀이 문제를 명확히 인지하고 있는 상태
    • ‘이 단계는 항상 병목이 된다’, ‘여기서 사고가 자주 발생한다’
  • 모호함은 아직 이해되지 않은 영역
    • ‘정책이 명확하지 않다’, ‘누가 담당자인지 모른다’

고충점은 명확한 개선 대상이고, 모호함은 탐색 대상이다.

아래는 예약 프로세스에서 항공권 요금이 어떻게 비교되는지에 관한 도메인 지식이 사라진 부분을 고충점으로 표시한 예시이다.

프로세스에서 주목할만한 관점을 표시

5.4. 4단계: 중요 이벤트

컨텍스트가 바뀌는 것을 나타내는 중요 이벤트인 중대한 비즈니스 이벤트를 찾는다.
중대 이벤트 전후로 세로로 선을 긋는다.

아래는 주문 과정에서 발생하는 중요한 상황 변화를 나타내는 예시이다.
예) 쇼핑 카트가 초기화됨, 주문이 생성됨..

컨텍스트 변경을 나타내는 중요 이벤트

중요 이벤트는 나중에 바운디드 컨텍스트의 후보가 된다.

5.5. 5단계: 커맨드

도메인 이벤트가 이미 발생한 것을 설명하는 반면, 커맨드는 무엇이 이벤트나 이벤트 흐름을 시작하게 하는지를 설명한다.
따라서 과거형이 아닌 명령형으로 작성한다.
예) 캠페인을 게시한다, 트랜잭션을 롤백한다..

커맨드는 파란색 포스트잇으로 작성하며, 커맨드가 생성하는 이벤트 앞에 붙인다.
특정 역할을 담당하는 액터가 특정 커맨드를 실행한다면 액터 정보는 노란색 포스트잇에 적어서 붙인다.

일반적으로 커맨드는 데이터에 대한 일부 작업을 수행하기 위한 사용자 행동의 결과이지만, 모든 커맨드가 액터와 연관되는 것은 아니다.

고객(액터)가 주문을 제출한다(커맨드)를 실행한 후, 주문이 생성됐다 등의 이벤트가 생성됨

5.6. 6단계: 정책

대부분 커맨드에는 관련된 액터가 없다.
정책 단계에서는 커맨드를 실행할 수 있는 자동화 정책을 찾는다.

정책은 반드시 충족되어야 하는 비즈니스 규칙의 집합이나 특정 조건에 따라 자동으로 실행되는 지침을 의미한다.

액터없이 자동으로 실행되는 커맨드는 이벤트에 반영하여 정책에 따라 실행되며, 이를 통해 자동화된 흐름을 모델링할 수 있다.

<자동화 정책>

  • 특정 도메인 이벤트가 발생했을 때, 별도의 액터없이 커맨드가 실행되는 규칙
    • 이벤트: 배송 승인됨
    • 커맨드: 주문 배송 시작
    • 정책: ‘배송이 승인되면 주문을 배송한다.’

정책은 보라색 포스트잇에 적어서 이벤트와 커맨드를 화살표 또는 선으로 연결한다.

배송이 승인됐다(이벤트)가 나타날 때 주문을 배송한다(커맨드)를 실행하는 자동화 정책

이벤트 스토밍 중에는 불확실하거나 깊이 논의되지 않은 영역이 발견된다.
이 때 중요한 것은 정확한 답을 내리려 애쓰지 말고, 정책 포스트잇을 통해 모호한 개념에 이름을 부여한 후 논의를 다음 단계로 진행하는 것이다.

참여자 간의 의견이 갈리면 의견 충돌 지점을 명확히 표시하고, 세션의 흐름을 끊지 않도록 다른 항목으로 우선 진행하는 것이 좋다.
이벤트 스토밍은 빠른 흐름이 핵심이다. 정답을 강요하기보다는 의문을 드러내는 것 자체에 가치가 있다.

<조건부 정책>
특정 조건을 만족할 때만 커맨드를 실행해야 한다면, 그 조건을 정책 포스트잇에 명시한다.

  • 이벤트: 불만 접수됨
  • 커맨드: 상부 보고
  • 조건: ‘VIP 고객일 경우에만’

모델링 공간에서 이벤트와 커맨드가 멀리 떨어져있다면 화살표를 그려서 연결한다.

4.7. 7단계: 읽기 모델

읽기 모델은 도메인 내 액터가 커맨드를 실행하기 전에 의사결정을 내리는 데 사용하는 정보의 원천을 의미한다.
이벤트 스토밍에서는 이를 통해 도메인 내에서 어떤 데이터가 어떤 용도로 사용되는지를 시각적으로 드러낸다.

<읽기 모델의 목적>

  • 액터의 판단이 어떤 정보를 바탕으로 이루어지는지 명확하게 모델링
  • 시스템이 의도한 행동을 유도하기 위한 데이터 구조의 필요성을 설명

<읽기 모델의 역할>

  • 단순한 데이터 조회가 아니라 의사결정을 유도하기 위해 사전 구성된 정보 집합임
  • 목적 지향적
  • 특정 문맥에 맞춰 전처리됨
  • 시각화 또는 집계 형태로 표현될 수 있음

<읽기 모델의 필요성>

  • 데이터 명시화
    • 커맨드 실행 전에 필요한 정보가 무엇인지 드러냄
  • 설계 기반 제공
    • 시스템에서 어떤 형태의 데이터를 미리 준비해야 하는지 정의
  • UX 고려 요소
    • 액터가 정보에 어떻게 접근하고 해석할 것인지 고려 가능
  • 비즈니스 정합성
    • 커맨드 실행 조건을 명확히 하여 규칙 누락 방지

읽기 모델은 녹색 포스트잇에 액터의 의사결정을 도울 때 필요한 정보의 원천에 대해 짧게 기재한다.
액터가 이 읽기 모델을 참고하여 커맨드를 실행하므로 커맨드 앞에 읽기 모델을 둔다.

고객(액터)이 주문(커맨드)을 제출하는 의사결정을 위해 필요한 쇼핑카트(읽기 모델) 뷰

5.8. 8단계: 외부 시스템

외부 시스템과의 연동 구조를 모델에 통합한다.

외부 시스템이란 현재 탐색 중인 도메인에 직접 포함되지 않은 시스템을 의미한다.
이 단계의 목적은 도메인의 경계를 명확히 하고, 외부와의 입출력 흐름을 시각적으로 드러내는 것이다.

<외부 시스템의 2가지 역할>

  • 입력 시스템
    • 외부 시스템이 우리 도메인의 커맨드를 유발할 수 있다.
    • 예) CRM 시스템이 ‘주문 배송 시작’ 커맨드를 시작
  • 출력 시스템
    • 내부 도메인에서 발생한 이벤트가 외부 시스템으로 전달될 수 있다.
    • 예) ‘배송 승인됨’ 이벤트가 발생하면 CRM 시스템에 알림 전송

외부 시스템은 핑크색 포스트잇으로 표시한다.

아래는 외부 시스템인 CRM 과의 상호작용 흐름 예시이다.

커맨드의 실행을 시작하는 외부 시스템과 외부 시스템에 전달되는 이벤트의 승인

  • CRM(외부 시스템)이 주문 배송 시작 커맨드를 직접 실행한다.(입력)
  • 내부 도메인에서 배송 승인됨 이벤트가 발생하면,
  • 정책을 통해 CRM 에 알림을 전달한다. (출력)

이처럼 이벤트 ↔ 정책 ↔ 커맨드 ↔ 외부 시스템 구조로 구성되며, 외부와 내부의 연결 경로를 명확하게 모델링할 수 있다.

5.9. 9단계: 애그리거트/엔티티

모든 이벤트와 커맨드가 표현되면 애그리거트의 개념을 포함하여 모델을 구성할 수 있다.
애그리거트는 커맨드를 받아서 이벤트를 생성한다.

애그리거트는 커다란 노란색 포스트잇으로 기재하고, 왼쪽에 커맨드를 두고 오른쪽에 이벤트를 둔다.

애그리거트에 구성된 커맨드와 이벤트

5.10. 10단계: 바운디드 컨텍스트

이제 서로 연관된 애그리거트를 찾는다.
애그리거트의 그룹은 바운디드 컨텍스트 경계의 후보가 된다.

시스템을 바운디드 컨텍스트로 분리

6. 변형

이벤트 스토밍의 진행 과정을 반드시 따라야하는 것은 아니다.
상황에 잘 맞게 진행 과정에 대해 자유롭게 변형을 해도 좋다.

이벤트 스토밍이 끝나면 도메인 이벤트, 커맨드, 애그리거트, 바운디드 컨텍스트 후보를 포함한 모델을 얻게 된다.
뿐만 아니라 다양한 이해관계자 간의 지식 공유, 비즈니스와 멘탈 모델의 일치, 충돌 모델 발견, 유비쿼터스 언어 구축을 할 수 있다.

7. 이벤트 스토밍을 사용하는 경우

  • 유비쿼터스 언어 구축
  • 비즈니스 프로세스 모델링
  • 새로운 비즈니스 요구사항 탐색
  • 도메인 지식 복구
  • 기존 비즈니스 프로세스의 개선 방법 탐색
  • 새로운 팀원의 훈련

8. 진행 팁

이벤트스토밍을 처음 해보는 그룹을 대상으로 진행할 때는 시작할 때 진행 개요를 빠르게 소개한다.
참가자들이 이벤트, 커맨드, 액터 등 모델링 요소에 부여된 색을 기억하기 쉽게 포스트잇을 사용하여 워크샵이 진행되는 동안 모든 참가자들이 볼 수 있게 붙여둔다.

그룹 활동의 활발함이 떨어지면 질문을 던져서 과정을 돕거나 워크숍의 다음 단계로 넘어갈지를 결정한다.
이벤트 스토밍은 집중적인 활동이기 때문에 휴식이 필요한데, 휴식 후 다시 시작할 때는 회의실에 모든 참가자가 돌아오기 전까지는 시작하지 않는다.
시작할 때는 현재까지 진행된 모델링을 리뷰해서 모든 참가자가 협력적인 모델링 분위기로 돌아오도록 돕는다.

이벤트 스토밍은 대면으로 하는 것이 가장 효과적이지만, 그렇지 못할 경우 miro.com 이라는 서비스를 이용하는 것도 괜찮다.
원격 이벤트 스토밍은 참가자의 수가 적을 때 더욱 효과적이다.
대면 이벤트 스토밍은 10명 정도 참가가 가능하지만, 원격 이벤트 스토밍은 5명 정도로 제한하는 것이 좋다.
더 많은 참가자가 지식 공유를 해야한다면 세션을 나누어서 진행한 후 각각의 결과를 비교해서 취합된 모델을 만든다.

정리하며..

  • 이벤트 스토밍은 협업을 통해 비즈니스 프로세스를 모델링하는 워크숍임
  • 도출된 모델 외에 지식 공유라는 이점을 얻을 수 있음
  • 실패에 관대한 문화 속에서 안전하고 신속한 실험을 가능하게 하는 것이 혁신적인 환경을 만드는 열쇠임
  • 이벤트 우선 모델링은 모든 이해관계자가 의사소통을 하는데 발생하는 간극을 해소함
  • 이벤트 우선 모델로 실험을 추진하면 능동적인 학습을 할 수 있게 되며, 사람이나 도구에 더 적은 비용을 지불하면서 지식을 습득하는 것을 가속화할 수 있음
  • 이벤트 스토밍은 기존 비즈니스 조직 간 의사소통의 단절 문제를 극복함으로써 부서 간 협력을 가능하게 함
  • 이벤트를 검토하여 모델링 작업을 시작하면 팀이 건설적인 피드백을 활용하고 비즈니스 소트프웨어 복잡성을 이해함으로써 심층 학습을 빠르게 추진할 수 있음

참고 사이트 & 함께 보면 좋은 사이트

본 포스트는 블라드 코노노프 저자의 도메인 주도 설계 첫걸음과 반 버논, 토마스 야스쿨라 저자의 전략적 모놀리스와 마이크로서비스 를 기반으로 스터디하며 정리한 내용들입니다.




© 2020.08. by assu10

Powered by assu10