1.2 이벤트 스토밍 준비

1. 이벤트 스토밍 이해하기

1.1 이벤트 스토밍이란?

이벤트 스토밍(Event Storming)은 알베르토 브란디니(Alberto Brandolini)가 개발한 워크숍 기법으로, 복잡한 비즈니스 도메인을 이해하고 모델링하는 데 사용됩니다. 이 기법은 도메인 전문가와 개발자 간의 협업을 촉진하여 시스템의 이벤트 흐름을 시각화하는 데 중점을 둡니다. 다양한 이해관계자들이 한자리에 모여 시스템의 이벤트를 식별하고, 이를 통해 도메인의 전반적인 구조와 상호작용을 명확하게 이해할 수 있습니다.

1.2 목적과 장점

이벤트 스토밍은 다음과 같은 세 가지 주요 영역에서 가치를 제공합니다:

도메인 이해도 향상을 통해 다음과 같은 이점을 얻을 수 있습니다:

• 도메인 전문가와 개발자가 공통 언어를 사용하여 효과적으로 지식을 공유할 수 있습니다.
• 복잡한 비즈니스 프로세스를 시각적으로 표현하여 전체 흐름을 직관적으로 파악할 수 있습니다.
• 도메인의 핵심 로직을 발견하고 이를 중심으로 설계를 진행할 수 있습니다.
• 암묵적인 업무 지식과 규칙을 명시적으로 도출하여 문서화할 수 있습니다.

협업 효율성 측면에서는 다음과 같은 장점이 있습니다:

• 참여자들이 실시간으로 피드백을 주고받으며 즉각적인 조정이 가능합니다.
• 다양한 이해관계자들이 함께 모여 상호 이해도를 높일 수 있습니다.
• 직접 대화를 통해 문서 기반 의사소통 대비 의사소통 비용을 크게 절감할 수 있습니다.
• 시각적 도구를 활용한 토론을 통해 신속한 합의점 도출이 가능합니다.

설계 품질 향상 측면에서는 다음과 같은 이점을 제공합니다:

• 도메인 중심 사고를 통해 효과적인 도메인 주도 설계를 구현할 수 있습니다.
• 핵심 비즈니스 로직을 식별하고 이를 중심으로 설계를 진행할 수 있습니다.
• 업무 경계와 맥락이 자연스럽게 도출되어 마이크로서비스 설계에 적합합니다.
• 프로젝트 전반에 걸쳐 사용할 공통 언어를 정립하여 일관된 커뮤니케이션이 가능합니다.

1.3 도서관 시스템에서의 적용

도서관 시스템은 이벤트 스토밍을 적용하기에 매우 적합한 도메인입니다. 도서 대출이라는 핵심 프로세스를 중심으로 다양한 이벤트와 규칙들이 존재하며, 이를 이벤트 스토밍을 통해 효과적으로 모델링할 수 있습니다.

예를 들어, 도서 대출 프로세스의 주요 이벤트 체인을 살펴보면 다음과 같습니다:

도서대출됨 → 반납기한알림발송됨 → 도서반납됨

이러한 이벤트 체인을 통해 우리는 다음과 같은 인사이트를 얻을 수 있습니다:

• 대출 프로세스의 전체 흐름과 각 단계별 상태 변화를 파악할 수 있습니다.
• 각 단계에서 적용되어야 하는 비즈니스 규칙(예: 대출 가능 여부 확인, 연체 관리 등)을 발견할 수 있습니다.
• 시스템이 자동으로 처리해야 하는 중요한 시점들(예: 반납 기한 알림 발송)을 식별할 수 있습니다.
• 사용자와 시스템 간의 상호작용 지점들을 명확히 할 수 있습니다.

2. 이벤트 스토밍의 구성요소

이벤트 스토밍은 서로 다른 색상의 스티커를 사용하여 도메인의 다양한 요소들을 시각화합니다. 각 색상은 특정한 의미를 가지며, 이들의 조합을 통해 전체 시스템의 동작을 표현합니다.

2.1 도메인 이벤트 (주황색 스티커)

도메인 이벤트(Domain Event)는 시스템 내에서 발생하는 의미 있는 상태 변화나 사건을 표현합니다. 이는 이벤트 스토밍의 가장 기본적인 구성 요소이며, 다음과 같은 특징을 가집니다:

• 항상 과거 시제로 표현하여 이미 발생한 사실임을 명확히 합니다.
• 도메인에서 중요한 상태 변화를 나타냅니다.
• “목적어 + 동사의 과거형” 형태로 표현합니다.
• 시스템의 다른 부분에 영향을 미칠 수 있는 중요한 사건을 나타냅니다.

도메인 이벤트의 좋은 예시와 피해야 할 예시를 살펴보겠습니다:

// 좋은 도메인 이벤트의 예시
도서대출됨              - 명확한 비즈니스적 의미를 가집니다
회원가입승인됨          - 상태 변화가 명확합니다
대출기한초과알림발송됨   - 중요한 비즈니스 사건을 표현합니다

// 피해야 할 예시
데이터베이스업데이트됨   - 기술적 구현에 가깝습니다
회원정보변경            - 현재형이라 부적절합니다
도서확인                - 이벤트가 아닌 단순 동작입니다

2.2 커맨드 (파란색 스티커)

커맨드(Command)는 도메인 이벤트를 발생시키는 직접적인 계기가 되는 명령이나 의도를 표현합니다. 커맨드는 사용자나 시스템의 의도적인 행위를 나타내며, 다음과 같은 특징을 가집니다:

• 명령형으로 표현하여 의도를 명확히 합니다.
• “동사원형 + 목적어” 형태로 작성합니다.
• 특정 액터(사용자 또는 시스템)가 수행하는 행위입니다.
• 하나 이상의 도메인 이벤트를 발생시킬 수 있습니다.

다음은 도서관 시스템에서 커맨드와 이벤트의 관계를 보여주는 예시입니다:

도서대출하기 → 도서대출됨
(커맨드)      (도메인 이벤트)

// 복잡한 프로세스의 예
회원가입신청하기 → 회원가입신청됨 → 회원가입승인하기 → 회원가입승인됨

2.3 애그리거트 (노란색 스티커)

애그리거트(Aggregate)는 관련된 객체들의 집합으로, 일관성과 트랜잭션의 경계를 정의합니다. 애그리거트는 다음과 같은 특징을 가집니다:

• 동일한 생명주기를 가진 객체들의 집합입니다.
• 일관성을 보장해야 하는 비즈니스 규칙의 경계를 형성합니다.
• 커맨드를 처리하고 이벤트를 발생시키는 주체입니다.
• 하나의 루트 엔티티를 중심으로 구성됩니다.

도서관 시스템의 주요 애그리거트 예시:

[도서]
- ISBN, 제목, 저자 정보
- 출판 정보
- 분류 정보

[도서 복본]
- 도서 식별자
- 대출 상태
- 물리적 상태 정보

[회원]
- 회원 정보
- 대출 이력
- 연체 상태

2.4 정책 (보라색 스티커)

정책(Policy)은 특정 이벤트가 발생했을 때 자동으로 수행되어야 하는 비즈니스 규칙이나 프로세스를 정의합니다. 정책은 다음과 같은 특징을 가집니다:

• 이벤트에 반응하여 자동으로 실행됩니다.
• 명확한 조건과 결과를 가집니다.
• 시스템의 자동화된 처리를 정의합니다.
• 여러 개의 후속 커맨드나 이벤트를 발생시킬 수 있습니다.

정책은 다음과 같은 형식으로 표현합니다:

[도서반납됨 발생 시]
- 예약자가 있는지 확인합니다
- 도서의 물리적 상태를 검사합니다
- 다음 예약자에게 대출 가능 알림을 발송합니다

[대출기한초과됨 발생 시]
- 회원의 연체 상태를 업데이트합니다
- 연체 알림을 발송합니다
- 추가 대출을 제한합니다

2.5 읽기 모델 (초록색 스티커)

읽기 모델(Read Model)은 시스템의 상태를 조회하기 위해 최적화된 데이터 뷰를 제공합니다. 읽기 모델은 다음과 같은 특징을 가집니다:

• 하나 이상의 이벤트에 의해 업데이트됩니다.
• 사용자의 조회 요구사항에 최적화되어 있습니다.
• 데이터의 일관성보다는 조회 성능에 초점을 맞춥니다.
• 필요한 정보만을 포함하여 간결성을 유지합니다.

읽기 모델의 예시:

도서 검색 뷰
- 조회 항목: 제목, 저자, ISBN, 현재 대출 가능 여부, 예약 현황
- 업데이트 트리거: 도서등록됨, 도서대출됨, 도서반납됨
- 정렬 기준: 제목, 저자, 출판일

대출 현황 뷰
- 조회 항목: 대출 도서 목록, 반납 예정일, 연체 상태
- 업데이트 트리거: 도서대출됨, 도서반납됨, 연체상태변경됨
- 필터링: 현재 대출 중, 반납 완료, 연체 중

3. 워크샵 진행 방식

이벤트 스토밍의 성공은 체계적인 준비와 효과적인 실행에 달려있습니다. 이 섹션에서는 워크샵을 준비하고 진행하는 전체 과정을 상세히 살펴보겠습니다.

3.1 사전 준비 단계

워크샵의 성공을 위해서는 철저한 사전 준비가 필수적입니다. 사전 준비는 참여자 구성부터 물리적 환경 설정까지 다양한 측면을 고려해야 합니다.

3.1.1 참여자 구성 및 준비

참여자의 구성은 워크샵의 품질을 결정하는 가장 중요한 요소입니다. 각 역할별로 적합한 참여자를 신중하게 선정하고, 효과적인 워크샵 진행을 위한 사전 준비를 수행해야 합니다.

참여자 선정 시에는 다음과 같은 기준을 고려해야 합니다:

• 도메인에 대한 전문성과 경험 수준을 갖추고 있는지 확인합니다.
• 해당 영역에서 실질적인 의사결정 권한을 보유하고 있는지 검토합니다.
• 워크샵 전 과정에 지속적으로 참여할 수 있는지 확인합니다.
• 타인과의 효과적인 의사소통 능력과 협업 의지를 갖추고 있는지 평가합니다.

선정된 참여자들을 위한 사전 오리엔테이션은 다음 내용을 포함해야 합니다:

• 이벤트 스토밍의 목적과 기대효과에 대한 명확한 설명
• 각 참여자의 역할과 책임에 대한 상세한 안내
• 워크샵의 전반적인 진행 방식과 지켜야 할 규칙들
• 참여자들이 준비해야 할 사항과 참고할 수 있는 자료

3.1.2 환경 설정

워크샵 환경은 참여자들의 집중도와 협업 효율성에 직접적인 영향을 미칩니다. 진행 방식에 따라 물리적 환경 또는 온라인 환경을 적절히 구성해야 합니다.

오프라인 환경을 구성할 때는 다음 사항을 고려합니다:

• 충분한 크기의 벽면 또는 화이트보드가 필요합니다(최소 5-6미터 길이).
• 참가자들이 자유롭게 움직일 수 있는 충분한 공간을 확보합니다(참가자당 최소 2㎡).
• 장시간 집중할 수 있도록 적절한 조명과 환기 시설을 갖춥니다.
• 참가자들이 휴식을 취할 수 있는 별도의 공간과 다과를 준비합니다.

온라인 환경을 구성할 때는 다음 사항을 준비합니다:

• Miro나 Mural과 같은 협업 도구의 작업 공간을 미리 구성합니다.
• 안정적인 화상회의 도구를 설정하고 사전에 테스트를 진행합니다.
• 모든 참여자에게 필요한 접속 권한을 부여하고 확인합니다.
• 기술적 문제 발생 시를 대비한 백업 도구와 대체 수단을 준비합니다.

3.1.3 워크샵 규칙 수립

효과적인 워크샵 진행을 위해서는 명확한 규칙과 가이드라인이 필요합니다. 이는 참여자들의 적극적인 참여를 유도하고 워크샵의 목표 달성을 돕습니다.

시간 관리에 관한 규칙은 다음과 같이 설정합니다:

• 전체 워크샵은 4-6시간을 기준으로 진행합니다.
• 각 세션별로 명확한 시간 배분을 설정합니다.
• 90분마다 15분의 휴식 시간을 제공합니다.
• 시작과 종료 시간을 정확히 준수합니다.

의사소통 규칙은 다음 사항을 포함합니다:

• 모든 참여자에게 발언 기회를 공평하게 제공합니다.
• 건설적인 피드백을 주고받는 방식을 정립합니다.
• 의견 충돌이 발생했을 때의 조정 방법을 사전에 합의합니다.
• 중요한 결정사항을 기록하는 방식을 정합니다.

3.2 워크샵 실행 단계

워크샵 실행은 체계적인 프로세스에 따라 진행하되, 상황에 따라 유연하게 조정할 수 있어야 합니다. 각 단계별로 충분한 시간을 할애하고, 모든 참여자의 의견이 반영될 수 있도록 합니다.

3.2.1 도메인 이벤트 도출 (60-90분)

도메인 이벤트 도출은 전체 워크샵의 기초가 되는 매우 중요한 단계입니다. 이 단계에서는 시스템에서 발생하는 모든 중요한 변화나 사건을 식별합니다.

진행자는 다음과 같이 단계를 이끌어갑니다:

• 참여자들에게 주황색 스티커를 나누어주고, 자유롭게 도메인 이벤트를 작성하도록 합니다.
• 모든 이벤트는 반드시 과거형으로 작성하도록 안내합니다.
• 작성된 이벤트들을 시간 순서대로 벽면에 배치하도록 합니다.
• 유사하거나 관련된 이벤트들을 그룹화하도록 유도합니다.

이 단계에서 특히 중요한 점검 사항은 다음과 같습니다:

• 비즈니스에서 중요한 모든 이벤트가 포함되었는지 확인합니다.
• 이벤트들이 적절한 크기로 분할되었는지 검토합니다.
• 이벤트 간의 시간적 순서가 명확한지 확인합니다.
• 중요한 이벤트가 누락되지 않았는지 재검토합니다.

3.2.2 커맨드와 액터 식별 (45-60분)

도메인 이벤트를 식별한 후에는, 각 이벤트를 발생시키는 커맨드와 그 커맨드를 실행하는 액터를 파악합니다. 이 단계는 시스템의 상호작용을 이해하는 데 매우 중요합니다.

진행자는 참여자들에게 다음과 같이 안내합니다: “이제 각 이벤트가 어떻게 발생하게 되었는지 살펴보겠습니다. 각 이벤트의 왼쪽에 파란색 스티커로 이벤트를 발생시키는 명령이나 동작을 적어주세요. 그리고 그 명령을 누가 수행하는지도 함께 생각해보겠습니다.”

이 단계에서는 다음 사항들을 중점적으로 검토합니다:

• 모든 이벤트가 명확한 트리거(커맨드)를 가지고 있는지 확인합니다.
• 각 커맨드를 실행하는 액터의 권한과 책임이 적절한지 검토합니다.
• 자동화가 가능한 프로세스를 식별하고 표시합니다.
• 커맨드 실행에 필요한 전제 조건들을 명확히 합니다.

예를 들어, 도서관 시스템에서는 다음과 같은 흐름이 나타날 수 있습니다:

[회원]           [사서]           [시스템]
도서대출신청 →   대출승인     →   연체여부확인
   ↓               ↓              ↓
도서대출신청됨    도서대출됨    대출가능여부확인됨

3.2.3 애그리거트 도출 (60-90분)

애그리거트 도출 단계에서는 관련된 커맨드와 이벤트들을 중심으로 일관성을 유지해야 하는 객체들의 경계를 정의합니다. 이는 시스템의 구조를 결정하는 중요한 단계입니다.

진행자는 다음과 같이 단계를 이끌어갑니다: “지금까지 파악한 커맨드와 이벤트들을 살펴보면서, 이들이 다루는 핵심 객체들을 찾아보겠습니다. 노란색 스티커에 이 객체들을 적어주시고, 관련된 커맨드와 이벤트 근처에 배치해주세요.”

애그리거트를 도출할 때는 다음 사항들을 고려합니다:

• 함께 변경되어야 하는 데이터들을 하나의 경계로 묶습니다.
• 트랜잭션의 범위가 현실적으로 관리 가능한지 검토합니다.
• 애그리거트 간의 참조 관계를 최소화하여 결합도를 낮춥니다.
• 각 애그리거트가 자신의 불변식을 독립적으로 관리할 수 있는지 확인합니다.

3.2.4 정책 정의 (45-60분)

정책 정의 단계에서는 특정 이벤트가 발생했을 때 시스템이 자동으로 수행해야 하는 업무 규칙들을 정의합니다. 이는 시스템의 자동화된 처리 로직을 설계하는 중요한 과정입니다.

진행자는 참여자들에게 다음과 같이 안내합니다: “각 이벤트가 발생한 후에 시스템이 자동으로 처리해야 하는 업무들을 살펴보겠습니다. 보라색 스티커에 이러한 정책들을 작성하고, 해당 이벤트 근처에 배치해주세요.”

정책을 정의할 때는 다음 사항들을 주의 깊게 검토합니다:

• 정책이 충분히 구체적이고 실행 가능한지 확인합니다.
• 정책 실행의 전제 조건과 예외 상황을 명확히 정의합니다.
• 여러 정책 간의 우선순위와 실행 순서를 결정합니다.
• 정책 실행 결과가 다른 이벤트나 프로세스에 미치는 영향을 고려합니다.

3.2.5 경계 설정과 검토 (60분)

마지막으로, 지금까지 도출한 모든 요소들을 검토하고 시스템의 경계를 설정합니다. 이 단계는 전체 결과물의 완성도를 높이고 실제 구현 가능성을 검증하는 중요한 과정입니다.

진행자는 다음과 같이 검토를 이끌어갑니다: “지금까지 파악한 내용들을 전체적으로 살펴보면서, 서로 밀접하게 관련된 기능들을 경계선으로 묶어보겠습니다. 또한 각 영역 간의 상호작용도 확인해보겠습니다.”

이 단계에서는 다음 사항들을 중점적으로 검토합니다:

• 식별된 경계들이 현실적이고 관리 가능한지 확인합니다.
• 경계 간의 의존관계가 적절한지 검토합니다.
• 누락되거나 불명확한 부분이 없는지 확인합니다.
• 전체 프로세스의 일관성과 완전성을 검증합니다.

3.3 후속 조치

워크샵이 끝난 후에도 결과물을 효과적으로 활용하고 지속적으로 개선하기 위한 활동이 필요합니다.

3.3.1 결과물 정리

워크샵의 결과물을 체계적으로 정리하여 문서화합니다:

• 식별된 모든 이벤트, 커맨드, 정책들을 디지털 형태로 변환합니다.
• 주요 결정사항과 그 근거를 명확히 기록합니다.
• 워크샵 과정에서 발견된 이슈들을 목록화합니다.
• 참여자들의 피드백을 수집하고 분석합니다.

3.3.2 이행 계획 수립

워크샵 결과물을 실제 시스템으로 구현하기 위한 계획을 수립합니다:

• 도출된 설계를 바탕으로 구체적인 구현 계획을 작성합니다.
• 개발 우선순위와 단계별 목표를 설정합니다.
• 필요한 자원을 파악하고 제약사항을 식별합니다.
• 잠재적 리스크와 그 대응 방안을 수립합니다.

이벤트 스토밍 워크샵은 반복적인 수행을 통해 지속적으로 개선될 수 있습니다. 각 진행 단계에서 발생하는 문제점과 개선사항을 기록하고, 다음 워크샵에 이를 반영하여 더 나은 결과를 도출할 수 있도록 합니다.