B컷전문 | 개발과 인생의 이야기

분산 환경에서 트랜잭션 일관성을 유지하기 위해 자주 사용되는 Saga 패턴을 분석합니다. 오케스트레이션과 코레오그래피의 차이, 설계 시 주의할 점을 실전 중심으로 설명합니다.

 

---

 

분산 환경의 트랜잭션 문제

 

마이크로서비스나 이벤트 기반 시스템에서는 하나의 비즈니스 로직이 여러 서비스에 걸쳐 수행되는 경우가 많습니다.

예를 들어 주문 처리를 생각해 봅시다:

 

1. 주문 서비스 – 주문 생성
2. 결제 서비스 – 결제 승인
3. 재고 서비스 – 재고 차감
4. 배송 서비스 – 배송 요청

 

이 네 단계는 논리적으로 하나의 트랜잭션처럼 보이지만, 실제로는 서로 다른 시스템에서 독립적으로 처리됩니다.

이때 강한 일관성을 유지하려고 하면 분산 락·2PC(2 Phase Commit) 같은 복잡하고 성능 저하를 유발하는 방법이 필요합니다.

그래서 현실적인 대안으로 Saga 패턴이 등장합니다.

 

---

 

Saga 패턴이란?

 

Saga 패턴은 긴 트랜잭션을 여러 개의 로컬 트랜잭션으로 나누고, 각 단계 실패 시 보상 트랜잭션을 수행해 전체 프로세스를 논리적으로 일관성 있게 유지하는 방식입니다.

 

• 각 로컬 트랜잭션은 자신의 데이터베이스에서만 커밋
• 실패 시 이전 단계들을 취소하는 보상 액션 수행

 

---

 

Saga 패턴의 두 가지 접근 방식

 

 

1. 오케스트레이션 기반(Orchestration-based)

 

• **중앙 조정자(Orchestrator)**가 전체 흐름을 제어
• 각 단계 서비스는 오케스트레이터의 명령에 따라 동작
• 예: 주문 오케스트레이터가 결제 요청 → 재고 차감 요청 → 배송 요청 순서로 호출

 

장점

 

• 흐름이 명확하고 추적 쉬움
• 장애 처리 로직 중앙 집중화

 

단점

 

• 오케스트레이터가 병목·단일 장애점(SPOF) 될 가능성
• 중앙 집중 구조로 유연성 감소

 

---

 

2. 코레오그래피 기반(Choreography-based)

 

• 중앙 조정자 없이 이벤트 기반으로 각 서비스가 다음 단계를 트리거
• 예: 주문 생성 이벤트 → 결제 서비스가 결제 → 결제 완료 이벤트 → 재고 서비스 차감

 

장점

 

• 중앙 집중 제어 없이 확장성 높음
• 서비스 간 결합도 낮음

 

단점

 

• 흐름이 분산돼 가시성 낮음
• 복잡한 비즈니스 로직에서 순서 제어 어려움

 

---

 

실전 예시: 주문 처리 Saga (오케스트레이션 방식)

 

1. Order Orchestrator: 주문 생성 → 상태: PENDING_PAYMENT
2. Payment Service: 결제 승인 → 상태: PAID
3. Inventory Service: 재고 차감 → 상태: INVENTORY_CONFIRMED
4. Shipping Service: 배송 요청 → 상태: SHIPPED

 

실패 시:

 

• 결제 실패 → 주문 취소 이벤트 발행
• 재고 부족 → 결제 취소 요청 후 주문 취소

 

---

 

보상 트랜잭션 설계 팁

 

• 원래 작업의 반대 작업이어야 하지만 완벽한 역연산이 아닐 수 있음
• (예: 결제 취소, 재고 복원)
• 보상 트랜잭션은 항상 멱등성 보장 필요
• 보상 불가능한 작업(이메일 전송 등)은 별도 관리

 

---

 

Saga 패턴 적용 시 고려사항

 

1. 오케스트레이션 vs. 코레오그래피 선택
   • 흐름 단순·명확성이 중요 → 오케스트레이션
   • 유연성과 서비스 자율성이 중요 → 코레오그래피
2.  
3. 장애와 재시도 전략
   • 모든 단계에서 재시도와 타임아웃 설계
   • 재시도 시 멱등성 필수
4.  
5. 모니터링과 가시성
   • 분산 트랜잭션 추적 시스템(예: OpenTelemetry, Zipkin) 필요
   • Saga 상태 대시보드 구축
6.  
7. 헥사고날 아키텍처와의 연결
   • Saga 오케스트레이터는 Application Layer의 유즈케이스로 구현 가능
   • 각 단계 서비스는 자신의 Inbound Port를 통해 명령 수신
   • Outbound Port로 다른 서비스 호출 또는 이벤트 발행
8.  

 

---

 

일관성을 유지하는 ‘프로세스 설계’의 힘

 

Saga 패턴은 단순히 트랜잭션 관리 기법이 아니라, 비즈니스 프로세스를 안정적으로 운영하기 위한 아키텍처적 설계 패턴입니다.

서비스가 많아지고 데이터 경계가 복잡해질수록, Saga는 선택이 아니라 필수가 될 수 있습니다.

 

다만, 보상 트랜잭션과 장애 처리 로직을 포함한 운영 전략까지 설계에 포함해야 진정한 효과를 볼 수 있습니다.