현대의 웹·모바일 서비스는 속도와 안정성이 생명입니다. 그렇기 때문에 전 세계 사용자에게 빠르게 콘텐츠를 전달하기 위해 우리는 CDN(Content Delivery Network, 콘텐츠 전송 네트워크)을 인프라 구성의 필수요소로 다룹니다! 너무 필수적이지만 우리는 CDN의 정확한 개념이 뭔지 Origin Server며 Edge Server, Edge Location이 뭔지 매번 학습하고도 잊어버리는 경우가 많습니다. 이번 포스팅에서 CDN의 개념과 동작 방식의 흐름을 이해하고 Origin Server와 Edge Server가 어떤 차이를 갖는지 살펴봅시다.
CDN은 Content Delivery Network이다.
말 그대로 콘텐츠를 배달하는 네트워크라고 생각하면 조금 쉽습니다. CDN은 전 세계에 분산된 여러 데이터 센터( 엣지 로케이션, Edge Location )에 Origin Server의 콘텐츠 ( 정적 파일, 동적 페이지, API 응답 등등)를 복제, 캐싱(Cache)해 놓고, 사용자 요청이 들어오면 지리적으로 가정 가까운 엣지 로케이션에서 응답을 제공하는 네트워크 입니다.
왜 CDN이 필요했을까?
인터넷 사용이 글로벌화되면서 멀~리 있는 사람들까지 지연없이 컨텐츠를 제공하기 위해 CDN이 필요해졌습니다.
- 지연 시간(Latency)의 감소 - 오리진 서버와 물리적으로 떨어진 지역에서 요청 시 왕복 시간이 길어져 웹 페이지 로딩 속도가 느려짐
- 트래픽 부하 분산 - 대규모 행사나 프로모션 등으로 트래픽 급증 시 오리진 서버가 과부하되는 문제
- 가용성(Availability) 보장 - 특정 리전 장애 발생 시에도 다른 엣지 로케이션이 트래픽을 처리
그럼 CDN의 동작 방식이 뭘까?
CDN의 동작 방식을 이해하려면 Origin Server, Edge Location, Edge Server와 같은 개념을 이해해야합니다.
| Origin Server | Edge Server | Edge Location |
| 원본 콘텐츠가 저장되는 중앙 서버 | CDN 사업자가 전 세계에 구축한 데이터 센터 지점 | 각 엣지 로케이션에 배치된 캐시 서버. 캐싱, TLS 종료, 동적 콘텐츠 최적화와 같은 역할을 함. |
|
사용자와 물리적으로 가까운 곳에 위치해 요청 응답 속도 최적화를 목적으로 함 |
|
🧩 Origin Server vs Edge Server
Origin Server와 Edge Server의 차이와 함께 개념을 한번 더 집고간다면 본사와 지사 정도로 이해할 수 있습니다.
- Origin Server는 원본 데이터를 관리하는 곳으로, 실시간 업데이트와 권한 관리가 필수적입니다.
- Edge Server는 빠른 응답과 부하 분산이 핵심으로, 캐시 정책과 만료(Rule)를 적절히 설계해야 합니다.
| Origin Server | Edge Server | |
| 위치 | 중앙 데이터 센터 혹은 클라우드 리전 | 전 세계 여러 엣지 로케이션 |
| 주요 역할 | 콘텐츠 생성, 관리, 업데이트 | 캐시된 콘텐츠 제공, TLS 종료, 프래픽 분산 |
| 데이터 최신성 | 항상 최신 상태 | 캐시 만료 정책에 따라 일정 기간 지연 가능 |
| 스케일링 | 중앙 집중형 오토스케일링 필요 | 수평적 분산 아키텍처로 자동 확장 (클라우드 CDN) |
| 보안/제어 | 방화벽, WAF 등 종합 보안 설정 | 제한된 캐시 정책 설정, WAF 연동 |
| 오리진 부하 | 모든 콘텐츠 요청 처리 | 캐시 히트를 통해 부하 대폭 경감 |
🧩 CDN 동작 흐름
- 사용자 요청
- 브라우저가 https://example.com/style.css 요청
- DNS 라우팅
- DNS는 사용자의 지리적 위치를 기준으로 가장 가까운 엣지 로케이션(Edge Location)의 IP를 반환
- Edge Server 접속
- 사용자 → Edge Server
- 캐시 확인 (Cache Lookup)
- Cache Hit: 스타일시트가 이미 캐시에 존재 → 즉시 응답
- Cache Miss: 캐시에 없으면 5번으로 진행
- Origin Server 요청
- Edge Server → Origin Server(origin.example.com)
- 콘텐츠 받아오기
- Origin이 스타일시트를 전송
- 캐싱 및 사용자 응답
- Edge Server가 받은 스타일시트를 로컬에 저장(cache)
- 사용자에게 콘텐츠 전달
- 추가 요청 처리
- 동일한 요청이 다시 들어올 경우 4번의 Cache Hit 경로로 매우 빠르게 처리
sequenceDiagram
participant User
participant DNS
participant EdgeServer
participant OriginServer
User->>DNS: example.com DNS 질의
DNS-->>User: 가장 가까운 EdgeServer IP
User->>EdgeServer: GET /style.css
alt 캐시 존재 (Cache Hit)
EdgeServer-->>User: style.css (캐시된 응답)
else 캐시 없음 (Cache Miss)
EdgeServer->>OriginServer: GET /style.css
OriginServer-->>EdgeServer: style.css
EdgeServer-->>User: style.css
end
🧩 CDN 없이는 인터넷도 못써.. 그래서 CDN은 무슨 역할을 하는데?
과거에 해외사이트에 접속하면 로딩이되는데 한참 걸리거나 버튼하나 클릭해도 오래 로딩이 되는 경험을 한적이 있습니다. 하지만 요즘은 유튜브나 미디엄(Medium) 등등 해외 도메인을 가진 서비스를 이용한 것은 우리에게 너무나 당연하게 느껴집니다. CDN 덕분에 오래걸리지않고 이용할 수 있는 것이니까요!
1. 웹 정적 콘텐츠 가속
- 이미지, CSS, JavaScript 파일, 폰트 등을 CDN에 올려두면 전 세계 어디서나 빠른 로딩
- Netflix, YouTube, Instagram 등 대규모 스트리밍 서비스도 정적 자산은 CDN 활용
2. 동영상 스트리밍
- HLS/DASH 세그먼트 파일을 엣지에 캐시해 끊김 없는 재생 제공
- Adaptive Bitrate 스트리밍 시 특정 화질 세그먼트만 캐시하거나, 수요 지역별로 분산
3. API 가속 및 보안
- REST/GraphQL API 응답 캐싱(짧은 TTL 설정)으로 응답 속도 향상
- WAF(Web Application Firewall)를 CDN 레이어에 연동해 악성 요청 차단
5. 글로벌 웹 애플리케이션
- 싱가포르 본사 웹 사이트를 서울, 런던, 뉴욕 엣지에서 운영해 사용자 경험 통일
- 글로벌 쇼핑몰, 금융 서비스 등 고객 신뢰도가 중요한 서비스에 필수
7. 캐시 전략 및 운영 팁
- TTL(Time To Live) 설정
- 자주 바뀌지 않는 정적 자산: 긴 TTL(예: 1주일 이상)
- 자주 업데이트되는 파일: 짧은 TTL(수분~1시간)
- Cache Invalidation
- 자산 버전 관리(파일명 해시) → 배포 시마다 새로운 URL 제공
- API 리턴 값에 Cache-Control: no-cache 활용
- 프리페칭(Prefetch)과 프리워밍(Prewarm)
- 중요 리소스를 미리 캐시에 적재해 첫 사용자에도 빠른 응답 보장
- 모니터링 및 로깅
- Cache Hit/Miss 비율, 레이턴시(metrics)를 꾸준히 모니터링
- 이상 트래픽 탐지 시 WAF 룰 조정
마무리
CDN은 단순히 서버를 분산시킨 캐시망이 아니라, 대규모 트래픽에서도 안정적인 서비스를 제공하는 인프라입니다.
- Origin Server는 콘텐츠의 원본 관리하는 서버
- Edge Server는 지리적으로 분산된 캐시 계층으로 속도와 안정성 서버
적절한 캐싱 전략과 모니터링 체계를 구축하면, 직접 서버부하를 다루지않고도 오리진 서버의 부하를 크게 줄이면서도 사용자에게 빠른 서비스를 제공할 수 있습니다.
참고 자료
- AWS CloudFront: https://aws.amazon.com/cloudfront/
- Fastly: https://www.fastly.com/
- Cloudflare: https://www.cloudflare.com/