3장. 글로벌 DNS·엣지 네트워크 (고수: Route 53·Cloudflare)

학습 목표

• DNS 계층 구조와 Route 53의 핵심 레코드(A, AAAA, CNAME, Alias, TXT, CAA)를 구분하고, 루트 도메인(Zone Apex)에 CNAME을 쓸 수 없는 이유와 Alias 레코드의 해법을 설명한다.
• Route 53 라우팅 정책(단순, 가중치, 지연 시간, 장애 조치)과 헬스 체크를 조합해 카나리 배포와 자동 장애 조치를 설계한다.
• 무중단 도메인·서버 이전을 위해 전환 시점보다 최소 기존 TTL 시간 이전에 TTL을 미리 낮추어야 하는 원리를 설명한다.
• Cloudflare의 DNS 전용(회색 구름)과 프록시(주황 구름) 모드의 차이를 이해하고, SSL/TLS 모드 중 Flexible이 리다이렉트 루프나 평문 노출을 부르는 이유와 Full (Strict) + Origin CA 구성을 설명한다.
• WAF·Rate Limiting·Bot 제어 규칙을 설계할 때 정상 결제·인증 웹훅이 차단되지 않도록 예외와 서명 검증을 구성한다.
• CDN 캐시 규칙에서 개인화 API 응답(/api/*, Authorization, Set-Cookie)과 LLM 스트리밍(text/event-stream)의 캐시 오염 및 버퍼링 사고를 예방한다.
• Cloudflare Workers, Queues, 그리고 AI Gateway(관측성, 캐싱, 속도 제한, 멀티 프로바이더 폴백)를 결합해 탄력적인 AI 엣지 아키텍처를 설계한다.

들어가며

코드도 완벽하고 데이터베이스도 튼튼한데 사용자 화면에는 ERR_TOO_MANY_REDIRECTS(리다이렉트 횟수 초과)가 뜨거나, 서버를 새 클라우드로 옮겼더니절반의 사용자는 6시간 동안 이미 종료된 옛날 서버로 접속하거나, 더 끔찍하게는 내가 로그인했는데 남의 계정 프로필과 대화 내역이 내 화면에 그대로 보이는 사고가 일어납니다. 애플리케이션 코드를 아무리 뒤져 봐도 버그가 없습니다. 범인은 코드 바깥, 즉 DNS와 엣지 네트워크(CDN·리버스 프록시) 설정에 있기 때문입니다.

사용자가 주소창에 https://aidan.agentcat.app을 입력하는 순간부터 우리 애플리케이션 서버가 첫 바이트를 돌려주기까지, 요청은 먼저 **권한 있는 DNS(Amazon Route 53, Cloudflare DNS)**에서 IP 주소를 찾고, **글로벌 엣지 프록시(Cloudflare)**에서 TLS 핸드셰이크·WAF 검사·캐시 조회·워커 실행을 거친 뒤에야 비로소 원본 서버(Origin)에 도달합니다. AI 서비스에서는 여기에 하나가 더 추가됩니다. 우리 서버에서 다시 외부 LLM 프로바이더(OpenAI, Anthropic, Google)로 나가는 트래픽이 AI Gateway를 거쳐 흘러갑니다.

이 장에서는 인터넷의 전화번호부인 Route 53부터 전 세계 300여 개 도시의 앞마당에서 방패와 가속기 역할을 하는 Cloudflare의 프록시·보안·캐시·서버리스·AI 게이트웨이까지, 고수 엔지니어가 반드시 꿰뚫고 있어야 할 아홉 가지 핵심 설계 원리를 다룹니다.

핵심 개념

DNS 해석 경로와 핵심 레코드: 왜 루트 도메인에는 CNAME을 못 쓰는가

도메인 이름 시스템(DNS)은 사람이 읽기 쉬운 도메인(aidan.agentcat.app)을 컴퓨터가 통신할 수 있는 IP 주소(192.0.2.1 또는 2001:db8::1)로 바꾸어 주는 계층형 분산 데이터베이스입니다. 사용자의 기기(Stub Resolver)가 통신사나 공용 재귀 리졸버(Recursive Resolver, 예: 1.1.1.1, 8.8.8.8)에 물어보면, 재귀 리졸버는 루트(.) 네임서버 → 최상위 도메인(.app) 네임서버 → 권한 있는 네임서버(Authoritative Nameserver, 예: Route 53이나 Cloudflare) 순서로 찾아가 최종 레코드를 받아오고, 그 결과를 TTL(Time To Live, 초 단위 유효 시간) 동안 캐시에 저장해 재사용합니다.

가장 자주 다루는 DNS 레코드 유형과 용도는 다음과 같습니다.

여기서 시험에 단골로 출제되는 가장 중요한 규칙이 바로 **루트 도메인(Zone Apex, 예: example.com)의 CNAME 금지 규칙(RFC 1034 / RFC 2181)**입니다.

DNS 표준에 따르면 어떤 이름에 CNAME 레코드가 존재하면, 그 이름에는 다른 어떤 레코드도 함께 존재할 수 없습니다. 그런데 루트 도메인(example.com)에는 그 도메인 영역 전체를 정의하는 필수 레코드인 SOA(Start of Authority)와 NS(Name Server) 레코드가 무조건 존재해야 합니다. 따라서 표준 DNS에서는 www.example.com(서브도메인)에는 CNAME을 자유롭게 쓸 수 있지만, example.com(루트 도메인)에는 CNAME을 넣는 순간 영역(Zone) 규칙이 깨집니다.

클라우드 로드밸런서(ALB)나 CDN(CloudFront, Vercel)은 고정 IP 대신 도메인 주소만 주는데, 루트 도메인에 CNAME을 못 쓰면 어떻게 연결할까요?

• Amazon Route 53의 Alias 레코드: Route 53 고유의 확장 기능입니다. 관리자는 대상 ALB나 CloudFront, S3, 또는 같은 호스팅 영역의 레코드를 가리키도록 Alias를 설정하지만, 외부 DNS 리졸버가 example.com의 A 레코드를 물어보면 Route 53이 내부적으로 대상의 현재 IP 주소를 찾아 표준 A/AAAA 응답으로 돌려줍니다. 따라서 DNS 표준을 전혀 어기지 않으면서 루트 도메인에 사용할 수 있고, AWS 리소스를 가리키는 Alias 질의는 Route 53 쿼리 요금도 부과되지 않습니다.
• Cloudflare의 CNAME Flattening(평탄화): 루트 도메인에 CNAME을 입력하면 Cloudflare 네임서버가 백그라운드에서 대상 도메인을 끝까지 추적해 최종 IP(A/AAAA)로 평탄화해서 응답해 줍니다.

Route 53 라우팅 정책과 헬스 체크를 통한 무중단 트래픽 제어

Route 53은 단순히 도메인을 하나의 IP로만 연결하는 것이 아니라, 트래픽의 비율·지연 시간·서버 생존 여부에 따라 서로 다른 엔드포인트로 응답을 갈라 주는 **라우팅 정책(Routing Policy)**을 제공합니다.

여기서 핵심은 라우팅 정책 자체는 대상 서버가 살아 있는지 죽었는지 자동으로 알지 못한다는 점입니다. 가중치 라우팅이나 장애 조치 라우팅이 죽은 서버로 트래픽을 보내지 않게 하려면 반드시 **Route 53 헬스 체크(Health Check)**를 만들어 레코드에 연결(Evaluate Target Health 또는 헬스 체크 ID 지정)해야 합니다.

이때 헬스 체크 대상 엔드포인트(/api/health)를 어떻게 구현하느냐도 중요합니다. 만약 /api/health가 데이터베이스나 외부 API는 전혀 확인하지 않고 무조건 200 OK 문자열만 돌려주는 껍데기(Shallow Check)라면, 데이터베이스 연결이 끊겨 모든 실제 요청이 500 오류를 뿜고 있어도 Route 53은 서버가 정상인 줄 알고 계속 트래픽을 보냅니다. 반대로 헬스 체크마다 무거운 LLM 호출을 실행하면 전 세계 헬스 체커들이 몇 초마다 보내는 요청 때문에 비용이 폭발합니다. 따라서 헬스 체크는 로컬 프로세스 상태와 핵심 의존성(예: DB 연결 풀 SELECT 1)을 가볍게 확인해 이상 시 503 Service Unavailable을 반환하도록 설계해야 합니다.

무중단 도메인·서버 이전과 TTL(Time To Live) 사전 단축의 법칙

서버나 플랫폼을 이전할 때 가장 많이 저지르는 실수를 살펴봅시다. 어떤 팀이 기존 서버(IP 198.51.100.10)의 DNS A 레코드 TTL을 평소대로 **86,400초(24시간)**로 두고 운영하고 있었습니다. 일요일 새벽 2시에 새 서버(IP 203.0.113.50)로 전환하기로 하고, 새벽 2시 정각에 DNS 콘솔에 들어가 TTL을 60초로 바꾸는 동시에 IP 주소를 새 서버로 고친 뒤, 새벽 2시 10분에 구 서버를 꺼 버렸습니다.

결과는 어땠을까요? 일요일 내내 고객 절반 이상이 "사이트에 접속할 수 없다"고 항의했습니다. 왜 새벽 2시에 TTL을 60초로 줄였는데 소용이 없었을까요?

이미 새벽 1시 50분에 질의를 마친 전 세계 통신사 DNS 리졸버들은 구 서버 IP(198.51.100.10)를 '앞으로 24시간(86,400초) 동안은 다시 물어보지 말고 캐시에서 꺼내 써라'라는 옛날 TTL과 함께 저장해 두었기 때문입니다! 리졸버는 자신의 캐시 유효 시간이 끝날 때까지는 권한 있는 네임서버에 다시 찾아오지조차 않으므로, 우리가 새벽 2시에 네임서버에서 바꾼 새 IP와 60초짜리 새 TTL은 리졸버에게 전달될 기회조차 없습니다.

따라서 무중단 DNS 전환의 정석 타임라인은 반드시 다음 5단계 순서를 지켜야 합니다.

1. 사전 준비 (전환 최소 24~48시간 전, 즉 '기존 TTL' 시간보다 훨씬 이전): 기존 레코드의 IP는 그대로 둔 채 TTL만 먼저 짧은 값(예: 60초~300초)으로 낮춥니다.
2. 기존 캐시 만료 대기: 기존에 24시간으로 설정되어 있었다면 최소 24시간 이상 기다립니다. 이 시간이 지나면 전 세계 모든 리졸버의 옛날 캐시가 만료되어, 이제 모든 리졸버는 60~300초마다 우리 네임서버에 새로 물어보는 상태가 됩니다.
3. 신규 환경 준비 및 병행 가동: 새 서버를 띄우고 구 서버와 새 서버가 모두 정상 요청을 처리할 수 있도록(동일 DB 바라보기 등) 두 환경을 동시에 열어 둡니다.
4. 레코드 전환 (Cutover): DNS 레코드의 값을 새 서버 IP(또는 새 대상)로 변경합니다. 이미 TTL이 60~300초로 줄어 있으므로 최대 1~5분 안에 전 세계 트래픽이 새 서버로 넘어옵니다.
5. 관측 후 구 서버 종료 및 TTL 복원: 구 서버의 액세스 로그에 더 이상 트래픽이 들어오지 않는 것을 확인한 뒤 구 서버를 내리고, DNS 질의 비용과 지연을 줄이기 위해 TTL을 다시 평상시 값(예: 3,600초)으로 올립니다.

Cloudflare 프록시(주황 구름) 대 DNS 전용(회색 구름)과 원본 IP 은폐

Cloudflare에 도메인을 등록하면 각 DNS 레코드 옆에 구름 모양 스위치가 있습니다. 이 스위치 하나가 네트워크 경로 전체를 바꿉니다.

주황 구름(Proxied)을 켤 때 반드시 알아야 할 두 가지 실무 함정이 있습니다.

1. 외부 서비스의 CNAME 검증이나 비-HTTP 포트는 회색 구름(DNS Only)으로 두어야 할 때가 있습니다. 예를 들어 외부 이메일 발송 서비스(DKIM CNAME)나 타 플랫폼(Vercel, AWS ACM 인증서 검증 CNAME 등)이 "우리 쪽으로 CNAME이 정확히 걸려 있는지" DNS 질의로 검증할 때, 주황 구름을 켜 두면 Cloudflare가 CNAME을 숨기고 Cloudflare IP(A/AAAA)로 응답해 버려 상대 플랫폼이 "CNAME 설정을 찾을 수 없다"며 검증에 실패합니다. 또한 Cloudflare 기본 프록시는 표준 HTTP/HTTPS 포트(80, 443 등) 트래픽만 중계하므로, 일반 SSH(22)나 DB(5432) 포트를 주황 구름 도메인으로 직접 접속하려 하면 연결되지 않습니다(이때는 4장의 Cloudflare Tunnel이나 Spectrum을 씁니다).
2. 주황 구름을 켰다고 원본 서버 방화벽을 전 세계(0.0.0.0/0)에 열어 두면 WAF가 무용지물이 됩니다! 공격자가 과거 DNS 이력 조회 사이트(SecurityTrails 등)나 실수로 노출된 서브도메인(direct.example.com), 혹은 전체 IPv4 대역 스캔으로 원본 서버의 진짜 IP 주소를 알아낸 뒤, Cloudflare를 거치지 않고 Host: app.example.com 헤더를 붙여 원본 IP로 직접 요청을 쏘면 Cloudflare의 WAF와 Rate Limiting을 100% 우회할 수 있습니다. 이를 막으려면 원본 서버 방화벽에서 오직 Cloudflare의 공개 엣지 IP 대역만 허용하거나, Authenticated Origin Pulls(mTLS 클라이언트 인증서 검증) 또는 Cloudflare Tunnel로 원본을 잠가야 합니다.

SSL/TLS 암호화 모드: 왜 Flexible은 절대 쓰면 안 되고 Full (Strict)가 표준인가

Cloudflare 프록시(주황 구름)를 쓰면 암호화 구간이 두 개로 나뉩니다. 첫째는 [사용자 브라우저 ↔ Cloudflare 엣지] 구간이고, 둘째는 [Cloudflare 엣지 ↔ 우리 원본 서버(Origin)] 구간입니다. Cloudflare의 SSL/TLS 모드는 바로 이 **두 번째 구간(엣지 ↔ 원본 서버)**을 어떻게 연결할지를 결정합니다.

여기서 실무와 시험에서 가장 유명한 장애 시나리오가 바로 **Flexible 모드가 일으키는 무한 리다이렉트 루프(ERR_TOO_MANY_REDIRECTS)**입니다.

왜 이런 일이 벌어질까요?

1. 사용자가 브라우저에서 https://app.example.com으로 접속합니다.
2. Cloudflare는 Flexible 모드이므로, 원본 서버(Vercel, Nginx, ALB 등)에는 **평문 http://app.example.com (포트 80, X-Forwarded-Proto: http)**으로 바꿔서 요청을 보냅니다.
3. 그런데 현대적인 원본 서버나 웹 프레임워크는 보안을 위해 "어? 평문 HTTP로 요청이 들어왔네? https://app.example.com으로 다시 접속해!"라며 301/308 Redirect to https://app.example.com 응답을 돌려줍니다.
4. 브라우저는 시키는 대로 다시 https://app.example.com을 요청하고, Cloudflare는 또 원본에 http://로 보내고, 원본은 또 https://로 리다이렉트시키는 무한 뺑뺑이가 돌다가 브라우저가 ERR_TOO_MANY_REDIRECTS 오류를 띄우며 멈춥니다!

따라서 해법은 명확합니다. Flexible 모드는 절대로 쓰지 말고 반드시 Full (Strict) 모드를 사용해야 합니다. 원본 서버에 공인 인증서(Let's Encrypt 등)를 자동 갱신하기 번거롭다면, Cloudflare가 무료로 발급해 주는 Cloudflare Origin CA 인증서(최대 15년 유효, Cloudflare 엣지와 원본 서버 구간 전용)를 원본 서버나 ALB에 설치하고 Full (Strict)를 켜면 한 번에 해결됩니다.

WAF·Rate Limiting·Bot 제어와 정상 웹훅 보호

Cloudflare 엣지에서는 요청이 원본 서버에 닿기 전에 악성 트래픽을 걸러내는 세 겹의 방어막을 운영합니다.

• WAF 관리형 규칙(Managed Rules): SQL 인젝션, XSS, Log4Shell, 최신 프레임워크 CVE 공격 패턴을 자동으로 차단합니다.
• 속도 제한(Rate Limiting Rules): 특정 IP, 사용자 세션, 또는 API 키가 짧은 시간 안에 비정상적으로 많은 요청(예: 로그인 무차별 대입 공격 /api/auth/login 분당 10회 초과, 고비용 AI 생성 API /api/chat 분당 20회 초과)을 보내면 429 Too Many Requests로 차단합니다. 이때 NAT 환경(사내 오피스, 대학교, 통신사 게이트웨이)에서는 수백 명의 정상 사용자가 같은 공인 IP를 공유하므로, 민감한 API의 레이트 리밋은 단순 IP 단독 기준보다 세션 쿠키·인증 토큰·복합 키를 함께 고려해 오차단을 줄입니다.
• Bot 제어(Bot Fight Mode / Super Bot Fight Mode): 자동화된 스크래퍼와 크롤러에 JS 챌린지나 Turnstile 캡차를 제시합니다.

여기서 자주 터지는 실무 사고는 Bot Fight Mode나 과도한 WAF 규칙이 외부 결제사(Toss, Stripe, Lemon Squeezy)나 GitHub, Slack이 보내는 정상 서버 간 웹훅(Webhook) 요청까지 '봇'으로 판정해 JS 챌린지(HTML 화면)를 내려보내 결제가 누락되는 사고입니다! 외부 웹훅 서버는 브라우저가 아니므로 자바스크립트 챌린지나 캡차를 풀 수 없습니다.

따라서 웹훅 엔드포인트(예: /api/payments/webhook)를 보호할 때는 다음과 같이 설계합니다.

1. /api/payments/webhook 경로에는 브라우저 대상 인터랙티브 챌린지(JS Challenge / Managed Challenge)가 걸리지 않도록 WAF 사용자 지정 규칙을 구성하되, 보안 검사 전체를 무작정 다 끄지는 않습니다.
2. 대신 애플리케이션(또는 엣지 워커) 코드에서 웹훅 발신자가 보낸 암호화 HMAC 서명 헤더(예: X-Signature, Stripe-Signature)와 타임스탬프를 비밀키로 엄격히 검증해 위조된 요청을 거부합니다.

CDN 캐시 규칙과 동적 API·스트리밍 캐시 오염 방지

CDN 캐싱은 정적 자산(/static/*, 폰트, 공개 이미지)의 응답 속도를 높이고 원본 서버 부하를 줄여 주는 일등 공신입니다. 그러나 캐시 규칙(Cache Rules)을 잘못 건드려 동적 응답을 캐싱하는 순간, 인프라 역사상 가장 끔찍한 개인정보 유출 사고인 '캐시 오염(Cache Poisoning / Web Cache Deception)'이 발생합니다.

만약 관리자가 원본 서버 부담을 줄이겠다며 Cloudflare Cache Rule에서 URI Path starts with /api/ 또는 사이트 전체(*)에 대해 **Cache Everything (모든 것 캐시) 및 Ignore Cache-Control (원본 헤더 무시)**을 켰다고 상상해 봅시다.

1. 첫 번째로 홍길동 고객이 로그인한 상태에서 /api/me(또는 서버 사이드 렌더링된 /dashboard)를 호출합니다.
2. 원본 서버는 홍길동의 이름, 이메일, 최근 AI 상담 내역, 심지어 응답 헤더의 Set-Cookie: session=hong_secret까지 담아 응답합니다.
3. Cloudflare 엣지 노드가 이 응답을 /api/me라는 캐시 키(Cache Key)에 그대로 저장해 버립니다!
4. 1초 뒤 전혀 모르는 김철수(심지어 비로그인 사용자)가 /api/me에 접속하면, Cloudflare는 원본 서버에 물어보지도 않고 캐시에 들어 있던 홍길동의 개인정보와 홍길동의 세션 쿠키를 김철수에게 그대로 내려줍니다!

따라서 AI·웹 서비스의 캐시 설계에서는 다음 네 가지 철칙을 목숨처럼 지켜야 합니다.

Cloudflare Workers와 Queues: 엣지 컴퓨팅과 비동기 작업 분리

Cloudflare는 전 세계 엣지 노드에서 경량 V8 Isolate 기반으로 즉시 실행되는 서버리스 런타임인 Cloudflare Workers와, 비동기 메시지 브로커인 Cloudflare Queues를 제공합니다.

• Cloudflare Workers: 무거운 가상머신이나 컨테이너를 띄우는 대신 V8 엔진의 격리 공간(Isolate)만 수 밀리초 만에 생성하므로 콜드 스타트가 사실상 0ms에 가깝습니다. 사용자와 가장 가까운 엣지에서 JWT 서명을 1차 검증해 무효한 요청을 원본 서버 도달 전에 쳐내거나, 국가 헤더(CF-IPCountry)에 따라 결제 통화·언어를 라우팅하거나, 정적 응답 헤더(보안 헤더 Strict-Transport-Security, Content-Security-Policy)를 주입하는 가벼운 관문 작업에 이상적입니다. 단, Workers는 CPU 연산 시간 제한이 엄격하고 단일 중앙 데이터베이스가 멀리 떨어져 있다면(1장에서 본 RTT 문제) 무거운 다중 DB 트랜잭션보다 엣지 라우팅·검증·캐시 조합이나 Smart Placement에 맞추어 써야 합니다.
• Cloudflare Queues: AI 서비스에서는 사용자가 요청을 보냈을 때 당장 1초 안에 답을 줄 수 없는 무거운 후처리 작업이 많습니다(예: 100쪽짜리 PDF 임베딩 생성, 대량 알림 메일 발송, 외부 웹훅 수신 후 복잡한 정산 처리). 이를 사용자의 HTTP 요청 안에서 동기로 처리하면 타임아웃이 나거나 외부 API 장애가 곧바로 사용자 오류로 이어집니다. 이때 요청을 받은 프런트 Worker(Producer)는 Queues에 작업 메시지만 넣고 즉시 202 Accepted를 반환하고, 뒤쪽의 Consumer Worker가 배치(Batch) 단위로 메시지를 꺼내 처리하게 분리하면 트래픽 급증을 완충(Buffering)할 수 있습니다. 일시적 실패 시 자동 재시도(Retry with backoff)를 수행하고, 끝내 실패한 메시지는 **데드 레터 큐(Dead Letter Queue, DLQ)**로 따로 모아 유실 없이 원인을 분석하고 재처리할 수 있습니다.

Cloudflare AI Gateway: LLM 트래픽의 관측·캐싱·속도 제한·폴백

우리 애플리케이션이 OpenAI, Anthropic, Google Gemini 같은 외부 LLM API를 직접 호출할 때 가장 큰 운영 고충은 무엇일까요?

1. 여러 서비스와 에이전트가 각자 API를 부르다 보니 어느 기능에서 토큰과 비용이 얼마나 나가는지, 지연 시간(TTFT)과 오류율이 얼마인지 한눈에 볼 수 없습니다.
2. 똑같은 시스템 프롬프트와 똑같은 질문이 수백 번 반복되는데도 매번 LLM 요금을 내고 수초씩 기다립니다.
3. 특정 LLM 벤더(예: OpenAI)에 일시적인 장애(502/503)나 레이트 리밋(429)이 발생하면 우리 서비스 전체가 그대로 멈춥니다.

Cloudflare AI Gateway는 애플리케이션 코드와 LLM 프로바이더 API 사이에 위치하는 LLM 전용 프록시 관문입니다. 기존 SDK에서 API 기본 주소(baseURL)만 AI Gateway 주소로 바꾸면 코드를 거의 고치지 않고도 다섯 가지 강력한 인프라 통제를 얻을 수 있습니다.

깊이 읽기

무중단 블루-그린 인프라 전환에서 DNS 가중치 라우팅과 엣지 라우팅의 차이

대규모 아키텍처 개편으로 트래픽의 5%만 먼저 새 인프라(Green)로 보내고 95%는 기존 인프라(Blue)에 두는 카나리 전환을 할 때, **Route 53 가중치 라우팅(DNS 계층)**과 Cloudflare Workers / Load Balancing(HTTP 엣지 계층) 중 어느 것을 써야 할까요? 두 방식은 전환 속도와 회수(Rollback) 시간에서 결정적인 차이가 있습니다.

따라서 두 방식을 상호 배타적으로 볼 필요가 없습니다. 평상시에는 Route 53과 Cloudflare를 함께 쓰되, 애플리케이션 버전이나 원본 서버 풀 사이의 세밀한 카나리 분배와 즉각적인 서킷 브레이킹은 HTTP 헤더와 쿠키를 볼 수 있는 엣지 프록시 계층에서 수행하고, 리전 전체나 CDN 사업자 자체를 옮기는 거시적 재해 복구에는 DNS 라우팅 정책(사전 낮은 TTL 유지)을 쓰는 것이 가장 단단한 다층 구조입니다.

원본 서버 직접 노출(Origin IP Leak) 경로와 완전한 원본 잠금(Origin Lockdown)

Cloudflare WAF에 한 달에 수백만 원을 써서 완벽한 차단 규칙을 세워 두었더라도, 공격자가 원본 서버의 IP나 원본 플랫폼 주소(예: my-app.vercel.app, 또는 AWS ALB의 기본 *.elb.amazonaws.com 주소)로 직접 요청을 보낼 수 있다면 WAF는 종이호랑이에 불과합니다.

실무에서 원본 주소가 새어 나가는 경로는 놀라울 만큼 다양합니다.

1. Cloudflare를 도입하기 전에 썼던 구 IP가 과거 DNS 히스토리 데이터베이스에 남아 있는 경우.
2. 메일 서버(MX, mail.example.com)나 개발 서버(dev.example.com)를 같은 서버에 두고 그 레코드만 회색 구름(DNS Only)으로 열어 둔 경우.
3. 애플리케이션의 비밀번호 재설정 이메일 발송이나 이미지 다운로드 기능(SSRF)이 외부 서버로 직접 아웃바운드 요청을 보내면서 원본 서버의 공인 IP를 드러내는 경우.
4. Vercel의 기본 배포 도메인(aidan-mu.vercel.app)이 보호나 리다이렉트 없이 그대로 열려 있는 경우.

따라서 진정한 엣지 보안은 **"Cloudflare(또는 지정된 프록시)를 거치지 않은 요청은 원본이 아예 거부한다"**는 **원본 잠금(Origin Lockdown)**이 완성되어야 끝납니다.

• 네트워크 방화벽 수준: 원본 보안 그룹(Security Group)의 인바운드 443 포트를 0.0.0.0/0에서 Cloudflare 공인 IPv4/IPv6 목록으로만 좁히거나, 아예 인바운드 포트를 모두 닫고 Cloudflare Tunnel(4장)로만 연결합니다.
• TLS 상호 인증 수준 (Authenticated Origin Pulls, mTLS): 공격자가 다른 Cloudflare 무료 계정을 만들어 자기 도메인의 원본 IP를 우리 서버 IP로 지정해 Cloudflare IP 대역 검사를 우회하는 것까지 막으려면, 영역별(Per-Zone) 또는 사용자 지정 클라이언트 인증서를 통한 Authenticated Origin Pulls를 켜서 오직 '우리 Cloudflare 계정 영역'이 제시하는 TLS 클라이언트 인증서가 있을 때만 원본이 응답하게 만듭니다.
• 플랫폼 도메인 수준: 관리형 플랫폼(Vercel 등)을 원본으로 쓸 때는 기본 .vercel.app 주소로 들어온 요청을 정식 프로덕션 도메인(https://aidan.agentcat.app)으로 308 Permanent Redirect 시키거나 배포 보호 및 서명된 커스텀 헤더 검증으로 우회 진입을 차단합니다.

실무 장면

별무리커머스: Cloudflare 도입 당일 터진 무한 리다이렉트와 장바구니 캐시 오염

맞춤형 선물 추천 AI 쇼핑몰 '별무리커머스'는 블랙프라이데이 트래픽 급증과 해외 봇 공격에 대비해 기존 AWS ALB 앞에 Cloudflare를 붙이기로 했다. 담당 엔지니어는 금요일 저녁에 도메인 네임서버를 Cloudflare로 바꾸고 두 가지 설정을 켰다. 첫째, 원본 설정을 건드리기 귀찮아 SSL/TLS 모드를 Flexible로 두었다. 둘째, 서버 부하를 극적으로 줄이겠다며 모든 경로(*)에 대해 Cache Level: Cache Everything 규칙을 추가했다.

전환 5분 뒤 사이트 전체가 마비되었다. 첫째, 접속한 고객의 절반은 브라우저에 ERR_TOO_MANY_REDIRECTS 오류가 떠서 아예 첫 화면조차 열지 못했다. AWS ALB에 걸려 있던 "HTTP(80) 요청을 HTTPS(443)로 리다이렉트하라"는 규칙과 Cloudflare의 Flexible 모드(엣지→원본을 HTTP 80으로 전송)가 충돌해 무한 리다이렉트 루프에 빠진 것이었다.

급히 ALB의 HTTP 리다이렉트를 끄자 사이트는 열렸지만, 10분 뒤 훨씬 더 끔찍한 두 번째 사고가 터졌다. 고객센터로 "내 장바구니와 배송지 주소록에 생판 모르는 다른 사람의 이름과 전화번호, AI 선물 상담 내역이 들어 있다!"는 신고가 폭주한 것이다. Cache Everything 규칙 때문에 첫 로그인 고객이 호출한 /api/cart와 /api/chat/history의 JSON 응답이 Cloudflare 엣지에 통째로 캐시되어, 뒤이어 접속한 다른 고객들에게 그대로 배포된 전형적인 캐시 오염 사고였다. 게다가 AI 선물 상담의 실시간 스트리밍(/api/chat/stream)도 한 글자씩 나오지 않고 20초 동안 멈췄다가 한꺼번에 쏟아졌다.

긴급 투입된 인프라 아키텍트는 15분 만에 다음 조치를 순서대로 실행해 사태를 수습했다.

1. 즉시 캐시 전체 삭제(Purge Everything) 및 동적 경로 우회: Cloudflare 캐시를 전량 퍼지(Purge)해 오염된 개인정보 응답을 즉시 지웠다. 이어서 Cache Rule을 전면 수정해 /api/*, /auth/*, /checkout/* 및 Cookie나 Authorization 헤더가 포함된 요청은 무조건 **Bypass Cache**가 되도록 최우선 순위로 고정했다. 원본 서버에서도 모든 개인화 응답에 Cache-Control: private, no-store 헤더를 강제하고, SSE 스트리밍 응답에는 Content-Type: text/event-stream과 Cache-Control: no-cache, no-transform을 명시했다.
2. Full (Strict) 전환과 원본 보호: ALB에 정상 ACM 인증서가 이미 걸려 있었으므로 Cloudflare SSL/TLS 모드를 즉시 **Full (Strict)**로 바꾸고 ALB의 HTTPS 리다이렉트를 복구했다. 무한 루프가 사라지고 전 구간이 안전하게 암호화되었다.
3. 사후 조치: 캐시 오염이 있었던 12분간의 액세스 로그를 전수 대조해 타인의 배송지 정보가 노출된 가능성이 있는 세션 18건을 특정하고, 보안팀 및 개인정보 보호 책임자와 함께 세션 강제 만료 및 법적 통지 절차를 밟았다.

나래AI랩: 오픈AI 장애에도 멈추지 않은 AI Gateway 폴백과 사전 TTL 단축 이전

기업용 회의록 요약 서비스를 운영하는 '나래AI랩'은 두 가지 큰 과제를 앞두고 있었다. 하나는 기존 가비아 DNS에서 Amazon Route 53으로 권한 있는 네임서버와 API 엔드포인트를 무중단으로 이전하는 것이었고, 다른 하나는 단일 LLM 벤더에 장애가 날 때마다 회의록 요약 전체가 멈추는 단일 장애점(SPOF)을 없애는 것이었다.

팀은 먼저 도메인 이전을 위해 전환 예정일보다 사흘(72시간) 앞선 목요일 오전에 기존 DNS의 모든 레코드 TTL(기존 36,000초=10시간)을 60초로 낮추어 두었다. 충분한 대기 시간을 거쳐 전 세계 리졸버가 60초 주기로 질의하는 상태가 된 일요일 새벽, Route 53 호스팅 영역에 루트 도메인(narae.ai)은 Alias 레코드로, API 서브도메인(api.narae.ai)은 헬스 체크가 연결된 장애 조치(Failover) 레코드로 구성해 전환했다. 사전 TTL 단축 덕분에 단 한 건의 구 서버 유실도 없이 2분 만에 전환이 끝났고, 안정화 확인 후 TTL을 다시 3,600초로 복원했다.

이어서 LLM 호출 경로에는 Cloudflare AI Gateway와 Queues를 도입했다.

두 달 뒤 실제로 주 LLM 프로바이더에 40분간 글로벌 API 장애가 발생했지만, 나래AI랩의 요약 파이프라인은 AI Gateway가 2초 만에 대체 모델로 트래픽을 자동 우회시킨 덕분에 고객 문의 0건으로 장애 시간을 통과했다.

자주 틀리는 지점

1. "루트 도메인(example.com)에도 서브도메인처럼 표준 CNAME 레코드를 그냥 넣으면 된다." DNS 표준상 루트 도메인(Zone Apex)에는 SOA와 NS 레코드가 함께 있어야 하므로 다른 레코드와 공존할 수 없는 표준 CNAME을 쓸 수 없습니다. Route 53의 Alias 레코드나 Cloudflare의 CNAME Flattening을 써야 합니다.
2. "서버 이전 당일에 DNS 레코드 IP를 바꾸면서 그때 TTL도 60초로 줄이면 전 세계에 60초 만에 반영된다." 이미 이전 질의를 마친 DNS 리졸버들은 바꾸기 전의 옛날 TTL 시간 동안 구 IP를 캐시에 쥐고 재질의하지 않습니다. 반드시 전환 시점보다 최소 '기존 TTL 시간' 이전에 미리 TTL을 낮추고 기다려야 합니다.
3. "원본 서버에 SSL 인증서를 설치하기 귀찮으니 Cloudflare SSL 모드를 Flexible로 두면 안전하고 편하다." Flexible은 Cloudflare와 원본 서버 사이를 평문 HTTP(80)로 연결할 뿐 아니라, 원본 서버에 HTTPS 강제 리다이렉트가 켜져 있으면 ERR_TOO_MANY_REDIRECTS 무한 루프 장애를 일으킵니다. 반드시 원본 인증서(Origin CA 등)를 설치하고 Full (Strict)를 써야 합니다.
4. "Cloudflare 주황 구름(Proxied)을 켰으니 원본 서버 보안 그룹은 0.0.0.0/0으로 열어 두어도 아무도 직접 못 들어온다." 주황 구름은 DNS 응답만 Cloudflare IP로 바꿀 뿐입니다. 원본 서버의 실제 IP가 노출되어 있으면 공격자가 IP로 직접 요청을 보내 WAF를 우회할 수 있으므로, 원본 방화벽 제한·Authenticated Origin Pulls(mTLS)·Cloudflare Tunnel 등으로 원본을 잠가야 합니다.
5. "서버 부하를 줄이려면 /api/* 경로에도 CDN Cache Everything을 켜는 것이 좋다." 사용자마다 응답이 다른 API나 Set-Cookie/Authorization이 오가는 경로를 공유 CDN에 캐싱하면 첫 사용자의 개인정보와 세션이 다른 사용자에게 그대로 노출되는 대형 보안 사고가 납니다. 개인화 API와 SSE 스트리밍은 반드시 캐시를 우회(Bypass)해야 합니다.
6. "외부 플랫폼의 도메인 소유권 확인용 CNAME 레코드도 보안을 위해 주황 구름(Proxied)을 켜 두어야 한다." 주황 구름을 켜면 Cloudflare가 CNAME 대신 자신의 A/AAAA IP로 응답하므로, 상대 플랫폼이 CNAME 대상 문자열을 확인하지 못해 도메인 인증이나 인증서 발급이 실패합니다. 검증용 CNAME은 회색 구름(DNS Only)으로 두어야 합니다.

한눈에 정리

공식 문서로 확인하기

• AWS Route 53 — Choosing between alias and non-alias records: 루트 도메인 제약과 Alias 대 CNAME 비교.
• AWS Route 53 — Choosing a routing policy & Health Checks: 단순, 가중치, 지연 시간, 장애 조치 라우팅과 헬스 체크 연동.
• Cloudflare — Proxy status (Orange vs Grey Cloud): 프록시 작동 방식과 CNAME 검증 시 주의점.
• Cloudflare — SSL/TLS Encryption modes (Full (Strict)) & Origin CA: Flexible의 위험성, 리다이렉트 루프 원인과 Full (Strict) 구성.
• Cloudflare — Cache Rules & Preventing Cache Poisoning: 동적 콘텐츠 캐시 우회(Bypass)와 캐시 키 설계.
• Cloudflare — AI Gateway Documentation: LLM 통합 로깅, 캐싱, 레이트 리밋, Universal Endpoint 폴백 라우팅.

셀프 체크

3-1. DNS 표준에서 서브도메인(www.example.com)에는 CNAME 레코드를 쓸 수 있지만 루트 도메인(Zone Apex, example.com)에는 CNAME을 쓸 수 없는 이유를 설명하고, Route 53에서 루트 도메인을 AWS ALB에 연결할 때 사용하는 해법을 쓰라.

3-2. 기존 TTL이 86,400초(24시간)인 도메인의 서버 IP를 무중단으로 이전하려 할 때, 왜 이전 작업 당일이 아니라 최소 24시간 이상 전에 미리 TTL을 60~300초로 낮추어 두어야 하는지 재귀 DNS 리졸버의 캐시 동작 원리로 설명하라.

3-3. 원본 웹 서버에 "평문 HTTP 요청이 오면 HTTPS로 301 리다이렉트한다"는 설정이 켜져 있을 때, Cloudflare의 SSL/TLS 암호화 모드를 Flexible로 설정하면 사용자 브라우저에서 어떤 오류가 왜 발생하는지 설명하고, 올바른 SSL/TLS 모드를 쓰라.

3-4. Cloudflare에서 도메인에 주황 구름(Proxied)을 켜고 WAF 규칙을 완벽히 설정했더라도, 공격자가 원본 서버의 실제 IP 주소를 알아내면 어떻게 WAF를 우회할 수 있는지 설명하고, 이를 원본 서버 측에서 차단하는 방법을 두 가지 이상 쓰라.

3-5. 개인화된 사용자 정보를 반환하는 /api/profile 엔드포인트와 LLM 실시간 스트리밍을 반환하는 /api/chat/stream(text/event-stream) 엔드포인트에 대해, CDN에서 무분별한 캐싱 및 응답 버퍼링을 켰을 때 각각 어떤 사고가 발생하는지 쓰고 올바른 Cache-Control 및 캐시 규칙을 제시하라.

3-6. 설계 과제: 단일 LLM API(예: OpenAI)에 의존하던 고객 상담 요약 서비스가 프로바이더의 일시적 503 장애와 에이전트 루프로 인한 시간당 호출 폭주 때문에 자주 멈춘다. Cloudflare AI Gateway를 도입해 이 두 문제를 어떻게 해결할 수 있는지 핵심 기능 세 가지를 들어 설명하라.

실습 과제