네트워크 보안 | CDN이란?

 

CDN: 글로벌 서비스가 빨라지는 이유 🚀

요즘은 해외 사이트에 접속해도 로딩이 생각보다 빠른 편입니다.
넷플릭스 스트리밍이 크게 끊기지 않는 것도,

게임 클라이언트 패치가 몇십 GB씩 내려오는 것도

결국 뒷단에 CDN(Content Delivery Network)이 깔려 있기 때문입니다.

 

한 줄로 말하면, CDN은 이렇게 정리할 수 있습니다:

콘텐츠를 사용자 근처에서 제공해서 지연(latency)을 줄이는 네트워크 구조

구조 자체는 단순한데, 실제 서비스 운영에서는 체감 차이가 꽤 큽니다.

---

1. 왜 CDN이 필요한가? 🤔

인터넷은 마법이 아니라 물리적인 회선 위에서 움직입니다.

한국에서 미국 서부에 있는 서버로 요청을 보내면, 실제로 패킷은 여러 라우터를 거쳐 태평양을 건너갑니다.

이 과정에서 지연(latency)이 계속 누적됩니다.

문제는 대부분의 서비스가 이미 글로벌 사용자를 대상으로 하고 있다는 점입니다.

특히 아래 유형은 성능 요구사항이 더 빡셉니다:

• 스트리밍 서비스 (영상·음악) 🎬
• 대형 게임 패치 다운로드 🎮
• 이미지·정적 파일 다량 제공 🖼️
• 모바일 앱 백엔드 API 📱
• 세일·이벤트 시 폭주하는 트래픽 💥

이런 환경에서 Origin 서버만으로 모든 지역의 사용자 요구를 처리하려고 하면, 성능·안정성·비용 면에서 모두 부담이 커집니다.

그래서 CDN이 사실상 기본 인프라가 되었습니다.

---

2. CDN의 구성 요소 🧩

CDN은 크게 세 가지 요소로 나눠서 보면 이해가 쉽습니다.

2-1. Origin Server (원본 서버)

애플리케이션이나 콘텐츠의 원본이 저장된 곳입니다.

실제 비즈니스 로직, 원본 이미지/영상, HTML, API 응답 등이 여기서 만들어집니다.

2-2. POP(Point of Presence) / Edge 서버

전 세계 여러 지역에 분산된 CDN 지점입니다.

사용자와 지리적으로 가까운 POP에서 캐시된 콘텐츠를 대신 전달합니다. 예를 들면:

• 서울 POP
• 도쿄 POP
• 프랑크푸르트 POP
• 버지니아 POP

사용자는 보통 Origin까지 직접 가지 않고, 가장 가까운 POP에서 응답을 받습니다.

2-3. Control Plane (제어·정책·라우팅)

겉으로 잘 안 보이지만, CDN의 두뇌 역할입니다. 여기서 다음을 결정합니다:

• 어느 POP로 사용자를 라우팅할지 (DNS, Anycast, GSLB 등)
• 어떤 리소스를 얼마나 오래 캐시할지 (TTL, Cache Rule)
• 캐시를 언제 비울지 (Purge/Invalidation)
• HTTPS 종료 위치와 인증서 관리
• WAF, Rate Limiting, Bot 차단 같은 보안 정책

단순히 “POP 서버 여러 개”만 있다고 CDN이 되는 게 아니라, 이 제어 계층까지 합쳐져야 진짜 CDN이라고 볼 수 있습니다.

---

3. 동작 흐름 (기본 Flow) 🔄

CDN 동작은 크게 두 가지 케이스로 나눌 수 있습니다.

3-1. Cache Hit (캐시에 있을 때)

Client → Local POP → Response (캐시 있음)

 

이 경우가 가장 이상적인 상황입니다.

POP에 이미 동일 리소스가 캐시되어 있기 때문에 Origin까지 갈 필요 없이 바로 응답이 내려옵니다.

3-2. Cache Miss (캐시에 없을 때)

Client → Local POP → Origin → POP 캐시 저장 → Response

 

최초 요청 또는 TTL 만료 후 첫 요청일 때 이런 흐름이 발생합니다.

이때만 Origin까지 갔다가, 응답을 POP에 저장해두고 이후 요청은 POP에서 처리합니다.

---

4. 전체 시퀀스 흐름도 🧪

조금 더 실제 요청 단위로 쪼개면 다음과 같은 흐름으로 볼 수 있습니다.

[Client]
   │ 1. DNS 요청 (cdn.example.com?)
   ▼
[CDN Control Plane]
   │ 2. 가장 가까운 POP IP로 응답
   ▼
[Closest POP]
   │ 3-1. 캐시에 있으면 즉시 응답 (Cache Hit)
   │
   │ 3-2. 캐시에 없으면 Origin으로 요청 (Cache Miss)
   ▼
[Origin Server]
   │ 4. 콘텐츠 반환 (원본 데이터)
   ▼
[Closest POP]
   │ 5. 콘텐츠 캐시 저장 후 Client에게 반환
   ▼
[Client]
   │ 6. 빠른 응답 수신 (다음 요청은 POP에서 처리)

핵심 포인트는 하나입니다:

“Origin까지 가야 하는 요청 횟수를 최대한 줄인다.”

이 구조만으로도 서비스 체감 성능과 Origin 부담이 크게 달라집니다.

---

5. CDN이 만들어내는 효과 ✅

CDN이 가져오는 이점은 네 가지로 요약할 수 있습니다.

1. Latency 감소 ⏱️
   물리적인 거리가 줄어들지는 않지만, 사용자는 가까운 POP에서 응답을 받기 때문에 체감 응답 시간이 훨씬 짧아집니다.
2. Origin 서버 트래픽 감소 🧯
   정적 리소스, 반복 요청을 POP에서 소화하므로 Origin은 진짜 필요한 요청에만 집중할 수 있습니다.
3. 글로벌 성능 확보 🌍
   한국, 미국, 유럽, 동남아 등 다양한 지역에서 서비스 성능의 편차를 줄일 수 있습니다.
4. 비용 절감 💰
   서버 증설, 대역폭 비용을 줄일 수 있고, 같은 인프라로 더 많은 트래픽을 처리할 수 있습니다.

보안 측면에서의 추가 효과 🔐

최근 CDN은 단순 캐시 시스템을 넘어 엣지 보안 플랫폼 역할까지 수행합니다. 예를 들면:

• DDoS 방어 (대량 트래픽 흡수)
• WAF(Web Application Firewall) 연동
• Bot 탐지 및 차단
• API Rate Limiting
• Geo IP 기반 차단/제한

그래서 Cloudflare, Akamai, Fastly, CloudFront 같은 서비스들이 이제는 단순히 “CDN”이 아니라

Edge Platform이라는 표현을 더 많이 씁니다.

---

6. 어디에 쓰이고 있을까? 🔍

대부분 우리가 자주 쓰는 서비스들은 이미 CDN 위에서 돌아가고 있습니다.

• 영상 스트리밍 서비스 (Netflix, YouTube 등)
• 전자상거래 사이트 (대형 쇼핑몰)
• 게임 런처 및 패치 서버
• 이미지/정적 파일 제공 서버
• SaaS·웹 애플리케이션의 정적 리소스 및 API 엔드포인트

심지어 “웹페이지 UI 없이 API만 있는 서비스”도 요즘은 CDN을 붙입니다.

HTTP/HTTPS 기반 트래픽이라면, CDN의 이점을 가져갈 수 있기 때문입니다.

---

7. 정리 🧾

CDN의 핵심을 한 줄로 다시 정리하면:

“멀리 있는 Origin까지 굳이 가지 않고, 더 가까운 POP에서 콘텐츠를 제공하는 구조”

이 단순한 구조 덕분에 서비스는:

• 더 빠르고 🚀
• 더 안정적이고 🧱
• 더 저렴하게 운영 가능해집니다 💸

그래서 요즘 SaaS, 게임, 스트리밍, 커머스 기업들 입장에서는 “CDN을 쓴다 / 안 쓴다”의 문제가 아니라

“어떤 CDN/엣지 플랫폼을 어떤 구조로 붙일 것인가”가 더 중요한 고민이 되었습니다.