대규모 시스템 최적화: 100TB RAM 뒤에 숨은 수학과 역설

저는 기술 블로그에서 클라우드플레어의 놀라운 최적화 사례를 접했습니다. 수천 대의 서버와 페타바이트급 RAM을 운영하는 거대 기업에서 단 100TB의 RAM을 절약했다는 기사는 언뜻 보기에 대단치 않아 보일 수 있습니다. 하지만 이는 단순히 숫자의 문제가 아닙니다. 무한해 보이는 자원 속에서도 효율을 향한 집념이 시스템의 본질을 어떻게 변화시키는지 보여주는 이야기입니다.

우리 중 대부분은 클라우드플레어처럼 거대한 인프라를 직접 관리할 일은 없을 겁니다. 그러나 우리가 매일 작성하는 코드 한 줄, 설계하는 업무 프로세스, 심지어 개인의 자원 관리 방식에서도 작은 비효율이 규모에 따라 증폭되는 현상은 흔하게 목격됩니다. 이 리포트는 클라우드플레어의 사례를 통해, 어떻게 시스템의 숨겨진 낭비를 발견하고 역설적인 해결책으로 본질적인 효율을 이끌어냈는지 탐구합니다.

스케일이 비효율을 증폭시키는 방식

클라우드플레어는 전 세계에 분산된 수많은 서버를 통해 인터넷 트래픽의 상당 부분을 처리합니다. 이들은 방대한 자원을 보유하고 있지만, 모든 서비스가 모든 노드에서 최대치로 돌아가야 하는 상황에서는 단 1%의 비효율도 막대한 손실로 이어집니다. 원문은 "At this scale, small improvements are greatly magnified, so even 1%-at-a-time improvements are worth celebrating"이라고 강조합니다.

이는 단순히 기술 기업만의 이야기가 아닙니다. 모든 조직은 한정된 자원(시간, 인력, 예산) 내에서 최대의 성과를 추구해야 합니다. 이때 '규모의 경제'는 긍정적인 효과만 가져오는 것이 아닙니다. 낭비 요소를 초기 단계에서 제거하지 않으면, 규모가 커질수록 그 낭비는 기하급수적으로 증폭되어 시스템 전체를 갉아먹는 원인이 됩니다. 마치 '기술 부채'처럼, 작은 미결정이 시간이 지남에 따라 막대한 비용으로 돌아오는 것과 같습니다. 이는 낭비 제거를 통한 지속 가능한 성장이라는 '린(Lean)' 원칙의 핵심을 관통합니다.

직관이 오작동하는 지점: '더 많은' 해시의 역설

클라우드플레어의 메모리 낭비는 '컨시스턴트 해싱(Consistent Hashing)'이라는 기술에서 발생했습니다. 이 기술은 수많은 서버에 작업을 균등하게 분배하기 위해 사용되는데, 서버의 추가나 제거 시 시스템 변경을 최소화하는 장점이 있습니다.

문제는 "더 많이"가 항상 "더 좋다"는 직관에서 비롯되었습니다. 서버 간 작업량을 균등하게 분배하기 위해 서버마다 해시 포인트를 늘려나가면, 이론적으로는 분포가 더 균일해질 것이라고 생각하기 쉽습니다. 실제로 초기에는 이런 접근 방식이 효과적입니다. NGINX에서는 서버당 160개의 해시를 기본으로 설정했고, 클라우드플레어도 이를 따랐습니다.

하지만 클라우드플레어 엔지니어 케빈은 수학적 분석을 통해 이 직관의 한계를 발견합니다. 해시 개수를 무작정 늘리는 것은 특정 지점 이후부터는 효율 개선에 미미한 영향을 미치며, 심지어 32비트 해시의 경우 충돌(Collision) 확률이 기하급수적으로 증가하여 오히려 예측 불가능한 오류를 유발한다는 것을 밝혀냈습니다. 이는 '생일 역설(Birthday Paradox)'처럼 우리가 직관적으로 생각하는 확률과 실제 확률이 얼마나 다른지를 보여주는 좋은 예시입니다.

이러한 역설적 상황은 행동경제학에서 말하는 '확증 편향'이나 '과잉확신 편향'과도 맞닿아 있습니다. 한번 성공했던 방식이나 익숙한 직관에 매몰되어, 변화하는 상황이나 깊은 분석의 필요성을 간과하는 경향을 보이는 것입니다. "더 많은 해시"라는 초기 성공 공식이, 특정 규모와 조건에서는 오히려 시스템을 갉아먹는 독이 될 수 있었던 것입니다.

수학과 구조가 이끄는 효율 혁신

클라우드플레어 엔지니어들은 이 문제를 해결하기 위해 두 가지 핵심적인 접근 방식을 취했습니다. 하나는 데이터 구조의 최적화였고, 다른 하나는 해시 개수를 줄이는 수학적 분석이었습니다.

첫 번째 최적화는 엔지니어 자이둔의 통찰에서 시작됩니다. 해시 값을 저장하는 Point 구조체 내에서 서버 인덱스를 가리키는 index 필드가 32비트(u32)로 선언되어 있었는데, 실제 필요한 서버 개수(최대 6만 5천여 개)를 고려하면 16비트(u16)로 충분하다는 것을 발견합니다. 하지만 단순히 u32를 u16으로 바꾸는 것만으로는 Rust 언어의 메모리 정렬(alignment) 규칙 때문에 메모리 절감이 일어나지 않았습니다. 자이둔은 이를 #[repr(packed)] 속성을 사용하거나 바이트 배열로 직접 처리하는 방식으로 우회하여, 해시 관련 메모리를 무려 25% 절감하는 데 성공했습니다.

두 번째이자 더 큰 최적화는 케빈의 수학적 분석에서 나왔습니다. 그는 해시 개수와 분산 오차율(Coefficient of Variation, CVk) 간의 실제 관계를 밝혀내는 공식을 도출했습니다. 이 공식을 통해 해시 개수를 특정 수준 이상으로 늘리는 것이 의미 없다는 것을 증명했습니다. 예를 들어, 서버당 10만 개의 해시를 사용했을 때 마지막 9만 개가 오차율을 줄이는 데 기여하는 정도는 불과 0.7%에 불과했습니다. 오히려 너무 많은 해시는 해시 충돌로 인한 예측 불가능한 오류를 야기했습니다. 결국 클라우드플레어는 각 서버에 할당되는 해시 개수를 90%까지 줄이면서도 분산 효율에는 거의 영향을 주지 않는 최적점을 찾아냈습니다.

이 두 가지 접근 방식은 문제 해결의 본질을 보여줍니다. 즉, 표면적인 문제(메모리 부족) 뒤에 숨겨진 구조적 비효율(데이터 타입, 메모리 정렬)과 수학적 한계(알고리즘의 최적점)를 파고들어 근본적인 해결책을 찾아낸 것입니다.

파괴 없이 변화를 만드는 마이그레이션 전략

대규모 시스템에서 핵심 로직을 변경하는 것은 매우 위험합니다. 클라우드플레어는 새로운 해시 링(ring)으로 한 번에 전환할 경우, 거의 모든 캐시된 콘텐츠가 무효화되어 "기존 서버에 대한 트래픽이 종말적으로 증가"할 것이라고 예상했습니다. 이는 메모리 최적화가 오히려 시스템 마비로 이어질 수 있는 상황이었습니다.

그들은 이를 피하기 위해 점진적 마이그레이션 전략을 사용했습니다. 한동안 PBR(Pingora Backend Router)은 이전 버전의 해시 링과 새로운 해시 링을 동시에 메모리에 유지했습니다. 각 요청은 특정 마이그레이션 프레임워크를 통해 어떤 링을 사용할지 결정했습니다. 이는 요청 단위로 롤아웃 결정을 안정적으로 가져가며, 문제가 발생했을 때 신속하게 롤백할 수 있는 경로를 제공했습니다.

롤아웃은 작은 검증 지역에서 시작하여 점차 큰 데이터센터 그룹으로 확장되었고, 최종적으로 전 세계로 적용되었습니다. 이 과정에서 백엔드 선택 추적, 링 버전 카운터, 연결 오류, 프로세스 메모리, 캐시 동작, 오리진 트래픽 등 수많은 지표를 면밀히 모니터링했습니다. 이러한 통제된 배포(Controlled Deployment) 전략은 카나리 릴리즈(Canary Release)나 블루/그린 배포(Blue/Green Deployment)와 같은 현대적인 소프트웨어 배포 기법과 맥을 같이하며, 대규모 시스템 변경의 안정성을 보장하는 핵심적인 방법론입니다. 결국 이들은 시스템에 파괴적인 영향을 주지 않고 성공적으로 100TB의 RAM을 확보할 수 있었습니다.

Action Plan / Worksheet: 당신의 일에서 100TB RAM을 찾아내는 질문들

클라우드플레어의 사례는 우리 각자의 일과 시스템에 다음과 같은 질문을 던집니다.

• "당연하게 여기는 가정"에 대한 질문:

• 내가 만드는 서비스나 시스템에서 "더 많이"가 항상 "더 좋다"고 믿고 있는 부분은 무엇인가?
• 현재 사용하고 있는 데이터 구조나 변수 타입이 실제로 필요한 최소한의 리소스만 사용하고 있는가?
• 익숙한 방식이나 과거의 성공 경험 때문에, 새로운 통찰을 놓치고 있는 부분은 없는가?

• "규모의 비효율"에 대한 질문:

• 내가 담당하는 업무 프로세스나 코드에서, 현재는 작지만 규모가 커질수록 치명적인 비효율이 될 수 있는 요소는 무엇인가?
• 어떤 자원(시간, 돈, 인력)이 아무도 모르게 낭비되고 있으며, 그 낭비가 스케일에서 어떻게 증폭될 수 있는가?

• "수학적 본질"에 대한 질문:

• 나의 시스템이나 업무의 핵심 메커니즘을 숫자로 표현하고 분석할 수 있는가?
• 단순한 통계나 추측이 아니라, 실제 데이터를 기반으로 '최적점'을 찾아낸 경험이 있는가?
• 문제를 해결하기 위해 필요한 '숨겨진 수학' 또는 '알고리즘적 통찰'은 무엇인가?

• "안전한 변화"에 대한 질문:

• 핵심적인 부분을 개선할 때, '한 번에 모두'가 아닌 '점진적이고 통제된' 방식으로 변화를 도입할 수 있는가?
• 변경 사항을 적용하기 전후로 어떤 지표들을 모니터링해야 하는가? 문제가 발생했을 때 안전하게 롤백할 수 있는 계획이 있는가?

Epilogue

클라우드플레어의 100TB RAM 절약 스토리는 단순한 기술 성과를 넘어섭니다. 이는 "왜?"라는 근원적인 질문을 던지고, 직관을 의심하며, 수학과 구조의 본질을 파고드는 태도가 어떻게 거대한 문제를 해결하는 열쇠가 되는지를 보여줍니다. 우리 주변의 모든 시스템에는 눈에 보이지 않는 낭비와 비효율이 숨어있습니다. 그것을 찾아내고 개선하는 여정은 끊임없이 이어져야 할 성장 동력입니다. 수학은 보편적이며, 당신의 시스템에도 적용될 수 있습니다.

참고

• 원문: Guthrie, K., Iurchenko, M., Al Hadi, Z. A., & Babrou, I. (2026, September 18). Saving another 100TB of RAM with math (and Rust). Cloudflare Blog. Retrieved from https://blog.cloudflare.com/saving-100-tb-of-ram-with-math/
• 개념:

린(Lean) 원칙: 낭비 제거를 통한 효율 극대화 (예: The Lean Startup, Eric Ries)

행동경제학: 직관과 편향이 의사결정에 미치는 영향 (예: Thinking, Fast and Slow, Daniel Kahneman)

• 시스템 엔지니어링: 대규모 시스템 설계 및 최적화
• 점진적 배포: 시스템 변경의 안정성을 위한 전략 (카나리 릴리즈, 블루/그린 배포 등)