Saga

주문 처리를 만든다고 하면, 재고 서비스에서 수량을 줄이고, 결제 서비스에서 금액을 차감하고, 배송 서비스에서 발송을 예약해야 합니다. 각 서비스는 자신의 데이터베이스를 따로 갖고 있습니다. 결제까지 성공했는데 배송 예약에서 실패했다면, 재고와 결제는 이미 반영된 상태입니다. 이 상황을 하나의 전역 트랜잭션으로 묶으려 하면 서비스 간 2PC(Two-Phase Commit)가 필요한데, 서비스 중 하나가 느리거나 잠시 내려가는 순간 전체 흐름이 잠겨 버립니다. 그렇다고 중간 실패를 무시하면 데이터가 어긋납니다.

단일 데이터베이스 시절에는 트랜잭션 하나로 모든 상태 변경을 원자적으로 묶을 수 있었습니다. 서비스가 나뉘고 각자 독립 저장소를 가지게 되면서 이 방식은 더 이상 통하지 않았습니다. 분산 환경에서의 2PC는 가용성과 성능을 크게 떨어뜨렸고, 네트워크 파티션이 생기면 흐름 전체가 멈췄습니다. 비즈니스는 여전히 '주문 전체가 맞아야 한다'는 기대를 버릴 수 없었지만, 기술 구조는 원자성을 한 번에 보장할 수 없게 되었습니다. 이 압력 속에서 '모두 성공하거나 모두 되돌리기'를 전역 잠금 없이 이벤트와 보상 작업으로 구현하는 Saga가 실무 패턴으로 정착했습니다.

흐름은 여러 단계의 로컬 트랜잭션으로 이뤄집니다. 주문 생성, 재고 예약, 결제 승인 같은 순서로 각 단계가 성공하면 이벤트나 메시지를 통해 다음 단계로 진행합니다. 중간 단계에서 실패하면 역순으로 보상 작업을 실행해 앞서 반영된 변경을 되돌립니다. 예를 들어 결제 승인이 실패하면 재고 예약 취소 트랜잭션을 실행합니다. 이 흐름을 한 곳에서 지휘하는 방식(Orchestration)과 각 서비스가 이벤트를 듣고 반응하는 방식(Choreography) 두 가지로 구현할 수 있으며, 전자는 흐름이 명시적이고 후자는 서비스 간 결합이 느슨합니다.

Saga와 Circuit Breaker는 둘 다 분산 환경의 실패를 다루지만 바라보는 층이 다릅니다. Saga는 여러 서비스에 걸친 비즈니스 흐름이 중간에 깨졌을 때 상태를 어떻게 정리하느냐의 문제이고, Circuit Breaker는 특정 서비스 호출이 반복 실패할 때 그 호출 자체를 잠시 끊어 시스템 전체를 보호하는 패턴입니다. 둘은 서로 배타적이지 않고 함께 쓰이는 경우가 많습니다. Saga는 흐름의 정합성을, Circuit Breaker는 호출 경로의 안정성을 각각 담당합니다.

주문, 예약, 정산처럼 여러 서비스가 순서대로 참여하고 중간 실패 시 앞 단계를 되돌려야 하는 비즈니스 흐름에서 Saga는 필수에 가깝습니다. '하나의 요청이 여러 서비스를 거치는데, 부분 성공 상태를 어떻게 정리할지 막막하다'거나 '전역 트랜잭션 없이도 비즈니스 결과의 일관성이 필요하다'는 상황이 신호입니다. 다만 보상 작업은 비즈니스 의미를 가져야 하므로, 모든 실패 경로에서 실제로 되돌릴 수 있는 작업인지 미리 검토해야 합니다. 또 각 단계에서 같은 메시지가 재전달될 수 있어 Idempotency가 함께 설계되어 있지 않으면 보상 작업 자체가 중복 실행될 수 있습니다.