요약
클라우드플레어가 DNS 설정이 바뀔 때 필요한 부분만 다시 빌드하게 바꿔 지연은 절반, 메모리는 85% 줄였습니다.
클라우드플레어가 자사 블로그에 DNS 변경을 엣지 서버로 전파하는 파이프라인의 개편 결과를 공개했습니다. 예전에는 존(zone, 한 도메인에 딸린 DNS 레코드 묶음) 설정 하나만 바뀌어도 레코드가 수천만 개인 존까지 통째로 다시 만들었습니다.
왜 중요한가
- 전체 재빌드는 존 전체를 메모리에 올려야 해서, 가장 큰 존은 아예 메모리에 들어가지 않을 만큼 한계에 닿아 있었습니다.
- 작은 빌드의 결과가 전체 빌드와 바이트 단위로 같다고 증명하지 못하면 전체 빌드로 돌아갑니다. 작업을 줄이면서도 틀린 DNS 데이터가 퍼지는 일을 막는 원칙입니다.
- 가장 느린 변경이 반영되기까지 걸리던 시간이 크게 줄어, 고객의 DNS 변경이 더 빨리 전 세계에 적용됩니다.
핵심 내용
- 플래너(빌드 범위를 정하는 부품)가 변경마다 다섯 가지 빌드 가운데 안전한 가장 작은 것을 고릅니다.
- 하루 빌드의 92.95%가 전체 재빌드를 피했고, 전체 빌드 비중은 11.88%에서 7.04%로 약 40% 줄었습니다.
- 최대 메모리는 79GiB에서 12GiB로, 빌드 완료 지연 중앙값은 약 7.7초에서 3.3초로 줄었습니다.
- 가장 느린 1%(p99) 지연의 최대치는 14.6분에서 1.21분으로 줄었습니다.
- 운영 데이터를 그대로 받는 별도 미러 환경에서 두 방식의 결과를 비교하며 무료 존부터 차례로 배포했습니다.
HN 반응
- 메모리 값이 오른 지금 최적화가 다시 중요해질지 묻는 댓글에, 클라우드플레어 전 CTO는 회사가 원래 최적화를 중시해 왔다고 답했습니다.
- 클라우드플레어 기술 블로그를 칭찬하는 댓글이 많았지만, 일부 이용자는 이 글의 문체가 LLM이 쓴 것 같다고 지적했습니다.
메모리가 귀해지면 소프트웨어를 더 효율적으로 최적화하려는 움직임이 생기지 않을까 궁금했습니다.
메모리 사용량을 줄이는 R&D와 효율화 개발의 투자 대비 효과(ROI)가 어느 정도인지 알고 싶습니다. 지금의 ROI와 가까운 미래의 ROI를 모두 따져 봐야 할 것 같습니다(메모리 가격은 적어도 1~2년은 더 높게 유지될 가능성이 크니까요).
Cloudflare는 예전부터 최적화 문화가 꽤 강했습니다. 블로그를 거슬러 올라가 보면 소프트웨어로 CPU, 지연 시간, RAM 등을 줄인 글이 많이 있습니다. 이것은 Cloudflare가 성공한 핵심 요인 중 하나이고, 오늘날 시장에서 살아남는 데에도 중요한 부분입니다.
출처: 제가 Cloudflare의 CTO였습니다.
Cloudflare 기술 블로그를 즐겨 읽고, 당신과 회사에 대해서도 꽤 잘 알고 있습니다.
저는 공동 창업자 두 분과 이전 회사에서 함께 일했고, 초기 프로토타입 일부는 당시 제 아파트에서 작성되기도 했습니다.
게다가 Cloudflare는 (Google처럼) 광고로 사용자 시선을 팔아서가 아니라 인프라 마진으로 돈을 법니다. 그러니 이런 기조를 계속 이어 갈 인센티브가 잘 맞아떨어지죠.
왜 CTO 자리에서 물러나셨는지 궁금했는데, 이사회 합류를 축하드립니다(벌써 18개월이 조금 넘은 것 같네요).
저는 당신이 누구인지 전혀 모르지만, HN에서 Cloudflare 내부 사정을 기술적으로나 정치적으로나 꽤 솔직하게 공개해 주셔서 고맙게 생각합니다.
오랫동안 CTO를 맡아 왔고, 이사회 역할이면 매일 출근하지 않으면서도 계속 관여할 수 있어서 CTO에서 물러나기로 했습니다. 제 "은퇴"에 대해서는 여기에 썼습니다: https://blog.cloudflare.com/three-chapters-at-cloudflare-programmer-to-cto-to-board-of-directors/
공교롭게도 이번 주말에 64GB RAM을 단 제 맥이 최적화가 엉망인 애플리케이션들 때문에 메모리 부족(OOM)이 나서 화가 났습니다. 문제를 일으킨 앱 거의 전부가 웹 기술, 특히 Electron을 쓰고 있었어요. Electron 자체의 문제인지 그냥 코딩을 못 한 건지는 모르겠지만, 어쨌든 패턴이 보입니다.
Electron은 사라져야 해요.
그런데 편하긴 하죠. 그래서 쓰는 사람들을 탓하기도 어렵네요.
저는 Electron의 가장 큰 결함이 단지 웹 기술이라 비효율적이라는 점만이 아니라, 앱끼리 인스턴스를 공유할 방법이 아예 없다는 점이라고 생각합니다. 모든 앱이 각자 번들로 넣은 Chromium+Node의 정확히 그 복사본만 쓰도록 강제하고, 다른 앱과 상관없이 따로 실행되게 하니까요. 이건 Electron을 없애고 다른 걸로 갈아탈 필요까지 없이, 다른 비슷한 도구들이 이미 오래전에 도입한 선택 기능 하나만 있으면 되는 문제입니다.
특정 앱에서는 정확한 버전 고정이 진짜로 필요할 때도 있을 거고, 그게 가치가 있는 경우도 있겠죠. 하지만 지금 제가 돌리는 Electron 앱 중 적어도 절반은, 기본 동작으로 같은 LTS 버전 Chromium+Node 인스턴스를 공유할 수 있었다면 기꺼이 그렇게 썼을 거라고 봅니다.
"시스템 웹뷰면 충분하잖아"라는 접근이 바로 Tauri가 존재하는 이유입니다.
윈도 시절에는 VB6 앱에 Internet Explorer를 ActiveX 컨트롤로 넣어서 연동할 수 있었습니다. 물론 아주 초보적인 수준이었지만요.
Electron이 어느 정도 공통 표준처럼 자리 잡았으니, 주요 OS 업체들이 모여서 이 아이디어를 되살려야 하지 않을까요? 예를 들어 Java JRE처럼 OS가 브라우저와 JS 인터프리터라는 기본 런타임을 제공하고, 파일 시스템 접근, 로우 네트워킹, 알림 같은 로컬 기능을 쓰기 위한 정해진 헬퍼 API 세트를 함께 주는 겁니다. 앱은 그 런타임을 호출하기만 하면 되고요.
최신 윈도는 이미 정확히 그걸 제공합니다. 기본은 항상 최신 버전을 따라가되 번들로 포함하는 선택지도 있는 WebView2입니다. https://developer.microsoft.com/en-us/microsoft-edge/webview2?form=MA13LH&cs=2334358009
하지만 맥과 리눅스 지원 계획은 접었기 때문에 Electron 대체재로는 쓸모가 좀 떨어집니다. 애초에 Electron을 그대로 바꿔 끼울 수 있는 것도 아니었어요. 웹 기반이긴 해도 추가 API 세트가 다르니까요. 이미 앱들이 Electron으로 만들어져 있고, 절약의 이득이 개발자가 아니라 사용자에게 돌아가는 상황이라 다른 쪽으로 빠르게 옮겨 가지는 않을 겁니다. 실행 방식만 다를 뿐 Electron과 100% 호환되는 것이어야 합니다.
맞아요, 일종의 웹 OS 같은 거죠.
그게 바로 2000년대 후반에 Palm이 만들었던 겁니다. Amiga처럼 너무 일찍 나왔고, 수준 낮고 비싼 하드웨어(그리고 HP의 잘못된 인수)에 발목이 잡혔죠.
그건 Electron이 Chrome으로 하는 일과 크게 다르지 않아요. Chrome을 system32에서 불러오는 대신 자체 복사본을 포함한다는 차이뿐입니다.
ActiveX 같은 공통 프레임워크가 사라진 건 아쉬운 일입니다. 지금은 뭔가를 임베드하려면 그것마다 제각각의 방식으로 해야 하니까요.
제가 웹 개발자로 일하는 동안 IE6도 Flash도 퇴출시켰습니다. 언젠가는 Electron의 고통도 가라앉겠지만 오래 걸릴 수 있습니다.
그 관에 못이라도 기부하고 싶은 심정입니다. 하지만 가치를 만드는 데 필요한 최소한의 산출물을 생각하면, 플랫폼마다 따로 앱을 만드는 건 너무 힘들죠.
공통 뷰/컨트롤러 언어를 여러 플랫폼용 실행 파일로 트랜스파일할 수 있는 날이 오기를 꿈꿉니다... 그것도 형편없지 않게요.
이건 꼼꼼히 감독하는 LLM을 쓰기에 적당한 일일 겁니다.
"앤디가 주는 것을 빌이 빼앗아 간다"
제가 계속 생각했던 게 바로 이 핵심입니다. 데스크톱과 노트북의 메모리가 정체기에 들어서면, 이런 비효율적인 프로그램 중 일부가 최적화되기 시작할까요?
claude-code는 메모리를 수상할 정도로 많이 쓰는데, 다른 도구들만큼 최적화에 신경 쓰는 것 같지도 않아요.
Claude Code 소스가 유출됐는데 완전 쓰레기 코드예요. 자기들 코드를 들여다보지도 않는다고요.
이제 가장 뜨거운 최적화 KPI는 확보한 메모리 TB 수입니다.
Cloudflare는 전반적으로 훌륭한 기술 블로그 글을 꾸준히 내놓는데도 충분히 인정받지 못하는 것 같아요.
게다가 정말 사람이 손질한 콘텐츠처럼 읽히기도 하고요.
저는 이 부분에서 LLM 탐지기가 울리기 시작했어요.
이 점을 염두에 두고 글의 앞부분을 다시 읽어 보니, LLM이 쓴 글이라고 꽤 확신합니다.
그렇긴 해도 잘 다듬은 글인 건 맞아요. 냄새나는 표현을 빼면 내용 자체는 밀도도 높고 흥미롭습니다. Cloudflare의 LLM 생성 글이 전부 이만큼 좋은 건 아니지만, 이 글은 꽤 괜찮은 편이에요.
그게 뭘 측정하는 건가요?
어떤 점에서요?
언어학이 관찰을 정량화하지 못한다 해도(예: 텍스트에서 특정 단어가 쓰인 비율), 적어도 정성적인 관찰은 내놓습니다(예: 현대 소설은 문장이 더 짧고 묘사가 적다). 여기서 하려는 말이 뭔가요? 자기는 속지 않는 사람이니 모두 자기 말을 귀담아들으라는 건가요?
Cloudflare에서 일하면 어떤가요?
가끔 개가 라바 램프 앞을 지나가면 몇 분 동안 모두의 비밀 키가 0이 되곤 합니다.
적어도 4는 아니잖아요.
초당 변경 700건이면 규모나 관리하는 도메인 수를 생각하면 좀... 너무 적은 거 아닌가요?
도메인은 전체 약 3억 6천만 개(Verisign 기준 3월 31일 현재, 비활성 사이트 포함)이고 Cloudflare가 그중 1/3에서 1/2 정도를 관리한다면, 많아야 1억 8천만 개 도메인입니다.
초당 700건이면 한 달에 18억 건입니다. 도메인당 월 10건이면 상당히 적은 편이라 롱테일 분포가 아주 길다는 뜻일 텐데, 대부분의 웹사이트는 사업체가 한 번 만들어 두고 DNS 변경은 몇 년에 한 번 있을까 말까 한 정적 페이지이니 납득이 됩니다.