Shallow Think

Cloudflare 완전 정복: 무엇이고, 왜 쓰고, 어떻게 활용하는가

2026년 1월 6일 오전 1:35

Cloudflare는 단순히 “CDN 회사”가 아니라, 전 세계 엣지(Edge) 네트워크를 기반으로
웹사이트/서비스의 성능(빠르게), 보안(안전하게), **가용성(끊기지 않게)**을 통합적으로 제공하는 플랫폼이다.

이 글은 다음 질문에 답한다.

  • Cloudflare는 무엇인가?
  • 기업/서비스는 Cloudflare를 왜 쓰는가?
  • Cloudflare를 어떻게 쓰는가? (실전 흐름)
  • 어떤 장점/주의점이 있고, 어떻게 활용하면 좋은가?

1) Cloudflare는 “엣지 네트워크 기반의 인터넷 인프라 플랫폼”이다

핵심 개념: 엣지(Edge)와 리버스 프록시(Reverse Proxy)

대부분의 Cloudflare 기능은 이 한 문장으로 설명된다.

“사용자와 내 서버 사이에 Cloudflare가 들어가서(리버스 프록시),
트래픽을 엣지에서 처리/보호/최적화한다.”

즉, 사용자는 내 원 서버(origin)가 아니라 Cloudflare 엣지와 먼저 통신하고,
Cloudflare는 필요한 경우에만 원 서버로 요청을 전달한다.

Cloudflare가 앞단에 서면 생기는 변화

  • 캐싱: 자주 요청되는 콘텐츠를 엣지에 저장 → 빠른 응답
  • TLS/SSL 처리: HTTPS 연결을 Cloudflare가 처리 → 설정 단순화 + 보안 강화
  • 보안 검사: WAF/봇 차단/DDoS 방어 등 → 공격이 원 서버까지 도달하기 전에 차단
  • 라우팅 최적화: 더 빠른 경로로 트래픽 전달(기능/플랜에 따라 차이)
  • 엣지 컴퓨팅: Cloudflare Workers 같은 기능으로 “서버 코드를 엣지에서 실행”

2) Cloudflare 제품군을 큰 그림으로 분류하면 5가지다

Cloudflare는 제품이 많아서 처음엔 정신이 없는데, 아래 5개 축으로 보면 정리된다.

A. 네트워크/성능 (Speed)

  • CDN/캐시
  • 이미지 최적화(리사이즈/포맷 변환 등)
  • 압축, HTTP/2·HTTP/3, 브로틀리(Brotli) 같은 전송 최적화
  • 정적 자산 가속, 글로벌 엣지 제공

B. 보안 (Security)

  • DDoS 방어(네트워크 레벨부터 웹 레벨까지)
  • WAF(웹 애플리케이션 방화벽)
  • Bot Management(자동화 트래픽/스크래퍼 방어)
  • Rate Limiting(요청 폭주 제한)
  • Turnstile(캡차 대체)

C. DNS / 도메인 / 트래픽 제어 (Control Plane)

  • DNS(레코드 관리)
  • 로드밸런싱(헬스체크 기반 라우팅)
  • Rules(리다이렉트, 헤더, 캐시 정책, 차단 규칙 등)

D. 개발자 플랫폼 (Developer Platform)

  • Workers: 엣지에서 실행되는 서버리스 런타임
  • Pages: 정적 사이트(SSG) 호스팅 + (선택) Functions
  • KV / Durable Objects / Queues 등(플랫폼 기능: 상태/스토리지/메시징)

E. Zero Trust / 기업용 네트워크 (Access)

  • 사내/관리자 페이지를 “VPN 없이” 안전하게 접근 제어(SSO, MFA)
  • Cloudflare Tunnel로 원 서버를 인터넷에 직접 노출하지 않고 연결
  • 네트워크/디바이스 정책 기반 접근 제어

3) 왜 Cloudflare를 쓰는가? (기업들이 선택하는 이유)

기업들이 Cloudflare를 쓰는 이유는 결국 돈/리스크/속도의 문제로 귀결된다.

1) “보안 비용”을 앞단에서 크게 줄여준다

  • 공격(DDoS, 봇, 스캐닝)이 원 서버에 닿기 전에 엣지에서 막히면:
    • 원 서버 CPU/대역폭 낭비가 줄고
    • 장애 확률이 내려가고
    • 보안팀/인프라팀의 운영 부담이 감소한다

특히 회원가입/로그인/검색/결제 같은 엔드포인트는 봇 공격과 요청 폭주에 취약한데,
Cloudflare의 WAF/Rate Limiting/봇 방어는 이런 구간에 강한 편이다.

2) 성능 개선이 “인프라 구조 변경 없이” 가능하다

  • 캐싱/압축/프로토콜 최적화는 원 서버를 갈아엎지 않아도 효과가 난다.
  • 특히 글로벌 유저가 있을수록 “엣지 캐시”의 체감 효과가 커진다.

3) 가용성과 운영 안정성

  • 원 서버가 일시적으로 느려져도 캐시된 자산은 엣지에서 계속 제공 가능
  • 트래픽 스파이크(갑자기 방문자 폭증)에 대한 완충 역할
  • 헬스체크/로드밸런싱을 통해 장애 대응 옵션 확보

4) “개발자 플랫폼”이 같이 붙어 있다 (Workers/Pages)

  • 정적 사이트는 Pages로 배포(빌드 산출물 올리면 끝)
  • API 앞단에서 Workers로:
    • 인증/권한 체크
    • A/B 테스트 라우팅
    • 헤더/쿠키 조작
    • 국가/언어별 라우팅
    • 간단한 API 게이트웨이 같은 작업을 엣지에서 빠르게 처리할 수 있다.

5) Zero Trust로 내부 시스템 보호(기업용)

  • 관리자 페이지/백오피스를 공개 인터넷에 노출하지 않고도 운영 가능
  • SSO/MFA/접근 정책으로 보안 강화
  • 기존 VPN의 운영/UX 문제를 줄이는 경우가 많다

4) Cloudflare는 “어떻게 쓰는가?” (실전 도입 흐름)

정적 블로그부터 API 서비스까지, 도입 흐름은 보통 아래 순서로 간다.

Step 1) 도메인 DNS를 Cloudflare로 연결

  • 도메인을 Cloudflare에 추가
  • 도메인 Registrar(가비아/Namecheap 등)에서 네임서버를 Cloudflare로 변경
  • DNS 레코드(A/CNAME 등) 설정

여기서부터 Cloudflare는 네 트래픽의 “교통정리판”이 된다.

Step 2) 프록시 적용(오렌지 구름)과 SSL/TLS 설정

  • DNS 레코드에 프록시(오렌지 구름)를 켜면 Cloudflare가 앞단에 선다
  • SSL/TLS 모드 설정:
    • 원 서버까지 HTTPS를 쓸지
    • 인증서 구성은 어떤지
    • 리다이렉트(HTTP→HTTPS) 정책

운영 팁

  • 원 서버까지 HTTPS를 사용하는 구성이 보통 안전하다.
  • 프록시를 켜면 원 서버 IP가 숨겨지는 효과가 있어 보안에 도움이 된다.

Step 3) 성능 최적화(캐시/압축)와 보안 규칙 적용

  • 캐시 룰(정적 자산 캐싱, HTML 캐싱 전략 등)
  • WAF 룰(공격 패턴 차단)
  • Rate Limiting(로그인/검색 엔드포인트 폭주 제한)
  • Bot 보호, Geo 차단 등

Step 4) Pages/Workers로 앱 배포 or 엣지 로직 추가

  • 정적 사이트: Pages가 가장 쉬움
  • 서버 로직/엣지 기능: Workers로 확장

5) “정적 사이트(블로그)”에서 Cloudflare를 가장 잘 쓰는 법

정적 블로그는 Cloudflare와 궁합이 정말 좋다. 이유는 단순하다:

  • 블로그는 정적 파일(HTML/CSS/JS/이미지)이 대부분이고
  • 캐싱이 매우 잘 먹히며
  • DDoS/봇 공격 방어가 원 서버 부담 없이 가능해지기 때문

추천 조합

  • Cloudflare Pages로 배포 (빌드 결과물 dist 서빙)
  • 캐시 정책은 기본값으로도 대체로 만족
  • 이미지가 많다면 이미지 최적화 기능 고려(플랜/프로덕트에 따라 다름)
  • 댓글/검색 같은 동적 기능은:
    • 외부 서비스(예: 검색 인덱스/댓글 SaaS)를 붙이거나
    • Workers로 최소 로직만 엣지에서 처리하는 방식 고려

Pages 운영에서 자주 하는 설정

  • 리다이렉트 규칙(이전 URL 호환)
  • 보안 헤더 설정
  • 캐시 헤더(정적 자산 장기 캐시)