사가 패턴이란?
마이크로서비스 아키텍처에서는 하나의 비즈니스 프로세스가 여러 서비스에 걸쳐 처리되는 경우가 많습니다. 예를 들어 ‘주문하기’라는 하나의 작업이 주문 서비스, 결제 서비스, 재고 서비스로 나뉘어 각각 별도의 데이터베이스를 가지고 동작한다면, 기존처럼 하나의 트랜잭션으로 묶어서 처리할 수 없습니다. 이때 등장하는 것이 사가 패턴(Saga Pattern)입니다. 사가 패턴은 하나의 큰 트랜잭션을 여러 개의 작은 로컬 트랜잭션으로 나누고, 각 단계가 성공하면 다음 단계로 넘어가고 실패하면 이전 단계를 취소하는 ‘보상 트랜잭션(Compensating Transaction)’을 실행하여 데이터 일관성을 맞추는 방식입니다.
동작 원리: 코레오그래피와 오케스트레이션
사가 패턴은 크게 두 가지 방식으로 구현됩니다.
- 코레오그래피(Choreography): 중앙 지휘자 없이 각 서비스가 이벤트를 발행하고 구독하며 다음 단계를 스스로 트리거하는 방식입니다. 예를 들어 주문 서비스가 ‘주문 생성됨’ 이벤트를 발행하면, 결제 서비스가 이를 구독해 결제를 진행하고 ‘결제 완료’ 이벤트를 다시 발행하는 식입니다.
- 오케스트레이션(Orchestration): 사가 오케스트레이터라는 중앙 관리자가 각 서비스에 ‘이 작업을 해라’고 명령을 내리고 응답을 받아 다음 단계를 결정하는 방식입니다.
실패 상황을 예로 들면, 주문-결제-재고 차감 순서로 진행되다가 재고가 부족해 마지막 단계가 실패했다고 가정해봅시다. 이 경우 시스템은 자동으로 ‘결제 취소’와 ‘주문 취소’라는 보상 트랜잭션을 순차적으로 실행해, 마치 아무 일도 없었던 것처럼 상태를 되돌립니다. 이는 마치 여행 패키지를 예약할 때 항공권, 호텔, 렌터카를 각각 따로 예약했다가 렌터카 예약이 실패하면 이미 예약한 항공권과 호텔을 취소 처리하는 것과 비슷한 원리입니다.
실무에서 사가 패턴을 쓰는 이유
전통적인 2PC(Two-Phase Commit) 방식은 모든 서비스가 잠금을 걸고 동시에 커밋 여부를 결정해야 하므로, 서비스 수가 늘어날수록 성능 저하와 장애 전파 위험이 커집니다. 반면 사가 패턴은 각 서비스가 자신의 로컬 트랜잭션만 책임지기 때문에 서비스 간 결합도가 낮고 확장성이 뛰어납니다. 다만 최종적 일관성(Eventual Consistency)만 보장하므로, 일시적으로 데이터가 불일치하는 구간이 존재할 수 있다는 점과 보상 트랜잭션 설계가 까다롭다는 점은 반드시 고려해야 합니다.