기술과 산업/아키텍처

소프트웨어 아키텍처 시리즈 14화 – 이벤트 기반 시스템의 데이터 일관성 문제와 해결 전략

B컷개발자 2025. 7. 29. 09:44
728x90

이벤트 기반 시스템은 유연성과 확장성은 높지만, 데이터 일관성 문제를 내포하고 있습니다. 이 글에서는 이벤트 처리에서 발생하는 일관성 이슈의 원인과, 그것을 해결하기 위한 실전 설계 전략을 집중 분석합니다.

 

 

왜 이벤트 기반 시스템은 ‘일관성 문제’를 안고 있는가?

 

이벤트 기반 시스템은 다음과 같은 장점을 가지고 있습니다:

 

  • 서비스 간 강한 결합 제거
  • 비동기 메시지 전달을 통한 확장성과 탄력성 확보
  • CQRS + 이벤트 소싱 기반의 독립적인 읽기/쓰기 구조

 

그러나 이 구조는 근본적으로 **즉시 일관성(Strong Consistency)**이 아닌,

**최종적 일관성(Eventual Consistency)**를 전제로 하기 때문에, 데이터 간 불일치가 필연적으로 발생할 수 있습니다.

 

 

대표적인 일관성 문제 사례

 

 

1. 이벤트 중복 처리

  • 동일한 이벤트가 두 번 처리되어 데이터가 중복 갱신됨

 

 

2. 이벤트 순서 불일치

  • OrderShipped 이벤트가 OrderPlaced보다 먼저 도착 → Projection 오류

 

 

3. 이벤트 손실

  • 브로커 장애 또는 구독 서비스 장애로 이벤트 누락 → 데이터 일관성 훼손

 

 

4. 트랜잭션 경계 문제

  • 이벤트 발행은 완료되었지만, DB 커밋이 실패 → 외부 시스템은 상태 변경됐다고 믿음

 

 

메시지 일관성 보장의 난이도

 

이벤트 기반 구조는 보통 다음 두 계층으로 나뉩니다:

 

  1. 도메인 계층: 명령 수행 → 이벤트 생성
  2. 인프라 계층: 메시지 브로커 발행

 

이 둘이 동시에 실패하거나, 동시에 성공하지 않는 문제는 “데이터-이벤트 일관성 문제(Data-Messaging Inconsistency)“라고 불리며, 이는 실무에서 가장 자주 발생하는 장애 유형입니다.

 

 

실전 해결 전략 1 – 트랜잭셔널 아웃박스 패턴(Transactional Outbox)

 

이 방식은 도메인 이벤트를 데이터베이스 테이블에 먼저 저장한 뒤,

비동기적으로 메시지 브로커에 전달하는 구조입니다.

 

 

흐름

  1. 도메인 로직 수행 → 이벤트 저장 (Outbox 테이블)
  2. 트랜잭션 커밋
  3. 별도의 Polling 프로세스 또는 CDC가 Outbox 테이블의 이벤트를 브로커로 전송

 

이 구조는 데이터베이스의 트랜잭션 경계 내에서 처리되기 때문에 DB 상태와 이벤트 메시지 간의 원자성을 확보할 수 있습니다.

 

 

장점

  • 메시지 누락, 중복 방지
  • 이벤트 저장 시점과 데이터 저장 시점의 일관성 보장

 

 

단점

  • Poller 개발 필요
  • DB 테이블 증가
  • 지연(latency) 존재

 

 

실전 해결 전략 2 – 이벤트 재처리/멱등성 보장

 

불가피하게 이벤트가 중복되거나 순서가 뒤바뀔 수 있으므로,

**이벤트 핸들러는 반드시 멱등성(idempotency)**을 보장해야 합니다.

 

 

예시

  • OrderPlaced 이벤트는 이미 동일한 주문 ID가 처리됐는지 확인한 후 저장
  • Redis, DB에 이벤트 ID 기반 중복 처리 여부 캐시

 

이 전략은 마이크로서비스 간 통신이나 Kafka 기반 이벤트 설계에서 필수입니다.

 

 

실전 해결 전략 3 – 이벤트 순서 보장

 

Kafka의 파티션과 키 기반 순서 보장 기능을 활용하면,

동일한 키(예: orderId)에 대해서는 이벤트 순서를 강제할 수 있습니다.

 

 

설계 팁

  • 주문 ID, 사용자 ID 등을 Partition Key로 활용
  • Consumer 그룹은 파티션 기반 처리 구조로 구성

 

 

실전 해결 전략 4 – Snapshot과 보정 시나리오 도입

 

일부 Projection은 이벤트 누락이나 순서 꼬임에 취약합니다.

이 경우 일정 간격으로 도메인 상태를 Snapshot 형태로 저장하고,

문제 발생 시 Projection을 재생하거나 재빌드할 수 있도록 설계합니다.

 

 

구성

  • 스냅샷 DB 테이블 (정기 백업)
  • Projection 초기화/리플레이 도구

 

 

추가 전략 – 사가(Saga) 패턴으로 분산 트랜잭션 정렬

 

일련의 이벤트 체인에서 트랜잭션 경계를 나누되,

각 단계에서 보상 로직을 포함하여 시스템 전체의 논리적 일관성을 유지합니다.

 

예: 주문 생성 → 결제 승인 → 재고 차감 → 배송 요청
중간 실패 시, 이전 단계 보상(결제 취소 등) 로직 실행

 

 

도입 판단 기준

고려사항권장 전략

데이터-이벤트 일관성 트랜잭셔널 아웃박스
중복/누락 가능성 높음 멱등성 + 재처리 설계
순서 중요 파티션 키 기반 메시지 설계
복잡한 상태 전이 Saga 또는 State Machine

 

 

일관성은 트레이드오프의 문제다

 

이벤트 기반 아키텍처는 확장성과 유연성을 주지만,

그 대가로 우리는 데이터 일관성에 대한 설계 책임을 직접 져야 합니다.

 

즉, CAP 이론의 현실을 받아들이고,

시스템 목적과 복잡도에 맞는 일관성 전략을 구조적으로 설계해야 합니다.

 

그리고 그 전략은 단순한 기술 선택이 아니라,

아키텍트의 판단과 균형 감각이 필요한 영역입니다.

728x90