클라우드플레어는 도메인의 DNS를 맡기면 CDN, SSL 인증서, DDoS 방어까지 무료 플랜에서 쓸 수 있는 서비스입니다. 다만 모든 레코드에 프록시(주황 구름)를 켜는 게 정답은 아니고, Vercel 같은 호스팅 앞에서는 오히려 꺼 두는 편이 공식 권장입니다. 이 글의 요금·한도는 2026년 10월 12일 Cloudflare·Vercel 공식 문서에서 확인한 값이며, 엠제이커넥트도 mjconnect.kr 도메인의 DNS를 이곳에서 관리하고 있습니다.
클라우드플레어 무료 플랜에는 무엇이 들어 있나요?
공식 요금 페이지 기준으로 Free 플랜은 월 $0입니다. 여기에 들어 있는 기능은 아래와 같습니다.
| 기능 | Free 플랜에서 | 메모 |
|---|---|---|
| DNS | 포함 | 도메인의 네임서버를 클라우드플레어로 옮겨 관리 |
| CDN | 포함 | 프록시(주황 구름)를 켠 레코드에만 적용 |
| SSL 인증서 | Universal SSL 포함 | 방문자와 클라우드플레어 사이 HTTPS |
| DDoS 방어 | Unmetered(사용량 제한 없음) | 역시 프록시를 켠 트래픽 대상 |
| 방화벽(WAF) | Free Managed Ruleset 포함 | 세부 규칙은 유료 플랜이 더 많음 |
| 규칙 | 70개 + 대량 리디렉션 1만 개 | 리디렉션·헤더 같은 규칙 |
유료로 올라가면 Pro가 연간 결제 시 월 $20(월간 결제 $25), Business가 연간 결제 시 월 $200(월간 결제 $250)입니다. 개인 블로그나 소규모 서비스라면 Free로 시작해서 부족한 기능이 생겼을 때 올리는 순서가 돈이 덜 듭니다.
Workers와 Pages는 무료로 어디까지 쓸 수 있나요?
DNS·CDN과 별개로, 코드를 올려 돌리는 개발자 기능(Workers·Pages)도 있습니다. 무료 한도는 개발자 문서에 이렇게 나와 있습니다.
- Workers: 하루 10만 요청, 호출당 CPU 시간 10ms. 넘으면 유료 플랜(계정당 월 $5부터, 월 1,000만 요청 포함)이 필요합니다.
- Pages: 월 500회 빌드, 동시 빌드 1개, 사이트당 파일 2만 개, 파일 하나 25MiB, 프로젝트당 커스텀 도메인 100개.
정적 사이트나 가벼운 API라면 무료 한도로 충분한 경우가 많습니다. 반대로 요청이 하루 10만 건을 넘는 서비스라면 처음부터 유료 플랜 비용을 계산에 넣어 두는 게 맞습니다. 클라우드 비용을 줄이는 다른 방법은 클라우드·크레딧 글 모음에서 이어서 볼 수 있습니다.
주황 구름과 회색 구름은 무엇이 다른가요?
DNS 레코드마다 Proxy status를 고를 수 있고, 이 선택이 클라우드플레어를 쓰는 방식을 정합니다.
프록시(Proxied, 주황 구름)
방문자 요청이 Cloudflare 네트워크를 거쳐 서버로 갑니다. 그래서 캐시, DDoS 방어, 방화벽이 동작하고 서버의 실제 IP가 가려집니다. 공식 문서에 따르면 프록시는 A, AAAA, CNAME 레코드에만 켤 수 있습니다.
DNS only(회색 구름)
DNS는 서버의 실제 주소만 알려 주고, 트래픽은 서버로 바로 갑니다. 캐시와 방어는 서버나 호스팅 업체가 맡습니다. 공식 문서는 웹 트래픽 레코드를 DNS only로 두면 원본 IP가 누구에게나 보인다는 점을 경고하고, MX·TXT 같은 메일·인증 레코드는 항상 DNS only라고 설명합니다.
Vercel 같은 호스팅 앞에서는 어떻게 설정해야 할까요?
Vercel은 지식 베이스 문서에서 클라우드플레어 같은 리버스 프록시를 Vercel 앞에 두는 것을 권장하지 않는다고 밝힙니다. 이유는 세 가지입니다.
- 트래픽이 가려져 Vercel 방화벽과 위협 탐지가 제대로 동작하지 않습니다.
- 중간 단계가 하나 늘어 지연이 생기고, 캐시가 두 겹이 되어 관리가 어려워집니다.
- 봇 보호를 켠 경우, 프록시가 신호를 가려 정상 사용자를 봇으로 오인할 수 있습니다.
그래서 이 블로그(blog.mjconnect.kr)도 Cloudflare DNS에 CNAME 레코드를 DNS only(회색 구름)로 두고 Vercel에 연결합니다. DNS 관리는 한 곳으로 모으고, 트래픽 처리는 호스팅에 맡기는 구성입니다. 이 레코드는 클로드 코드에서 Cloudflare 공식 MCP 플러그인으로 추가했고, 그 연결 과정은 클로드 MCP 연결 방법에 정리했습니다. 호스팅 쪽 요금과 상업적 이용 조건은 Vercel 무료(Hobby)와 Pro 비교에 따로 적었습니다. 다른 호스팅을 쓴다면 연결 전에 그 호스팅의 Cloudflare 연동 안내를 먼저 확인하세요. 서버 구성 전반은 서버·아키텍처 글 모음에 정리하고 있습니다.
클라우드플레어를 켰더니 접속이 안 될 때는 어떻게 하나요?
가장 흔한 증상은 "리디렉션이 너무 많습니다(ERR_TOO_MANY_REDIRECTS)" 오류입니다. 공식 문서가 설명하는 원인은 다음과 같습니다.
- SSL 모드가 Flexible이면 CDN과 서버 사이가 HTTP로 연결됩니다.
- 서버가 HTTP 요청을 HTTPS로 돌려보내면, CDN은 다시 HTTP로 요청하고 요청이 끝없이 돕니다.
해결 방법은 SSL 모드를 Full 이상으로 올리거나 서버의 HTTPS 리디렉션을 빼는 것입니다. 공식 문서는 원본 서버로 가는 악의적 연결을 막기 위해 Full 또는 Full(strict) 모드를 강하게 권장합니다. 서버에 인증서가 있다면 Full(strict)부터 시도하는 순서가 안전합니다. 서버 쪽 인증서를 무료로 받는 방법은 SSL 인증서 무료 발급하는 법에 정리했습니다.
네임서버를 옮길 때는 무엇을 먼저 확인해야 하나요?
도메인을 추가하면 기존 레코드를 자동으로 읽어 오지만, 빠지는 레코드가 생길 수 있어 사람이 대조해야 합니다. 네임서버를 바꾸는 순간부터 새 레코드가 기준이 되기 때문에, 바꾸기 전에 아래 순서로 확인하면 장애를 피할 수 있습니다. 도메인을 아직 사지 않았다면 구입부터 연결까지의 순서는 가비아 도메인 구입과 연결에 정리했습니다.
- 기존 업체의 레코드를 전부 적어 둡니다. A·CNAME 같은 웹 레코드뿐 아니라 MX(메일), TXT(SPF·DKIM·도메인 소유 확인)를 빠짐없이 옮겨 적습니다.
- 새로 읽어 온 레코드와 한 줄씩 대조합니다. 메일 레코드가 하나라도 빠지면 메일 수신이 끊기고, 소유 확인 TXT가 빠지면 서치 콘솔 같은 외부 서비스 인증이 풀립니다.
- 웹 레코드의 Proxy status를 정합니다. 앞에서 본 기준대로 직접 운영하는 서버는 주황, 호스팅 연결은 회색으로 둡니다.
- 네임서버를 바꾼 뒤 실제 응답을 확인합니다. 브라우저 접속만 보지 말고 메일 발송·수신까지 한 번 시험해 보는 편이 안전합니다.
이 과정은 도메인 규모와 관계없이 같고, 레코드가 많을수록 대조에 시간이 더 듭니다.
클라우드플레어가 맞지 않는 경우는 언제인가요?
무료라고 해서 모든 사이트에 붙일 필요는 없습니다. 아래 경우에는 효과가 작거나 오히려 손해일 수 있습니다.
- 호스팅이 이미 CDN과 방어를 제공할 때: Vercel처럼 자체 CDN·방화벽이 있으면 DNS만 맡기고 프록시는 끄는 편이 공식 권장입니다. 이 경우 CDN·DDoS 기능은 쓰지 않는 셈입니다.
- 요청량이 많은 Workers 서비스: 하루 10만 요청을 넘으면 무료 한도를 벗어나므로 월 $5부터의 비용이 생깁니다.
- 네임서버를 옮기기 어려운 경우: 도메인 업체의 부가 서비스(메일 등)와 묶여 있으면 이전 과정에서 메일 레코드를 빠뜨려 장애가 날 수 있습니다. MX·TXT 레코드를 먼저 옮겨 적어 두세요.
그래서 클라우드플레어는 어떻게 시작하면 될까요?
- 도메인을 Free 플랜에 추가하고, 기존 DNS 레코드가 빠짐없이 옮겨졌는지 확인합니다(특히 메일 관련 MX·TXT).
- 직접 운영하는 서버로 가는 웹 레코드는 주황 구름, Vercel 같은 호스팅으로 가는 레코드는 회색 구름으로 둡니다.
- 주황 구름을 쓰는 서버는 SSL 모드를 Full 또는 Full(strict)로 맞춰 리디렉션 루프를 피합니다.
- Workers·Pages를 쓸 계획이면 무료 한도(하루 10만 요청, 월 500회 빌드)를 먼저 대조합니다.
서비스를 직접 만들면서 도메인·서버 구성까지 함께 맡기고 싶다면 아래에서 엠제이커넥트 개발 외주를 확인할 수 있습니다. 바이브코딩이 처음이라면 바이브코딩 뜻과 시작하는 법부터 보고, 바이브코딩으로 만든 서비스를 배포하는 이야기는 바이브코딩 글 모음에서, 이 블로그를 누가 운영하는지는 블로그 소개에서 볼 수 있습니다.
