CloudFront 캐시가 안 맞는 이유, 캐시 키와 TTL로 이해하는 캐시 정책 고르는 법

CloudFront를 붙였는데 원본 서버로 가는 요청이 별로 줄지 않거나, 반대로 내용을 고쳤는데 사용자 화면에 옛 내용이 계속 보이는 경우가 있습니다. 두 문제 모두 원인은 같은 곳에 있습니다. CloudFront가 "같은 요청"을 어떻게 구분하는지, 그리고 저장한 응답을 얼마 동안 재사용하는지를 정하는 캐시 정책입니다.

 

캐시 정책은 두 가지를 정합니다. 하나는 캐시 키, 즉 어떤 요청을 같은 파일로 볼지에 대한 기준이고, 다른 하나는 TTL, 즉 저장한 응답을 몇 초 동안 쓸지에 대한 기준입니다. AWS는 자주 쓰는 조합을 관리형 캐시 정책으로 미리 만들어 두었습니다.

 

이 글에서는 캐시 키와 TTL이 동작하는 방식, 대표적인 관리형 정책의 설정값, 캐시 적중률을 떨어뜨리는 흔한 실수, 그리고 내용을 바꿨을 때 무효화와 파일 이름 버전 관리 중 무엇을 쓸지 정리합니다.

 

CloudFront 캐시가 안 맞는 이유, 캐시 키와 TTL로 이해하는 캐시 정책 고르는 법

 

캐시 키: 어떤 요청을 같은 파일로 볼까

CloudFront는 요청이 들어오면 캐시 키를 만들어, 같은 키로 저장된 응답이 있으면 원본에 묻지 않고 바로 돌려줍니다. 캐시 키에는 기본적으로 도메인과 경로가 들어가고, 정책에 따라 쿼리 문자열, 헤더, 쿠키가 더해집니다. 캐시 키에 들어가는 값이 많을수록 같은 파일이 여러 개로 나뉘어 저장되고, 그만큼 원본으로 가는 요청이 늘어납니다.

 

내용이 같은 파일도 캐시 키가 다르면 따로 저장되고, 원본 요청이 늘어납니다

 

예를 들어 이미지 주소 뒤에 광고 추적용 쿼리 문자열이 붙는 경우를 생각해 보겠습니다. 쿼리 문자열을 캐시 키에 넣으면 /logo.png?utm_source=a와 /logo.png?utm_source=b가 서로 다른 파일로 취급되어 각각 원본에서 다시 가져옵니다. 이미지 내용은 똑같은데도 말입니다. 반대로 쿼리 문자열에 따라 내용이 달라지는 검색 결과 페이지라면, 쿼리 문자열을 빼는 순간 모든 사용자가 같은 결과를 보게 됩니다.

 

TTL: 얼마 동안 재사용할까

TTL은 최소, 기본, 최대 세 값으로 정합니다. 원본이 Cache-Control 같은 헤더로 보관 시간을 알려 주면 CloudFront는 그 값을 최소와 최대 범위 안에서 따르고, 원본이 아무것도 알려 주지 않으면 기본 TTL을 씁니다.

 

관리형 정책	최소 TTL	기본 TTL	최대 TTL	캐시 키에 더하는 값
CachingOptimized	1초	86,400초(24시간)	31,536,000초(365일)	쿼리 문자열·쿠키 없음, 압축 형식 구분용 헤더만
CachingDisabled	0초	0초	0초	없음(캐시 안 함)
UseOriginCacheControlHeaders	0초	0초	31,536,000초	Host·Origin 등 헤더와 모든 쿠키

 

주의할 점이 하나 있습니다. 최소 TTL이 0보다 큰 정책은 원본이 no-cache나 no-store를 보내도 최소 TTL만큼은 캐시합니다. CachingOptimized는 최소 TTL이 1초라서, 개인화된 페이지에 잘못 붙이면 다른 사용자의 응답이 잠깐이라도 재사용될 위험이 있습니다.

 

상황별로 고르는 법

콘텐츠	추천 정책	이유
이미지·CSS·JS 같은 정적 파일	CachingOptimized	캐시 키가 단순해 적중률이 높음
로그인 후 화면, API 응답	CachingDisabled	사용자마다 다른 응답을 재사용하면 안 됨
원본이 보관 시간을 직접 정하는 웹 페이지	UseOriginCacheControlHeaders	원본의 Cache-Control을 따름
쿼리 문자열로 내용이 바뀌는 페이지	필요한 쿼리 문자열만 넣은 사용자 정의 정책	필요한 값만 키에 넣어 적중률 유지

 

하나의 배포에 하나의 정책만 쓸 필요는 없습니다. /static/* 경로에는 CachingOptimized를, /api/* 경로에는 CachingDisabled를 붙이는 식으로 경로별 캐시 동작을 나누는 것이 일반적인 구성입니다.

 

사용자 정의 캐시 정책을 만들 때

관리형 정책이 맞지 않으면 직접 캐시 정책을 만들 수 있습니다. 이때의 원칙은 하나입니다. 응답 내용을 실제로 바꾸는 값만 캐시 키에 넣는 것입니다.

 

값	캐시 키에 넣을 때	빼도 될 때
쿼리 문자열	page, lang처럼 내용이 달라지는 값	utm_source 같은 추적용 값
헤더	언어나 기기 종류로 응답이 달라질 때	원본이 헤더와 관계없이 같은 응답을 줄 때
쿠키	쿠키 값에 따라 다른 화면을 보여 줄 때	분석·광고용 쿠키

 

쿼리 문자열은 전부 넣거나 빼는 대신 필요한 이름만 골라 넣을 수 있습니다. 원본에는 전달해야 하지만 캐시 키에는 넣고 싶지 않은 값이 있다면 캐시 정책이 아니라 원본 요청 정책에서 전달하도록 설정합니다. 캐시 키와 원본 전달을 분리해서 생각하면 적중률을 지키면서도 원본이 필요한 정보는 받을 수 있습니다.

 

내용을 바꿨는데 옛 내용이 보일 때

캐시된 파일을 바로 바꾸는 방법은 두 가지입니다. 하나는 무효화로 캐시를 지우는 것이고, 다른 하나는 파일 이름에 버전을 붙여 새 주소로 배포하는 것입니다.

 

• 무효화 — 한 달에 처음 1,000개 경로까지는 무료이고, 그 이후로는 경로마다 요금이 붙습니다. /images/*처럼 별표를 쓴 경로는 파일이 수천 개여도 1개 경로로 셉니다. 무료 한도는 계정 안의 모든 배포를 합쳐서 계산합니다.
• 파일 이름 버전 — app.js 대신 app.20261002.js처럼 내용이 바뀔 때 이름을 바꾸면 무효화 없이 새 파일이 바로 쓰입니다. 정적 파일에 긴 TTL을 걸어도 안전해집니다.

 

배포할 때마다 전체 경로(/*)를 무효화하는 습관은 무료 한도 안이라면 비용 문제는 적지만, 캐시가 통째로 비워져 배포 직후 원본으로 요청이 몰립니다. 자주 바뀌는 정적 파일은 이름 버전 방식이 더 깔끔합니다.

 

캐시 정책에서 자주 묻는 것

캐시 적중률은 어디서 보나요?

CloudFront 콘솔의 보고서와 지표에서 캐시 적중률과 원본으로 간 요청 비율을 볼 수 있습니다. 정책을 바꾼 전후로 이 값을 비교하면 효과를 확인할 수 있습니다.

 

TTL을 길게 잡으면 위험하지 않나요?

내용이 바뀌지 않는 파일이라면 길게 잡을수록 적중률이 높아지고 원본 부담이 줄어듭니다. 위험은 내용이 바뀌는데 이름이 그대로인 파일에서 생깁니다. 이런 파일은 TTL을 짧게 잡거나, 앞에서 설명한 것처럼 바뀔 때마다 이름에 버전을 붙여 새 주소로 배포하면 긴 TTL을 걸어도 안전합니다.

 

S3 정적 사이트에는 어떤 정책이 맞나요?

이미지·스크립트처럼 바뀌지 않는 파일이 대부분이라면 CachingOptimized가 기본 선택입니다. 자주 바뀌는 index.html만 다른 캐시 동작으로 분리해 짧은 TTL을 주거나, 배포할 때 그 경로만 무효화하면 나머지 파일은 긴 TTL의 이점을 그대로 누릴 수 있습니다.

 

원본에서 Cache-Control을 꼭 보내야 하나요?

꼭 필요하지는 않지만, 원본이 파일 종류별로 보관 시간을 알려 주면 CloudFront와 브라우저 캐시를 함께 제어하기 쉬워집니다. 보내지 않으면 정책의 기본 TTL이 쓰입니다.

 

캐시가 맞으면 요금도 달라진다 — 5TB·1,000만 요청 비교

캐시 정책은 속도 문제로만 생각하기 쉬운데, 원본으로 가는 요청 수와 전송량을 줄이므로 요금에도 바로 반영됩니다. 월 5TB를 1,000만 번 내려받는 사이트를 서울 리전 단가(AWS Price List 2026년 10월)로 비교했습니다.

구성	전송 요금	요청 요금	월 합계
S3에서 직접 서빙	632.52달러 (첫 100GB 무료 뒤 GB당 0.126)	GET 1,000만 건 3.50달러	636.02달러
CloudFront, 캐시 적중률 90%	491.52달러 (1TB 무료 뒤 GB당 0.120)	HTTPS 1,000만 건 12.00달러 + 원본 GET 100만 건 0.35달러	503.87달러
CloudFront, 캐시 적중률 30% (캐시 키에 불필요한 쿼리 포함)	491.52달러	12.00달러 + 원본 GET 700만 건 2.45달러	505.97달러

CloudFront를 쓰는 것만으로 21%가 줄고, 적중률 차이는 요금보다 원본 서버 부하와 응답 속도에서 더 크게 나타납니다. 캐시 키에 세션 쿠키나 추적용 쿼리 문자열이 들어가면 같은 파일이 수백 가지로 쪼개져 적중률이 떨어지므로, 캐시 키는 파일을 구분하는 데 꼭 필요한 항목만 남깁니다.

정리

• 캐시 정책은 캐시 키(무엇을 같은 파일로 볼지)와 TTL(얼마 동안 재사용할지)을 정합니다.
• CachingOptimized는 최소 1초·기본 24시간·최대 365일이고, 쿼리 문자열과 쿠키를 캐시 키에 넣지 않습니다.
• 최소 TTL이 0보다 크면 원본의 no-cache를 무시하므로 개인화된 응답에는 CachingDisabled를 씁니다.
• 무효화는 월 1,000개 경로까지 무료이고 별표 경로는 1개로 세며, 자주 바뀌는 정적 파일은 이름에 버전을 붙이는 편이 낫습니다.

함께 읽으면 좋은 글: 데이터 전송 비용과 CDN / S3 퍼블릭 액세스 차단 설정

참고 자료: CloudFront 관리형 캐시 정책, 무효화 요금, Amazon CloudFront 요금

※ 본 글은 2026년 10월 기준 Amazon CloudFront 개발자 안내서를 참고해 작성했으며, 정책 설정값과 요금은 변경될 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.