2단계 커밋 (Two-Phase Commit)
쉽게 풀면
여러 사람이 동시에 계약서에 서명해야 효력이 발생하는 상황을 생각해 보세요. 먼저 "다들 서명할 준비가 됐습니까?"라고 물어보고(1단계, 준비 단계) 전원이 "예"라고 답해야만 실제로 도장을 찍습니다(2단계, 커밋 단계). 만약 단 한 명이라도 "아니오"라고 하면 아무도 도장을 찍지 않고 전체를 취소합니다. 은행 계좌 이체처럼 여러 서버에 걸쳐 있는 작업을 처리할 때, 한쪽 서버는 성공하고 다른 쪽은 실패해서 데이터가 어긋나는 사고를 막기 위해 이런 2단계 확인 절차를 사용합니다.
왜 중요한가
분산 시스템은 여러 노드가 독립적으로 실패할 수 있기 때문에, 하나의 논리적 작업을 여러 서버에 걸쳐 원자적으로 완료하는 문제는 분산 데이터베이스와 마이크로서비스 아키텍처 연구에서 핵심 주제로 다뤄집니다. 2단계 커밋은 이 문제에 대한 가장 고전적인 해법이라 이후 등장한 3단계 커밋, 분산 합의 알고리즘, 사가(saga) 패턴 등을 비교·평가하는 기준선으로 논문에서 자주 인용됩니다. 또한 성능과 일관성 사이의 트레이드오프를 논의할 때 대표적인 사례로 언급됩니다.
논문에서는 이렇게 쓰입니다
이 문장은 여러 서버에 흩어진 데이터를 하나의 트랜잭션으로 묶어 처리할 때 2단계 커밋을 사용했고, 그 과정에서 중앙 조정자가 멈췄을 때 생기는 지연 시간을 실험으로 확인했다는 뜻입니다.
서비스가 여러 개로 쪼개진 시스템에서 2단계 커밋을 쓰면 참여자가 늘어날수록 모두의 응답을 기다려야 하므로 처리 시간이 길어진다는 실험 결과를 설명하는 문장입니다.
여러 지역(리전)에 데이터가 복제된 클라우드 스토리지에서도 2단계 커밋의 아이디어를 응용하여 일관성을 맞추려는 시도를 설명하는 문장입니다.
조금 더 깊게 보면
2단계 커밋의 준비 단계에서 참여자는 자신의 작업 결과를 로그에 기록해 두고 커밋 또는 롤백 준비를 마쳤음을 알리는데, 이 로그가 있어야 조정자나 참여자가 장애 후 재시작해도 이전 상태를 복구할 수 있습니다. 이 프로토콜의 근본적인 한계인 블로킹 문제를 완화하기 위해 제안된 것이 3단계 커밋(three-phase commit)이며, 최근 분산 시스템 논문에서는 아예 중앙 조정자 없이 합의를 이루는 Paxos나 Raft 같은 합의 알고리즘, 또는 보상 트랜잭션을 활용하는 사가 패턴과 비교하는 방식으로 다뤄지는 경우가 많습니다.
주의할 점
2단계 커밋은 참여 서버 전원의 동의를 기다려야 하므로, 조정자(coordinator) 역할을 하는 서버가 응답 없이 멈추면 나머지 참여자들도 계속 대기 상태에 빠지는 "블로킹" 문제가 있다. 이 때문에 대규모 분산 시스템에서는 분산 합의 알고리즘이나 CAP 정리에서 다루는 다른 절충안이 함께 논의된다.