CDN이 무엇을 제공해야 하는지 결정하기
우선 인벤토리를 작성하세요. 이미지, 스타일시트, 스크립트, 폰트, 다운로드 같은 버전 관리된 자산을 HTML, API, 계정 페이지, 결제, 관리 영역과 분리합니다. CDN은 종종 수요에 따라 캐시를 채웁니다: 첫 번째 요청은 오리진에 도달할 수 있고, 이후 일치하는 요청은 엣지에서 제공될 수 있습니다. 가까운 엣지와 캐시 히트는 별개의 이점입니다.
각 경로를 공급하는 호스트, 애플리케이션, 스토리지 버킷 또는 로드 밸런서를 기록하세요; 캐시 미스 시 이곳이 응답해야 합니다.
모든 방문자에 대해 동일하고 명시된 수명(수명 만료 시)까지 안전하게 유지할 수 있는 자산부터 시작하세요.
자격을 갖춘 엔지니어가 분리 설계를 하고 테스트하지 않는 한 개인 대시보드, 세션 바인딩 페이지, 고객 데이터를 공유하지 마세요.
콘텐츠 동작에 맞춰 캐시 정책 설정하기
HTTP 응답 헤더는 캐시 동작을 표현합니다. Cache-Control은 응답을 저장할 수 있는지와 얼마나 오랫동안 신선한지(시간 대기, TTL)를 알립니다. 브라우저는 개인 캐시이고 CDN은 보통 공유 캐시입니다. 명시적 헤더를 사용하세요. HTTP 표준은 s-maxage로 공유 캐시의 수명을 max-age와 별도로 설정할 수 있게 허용합니다.
콘텐츠가 변경될 때마다 새 URL을 게시하세요(예: 콘텐츠 해시가 포함된 파일명). 변경 불가능한 버전에 대해 긴 문서화된 수명을 부여하세요.
오래된 콘텐츠의 비용에 따라 짧은 수명 또는 검증 동작을 선택하세요; 가격, 재고, 계정 상태에 대해 자산 규칙을 재사용하지 마세요.
한 사용자만을 위한 응답에는 private를 사용하세요. 쿠키만으로는 공유 캐시에 안전하다고 볼 수 없습니다.
무효화(퍼지)는 예외로 유지하고 릴리스 계획으로 삼지 않기
무효화(퍼지)는 관리형 CDN에 저장된 특정 객체를 정상 만료 전에 삭제하라고 지시하는 것입니다. 교정용으로 사용하고 모든 배포마다 사용하지 마세요. 퍼지하기 전에 오리진이 이미 대체물을 반환하는지 확인하세요; 그렇지 않으면 리필(refill)이 잘못된 응답을 유지할 수 있습니다. 브라우저 캐시는 CDN의 퍼지 제어 밖에 있으므로 URL 버전 관리는 변경 파일에 대해 신뢰할 수 있습니다.
전체 사이트 퍼지 대신 특정 경로, 릴리스 그룹, 또는 제공업체가 지원하는 캐시 태그를 선호하세요; 넓은 퍼지는 갑자기 오리진에 부하를 줄 수 있습니다.
분산 퍼지는 모든 엣지에 동시에 도달하지 않을 수 있습니다. 제공업체의 완료 의미론을 확인하고 대표 URL을 테스트하세요.
이전 및 새 URL, 캐시 규칙, 퍼지 범위, 예상 결과, 되돌리기 단계를 기록하세요.
전달 계층 뒤에 오리진을 유지하기
직접 오리진 접근은 CDN 캐싱과 엣지 제어를 우회할 수 있습니다. 오리진을 CDN만, 그리고 의도된 경로만 접근하도록 제한하세요. 스택에 따라 클라우드 오리진 접근 제어, 문서화된 CDN 이그레스 범위를 가진 방화벽 규칙, 프라이빗 네트워킹, 서명된 오리진 요청, 또는 상호 인증 TLS(mTLS)를 사용하세요.
권한 있는 테스트 위치에서 오리진이 공개 요청을 거부하고 CDN 호스트네임이 작동하는지 확인하세요.
헬스체크, 배포 도구, 내부 접근은 광범위한 공개 규칙 대신 식별 및 네트워크로 범위를 제한하세요.
오리진 인증 방식은 CDN과 오리진에 따라 다릅니다. 최신 제공업체 설정 지침과 보안 검토를 사용하세요.
TLS를 두 개의 연결로 취급하기
엣지에서의 HTTPS는 방문자와 CDN 간 연결을 보호하지만, CDN과 오리진 간 연결도 보호되어야 합니다. 양쪽 구간 모두 암호화를 요구하고 오리진 인증서를 검증하며 호스트네임과 갱신 소유권을 할당하세요. OWASP는 기본값으로 TLS 1.3을 권장하며 호환성을 위해 TLS 1.2를 허용합니다; TLS 1.0과 1.1은 비활성화해야 한다고 권고합니다. 규제 데이터, 결제 흐름, 또는 특이한 클라이언트 호환성에 대해서는 자격 있는 검토를 받으세요.
엣지와 오리진 인증서 소유자, 갱신 경로, 실패 시 대응을 목록화하세요.
HTTP→HTTPS, 정규 호스트, 딥링크 리다이렉트에 루프나 경로 손실이 없는지 테스트하세요.
암호화가 응답을 캐시해도 안전하다는 의미는 아닙니다; 인증, 개인화, 결제 인접 페이지에 대해 별도의 캐시 규칙을 설정하세요.
트래픽을 변경하기 전에 실제 전달 경로 테스트하기
스테이징 호스트네임이나 좁은 프로덕션 경로에서 시작한 뒤 CDN 호스트네임을 테스트하세요 — 오리진만이 아닙니다. Chrome DevTools의 Network 탭은 요청 상태, 도메인, 타이밍, 크기, 헤더를 보여줍니다. 빈 캐시 하드 리로드로 첫 방문을 근사하고, 반복 방문으로 재사용을 검사하세요. 단순히 더 빨라 보이는 페이지가 아니라 예상 헤더와 콘텐츠를 비교하세요. 관객이 지역별로 분산되어 있다면 대표 지역에서 반복 테스트하세요.
Cache-Control과 제공업체의 cache-status 같은 헤더를 검사하세요. 공용 자산이 재사용되고 민감한 페이지가 예상치 않게 공유되지 않는지 확인하세요.
미스, 오래된 콘텐츠 정정, 오리진 오류, 한 자산 또는 경로의 롤백을 광범위한 출시 전에 연습하세요.
테스트한 URL, 헤더 캡처, 경로 규칙 버전, 변경 전후 타이밍을 변경 기록과 함께 저장하세요.
운영 요구사항으로 CDN 선택하고 증명하기
단지 PoP(Point-of-Presence) 수나 일반적인 속도 주장만으로 CDN을 선택하지 마세요. 성능은 지리, 시간대, 트래픽 분포, 라우팅, 캐시 히트 비율 등에 따라 달라집니다. 후보들을 대표 경로, 자산, 지역에서 비교하세요. 각 후보가 필요한 캐시 제어, 타깃 무효화, 오리진 제한, 인증서 워크플로, 로그, 접근 권한, 가격, 지원, 변경 프로세스를 지원하는지 물어보세요.
후보들에 대해 동일한 캐시 헤더, 오리진 동작, 페이지를 사용하세요; 첫 방문과 반복 방문 결과를 별도로 기록하세요.
요청, 전송, 무효화, 로깅, 지원 비용과 캐시 미스 급증 시 비용을 검토하세요. 가격과 제어는 플랜별로 다릅니다.
내보낼 수 있는 구성, 최소 권한, 테스트된 롤백, 명확한 소유권을 요구한 뒤 핵심 경로를 맡기세요.