왜 2017년에 만든 논문 리스트가 아직도 읽히는 걸까요
분산 시스템 엔지니어 니콜라에 바르톨로메이(Nicolae Vartolomei)가 2017년에 정리한 "Distributed Systems Classics"라는 읽기 목록이 있어요. 만든 지 10년이 다 되어가는 이 목록이 요즘 다시 개발자들 사이에서 회자되고 있는데요, 좀 신기하죠. 프론트엔드 프레임워크는 2년만 지나도 옛날 얘기인데, 여기 실린 논문들은 1978년, 1985년에 나온 것들이거든요. 이유는 단순해요. 도구는 바뀌지만 문제는 안 바뀌기 때문이에요. 컴퓨터 여러 대를 묶어서 하나처럼 동작하게 만들 때 생기는 어려움은 40년 전이나 지금이나 똑같아요. 네트워크는 끊기고, 서버는 죽고, 각 서버의 시계는 미묘하게 다르게 흘러요. 이 세 가지 사실에서 골치 아픈 문제가 전부 파생되는데, 고전 논문들은 바로 그 문제들의 정체를 처음으로 정확하게 밝혀낸 글들이에요.
분산 시스템이 뭐길래 이렇게 어렵냐면
이게 뭐냐면, 서버 한 대로 감당이 안 되니까 여러 대에 일을 나눠 맡기는 건데요. 문제는 그 순간부터 "지금 상태가 정확히 뭐지?"에 답하기 어려워진다는 거예요. 서버 A가 B한테 메시지를 보냈는데 답이 안 와요. B가 죽은 걸까요, 네트워크가 느린 걸까요, 아니면 B는 잘 처리했는데 답장만 유실된 걸까요? 이 셋을 구분할 방법이 없어요. 카톡을 보냈는데 1이 안 사라지는 상황이랑 똑같아요. 폰이 꺼졌는지, 지하철이라 안 터지는지, 읽씹인지 알 수가 없죠. 고전 논문들은 이런 상황에서 "그래도 확실히 알 수 있는 건 뭔가", "무엇은 아무리 노력해도 불가능한가"를 수학적으로 정리해놨어요.
이런 리스트에서 빠지지 않는 논문들
램포트의 "Time, Clocks, and the Ordering of Events" (1978). 분산 시스템의 출발점으로 불리는 논문이에요. 서버마다 시계가 다르니까 "몇 시에 일어났나"로 순서를 정하는 건 포기하고, "A가 B에게 메시지를 보냈다면 A의 송신은 B의 수신보다 먼저다"처럼 인과관계로만 순서를 정하자는 아이디어예요. 이걸 논리적 시계(logical clock)라고 부르는데, 데이터베이스 복제나 이벤트 소싱이 전부 이 위에 서 있어요.
FLP 불가능성 정리 (1985). 내용이 좀 충격적이에요. "메시지가 언제 도착할지 보장이 없는 시스템에서는, 서버 단 한 대만 죽을 수 있어도 모두가 하나의 값에 합의하는 걸 100% 보장하는 알고리즘은 존재하지 않는다." 그럼 우리가 쓰는 시스템들은 어떻게 돌아가냐고요? "5초 동안 답 없으면 죽은 걸로 치자" 같은 타임아웃이라는 현실적 타협을 쓰는 거예요. 이걸 읽으면 왜 분산 시스템 설정마다 타임아웃 값이 그렇게 많은지 이해가 돼요.
팍소스(Paxos)와 래프트(Raft). "현실적으로 충분히 잘 되는" 합의 알고리즘들이에요. 램포트의 팍소스가 원조인데 워낙 난해해서 "Paxos Made Simple"이라는 해설판까지 나왔고, 그래도 어려워서 2014년에 스탠퍼드 팀이 이해하기 쉬운 걸 목표로 래프트를 만들었죠. 리더를 뽑고, 리더가 로그를 복제하고, 과반수가 확인하면 확정하는 구조예요. 쿠버네티스가 상태를 저장하는 etcd, 하시코프 Consul, 카프카가 주키퍼를 떼어내고 도입한 KRaft가 전부 래프트 구현이에요.
다이나모(Dynamo, 2007). 아마존 장바구니용 저장소 논문인데, 앞의 논문들과 정반대 철학이에요. "합의를 기다리다 고객이 장바구니에 물건을 못 담으면 그게 더 손해다. 일단 쓰게 하고 나중에 맞추자." 이게 최종 일관성(eventual consistency)이에요. 데이터를 어느 서버에 둘지 정하는 일관된 해싱, 충돌을 감지하는 벡터 클록, 서버끼리 소문내듯 상태를 퍼뜨리는 가십 프로토콜이 여기서 대중화됐고, 카산드라가 이 논문의 직계 후손이에요.
구글 3부작: GFS, MapReduce, Bigtable. 싸구려 서버 수천 대를 묶어서 세상에서 제일 큰 데이터를 처리하는 법을 보여준 논문들이고, 오픈소스 진영이 이걸 따라 만든 게 하둡이에요. 이후의 스패너(Spanner, 2012)는 GPS와 원자시계를 데이터센터에 넣어서 램포트가 포기했던 "물리적 시간으로 순서 정하기"를 되살린 논문인데, CockroachDB나 TiDB가 이 설계를 따라가요. 이 밖에 분산 스냅샷을 정의한 챈디-램포트 알고리즘(플링크 체크포인트의 원리예요), "네트워크는 신뢰할 수 있다" 같은 8가지 착각을 정리한 "분산 컴퓨팅의 오류들"도 단골이에요.
지금 업계에서 이 논문들의 위치
재미있는 건, 요즘 새 시스템들도 결국 이 고전들 중 어느 쪽을 택하느냐로 귀결된다는 거예요. 강한 일관성이 필요하면 래프트 계열(etcd, CockroachDB), 가용성이 우선이면 다이나모 계열(카산드라, DynamoDB), 대용량 순차 처리면 GFS 계열(HDFS, 카프카). 새 데이터베이스 소개 글을 읽을 때 "이건 스패너 방식이네", "이건 다이나모 계열이구나" 하고 분류할 수 있으면, 문서를 다 읽기 전에 장단점을 대략 예측할 수 있어요. 그게 고전을 읽는 실질적 이득이에요.
한국 개발자에게 이게 왜 필요한가
솔직히 주니어 때는 이런 논문 안 읽어도 일하는 데 지장 없어요. 프레임워크가 다 해주니까요. 그런데 서비스가 커지고 "왜 이 데이터가 가끔 옛날 값으로 보이지?", "왜 리더 선출이 자꾸 일어나지?" 같은 문제를 마주하는 순간, 읽은 사람과 안 읽은 사람의 해결 속도가 확 갈려요. 백엔드 면접에서 나오는 "카프카 파티션 리더가 죽으면 어떻게 되나요" 같은 질문도, 래프트 한 편 읽어두면 어떤 시스템이든 같은 원리로 설명할 수 있고요.
읽는 요령을 드리자면, 처음부터 끝까지 읽으려 하지 마세요. 초록, 서론, 그림만 먼저 보고 결론을 읽은 다음 본문으로 돌아가는 게 훨씬 덜 지쳐요. 순서는 램포트의 시계 논문, 래프트, 다이나모 세 편으로 시작하는 걸 추천해요. 이 셋이면 나머지를 읽을 때 필요한 어휘가 거의 다 갖춰지거든요. 논문이 부담스러우면 마틴 클레프만의 "데이터 중심 애플리케이션 설계(DDIA)"가 이 논문들을 한 권으로 풀어놓은 책이니 그걸 먼저 보는 것도 좋아요.
정리하면
분산 시스템의 도구는 계속 바뀌지만, 그 도구들이 풀려는 문제는 1978년에 이미 정의됐고, 이해하는 가장 빠른 길은 여전히 원전 논문이에요. 여러분은 분산 시스템 개념을 주로 어디서 배우셨나요? 논문으로 시작하는 게 나은지, 실제 장애를 겪고 나서 논문을 찾아 읽는 게 나은지, 경험담이 궁금해요.
🔗 출처: Hacker News