Saga Pattern

📌 Brief Summary

Saga Pattern은 마이크로서비스 아키텍처 환경에서 여러 서비스에 걸친 분산 트랜잭션을 관리하기 위한 서비스 협업 패턴입니다 [1, 2]. 각 서비스가 자체 데이터베이스를 가지는 느슨한 결합 환경에서 강력한 ACID 트랜잭션 대신, 분산된 명령을 일련의 로컬 트랜잭션으로 구현합니다 [2, 3]. 이를 통해 전체 시스템의 일관성을 맞추는 최종 일관성(Eventual Consistency) 모델을 제공합니다 [4].

📖 Core 비즈니스 트랜잭션 Content

분산 환경의 한계 극복: 마이크로서비스 아키텍처에서는 결합도를 낮추기 위해 각 서비스가 개별 데이터베이스를 보유하는 패턴(Database per Service)을 사용합니다 [3, 5]. 이로 인해 여러 서비스에 걸친 분산된 작업(Distributed Operations)을 처리할 때 기존의 단일 ACID 트랜잭션을 적용하기 어렵습니다 [3, 4]. Saga 패턴은 분산 명령을 여러 개의 연속적인 로컬 트랜잭션(Local transactions)으로 쪼개어 구현함으로써 이 문제를 해결합니다 [2].
비동기 메시징 및 워크플로우 제어: Saga 패턴은 주로 비동기 메시징(Asynchronous messaging)을 사용하여 서비스 간 통신을 수행합니다 [2]. 여러 서비스 간의 메시지 흐름을 안정적으로 관리하기 위해 코레오그래피(Choreography)나 Saga 오케스트레이션(Saga Orchestration)과 같은 워크플로우 관리 패턴을 함께 활용합니다 [6].
원자적 업데이트 지원: 비즈니스 엔티티를 영구적으로(Atomically) 업데이트하고 메시지를 전송하는 과정의 안정성을 보장하기 위해, Saga 패턴은 종종 Transaction Outbox 패턴과 결합하여 사용됩니다 [2].

⚖️ Trade-offs & Caveats

구현 및 테스트 난이도 증가: 엄격한 ACID 트랜잭션 대신 최종 일관성(Eventual Consistency) 모델을 사용해야 하므로, 시스템의 전반적인 구현과 테스트 난이도가 크게 상승합니다 [3, 4].
복잡한 에러 복구 매커니즘: 여러 서비스에 걸쳐 트랜잭션이 분산되어 실행되기 때문에, 프로세스 중간 단계에서 실패가 발생할 경우 이를 논리적으로 되돌려야 합니다. 이를 위해 이미 완료된 이전 단계의 작업을 취소하는 보상 트랜잭션(Compensating Transaction) 등의 복잡한 오류 처리 메커니즘을 반드시 설계해야 하는 부담이 있습니다 [6].

🔗 Knowledge Connections

[아키텍처 / 기반 기술]

Microservice Architecture
- 연결 이유: Saga 패턴이 등장하게 된 직접적인 배경으로, 각 서비스가 독자적인 데이터베이스를 가지면서 분산 트랜잭션 관리가 필요해졌기 때문입니다 [2, 3].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 독립적인 서비스들이 어떻게 데이터를 격리하고 통신하는지, 그리고 왜 분산 트랜잭션이 복잡해지는지 이해할 수 있습니다.
Eventual Consistency
- 연결 이유: Saga 패턴이 강력한 ACID 속성을 포기하는 대신 채택하는 데이터 일관성 모델입니다 [3, 4].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 분산 시스템에서 데이터 불일치를 허용하는 시간적 창(Window)과, 그것을 비즈니스 로직으로 어떻게 보완하는지 이해할 수 있습니다.

[구현 / 연관 패턴]

Transaction Outbox Pattern
- 연결 이유: Saga 구현 시 비즈니스 엔티티의 업데이트와 비동기 메시지 발행을 원자성 있게 처리하기 위해 필수적으로 요구되는 패턴입니다 [2].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 분산 환경에서 데이터베이스 저장과 메시징 시스템 간의 신뢰성 있는 이벤트 발행 방법을 학습할 수 있습니다.
Compensating Transaction
- 연결 이유: Saga의 파이프라인 단계 중 하나가 실패했을 때, 이전에 실행된 로컬 트랜잭션들을 논리적으로 롤백하기 위해 사용됩니다 [6].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 분산 에러 핸들링과 트랜잭션 취소의 원리를 깊이 있게 파악할 수 있습니다.
CQRS
- 연결 이유: Saga가 분산 커맨드(명령)를 처리한다면, CQRS는 분산 쿼리(조회)를 처리하기 위해 비동기 메시징과 함께 짝을 이루어 도입되는 핵심 패턴입니다 [2, 7].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 명령과 조회의 책임을 분리하여 MSA 내에서 데이터를 관리하는 전체적인 전략을 이해할 수 있습니다.

Deeper Research Questions

Saga 패턴에서 코레오그래피(Choreography) 방식과 오케스트레이션(Orchestration) 방식의 구조적 차이와 장단점은 무엇인가?
Transaction Outbox 패턴은 구체적으로 어떻게 로컬 데이터베이스 업데이트와 메시지 브로커 간의 원자성을 보장하는가?
최종 일관성(Eventual Consistency) 모델을 적용할 때 발생할 수 있는 데이터 조회 시점의 지연을 비즈니스 로직이나 UX 측면에서 어떻게 보완할 수 있는가?
마이크로서비스에서 실패한 Saga 트랜잭션에 대해 Compensating Transaction을 구성할 때 멱등성(Idempotency)을 어떻게 보장할 수 있는가?
Saga 패턴과 CQRS를 동시에 결합하여 사용하는 시스템에서 이벤트 메시지의 흐름과 데이터 동기화 파이프라인은 어떻게 설계해야 하는가?

Practical Application Contexts

Implementation: 비동기 메시지 큐(예: Kafka, RabbitMQ)를 활용하여 각 서비스의 로컬 트랜잭션 처리 완료 이벤트를 다음 서비스로 전달하는 시스템을 구축할 때 적용됩니다 [2].
System Design: 이커머스의 주문-결제-재고-배송과 같이 여러 마이크로서비스의 도메인을 거쳐야 하는 복잡한 비즈니스 트랜잭션 워크플로우를 설계할 때 핵심 아키텍처로 사용됩니다 [2, 6].
Operation / Maintenance: 최종 일관성으로 인해 데이터의 일시적 불일치가 발생할 수 있으며, 중간에 트랜잭션이 실패할 경우 보상 트랜잭션 추적 등을 위해 강력한 분산 트레이싱(Distributed Tracing) 체계를 운영해야 합니다 [4, 6].
Learning Path: 모놀리식 아키텍처에서 마이크로서비스 아키텍처로 분리(Decomposition)하는 리팩토링 과정 중, 다중 데이터베이스 간의 데이터 정합성을 유지하는 기법으로 학습하게 됩니다 [1, 2].
My Project Relevance: 주문이나 결제와 같이 강력한 데이터 일관성이 요구되지만 분산 서비스로 나누어져야만 하는 프로젝트에서 데이터 무결성을 보장하기 위한 방안으로 직접 검토할 수 있습니다 [2].

Adjacent Topics

API Composition
- 확장 방향: 다중 서비스 간의 데이터 변경(Command)을 다루는 Saga 패턴과 대조적으로, 다중 서비스로부터 데이터를 조회(Query)하여 조합하는 패턴을 함께 학습하여 분산 데이터 관리의 전체 그림을 완성할 수 있습니다 [2].
Service Mesh
- 확장 방향: 마이크로서비스 간의 복잡한 통신(비동기 호출, 재시도, 서킷 브레이커 등)을 애플리케이션 코드 외부의 인프라 레벨에서 투명하게 관리하는 방법을 확장하여 학습할 수 있습니다 [8].

Last updated: 2026-05-02

7.8 KiB Raw Blame History