Cloudflare 역사를 알면 서비스가 보인다 DNS에서 풀스택 플랫폼까지
Cloudflare가 DNS와 CDN 회사에서 어떻게 개발자 플랫폼으로 진화했는지, 역사를 통해 Workers, Pages, D1 등 서비스의 탄생 배경을 이해합니다.
Cloudflare 15주년 타임라인 | Cloudflare 공식 블로그
2025년 11월 18일 밤, 갑자기 ChatGPT가 안 됐습니다. X(트위터)도 먹통, Canva도 접속 불가. “내 인터넷 문제인가?” 싶어서 이것저것 눌러봤지만 소용없었습니다. 알고 보니 Cloudflare 서버에 장애가 발생한 것이었습니다. 전 세계 수백만 개 웹사이트가 동시에 마비됐고, 약 3시간 만에 복구됐습니다.
이 사건을 보면서 많은 분들이 처음 알았을 겁니다. “Cloudflare가 이렇게 많은 서비스의 기반이었구나.” 그렇습니다. 우리가 매일 쓰는 서비스 상당수가 Cloudflare 위에서 돌아가고 있습니다. 그런데 정작 Cloudflare가 뭘 하는 회사인지, 왜 이렇게 다양한 서비스를 제공하는지 아는 분은 많지 않습니다.
Cloudflare의 역사를 알면 지금 제공하는 서비스들이 왜 존재하는지, 어떻게 활용해야 하는지가 명확해집니다. 이번 글에서는 Cloudflare가 어떻게 작은 보안 회사에서 글로벌 인터넷 인프라 기업으로 성장했는지, 그 과정에서 탄생한 서비스들의 배경을 풀어보겠습니다.
시작은 스팸 추적이었습니다
Cloudflare의 시작은 의외로 소박합니다. 2004년 Matthew Prince와 Lee Holloway라는 두 사람이 Project Honey Pot 이라는 프로젝트를 시작했습니다. “스팸 이메일이 도대체 어디서 오는 거지?”라는 단순한 궁금증에서 출발한 프로젝트였습니다.
이들은 웹사이트에 “덫”을 설치해서 스팸봇의 움직임을 추적했습니다. 그러다 깨달은 게 있었습니다. “우리가 이렇게 많은 악성 트래픽 데이터를 갖고 있으니, 이걸 활용해서 웹사이트를 보호해줄 수 있지 않을까?”
2009년 7월 26일, Matthew Prince, Lee Holloway, 그리고 Michelle Zatlyn이 함께 Cloudflare 를 창업했습니다. 그리고 2010년 9월 27일 TechCrunch Disrupt에서 세상에 모습을 드러냈습니다. 당시 내세운 슬로건은 “5분 만에 설정 가능한 무료 CDN”이었습니다.
CDN과 DNS의 강자로 자리잡다
Cloudflare가 처음 세상에 내놓은 서비스는 CDN(Content Delivery Network) 과 DDoS 방어 였습니다. CDN이 뭐냐고요? 쉽게 말해 웹사이트 콘텐츠를 전 세계 여러 서버에 복사해두고, 사용자와 가까운 서버에서 전달하는 서비스입니다. 한국에서 미국 서버에 있는 웹사이트를 볼 때, 한국에 있는 Cloudflare 서버에서 콘텐츠를 가져오니까 훨씬 빠른 것입니다.
DDoS 방어는 해커들이 웹사이트를 마비시키려고 엄청난 양의 트래픽을 보내는 공격을 막아주는 것입니다. Cloudflare가 중간에서 악성 트래픽을 걸러내고, 정상적인 방문자만 통과시킵니다.
2014년에는 Universal SSL 을 무료로 제공하기 시작했습니다. 웹사이트 주소가 http가 아니라 https로 시작하면 보안 연결이 적용된 건데, 예전에는 이걸 적용하려면 돈을 내야 했습니다. Cloudflare가 이걸 무료로 풀어버리면서 전 세계 웹사이트의 암호화 비율이 급격히 올라갔습니다.
2018년 4월 1일에는 1.1.1.1 이라는 DNS 서비스를 시작했습니다. DNS는 도메인 이름(예: google.com)을 실제 서버 주소(IP)로 바꿔주는 서비스인데, Cloudflare의 DNS가 가장 빠르다고 알려져 있습니다. 지금도 많은 분들이 인터넷 속도를 높이려고 DNS 설정을 1.1.1.1로 바꿔 사용합니다.
Workers의 탄생과 한계
2017년 9월, Cloudflare는 Workers 를 출시했습니다. 이건 Cloudflare 역사에서 정말 중요한 전환점이었습니다. 단순히 콘텐츠를 전달하고 보안을 제공하는 회사에서, 개발자들이 코드를 실행할 수 있는 플랫폼 으로 변신한 것입니다.
Workers의 아이디어는 이랬습니다. “Cloudflare는 전 세계 수백 개 도시에 서버를 두고 있잖아. 그 서버들에서 개발자들이 자기 코드를 돌릴 수 있게 해주면 어떨까?” 이렇게 하면 사용자와 가까운 곳에서 코드가 실행되니까 엄청나게 빠릅니다. AWS Lambda 같은 서버리스 서비스와 비슷하지만, 전 세계 엣지에서 실행된다는 점이 달랐습니다.
그런데 Workers에는 한계가 있었습니다. 정적 파일(HTML, CSS, 이미지 등)을 호스팅하는 데는 적합하지 않았습니다. Workers는 코드를 실행하는 데 특화되어 있었지, 파일을 저장하고 전달하는 용도로 만들어진 게 아니었습니다. 개발자들이 Workers로 웹사이트를 만들려고 하면 이런저런 불편함을 겪었습니다.
Cloudflare는 현명한 선택을 했습니다. 모든 것을 직접 개발하려 하기보다, 이미 잘 만들어진 외부 도구들과 쉽게 연동할 수 있도록 표준 프로토콜과 호환성 에 집중한 것입니다.
대표적인 예가 R2 입니다. Cloudflare가 오브젝트 스토리지를 만들 때, 완전히 새로운 API를 설계하지 않았습니다. 대신 AWS S3 API와 100% 호환 되도록 만들었습니다. 덕분에 기존에 S3를 쓰던 개발자들은 코드 한 줄만 바꿔도 R2로 마이그레이션할 수 있습니다. S3용으로 만들어진 수천 개의 도구와 라이브러리가 그대로 작동합니다.
데이터베이스도 마찬가지입니다. Cloudflare는 자체 데이터베이스 D1을 만들면서도, 외부 데이터베이스와의 연동을 적극 지원합니다. Neon, PlanetScale, Supabase, Turso 같은 인기 있는 서버리스 데이터베이스를 Workers에서 클릭 몇 번으로 연결할 수 있습니다. 2023년에는 Hyperdrive 라는 서비스를 출시해서, 기존에 쓰던 PostgreSQL이나 MySQL 데이터베이스를 Workers에서 빠르게 접근할 수 있게 했습니다.
더 인상적인 건 WinterCG(Web-interoperable Runtimes Community Group) 입니다. 2022년 Cloudflare는 Deno, Node.js 진영과 손잡고 W3C 산하에 이 표준화 그룹을 만들었습니다. 목표는 서버 사이드 JavaScript 런타임들이 공통된 표준 API를 사용하도록 하는 것입니다. 즉, Workers에서 작성한 코드가 Deno에서도, Node.js에서도 똑같이 돌아가게 하자는 것입니다. “우리 플랫폼에 종속시키겠다”가 아니라 “어디서든 돌아가는 코드를 쓰게 하겠다”는 발상입니다.
이런 전략 덕분에 개발자들은 Cloudflare에 올인하지 않아도 됩니다. S3를 쓰다가 R2로 옮겨도 되고, R2를 쓰다가 다시 S3로 돌아가도 됩니다. Supabase 데이터베이스를 쓰다가 D1으로 바꿔도 되고, 그 반대도 됩니다. 이 유연함이 오히려 개발자들을 Cloudflare로 끌어들이는 힘이 되었습니다.
Pages가 나온 이유
Cloudflare는 Workers를 억지로 확장하는 대신, 아예 새로운 서비스를 만들기로 결정 했습니다. 그렇게 2020년 12월에 탄생한 게 Cloudflare Pages 입니다.
Pages는 처음부터 “웹사이트 호스팅”에 집중했습니다. GitHub이나 GitLab에 코드를 올리면 자동으로 빌드해서 배포해주고, 미리보기 URL도 만들어주고, 커스텀 도메인 연결도 쉽게 해줍니다. Netlify나 Vercel 같은 서비스와 경쟁하는 포지션이었습니다.
결국 Cloudflare의 전략은 이랬습니다. Workers는 “코드 실행”에 집중하고, Pages는 “웹사이트 호스팅”에 집중한다. 각자 잘하는 일에 집중하되, 서로 연동되게 만들자. Pages에서도 서버 사이드 로직이 필요하면 Workers 기반의 Functions를 쓸 수 있게 했습니다.
그리고 결국 다시 하나로
재미있는 건 2024년 이후의 행보입니다. Cloudflare는 Workers와 Pages를 점점 통합하기 시작했습니다. 2024년 9월에는 Workers에서도 정적 자산을 무료로 호스팅할 수 있게 됐습니다. 그러니까 예전에는 Pages에서만 가능했던 일을 Workers에서도 할 수 있게 된 것입니다.
2025년 4월 공식 블로그에서 Cloudflare는 이렇게 발표했습니다. “앞으로는 Workers로 시작하세요. Pages는 계속 지원하지만, Workers가 프론트엔드, 백엔드, 데이터베이스를 모두 다루는 풀스택 플랫폼이 될 것입니다.”
결국 돌고 돌아 Workers가 진화해서 Pages의 역할까지 흡수한 셈입니다. 다만 Pages가 있었기에 정적 호스팅의 노하우가 쌓였고, 이제 그걸 Workers에 녹여넣을 수 있게 된 것입니다. 처음부터 Workers만 고집하지 않고 Pages를 따로 만든 결정이 결국 좋은 방향으로 작용했습니다.
데이터베이스와 스토리지까지 확장
Workers와 Pages로 코드 실행과 호스팅을 해결했지만, 서비스를 만들려면 데이터를 저장할 곳도 필요합니다. Cloudflare는 이 문제도 직접 해결하기로 했습니다.
2019년에 Workers KV 가 나왔습니다. 간단한 키-값 저장소로, 설정 값이나 세션 정보를 저장하기 좋습니다. 2022년에는 R2 가 출시됐습니다. AWS S3와 호환되는 오브젝트 스토리지인데, 가장 큰 차별점은 데이터 전송 비용(이그레스)이 0원 이라는 것입니다. S3를 쓰다가 요금 폭탄 맞은 경험이 있는 분들에게는 혁명적인 소식이었습니다.
2022년에는 D1 도 발표됐습니다. SQLite 기반의 서버리스 데이터베이스입니다. 회원 정보, 주문 내역 같은 관계형 데이터를 저장할 수 있습니다. Workers에서 바로 연결해서 쿼리할 수 있으니, 별도의 데이터베이스 서버를 운영할 필요가 없어졌습니다.
왜 이 역사가 중요한가
Cloudflare 서비스를 처음 접하면 당황스럽습니다. Workers도 있고 Pages도 있고, 뭘 써야 하지? D1이랑 KV랑 R2는 뭐가 다르지? 서비스가 왜 이렇게 많지?
역사를 알면 이해가 됩니다. Cloudflare는 “없던 걸 새로 만든” 게 아니라, “필요에 따라 하나씩 추가한” 것입니다.
CDN과 보안이 본업이었는데, 개발자들이 코드도 돌리고 싶어해서 Workers를 만들었습니다. 정적 사이트 호스팅이 불편해서 Pages를 만들었습니다. 데이터 저장이 필요해서 KV, R2, D1을 만들었습니다. 봇 차단이 필요해서 Turnstile을 만들었습니다. 이메일이 필요해서 Email Routing을 만들었습니다.
이런 맥락을 알면 서비스 선택이 훨씬 쉬워집니다. 정적 웹사이트만 올릴 거면 Pages(또는 Workers)면 충분합니다. 서버 로직이 필요하면 Workers를 씁니다. 데이터를 저장하려면 용도에 따라 KV(간단한 값), D1(관계형 데이터), R2(파일)를 고르면 됩니다. 클라우드플레어의 터널 서비스를 이용하면 내 노트북을 서버로 이용하고 제어를 모바일에서 할 수있는 툴을 쉽게 만들 수 있습니다.
결론
Cloudflare는 2009년 “웹사이트를 보호하자”라는 작은 아이디어에서 시작해서, 2026년 현재 “웹 서비스를 만드는 데 필요한 모든 것”을 제공하는 플랫폼이 됐습니다. DNS, CDN, DDoS 방어라는 본업에서 시작해 Workers, Pages, D1, R2, KV, Turnstile, Email Routing, Access까지 확장했습니다.
2025년 11월 장애 사태가 보여줬듯이, Cloudflare에 의존하는 서비스가 그만큼 많아졌다는 뜻이기도 합니다. ChatGPT, X, Discord, Canva 등 수많은 서비스가 Cloudflare 위에서 돌아갑니다. 그만큼 신뢰할 수 있는 인프라라는 반증이기도 합니다.
1인기업을 준비하는 분들이라면, Cloudflare 하나만 잘 알아도 인프라 걱정의 90%는 해결됩니다. 역사를 알면 서비스가 보이고, 서비스를 알면 내 프로젝트에 어떻게 적용할지가 보입니다.
#Cloudflare #CDN #DNS #Workers #Pages #인터넷인프라 #서버리스 #개발자플랫폼