Raft 멤버십 변경 중 스플릿브레인은 리더 선출 로직 자체의 결함이 아니라, 구성(configuration)이 노드마다 다른 시점에 도착하는 데서 재현된다. 구성 전파를 단일 커밋으로 밀어붙이는 구현과, old/new 구성의 과반을 모두 만족시키는 joint consensus 구현은 이 지점에서 안전성 비용이 갈린다. 2026년 기준으로도 이 둘 사이의 트레이드오프는 여전히 유효한 설계 축이다.
Raft 멤버십 변경 중 스플릿브레인은 왜 재현되는가?
결론은 "리더 선출"이 아니라 "구성 전파 시점의 불일치"가 원인이라는 것이다. 리더가 새 구성을 커밋했다고 믿는 순간과, 특정 follower가 그 구성을 실제로 본 시점 사이에 간극이 생기면, 그 간극에서 서로 다른 정당성을 주장하는 두 리더가 만들어질 수 있다.
- 스플릿브레인은 리더 선출 알고리즘의 버그가 아니라 구성 전파 지연의 산물이다
- 두 번의 멤버십 변경이 연속으로 암묵적 커밋되면 특정 follower가 "double-lagging configuration"을 들고 잘못된 선거에서 이길 수 있다
- joint consensus, quorum 강제, learner(nonvoter) 단계 도입은 모두 이 간극을 좁히거나 없애려는 장치다
- 안전장치를 강하게 걸수록 quorum을 잃었을 때 재구성 자체가 멈추는 비용이 따른다
두 선택지는 뚜렷하다. 하나는 구성 변경을 하나의 로그 엔트리로 빠르게 밀어넣고 결과를 나중에 정리하는 방식이고, 다른 하나는 전환 중간에 옛 구성과 새 구성의 과반을 동시에 만족시키도록 강제하는 방식이다. 전자는 전환이 빠르지만 중간 상태를 노출하고, 후자는 중간 상태를 봉쇄하지만 그만큼 전환 절차가 늘어난다.
암묵적 커밋 하나가 이중 지연 구성을 만드는 이유는?
원인은 "커밋"의 가시성 범위가 노드마다 다르다는 점이다. tbg의 분석에 따르면 멤버십 변경이 암묵적 커밋 상태로 일부 follower에만 보일 때, 두 번째 변경이 그 위에 겹쳐지면 특정 follower가 옛 구성과 새 구성 사이에 낀 채로 남는다. 이 노드가 다음 선거에서 이기면, 다른 노드들이 이미 인식한 구성과 다른 구성을 근거로 리더 행세를 하게 된다 출처: tbg gist. 데이터 로그의 지연은 재시도로 흡수되지만, 구성 로그의 지연은 "누가 투표권자인가"를 흔들기 때문에 같은 방식으로 흡수되지 않는다.
joint consensus가 분기를 막는 방식은 무엇이 다른가?
joint consensus는 전환 과도기 동안 옛 구성과 새 구성 둘 다의 과반을 요구해 어느 한쪽만으로는 결정을 내리지 못하게 만든다. Cockroach Labs의 설명대로, 이 방식은 과도기 자체를 없애는 게 아니라 과도기에서 "혼자 결정할 수 있는 다수"가 존재하지 않도록 만드는 쪽에 가깝다 출처: Cockroach Labs. DSN 2025의 ReCraft 연구도 분리·병합·멤버십 변경을 하나의 자가완결 절차로 묶어야 한다는 점을 근거로 삼는데, 이는 구성 전환을 별개의 임시 처리로 두면 안전성 증명이 깨진다는 뜻이다 출처: DSN 2025 ReCraft.
quorum 강제와 가용성은 어떻게 맞바꿔지는가?
quorum을 강제하면 안전성은 오르지만 진행이 멈출 수 있는 조건이 늘어난다. etcd는 멤버십 변경 자체를 quorum 기반 합의로만 반영해 split brain inconsistency를 원천적으로 피하며, 3노드 중 1노드가 죽어도 quorum 2가 유지돼 전진할 수 있다고 설명한다 출처: etcd FAQ. 반면 strict-reconfig-check는 quorum loss를 유발할 수 있는 재구성 요청 자체를 거부하는데, 이는 가용성보다 안전성을 우선한 선택이다. 대표적으로 2대씩 갈라진 분할에서는 어느 쪽도 quorum 3을 확보하지 못해 진행이 통째로 멈춘다 출처: etcd learner 설계.
| 항목 | quorum 강제형 (etcd, joint consensus) | 암묵적 커밋형 (단일 단계 전환) |
|---|---|---|
| 대표 사례 | etcd strict-reconfig-check, Cockroach joint consensus | 단순 단일 커밋 방식, 이중 지연 구성 재현 사례 |
| 스플릿브레인 방지 방식 | 과도기에 old/new 과반 동시 요구 | 전환을 빠르게 끝내는 데 의존 |
| 실패 시 동작 | 재구성 자체를 거부하거나 진행 정지 | 잘못된 리더 선출로 이어질 여지 남음 |
| 비용 | quorum 손실 시 가용성 정지 | 구성 불일치 노출 가능성 |
joint consensus로 옮기면 실제로 무엇이 추가되는가?
전환 비용은 "한 번의 커밋"을 "두 단계 전환"으로 늘리는 데서 나온다. Async Raft 문서는 change_membership 호출 후 재구성이 끝날 때까지 같은 재구성을 다시 호출할 수 없고, 이 과정이 보통은 빠르게 끝난다고 설명한다 출처: Async Raft. 즉 갈아탈 때 실제로 드는 것은 지연 그 자체가 아니라, "전환 완료를 명시적으로 기다리는" 상태 관리 로직이다. HashiCorp Raft가 voter로 바로 올리지 않고 nonvoter로 먼저 따라잡게 하는 것도 같은 맥락으로, 전환 시간을 늘려 잘못된 선거 가능성을 줄이는 대가를 지불한다 출처: HashiCorp Raft membership.
어느 쪽을 기본값으로 둬야 하는가?
정답은 클러스터 규모와 재구성 빈도에 달려 있다. 노드 수가 작고 재구성이 자주 일어나는 환경에서는 암묵적 커밋형이 이중 지연 구성을 만들 확률이 높아지므로 quorum 강제형이 필요하다. 반대로 재구성이 드물고 노드 수가 충분해 quorum 손실 위험이 낮다면, 전환 단계를 줄여 지연을 줄이는 선택도 근거가 있다. 어느 쪽도 "항상 맞는 기본값"은 아니며, 판단 기준은 재구성 빈도와 quorum 여유분이다.
핵심 정리
- 스플릿브레인은 리더 선출이 아니라 구성 전파 시점의 불일치에서 재현된다
- 암묵적 커밋이 연속되면 특정 follower가 이중 지연 구성을 들고 잘못된 선거에서 이길 수 있다
- joint consensus와 etcd의 quorum 강제(
strict-reconfig-check)는 안전성을 사서 가용성 정지 위험을 지불하는 구조다 - 전환 비용은 지연이 아니라 "전환 완료를 명시적으로 기다리는" 상태 관리 로직에 있다
- 기본값 선택은 재구성 빈도와 quorum 여유분을 기준으로 판단해야 한다
더 알아보기
분산 일관성과 합의: 시스템 설계의 기본 축 — 이 주제의 종합 가이드