서론
최근 AI의 시대가 열리면서 개인이 빠른 속도로 서비스를 만들 수 있습니다. 그래서 저도 여러 서비스를 만들고 배포하는 과정에서 cloudflare를 사용했었는데요. 프리티어를 사용하면서 만족스러웠던 점과 어떤 상황에서 사용하면 좋을지 추천하려고 이 글을 작성합니다.
같이 알아볼 내용
- Workers & Pages 장단점
- KV 장단점
- D1 장단점
- cloudflare 콜드스타트 간단 체감
Workers & Pages
Workers
Workers는 Cloudflare의 엣지 네트워크에서 코드를 실행할 수 있는 서버리스 플랫폼입니다. 전 세계에 분산된 Cloudflare의 데이터센터에서 실행되기 때문에 사용자와 가장 가까운 위치에서 요청을 처리합니다. 일반적인 서버리스(AWS Lambda 등)와 다르게 V8 isolate 기반으로 동작해서 콜드 스타트가 매우 짧은 것이 특징입니다.
프리티어 스펙은 다음과 같습니다.
| 항목 | Free Tier |
|---|---|
| 일일 요청 | 100,000 / day |
| 분당 요청 | 1,000 / min |
| CPU 시간 | 10ms / 요청 |
| 메모리 | 128MB |
| Worker 개수 | 100개 |
| 스크립트 크기 | 3MB (압축 후) |
| Cron Triggers | 5개 |
개인 프로젝트나 소규모 API 서버를 운영하기에는 충분한 스펙입니다. 다만 CPU 시간이 요청당 10ms로 제한되어 있어서 무거운 연산이 필요한 작업에는 적합하지 않습니다.
참고로 여기서 말하는 CPU 타임은 네트워크 요청 같은 I/O 바운드 시간을 제외한 순수하게 CPU를 사용하는 시간이기 때문에 생각보다는 널널했습니다.
Pages
Pages는 정적 사이트 호스팅 서비스입니다. Vercel이나 Netlify와 비슷한 역할을 합니다. GitHub이나 GitLab 저장소를 연결하면 코드를 푸시할 때마다 자동으로 빌드하고 배포해 줍니다. Next.js, Astro, React 등 다양한 프레임워크를 지원합니다.
| 항목 | Free Tier |
|---|---|
| 월별 빌드 | 500회 / month |
| 빌드 타임아웃 | 20분 |
| 프로젝트당 파일 수 | 20,000개 |
| 단일 파일 크기 | 25MB |
| 프로젝트 수 | ~100개 |
| 커스텀 도메인 | 프로젝트당 100개 |
| 대역폭 | 무제한 |
대역폭이 무제한이라는 점이 큰 장점입니다. 또한 Pages에서 Functions를 사용하면 Workers와 동일한 서버리스 기능을 사용할 수 있어서 프론트엔드와 백엔드를 하나의 프로젝트로 관리할 수 있습니다.
단점
저만 그런 걸 수도 있지만 GitHub와 연동에서 자동배포를 적용하면 빌드가 밀리거나 꼬이는 경우가 간혹 발생합니다. 그래서 이 부분에서는 조금 신경을 쓰고 확인을 해야 했습니다.
월별 한도가 500회라는데 이것을 확인할 수 있는 곳이 없어서 현재 얼만큼 배포했고 이번 달에 얼마나 더 배포할 수 있는지 알 수가 없는 게 단점입니다.
물론 워커와 연동을 하면 Deployments 페이지에서 이번 달 배포만 남겨 두고 배포 횟수를 세면 되지만, 추가로 cron trigger를 사용하고 또 구축까지 손이 가기 때문에 좀 불편함이 있습니다.
KV
KV(Key-Value)는 Cloudflare에서 제공하는 전역 분산 키-값 저장소입니다. 간단하게 말하면 전 세계 엣지에서 빠르게 읽을 수 있는 저장소입니다. 설정값, 캐시 데이터, 사용자 세션 같은 읽기가 많은 데이터를 저장하기에 적합합니다.
| 항목 | Free Tier |
|---|---|
| 읽기 | 100,000 / day |
| 쓰기 | 1,000 / day |
| 삭제 | 1,000 / day |
| 리스트 요청 | 1,000 / day |
| 저장 용량 | 1GB |
읽기는 일일 10만 건으로 넉넉하지만 쓰기는 1,000건으로 제한되어 있습니다. 그래서 자주 변경되는 데이터보다는 한 번 쓰고 여러 번 읽는 데이터에 적합합니다. 또한 eventual consistency(최종 일관성) 모델이기 때문에 쓰기 후 전 세계 엣지에 반영되기까지 약간의 지연이 있을 수 있습니다.
단점
쓰기가 일일 1,000건이기 때문에 KV를 캐시로 사용하더라도 한도가 다 차면 원본 읽기를 할 수 있게 설계하는 것이 좋습니다.
D1
D1은 Cloudflare에서 제공하는 서버리스 SQL 데이터베이스입니다. SQLite를 기반으로 하고 있어서 SQL 문법에 익숙한 분이라면 바로 사용할 수 있습니다. Workers와 함께 사용하면 별도의 데이터베이스 서버 없이 풀스택 애플리케이션을 만들 수 있습니다.
| 항목 | Free Tier |
|---|---|
| 행 읽기 | 5,000,000 / day |
| 행 쓰기 | 100,000 / day |
| 저장 용량 | 5GB |
프리티어 치고는 상당히 넉넉한 스펙입니다. 일일 행 읽기가 500만 건이고 저장 용량도 5GB나 되기 때문에 개인 프로젝트에서는 부족함 없이 사용할 수 있습니다. 다만 D1은 아직 발전 중인 서비스이기 때문에 프로덕션 환경에서 사용할 때는 제한 사항을 잘 확인하는 것이 좋습니다.
장점
저는 사용하면서 만족스러웠던 기능 중에 타임 트래블 기능이 있습니다. 이 기능은 자동 백업과 특정 시점 복원 기능입니다. (프리티어는 보존 기간 7일)
바이브 코딩을 하면서 DB를 날려먹은 적이 있는데요. 이럴 때 이 기능을 통해서 쉽게 복구할 수 있었습니다.
주의할 점
이번에는 단점이라고 하기보단 주의할 점에 가깝습니다.
행 읽기가 단순히 반환하는 행의 수가 아니라 조회 과정에서 스캔한 행의 수이기 때문에 인덱스를 잘못 설계한다면 빠르게 행 읽기를 다 소진할 수 있습니다.
SQLite 기반으로 설계했기 때문에 동시성 제어가 약할 수 있습니다. 저 같은 경우에는 괜찮았지만 만약에 여러 사용자가 동시에 쓰기를 하는 경우에는 주의를 해야 할 것 같습니다.
콜드스타트 체감하기
Cloudflare의 문서를 보면 콜드스타트에 자신이 있어 보이는데요. 하지만 실사용을 해보면서 콜드스타트를 느끼는 부분이 있어서 간단하게 측정을 해봤습니다. 정밀한 벤치마크는 아니고 체감용으로 가볍게 확인해 보시면 좋을 것 같습니다.
테스트 방법
바인딩 종류별로 오버헤드가 얼마나 차이가 나는지 확인하기 위해 3개의 엔드포인트를 만들었습니다.
| 엔드포인트 | 하는 일 | 측정 대상 |
|---|---|---|
| /worker-only | JSON 바로 리턴 | 워커 초기화만 (베이스라인) |
| /kv-read | 없는 키 1개 읽기 → null | 워커 + KV 바인딩 초기화 |
| /d1-query | SELECT 1 | 워커 + D1 바인딩 초기화 |
KV는 없는 키를 읽어서 null을 반환하고, D1은 SELECT 1로 테이블을 건드리지 않기 때문에 실제 데이터 I/O 없이 순수하게 바인딩이 붙는 오버헤드만 비교할 수 있습니다.
테스트 결과
| 엔드포인트 | 콜드 스타트 (ms) | 웜 스타트 (ms) |
|---|---|---|
| worker-only | 52 | 25 |
| kv-read | 288 | 41 |
| d1-query | 671 | 74 |
워커 자체로는 괜찮지만 다른 서비스와 연동할 때에는 콜드스타트가 아주 무시할 정도는 아닌 것을 알 수 있습니다.
특히 D1의 경우 실사용에서는 데이터를 가지고 오기 때문에 콜드스타트가 1초를 넘는 경우가 빈번하게 발생했습니다.
마치며
저는 기존 서비스를 제가 쓰기 편하게 커스터마이징하기 위해 AI를 활용해 재작성했고, Cloudflare 프리티어에 배포한 뒤 wrangler CLI와 AI로 관리까지 편하게 할 수 있었습니다. AI로 누구나 자신만의 서비스를 빠르게 만들 수 있는 시대인 만큼, 배포와 운영까지 부담 없이 할 수 있는 Cloudflare 프리티어를 사용해보는게 어떨까요.
특히 블로그처럼 읽기 위주의 서비스라면 프리티어만으로도 부족함 없이 운영할 수 있기 때문에 비용 걱정 없이 시작하기 좋은 선택지라고 생각합니다.
다만 KV의 쓰기 제한, D1의 동시성 한계가 있고 KV와 D1은 Cloudflare 고유 서비스이기 때문에 벤더 종속이 생길 수 있습니다. 많은 사용자를 대상으로 한다면 Workers Paid($5/month) 전환 비용과 다른 플랫폼으로의 마이그레이션 비용을 미리 감안해 두는 것이 좋겠습니다.