분산 트랜잭션: Saga와 2PC 중 무엇을 선택할까요?
한 줄 답변
강한 일관성이 필수인 금융 결제 등에는 2PC를 고려하되, 가용성과 확장성이 중요한 일반적인 MSA 환경에서는 보상 트랜잭션을 활용하는 Saga 패턴을 우선적으로 검토해야 합니다.
핵심 개념 정리
분산 트랜잭션은 여러 독립된 서비스나 데이터베이스에 걸쳐 수행되는 트랜잭션의 원자성을 보장하는 기술입니다. 과거 단일 DB 환경에서는 ACID를 쉽게 보장할 수 있었으나, 각 서비스가 전용 DB를 갖는 MSA 환경에서는 네트워크 지연이나 장애 시 데이터 불일치 위험이 큽니다.
2PC(Two-Phase Commit)는 모든 참여 노드가 커밋 준비가 되었는지 확인하는 Prepare 단계와 실제 커밋을 수행하는 Commit 단계로 나뉩니다. 중앙 조정자(Coordinator)가 모든 노드의 성공 여부를 확인한 뒤 최종 반영하므로 데이터의 강한 일관성(Strong Consistency)을 제공합니다. 하지만 특정 노드 장애 시 전체 시스템이 대기 상태에 빠지는 '블로킹' 문제와 성능 병목으로 인해 대규모 시스템에서는 확장이 어렵습니다.
Saga 패턴은 각 서비스의 로컬 트랜잭션을 순차적으로 실행하며, 중간에 실패가 발생하면 이미 완료된 단계들을 되돌리는 '보상 트랜잭션(Compensating Transaction)'을 비동기로 실행합니다. 이는 최종 일관성(Eventual Consistency)을 달성하는 방식으로, 시스템 가용성과 확장성이 매우 높습니다. 다만 개발자가 직접 보상 로직을 설계해야 하므로 구현 복잡도가 높고, 격리성(Isolation)이 완벽하지 않아 동시성 제어에 주의가 필요합니다.
비교 정리
| 항목 | 2PC (Two-Phase Commit) | Saga 패턴 |
|---|---|---|
| 일관성 모델 | 강한 일관성 (Strong) | 최종 일관성 (Eventual) |
| 가용성 | 낮음 (장애 시 전체 블로킹) | 높음 (비동기 및 격리 처리) |
| 성능 및 확장성 | 낮음 (중앙 코디네이터 병목) | 높음 (서비스 간 낮은 결합도) |
| 구현 난이도 | 낮음 (인프라 수준에서 지원) | 높음 (애플리케이션 보상 로직) |
면접에서 이렇게 답하세요
면접에서는 단순히 'Saga가 최신이라 좋다'는 식의 답변보다는 비즈니스 요구사항에 따른 트레이드오프를 설명하는 것이 핵심입니다. 금융권의 계좌 이체처럼 즉각적인 정합성이 중요한지, 혹은 이커머스의 주문 완료 후 포인트 적립처럼 지연 처리가 허용되는지를 구분하세요. 실무에서 보상 트랜잭션의 멱등성을 어떻게 보장했는지나, 메시지 큐를 활용한 이벤트 기반 설계를 언급하면 좋은 점수를 얻을 수 있습니다.
자주 묻는 추가 질문
Q. Saga 패턴에서 보상 트랜잭션 자체가 실패하면 어떻게 하나요?
보상 트랜잭션은 성공할 때까지 재시도되어야 하며, 지속적인 실패 시 Dead Letter Queue에 담아 운영자의 수동 개입이나 별도의 복구 프로세스를 거치도록 설계해야 합니다.
Q. Choreography와 Orchestration Saga의 차이는 무엇인가요?
이벤트 발행을 통해 서비스들이 자율적으로 연쇄 반응하는 것이 Choreography, 중앙 제어기가 각 서비스의 호출 순서를 관리하는 것이 Orchestration 방식입니다.
Q. 2PC가 실제 실무에서 기피되는 가장 큰 이유는 무엇인가요?
네트워크 파티션이나 특정 노드의 일시적 장애가 전체 트랜잭션의 타임아웃과 리소스 점유로 이어져 시스템 전체의 처리량(Throughput)을 급격히 저하시키기 때문입니다.
커뮤니티 하이라이트
“실무에선 보상 트랜잭션을 짜는 게 생각보다 고통스럽습니다. 설계 단계부터 멱등성과 실패 시나리오를 꼼꼼히 정의하는 게 제일 중요해요.”
“강한 일관성이 꼭 필요한 도메인인지 먼저 자문해 보세요. 대부분의 비즈니스 유스케이스는 지연된 일관성으로도 충분히 운영 가능합니다.”
42명의 개발자가 이 질문에 참여했습니다
관련 면접 질문
앱에서 직접 답변해보세요
매일 3개의 면접 질문에 답변하고,
다른 개발자들의 답변을 비교해보세요.