CDN

서울에 있는 원본 서버에서 뉴욕 사용자에게 이미지와 스크립트를 직접 보내면, 파일이 작아도 지리적 거리 때문에 왕복 지연이 100~200ms씩 쌓입니다. 인기 있는 정적 자산을 수천 명이 반복해서 요청하면 원본 서버는 같은 파일을 계속 다시 보내느라 불필요한 부하를 떠안습니다. 특정 리전 원본만 믿고 있으면 그 리전에 장애가 생길 때 전체 사용자 경험도 함께 흔들립니다. 결국 문제는 단순한 서버 성능이 아니라, 똑같은 콘텐츠를 먼 곳에서 반복해서 전달하는 구조 자체에 있습니다. CDN은 이 구조를 바꿔 사용자가 원본까지 가지 않아도 되도록 만드는 전달망입니다.

인터넷 사용자가 지역적으로 넓게 퍼지고, 대용량 이미지와 동영상, 다운로드 파일이 늘어나던 시기에는 원본 서버 한 곳에서 모든 요청을 감당하는 방식이 점점 비효율적이 됐습니다. 대역폭 비용은 높았고, 인기 콘텐츠 하나가 몰리면 원본 서버가 병목이 되거나 다운되기 쉬웠습니다. 그래서 자주 요청되는 데이터를 사용자 가까이 복제해 두는 분산 캐시 네트워크가 중요한 인프라로 떠올랐습니다. CDN은 처음에는 정적 파일 가속이 핵심이었지만, 이후 보안 필터링, 동적 콘텐츠 최적화, 엣지 컴퓨팅까지 역할이 넓어졌습니다. 그래도 본질은 여전히 같아서, 멀리 있는 원본에 매번 직접 가지 않게 만드는 구조적 최적화가 핵심입니다.

CDN은 원본 서버 앞단에 전 세계 엣지 서버를 두고, 자주 요청되는 콘텐츠를 그 엣지에 캐시합니다. 사용자의 요청은 Anycast 라우팅을 통해 물리적으로 더 가까운 엣지로 유도되고, 해당 엣지에 캐시가 있으면 원본까지 가지 않고 바로 응답합니다. 캐시가 없으면 엣지가 원본에서 콘텐츠를 가져와 사용자에게 전달하고, 다음 요청을 위해 일정 기간 저장합니다. 이때 무엇을 얼마나 오래 저장할지는 `Cache-Control`과 TTL, 무효화 정책으로 제어합니다. CDN은 단순한 복사본 저장소가 아니라, 요청 경로와 캐시 정책을 함께 운영하는 지리적 분산 계층으로 이해해야 합니다.

CDN과 로드 밸런서는 모두 트래픽 앞단에 위치할 수 있지만 해결하려는 문제가 다릅니다. CDN은 사용자와 원본 사이의 물리적 거리를 줄이고, 반복되는 콘텐츠 요청을 엣지 캐시에서 처리해 전 세계 지연과 원본 부하를 낮춥니다. 로드 밸런서는 보통 하나의 리전이나 서비스 경계 안에서 여러 서버 복제본으로 요청을 나누고 장애를 흡수하는 데 집중합니다. CDN은 '콘텐츠를 어디에서 줄 것인가'에 가깝고, 로드 밸런서는 '같은 서비스를 어떤 백엔드가 처리할 것인가'에 가깝습니다. 대규모 서비스가 둘을 함께 쓰는 이유는 지리적 분산 문제와 백엔드 분산 문제가 서로 다른 층위이기 때문입니다.

CDN은 이미지, 동영상, CSS, JavaScript, 문서 다운로드처럼 많은 사용자가 반복해서 요청하는 콘텐츠를 전 세계에 빠르게 전달할 때 효과적입니다. 글로벌 서비스에서 첫 화면 로딩 속도를 개선하고 원본 서버 부하를 줄이는 데도 큰 도움이 됩니다. 반면 사용자마다 응답 내용이 크게 달라지는 개인화 페이지나, 인증 상태에 따라 결과가 바뀌는 민감한 동적 응답은 캐시 전략을 더 세심하게 설계해야 합니다. 잘못 캐시하면 최신 변경이 늦게 반영되거나 의도하지 않은 응답이 재사용될 수 있습니다. CDN을 잘 운영하는 핵심은 캐시를 많이 켜는 것이 아니라, 무엇을 엣지에 두고 무엇은 원본에서 처리할지 경계를 분명히 잡는 데 있습니다.