2단계 커밋이란?
여러 개의 데이터베이스나 서버에 걸쳐 하나의 트랜잭션을 처리해야 할 때가 있습니다. 예를 들어 주문 시스템에서 ‘재고 차감 DB’와 ‘결제 DB’가 서로 다른 서버에 있다면, 두 작업이 모두 성공하거나 모두 실패해야 데이터 정합성이 유지됩니다. 이런 상황에서 사용하는 대표적인 분산 트랜잭션 처리 방식이 바로 2단계 커밋(Two-Phase Commit, 2PC)입니다. 이름 그대로 트랜잭션을 준비 단계와 커밋 단계, 두 단계로 나누어 진행합니다.
동작 원리: Prepare와 Commit
2PC에는 전체를 조율하는 코디네이터(Coordinator)와 실제 작업을 수행하는 여러 참여자(Participant)가 존재합니다. 마치 결혼식 주례가 신랑, 신부에게 각각 ‘동의하십니까?’라고 묻고, 둘 다 ‘예’라고 답해야 최종적으로 ‘부부가 되었음을 선언’하는 것과 비슷한 구조입니다.
- 1단계 (Prepare): 코디네이터가 모든 참여자에게 ‘트랜잭션을 커밋할 준비가 되었는가?’를 묻습니다. 각 참여자는 실제 작업을 수행할 수 있는지 검증한 뒤, 가능하면
Yes, 불가능하면No를 응답합니다. - 2단계 (Commit/Rollback): 모든 참여자가
Yes를 보냈다면 코디네이터는 전체에게Commit명령을 내려 트랜잭션을 확정합니다. 단 한 곳이라도No를 보내거나 응답이 없다면, 전체에게Rollback을 지시해 작업을 취소시킵니다.
이렇게 하면 재고 차감은 성공했는데 결제는 실패하는 식의 ‘반쪽짜리 트랜잭션’을 방지할 수 있습니다.
실무에서 왜 쓰는지, 그리고 한계
2PC는 은행 간 송금, MSA 환경에서 여러 서비스의 상태를 동기화해야 하는 경우, 분산 데이터베이스의 트랜잭션 관리 등에 활용됩니다. 데이터 정합성을 강하게 보장한다는 장점이 있지만, 몇 가지 한계도 뚜렷합니다.
- 코디네이터가 장애로 멈추면 참여자들은 커밋도 롤백도 하지 못한 채
블로킹상태에 빠질 수 있습니다. - 모든 참여자의 응답을 기다려야 하므로 서비스 응답 속도가 느려질 수 있습니다.
- 참여자 수가 많아질수록 장애 지점이 늘어나 안정성이 떨어집니다.
이런 단점 때문에 최근 MSA 환경에서는 2PC 대신 Saga 패턴처럼 각 서비스가 독립적으로 커밋하고, 실패 시 보상 트랜잭션으로 되돌리는 방식을 더 선호하는 추세입니다. 하지만 2PC는 분산 트랜잭션의 가장 기본이 되는 개념이므로, 이후 등장하는 다양한 분산 처리 패턴을 이해하기 위한 출발점으로 꼭 알아둘 필요가 있습니다.