얼마 전 작은 쇼핑몰 운영자와 서버 비용을 봤는데, 월 방문자가 8만 명 정도인데도 클라우드 서버를 세 대로 늘릴 생각을 하고 있었습니다. 실제로 로그를 보니 병목은 서버 CPU가 아니라 이미지였습니다. 상품 사진, 배너, 자바스크립트 파일이 전체 전송량의 82%를 차지했죠. 이런 경우에는 서버를 키우는 것보다 CDN을 붙이는 쪽이 싸고 안정적입니다.
CDN은 방문자 가까운 위치의 캐시 서버에서 이미지, CSS, 자바스크립트 같은 파일을 내려주는 구조입니다. 원본 서버는 모든 요청을 직접 처리하지 않아도 됩니다. 그런데 모든 사이트에 무조건 필요한 건 아닙니다. 트래픽이 작고 이미지도 적은 블로그라면 기본 웹호스팅만으로 충분한 경우가 많습니다.
CDN이 필요한 구간부터 계산하기
저는 CDN 적용 여부를 볼 때 월 방문자 수보다 전송량과 동시접속을 먼저 봅니다. 방문자가 많아도 페이지가 가볍다면 버팁니다. 반대로 방문자가 적어도 사진 한 장이 3메가바이트씩이면 금방 한계가 옵니다.
계산은 단순하게 시작하면 됩니다. 한 페이지를 열 때 내려가는 파일 용량을 재고, 하루 페이지뷰를 곱합니다. 예를 들어 한 페이지가 4메가바이트이고 하루 1만 페이지뷰라면 하루 전송량은 약 40기가바이트입니다. 월로 보면 1.2테라바이트 수준입니다. 이 정도면 저가 웹호스팅에서 트래픽 제한에 걸리거나 속도 제한을 만날 수 있습니다.
대략적인 판단 기준
- 월 전송량 50기가바이트 이하: 일반 웹호스팅이나 기본 VPS로도 충분한 경우가 많습니다.
- 월 전송량 100~500기가바이트: 이미지가 많다면 CDN 적용 효과가 보이기 시작합니다.
- 월 전송량 1테라바이트 이상: 서버 증설보다 CDN 비용을 먼저 계산하는 편이 낫습니다.
- 해외 접속 비중이 20% 이상: 국내 서버만 두는 것보다 CDN 체감 속도가 커질 수 있습니다.
사실 CDN은 트래픽을 줄인다기보다 원본 서버가 직접 감당하는 트래픽을 줄입니다. 이 차이를 알아야 합니다. 사용자는 여전히 파일을 내려받고, 비용도 어딘가에서는 발생합니다. 다만 원본 서버의 디스크, 네트워크, 웹서버 프로세스가 덜 바빠지는 겁니다.
처음에는 정적 파일만 빼는 게 안전합니다
처음 CDN을 붙일 때 전체 사이트를 한 번에 태우는 건 권하지 않습니다. 특히 로그인, 장바구니, 주문, 관리자 화면까지 CDN 뒤에 넣으면 캐시 규칙 하나 때문에 개인정보나 잘못된 화면이 노출될 수 있습니다. 실제 장애는 고급 기능보다 이런 기본 설정에서 더 자주 납니다.
처음 적용할 대상은 이미지, CSS, 자바스크립트, 폰트 파일 정도면 충분합니다. 게시글 본문 HTML이나 로그인 페이지는 원본 서버에서 직접 처리하게 둡니다. 블로그라면 썸네일과 첨부 이미지만 CDN으로 빼도 체감 속도와 서버 부하가 꽤 달라집니다.
- 이미지 파일: 캐시 기간을 길게 잡기 좋습니다.
- CSS와 자바스크립트: 파일명에 버전값을 붙이면 오래 캐시해도 안전합니다.
- 폰트 파일: 반복 방문자가 많을수록 효과가 있습니다.
- HTML 문서: 초기에 캐시하지 않는 편이 사고가 적습니다.
파일명이 바뀌지 않는데 내용만 바꾸는 운영 방식이면 CDN 캐시가 늦게 갱신됩니다. 그래서 배포할 때 파일명에 날짜나 해시값을 붙이는 방식이 좋습니다. 예를 들어 스타일 파일을 수정할 때 기존 파일을 덮어쓰지 말고 새 이름으로 배포하면 캐시 삭제를 기다릴 일이 줄어듭니다.
캐시 시간은 길수록 좋은 게 아닙니다
CDN 설정에서 가장 흔한 실수는 모든 파일의 캐시 시간을 길게 잡는 겁니다. 이미지처럼 거의 안 바뀌는 파일은 길게 잡아도 됩니다. 하지만 자주 바뀌는 스크립트나 이벤트 배너를 길게 잡으면 운영자가 수정해도 방문자에게 예전 화면이 계속 보입니다.
저는 보통 파일 성격별로 나눕니다. 상품 이미지나 로고는 7일 이상, CSS와 자바스크립트는 파일명 버전 관리가 된다면 30일 이상도 가능합니다. 반대로 이벤트 이미지처럼 자주 교체되는 파일은 1시간에서 하루 정도로 짧게 둡니다. 관리자 화면, 로그인 응답, 장바구니 관련 요청은 캐시 금지로 둡니다.
또 하나 조심할 건 쿠키입니다. 쿠키가 붙은 요청을 CDN이 어떻게 처리하는지 확인해야 합니다. 회원별로 다른 화면을 보여주는 사이트에서 쿠키를 무시하고 캐시하면 다른 사람의 화면이 섞여 보일 수 있습니다. 서버 인프라 일을 오래 하다 보면, 이런 사고는 트래픽 폭주보다 복구가 더 피곤합니다.
비용은 전송량보다 요청 수까지 봐야 합니다
CDN 요금은 보통 전송량 기준으로 많이 보지만, 실제 청구 구조에는 요청 수, 지역, 보안 기능, 로그 저장 비용이 붙는 경우가 있습니다. 이미지 한 장이 큰 사이트는 전송량이 비용을 좌우하고, 작은 아이콘 파일이 수백 개씩 쪼개진 사이트는 요청 수가 생각보다 큽니다.
예를 들어 월 300기가바이트를 전송하는 블로그라면 CDN 비용은 큰 부담이 아닐 수 있습니다. 그런데 페이지마다 작은 파일 120개를 부르면 방문자 10만 명 기준으로 요청 수가 1,200만 건까지 올라갑니다. 이럴 때는 CDN만 붙일 게 아니라 파일 병합, 이미지 압축, 불필요한 스크립트 제거를 같이 해야 합니다.
싼 요금제가 나쁘다는 뜻은 아닙니다. 오히려 월 100기가바이트 안쪽 블로그는 무료 구간이나 저가형으로 충분한 경우가 많습니다. 다만 무료 구간은 캐시 삭제 횟수, 보안 기능, 로그 확인 범위가 제한될 수 있습니다. 장애 때 로그가 없으면 원인을 찾는 시간이 길어집니다.
장애가 나면 CDN을 바로 끄기 전에 확인할 것
사이트가 이상해졌을 때 CDN을 끄면 원인이 사라진 것처럼 보일 때가 있습니다. 하지만 실제로는 원본 서버 설정, SSL 인증서, 캐시 규칙, 리다이렉트가 얽힌 문제일 수 있습니다. 순서를 잡고 봐야 시간이 덜 낭비됩니다.
- 원본 서버에 직접 접속했을 때 정상 응답이 나오는지 확인합니다.
- SSL 인증서가 원본 서버와 CDN 양쪽에서 모두 유효한지 봅니다.
- 캐시된 파일과 원본 파일의 내용이 같은지 비교합니다.
- 리다이렉트가 반복되는지 확인합니다.
- 특정 지역이나 통신사에서만 느린지 로그와 모니터링으로 나눠 봅니다.
특히 SSL 설정은 자주 사고가 납니다. 원본 서버는 일반 연결만 열어두고 CDN에서만 보안 연결을 쓰게 만들면, 설정 조합에 따라 무한 이동이 생길 수 있습니다. 서버에서 보안 연결을 강제하고 CDN도 같은 규칙을 밀어 넣으면 요청이 계속 돌기도 합니다. 이런 문제는 서버 증설로 해결되지 않습니다.
CDN은 서버를 대체하는 물건이 아니라, 원본 서버가 덜 맞도록 앞에서 충격을 받아주는 장치에 가깝습니다. 그래서 먼저 내 사이트의 파일 크기, 월 전송량, 로그인 여부, 캐시 가능한 비율을 계산해야 합니다. 숫자를 놓고 보면 생각보다 답이 단순해집니다. 이미지가 트래픽 대부분이면 CDN이 잘 맞고, 데이터베이스 쿼리나 PHP 처리 시간이 병목이면 서버와 코드 쪽을 봐야 합니다. 저는 늘 이 순서로 봅니다. 비싼 요금제부터 고르는 것보다, 어디서 느려지는지 확인하는 쪽이 훨씬 덜 위험합니다.
