분산 트랜잭션에서 2PC·3PC·Paxos를 선택하는 기준
분산 트랜잭션의 원자성을 다루는 2PC, 3PC, Paxos의 동작 방식과 장애 특성, 실무 적용 지점을 정리합니다.
2026-08-14 · 최초 발행 2026-01-19
여러 노드가 하나의 결과를 확정해야 할 때
분산 트랜잭션은 참여 노드 전체가 함께 커밋하거나 함께 롤백해야 한다. 이 원자성을 지키지 못하면 한쪽 계좌에서만 출금되거나, 일부 노드만 변경된 상태가 남는다.
ACID 관점에서 분산 환경이 지켜야 할 기준은 다음과 같다.
- Atomicity(원자성): 모든 노드가 커밋하거나 모두 롤백한다.
- Consistency(일관성): 트랜잭션 전후 데이터 무결성을 유지한다.
- Isolation(격리성): 동시에 실행되는 트랜잭션이 서로 간섭하지 않는다.
- Durability(지속성): 커밋된 데이터는 영구 저장된다.
문제는 노드가 늘어날수록 실패도 독립적으로 발생한다는 점이다. 네트워크 분할로 통신이 끊길 수 있고, 참여자 또는 코디네이터가 중단될 수 있으며, 일부 노드만 성공하거나 실패하는 부분 실패도 생긴다.
2PC는 준비와 확정으로 커밋을 조율한다
2PC(Two-Phase Commit)는 코디네이터가 참여자들의 상태를 확인한 뒤 전체 결정을 전달하는 분산 커밋 프로토콜이다. 첫 단계에서 참여자는 실행 가능 여부를 기록하고, 다음 단계에서 코디네이터의 최종 결정을 따른다.
Phase 1인 Prepare에서 코디네이터는 모든 참여자에게 준비를 요청하고, 참여자는 READY 또는 ABORT로 응답한다. Phase 2에서는 전체 READY가 확인된 경우에만 COMMIT을 전달하며, 하나라도 ABORT를 반환하면 전체 트랜잭션을 ABORT한다.
구조가 단순하고 참여자 전체의 원자성을 보장한다는 장점이 있다. 반면 코디네이터가 장애를 일으키면 Prepared 상태의 참여자가 무한히 기다릴 수 있다. 코디네이터가 단일 장애점(SPOF)이 되며, 처리마다 2번의 네트워크 라운드트립이 필요하다.
Prepared 상태에서 코디네이터가 멈추면 참여자는 스스로 커밋 또는 롤백을 결정할 수 없다. 코디네이터가 재시작한 뒤 로그를 바탕으로 상태를 복구하거나, 타임아웃 이후 관리자가 개입하는 방식으로 복구한다.
3PC는 결정 이전의 불확실성을 줄인다
3PC(Three-Phase Commit)는 2PC의 블로킹 문제를 줄이기 위해 Pre-Commit 단계를 둔다. 모든 참여자가 READY를 보낸 뒤 바로 최종 커밋으로 가지 않고, 먼저 커밋 가능한 상태를 공유한다.
Prepare 단계는 2PC와 같다. Pre-Commit에서는 모든 참여자가 READY를 반환했을 때 커밋 가능한 상태로 바뀌고, Do-Commit에서 최종 커밋을 수행한다.
Pre-Commit 이후 코디네이터에 장애가 생기면 참여자가 타임아웃 뒤 자동 커밋할 수 있어 Non-Blocking 프로토콜로 설명된다. 다만 네트워크 분할에서는 여전히 일관성 문제가 생길 수 있다. 네트워크 라운드트립도 3번으로 늘어나며, 복잡도 대비 이득이 크지 않아 실무에서 2PC만큼 널리 쓰이지 않는다.
Paxos는 커밋이 아닌 합의 자체를 다룬다
Paxos는 여러 노드가 하나의 값에 합의하는 Consensus 문제를 해결한다. 일부 노드에 장애가 나도 합의를 진행할 수 있으며, 2PC와 3PC처럼 코디네이터에 의존하지 않는 Peer-to-Peer 구조다.
Proposer는 값을 제안하고, Acceptor는 제안을 수락하거나 거부한다. 합의에는 과반수의 수락이 필요하다. Learner는 최종 합의된 값을 학습한다.
Basic Paxos는 Prepare와 Accept 단계로 진행된다.
Prepare 단계에서 Proposer는 제안 번호 n을 보내고, Acceptor는 더 높은 번호를 수락하지 않았다면 Promise를 반환한다. Accept 단계에서는 Proposer가 값을 제안하며, Acceptor의 수락으로 합의가 성립한다.
Paxos의 Safety는 한 번에 하나의 값만 합의되도록 해 일관성을 보장한다는 뜻이다. 반면 경쟁 상황에서는 합의가 실패할 수 있어 Liveness 문제가 생길 수 있다. Multi-Paxos는 Leader를 선출해 Phase 1을 한 번만 수행하고 이후 Phase 2를 반복한다. Raft는 Paxos를 이해하기 쉬운 Leader 중심 구조로 재설계했으며, Leader Election, Log Replication, 커밋된 엔트리의 영구 보존을 다룬다.
파일시스템부터 조정 서비스까지 이어지는 적용 지점
분산 파일시스템에서는 HDFS의 NameNode가 메타데이터에 대해 Paxos/Raft 기반 합의를 사용하며, GFS(Google File System)는 Master 장애 때 Paxos로 새 Master를 선출한다.
분산 데이터베이스에서는 Google Spanner가 Paxos로 복제 그룹을 관리하고 2PC로 다중 그룹 트랜잭션을 처리한다. CockroachDB는 Raft 기반 복제와 분산 트랜잭션용 2PC를 적용하며, MongoDB는 Replica Set에서 Raft 유사 프로토콜을 사용한다.
분산 조정 서비스의 경우 Apache ZooKeeper는 Paxos 변형인 ZAB(ZooKeeper Atomic Broadcast) 프로토콜을 사용한다. etcd와 Consul은 Raft 합의 알고리즘을 사용하고, Chubby(Google)는 Paxos 기반 분산 락 서비스다.
운영체제 레벨에서도 같은 문제가 나타난다.
분산 공유 메모리는 페이지 업데이트를 합의해야 하고, 분산 락 관리자는 락 획득과 해제의 결정을 위해 Paxos를 활용할 수 있다. 클러스터 자원 스케줄러도 작업 할당에 대한 합의가 필요하다.
지연, 장애 허용, 구현 복잡도의 차이
| 특성 | 2PC | 3PC | Paxos |
|---|---|---|---|
| 라운드트립 | 2 | 3 | 2 (Basic Paxos) |
| 블로킹 | 예 | 조건부 | 아니오 |
| Fault Tolerance | 낮음 | 중간 | 높음 (과반수 생존) |
| 복잡도 | 낮음 | 중간 | 높음 |
| 적용 사례 | XA 트랜잭션 | 거의 없음 | 분산 합의 전반 |
성능을 조정할 때는 여러 트랜잭션을 묶어 한 번에 커밋하는 Batching, 다음 라운드를 기다리지 않고 제안을 이어가는 Pipelining을 사용할 수 있다. Paxos에서는 읽기와 쓰기 Quorum 크기를 조정하는 Quorum Tuning이 가능하고, 2PC에서는 독립적인 참여자 그룹을 병렬 처리하는 Parallel 2PC를 적용할 수 있다.
프로토콜을 운영 환경에 맞추는 방법
마이크로서비스 간 트랜잭션에서는 2PC와 Saga 패턴을 비교할 필요가 있다. XA 트랜잭션에서는 JDBC, JMS 등의 표준 API를 활용할 수 있으며, 타임아웃을 설정해 무한 대기를 막고 자동 롤백을 고려해야 한다.
Paxos 또는 Raft를 도입할 때는 최소 3개의 노드와 과반수 조건을 전제로 잡는다. 노드는 동일 데이터센터에 배치하는 편이 권장되며, 로그를 처리할 빠른 디스크 I/O가 필요하다. Leader 전환과 합의 지연도 모니터링 대상이다.
CAP 관점에서 2PC는 일관성과 분할 허용을 선택하며 가용성을 희생하는 CP 특성을 갖는다. Paxos 역시 과반수가 생존할 때 일관성과 분할 허용을 제공하는 CP 방식이다. 네트워크 분할이 드문 환경이라면 2PC를 허용할 수 있다.
2PC는 단순한 원자적 커밋에 적합하지만 블로킹을 감수해야 한다. 3PC는 이를 보완하려 했으나 복잡도와 실효성의 문제가 남는다. Paxos와 Raft는 장애 허용 합의가 필요한 분산 시스템의 기반이 되며, 2PC와 Paxos를 조합한 하이브리드 접근도 사용된다.