영화 '퀸카로 살아남는 법'으로 배우는 Raft 합의 알고리즘

분산 시스템의 핵심 문제, 쉽게 이해하기

분산 시스템을 공부하다 보면 반드시 만나는 개념이 있어요. 바로 합의 알고리즘(Consensus Algorithm)이에요. 이게 뭐냐면, 여러 대의 서버가 네트워크로 연결되어 있을 때 "이 데이터의 현재 상태가 뭔지" 서로 합의하는 방법을 말해요. 한 대의 서버만 있으면 그 서버가 가진 데이터가 곧 진실이지만, 여러 대가 있으면 "누구 말이 맞아?"라는 문제가 생기거든요.

CockroachDB를 만든 Cockroach Labs에서 이 Raft 합의 알고리즘을 영화 'Mean Girls(퀸카로 살아남는 법)'에 비유해서 설명한 글이 있는데요, 이 비유가 정말 절묘해서 이해하기가 훨씬 쉬워요.

Raft가 뭔데? 그리고 왜 필요한데?

분산 데이터베이스나 분산 시스템에서는 데이터를 여러 서버에 복제해두는데요, 이렇게 하면 한 서버가 죽어도 다른 서버에서 데이터를 제공할 수 있어요. 문제는 데이터를 수정할 때예요. 5대의 서버에 같은 데이터가 있는데, 클라이언트가 "값을 A에서 B로 바꿔줘"라고 요청하면, 5대 모두 동의하고 동시에 바뀌어야 하잖아요. 이걸 조율하는 게 합의 알고리즘이에요.

Raft 이전에는 Paxos라는 알고리즘이 있었는데, 이게 악명 높을 정도로 이해하기 어려웠어요. 논문을 읽어도 무슨 말인지 모르겠다는 얘기가 학계에서도 나올 정도였거든요. 그래서 2014년에 Diego Ongaro와 John Ousterhout이 "이해하기 쉬운 합의 알고리즘"을 목표로 Raft를 만들었어요.

Mean Girls로 이해하는 Raft의 핵심

영화에서 학교에는 여러 그룹이 있고, 각 그룹에는 리더가 있잖아요. Raft도 마찬가지예요. 서버(노드)들의 클러스터에서 리더를 한 명 뽑고, 그 리더가 모든 결정을 내리는 구조예요.

리더 선출(Leader Election) — 영화에서 레지나 조지가 퀸카 자리에서 밀려나면 새로운 퀸카가 등장하듯이, Raft에서도 리더가 응답을 안 하면(서버가 죽으면) 나머지 서버들이 투표를 해서 새 리더를 뽑아요. 각 서버는 타임아웃을 갖고 있는데, 리더한테 일정 시간 동안 연락이 없으면 "나를 새 리더로 뽑아달라"고 다른 서버들에게 투표를 요청해요. 과반수 이상의 표를 받으면 새 리더가 되는 거예요.

로그 복제(Log Replication) — 리더가 결정되면, 모든 변경 사항은 리더를 통해서만 들어와요. 리더가 "이 데이터를 이렇게 바꾸겠다"는 명령을 로그에 기록하고, 팔로워(다른 서버)들에게 보내요. 팔로워 과반수가 "받았어, 기록했어"라고 응답하면 그제서야 확정(commit)이 되는 거예요. 영화에서 레지나가 "수요일에는 핑크색 옷을 입어"라고 하면 다른 멤버들이 따르는 것처럼요.

임기(Term) — Raft에는 임기라는 개념이 있어요. 리더가 바뀔 때마다 임기 번호가 하나씩 올라가요. 이건 시간을 논리적으로 나누는 역할을 하는데, 네트워크가 분리됐다가 다시 합쳐질 때 "더 높은 임기의 리더가 진짜 리더"라고 판단하는 기준이 돼요.

실제로 Raft는 어디에서 쓰이나요?

생각보다 엄청 많은 곳에서 쓰이고 있어요. CockroachDB는 물론이고, etcd(쿠버네티스의 핵심 저장소), Consul(서비스 디스커버리), TiKV(TiDB의 스토리지 엔진) 같은 프로젝트들이 Raft 기반이에요. 즉, 여러분이 쿠버네티스를 쓰고 있다면 이미 간접적으로 Raft를 사용하고 있는 셈이에요.

비교 대상으로는 Paxos 외에도 최근에 주목받는 것들이 있어요. Viewstamped Replication이나, Raft를 개선한 Multi-Raft(하나의 클러스터에서 여러 Raft 그룹을 운영), 그리고 최근에는 EPaxos나 Flexible Paxos 같은 변형들도 연구되고 있어요. 하지만 Raft가 여전히 가장 널리 쓰이는 이유는 단순해요 — 이해하기 쉬우니까 구현도 정확하게 할 수 있고, 디버깅도 쉽거든요.

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

분산 시스템을 직접 설계할 일이 없더라도 Raft를 이해하면 좋은 이유가 있어요. 요즘 마이크로서비스 아키텍처나 쿠버네티스 기반 인프라를 다루는 분들이 많은데, 이런 시스템의 근간이 되는 원리를 알면 장애 상황에서 훨씬 빠르게 문제를 파악할 수 있어요. "etcd 클러스터에서 노드 하나가 죽었는데 왜 전체가 느려지지?"같은 질문에 답할 수 있게 되는 거예요.

또한 기술 면접에서도 분산 시스템의 합의 문제는 자주 나오는 주제예요. 특히 네이버, 카카오, 라인 같은 대규모 서비스 회사나, 쿠팡 같은 이커머스 백엔드 면접에서 CAP 정리, 합의 알고리즘, 리더 선출 같은 개념을 물어보거든요.

정리하자면

Raft는 "분산 시스템에서 여러 서버가 하나의 진실에 합의하는 방법"이에요. 리더 선출, 로그 복제, 임기라는 세 가지 핵심 개념만 잡으면 전체 그림이 보여요. Mean Girls 비유가 잘 와닿았다면, 원문도 한번 읽어보시는 걸 추천해요.

혹시 Raft나 분산 합의 알고리즘을 실무에서 직접 다뤄본 경험이 있으신가요? 장애 상황에서 리더 선출이 어떻게 동작하는지 체감한 적이 있다면 공유해주세요!