한눈에 보기
CDN은 같은 파일을 여러 지역의 서버에 사본으로 두고 가까운 곳에서 내려주는 구조입니다. 이 글은 위 카드의 개념을 한 흐름으로 묶어, 요청 하나가 엣지 → 오리진을 오가는 과정, 무엇을 얼마나 저장할지 정하는 HTTP 캐시 규칙(RFC 9111), 그리고 CDN이 오히려 장애의 원인이 되었던 공개 사례까지 다룹니다.
- CDN의 핵심 동작은 "엣지에 사본이 있으면 바로 응답(히트), 없으면 오리진에서 가져와 저장(미스)"입니다.
- 무엇을 저장하고 얼마나 유지할지는 오리진이 보내는 Cache-Control 같은 HTTP 헤더가 정합니다.
- 캐시는 "요청 방식과 URL"을 기본 열쇠(캐시 키)로 삼고, Vary 헤더가 있으면 그 헤더 값도 열쇠에 포함됩니다.
- CDN은 속도와 부하 분산에 이점이 있지만, 설정 실수나 공급자 장애가 한꺼번에 많은 사이트에 영향을 주는 집중 위험도 있습니다.
배경: 한 서버로는 왜 부족한가
웹이 커지면서 인기 있는 사이트 하나가 한 대의 서버로 모든 요청을 받는 방식은 두 가지 한계에 부딪힙니다. 하나는 거리입니다. 서버가 멀리 있으면 왕복 시간이 길어집니다. 다른 하나는 집중입니다. 어느 순간 요청이 몰리면(플래시 크라우드) 서버가 감당하지 못합니다. CDN은 사본을 이용자 가까이 여러 곳에 두어 두 문제를 함께 줄이려는 구조입니다. 특정 상용 서비스의 출발 연도 같은 이력은 이 글에서 다루지 않고, 여기서는 표준 문서와 공개된 사후 분석으로 확인되는 원리 중심으로 설명합니다.
요청 하나가 지나가는 길: 히트와 미스
- 이용자가 주소를 입력하면 이름 해석(DNS) 또는 애니캐스트 라우팅에 의해 가까운 엣지 서버로 연결됩니다.
- 엣지는 요청의 캐시 키로 저장된 사본을 찾습니다.
- 사본이 있고 아직 신선하면(HTTP 캐시 규칙상 유효 기간 안이면) 그대로 응답합니다. 이것이 캐시 히트입니다.
- 사본이 없거나 만료되었으면 오리진에 요청합니다. 만료된 경우 엣지는 조건부 요청(ETag를 담은 If-None-Match)으로 "바뀌었는지"만 물을 수 있고, 바뀌지 않았으면 오리진은 본문 없이 304로 답해 저장본의 수명이 갱신됩니다(RFC 9111 4.3절).
- 오리진 응답을 엣지가 이용자에게 전달하고, 저장이 허용된 응답이면 다음 요청을 위해 보관합니다.
캐시 규칙: 오리진이 보내는 헤더가 정한다
CDN은 임의로 저장하는 것이 아니라 HTTP 캐시 표준인 RFC 9111(HTTP Caching, 2022)의 규칙을 기본으로 따릅니다. 아래는 이 문서에서 확인한 핵심 요소입니다. CDN 서비스마다 이 규칙 위에 자체 설정(캐시 무시, 기간 강제 등)을 제공하는 경우가 많으니, 실제 동작은 사용하는 CDN의 문서를 확인하세요.
| 헤더·개념 | RFC 9111에서의 의미(요지) |
|---|---|
| 캐시 키 | 최소한 요청 메서드와 대상 URI로 구성된다. Vary에 적힌 요청 헤더도 키에 반영된다 |
| Cache-Control: max-age | 응답이 신선하다고 볼 수 있는 시간(초) |
| Cache-Control: s-maxage | 공유 캐시(CDN 같은 중간 캐시)에 한해 max-age를 덮어쓴다 |
| Cache-Control: private | 공유 캐시는 저장하면 안 되고, 개인 캐시(브라우저)만 저장 가능 |
| Cache-Control: no-store | 캐시가 응답을 저장하거나 다른 요청에 재사용하면 안 된다 |
| Vary | 저장된 응답을 재사용하려면 Vary가 지정한 요청 헤더 값이 일치해야 한다. 값이 *이면 항상 일치하지 않는다 |
| Age | 캐시가 저장본을 응답할 때 붙이는, 저장 후 경과 시간(초) |
여기서 "개인화된 페이지를 CDN이 그대로 저장하면 다른 사람에게 노출될 수 있다"는 앞의 카드 설명이 구체화됩니다. 로그인 사용자별 응답에는 private나 no-store를 쓰고, 모두에게 같은 정적 파일에는 긴 max-age 또는 s-maxage를 쓰는 식으로 구분합니다. 정적 파일은 파일 이름에 해시나 버전을 넣어 바꾸면 URL 자체가 새로운 캐시 키가 되므로 퍼지 없이 새 버전이 즉시 쓰입니다.
비교: CDN과 이웃 개념
| 구분 | 하는 일 | 위치 |
|---|---|---|
| 브라우저 캐시 | 한 이용자의 기기에 저장해 재방문을 빠르게 함(private 캐시) | 이용자 기기 |
| CDN(공유 캐시) | 여러 이용자가 같은 사본을 공유하며 오리진 부하를 줄임 | 오리진과 이용자 사이의 여러 지역 |
| 로드밸런서 | 같은 서비스를 하는 여러 서버로 요청을 나눔. 사본 저장이 목적이 아님 | 대개 오리진 쪽 인프라 앞 |
| 오리진 서버 | 콘텐츠의 원본을 만들고 보관함 | 운영자의 서버·클라우드 |
로드밸런서와의 관계는 로드밸런싱 기초에서 이어서 볼 수 있습니다.
가장 가까운 서버로 가는 길: 애니캐스트의 정확한 의미
애니캐스트는 여러 위치의 서버가 같은 IP 주소를 알리고, 라우팅이 한 곳을 골라 연결하는 방식입니다. RFC 4786(Operation of Anycast Services, 2006, BCP 126)은 애니캐스트의 운영 방법을 설명하면서 DNS 루트 서버 운영자들이 이를 널리 활용해 왔다고 소개하고, 공격 트래픽을 한 노드나 그 주변 지역에 가두는 효과가 있다고 설명합니다. 여기서 주의할 점은 라우팅이 고르는 서버가 "지리적으로 가장 가까운" 서버와 항상 같지는 않다는 것입니다. 선택 기준은 네트워크 경로상의 가까움이므로, 지리적 거리와 어긋날 수 있습니다. 또한 모든 CDN이 애니캐스트만 쓰는 것은 아니며, DNS 응답으로 가까운 엣지 주소를 알려주는 방식 등을 함께 쓰는 서비스도 있으니 구체적인 방식은 각 서비스의 문서를 확인해야 합니다.
실제 사례: CDN에 의존한다는 것의 양면
Fastly, 2021년 6월 8일: 유효한 설정 변경이 일으킨 장애
Fastly의 공개 사후 분석에 따르면 2021년 6월 8일 09:47(UTC)에 전 세계적 장애가 시작되어 네트워크의 85%가 오류를 반환했습니다. 회사는 49분 안에 네트워크의 95%가 정상으로 돌아왔다고 밝혔습니다. 원인은 5월 12일부터 배포된 소프트웨어 업데이트에 들어 있던 미발견 버그였고, 한 고객이 유효한 설정 변경을 적용하자 특정 조건에서 이 버그가 작동했다고 합니다. 모니터링은 약 1분 만에 장애를 감지했고, 원인이 된 고객 설정은 10:27에 확인되었습니다. 여기서 배울 점은 두 가지입니다. 하나는 많은 사이트가 같은 CDN을 쓸 때 공급자 한 곳의 문제가 동시에 여러 사이트에 보일 수 있다는 점입니다. 다른 하나는 CDN을 도입할 때 오리진 직접 접근 경로나 다중 공급자 같은 대안을 고려할 가치가 있다는 점인데, 이는 사후 분석이 아니라 일반적인 설계 관점의 이야기입니다.
Cloudflare, 2019년 7월 2일: 엣지에 배포된 규칙이 CPU를 소진
Cloudflare의 사후 분석에 따르면 2019년 7월 2일 13:42(UTC)쯤 방화벽(WAF) 관리 규칙 업데이트가 배포되었고, 규칙 속 정규 표현식이 과도한 역추적을 일으켜 HTTP/HTTPS를 처리하는 서버의 CPU가 거의 100%에 이르렀습니다. 고객 사이트에는 502 오류가 나타났고, 14:07에 WAF를 전 세계적으로 끄는 조치를 실행해 14:09에 트래픽과 CPU가 정상화되었습니다. 총 약 27분이었으며, WAF는 원인을 확인한 뒤 14:52에 다시 켜졌다고 설명합니다. 이 사례는 CDN이 단순 캐시가 아니라 보안 규칙을 엣지에서 실행하는 플랫폼이기도 하다는 점과, 모든 엣지에 동시에 배포되는 변경이 큰 영향을 줄 수 있다는 점을 보여줍니다. 위 두 사례 모두 공급자가 공개한 설명에 근거하며, 개별 사이트가 입은 손실은 확인하지 않았습니다.
가상 예시: 히트율이 오리진 부하를 바꾸는 계산
이 예시는 실제 사이트의 수치가 아닌 가상 예시입니다. 하루 요청이 1,000,000건이고 CDN 캐시 히트가 920,000건이라면 히트율은 92%이고, 오리진에 도달하는 요청은 80,000건입니다. CDN이 없을 때 오리진이 1,000,000건을 받는 것과 비교하면 오리진 요청은 12.5분의 1로 줄어듭니다(1,000,000 ÷ 80,000 = 12.5). 히트율이 95%로 오르면 오리진 요청은 50,000건으로 줄어듭니다. 히트율을 높이려면 정적 파일의 캐시 기간을 늘리고, 같은 파일인데 URL 쿼리 문자열만 달라 별도 캐시 키가 되는 상황을 줄이는 방법을 일반적으로 검토합니다.
직접 해보기: 내 사이트가 캐시되는지 확인
- 브라우저 개발자 도구의 네트워크 탭에서 파일을 선택해 응답 헤더를 봅니다.
- Cache-Control, Age, Vary 헤더가 있는지 봅니다. Age가 0보다 크면 중간 캐시에서 일정 시간 저장된 응답일 가능성이 있습니다.
- 많은 CDN이 히트·미스 여부를 별도 응답 헤더로 알려주지만, 헤더 이름은 서비스마다 다르므로 사용하는 CDN의 문서를 확인하세요.
- 로그인 후에만 보이는 페이지의 응답에 private 또는 no-store가 적용되는지 점검합니다.
흔한 오해와 정정
- 오해: CDN을 쓰면 모든 페이지가 자동으로 빨라진다. 실제: 캐시할 수 있는 응답에서 효과가 큽니다. 개인화되어 저장이 안 되는 응답은 오리진까지 가야 합니다.
- 오해: 애니캐스트는 항상 지리적으로 가장 가까운 서버로 연결한다. 실제: 라우팅 경로상 가까운 곳으로 가므로 지리적 거리와 다를 수 있습니다.
- 오해: 캐시가 문제면 퍼지만 하면 된다. 실제: 브라우저 캐시에 남은 사본은 CDN 퍼지로 지워지지 않습니다. 파일명에 버전을 넣는 방식이 둘 모두에 효과적입니다.
- 오해: CDN을 쓰면 DDoS 걱정이 없다. 실제: RFC 4786도 애니캐스트가 공격을 분산·한정할 수 있다고 설명하지만 모든 공격을 막는다는 뜻은 아니며, 오리진 주소가 노출되어 있으면 우회될 수 있습니다.
한계와 더 알아볼 점
CDN의 구체적인 캐시 키 구성, 퍼지 속도, 엣지 위치 수, 애니캐스트와 DNS 기반 라우팅의 비중은 서비스마다 다르고 수시로 바뀌므로 이 글의 일반 원리가 모든 서비스에 똑같이 적용되지는 않습니다. Cache-Control의 세부 해석, stale-while-revalidate 같은 확장 지시어, 엣지 컴퓨팅의 동작 방식은 이 글에서 깊이 다루지 않았으니 RFC 9111과 각 CDN의 공식 문서를 참고하세요.
웹사이트 로딩 속도를 더 개선하고 싶다면
CDN 외에도 이미지 최적화, 캐싱, 코드 압축 등 로딩 속도에 영향을 주는 다른 요소가 궁금하다면웹사이트 로딩 속도 개선 방법을 함께 확인해보세요.
여러 서버로 트래픽을 나누는 로드밸런싱도 함께 보면 좋아요
CDN이 지역별로 트래픽을 나눈다면, 같은 지역 서버들 사이에서 트래픽을 나누는 기술도 있습니다.로드밸런싱(부하 분산)이란? 기초 개념 정리에서 이어서 알아보세요.
자주 묻는 질문
CDN을 쓰면 원본 서버는 완전히 필요 없나요?
아닙니다. 캐시 미스가 발생하거나 캐싱할 수 없는 동적 콘텐츠를 처리할 때는 여전히 오리진 서버가 필요합니다. CDN은 오리진의 부담을 크게 줄여주는 역할이지, 오리진을 완전히 대체하지는 않습니다.
개인 블로그나 작은 사이트에도 CDN이 필요할까요?
트래픽이 적다면 체감 효과가 크지 않을 수 있지만, 이미지가 많거나 해외 방문자 비중이 높은 사이트라면 무료 플랜을 제공하는 CDN 서비스만으로도 로딩 속도와 보안(DDoS 방어) 측면에서 도움을 받을 수 있습니다.
CDN과 브라우저 캐시는 어떻게 함께 동작하나요?
오리진의 응답 헤더가 두 캐시 모두에 적용됩니다. 예를 들어 s-maxage는 CDN 같은 공유 캐시에만 적용되어 max-age와 따로 기간을 정할 수 있고, private는 브라우저만 저장하게 합니다(RFC 9111).
CDN에 옛날 파일이 남아 있을 때는 어떻게 하나요?
CDN 관리 화면에서 해당 파일이나 전체를 퍼지하거나, 파일명에 버전을 붙여 새 URL로 배포하는 방법이 일반적입니다. 퍼지 후에도 이용자 브라우저에 남은 사본은 해당 파일의 캐시 기간이 지나야 바뀔 수 있습니다.
CDN 장애가 나면 내 사이트에서 할 수 있는 일이 있나요?
공급자의 상태 페이지와 공지를 확인하는 것이 먼저입니다. 설계 차원에서는 오리진으로 직접 접근하는 대체 경로나 다른 공급자로 전환하는 계획을 평소에 준비해 두는 방법이 일반적으로 논의되지만, 비용과 복잡도가 늘어나므로 사이트의 중요도에 맞게 판단합니다.
이어 읽기
DNS 조회 과정, DDoS 공격 유형,HTTP 상태 코드를 함께 보면 CDN 앞뒤에서 일어나는 일이 더 선명해집니다.