MSA 분산 트랜잭션, SAGA 패턴 vs. 이벤트 소싱(ES) 완벽 비교 및 선택 가이드

마이크로서비스 아키텍처(MSA)를 도입하는 순간, 개발자들은 가장 근본적인 문제에 직면합니다. 바로 '트랜잭션' 문제입니다. 전통적인 모놀리식 애플리케이션에서는 데이터베이스의 ACID(원자성, 일관성, 독립성, 영속성) 속성을 활용하여 여러 비즈니스 로직을 하나의 원자적 단위로 묶어 처리했습니다. 하지만 MSA 환경에서는 각 서비스가 독립적인 데이터베이스를 소유하기 때문에, 단일 트랜잭션 경계가 사라지면서 이 ACID 보장이 깨지게 됩니다.

이러한 분산 트랜잭션의 복잡성은 MSA 도입의 가장 큰 기술적 허들 중 하나입니다. 이 문제를 해결하기 위해 등장한 대표적인 두 가지 패턴이 바로 SAGA 패턴과 **이벤트 소싱(Event Sourcing)**입니다. 이 글에서는 두 패턴의 작동 원리를 깊이 있게 비교하고, 실제 시스템 설계 시 어떤 기준으로 선택해야 하는지 실질적인 가이드를 제공합니다.

1. MSA 환경에서 ACID 트랜잭션이 깨지는 근본적인 이유

MSA의 핵심 철학은 '느슨한 결합(Loose Coupling)'과 '독립적인 배포'입니다. 이 목표를 달성하기 위해 서비스 경계(Service Boundary)를 데이터베이스 경계로 확장했습니다.

문제의 핵심: 만약 '주문 서비스'가 결제 성공을 확인하고 '재고 서비스'가 재고를 차감해야 하는 비즈니스 플로우가 있다고 가정해 봅시다. 전통적인 방식이라면, 이 두 작업이 하나의 DB 트랜잭션으로 묶여서 둘 중 하나라도 실패하면 모두 롤백됩니다.

하지만 MSA에서는 주문 서비스가 A DB를, 재고 서비스가 B DB를 사용합니다. A DB에서 성공적으로 커밋했더라도, B DB에서 네트워크 오류나 비즈니스 로직 오류로 실패한다면, A DB의 작업은 이미 롤백되지 않은 상태로 남아 데이터 불일치(Data Inconsistency)가 발생합니다.

이러한 상황에서 우리는 **결과적 일관성(Eventual Consistency)**을 받아들이고, 실패했을 때의 '복구 로직'을 설계해야 합니다. 이것이 SAGA와 Event Sourcing이 등장한 배경입니다.

2. SAGA 패턴: 보상 트랜잭션으로 분산 트랜잭션 해결하기

SAGA 패턴은 분산 트랜잭션을 일련의 로컬 트랜잭션(Local Transaction)들의 순차적인 실행으로 정의하고, 만약 중간 단계 중 하나라도 실패하면, 이전에 성공했던 모든 트랜잭션들을 되돌리는 **보상 트랜잭션(Compensating Transaction)**을 실행하여 시스템을 일관된 상태로 되돌리는 방식입니다.

SAGA는 트랜잭션의 '실행 순서'와 '실패 시의 롤백 경로'에 초점을 맞춥니다.

SAGA의 구현 방식: 오케스트레이션 vs. 코레오그래피

SAGA를 구현하는 방식은 크게 두 가지로 나뉩니다.

1. 오케스트레이션 (Orchestration): 중앙의 오케스트레이터(Orchestrator) 서비스가 전체 트랜잭션의 흐름을 관리하고, 각 서비스에 순서대로 명령(Command)을 내립니다.
   • 장점: 흐름 제어가 명확하고 추적이 쉽습니다.
   • 단점: 오케스트레이터가 단일 실패 지점(Single Point of Failure)이 될 위험이 있으며, 오케스트레이터 자체가 복잡한 비즈니스 로직을 가지게 됩니다.
2. 코레오그래피 (Choreography): 중앙 제어 없이, 각 서비스가 자신의 로컬 트랜잭션을 완료한 후, 그 결과를 **이벤트(Event)**로 발행합니다. 이 이벤트를 구독(Subscribe)하는 다른 서비스들이 다음 작업을 수행합니다.
   • 장점: 서비스 간의 결합도가 극도로 낮아지고, 확장성이 뛰어납니다.
   • 단점: 전체적인 흐름을 파악하기 어렵고(Spaghetti Flow), 복잡한 트랜잭션의 경우 어떤 서비스가 어떤 이벤트를 발행했는지 추적하기 매우 어렵습니다.

💡 실무 개발자 관점의 의견: 저는 복잡도가 높은 대규모 시스템에서는 초기에는 오케스트레이션을 사용하여 흐름을 명확히 잡고, 시스템이 안정화된 후 비즈니스 로직의 분리를 위해 코레오그래피로 점진적으로 전환하는 하이브리드 접근법을 선호합니다.

3. 이벤트 소싱(Event Sourcing): 상태 변화의 불변 기록을 통한 트랜잭션 관리

이벤트 소싱(ES)은 '현재 상태(Current State)'를 저장하는 대신, **시스템에서 발생한 모든 상태 변화의 기록(Event Stream)**을 시간 순서대로 저장하고 이를 근본적인 데이터로 삼는 아키텍처 패턴입니다.

ES의 핵심은 '상태'가 아니라 '사건(Event)' 그 자체를 신뢰한다는 것입니다.

데이터 흐름의 변화: 명령(Command) $\rightarrow$ 이벤트(Event) $\rightarrow$ 상태(State)

1. 명령 수신: 외부에서 '주문 생성 요청(Command)'이 들어옵니다.
2. 비즈니스 로직 실행: 도메인 로직이 실행됩니다.
3. 이벤트 기록: 로직이 성공하면, "주문이 생성되었다(OrderCreated)"와 같은 불변의 이벤트가 이벤트 스토어(Event Store)에 기록됩니다.
4. 상태 재구성(Rehydration): 현재 시점의 상태가 필요할 때, 시스템은 처음부터 기록된 모든 이벤트를 순서대로 재생(Replay)하여 현재의 객체 상태를 재구성합니다.

ES는 트랜잭션의 실패를 '롤백'하는 것이 아니라, '새로운 이벤트'를 발행하여 이전의 잘못된 상태를 무효화하는 방식으로 처리합니다.

4. SAGA vs. Event Sourcing: 무엇을 선택해야 할까? (비교 분석 및 의사결정 트리)

두 패턴 모두 분산 트랜잭션 문제를 해결하지만, 그 접근 방식과 초점이 완전히 다릅니다.

📊 핵심 비교 테이블

🔍 시나리오별 선택 가이드

1. "주문 처리" 시나리오 (A $\rightarrow$ B $\rightarrow$ C 순차적 작업):

   • 추천: **SAGA 패턴 (SAGA Pattern)**을 사용합니다. (이는 SAGA 패턴이 구현하는 분산 트랜잭션의 개념이며, SAGA는 이벤트 기반으로 여러 서비스 간의 일관성을 유지하는 패턴입니다.)
   • 이유: 주문(A)이 성공해야 재고 차감(B)이 되고, 재고 차감이 성공해야 결제(C)가 진행되는 등, 순차적이고 보상(Compensation) 메커니즘이 필요한 경우에 가장 적합합니다.

2. "사용자 계정 변경 이력 추적" 시나리오 (시간에 따른 모든 상태 변화 기록):

   • 추천: **이벤트 소싱 (Event Sourcing)**을 사용합니다.
   • 이유: "사용자가 언제, 어떤 이유로, 무엇을 변경했는지" 그 과정 자체가 비즈니스 가치일 때, 모든 상태 변화를 이벤트로 기록하는 것이 가장 정확하고 강력합니다.

결론: 상호 보완적 관계

실제 대규모 시스템에서는 이 두 가지 개념이 상호 보완적으로 사용되는 경우가 많습니다.

• SAGA 패턴: 여러 서비스 간의 **일관성(Consistency)**을 유지하는 '흐름 제어'에 중점을 둡니다.
• 이벤트 소싱: 각 서비스 내부의 **상태 변화 기록(History)**을 가장 정확하게 보존하는 '데이터 모델링'에 중점을 둡니다.

따라서, 복잡한 도메인에서는 SAGA 패턴을 통해 서비스 간의 흐름을 관리하고, 각 서비스 내부에서는 이벤트 소싱을 통해 데이터의 무결성을 확보하는 것이 가장 견고한 아키텍처가 될 수 있습니다.