Bunny DNS 완전 무료화, Cloudflare 대체될까 – 직접 비교

목차

• 배경 — DNS 시장이 또 흔들리는 이유
• 비교 기준 — 무엇을 보고 골랐나
• 항목별 비교
  • 가격 구조
  • GeoDNS와 라우팅
  • API와 자동화
  • 전파 속도와 안정성
  • 부가 기능
• 벤치마크 — 같은 도메인을 양쪽에 올려봤다
• 어떤 경우에 갈아탈 만한가
• 당장 해볼 만한 액션 3개

Bunny DNS는 Bunny.net이 자사 CDN 인프라 위에 얹어 운영하는 권위 응답(authoritative) 매니지드 DNS 서비스다. 한 줄로 정의하면 "Anycast 기반의 GeoDNS를 저비용으로 제공하는 매니지드 DNS"인데, 2026년 상반기에 가격 정책이 한 번 더 바뀌면서 무료 사용 범위가 크게 넓어졌다(공식 Bunny Pricing 페이지 2026-06-29 기준).

지금 운영 중인 사이드 프로젝트 도메인이 셋 있다. Cloudflare 계정 한 곳에 다 묶어뒀다가 한 도메인이 ToS 이슈로 차단되면서 같은 계정 내 다른 도메인의 응답까지 잠시 영향을 받은 적이 있다. 그 사건 이후로 DNS는 도메인 단위로 분산해두는 게 마음이 편해졌고, 후보 중 하나로 Bunny DNS가 올라왔다. 이번 글은 Cloudflare DNS와 Bunny DNS, 그리고 보조 후보였던 Route 53을 같은 잣대로 비교한 기록이다.

배경 — DNS 시장이 또 흔들리는 이유

결국, DNS는 클라우드 스택에서 가장 조용한 컴포넌트다. 평소엔 존재 자체를 잊고 살다가, 장애가 나거나 비용 청구서가 이상해질 때만 한 번씩 들여다본다. 그러다 보니 "처음 깐 거 그대로 쓰는" 영역이기도 하다.

문제는 2024~2025년을 지나면서 매니지드 DNS 시장이 다시 흔들리기 시작했다는 점이다. Cloudflare는 무료 플랜 ToS의 해석을 좁히는 흐름이 있었고(특히 영상·중계 트래픽 비중이 높은 사용자가 통보를 받는 사례가 보고된다), Route 53은 호스팅 존당 월 $0.50 + 쿼리 비용이라는 구조를 그대로 유지하고 있다. 그 사이를 Bunny가 "DNS는 그냥 무료"라는 단순한 메시지로 비집고 들어왔다.

즉, 프론트에서 백엔드로 넘어와 인프라를 본격적으로 만지기 시작하면서 한 가지 배운 게 있다. 인프라 비용은 한 줄 청구서가 아니라 누적되는 구조라는 것이다. 사이드 프로젝트 하나당 월 1달러는 우습지만, 도메인 10개가 되면 그게 곧 월 만 원이다. 프론트 시절에는 잘 안 보이던 항목이다.

비교 기준 — 무엇을 보고 골랐나

물론, 세 후보를 같은 잣대로 비교하려고 기준을 먼저 정리했다. 도메인 운영자가 실제로 신경 쓰는 항목만 추렸다.

• 가격 구조: 도메인당 / 쿼리당 비용
• GeoDNS와 라우팅: 지역별·지연 기반 응답 분기 지원 여부
• API와 자동화: Terraform/CLI 사용성, IaC 호환
• 전파 속도와 안정성: 변경 반영 시간, Anycast PoP 수
• 부가 기능: DNSSEC, DDoS, 모니터링, 즉시 무효화

한편, 가격 외 항목을 함께 보는 이유는, DNS는 한 번 옮기면 보통 1~2년은 그대로 둔다는 점 때문이다. 처음 싼 게 1년 뒤에도 싸리란 보장이 없으니, API와 부가 기능까지 같이 본다.

항목별 비교

가격 구조

"무료"라는 단어가 셋 다 들어가지만 내용이 다르다.

물론, (가격·정책 모두 공식 페이지 2026-06-29 확인 기준. 정책은 자주 바뀌므로 결정 전 재확인 권장)

이처럼, 수치만 보면 Cloudflare가 더 좋아 보이지만, GeoDNS 한 줄이 들어가는 순간 그림이 달라진다. Cloudflare에서 GeoDNS를 켜려면 Load Balancing 모듈을 활성화해야 하고, 그건 월 5달러부터 시작한다. Bunny는 동일한 기능을 무료 플랜에서 그냥 켤 수 있다. 사이드 프로젝트 한두 개 운영 비용이 그대로 GeoDNS 한 줄에 묶이는 셈이다.

반면, Route 53은 비교 후보로 올렸지만 가격 표를 보는 순간 사실상 제외됐다. AWS 다른 서비스와 묶여 있어 IAM·태그 정책이 이미 잡혀 있는 팀이 아니라면, 사이드 프로젝트 DNS만 두기엔 무겁다.

GeoDNS와 라우팅

이번 비교를 시작한 진짜 이유가 GeoDNS다. 한국·일본 사용자 비율이 6:4 정도인 프로젝트가 있는데, 일본 트래픽은 도쿄 리전 오리진으로 보내고 싶었다. 같은 코드, 같은 컨테이너지만 한일 간 RTT가 30~40ms 차이가 나니까 API 응답 체감이 다르다.

Bunny에서 GeoDNS를 켜는 건 단순하다. 레코드 하나에 "Geographic Routing"을 토글하고 국가 코드별 IP를 매핑하면 끝난다. UI상에서 10분이면 다 잡힌다.

이처럼, Cloudflare에서 같은 일을 하려면 Load Balancer Pool을 만들고 Health Check를 붙이고 Steering Policy를 Geo로 바꿔야 한다. 기능 자체는 더 강력하다. Health Check 실패 시 자동 페일오버, 가중치 기반 분배, 세션 어피니티까지 다 들어 있다. 다만 작은 프로젝트 입장에선 그 깊이가 부담이다.

특히, 규모로 갈리는 셈이다. 트래픽이 작은 사이드 프로젝트는 Bunny의 단순한 GeoDNS면 충분하고, 트래픽이 일정 규모를 넘는 순간 Cloudflare의 Health Check 기반 페일오버가 결국 필요해진다.

API와 자동화

API는 셋 다 REST를 제공하지만 Terraform 생태계 두께가 다르다.

# Bunny DNS 레코드 추가 — 간단한 형태
resource "bunnynet_dns_record" "api" {
  zone  = bunnynet_dns_zone.main.id
  name  = "api"
  type  = "A"
  value = "203.0.113.10"
  ttl   = 300  # 5분, 빠른 롤백용
}

Bunny의 Terraform Provider는 2025년 후반에야 1.0이 나왔다. 그 전까지는 커뮤니티 Provider를 써야 했고, 지금도 일부 신규 API 필드(특히 GeoDNS 세부 규칙)가 늦게 따라온다. 반대로 Cloudflare Provider는 v4 기준으로 거의 모든 기능이 매핑돼 있고, 예제도 풍부하다.

그런데, 자동화 비중이 큰 운영이라면 Cloudflare 손이 덜 간다. Bunny는 콘솔 작업이 빠른 대신 IaC 통합이 한 박자 늦다. 백엔드로 넘어온 뒤로 "콘솔에서 클릭"을 최대한 피하려는 습관이 생겼는데, Bunny는 그 습관과 한 발짝 부딪힌다.

전파 속도와 안정성

DNSPerf나 SolveDNS 같은 외부 측정 서비스의 6월 측정치를 보면 두 서비스 모두 글로벌 평균 응답 시간이 10ms대 안쪽이다(2026-06 기준). 체감상의 차이는 거의 없다.

그런데, Anycast PoP 수는 Cloudflare가 약 330개로 가장 넓다고 알려져 있고, Bunny는 자사 CDN PoP 기준 120개 안팎으로 보인다(공식 네트워크 페이지 기준). 한국에서 한국 사용자에게 응답할 때 차이를 느끼긴 어렵고, 차이가 나는 건 남미나 아프리카 같은 외곽 지역이다.

레코드 변경 후 전파는 둘 다 TTL을 따라간다. Bunny는 자사 콘솔에서 "Purge DNS Cache" 같은 즉시 무효화를 무료 플랜에서도 제공한다는 점은 의외였다. 긴 TTL을 걸어두고 운영하다가 비상시에만 짧게 무효화하는 패턴이 가능해진다.

부가 기능

DNS만 놓고 보면 Bunny가 단순하다. Cloudflare는 DNS 옆에 WAF, Bot Management, Workers, R2 같은 게 한 콘솔에 다 붙어 있어서 "DNS만 쓰러 갔다가 다른 거 켜고 나오는" 경우가 흔하다. 이게 장점이자 단점이다. 한 곳에서 다 해결되니 편하지만, 무의식적으로 잠금이 깊어진다.

DNSSEC은 셋 다 무료로 켤 수 있다. 다만 NS 변경 시 KSK 회전 시점만 잘 맞춰야 한다. Bunny는 DNSSEC 활성화 후 DS 레코드를 상위 레지스트라에 등록하는 흐름이 콘솔에 단계별로 안내되는 편이다. 처음 켜는 입장에서 친절하다.

벤치마크 — 같은 도메인을 양쪽에 올려봤다

그래서, 같은 사이드 프로젝트 도메인을 Bunny와 Cloudflare에 동시에 등록해두고, dig 명령으로 응답 시간을 며칠간 찍어봤다. NS만 바꿔가며 측정했고, 측정 위치는 서울 가정용 회선과 도쿄 VPS 두 곳이다.

(샘플 수가 적은 체감 확인용 측정이다. 1주일치 평균이며, 정밀 벤치마크는 DNSPerf 같은 전문 서비스의 수치를 참고하는 게 낫다.)

이처럼, 수치 차이가 거의 없다. 1~2ms 차이는 실제 페이지 로드에서 의미가 없다. 적어도 한국·일본 트래픽 기준으로는 둘 중 어느 쪽을 골라도 사용자가 체감하는 차이는 없다고 본다.

특히, 차이가 의미를 가지는 지점은 따로 있다. Cloudflare는 무료 플랜의 DNS 자체 SLA가 명시돼 있지 않다. Bunny는 99.99% DNS SLA를 약관에 적어둔다(서비스 약관 기준). 무료 사용자도 적용 대상이라는 점이 흥미롭다. 물론 SLA 보상이 무료 사용자에게 실제로 의미 있는 수준은 아니다. 그래도 "약속을 적어두는 쪽"과 "안 적어두는 쪽"의 운영 자세 차이는 보인다.

어떤 경우에 갈아탈 만한가

여기서부터는 객관 비교에서 벗어난 개인 판단이다.

결국, Bunny로 옮길 만한 경우

• 사이드 프로젝트나 작은 SaaS의 DNS 비용을 0원으로 만들고 싶다
• GeoDNS를 유료 플랜 없이 켜고 싶다
• Cloudflare 한 계정에 도메인이 너무 많이 묶여 있어 분산하고 싶다
• DNS 작업을 콘솔에서 빠르게 끝내는 편이 편하다

그래서, Cloudflare에 남는 게 나은 경우

• WAF, Workers, R2 등 다른 제품과 묶어 쓰고 있다
• Terraform/Pulumi 기반 IaC가 운영의 중심이다
• Health Check 기반 페일오버가 필요하다
• 글로벌 외곽(남미·아프리카) 트래픽 비중이 크다

게다가, 지금 운영 중인 도메인 셋 중 둘은 Bunny로 옮겼고, 메인 도메인 하나는 Cloudflare에 그대로 뒀다. 의사결정의 핵심은 "기능이 더 강한 쪽" vs "관리가 더 단순한 쪽"이었고, 도메인의 중요도와 트래픽 규모에 따라 갈렸다. 한 곳에 다 묶는 건 더 이상 후보가 아니었다.

따라서, 프론트에서 백엔드로 넘어오면서 깨달은 게 하나 더 있다. 인프라 선택은 "최고의 도구"를 고르는 게임이 아니라 "이 워크로드에 충분히 잘 맞는 도구"를 고르는 게임이라는 점이다. Bunny DNS가 Cloudflare를 모든 영역에서 대체하지는 못한다. 그래도 "DNS만 깔끔하게"라는 좁은 영역에서는 충분히 잘 맞는 도구다.

당장 해볼 만한 액션 3개

• 사용 중인 매니지드 DNS의 월 청구서를 한 번 들여다본다. GeoDNS, Load Balancer, Health Check가 따로 청구되고 있다면 비교 대상이다.
• Bunny에 테스트 도메인 하나만 옮겨본다. NS 변경까지 30분이면 끝난다. 영향 적은 도메인부터 시작하는 게 안전하다.
• Terraform으로 운영 중이라면, Bunny Provider 이슈 트래커를 먼저 확인한다. 누락된 필드가 운영에 영향을 줄 수 있다.

물론 Bunny의 무료 정책이 얼마나 오래 유지될지는 더 지켜봐야 한다.

관련 글

• Cloudflare OAuth 무료 공개 — Auth0·Keycloak 대체 가능한가 – Cloudflare가 OAuth Provider를 MIT 라이선스로 공개하면서 인증 인프라 선택지가 한 칸 늘었다. Auth0·Keyclo…
• Cloudflare Turnstile WebGL 핑거프린팅 강제 문제와 대안 4종 비교 – Turnstile이 WebGL 정보를 챌린지 신호로 적극 활용하면서 Tor와 프라이버시 브라우저 사용자가 가입을 못 끝낸다. 대안 3종을 …
• GPU 서버 $48K 직접 샀더니 클라우드보다 진짜 싸졌나 – $48,000짜리 온프렘 GPU 서버. AWS로 같은 워크로드 돌리면 월 $21,600이라 2.2개월이면 본전이라 생각했다. 실제로는 14…