MSA의 거대한 장벽: 분산 트랜잭션, 왜 2PC 대신 Saga 패턴인가?

Advanced Architecture Series 01

MSA의 난제,
데이터 정합성을 위한 Saga 패턴 완벽 정리 (1부)

 

안녕하세요, code-resting입니다. 모놀리식 아키텍처에서는 단일 DB의 @Transactional 하나면 충분했습니다. 하지만 서비스가 쪼개진 MSA 환경에서는 어떤가요? 주문 서비스는 성공했는데 결제 서비스에서 에러가 난다면? 이미 성공한 주문은 어떻게 취소해야 할까요? 오늘은 분산 환경의 영원한 숙제, 분산 트랜잭션의 해결사를 소개합니다.

1. 전통적인 2PC(2-Phase Commit)의 몰락

분산 트랜잭션을 해결하기 위한 고전적인 방법은 2PC였습니다. 모든 노드가 '준비' 상태를 확인하고 동시에 '커밋'하는 방식이죠. 하지만 2026년의 고가용성 시스템에서 2PC는 거의 쓰이지 않습니다.

⚠️ 2PC를 쓰면 안 되는 이유

• 성능 병목: 모든 서비스가 응답할 때까지 자원이 락(Lock)에 걸려 처리량이 급감합니다.
• 단일 장애점(SPOF): 코디네이터 노드가 죽으면 전체 시스템이 마비됩니다.
• NoSQL 미지원: 대부분의 현대적인 NoSQL DB는 2PC를 지원하지 않습니다.

2. Saga 패턴: "보상 트랜잭션"의 마법

Saga 패턴은 거대한 하나의 트랜잭션을 여러 개의 로컬 트랜잭션으로 나눕니다. 핵심은 보상 트랜잭션(Compensating Transaction)입니다. 어떤 단계에서 실패하면, 이전 단계들을 원상복구 시키는 별도의 로직을 실행하는 것이죠.

주문 흐름 예시:

1. 주문 생성 (성공)
2. 결제 처리 (성공)
3. 재고 차감 (실패!)
4. 보상 실행: 결제 취소 → 주문 취소 처리 (데이터 일치 완료)

3. Saga의 두 가지 얼굴: Choreography vs Orchestration

Saga를 구현하는 방식은 크게 두 가지로 나뉩니다. 각 방식의 선택 기준은 서비스의 복잡도에 달려 있습니다.

방식	특징	장점
Choreography	중앙 제어 없이 이벤트로 통신	결합도가 낮고 구축이 빠름
Orchestration	중앙 컨트롤러가 흐름 제어	복잡한 비즈니스 로직 파악 용이

💡 1부 요약

분산 환경에서 100% 실시간 정합성을 맞추는 것은 불가능에 가깝습니다. Saga 패턴은 이를 '결과적 정합성(Eventual Consistency)'으로 해결합니다. 2부에서는 실제 Kafka를 활용하여 이 패턴을 코드로 어떻게 구현하는지 상세히 다뤄보겠습니다.

© 2026 code-resting. All rights reserved.