요즘 이전 문의를 받다 보면 CDN부터 붙여야 하냐는 질문이 많아졌다. 사이트가 조금 느려지거나 이미지가 늦게 뜨면 바로 CDN 요금제를 찾는 식이다. 그런데 14년 정도 웹서버와 호스팅 인프라를 만져보면, CDN은 만능 가속 장치라기보다 원본 서버가 반복해서 보내는 파일을 대신 배달해주는 캐시 계층에 가깝다. 잘 붙이면 비용과 장애를 줄이고, 대충 붙이면 원인 파악만 더 어려워진다.
CDN이 필요한 구간을 먼저 계산하는 방법
CDN을 붙일지 말지는 방문자 수보다 전송량과 파일 성격으로 보는 게 맞다. 예를 들어 하루 방문자가 3천 명이어도 페이지 대부분이 텍스트이고 이미지가 작으면 일반 웹호스팅으로 충분한 경우가 많다. 반대로 하루 방문자는 1천 명인데 한 페이지마다 2MB짜리 이미지 20장이 들어가면 서버보다 대역폭이 먼저 부담된다.
간단히 계산하면 된다. 페이지 1회 열람에 이미지, CSS, 자바스크립트, 폰트까지 합쳐 5MB가 나가고 하루 페이지뷰가 2만이면 하루 전송량은 약 100GB다. 한 달이면 3TB 안팎이다. 이 정도부터는 웹호스팅 트래픽 제한, VPS 대역폭, 클라우드 아웃바운드 비용을 같이 봐야 한다. 여기서 CDN 캐시 적중률이 80%라면 원본 서버가 직접 보내는 양은 600GB 수준으로 줄어든다.
- 월 전송량이 수십 GB 수준이면 CDN보다 이미지 압축과 캐시 헤더가 먼저다.
- 월 1TB를 넘고 이미지·영상·다운로드 파일 비중이 높으면 CDN 검토 가치가 있다.
- 동시접속이 순간적으로 튀는 이벤트 페이지는 서버 증설보다 CDN 캐시가 더 싸게 먹히는 경우가 많다.
- 로그인 후 개인화 화면이 대부분이면 CDN 효과는 제한적이다.
CDN으로 빨라지는 것과 그대로인 것
CDN이 잘하는 일은 정적 파일 배달이다. 이미지, CSS, 자바스크립트, 폰트, 압축된 첨부파일처럼 여러 사용자에게 같은 파일을 반복해서 보내는 경우에 강하다. 사용자가 가까운 캐시 서버에서 파일을 받으니 지연 시간이 줄고, 원본 서버의 네트워크와 디스크 I/O도 가벼워진다.
근데 게시판 글 목록, 장바구니, 관리자 페이지, 결제 화면처럼 사용자마다 결과가 달라지는 응답은 조심해야 한다. 잘못 캐시하면 남의 정보가 보일 수 있다. 이건 속도 문제가 아니라 사고다. 운영 중 가장 무서운 장애는 느린 장애보다 데이터가 섞이는 장애다. 그래서 CDN 도입 전에는 어떤 경로를 캐시하고 어떤 경로를 절대 캐시하지 않을지 먼저 나눠야 한다.
캐시해도 되는 파일
- 버전명이 붙은 CSS와 자바스크립트 파일
- 상품 이미지, 썸네일, 로고, 공개 첨부파일
- 다운로드용 공개 PDF나 압축 파일
- 변경 주기가 낮은 공개 랜딩 페이지 일부
캐시하면 위험한 응답
- 로그인 사용자별 대시보드
- 장바구니, 주문, 결제, 쿠폰 화면
- 관리자 페이지와 회원 정보 페이지
- 쿠키나 인증 헤더에 따라 내용이 바뀌는 API
설정보다 중요한 건 캐시 정책이다
CDN 장애 문의를 보면 서비스 자체 문제보다 캐시 정책이 애매한 경우가 많다. 파일을 바꿨는데 예전 이미지가 계속 보인다거나, CSS 수정이 일부 사용자에게만 늦게 반영되는 식이다. 이건 CDN이 이상해서라기보다 파일 이름과 TTL을 운영 방식에 맞추지 않은 경우가 많다.
제가 보통 권하는 방식은 단순하다. 자주 바뀌지 않는 정적 파일은 파일명에 버전을 붙이고 TTL을 길게 둔다. 예를 들어 배포할 때마다 파일명에 해시가 붙는 구조면 한 달 이상 캐시해도 된다. 반대로 같은 파일명으로 계속 덮어쓰는 구조라면 TTL을 짧게 잡거나 배포 후 퍼지 절차를 넣어야 한다. 운영팀이 작은 사이트일수록 자동화가 중요하다. 사람이 매번 CDN 콘솔에 들어가서 캐시 삭제를 누르는 방식은 언젠가 빠진다.
- 이미지 파일명은 가능하면 변경 시 새 이름을 쓴다.
- CSS와 자바스크립트는 빌드 결과에 버전 문자열을 붙인다.
- HTML은 무리하게 길게 캐시하지 않는다.
- 배포 스크립트에 필요한 경로만 퍼지하는 단계를 넣는다.
- 원본 서버의 캐시 헤더와 CDN 규칙이 서로 충돌하지 않게 맞춘다.
비용은 요청 수와 전송량을 같이 봐야 한다
CDN 요금 비교에서 많이 놓치는 게 요청 수다. 전송량만 싸 보여도 이미지가 아주 잘게 쪼개진 사이트는 요청 수 비용이나 부가 기능 비용이 붙을 수 있다. 반대로 큰 파일을 적게 보내는 사이트는 전송량 단가가 더 중요하다. 무료 구간이 있는 서비스도 SSL, 방화벽, 로그 보관, 이미지 최적화, 오리진 보호 같은 기능은 조건이 다를 수 있다.
작은 쇼핑몰이나 블로그라면 처음부터 비싼 엔터프라이즈 구성이 필요하지 않은 경우가 많다. 월 방문자 5만, 월 전송량 200GB 이하, 해외 접속 비중이 낮은 사이트라면 이미지 압축, 브라우저 캐시, 서버 압축만으로 충분한 사례도 흔하다. 반대로 광고 집행일에 트래픽이 몰리고 이미지가 많은 랜딩 페이지라면 저가 CDN이라도 붙이는 편이 낫다. 서버를 한 단계 올리는 것보다 전송 계층을 분리하는 게 더 싸게 끝날 수 있다.
장애 때 확인 순서
CDN을 쓰면 장애 지점이 하나 늘어난다. 그래서 확인 순서가 있어야 한다. 사이트가 안 열릴 때 원본 서버가 죽었는지, DNS가 잘못됐는지, CDN 캐시가 오래된 건지, SSL 인증서가 만료됐는지 구분하지 못하면 복구 시간이 길어진다. 장애는 기술보다 순서 싸움일 때가 많다.
- 원본 서버에 직접 접근했을 때 정상 응답하는지 확인한다.
- CDN을 거친 응답 코드가 200, 301, 403, 404, 502, 504 중 무엇인지 본다.
- 최근 DNS 변경, 인증서 갱신, 방화벽 규칙 변경이 있었는지 확인한다.
- 캐시 퍼지 후에도 같은 문제가 나는지 본다.
- 원본 서버가 CDN 대역을 차단하고 있지 않은지 확인한다.
실무에서는 502와 504가 자주 나온다. 502는 CDN이 원본 서버에서 정상 응답을 못 받았다는 신호인 경우가 많고, 504는 원본 서버 응답이 늦어서 시간 제한에 걸린 경우가 많다. 여기서 무작정 CDN을 껐다 켜기보다 원본 서버의 웹서버 로그, 애플리케이션 로그, DB 상태를 같이 봐야 한다. CDN은 앞단 증상만 보여준다. 병목은 뒤에 있을 수 있다.
처음 도입할 때는 작게 붙이는 게 낫다
처음부터 전체 사이트를 CDN 뒤에 넣는 방식은 편해 보이지만 위험하다. 저는 보통 이미지와 정적 파일 경로부터 분리해서 적용한다. 문제가 생겨도 영향 범위가 작고, 캐시 적중률과 전송량 절감 효과를 숫자로 확인하기 쉽다. 1주일 정도 지켜보면 어떤 파일이 많이 나가는지, 어떤 경로에서 원본 요청이 계속 발생하는지 감이 잡힌다.
운영 기준으로 보면 CDN은 좋은 도구다. 다만 사이트가 느린 이유가 DB 쿼리, PHP 프로세스 부족, 워드프레스 플러그인 충돌, 백업 작업 시간대 겹침이라면 CDN을 붙여도 체감이 크지 않다. 먼저 병목을 보고, 반복 전송되는 정적 자산이 크고 많을 때 CDN을 쓰는 게 맞다. 싸게 운영하는 건 무조건 낮은 요금제를 고르는 게 아니라, 돈을 써야 하는 구간과 안 써도 되는 구간을 나누는 일에 가깝다.
