Two-Phase Commit이 사라진 이유

분산 시스템의 고전적인 합의 알고리즘 투 페이즈 커밋

현대적인 웹 애플리케이션이나 클라우드 서비스는 하나의 서버가 아닌 수많은 서버가 협력하여 작동하는 분산 환경 위에서 구축됩니다. 이때 가장 큰 난제 중 하나는 여러 서버에 흩어진 데이터를 어떻게 일관되게 유지하느냐 하는 것입니다. 이를 해결하기 위해 과거부터 사용되어 온 대표적인 기법이 바로 투 페이즈 커밋(Two-Phase Commit, 2PC)입니다.

투 페이즈 커밋은 이름 그대로 데이터를 처리하는 과정을 두 단계로 나누어 수행합니다. 모든 참여자에게 작업을 준비할지 묻는 ‘준비 단계’와, 모두가 준비되었다고 응답하면 실제 변경 사항을 적용하는 ‘커밋 단계’로 이루어집니다. 이 방식은 데이터의 무결성을 보장하는 가장 확실한 방법처럼 보였지만, 시간이 흐르며 현대적인 대규모 시스템에서는 점차 그 자리를 감추게 되었습니다. 왜 투 페이즈 커밋이 과거의 유물이 되어가고 있는지, 그리고 그 대신 어떤 방식들이 활용되고 있는지 자세히 살펴보겠습니다.

투 페이즈 커밋이 작동하는 원리와 구조

투 페이즈 커밋은 트랜잭션 관리자(Coordinator)와 여러 데이터 저장소(Participant) 사이의 약속입니다. 이 과정은 다음과 같이 진행됩니다.

• 준비 단계: 트랜잭션 관리자가 모든 참여자에게 데이터 변경이 가능한지 묻습니다. 참여자는 변경 내용을 임시 저장하고 성공 여부를 응답합니다.
• 커밋 단계: 모든 참여자가 성공을 알리면 관리자는 최종 확정 명령을 내립니다. 만약 단 한 곳이라도 실패하면 관리자는 모든 참여자에게 작업을 취소하라는 명령을 보냅니다.

이 방식의 핵심은 ‘전부 아니면 전무(All or Nothing)’ 원칙입니다. 데이터가 중간 상태로 남지 않게 함으로써 완벽한 일관성을 보장합니다. 하지만 이 강력한 장점이 현대 시스템에서는 치명적인 단점으로 작용하게 됩니다.

투 페이즈 커밋이 외면받는 결정적인 이유

현대적인 분산 시스템에서 투 페이즈 커밋이 사라진 이유는 시스템의 가용성과 확장성을 저해하기 때문입니다. 이를 구체적인 문제점별로 정리하면 다음과 같습니다.

차단 문제와 성능 저하

투 페이즈 커밋은 동기식 프로토콜입니다. 트랜잭션 관리자가 명령을 내린 후 모든 참여자의 응답이 올 때까지 기다려야 합니다. 만약 특정 참여자가 네트워크 지연이나 장애로 인해 응답하지 않는다면, 전체 시스템은 해당 응답을 기다리며 멈춰 서게 됩니다. 이를 ‘차단(Blocking)’ 상태라고 합니다. 대규모 트래픽이 발생하는 서비스에서 이런 대기 시간은 곧 서비스 중단으로 이어집니다.

단일 장애점의 위험성

모든 결정을 트랜잭션 관리자가 내리기 때문에 관리자가 고장 나면 시스템 전체가 마비됩니다. 관리자가 상태를 기억하고 복구하는 과정이 매우 복잡하며, 이 과정에서 발생하는 병목 현상은 분산 시스템의 확장성을 심각하게 제한합니다.

확장성의 한계

서버 수가 늘어날수록 통신 비용이 기하급수적으로 증가합니다. 10개의 서버가 2단계에 걸쳐 통신해야 한다면 오가는 메시지 수가 수십 개에 달합니다. 클라우드 환경에서 수천 대의 서버를 운영할 때 투 페이즈 커밋을 사용하는 것은 사실상 불가능에 가깝습니다.

투 페이즈 커밋에 대한 흔한 오해와 진실

투 페이즈 커밋에 대해 많은 개발자가 오해하는 부분들이 있습니다. 이를 명확히 짚고 넘어가는 것이 중요합니다.

• 오해: 투 페이즈 커밋은 데이터 일관성을 위해 반드시 필요하다.
• 진실: 투 페이즈 커밋은 ‘강한 일관성’을 제공하지만, ‘최종적 일관성’만으로도 충분한 서비스가 많습니다. 모든 데이터가 실시간으로 일치할 필요는 없다는 뜻입니다.
• 오해: 데이터베이스 자체의 트랜잭션과는 다른 개념이다.
• 진실: 데이터베이스 내부의 트랜잭션은 투 페이즈 커밋과 유사한 메커니즘을 사용하지만, 이는 단일 노드 내에서의 이야기입니다. 여러 노드에 걸친 분산 환경에서는 훨씬 복잡한 문제가 발생합니다.

현대적인 대안 기술과 활용 방법

투 페이즈 커밋을 대체하기 위해 오늘날의 아키텍처는 가용성을 희생하지 않는 방향으로 발전했습니다. 가장 대표적인 방법은 사가(Saga) 패턴입니다.

사가 패턴의 개념

사가 패턴은 전체 트랜잭션을 여러 개의 작은 로컬 트랜잭션으로 쪼개어 처리합니다. 각 서비스는 자신의 데이터베이스만 업데이트하고, 다음 단계로 이벤트를 전달합니다. 만약 중간에 실패가 발생하면, 앞서 수행한 작업을 취소하는 ‘보상 트랜잭션(Compensating Transaction)’을 실행하여 전체 상태를 원상복구합니다.

최종적 일관성 모델

데이터가 즉시 일치하지 않더라도 시간이 지나면 모든 노드가 결국 같은 상태가 된다는 개념입니다. 이는 사용자 경험을 저해하지 않는 선에서 시스템의 응답 속도를 비약적으로 높여줍니다. 예를 들어, 온라인 쇼핑몰에서 결제 후 주문 완료 메시지가 바로 뜨지 않고 ‘처리 중’으로 표시되는 것이 최종적 일관성을 활용한 전형적인 사례입니다.

분산 합의 알고리즘의 활용

라프트(Raft)나 팩소스(Paxos)와 같은 알고리즘은 투 페이즈 커밋보다 훨씬 견고합니다. 이들은 시스템 내 과반수의 동의만 얻으면 작업을 진행할 수 있습니다. 즉, 일부 서버가 응답하지 않아도 시스템 전체는 멈추지 않고 계속 작동할 수 있는 높은 가용성을 제공합니다.

개발자와 설계자를 위한 실용적인 조언

시스템을 설계할 때 투 페이즈 커밋을 고려하고 있다면, 다시 한번 신중하게 생각해야 합니다. 다음의 체크리스트를 활용해 보세요.

• 정말 강한 일관성이 필요한가: 금융 거래나 핵심 자산 관리라면 투 페이즈 커밋이 필요할 수 있지만, 일반적인 사용자 활동 데이터라면 최종적 일관성으로 충분합니다.
• 시스템의 규모는 어느 정도인가: 서버가 3대 이하의 소규모라면 투 페이즈 커밋을 사용해도 큰 문제가 없지만, 마이크로서비스 아키텍처라면 사가 패턴을 도입하는 것이 훨씬 유리합니다.
• 보상 트랜잭션을 구현할 수 있는가: 사가 패턴을 도입하려면 작업 실패 시 데이터를 되돌리는 로직을 반드시 설계해야 합니다. 이는 구현 난이도가 높지만 시스템의 안정성을 극대화합니다.

전문가들은 분산 시스템에서 ‘완벽함’을 추구하는 것이 가장 큰 위험 요소라고 경고합니다. 시스템이 커질수록 장애는 발생하기 마련이며, 장애가 발생했을 때 시스템 전체를 멈추게 하는 설계는 피해야 합니다. 따라서 투 페이즈 커밋처럼 모든 참여자의 응답을 강제하는 방식보다는, 부분적인 성공을 허용하고 나중에 이를 보정하는 비동기적인 접근 방식이 훨씬 더 효율적이고 경제적입니다.

자주 묻는 질문과 답변

분산 트랜잭션과 투 페이즈 커밋에 대해 궁금해하는 내용을 모았습니다.

• 질문: 투 페이즈 커밋을 아예 쓰지 말아야 하나요?
• 답변: 아닙니다. 데이터 무결성이 무엇보다 중요한 금융권의 특정 핵심 모듈에서는 여전히 사용됩니다. 다만, 웹 서비스 전반에 적용하는 것은 권장되지 않습니다.
• 질문: 사가 패턴은 어떻게 구현하나요?
• 답변: 메시지 큐(Kafka, RabbitMQ)를 사용하여 서비스 간 이벤트를 전달하고, 각 서비스 내에서 로컬 트랜잭션을 처리한 뒤 성공 또는 실패 이벤트를 발행하는 방식으로 구현합니다.
• 질문: 투 페이즈 커밋과 3단계 커밋(3PC)의 차이는 무엇인가요?
• 답변: 3단계 커밋은 중간 단계를 추가하여 차단 문제를 해결하려 했지만, 여전히 네트워크 장애에 취약하며 복잡도가 높아져 실무에서 거의 사용되지 않습니다.

투 페이즈 커밋은 분산 데이터 처리를 이해하는 아주 중요한 출발점입니다. 비록 현대 시스템에서는 그 자리를 사가 패턴이나 분산 합의 알고리즘에 내주었지만, 이 기술이 해결하고자 했던 ‘데이터 무결성’이라는 본질적인 목표는 여전히 모든 시스템 설계의 핵심입니다. 기술의 유행을 쫓기보다는, 자신의 서비스가 요구하는 가용성과 일관성의 균형점을 찾아 최적의 아키텍처를 선택하는 안목이 필요합니다.