CDN이 속도를 높이는 방법: 캐시 히트부터 동적 콘텐츠까지

인프라 성능 네트워크 백엔드
5 분 소요

CDN이 무엇인지 일반인의 언어로는 캐시·CDN 교양 편에서 다뤘습니다. 이 글은 같은 주제의 실무자용 각도입니다. CDN이 정확히 어떤 시간을 줄여 주는지, 히트율은 무엇이 결정하는지, 그리고 설정 실수가 어떻게 CDN을 장식품으로 만드는지까지 다룹니다.

CDN이 줄이는 시간: 결국 거리입니다 #

네트워크 편의 결론을 다시 씁니다. 작은 요청의 체감 속도는 RTT × 왕복 횟수이고, RTT의 하한은 물리적 거리입니다. 서울 사용자가 미국 서버의 콘텐츠를 받으면 왕복마다 130ms대가 걸립니다. CDN은 이 거리를 줄입니다. 전 세계에 깔린 엣지 서버가 콘텐츠 사본을 들고 있다가 가까운 곳에서 응답하면, 같은 요청의 RTT가 수 밀리초대로 내려옵니다.

효과는 왕복 횟수만큼 곱해집니다. TCP·TLS 핸드셰이크의 2왕복 + 요청 1왕복이 전부 짧은 거리에서 일어나므로, 첫 바이트까지의 시간(TTFB)이 통째로 내려갑니다. 오리진(원본 서버) 입장에서는 트래픽이 엣지에서 흡수되므로 부하와 전송 비용이 함께 줄어드는 부수 효과도 있습니다.

히트율: CDN의 성능은 이 숫자 하나입니다 #

엣지에 사본이 있으면(히트) 수 밀리초, 없으면(미스) 오리진까지 다녀오는 원래 시간 + 약간의 오버헤드입니다. 즉 CDN의 실효 성능은 히트율이 결정합니다. 히트율 95%와 60%는 다른 물건입니다. 히트율을 결정하는 요소는 둘입니다.

첫째, 캐시 정책: 서버가 헤더로 선언합니다. CDN은 기본적으로 오리진의 Cache-Control 헤더를 따릅니다.

Cache-Control 예시 
# 빌드 해시가 붙은 정적 자산: 1년 캐시, 불변 선언
Cache-Control: public, max-age=31536000, immutable

# HTML: 엣지에 짧게, 브라우저에는 항상 재검증
Cache-Control: public, max-age=0, s-maxage=60

# 개인화된 응답: 공유 캐시 금지
Cache-Control: private, no-store

전형적인 전략이 위 세 줄에 다 들어 있습니다. 파일명에 해시가 붙는 자산은 영원히 캐시해도 안전하고(내용이 바뀌면 파일명이 바뀌므로), HTML은 짧은 엣지 캐시(s-maxage)로 오리진을 보호하면서 갱신을 빠르게 하고, 개인화 응답은 공유 캐시에 두지 않습니다. 헤더를 선언하지 않으면 CDN의 기본값에 운명을 맡기는 셈이 됩니다.

둘째, 캐시 키: 무엇을 “같은 요청"으로 볼 것인가? 엣지는 캐시 키(기본적으로 URL)가 같아야 사본을 재사용합니다. 여기서 히트율을 갉아먹는 실수들이 나옵니다.

  • 불필요한 쿼리 파라미터: 트래킹 파라미터(utm_* 등)가 붙으면 같은 콘텐츠가 URL마다 다른 항목으로 캐시됩니다. 캐시 키에서 무관한 파라미터를 제외하는 설정이 처방입니다.
  • 과도한 Vary 헤더: Vary: Cookie 같은 선언은 사실상 캐시를 끕니다. 사용자마다 쿠키가 다르기 때문입니다.
  • 세션 쿠키가 모든 응답에: 정적 자산 응답에까지 Set-Cookie가 붙으면 캐시하지 않는 CDN이 많습니다. 자산은 쿠키 없는 도메인·경로로 분리하는 것이 고전적 처방입니다.

무효화: 캐시의 유일한 어려움 #

“캐시를 오래 걸자니 갱신이 늦고, 짧게 걸자니 효과가 없다"는 딜레마의 해법은 콘텐츠 종류별로 다릅니다. 해시 붙은 자산은 무효화가 필요 없고(새 파일명 = 새 캐시), HTML·API처럼 URL이 고정된 것은 짧은 s-maxage + 배포 시 퍼지(purge)로 다룹니다. 최근 CDN들이 지원하는 stale-while-revalidate(만료된 사본을 일단 주고 뒤에서 갱신)는 짧은 캐시의 미스 비용을 지워 주는 실용적인 중간값입니다. 태그 기반 퍼지(특정 게시물 관련 URL만 골라 무효화)까지 가면 API 응답도 캐시 대상이 됩니다.

주의할 것은 “전체 퍼지"를 배포 루틴에 넣는 습관입니다. 배포마다 히트율이 0에서 다시 시작되고, 오리진이 배포 직후마다 트래픽을 고스란히 받습니다. 무효화는 좁게, 자산은 해시로. 이 두 원칙이면 전체 퍼지가 필요한 경우는 드뭅니다.

캐시가 안 되는 것들: 그래도 CDN이 돕는 부분 #

로그인한 사용자의 API 응답처럼 캐시할 수 없는 트래픽에도 CDN 경유가 이득인 경우가 많습니다. 이유는 다시 왕복입니다.

  • TLS 종료가 엣지에서: 사용자와의 핸드셰이크 왕복이 짧은 거리에서 끝납니다.
  • 엣지〜오리진 구간의 최적화: CDN은 오리진과의 커넥션을 미리 데워 재사용하고, 사업자 백본으로 라우팅합니다. 사용자가 인터넷을 통째로 건너는 것보다 빠른 경우가 많습니다.
  • 압축과 프로토콜: 최신 프로토콜(HTTP/2·HTTP/3)과 압축(brotli)을 엣지에서 처리해, 오리진이 구형이어도 사용자 쪽 경험을 끌어올립니다.

즉 CDN은 “정적 파일 배포 도구"가 아니라 “사용자와의 왕복을 엣지로 끌어오는 층"으로 보는 것이 실무 감각에 맞습니다.

정리 #

  • CDN의 효과는 거리를 줄여 RTT × 왕복 횟수의 곱을 줄이는 것입니다. TTFB와 오리진 부하·전송 비용이 함께 내려갑니다.
  • 실효 성능은 히트율이 결정하고, 히트율은 Cache-Control 선언과 캐시 키 설계가 결정합니다. 히트율 지표를 대시보드에 올리는 것이 시작입니다.
  • 해시 자산은 영구 캐시, HTML·API는 짧은 s-maxage + 좁은 퍼지, 개인화 응답은 private이 기본 전략입니다.
  • 트래킹 파라미터, Vary: Cookie, 자산에 붙는 세션 쿠키가 히트율을 갉아먹는 3대 실수입니다.
  • 캐시 불가능한 트래픽도 TLS 종료, 커넥션 재사용, 최신 프로토콜 덕에 CDN 경유가 이득인 경우가 많습니다.
X