CDN 제대로 쓰는 방법: 트래픽보다 먼저 확인할 설정값

얼마 전 작은 쇼핑몰 이전 작업을 봤는데, 서버 사양은 충분한데 이미지가 느리다는 이유로 클라우드 서버를 한 단계 올리려고 하더군요. 로그를 보니 병목은 CPU도 메모리도 아니었습니다. 같은 이미지를 매번 원본 서버에서 내려주고 있었고, 캐시 만료 시간은 0에 가까웠습니다. 이런 경우는 서버를 키우는 것보다 CDN 설정을 잡는 쪽이 훨씬 싸고 효과가 큽니다.

CDN은 사이트 앞단에 캐시 서버를 두는 구조입니다. 방문자가 서울에 있든 부산에 있든, 또는 해외에 있든 원본 서버까지 매번 가지 않고 가까운 엣지 서버에서 파일을 받게 만드는 방식입니다. 다만 붙였다고 자동으로 빨라지는 장비는 아닙니다. 캐시할 파일, 캐시하지 말아야 할 요청, 장애가 났을 때 원본으로 우회하는 기준을 정해야 제 역할을 합니다.

CDN을 써야 하는 구간부터 계산하기

트래픽이 하루 1천 명이라고 해서 무조건 CDN이 필요한 건 아닙니다. 페이지가 가벼우면 일반 웹호스팅으로도 충분합니다. 제가 먼저 보는 건 방문자 수보다 전송량입니다. 예를 들어 한 페이지가 HTML, CSS, 자바스크립트, 이미지까지 합쳐 3MB이고 하루 1만 페이지뷰가 나오면 하루 전송량은 약 30GB입니다. 한 달이면 900GB 근처까지 갑니다.

이 정도면 원본 서버 회선, 웹서버 동시 연결, 백업 시간까지 영향을 받기 시작합니다. 반대로 페이지당 500KB이고 하루 3천 페이지뷰라면 한 달 전송량은 45GB 정도입니다. 이 구간에서는 CDN보다 이미지 압축, 불필요한 스크립트 제거, 캐시 헤더 설정이 먼저입니다.

월 전송량 50GB 이하: CDN보다 이미지 최적화와 브라우저 캐시부터 확인
월 전송량 100~500GB: 이미지·CSS·JS 중심으로 CDN 적용 검토
월 전송량 1TB 이상: CDN 비용과 원본 서버 비용을 같이 계산
해외 접속 비중 20% 이상: 지역 지연 시간 때문에 CDN 효과가 커짐

여기서 중요한 건 평균이 아니라 피크입니다. 평소에는 괜찮다가 이벤트, 광고, 커뮤니티 유입 때만 죽는 사이트가 많습니다. 10분 동안 평소의 20배가 들어오는 구조라면 서버 증설보다 정적 파일을 CDN으로 빼는 게 더 현실적입니다.

처음 붙일 때는 정적 파일만 분리하기

처음부터 전체 사이트를 CDN 뒤에 넣으면 문제가 생겼을 때 원인을 찾기 어렵습니다. 특히 로그인, 장바구니, 관리자 화면, 결제 페이지가 있는 사이트는 캐시 정책을 잘못 잡으면 사용자별 화면이 섞이거나 세션 문제가 납니다. 실무에서는 이미지, CSS, JS, 폰트 파일부터 분리하는 방식이 안전합니다.

예를 들어 상품 이미지 경로, 업로드 파일 경로, 테마 리소스 경로만 CDN으로 보내면 장애 범위가 작습니다. 원본 서버에 문제가 있어도 이미 캐시된 파일은 계속 내려갈 수 있고, 반대로 CDN 설정이 꼬여도 동적 페이지 전체가 망가지지는 않습니다.

캐시 대상은 확장자 기준으로 나누는 게 관리하기 쉽습니다. jpg, png, webp, css, js, woff2 같은 파일은 대부분 캐시 대상입니다. html, php, api 요청, 장바구니 관련 경로, 관리자 경로는 기본적으로 제외합니다. 워드프레스나 쇼핑몰 솔루션을 쓰는 경우에도 이 원칙은 크게 다르지 않습니다.

캐시 시간은 길게, 파일명은 바뀌게

CDN에서 제일 많이 보는 사고가 캐시 만료 시간입니다. 너무 짧으면 CDN을 붙여도 원본 서버로 계속 확인 요청이 갑니다. 너무 길면 수정한 이미지나 스크립트가 반영되지 않아 운영자가 당황합니다. 그래서 파일 종류별로 다르게 잡아야 합니다.

이미지 파일: 7일에서 30일 정도
CSS·JS 파일: 파일명에 버전이 붙는다면 30일 이상
폰트 파일: 변경이 적으므로 30일 이상
HTML 문서: 일반 블로그는 짧게, 로그인 페이지는 캐시 제외

제가 선호하는 방식은 파일명을 바꾸는 배포입니다. 예를 들어 style.css를 계속 덮어쓰는 대신 style.20261013.css처럼 버전이 들어간 파일을 배포하면 캐시를 길게 잡아도 문제가 줄어듭니다. CDN 캐시 삭제 기능에만 의존하면 운영 중 실수할 여지가 많습니다. 삭제 버튼을 누르는 순간 전 세계 엣지 캐시가 동시에 비고, 그 직후 트래픽이 몰리면 원본 서버가 순간적으로 맞을 수 있습니다.

근데 작은 블로그라면 너무 복잡하게 갈 필요는 없습니다. 이미지와 첨부 파일은 길게, HTML은 짧게, 관리자와 로그인은 제외. 이 세 가지만 지켜도 대부분의 문제는 피해 갑니다.

원본 서버 보호 설정을 같이 해야 한다

CDN을 붙였는데도 원본 서버가 계속 바쁘다면 두 가지를 의심합니다. 첫째, 캐시 적중률이 낮은 경우입니다. 둘째, 방문자가 CDN을 거치지 않고 원본 서버로 직접 접근하는 경우입니다. CDN 관리 화면에서 캐시 적중률이 80% 이상 나오면 정적 파일 중심 사이트에서는 꽤 괜찮은 편입니다. 50% 아래라면 캐시 제외 규칙이나 쿠키 처리부터 봐야 합니다.

원본 서버는 가능하면 CDN 대역에서 오는 요청만 받도록 제한하는 게 좋습니다. 다만 초보자가 방화벽을 바로 잠그면 본인도 접속을 못 하는 일이 생깁니다. 먼저 원본 서버의 실제 IP 접속 여부, 관리자 접속 경로, 백업 접속 경로를 확인한 뒤 단계적으로 적용하는 편이 안전합니다.

SSL도 같이 봐야 합니다. 방문자와 CDN 사이만 암호화되고 CDN과 원본 서버 사이는 평문이면 중간 구간이 비게 됩니다. 운영 환경에서는 방문자-CDN, CDN-원본 서버 구간 모두 인증서를 적용하는 구성이 기본입니다. 인증서 자동 갱신을 쓰는 경우에는 CDN 적용 뒤에도 갱신 검증 파일에 접근 가능한지 확인해야 합니다.

장애 때 확인할 순서

CDN 장애는 증상이 애매합니다. 어떤 사람은 잘 보이고, 어떤 사람은 깨진 이미지가 보이고, 관리자 PC에서는 정상인 경우가 있습니다. 이럴 때 서버만 재시작하면 원인을 놓칩니다. 순서를 정해두면 복구 시간이 줄어듭니다.

1단계: 원본 서버에서 파일이 정상 응답하는지 확인
2단계: CDN 캐시 적중 여부와 응답 코드를 확인
3단계: 특정 파일만 문제인지 전체 경로 문제인지 분리
4단계: 최근 배포에서 파일명이 바뀌었는지 확인
5단계: DNS 변경, 인증서 만료, 방화벽 차단 여부 확인

특히 DNS를 바꾼 직후에는 전파 시간이 섞여서 일부 사용자는 예전 경로를 보고 일부 사용자는 새 경로를 봅니다. 이 시점에 설정을 계속 바꾸면 상태가 더 복잡해집니다. 변경 시간을 기록하고, 이전 값과 새 값을 남겨두는 습관이 중요합니다.

CDN은 비싼 서버를 대신하는 마법 상자가 아닙니다. 정적 파일을 원본 서버에서 떼어내고, 피크 시간에 서버가 맞는 부하를 줄이고, 해외 사용자의 지연 시간을 줄이는 도구에 가깝습니다. 작은 사이트라면 무료 구간이나 저가 요금제로도 충분한 경우가 많습니다. 다만 캐시 제외, SSL, 원본 보호, 백업 경로를 확인하지 않고 붙이면 장애 지점이 하나 더 늘어납니다. 저는 CDN을 도입할 때 늘 같은 순서로 봅니다. 먼저 전송량을 계산하고, 정적 파일만 분리하고, 캐시 시간을 정하고, 원본 접근을 제한합니다. 이 정도만 해도 과한 요금제 없이 꽤 오래 버티는 사이트가 많습니다.