Two-Phase Commit이 사라진 이유

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

현대적인 소프트웨어 아키텍처에서 데이터의 일관성을 유지하는 것은 매우 어려운 과제입니다. 특히 여러 대의 서버나 데이터베이스가 서로 협력하여 하나의 작업을 완수해야 하는 분산 환경에서는 더욱 그렇습니다. 이러한 환경에서 데이터의 무결성을 지키기 위해 오랫동안 표준처럼 사용되어 온 기술이 바로 투 페이즈 커밋(Two Phase Commit, 2PC)입니다. 하지만 최근의 클라우드 네이티브 환경이나 대규모 마이크로서비스 아키텍처에서 2PC는 점차 자취를 감추고 있습니다. 왜 이런 변화가 일어났는지, 그리고 우리는 어떤 대안을 선택해야 하는지 자세히 살펴보겠습니다.

투 페이즈 커밋의 기본 원리와 동작 방식

투 페이즈 커밋은 이름 그대로 두 단계에 걸쳐 트랜잭션을 처리합니다. 이 알고리즘은 분산 시스템 내의 모든 참여자가 동일한 결과를 공유하도록 강제하는 목적을 가집니다. 과정을 살펴보면 다음과 같습니다.

• 준비 단계(Prepare Phase): 트랜잭션 조정자(Coordinator)가 모든 참여자에게 트랜잭션을 실행할 준비가 되었는지 묻습니다. 참여자는 작업을 수행하고 결과를 임시로 저장한 뒤, 성공 여부를 응답합니다.
• 커밋 단계(Commit Phase): 모든 참여자가 성공을 응답하면 조정자는 최종적으로 커밋 명령을 내립니다. 만약 단 하나라도 실패하거나 응답이 없으면 조정자는 모든 참여자에게 롤백(Rollback)을 명령하여 작업을 취소합니다.

이 방식은 모든 노드가 100% 일치된 상태를 유지해야 하는 은행 시스템이나 전통적인 관계형 데이터베이스 환경에서는 매우 강력한 도구였습니다. 데이터가 섞이거나 일부만 반영되는 일을 원천적으로 차단하기 때문입니다.

왜 투 페이즈 커밋이 사라지고 있는가

2PC가 강력함에도 불구하고 현대 시스템에서 외면받는 이유는 시스템의 가용성과 확장성을 심각하게 저해하기 때문입니다. 이를 이해하기 위해서는 CAP 이론을 기억해야 합니다. 분산 시스템은 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 세 가지를 동시에 만족할 수 없다는 이론입니다.

블로킹 문제로 인한 성능 저하

2PC는 동기식 방식으로 작동합니다. 즉, 조정자가 모든 참여자의 응답을 기다리는 동안 해당 데이터베이스의 자원은 잠금(Lock) 상태가 됩니다. 만약 네트워크가 느려지거나 참여자 중 한 곳이라도 응답이 지연되면, 전체 시스템이 멈춰버리는 블로킹 현상이 발생합니다. 이는 사용자에게 긴 대기 시간을 유발하며, 트래픽이 많은 현대 서비스에서는 치명적인 결함이 됩니다.

단일 장애 지점의 위험

조정자(Coordinator)가 시스템의 핵심 역할을 수행하기 때문에, 조정자가 고장 나면 전체 트랜잭션이 마비됩니다. 이를 복구하기 위한 복잡한 메커니즘이 필요하며, 분산 시스템의 복잡도를 기하급수적으로 높입니다. 또한, 참여자가 많아질수록 통신 횟수가 늘어나 효율성이 급격히 떨어지는 단점이 있습니다.

실무에서 자주 접하는 오해와 진실

많은 개발자가 강력한 일관성만이 정답이라고 생각하지만, 실제 서비스 운영에서는 다른 접근이 필요할 때가 많습니다. 2PC와 관련하여 흔히 발생하는 오해를 짚어봅니다.

• 오해 1: 모든 데이터는 즉시 일관되어야 한다.
• 진실: 대부분의 비즈니스 로직은 ‘결과적 일관성(Eventual Consistency)’만으로도 충분합니다. 예를 들어, 온라인 쇼핑몰에서 재고가 1~2초 뒤에 반영되는 것은 시스템 운영상 큰 문제가 되지 않습니다.
• 오해 2: 2PC를 사용하지 않으면 데이터가 깨진다.
• 진실: 2PC 대신 사가(Saga) 패턴이나 메시지 큐를 활용한 비동기 처리를 사용하면, 데이터 정합성을 유지하면서도 시스템 성능을 크게 향상할 수 있습니다.

현대적인 대안 사가 패턴의 활용

최근에는 2PC 대신 사가 패턴(Saga Pattern)이 사실상 표준으로 자리 잡고 있습니다. 사가 패턴은 긴 트랜잭션을 여러 개의 작은 로컬 트랜잭션으로 나눕니다. 각 단계가 성공하면 다음 단계로 넘어가고, 만약 중간에 실패가 발생하면 이전 단계들을 순차적으로 취소하는 보상 트랜잭션(Compensating Transaction)을 실행합니다.

사가 패턴의 장점

• 비동기 처리: 각 단계가 독립적으로 실행되므로 시스템 전체가 블로킹되지 않습니다.
• 확장성: 서비스 간의 결합도가 낮아져 시스템 규모를 키우기가 훨씬 수월합니다.
• 유연성: 특정 서비스가 잠시 중단되더라도 재시도 로직을 통해 복구가 가능합니다.

사가 패턴 적용 시 주의사항

사가 패턴은 구현이 복잡합니다. 보상 트랜잭션을 설계할 때 오류가 발생하지 않도록 꼼꼼하게 작성해야 하며, 전체 트랜잭션의 상태를 추적하기 위한 별도의 모니터링 시스템이 필요합니다. 전문가들은 처음부터 완벽한 사가 패턴을 도입하기보다는, 비즈니스 흐름을 단순하게 유지하는 것부터 시작하라고 조언합니다.

분산 시스템 설계자를 위한 전문가 조언

분산 환경에서 데이터 일관성을 관리할 때는 ‘비즈니스 가치’를 먼저 고려해야 합니다. 무조건 2PC를 사용하여 100% 일관성을 유지하는 것이 기술적인 정답은 아닙니다. 오히려 시스템의 응답 속도가 느려져 사용자가 이탈한다면, 그 시스템은 실패한 것이나 다름없습니다.

첫째, 데이터의 중요도를 구분하세요. 결제나 계좌 이체처럼 엄격한 일관성이 필요한 데이터와, 상품 조회수나 추천 목록처럼 약간의 지연이 허용되는 데이터를 분리하여 처리하는 전략이 필요합니다.

둘째, 메시지 브로커를 활용하세요. 카프카(Kafka)나 래빗엠큐(RabbitMQ)와 같은 메시지 큐는 시스템 간의 결합도를 낮추고 데이터 전달의 신뢰성을 보장하는 훌륭한 도구입니다. 2PC의 동기식 통신 대신 메시지 기반의 비동기 통신을 도입하는 것만으로도 시스템 안정성이 비약적으로 상승합니다.

셋째, 멱등성(Idempotency)을 보장하세요. 네트워크 오류로 인해 메시지가 중복 전달되더라도 결과가 달라지지 않도록 설계하는 것은 분산 시스템의 기본 소양입니다. 동일한 요청을 여러 번 보내도 결과가 한 번만 반영되도록 API를 설계하는 것이 2PC를 대체하는 핵심 열쇠입니다.

자주 묻는 질문과 답변

Q: 2PC를 아예 사용하지 말아야 하나요?

A: 그렇지 않습니다. 마이크로서비스 외부의 레거시 시스템과 연동해야 하거나, 데이터의 무결성이 생명과 직결되는 아주 특수한 금융 인프라 내부에서는 여전히 2PC가 유효합니다. 다만, 일반적인 웹 서비스나 마이크로서비스 환경에서는 가급적 피하는 것이 좋습니다.

Q: 결과적 일관성으로 인해 발생하는 사용자 경험 문제는 어떻게 해결하나요?

A: 사용자에게는 ‘처리 중’이라는 상태를 명확히 보여주거나, 푸시 알림을 통해 작업 완료를 알려주는 UI/UX 전략을 병행해야 합니다. 데이터가 즉시 반영되지 않더라도 시스템이 사용자에게 적절한 피드백을 제공한다면 사용자는 이를 신뢰할 수 있습니다.

Q: 사가 패턴 도입 시 비용이 많이 들지 않나요?

A: 초기 설계와 테스트 비용은 발생하지만, 시스템 장애 대응 시간과 확장성 측면에서 얻는 이득이 훨씬 큽니다. 장기적으로 볼 때 2PC의 고질적인 성능 문제로 인해 서버를 계속 증설하는 것보다 훨씬 비용 효율적입니다.

결론적으로, 기술은 시대의 요구에 따라 변화합니다. 2PC는 과거의 제약 조건 속에서 최선의 선택이었지만, 이제는 더 나은 성능과 가용성을 제공하는 다양한 패턴들이 그 자리를 대신하고 있습니다. 새로운 기술을 도입할 때는 그 기술이 가진 본질적인 제약 사항을 명확히 이해하고, 현재 우리가 해결하고자 하는 문제가 무엇인지 깊이 고민하는 자세가 무엇보다 중요합니다.