Cloudflare Workers KV vs R2 단순 캐싱 레이턴시 비교: 1인 개발자 실전 선택 기준

KV는 빠르다. R2는 싸다. 그런데 막상 캐싱에 쓰면 어느 쪽이 더 나을까요?

1인 개발자로 Cloudflare Workers 쓰다 보면 이 고민 한 번씩은 해보게 돼요. 두 제품 다 캐싱 레이어로 쓰는 팀이 늘었는데, 설계 철학 자체가 달라서 잘못 고르면 월 청구서가 두 배로 나오거나 응답 속도가 생각보다 느려서 낭패 보기 딱 좋아요.

이 글에서 다루는 내용은 이렇게요:

• KV와 R2의 실제 레이턴시 차이 (공식 스펙 + 실사용 패턴 기반)
• 비용 구조 비교 (무료 티어부터 유료 전환 기준점까지)
• 단순 캐싱에 각각 어울리는 시나리오
• 1인 개발자가 당장 적용할 수 있는 선택 기준

핵심 요약

• Cloudflare Workers KV는 읽기에 특화된 엣지 분산 스토리지로, 전 세계 300개 이상 PoP에서 캐시 히트 시 1ms 미만 응답이 가능하다.
• R2는 S3 호환 오브젝트 스토리지로, Workers에서 접근 시 중앙 리전 왕복이 발생해 단순 캐싱 목적에서는 KV 대비 레이턴시가 10~50ms 더 높을 수 있다.
• KV 무료 티어는 하루 읽기 10만 건, R2 무료 티어는 월 스토리지 10GB + Class A 작업 100만 건으로, 캐싱 워크로드 특성에 따라 비용 구조가 역전된다.
• 단순 캐싱이라면 데이터 크기 25MB 미만에 읽기 빈도가 높으면 KV, 이미지나 파일처럼 크고 쓰기가 자주 없으면 R2가 맞는 선택이다.

Workers KV와 R2, 뿌리부터 다른 두 제품

Workers KV는 2018년 출시됐어요. 엣지에서 key-value 쌍을 읽는 속도를 극한으로 줄이는 게 목표였죠. 구조 자체가 읽기에 집중되어 있어요. 쓰기는 글로벌 복제에 최대 60초가 걸릴 수 있고, 값의 최대 크기는 25MB로 제한돼 있어요. 대신 캐시 히트가 나면 사용자와 가장 가까운 PoP에서 바로 응답하기 때문에 레이턴시가 극도로 낮아요.

R2는 2022년에 등장했어요. AWS S3를 정조준한 오브젝트 스토리지인데, 가장 큰 차별점은 이그레스(egress) 비용이 없다는 거였어요. S3는 데이터를 꺼낼 때마다 GB당 요금을 냈지만 R2는 출금 비용이 없어요. 덕분에 파일 저장, 미디어 서빙, 백업 용도로 빠르게 자리 잡았죠.

문제는 캐싱이에요. R2는 엣지에 분산된 게 아니라 특정 리전에 데이터가 있어요. Workers에서 R2에 접근하면 네트워크 홉이 추가로 발생해요. Cloudflare 공식 문서에 따르면 Workers와 R2 간 접근은 내부 네트워크를 타긴 하지만, KV처럼 엣지 PoP 로컬에서 처리되지는 않아요.

실제로 KV 공식 문서(developers.cloudflare.com/kv)는 캐시 히트 기준 레이턴시를 “single-digit milliseconds"로 명시하고 있어요. R2 공식 문서에는 구체적인 레이턴시 수치가 없고, 성능보다 일관성과 내구성을 강조해요. 이 차이 자체가 두 제품의 설계 의도를 그대로 드러내는 거예요.

레이턴시, 비용, 제한: 숫자로 보는 차이

레이턴시: 캐시 히트 vs 미스, 그리고 데이터 크기

KV는 캐시 히트가 나면 정말 빨라요. 엣지 PoP에 데이터가 있으면 1ms 미만도 나와요. 그런데 미스가 나면 얘기가 달라져요. 중앙 스토리지에서 데이터를 가져오면서 레이턴시가 50~100ms 수준으로 올라갈 수 있어요.

R2는 env.MY_BUCKET.get(key) 형태로 매 요청마다 리전 내 스토리지를 직접 조회하는 구조라, KV 히트처럼 극단적으로 빠르진 않아요. 하지만 KV 미스처럼 예측 불가한 레이턴시 스파이크도 덜해요. 평균 10~50ms 정도를 예상하면 돼요.

요약하면 이렇게 돼요:

비용 구조: 어느 쪽이 더 싸질까

KV는 읽기 요청 단가가 낮고, R2는 스토리지 자체가 저렴해요(월 $0.015/GB). 비용이 역전되는 지점은 대략 이렇게 돼요.

• KV가 유리한 경우: 데이터 크기 작고(수 KB~수백 KB), 읽기가 하루 수십만 건 이상
• R2가 유리한 경우: 데이터 크기 크고(수 MB 이상), 쓰기 빈도가 낮지 않은 경우

1인 개발자가 가장 많이 빠지는 함정은 KV의 쓰기 비용이에요. 무료 티어 쓰기가 하루 1,000건밖에 안 돼요. 캐시를 자주 갱신하는 구조라면 금방 유료 구간으로 넘어가요. 주의하세요.

1인 개발자 실전: 어떤 상황에 뭘 써야 하나

시나리오 A: API 응답 캐싱 (소형 JSON)

사용자 프로필, 상품 목록, 설정값 같은 소형 JSON 데이터를 캐싱하는 경우예요. 데이터 크기가 수 KB 이하고 읽기 빈도가 높다면 KV가 맞아요. 캐시 히트율만 높게 유지할 수 있다면 전 세계 어디서든 1ms 미만 응답이 나와요.

단, KV의 최종 일관성(eventual consistency)은 꼭 인지해야 해요. 데이터를 업데이트해도 최대 60초간 구버전이 응답될 수 있거든요. 자주 바뀌는 실시간 데이터엔 적합하지 않아요.

시나리오 B: 이미지/파일 캐싱 (대형 바이너리)

썸네일, PDF, 정적 에셋처럼 수십 MB짜리 파일 캐싱이라면 R2가 맞아요. KV는 25MB 제한이 있어서 아예 못 쓰는 경우가 생겨요. R2에 파일 올리고 Cloudflare Cache와 함께 쓰면 엣지 캐싱 효과도 어느 정도 볼 수 있어요.

시나리오 C: 하이브리드 접근

실전에서 가장 좋은 패턴은 KV + R2 조합이에요. 메타데이터(URL, 만료 시간, 해시값)는 KV에, 실제 파일은 R2에 저장해요. Workers에서 KV로 먼저 메타데이터를 확인하고, 필요할 때만 R2에서 파일을 꺼내는 구조죠. 이 패턴은 실제 프로덕션 코드에서도 자주 쓰여요.

지금 당장 선택해야 한다면

세 가지만 기억하면 돼요.

• 데이터가 25MB 미만이고, 하루 10만 건 이상 읽힌다면 → KV
• 데이터가 크거나 쓰기가 잦다면 → R2
• 레이턴시 일관성이 더 중요하다면 → R2 (KV 미스 스파이크 없음)

참고로 2026년 하반기에 Cloudflare가 R2의 엣지 캐싱 레이어를 강화한다는 로드맵이 있어요. 실현되면 두 제품의 레이턴시 격차가 좁아질 거예요. 그때까지는 위 기준이 유효해요.

결국 가장 먼저 확인해야 할 건 하나예요. 캐싱에 쓰는 데이터 크기가 얼마나 되나요? 그게 KV냐 R2냐의 답을 거의 결정하거든요.

참고자료

1. Storage (R2 and KV) | chrishutchinson/claude-receipts | DeepWiki
2. Cloudflare Workers KV · Cloudflare Workers KV docs
3. Cloudflare KV Reviews, Pricing & Alternatives (2026)

Photo by Robynne O on Unsplash