Raft의 '다수결' 원칙, 소수 노드만으로도 합의할 수 있을까

분산 시스템의 단골 고민, '합의'

서버를 여러 대 띄워서 운영하는 분산 시스템에서 가장 어려운 문제 중 하나가 합의(consensus)예요. 쉽게 말하면 "지금 우리 서버 다섯 대 중에 진짜 마스터는 누구지?" 같은 결정을 모두가 똑같이 인정하게 만드는 거죠. 가장 유명한 알고리즘이 Raft예요. etcd, CockroachDB, TiDB, MongoDB 등 거의 모든 현대 분산 데이터베이스의 뼈대를 이루고 있어요. Raft의 핵심 규칙은 "절반보다 많은 노드가 동의해야 결정이 확정된다"는 거예요. 5대면 3대, 7대면 4대가 필요한 거죠. 그런데 padhye.org에 올라온 글은 이 다수결을 살짝 비틀어요. "소수 노드만으로도 합의를 유지할 수 있을까?"라는 질문을 던지죠.

왜 다수결이 필요했을까

Raft가 다수결을 고집하는 이유는 스플릿 브레인(split brain)을 막기 위해서예요. 네트워크가 두 갈래로 끊겼다고 상상해 보세요. 한쪽 그룹에 2대, 다른 쪽에 3대가 남았다고 칠게요. 만약 각 그룹이 자기들끼리 리더를 뽑아서 데이터를 따로 쓰기 시작하면, 나중에 다시 연결됐을 때 어느 쪽 데이터가 진짜인지 알 수 없게 돼요. 그래서 Raft는 "3대 이상 모인 쪽만 작동해라, 2대만 남은 쪽은 멈춰라"라고 규칙을 세웠어요. 안전은 챙기지만, 단점이 있어요. 5대 중 3대가 죽으면 시스템이 통째로 멈추거든요.

글에서 제안하는 아이디어

원문에서 저자는 "정말로 다수가 필요한가?"를 다시 따져 봐요. 그가 짚는 건 Raft 안에도 사실 두 가지 종류의 결정이 섞여 있다는 점이에요. 하나는 데이터를 새로 쓰는 결정이고, 다른 하나는 이전에 합의된 데이터를 그대로 읽는 결정이에요. 쓰기는 강한 합의가 꼭 필요하지만, 읽기는 사실 이전에 이미 확정된 상태를 확인만 하면 되거든요. 그래서 그는 리스(lease) 기반 읽기나 위트니스(witness) 노드 같은 개념을 활용하면, 표면적으로는 소수만 살아 있어도 시스템이 일부 기능을 유지할 수 있다고 설명해요.

또 흥미로운 건 역할 분리예요. 5대를 모두 똑같이 쓰는 대신, 데이터를 직접 가진 노드 3대와 투표만 하는 위트니스 2대로 나누는 거죠. 위트니스는 디스크 부담이 적어서 저렴한 서버에 돌릴 수 있고, 장애가 났을 때 합의 정족수만 채워 줘요. MongoDB의 아비터(arbiter), CockroachDB의 비투표 레플리카 같은 개념이 비슷한 아이디어예요.

다른 합의 알고리즘과의 비교

이 주제는 Raft만의 고민은 아니에요. Paxos에는 Flexible Paxos라는 변종이 있는데요, 쓰기 정족수와 읽기 정족수를 다르게 설정해서 가용성을 높여요. 예를 들어 5대 중 쓰기는 4대, 읽기는 2대만 동의해도 되도록 설정하면, 어느 쪽이 고장 나도 한쪽 작업은 살아남죠. 또 Viewstamped Replication 같은 옛 알고리즘이나, 최근의 EPaxos는 리더가 없는 구조로 합의를 분산시켜요. "다수결"이라는 큰 원칙은 같지만, 그 다수의 정의를 더 유연하게 다루는 흐름이 분명해요.

여기서 또 짚을 만한 게 있어요. AWS의 Aurora, Google Spanner, Azure Cosmos DB 같은 대형 분산 DB들은 데이터센터 단위로 노드를 배치하고, 지역간 지연을 줄이기 위해 합의의 모양을 변형해 쓰고 있어요. "어디까지가 진짜 다수인가"라는 질문이 학술 영역을 넘어 실서비스의 비용·가용성 문제로 직결되고 있는 거죠.

한국 개발자에게 주는 시사점

실무에서 etcd, Zookeeper, Consul을 운영해 본 분이라면 한 번쯤 "3대 중 2대가 죽었는데 왜 클러스터가 통째로 멈추지?"라는 의문을 가져봤을 거예요. 답은 "다수결 때문"이고, 그걸 우회하려면 이번 글이 다루는 위트니스나 리스 같은 기법을 알아야 해요. 직접 구현할 일은 드물어도, 클러스터 토폴로지를 설계할 때 5대 vs 7대, 위트니스 노드 추가 여부 같은 결정이 가용성에 큰 영향을 줘요. 비용을 아끼겠다고 3대만 쓰면 한 대 죽었을 때 운영이 위험해지고, 5대를 다 풀 노드로 쓰면 디스크 비용이 부담돼요. 위트니스라는 중간 선택지를 알고 있으면 설계가 훨씬 유연해져요.

쿠버네티스를 운영한다면 컨트롤 플레인의 etcd가 정확히 이 다수결 위에서 돌고 있어요. 마스터 3대 구성에서 2대를 동시에 같은 AZ에 두면, 그 AZ가 죽었을 때 클러스터 전체가 멈춰요. AZ를 분산하는 것만으로도 가용성이 크게 달라지는 이유가 여기에 있어요.

마무리

Raft의 다수결은 절대 진리가 아니라 "안전과 가용성 사이의 한 가지 타협안"이에요. 소수 노드로도 일부 기능을 유지하는 변형들이 계속 나오고 있고, 우리 시스템에 맞게 골라 쓰는 게 중요한 시대가 됐어요. 여러분의 서비스는 노드 두 대가 동시에 죽어도 살아남을 수 있나요? 한 번 클러스터 구성도를 다시 그려보면 좋을 것 같아요.