1. 서론
최근 디지털 서비스 환경은 빠른 변화와 확장성을 요구받고 있으며, 이에 따라 마이크로서비스 아키텍처(MSA, Microservice Architecture)가 주요 설계 방식으로 자리잡고 있다. MSA는 서비스 단위를 작게 나누어 독립적으로 개발, 배포, 확장이 가능하다는 장점을 가지지만, 동시에 데이터 일관성과 트랜잭션 처리라는 새로운 문제를 야기한다.
특히 전통적인 모놀리식 아키텍처에서 사용되던 분산 트랜잭션(Distributed Transaction) 방식은 MSA 환경에서 성능 저하 및 결합도 증가 문제를 초래한다. 이러한 문제를 해결하기 위한 대표적인 방법이 바로 사가 패턴(Saga Pattern)이다. 본 칼럼에서는 SAGA 패턴의 개념부터 실제 활용 방식, 사례, 그리고 적용 시 고려해야 할 핵심 요소들을 체계적으로 살펴본다.
[그림 1] MSA에서의 SAGA패턴 도입 필요성

2. SAGA 패턴의 개념
SAGA 패턴은 분산 환경에서 하나의 비즈니스 트랜잭션을 여러 개의 로컬 트랜잭션(Local Transaction)으로 분리하여 처리하는 방식이다.
각 서비스는 자신의 데이터베이스에서 독립적으로 트랜잭션을 수행하며, 전체 트랜잭션의 일관성을 유지하기 위해 다음과 같은 구조를 갖는다.
- 각 단계는 로컬 트랜잭션 수행
- 실패 시 이전 단계들을 되돌리는 보상 트랜잭션(Compensating Transaction) 실행
즉, SAGA는 “전체 롤백”이 아니라 “부분 실행 + 보상”이라는 개념을 기반으로 한다.
이를 기반으로 기존 2PC(Two Phase Commit)과는 트랜잭션방식과 특성적인 부분에서의 차이점이 존재한다.
[표1] 2PC와 SAGA 패턴과의 비교
| 구분 | 2PC (Two Phase Commit) | SAGA 패턴 |
| 트랜잭션 방식 | 글로벌 트랜잭션 | 로컬 트랜잭션 |
| 결합도 | 높음 | 낮음 |
| 성능 | 낮음 (락 유지) | 상대적으로 높음 |
| 장애 대응 | 중앙 실패 위험 | 분산 처리 |
3. SAGA 패턴의 동작 방식
SAGA 패턴은 코레오그래피 방식 (Choreography)과 오케스트레이션 방식 (Orchestration)등 두 가지 방식으로 구현된다. 각각의 방식은 중앙제어자의 여부에 따라 차이가 있으며, 중앙집중식으로 구현시에는 오케스트레이터를 활용한 방식이 활용될 수 있고, 각 서비스 별 권한 분산을 위해서는 코레오그래피 방식을 활용할 수 있다.
[그림 2] SAGA 패턴의 두가지 방식

3.1 코레오그래피 방식 (Choreography)
각 서비스가 이벤트를 발행하고, 다른 서비스가 이를 구독하여 다음 작업을 수행하는 방식이다.
[그림 3] 코레오그래피 방식

3.2 오케스트레이션 방식 (Orchestration)
중앙의 오케스트레이터(Orchestrator)가 전체 흐름을 제어하는 방식이다. 오케스트레이터는 워크플로우를 정의하고, 각 단계에서 필요한 서비스를 직접 호출(명령)하여 작업을 지시한다. 서비스는 자신의 작업을 완료한 후 결과를 오케스트레이터에게 보고하며, REST API 기반으로 통신을 수행한다.
[그림 4] 오케스트레이션 방식

4. SAGA 패턴의 활용 방법
SAGA 패턴을 활용하는 방법으로는 이벤트 기반 메시징, 트랜잭션 상태 관리, 보상 트랜잭션 설계 등 크게 3가지 방법이 있다.
[그림 5] SAGA 패턴 활용 방법

각각의 방법들에 핵심은 기존 SAGA 패턴의 특성을 이해하는 것을 기반하여, 분산 환경에서의 비즈니스 트랜잭션을 여러 개의 로컬 트랜잭션(Local Transaction)으로 분리하여 처리하는 데에 있다.
각 서비스는 자신의 데이터베이스에서 독립적으로 트랜잭션이 수행되기 때문에 분산환경에서의 전체 트랜잭션의 일관성을 유지하기 위한 방안으로 활용하면 효과적으로 적용될 수 있다.
[표 2] SAGA 패턴 활용 방법 상세 설명
| 구분 | 핵심 개념 | 구현 시 고려사항 |
| 이벤트 기반 메시징 | 메시지 브로커 기반, 비동기통신서비스 간 결합도 최소화 | Kafka, RabbitMQ 활용이벤트 기반(Event-driven) 구조 설계 |
| 상태 관리 | 트랜잭션 단계 상태 추적 필요(STARTED /COMPLETED / FAILED / COMPENSATED) | 상태 저장 DB 활용이벤트 소싱(Event Sourcing) 적용 가능 |
| 보상 트랜잭션 설계 | 실패 시 보상 트랜잭션 수행,완전 롤백이 아닌 비즈니스 보정 | 결제 취소 / 재고 복구 / 주문 취소정확한 보상 로직 정의 필수 |
5. 적용 사례 및 고려사항
5.1 적용 사례
SAGA 패턴은 각각 콘텐츠/추천, 배차/결제 등 다양한 글로벌 회사들에서 활용되고 있다.
[표 3] SAGA 패턴 적용사례
| 기업 | 방식 | 적용 도메인 | 특징 |
| 글로벌 OTT N사 | Choreography | 콘텐츠/추천 | 이벤트 기반 |
| 글로벌 모빌리티 U사 | Hybrid | 배차/결제 | 복합 구조 |
| 글로벌 빅테크 A사 | Orchestration | 서버리스 | 상태 머신 기반 |
5.2 고려사항
SAGA 패턴은 강력하지만, 다음과 같은 고려사항이 반드시 필요하다.
[표 4] SAGA 패턴 도입 시 고려사항
| 구분 | 고려사항 | 유의점 |
| 데이터 일관성 | 비즈니스에서 허용 가능 여부 판단, UX 영향 고려 | 최종 일관성(Eventual Consistency) 기반, 즉시 일관성 보장 X |
| 보상 트랜잭션 | 외부 API / 비가역 작업 별도 설계, 보상 전략 명확화 필요 | 보상 로직 복잡도 증가, 유지보수 어려움 |
| 장애 처리 | 멱등성(Idempotency) 확보, Retry + DLQ 설계 | 메시지 유실 / 중복 실행 / 지연 발생 |
| 트랜잭션 추적 | Distributed Tracing 도입, Correlation ID 활용 | 분산 환경 → 흐름 추적 어려움 |
| 성능 vs 일관성 | 금융: Strong Consistency, 커머스: Eventual Consistency | 성능 ↑ 강한 일관성 ↓ |
참고자료
- Garcia-Molina, H., & Salem, K. (1987). “Sagas”
- Microservices Patterns – Chris Richardson
- Martin Fowler, “Microservices”
- AWS Architecture Blog (Saga Pattern 관련 자료)
- SK C&C 기술 블로그 – SAGA 패턴 설명, Microservices.io – Saga Pattern
- AWS Prescriptive Guidance – Saga Pattern
- SK C&C Tech Blog – SAGA 패턴