요즘 상담하다 보면 서버 사양은 낮은데 CDN만 비싼 상품으로 붙인 경우를 자주 봅니다. 반대로 이미지와 영상 파일이 많은 사이트인데도 웹서버 한 대가 모든 정적 파일을 직접 밀어내다가 느려지는 경우도 있고요. CDN은 만능 가속 버튼이 아닙니다. 어디에 병목이 있는지 보고 붙이면 비용을 줄이고 장애도 줄일 수 있습니다.
CDN이 필요한 구간부터 계산하기
CDN은 사용자의 요청을 원본 서버가 아니라 가까운 캐시 서버에서 처리하게 해주는 구조입니다. 특히 이미지, CSS, JS, 폰트, 다운로드 파일처럼 자주 바뀌지 않는 정적 파일에 효과가 큽니다. 그런데 방문자가 하루 300명이고 페이지당 이미지가 몇 장 안 되는 블로그라면 CDN보다 먼저 봐야 할 것은 서버 설정, 이미지 압축, 캐시 헤더입니다.
저는 보통 월 전송량부터 봅니다. 페이지 하나가 HTML 포함 3MB이고 하루 5천 페이지뷰면 하루 전송량은 약 15GB입니다. 한 달이면 450GB 정도죠. 이 정도부터는 웹호스팅 기본 트래픽 한도를 넘길 수 있고, VPS도 네트워크 비용이나 속도 제한을 확인해야 합니다. 반대로 페이지가 800KB이고 하루 1천 페이지뷰라면 월 24GB 수준입니다. 이 구간에서는 무료 CDN이나 호스팅 기본 캐시로도 충분한 경우가 많습니다.
- 월 전송량 50GB 이하: 이미지 최적화와 브라우저 캐시부터 점검
- 월 전송량 50~500GB: 무료 또는 저가 CDN을 붙이면 체감 효과가 있음
- 월 전송량 500GB 이상: 캐시 적중률, 원본 보호, 초과 요금까지 같이 계산
- 대용량 다운로드 중심: 요청 수보다 전송량 단가를 먼저 비교
캐시 정책을 못 잡으면 돈만 나갑니다
CDN을 붙였는데 서버 부하가 그대로인 경우가 있습니다. 대부분 캐시 정책이 비어 있거나, 동적 페이지까지 억지로 캐시하려다 우회가 많아진 경우입니다. CDN은 정적 파일에 긴 캐시 시간을 주고, 로그인 페이지나 장바구니 같은 개인화 페이지는 건드리지 않는 식으로 나눠야 합니다.
예를 들어 상품 이미지 주소가 매번 같고 파일 내용만 바뀌는 구조라면 문제가 생깁니다. CDN은 예전 이미지를 계속 보여줄 수 있습니다. 이때는 파일명에 버전 값을 붙이는 방식이 안정적입니다. logo.png를 계속 덮어쓰는 것보다 logo-v3.png처럼 새 파일로 배포하는 쪽이 운영 사고가 적습니다.
실무에서 자주 쓰는 기준
- 이미지, CSS, JS: 7일에서 30일 이상 캐시
- HTML 문서: 사이트 성격에 따라 짧게 두거나 캐시 제외
- 관리자, 로그인, 결제: 캐시 제외
- API 응답: 공개 데이터만 짧게 캐시하고 사용자별 응답은 제외
- 파일 교체 방식: 같은 이름 덮어쓰기보다 버전 파일명 사용
사실 CDN 장애보다 캐시 실수가 더 많이 납니다. 새로 올린 이미지가 안 보인다, CSS 수정이 반영되지 않는다, 로그인한 사람에게 다른 사람 화면이 보인다 같은 사고는 대개 캐시 구분을 대충 했을 때 생깁니다. 속도보다 먼저 안전한 제외 규칙을 잡아야 합니다.
원본 서버를 보호하는 설정
CDN을 붙이면 사용자는 CDN으로 접속하지만, 원본 서버가 완전히 숨는 것은 아닙니다. 원본 IP가 노출되어 있으면 공격이나 대량 요청이 CDN을 우회해서 바로 들어올 수 있습니다. 그래서 운영에서는 CDN 적용 후에도 방화벽, 접근 제한, 백업 경로를 같이 봅니다.
가능하면 원본 서버는 CDN 사업자의 IP 대역에서 오는 요청만 받게 제한합니다. 관리 페이지는 별도 주소나 VPN, IP 제한을 두는 편이 좋습니다. 작은 사이트라도 관리자 로그인 화면이 공개되어 있으면 자동 공격 로그가 금방 쌓입니다. 트래픽 문제인 줄 알았는데 실제로는 로그인 공격 때문에 CPU가 올라가는 경우도 꽤 있습니다.
- 원본 서버 방화벽에서 CDN 경유 요청만 허용
- 관리자 페이지는 IP 제한 또는 추가 인증 적용
- 실제 방문자 IP가 로그에 남도록 헤더 설정 확인
- CDN 장애 시 원본으로 임시 전환할 절차 준비
- DNS 변경 권한과 계정 복구 수단을 따로 보관
로그도 중요합니다. CDN 뒤에 서버를 두면 웹서버 로그에는 CDN 서버 IP만 찍히는 경우가 있습니다. 이 상태로 방치하면 장애 분석이 어려워집니다. 실제 방문자 IP를 기록하도록 웹서버 설정을 맞춰야 차단, 통계, 보안 분석이 가능합니다.
무료 CDN과 유료 CDN을 나누는 기준
무료 CDN이 나쁘다는 뜻은 아닙니다. 개인 블로그, 소규모 쇼핑몰, 회사 소개 사이트, 트래픽이 일정한 콘텐츠 사이트는 무료나 저가 상품으로도 충분한 구간이 많습니다. 제가 과하게 쓰지 말라고 하는 이유도 여기에 있습니다. 월 30GB 쓰는 사이트에 고급 엔터프라이즈 기능을 붙이는 건 대개 낭비입니다.
유료 CDN이 필요한 순간은 조금 다릅니다. 해외 방문자가 많거나, 대용량 파일 전송이 많거나, 캐시 규칙을 세밀하게 나눠야 하거나, 장애 대응 SLA가 필요한 경우입니다. 특히 매출이 걸린 쇼핑몰은 단순 속도보다 장애 대응과 로그 확인 범위가 중요합니다. CDN이 막혔을 때 누구에게 연락하고, 어떤 설정을 되돌릴지 정해져 있어야 합니다.
비교할 때 보는 항목
- 월 전송량 단가와 초과 요금
- 요청 수 과금 여부
- 한국과 주요 접속 국가의 응답 속도
- 캐시 무효화 속도와 횟수 제한
- 방화벽, 봇 차단, DDoS 방어 포함 여부
- 로그 제공 범위와 보관 기간
가격표만 보면 싸 보이는데 요청 수 과금이 붙어서 예상보다 많이 나오는 상품도 있습니다. 작은 이미지가 수백 개씩 로딩되는 사이트라면 전송량보다 요청 수가 문제가 됩니다. 반대로 영상이나 설치 파일은 요청 수보다 GB 단가가 중요합니다. 사이트 유형에 따라 계산 기준이 바뀝니다.
CDN 적용 순서
운영 중인 사이트에 CDN을 붙일 때는 한 번에 전체를 넘기지 않는 편이 안전합니다. 먼저 이미지와 정적 파일 경로만 CDN으로 빼고, 문제가 없으면 CSS와 JS까지 확대합니다. HTML 캐시는 가장 나중에 검토합니다. 로그인, 검색, 장바구니, 게시판처럼 사용자 상태가 섞이는 기능은 특히 조심해야 합니다.
- 현재 월 전송량과 피크 시간대 트래픽 확인
- 이미지 압축과 웹서버 캐시 헤더 먼저 적용
- 정적 파일만 CDN 경유로 전환
- 캐시 적중률과 원본 서버 요청 감소 확인
- 관리자, 로그인, 결제, API 제외 규칙 점검
- 장애 시 DNS 복구 절차와 백업 접속 경로 문서화
CDN을 붙인 뒤에는 속도 측정만 보면 부족합니다. 원본 서버 요청 수가 줄었는지, 404나 500 에러가 늘지 않았는지, 이미지 교체가 정상 반영되는지 같이 봐야 합니다. 캐시 적중률이 낮다면 CDN은 앞에서 트래픽만 한 번 더 통과시키는 장식이 됩니다.
제 기준에서는 CDN은 서버 증설보다 먼저 검토할 만한 도구입니다. 다만 계산 없이 붙이면 비용 구조가 흐려지고, 설정 없이 붙이면 장애 지점이 하나 더 늘어납니다. 트래픽이 늘어날수록 비싼 서버를 먼저 고르는 것보다 정적 파일을 밖으로 빼고, 원본을 보호하고, 백업 절차를 확인하는 쪽이 오래 갑니다. 싼 구성으로도 안정적인 사이트는 충분히 만들 수 있습니다.
