📚 커리큘럼
PART 2 · 강의 3/4

이벤트 기반
아키텍처

Event-Driven Architecture, CQRS, Event Sourcing 패턴으로 확장 가능하고 느슨하게 결합된 시스템을 설계합니다.

01

이벤트 기반 아키텍처란?

Event-Driven Architecture (EDA)의 핵심 개념

"시스템의 상태 변화를 이벤트로 표현하고, 이벤트에 반응하여 동작하는 아키텍처"

느슨한 결합, 확장성, 실시간 처리를 가능하게 하는 핵심 패턴

이벤트 흐름 시각화

📤
Producer

이벤트 발행

📨
Event Broker

이벤트 중개

📥
Consumer

이벤트 처리

📌 EDA의 핵심 특징
  • 비동기 통신 — Producer와 Consumer가 독립적으로 동작
  • 느슨한 결합 — 서비스 간 직접 의존성 제거
  • 확장성 — Consumer를 독립적으로 스케일링 가능
  • 실시간 처리 — 이벤트 발생 즉시 반응 가능
02

CQRS 패턴

Command Query Responsibility Segregation

💡 CQRS란?

읽기(Query)와 쓰기(Command)를 분리하여 각각 최적화된 모델로 처리하는 패턴입니다. 복잡한 도메인에서 읽기/쓰기 요구사항이 다를 때 효과적입니다.

✏️

Command Side (쓰기)

1️⃣ Command 수신 (CreateOrder, UpdateUser...)
2️⃣ 비즈니스 로직 검증
3️⃣ Write Model에 저장
4️⃣ 도메인 이벤트 발행
🔍

Query Side (읽기)

1️⃣ 이벤트 구독 (Event Handler)
2️⃣ Read Model 갱신 (비정규화)
3️⃣ Query 처리 (최적화된 조회)
4️⃣ 결과 반환 (빠른 응답)
⚡

성능 최적화

읽기/쓰기 각각에 최적화된 데이터 모델과 저장소 사용

📈

독립적 확장

읽기 부하가 높으면 Query Side만 스케일 아웃

🔒

보안 분리

쓰기와 읽기에 다른 보안 정책 적용 가능

03

Event Sourcing

이벤트를 통한 상태 관리

⚠️ Event Sourcing이란?

현재 상태를 직접 저장하는 대신, 상태를 변경한 모든 이벤트를 순서대로 저장합니다. 현재 상태는 이벤트들을 재생(replay)하여 계산합니다.

주문 처리 이벤트 타임라인

T1: 10:00:00
OrderCreated
{ orderId: "ORD-001", items: [...], total: 50000 }
T2: 10:05:00
PaymentReceived
{ orderId: "ORD-001", amount: 50000, method: "card" }
T3: 10:30:00
OrderShipped
{ orderId: "ORD-001", carrier: "FastShip", tracking: "TRK123" }
T4: 11:00:00
ItemReturned
{ orderId: "ORD-001", itemId: "ITEM-002", reason: "defect" }
T5: 11:30:00
RefundProcessed
{ orderId: "ORD-001", amount: 15000 }
📌 Event Sourcing 장점
  • 완전한 감사 추적 — 모든 변경 이력이 이벤트로 보존됨
  • 시간 여행 — 특정 시점의 상태를 재구성할 수 있음
  • 디버깅 용이 — 문제 발생 시 이벤트 재생으로 원인 파악
  • 이벤트 재처리 — 버그 수정 후 이벤트 재생으로 데이터 복구
04

인터랙티브 데모

이벤트 발행과 구독 체험하기

이벤트 시뮬레이터

[시스템] 이벤트 시뮬레이터가 준비되었습니다. 버튼을 클릭하여 이벤트를 발행해보세요.
💡 실제 활용 사례

이커머스 플랫폼에서 주문 이벤트가 발행되면, 재고 서비스는 재고를 감소시키고, 알림 서비스는 고객에게 이메일을 보내고, 분석 서비스는 주문 통계를 업데이트합니다. 각 서비스는 독립적으로 동작합니다.

05

패턴 비교 및 적용

언제 어떤 패턴을 사용할까?

특성 기본 EDA CQRS Event Sourcing
복잡도 낮음 중간 높음
주요 목적 서비스 분리 읽기/쓰기 최적화 이벤트 이력 보존
적합한 경우 마이크로서비스 통신 읽기 부하 >> 쓰기 부하 감사 추적 필수
데이터 일관성 최종 일관성 최종 일관성 강한 일관성 가능
⚠️ 주의사항

이벤트 기반 아키텍처는 강력하지만 복잡성을 증가시킵니다. 단순한 CRUD 애플리케이션에는 오버엔지니어링이 될 수 있습니다. 비즈니스 요구사항과 팀의 역량을 고려하여 적절한 수준의 패턴을 선택하세요.

SUMMARY

핵심 요약

  • EDA는 이벤트를 통해 느슨하게 결합된 비동기 시스템을 구축하는 패턴
  • CQRS는 읽기와 쓰기를 분리하여 각각 최적화하는 패턴
  • Event Sourcing은 상태 대신 이벤트를 저장하여 완전한 이력을 보존
  • 세 패턴은 함께 사용될 때 시너지가 높음
  • 복잡성과 이점을 고려하여 적절한 수준의 패턴을 선택해야 함