Saga 패턴이란 무엇인가
마이크로서비스 아키텍처에서는 하나의 비즈니스 로직이 여러 서비스에 걸쳐 실행되는 경우가 많습니다. 예를 들어 주문 서비스, 결제 서비스, 재고 서비스가 각각 독립된 데이터베이스를 가지고 있다면, 하나의 주문 처리 과정에서 여러 데이터베이스에 걸친 트랜잭션이 필요합니다. 하지만 전통적인 ACID 트랜잭션은 단일 데이터베이스 안에서만 보장되기 때문에, 분산 환경에서는 그대로 적용할 수 없습니다.
이런 문제를 해결하기 위해 등장한 것이 Saga 패턴입니다. Saga는 하나의 큰 트랜잭션을 여러 개의 작은 로컬 트랜잭션으로 쪼개고, 각 단계가 성공하면 다음 단계로 넘어가며, 중간에 실패하면 이전 단계들을 취소하는 ‘보상 트랜잭션(compensating transaction)’을 실행해 전체 데이터의 일관성을 맞추는 방식입니다.
Saga의 두 가지 구현 방식
Saga 패턴은 크게 두 가지 방식으로 구현됩니다.
Choreography(코레오그래피): 각 서비스가 이벤트를 발행하고 구독하며 다음 동작을 스스로 결정합니다. 별도의 중앙 제어자가 없어 서비스 간 결합도가 낮지만, 흐름이 복잡해지면 전체 흐름을 파악하기 어려워집니다.Orchestration(오케스트레이션): ‘오케스트레이터’라는 중앙 조정자가 각 서비스에 순서대로 명령을 내리고 결과를 확인합니다. 흐름을 한눈에 파악하기 쉽지만, 오케스트레이터에 로직이 집중되는 단점이 있습니다.
예를 들어 온라인 쇼핑몰에서 주문이 들어오면 ‘재고 차감 → 결제 승인 → 배송 요청’ 순서로 진행된다고 가정해봅시다. 만약 결제 승인 단계에서 실패하면, 이미 차감된 재고를 다시 복구하는 보상 트랜잭션이 실행됩니다. 이는 마치 여행 일정을 예약할 때 항공권, 호텔, 렌터카를 순서대로 예약하다가 렌터카 예약이 실패하면 이미 예약한 호텔과 항공권을 취소하는 것과 비슷한 원리입니다.
실무에서 Saga 패턴을 쓰는 이유
마이크로서비스 환경에서는 서비스마다 데이터베이스가 분리되어 있어 2PC(Two-Phase Commit)와 같은 전통적인 분산 트랜잭션 기법을 적용하기 어렵습니다. 2PC는 모든 참여자가 잠금을 걸고 대기해야 하므로 성능 저하와 가용성 문제가 발생하기 쉽습니다. 반면 Saga 패턴은 각 로컬 트랜잭션이 독립적으로 커밋되기 때문에 시스템 전체의 가용성을 높이고, 장애 상황에서도 유연하게 대응할 수 있습니다.
다만 Saga는 강한 일관성(strong consistency) 대신 최종적 일관성(eventual consistency)을 보장한다는 점을 이해해야 합니다. 따라서 설계 시 각 단계의 보상 트랜잭션을 명확히 정의하고, 실패 처리 로직을 꼼꼼히 검증하는 것이 중요합니다.