얼마 전 작은 쇼핑몰 서버를 봤는데, 하루 방문자가 아주 많은 편은 아닌데도 상품 이미지가 뜨는 속도가 들쑥날쑥했습니다. 서버 사양은 4코어에 메모리 8GB라서 부족하지 않았고, 문제는 원본 서버가 정적 파일까지 전부 직접 밀어내고 있다는 점이었습니다. 이런 경우 CDN을 붙이면 서버를 키우는 것보다 비용 대비 효과가 훨씬 좋습니다.
CDN은 어렵게 말하면 전 세계 여러 위치에 캐시 서버를 두고, 이미지·CSS·JS·영상 같은 파일을 사용자 가까운 곳에서 내려주는 구조입니다. 그런데 실제 운영에서는 “빠르게 해준다”보다 “원본 서버가 덜 맞는다”가 더 중요합니다. 원본 서버 요청 수가 줄면 CPU, 디스크 I/O, 네트워크 대역폭이 같이 편해집니다.
CDN이 필요한 구간부터 계산합니다
CDN은 트래픽이 엄청난 사이트만 쓰는 장비가 아닙니다. 월 5만 방문자 사이트도 이미지가 많으면 효과가 크고, 월 50만 방문자라도 HTML 위주의 가벼운 블로그면 굳이 급하지 않을 수 있습니다. 그래서 방문자 수만 보면 판단이 틀어집니다.
먼저 한 페이지가 내려주는 파일 크기를 봅니다. 예를 들어 글 본문 HTML 80KB, CSS와 JS 합쳐서 600KB, 이미지 3MB라면 사용자가 한 페이지를 볼 때 대략 3.7MB를 받습니다. 하루 1만 페이지뷰면 하루 전송량은 약 37GB입니다. 한 달이면 1TB를 넘습니다. 이 정도면 웹호스팅이나 저가 VPS에서 트래픽 제한, 순간 대역폭 제한, 이미지 로딩 지연이 슬슬 보입니다.
반대로 한 페이지가 700KB 정도이고 하루 2천 페이지뷰라면 한 달 전송량은 40GB 안팎입니다. 이런 사이트는 CDN보다 이미지 압축, 캐시 헤더, 서버 설정 점검이 먼저입니다. CDN을 붙여도 좋아지긴 하지만 비용과 설정 복잡도가 먼저 체감될 수 있습니다.
CDN으로 빼기 좋은 파일과 그렇지 않은 파일
CDN에 가장 잘 맞는 건 자주 바뀌지 않고 용량이 큰 파일입니다. 이미지, 폰트, CSS, JS, 다운로드 파일이 대표적입니다. 특히 썸네일과 상세 이미지는 효과가 큽니다. 원본 서버에서 매번 같은 이미지를 보내는 건 운영 관점에서 별로 좋은 구조가 아닙니다.
- 효과가 큰 파일: 상품 이미지, 게시글 이미지, CSS, JS, 폰트, 첨부 파일
- 주의가 필요한 파일: 로그인 후 보이는 페이지, 장바구니, 관리자 페이지, 개인화된 HTML
- 캐시하면 안 되는 파일: 결제 결과, 회원 정보, 임시 인증 파일, 사용자별 API 응답
사실 사고는 대부분 “CDN을 붙였다”에서 나지 않고 “캐시하면 안 되는 걸 캐시했다”에서 납니다. 예전에 회원별 쿠폰 페이지가 캐시돼서 다른 사람 쿠폰 정보가 보인 사례를 본 적이 있습니다. 서버는 멀쩡했지만 서비스 신뢰도는 크게 흔들렸습니다. CDN 설정에서는 성능보다 캐시 범위를 먼저 정해야 합니다.
캐시 시간은 길게보다 다르게 잡습니다
CDN 캐시 시간을 전부 1일, 전부 7일로 잡는 방식은 편하지만 거칠습니다. 파일 성격별로 다르게 잡는 게 운영하기 좋습니다. 로고처럼 거의 안 바뀌는 이미지는 길게, 자주 교체하는 배너 이미지는 짧게, HTML은 아예 캐시하지 않거나 아주 짧게 두는 식입니다.
제가 보통 잡는 기준은 이렇습니다. 파일명에 버전이 붙는 CSS와 JS는 7일에서 30일 정도도 괜찮습니다. 예를 들어 파일명이 바뀌면 새 파일로 인식되기 때문입니다. 게시글 이미지는 1일에서 7일 정도가 무난합니다. 자주 바뀌는 썸네일은 10분에서 1시간 정도로 짧게 잡습니다. 로그인, 주문, 관리자 화면은 캐시 제외가 기본입니다.
여기서 중요한 건 캐시 삭제 절차입니다. “이미지를 바꿨는데 왜 안 바뀌냐”는 문의가 꼭 생깁니다. 파일명을 바꾸는 방식으로 배포할지, CDN에서 특정 파일만 삭제할지 미리 정해야 운영자가 덜 고생합니다. 작은 사이트는 파일명 변경 방식이 단순하고 실수가 적습니다.
무료 CDN과 유료 CDN을 고르는 기준
무료 CDN도 개인 블로그, 회사 소개 사이트, 작은 쇼핑몰 초반 구간에서는 충분한 경우가 많습니다. 특히 이미지와 정적 파일 캐시만 쓰는 정도라면 굳이 비싼 요금제부터 갈 필요가 없습니다. 저는 서버 비용도 그렇지만 CDN도 먼저 작게 시작하는 편입니다.
다만 유료가 필요한 구간은 분명합니다. 대용량 파일 다운로드가 많거나, 해외 접속 비중이 높거나, 이미지 최적화 기능이 필요하거나, 장애 대응 지원이 중요하면 유료 상품을 봐야 합니다. 월 전송량이 1TB를 넘어가고 피크 시간대 이미지 로딩이 흔들린다면 무료 기능만으로는 답답할 수 있습니다.
비교할 때는 월 요금보다 초과 트래픽 단가, 요청 수 과금, 이미지 변환 과금, 캐시 삭제 제한을 같이 봐야 합니다. 어떤 상품은 기본료가 낮아 보여도 이미지 리사이징이나 요청 수에서 비용이 붙습니다. 사이트가 커질수록 “GB당 얼마냐”보다 “우리 사용 패턴에서 얼마냐”가 더 정확합니다.
CDN 붙인 뒤 꼭 확인할 설정
CDN 연결 후에는 페이지가 빨라졌는지만 보면 부족합니다. 운영자는 장애가 났을 때 원본 서버 문제인지 CDN 문제인지 나눠 볼 수 있어야 합니다. 그래서 연결 직후 확인할 항목을 짧게라도 남겨두는 게 좋습니다.
- 원본 서버 접속이 CDN 없이도 정상인지 확인
- 정적 파일 응답 헤더에 캐시 시간이 의도대로 들어가는지 확인
- 로그인 페이지와 관리자 페이지가 캐시 제외됐는지 확인
- 이미지 교체 후 새 파일이 사용자에게 보이는지 확인
- SSL 인증서가 원본 서버와 CDN 양쪽에서 정상인지 확인
- 원본 서버 IP가 불필요하게 외부에 노출되지 않는지 확인
SSL도 자주 삐끗합니다. CDN 쪽은 정상인데 원본 서버 인증서가 만료됐거나, 원본 연결 방식이 어긋나서 간헐적으로 오류가 나는 경우가 있습니다. 사용자는 “사이트가 가끔 안 열린다”고 말하지만 실제로는 CDN과 원본 서버 사이 연결 문제인 경우가 꽤 있습니다.
또 하나는 로그입니다. CDN을 붙이면 원본 서버 접속 로그에 실제 사용자 IP가 그대로 안 찍힐 수 있습니다. 보안 차단, 통계, 장애 분석을 로그에 의존하고 있다면 실제 사용자 IP를 전달하는 헤더 설정을 확인해야 합니다. 이걸 놓치면 공격 IP를 못 잡거나, 반대로 CDN 서버 대역을 차단해버리는 사고가 납니다.
서버 증설보다 CDN이 먼저인 경우
CPU 사용률은 낮은데 네트워크 전송량만 높고, 이미지 요청이 많고, 피크 시간대에 정적 파일 로딩이 느리다면 서버 증설보다 CDN이 먼저입니다. 반대로 DB 쿼리가 느리거나 PHP, Node, Java 같은 애플리케이션 처리 시간이 긴 사이트는 CDN만 붙여서는 큰 변화가 없습니다. 병목이 어디인지 봐야 돈을 덜 씁니다.
운영 경험상 작은 사이트가 갑자기 느려질 때 원인은 고급 인프라 부족보다 기본 설정 누락인 경우가 많습니다. 이미지 원본 그대로 업로드, 캐시 헤더 없음, 백업 파일을 같은 서버에 쌓아둠, 로그 파일 방치, SSL 갱신 실패 같은 것들입니다. CDN은 이런 문제 중 정적 파일 전송 부담을 줄여주는 도구일 뿐이고, 서버 운영 전체를 대신해주지는 않습니다.
그래도 제대로 붙인 CDN은 체감이 큽니다. 원본 서버 요청이 줄고, 피크 시간대가 부드러워지고, 해외 접속도 덜 답답해집니다. 저는 CDN을 고급 옵션이라기보다 기본 위생에 가까운 선택지로 봅니다. 다만 처음부터 거창하게 갈 필요는 없습니다. 캐시할 파일을 좁게 잡고, 무료나 저가 구간에서 시작한 뒤, 실제 전송량과 장애 패턴을 보고 넓혀가는 방식이 가장 오래 갑니다.
