2014년 USENIX ATC에서 발표된 논문 한 편이 Best Paper Award를 받았어요. 제목부터 이례적이었습니다 — “In Search of an Understandable Consensus Algorithm(이해 가능한 합의 알고리즘을 찾아서)”. 스탠퍼드의 Diego Ongaro와 John Ousterhout이 쓴 이 논문은 성능이나 이론적 새로움을 내세우지 않고, “우리는 그냥 이해하기 쉬운 알고리즘을 만들고 싶었다”는 목표를 정면에 내걸었어요. 그리고 그 대상은 1998년 Leslie Lamport가 발표한 이래 분산 합의의 사실상 표준이었던 Paxos였습니다. 그로부터 10여 년, etcd·Consul·CockroachDB 같은 핵심 인프라들은 대부분 Paxos가 아니라 이 Raft를 선택했어요. 대체 Raft는 Paxos와 정확히 어떤 지점에서 다른 선택을 했길래, 업계가 그렇게 몰려간 걸까요?
Raft 논문이 명시한 목표는 무엇인가
Raft 논문의 목표는 새로운 이론이 아니라 이해가능성(understandability) 그 자체예요. 논문은 초록에서 Raft가 “(Multi-)Paxos와 동등한 결과를 만들어내고 Paxos만큼 효율적”이라고 밝히면서도, 구조는 Paxos와 다르게 설계했고 그 이유가 “Raft를 더 이해하기 쉽게 만들고, 실용적인 시스템을 구축하기 위한 더 나은 기반을 제공하기 위해서”라고 명시합니다. 논문이 스스로를 성능이나 정확성 증명이 아니라 ‘가르치고 구현하기 쉬운 정도’로 평가하겠다고 선언한 셈이에요.
이 목표를 검증하려고 저자들은 실제로 사용자 연구까지 진행했어요. 스탠퍼드와 버클리 두 대학에서 상급 학부생·대학원생 43명을 모아 Raft 강의 영상과 Paxos 강의 영상을 각각 보여준 뒤 같은 난이도의 퀴즈를 풀게 했고, 참가자 순서도 절반씩 바꿔가며 편향을 줄였습니다. 결과는 Raft 쪽 평균 점수가 Paxos보다 높게 나왔고, 심지어 참가자 다수가 이미 Paxos 경험이 있어 Paxos에 유리한 조건이었는데도 그랬다는 점을 논문은 강조해요. 논문 저자들조차 “이 결과가 Paxos에 유리하게 작용했을 조건에서 나왔다”고 밝힌 대목은, 알고리즘의 우열을 성능이 아니라 ‘학습 곡선’으로 증명하려 한 이례적인 시도였다는 걸 보여줍니다.
Paxos는 왜 그렇게 어렵다는 평가를 받았나
Paxos가 어렵다는 평가는 알고리즘 자체보다 명세가 흩어져 있었다는 데서 시작돼요. Lamport의 원조 논문 The Part-Time Parliament는 1989년에 쓰였지만 그리스 의회 비유로 프로토콜을 설명하는 서술 방식 탓에 널리 읽히지 못했고, 정식 발표도 1998년에야 이뤄졌습니다. 너무 난해하다는 반응이 이어지자 Lamport는 2001년 이를 쉽게 풀어 쓴 Paxos Made Simple을 발표했는데, 이 논문의 초록은 “Paxos 알고리즘은 평이한 영어로 설명하면 아주 단순하다”는 문장으로 시작해요.
그런데 Paxos Made Simple이 실제로 명세한 건 단 하나의 값에 합의하는 Single-decree Paxos였습니다. etcd나 Consul처럼 계속 이어지는 로그 전체를 복제해야 하는 실제 시스템에는 여러 인스턴스의 Paxos를 연속으로 실행하는 Multi-Paxos가 필요한데, 이 확장 방식은 원 논문에 상세히 규정되지 않았어요. 그 결과 실무자들은 리더를 어떻게 선출할지, 로그 슬롯을 어떻게 채울지, 멤버십을 어떻게 바꿀지를 각자 알아서 채워 넣어야 했고, 같은 이름의 Paxos를 쓰면서도 구현마다 세부 동작이 달라지는 상황이 벌어졌습니다. HashiCorp이 Consul의 합의 프로토콜을 설명하며 “Paxos는 선택하는 사람 마음대로 채워야 하는 미완성 설계도 같았다”고 표현한 것도 이 지점을 가리켜요. 여기서 끝이 아니에요 — 바로 이 ‘미완성으로 남겨진 부분’을 Raft는 논문 한 편 안에서 전부 구체적으로 명세하는 쪽을 택했습니다.
Raft는 구조적으로 어떤 다른 선택을 했나
Raft가 이해가능성을 확보한 방법은 합의 문제를 강한 리더(strong leader) 중심으로 분해한 것입니다. Paxos는 이론적으로 여러 제안자(proposer)가 동시에 값을 제안할 수 있는 대칭적 구조라 두 제안이 충돌하는 경우까지 고려해야 하지만, Raft는 항상 단 하나의 리더만 로그 항목을 추가하고 팔로워는 그 순서를 그대로 받아 적습니다. 클라이언트 요청도 전부 리더로만 향하기 때문에, “지금 누가 결정권을 가지고 있는가”를 추론할 때 머릿속에 그려야 할 경우의 수 자체가 줄어들어요.
이 구조는 논문이 밝힌 대로 합의 문제를 리더 선출, 로그 복제, 안전성이라는 세 개의 독립된 하위 문제로 쪼갠 결과이기도 합니다. 리더 선출은 무작위화된 타임아웃으로 단순화했고, 로그 복제는 리더가 항목을 순서대로 밀어 넣는 방식으로 단순화했으며, 멤버십 변경처럼 Paxos에서 여러 대안이 난립했던 영역은 joint consensus라는 하나의 표준 절차로 명세했어요. 결과적으로 논문 한 편만 읽으면 실제 구현에 필요한 규칙이 전부 나온다는 점이, 매뉴얼처럼 세부 사항을 스스로 채워야 했던 Paxos와 가장 크게 갈리는 지점입니다. (리더 선출·로그 복제의 세부 동작은 Raft 논문 리뷰에서 더 다룹니다.)
etcd는 왜 Raft를 채택했나
etcd는 애초에 Raft 알고리즘을 실제 코드로 증명하는 대표 사례로 자리잡으면서 Raft를 선택했어요. CoreOS가 etcd 이전에 만들었던 초기 분산 저장소 Doozer는 Paxos 계열 합의를 썼지만, 이후 등장한 etcd는 Raft를 채택했고 지금은 Kubernetes의 클러스터 상태 저장소로 쓰이면서 사실상 가장 널리 배포된 Raft 구현체가 됐습니다. 커뮤니티에서 반복적으로 언급되는 이유도 동일해요 — “Paxos는 프로덕션에 올리려면 결국 Multi-Paxos를 스스로 설계해야 하는데, 이게 대부분의 사람에게 이해하기 어렵다”는 겁니다. 명세가 명확한 알고리즘일수록 버그를 잡고 리뷰하기도 쉬워서, 오픈소스로 여러 사람이 함께 유지보수해야 하는 프로젝트에는 특히 유리하게 작용했습니다.
Consul과 CockroachDB는 어떤 이유로 Raft를 골랐나
HashiCorp은 Consul의 합의 계층을 Raft로 구축하면서 “이해가능성을 위해 시작된 알고리즘”이라는 점을 채택 이유로 명시적으로 들었어요. Paxos는 복잡도가 사용 사례에 따라 계속 커지고 참고할 수 있는 자료도 제각각인 반면, Raft는 프로덕션급 분산 시스템을 구축하는 경로 자체를 논문이 안내해준다는 설명입니다. Consul처럼 서비스 디스커버리와 헬스체크까지 함께 운영해야 하는 시스템 입장에서는, 합의 계층의 동작을 팀 전체가 정확히 예측할 수 있다는 점이 안정성으로 직결돼요.
CockroachDB는 여기서 한 단계 더 나아가 Raft 구현체 자체를 etcd 팀과 협업하며 가져다 썼습니다. 클린한 추상화로 설계된 etcd의 Raft 라이브러리가 자신들의 요구사항에 맞게 확장하기 쉬웠다는 게 CockroachDB 측 설명이에요. 다만 CockroachDB는 데이터를 지리적으로 분산된 수많은 Range로 쪼개 저장하기 때문에, 노드 한 대가 수만~수십만 개의 Raft 합의 그룹에 동시에 참여해야 하는 문제가 생겼고, 이를 해결하려고 MultiRaft라는 별도 계층을 그 위에 얹었습니다. 강한 리더 구조가 준 이해가능성은 그대로 가져가되, 그 리더가 리전 하나에 묶여 병목이 되는 단점은 CockroachDB 스스로 추가 엔지니어링으로 보완한 셈입니다.
홈랩 관점에서는 이 선택이 왜 중요한가
홈랩을 운영하는 입장에서 두 알고리즘의 철학 차이는 실제로 쓰는 소프트웨어의 안정성과 직결돼요. Docker Compose로 홈랩 스택을 구성할 때 etcd나 Consul 같은 합의 기반 서비스를 올리는 경우가 있는데, 이런 컴포넌트가 내부적으로 Raft를 쓴다는 걸 알면 “리더가 다운되면 몇 초 안에 새 리더가 뽑히고, 그동안은 쓰기가 잠깐 멈춘다”는 동작을 예측할 수 있습니다. 반대로 Paxos 계열 시스템은 구현마다 세부 동작이 달라서 장애 시나리오를 일반화하기가 더 어려워요. Portainer로 여러 컨테이너를 관리하는 홈랩 환경에서도, 클러스터형 서비스를 붙일 때 이 합의 알고리즘의 특성을 미리 알아두면 노드 하나가 재시작될 때 왜 잠깐 응답이 지연되는지를 로그만 보고도 짐작할 수 있습니다.
결론
Raft 논문이 내세운 목표는 처음부터 끝까지 이해가능성 하나였고, 강한 리더로 결정권을 단일화하고, 리더 선출·로그 복제·멤버십 변경을 각각 하나의 명확한 절차로 명세한 것이 그 목표를 달성한 구체적인 방법이었습니다. Paxos가 원 논문에서 로그 복제용 Multi-Paxos를 구체적으로 규정하지 않아 구현자마다 다른 답을 냈던 것과 정반대로, Raft는 논문 하나만으로 실제 구현이 가능하도록 설계됐고, 그 결과 etcd·Consul·CockroachDB 같은 핵심 오픈소스 인프라가 약속이라도 한 듯 Raft로 수렴했습니다. 처음 질문으로 돌아가면, etcd·Consul·CockroachDB가 Paxos 대신 Raft를 택한 이유는 결국 성능이 아니라 “여러 사람이 함께 정확히 구현하고 검증할 수 있는가”라는, 오픈소스 생태계에 가장 중요한 기준에서 Raft가 확실히 앞섰기 때문이었습니다.
자주 묻는 질문
Q1. Raft와 Paxos 중 어느 쪽이 더 성능이 좋은가요?
성능 자체는 거의 차이가 없어요. Raft 논문도 '결과적으로 (Multi-)Paxos와 동등한 결과를 만들어내고, Paxos만큼 효율적'이라고 명시하고 있고, Raft가 이긴 지점은 속도가 아니라 이해가능성과 구현 난이도예요.
Q2. Paxos는 왜 어렵다는 평가를 받나요?
원조 논문인 The Part-Time Parliament(1989년 작성, 1998년 발표)가 그리스 의회를 비유로 설명하는 방식이라 읽기 어려웠고, Lamport 본인이 이를 풀어 쓴 Paxos Made Simple(2001)조차 프로토콜 하나로 결정을 내리는 Single-decree Paxos만 다뤄서, 실제 서비스에 필요한 로그 복제용 Multi-Paxos는 논문에 명세되지 않은 채 구현자마다 서로 다른 방식으로 채워 넣어야 했어요.
Q3. etcd는 처음부터 Raft를 썼나요?
아니요, etcd 이전에 CoreOS가 만든 Doozer 같은 초기 분산 키-값 저장소는 Paxos 계열 합의를 썼고, etcd는 2013년 이후 Raft를 채택하면서 사실상 Raft 알고리즘의 대표적인 오픈소스 구현체이자 데모 사례가 됐어요.
Q4. Raft의 '강한 리더' 방식은 단점은 없나요?
네, 모든 쓰기가 리더 한 대로 몰리기 때문에 리더가 병목이 될 수 있고, 리더가 지리적으로 멀리 떨어진 리전에 있으면 그 리전까지의 왕복 지연이 전체 쓰기 지연에 그대로 반영돼요. CockroachDB 같은 지리 분산 데이터베이스가 리전마다 수만 개의 Raft 그룹을 운영하는 MultiRaft 구조를 별도로 만든 것도 이 특성 때문이에요.
Q5. Raft를 배우면 Paxos는 몰라도 되나요?
실무에서 Raft 기반 시스템만 다룬다면 Paxos의 세부 구현까지 알 필요는 없지만, Google Spanner나 Chubby, Neon 같은 시스템은 여전히 Paxos 계열을 쓰고 있어서 분산 시스템을 폭넓게 이해하려면 두 알고리즘이 같은 문제(복제된 로그의 합의)를 어떤 다른 철학으로 풀었는지 비교해보는 게 도움이 돼요.
Q6. Raft 알고리즘 자체의 동작 방식은 어디서 볼 수 있나요?
리더 선출, 로그 복제, 안전성 보장 같은 Raft 자체의 상세 메커니즘은 별도로 정리한 [Raft 논문 리뷰](/blog/raft-consensus-algorithm-paper)에서 다루고 있어요.
관련 글
