B컷전문 | 개발과 인생의 이야기

도메인 주도 설계 이후, 이벤트 기반 아키텍처로 확장

 

지난 회차에서 도메인 주도 설계(DDD)를 중심으로 도메인 로직을 어떻게 구조화할 수 있는지 살펴봤습니다. 이번에는 그 연장선에서, 최근 아키텍처 설계 시 자주 등장하는 이벤트 소싱(Event Sourcing) 개념과 이를 도입할 때 반드시 고려해야 할 실무 포인트를 살펴보려 합니다.

 

이벤트 소싱은 단순한 ‘데이터 저장 방식’이 아닙니다. 도메인의 상태를 ‘이벤트의 흐름’으로 저장하고 해석하는 새로운 접근 방식이며, 복잡한 업무 로직이 존재하는 시스템에서 특히 큰 장점을 가집니다.

 

---

이벤트 소싱이란?

 

이벤트 소싱은 기존의 CRUD 모델처럼 데이터베이스에 현재 상태만 저장하는 것이 아니라, 모든 상태 변화를 이벤트 단위로 기록하는 방식입니다. 즉, 도메인의 상태는 ‘지금의 상태’가 아니라, ‘이전에 어떤 일들이 있었는가’로 구성되는 것입니다.

 

예를 들어 쇼핑몰에서 주문을 처리하는 경우:

 

• OrderCreated
• PaymentCompleted
• OrderShipped
• OrderCancelled

 

이런 이벤트들이 순서대로 기록되며, 시스템은 이 이벤트들을 **재생(replay)**해서 현재 상태를 계산합니다.

 

---

이벤트 소싱의 핵심 장점

 

1. 완전한 변경 이력 추적 가능
2. 모든 변경은 이벤트로 남기 때문에, 어떤 사용자가 언제 어떤 작업을 했는지를 100% 추적할 수 있습니다.
3. 강력한 감사 기능(Audit)
4. 금융, 헬스케어 등 규제가 엄격한 산업에서는 변경 이력 추적이 필수입니다. 이벤트 소싱은 이 점에서 탁월한 기반이 됩니다.
5. 시간여행(Timetravel)
6. 과거 특정 시점의 상태를 복원하거나, ‘만약 그때 이 이벤트가 없었다면?’이라는 가정 하에 시뮬레이션이 가능합니다.
7. CQRS와의 궁합
8. 이벤트 소싱은 커맨드와 쿼리를 분리하는 CQRS(Command Query Responsibility Segregation) 패턴과 매우 잘 어울립니다. 이벤트가 곧 커맨드 처리 결과이기 때문입니다.

 

---

실무에서 도입 시 고려사항

 

하지만 이벤트 소싱이 마법은 아닙니다. 다음과 같은 주의점이 반드시 필요합니다.

 

1. 복잡도 증가
2. 단순한 CRUD 시스템에서는 이벤트 소싱은 과도할 수 있습니다. 모든 이벤트를 정의하고 버전 관리하며, 상태를 재구성하는 로직을 설계해야 합니다.
3. 이벤트 저장소 설계 필요
4. RDB가 아닌 별도의 이벤트 스토어(예: Kafka, EventStoreDB, DynamoDB 등)를 사용하는 경우가 많습니다. 저장소의 내구성과 일관성 전략도 함께 고민해야 합니다.
5. 리플레이 비용
6. 이벤트가 많아질수록 시스템 기동 시 리플레이 비용이 커집니다. 따라서 중간 상태를 스냅샷(snapshot)으로 저장하는 전략이 병행되어야 합니다.
7. 데이터 정합성 관리
8. 분산 시스템 환경에서 ‘이벤트 순서 보장’은 매우 중요한 이슈입니다. 멱등성 처리, 이벤트 재처리 정책 등도 함께 설계해야 합니다.

 

---

적합한 도메인 예시

 

• 금융거래 시스템 (예: 계좌 입출금 이력)
• 주문/배송 추적 시스템
• IoT 센서 이벤트 기록
• 보험/청구 기록 시스템
• 헬스케어의 진료/투약 이력

 

---

아키텍트의 전략적 판단 포인트

 

이벤트 소싱은 정말 필요한 도메인에서만 선택적으로 도입되어야 합니다. 특히 다음 조건 중 다수에 해당할 경우, 이벤트 소싱을 고려할 만합니다:

 

• 상태 변경의 의미가 중요할 때
• 상태의 추적 및 재현이 중요한 도메인일 때
• CQRS를 병행하거나 분산 아키텍처가 필요한 경우

 

이벤트 소싱은 단순한 기술이 아니라 사고방식의 전환입니다. ‘상태 중심’에서 ‘이력 중심’으로의 전환은 코드뿐 아니라 개발자와 조직의 마인드셋까지 바꾸어야 가능한 일입니다.

 

모든 시스템에 적합한 것은 아니지만, 정확한 도메인 해석과 목적이 명확한 경우에는 분명히 강력한 무기가 될 수 있습니다.