CDN은 단일 장애점이다

CDN은 웹을 더 튼튼하게 만들어 줄 거라고 했다.

좁은 의미에서는 맞다. 트래픽을 흡수하고, 콘텐츠를 사용자 가까이에 캐싱하고, 오리진 장애를 가려 주고, 혼자였으면 부하에 무너졌을 사이트를 지켜 준다. 오리진이 죽어도 캐시가 계속 응답하면 CDN은 영웅처럼 보인다.

그러다 CDN 자신에게 나쁜 날이 온다.

그 순간 영웅이 곧 피해 반경이 된다.

쏠림은 은근하지 않다

몇 안 되는 CDN 회사가 웹 트래픽의 엄청난 비중 앞에 서 있다. Cloudflare 한 곳이 프록시하는 도메인만 수백만 개다. Akamai, Fastly, Amazon CloudFront가 나머지 중 큰 몫을 나눠 갖는다. CDN은 규모의 경제가 엄청난 사업이라 시장이 빠르게 몰렸다. 엣지 노드가 많을수록 성능이 좋고, 성능이 좋을수록 고객이 늘고, 고객이 늘수록 엣지 노드가 는다.

그 결과 인터넷의 상당 부분이 서너 개 회사의 인프라가 멀쩡하기를 기대며 돌아간다.

내려가면 모두가 안다

2021년 6월, 한 고객의 설정 변경이 Fastly의 숨은 버그를 건드렸다. 한 시간 가까이 Reddit, 뉴욕타임스, 영국 정부 사이트, Amazon, Twitch, Stack Overflow 같은 큰 사이트들이 열리지 않았다. 느려진 게 아니라 사라졌다. 사이트를 지켜야 할 엣지가 사이트를 쓰러뜨린 장본인이 됐다.

Cloudflare도 비슷한 일을 겪었다. 2022년 6월에는 가장 바쁜 데이터센터들의 BGP 경로 광고 방식을 바꾸다 실수해 19곳이 한 시간 넘게 멈췄다. 이 19곳이 Cloudflare 전체 요청의 절반가량을 처리하던 곳이었다. 2025년 11월에는 데이터베이스 권한 변경 하나 때문에 봇 관리 설정 파일 크기가 두 배로 불었고, 핵심 프록시가 이 파일을 처리하지 못해 ChatGPT부터 X까지 수많은 사이트가 세 시간가량 오류를 냈다. Cloudflare는 사후 분석 보고서를 놀라울 만큼 투명하게 공개한다. 이런 세부 사항을 우리가 아는 것도 그 덕분이다.

가정이 아니다. 주기적으로 일어난다. 이제 CDN 한 곳의 장애가 미치는 범위는 개별 사이트 장애가 낼 수 있는 피해를 한참 넘어선다.

아이러니

CDN은 오리진 장애에 대한 회복력을 더해 준다. 서버가 죽으면 CDN이 캐시를 내준다. 서버가 DDoS를 맞으면 CDN이 흡수한다. “오리진이 부하를 감당하지 못한다”는 특정 장애에 대해서는 CDN이 탁월하다.

하지만 CDN은 다른 장애를 끌어들인다. “CDN 자체가 실패한다”는 장애다. 수많은 사이트가 같은 CDN을 쓰니 이 장애는 서로 연동된다. Fastly가 내려가면 한 사이트가 아니라, 서로 아무 관계 없는 사이트 수천 개가 같은 이유로 한꺼번에 내려간다.

CDN이 몰리기 전의 인터넷에서는 장애가 서로 무관했다. 내 사이트가 죽어도 당신 사이트는 멀쩡했다. 서버도, 네트워크도, DNS도 달랐다. 장애가 날 수 있는 지점이 흩어져 있었다.

지금의 인터넷에서는 장애가 함께 온다. 내 사이트와 당신 사이트, 그리고 다른 만 개의 사이트가 같은 CDN을 골랐다는 이유로 동시에 죽는다. 성능을 얻고 독립성을 잃었다.

DNS가 문제를 키운다

많은 사이트가 DNS를 곧바로 CDN 인프라로 향하게 해 둔다. 도메인의 A 레코드(또는 CNAME)가 Cloudflare 엣지를 가리킨다. Cloudflare DNS가 내려가거나 엣지 IP가 응답을 멈추면 도메인 이름 자체가 풀리지 않는다. 느려지는 게 아니라 사라진다.

전통적인 구성이라면 오리진이 죽었을 때 DNS를 다른 곳으로 돌리면 된다. CDN이 DNS까지 맡은 구성에서는 DNS가 곧 CDN이다. 돌아갈 곳이 없다. 이름 풀이도, 콘텐츠 전송도, DDoS 방어도, SSL 종료도 전부 CDN이 한다. 업체 하나, 청구서 하나, 장애점 하나.

멀티 CDN은 있지만 쓰는 곳은 드물다

뻔한 해법은 여러 CDN을 두고 DNS로 장애 조치(failover)를 하는 것이다. Cloudflare가 내려가면 트래픽을 Fastly로 보낸다. 세련되고 튼튼하다.

CDN 이중화가 실제로 요구하는 건 이렇다. 두 CDN이 같은 오리진에서 콘텐츠를 가져온다. DNS는 두 CDN 중 어느 쪽도 아닌 별도 업체에 둔다. 장애 난 CDN이 DNS까지 맡고 있으면 장애 조치를 할 수단 자체가 없어지기 때문이다. 그 DNS 업체가 두 CDN의 상태를 계속 확인해 응답하는 쪽으로 트래픽을 보내고, 리졸버가 전환을 빨리 반영하도록 레코드 TTL은 1분 안팎으로 짧게 둔다. 두 CDN 모두 내 호스트 이름에 맞는 유효한 인증서가 있어야 하고, 캐시 규칙·리다이렉트·WAF 정책도 똑같아야 한다. 그렇지 않으면 사용자가 어느 CDN에 닿느냐에 따라 다른 사이트를 보게 된다.

복잡하고 비싸지는 건 바로 이 마지막 부분이다. 멀티 CDN을 하려면 여러 업체에 걸쳐 캐시 무효화를 관리하고, SSL 인증서를 맞추고, 서로 다른 설정 API를 다루고, CDN 청구서를 두 장 내야 한다. 대기업이라면 감당할 만한 비용이다. 인터넷 대부분을 이루는 수백만 개의 중소 사이트에게는 1년에 몇 시간 일어나는 사건을 대비하기엔 과하다.

합리적인 계산은 위험을 받아들이는 것이다. 1년에 몇 시간의 CDN 장애가 멀티 CDN 엔지니어링 비용보다 싸다. 맞는 계산이다. 그리고 쏠림이 계속 심해지는 이유이기도 하다. 개인으로서는 합리적인 선택이 모이면 집단 전체가 취약해진다.

클라우드와 같은 그림

클라우드 컴퓨팅도 같은 패턴이다. AWS, Azure, GCP는 수천 개 독립 데이터센터에 흩어져 있던 컴퓨팅 자원을 한곳으로 모았다. us-east-1에 문제가 생기면 인터넷의 눈에 띄는 일부가 버벅거린다.

CDN은 콘텐츠 전송에서 같은 일을 했다. 인터넷은 원래 그물망이었다. 지금은 점점 허브 몇 개에 바큇살이 매달린 구조가 되고 있고, 그 허브는 세 회사다.

무엇이 바뀌어야 하나

솔직히? 아마 아무것도 안 바뀔 것이다. 경제 논리가 너무 강하다. CDN은 자기 일을 정말 잘한다. 성능 향상도, DDoS 방어도, 운영 편의도 진짜다.

하지만 업계는 이 거래에 대해 솔직해야 한다. 우리는 회복력 대신 성능과 편리함을 골랐다. CDN 하나 뒤에 있는 모든 사이트는 그 CDN의 가동 시간에 말없이 기대고 있다. Cloudflare 비즈니스 요금제 SLA는 100% 가동을 약속하고, 지키지 못하면 서비스 크레딧으로 보상한다. 현실은, 그 약속이 깨지는 날엔 모두에게 한꺼번에 깨진다는 것이다.

다음번에 CDN 하나가 내려가 인터넷 절반이 멈추면 기억하자. 이건 선택이었다. 합리적인 선택이었을 수도 있다. 하지만 사고가 아니라 선택이었다. 우리는 속도를 위해 웹을 중앙화했고, 그 대가를 취약함으로 치렀다.