CS Fundamentals
분산 트랜잭션에 대해서 설명해주세요
마이크로서비스에서 여러 DB에 걸친 트랜잭션을 어떻게 처리할까요? 2PC의 한계부터 Saga 패턴의 보상 트랜잭션, Transactional Outbox로 이벤트 유실을 방지하는 방법까지 인터랙티브 시각화로 완전 정복합니다.
2026년 3월 15일 · 약 15분 읽기
Q. "마이크로서비스 환경에서 여러 서비스에 걸친 트랜잭션을 어떻게 처리하시겠습니까?"
예상 꼬리질문
답변 가이드
"마이크로서비스에서는 서비스마다 별도의 DB를 사용하기 때문에 단일 DB 트랜잭션으로 원자성을 보장할 수 없습니다. 부분 실패 시 데이터 불일치가 발생합니다."
"2PC는 강한 일관성을 보장하지만 코디네이터가 단일 장애점(SPOF)이 됩니다. Saga 패턴은 각 서비스가 로컬 트랜잭션을 커밋하고, 실패 시 보상 트랜잭션으로 되돌려 최종적 일관성을 보장합니다."
"이벤트 유실 문제는 Transactional Outbox 패턴으로 해결합니다. DB 저장과 이벤트 발행을 같은 트랜잭션으로 묶어 원자성을 확보합니다."
단일 DB에서는 BEGIN TRANSACTION ... COMMIT으로 모든 것을 원자적으로 처리할 수 있습니다. 하지만 마이크로서비스 아키텍처에서는 주문 서비스, 결제 서비스, 재고 서비스가 각자 별도의 DB를 가집니다.
"결제는 됐는데 재고는 그대로"라는 데이터 불일치가 발생할 수 있습니다. 이 문제를 어떻게 해결하는지 인터랙티브 시각화로 체험합니다.
1. 왜 분산 트랜잭션이 어려운가
꼬리질문: "분산 환경에서 트랜잭션이 왜 어렵나요?"
분산 환경에서는 네트워크 장애, 서비스 크래시 등으로 부분 실패가 발생합니다. 일부 서비스는 커밋되고 일부는 실패하면 전체 데이터 일관성이 깨집니다.
단순 재시도로는 이미 커밋된 서비스를 되돌릴 수 없습니다. 아래에서 부분 실패 시나리오를 확인해 보세요.
2. 2PC(2단계 커밋) — 강한 일관성의 대가
꼬리질문: "2PC(2단계 커밋)의 문제점이 뭔가요?"
2PC(Two-Phase Commit)는 코디네이터가 모든 참여자에게 "커밋 가능한가?" 묻는 Phase 1과 결과에 따라 "커밋/중단"을 명령하는 Phase 2로 나뉩니다. 하나라도 No라고 하면 전체 중단, 모두 Yes면 전체 커밋합니다.
강한 일관성을 보장하지만 코디네이터가 Phase 2 시작 직전에 장애가 나면 모든 참여자가 락을 보유한 채 결과를 알 수 없는 In-Doubt 상태에 빠집니다.
아래 시뮬레이터에서 2PC 흐름과 코디네이터 장애 시나리오를 체험해 보세요.
3. Saga 패턴 — 최종적 일관성
꼬리질문: "Saga 패턴이 무엇이고, 보상 트랜잭션은 어떻게 동작하나요?"
Saga 패턴은 각 서비스가 로컬 트랜잭션을 커밋하고 이벤트를 발행합니다. 중간에 실패하면 이미 커밋된 서비스를 보상 트랜잭션(Compensating Transaction)으로 되돌립니다.
2PC와 달리 분산 락을 사용하지 않으므로 가용성이 높습니다. 단, 보상 트랜잭션이 실행되는 동안 일시적 불일치가 존재합니다 — 이것이 "격리성 없음"입니다.
아래에서 Saga 흐름과 보상 트랜잭션 과정을 직접 시뮬레이션해 보세요.
4. 코레오그래피 vs 오케스트레이션
꼬리질문: "코레오그래피와 오케스트레이션의 차이가 뭔가요?"
Saga를 구현하는 방식은 두 가지입니다. 코레오그래피(Choreography)는 각 서비스가 이벤트를 구독하고 반응합니다. 느슨한 결합이지만 전체 흐름을 파악하기 어렵습니다.
오케스트레이션(Orchestration)은 중앙 조정자가 각 서비스에 명령을 내립니다. 흐름이 명확하지만 조정자가 단일 장애점이 될 수 있습니다.
두 방식의 트레이드오프를 비교해 보세요.
각 방식을 클릭하면 세부 비교를 확인할 수 있습니다
5. Transactional Outbox — 이벤트 유실 방지
꼬리질문: "Transactional Outbox 패턴은 어떤 문제를 해결하나요?"
Saga를 구현할 때 가장 큰 위험은 이벤트 유실입니다. DB에 저장하고 Kafka에 발행하려는 순간 서비스가 죽으면 DB에는 저장됐지만 이벤트는 발행되지 않아 Saga가 멈춥니다.
Transactional Outbox 패턴은 이벤트를 별도 outbox_events 테이블에 같은 트랜잭션으로 저장합니다. Message Relay 프로세스가 이 테이블을 폴링해 Kafka에 발행합니다.
Kafka 장애가 발생해도 outbox 테이블에 레코드가 남아있어 재시도할 수 있습니다.
면접 체크리스트
이 항목들을 자신 있게 설명할 수 있다면 분산 트랜잭션 질문은 준비 완료입니다.
- - 부분 실패 문제: 분산 환경에서 일부 서비스만 커밋되면 데이터 불일치 발생
- - 2PC: 강한 일관성, 코디네이터 장애 시 In-Doubt(SPOF 문제)
- - Saga: 로컬 트랜잭션 + 보상 트랜잭션, 최종적 일관성, 격리성 없음
- - 코레오그래피 vs 오케스트레이션: 느슨한 결합 vs 높은 가시성
- - Transactional Outbox: DB 저장과 이벤트 발행을 원자적으로 — 이벤트 유실 방지
참고 자료
- microservices.io — Saga Pattern — Saga 패턴의 공식적인 정의와 코레오그래피/오케스트레이션 비교
- microservices.io — Transactional Outbox — Transactional Outbox 패턴의 원리와 구현 방법
- Martin Fowler — Saga — 분산 시스템 패턴에서 2PC와 Saga를 설명하는 Martin Fowler의 글
- Baeldung — Saga Pattern in Microservices — Saga 패턴 구현 방법과 Spring 예제 코드
의견을 들려주세요
서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.