Cloudflare Workers KV vs D1: 1인 개발자 사이드프로젝트 실제 비용과 한계 비교

월 $0으로 사이드프로젝트를 굴리다가, 어느 날 갑자기 요금 고지서를 받는 경험. 생각보다 많은 개발자들이 겪어요.

Cloudflare Workers 생태계는 1인 개발자에게 정말 매력적인 선택지예요. Free 플랜만으로도 꽤 많은 걸 할 수 있거든요. 그런데 KV와 D1, 이 두 가지 스토리지 옵션 중 뭘 골라야 할지 애매한 순간이 반드시 찾아와요. “그냥 KV 쓰면 안 되나?” 싶다가도, D1이 SQL을 지원한다는 걸 알고 나면 또 흔들리고요.

2026년 지금, 데이터 기반으로 둘을 비교해 봤어요. 어떤 선택이 내 프로젝트에 맞는지, 찬찬히 봐요.

핵심 요약

• Cloudflare Workers Free 플랜 기준, KV는 하루 10만 읽기 요청, D1은 하루 500만 행 읽기를 무료로 제공해 읽기 집약적 워크로드라면 D1이 압도적으로 유리하다.
• KV는 키-값 구조 특성상 복잡한 쿼리 없이 단순 조회가 주인 캐싱, 세션 저장, 설정 데이터에 최적이며, D1은 관계형 데이터가 필요한 CRUD 앱에 더 적합하다.
• Workers Free 플랜의 하루 10만 요청 한도는 트래픽 스파이크 한 번에 쉽게 넘어갈 수 있어, 유료 전환 시점을 미리 계산해두는 게 필수다.
• 1인 개발자 사이드프로젝트 관점에서 D1은 2026년 현재 GA(정식 출시) 상태로, 프로덕션 사용에 충분한 안정성을 갖추고 있다.

이 비교가 지금 필요한 이유

Cloudflare Workers는 엣지 컴퓨팅 플랫폼으로 시작했어요. 서버 없이 전 세계 300여 개 데이터센터에서 코드를 실행하는 개념이죠. AWS Lambda와 자주 비교되는데, Workers는 V8 격리(isolate) 기반이라 콜드 스타트가 사실상 없어요. 이 점 하나만으로도 1인 개발자한테 꽤 매력적이에요.

문제는 스토리지예요. 코드는 Workers에서 실행되는데, 데이터는 어디에 저장하냐는 거죠. Cloudflare는 이 용도로 두 가지를 내놨어요.

• KV (Workers KV): 2018년 출시된 글로벌 분산 키-값 스토어. 결과적 일관성(eventual consistency) 방식이에요.
• D1: 2023년 오픈 베타를 거쳐 2024년 GA된 서버리스 SQLite 데이터베이스. SQL을 그대로 쓸 수 있어요.

D1이 정식 서비스로 자리를 잡으면서, 1인 개발자들 사이에서 “이제 뭘 써야 해?“라는 질문이 다시 뜨거워졌어요. 특히 사이드프로젝트에서는 무료 한도가 얼마나 되느냐가 기술 선택의 핵심이 되는 경우가 많죠.

실제 비용 구조: 숫자로 보는 차이

Free 플랜 한도 비교

Cloudflare 공식 문서 기준으로 정리하면 이렇게 돼요.

숫자를 보면 바로 보여요. D1의 읽기 한도가 KV보다 50배 많아요. 단순 요청 수로만 보면 D1이 압도적이에요.

그런데 여기서 짚어둘 게 있어요. Workers 자체의 하루 10만 요청 한도는 KV와 D1이 공유해요. 스토리지 한도가 넉넉해도, Workers 요청이 먼저 바닥날 수 있다는 뜻이에요.

KV 읽기가 실제로 얼마나 빨리 소진되나

간단한 계산을 해볼게요. 사이드프로젝트에서 사용자가 페이지를 열 때마다 KV에서 세션 데이터를 읽는다고 가정해요.

• DAU(일 방문자) 1,000명
• 1인당 평균 5페이지 뷰
• 페이지당 KV 읽기 2회

→ 하루 읽기 요청 = 1,000 × 5 × 2 = 10,000회

이 정도면 Free 한도(10만 회)의 10%밖에 안 써요. 여유롭죠.

그런데 트래픽이 갑자기 열 배 뛰면? 하루에 한도를 꽉 채워요. 해커뉴스나 Product Hunt에 링크가 뜨는 순간 그렇게 되는 거예요. D1이었다면 같은 상황에서 500만 행 한도가 있으니 훨씬 여유로워요.

어떤 프로젝트에 어떤 걸 써야 할까

KV가 맞는 경우

KV는 구조가 단순해요. 키 하나로 값 하나를 꺼내는 방식이죠. 이 단순함이 강점이 되는 상황이 있어요.

• 엣지 캐싱: 자주 바뀌지 않는 설정값이나 정적 데이터를 전 세계 엣지에 캐싱할 때. 결과적 일관성이 문제 안 되는 상황이에요.
• 세션 토큰 저장: 토큰을 키로, 사용자 정보를 값으로 저장하는 패턴. 조회가 단순하고 빨라요.
• 기능 플래그(Feature Flags): A/B 테스트나 기능 토글 값을 저장할 때. 변경이 몇 분 후에 반영돼도 괜찮은 경우죠.

KV의 진짜 약점은 쓰기예요. Free 플랜에서 하루 1,000회 쓰기 한도는 생각보다 빨리 차요. 사용자가 프로필을 수정할 때마다 KV에 쓴다면, 1,000명이 하루에 한 번씩만 수정해도 한도가 꽉 차거든요.

D1이 맞는 경우

D1은 SQLite를 서버리스로 쓰는 개념이에요. 관계형 데이터가 필요하다면 D1이 답이에요.

• 유저-콘텐츠 관계: 게시글, 댓글, 좋아요 같은 관계형 데이터. JOIN 쿼리를 자유롭게 쓸 수 있어요.
• CRUD 기반 앱: 할 일 관리, 북마크, 링크 단축 서비스 같은 일반적인 웹 앱.
• 데이터 분석이 필요한 경우: GROUP BY, COUNT, SUM 같은 집계가 필요할 때. KV로는 아예 불가능해요.

D1의 한계는 현재 단일 리전(single primary)이에요. 멀티 리전 쓰기는 아직 제한적이에요. 읽기는 빠른데, 쓰기 레이턴시가 지역에 따라 차이가 날 수 있어요.

1인 개발자 관점에서 실용적인 결론

상황 1 - 처음 사이드프로젝트 시작할 때

데이터 구조가 관계형이면 D1부터 시작하세요. 이유는 단순해요. Free 플랜 한도가 넉넉하고, SQL을 그대로 쓰면 되니까 러닝 커브가 없어요. ORM(예: Drizzle ORM)과 붙이면 익숙한 방식 그대로 개발할 수 있어요.

상황 2 - 트래픽이 올라서 유료 전환을 고려할 때

KV: 읽기 백만 건당 $0.50, 쓰기 백만 건당 $5.00 D1: 읽기 백만 행당 $0.001, 쓰기 백만 행당 $1.00

쓰기 대비 읽기가 압도적으로 많은 패턴이라면, D1의 과금 단가가 훨씬 저렴해요. 월 트래픽이 늘어날수록 이 차이가 커지는 구조예요.

상황 3 - 두 개를 같이 쓸 때

실제로 많은 프로젝트에서 KV와 D1을 함께 써요. D1에 본 데이터를 저장하고, KV로 자주 읽는 데이터를 캐싱하는 패턴이에요. 이렇게 하면 D1 읽기 부하를 줄이면서, KV의 글로벌 엣지 캐싱 이점을 동시에 가져갈 수 있어요. Workers 위에서 두 서비스를 바인딩하는 건 설정 몇 줄이면 되거든요.

앞으로 주시할 것들:

• D1 멀티 리전 쓰기 지원: Cloudflare가 로드맵에 올려둔 기능이에요. 출시되면 글로벌 유저를 대상으로 한 앱에서 D1의 강점이 더 커져요.
• Workers Free 플랜 한도 변경: Cloudflare는 종종 플랜 한도를 조정해요. 2025년에도 한 차례 상향 조정이 있었던 만큼, 공식 문서를 주기적으로 확인하는 습관이 필요해요.

정리: 선택 기준은 데이터 구조와 쓰기 빈도

한 줄로 요약하면 이래요.

단순 조회가 많고 구조가 평평하면 → KV. 관계형 데이터와 SQL이 필요하면 → D1.

비용 면에서는 Free 플랜 한도가 D1이 압도적이에요. 특히 읽기 집약적 앱에서는요. 유료 전환 후에도 D1의 읽기 단가가 KV보다 훨씬 낮아요. 그래서 새 프로젝트를 시작한다면, 특별히 KV가 필요한 이유가 없다면 D1부터 시도해 보는 게 합리적이에요.

그리고 프로젝트가 커지면, 어차피 두 개를 같이 쓰게 되는 날이 와요. 지금 어떤 선택을 하더라도, Cloudflare Workers 생태계 안에서는 나중에 바꾸거나 합치는 게 어렵지 않아요. 그게 이 플랫폼의 진짜 장점이거든요.

당신 프로젝트의 데이터 모델은 어떤 형태인가요? 거기서 출발하면 선택이 꽤 명확해질 거예요.

본 분석은 Cloudflare 공식 개발자 문서(developers.cloudflare.com/workers/platform/pricing/)의 2026년 5월 기준 Free 및 Paid 플랜 스펙을 참고했어요.

참고자료

1. Pricing · Cloudflare Workers docs
2. 클라우드플레어 워커(cloudflare workers)와 AWS 람다(AWS Lambda) 비교 | marinesnow34

Photo by NASA on Unsplash