응답을 구분하는 값은 캐시 키 설계에서, 오리진에만 추가로 필요한 값은 오리진 요청 정책에서 검토하세요. 오리진으로 전달했다는 이유만으로 캐시가 나뉘지는 않습니다. 개인화·인증 응답에는 이 구분을 기계적으로 적용하지 말고 별도의 캐시 안전성을 확인해야 합니다.
원인: 전달하는 값과 응답을 구분하는 값을 같은 것으로 본다
캐시 정책은 헤더·쿠키·쿼리 문자열 등 캐시 키에 포함할 값과 TTL을 다룹니다. 오리진 요청 정책은 캐시 키에 없는 추가 정보를 오리진 요청에 포함하는 용도로 사용할 수 있습니다. 캐시 키에 포함한 값은 오리진 요청에도 포함됩니다. 캐시 적중 때마다 오리진 요청이 발생하는 것으로 이해하면 검증이 어긋납니다.
| 질문 | 검토 대상 | 확인할 결과 |
| 이 값에 따라 응답이 다른가 | 캐시 키 또는 캐시 금지 설계 | 서로 다른 응답의 혼합 방지 |
| 응답은 같고 분석에만 필요한가 | 오리진 요청 정책 | 추가 전달과 키 분리 |
| 얼마 동안 보관하는가 | 캐시 정책 TTL | 오리진 지시와 최소 TTL |
1. 공개 응답의 변화 요인부터 적는다
예를 들어 공개 상품 설명이 언어 파라미터에 따라 달라지는 설계라면 URL·쿼리·헤더 중 어떤 값이 실제 응답을 바꾸는지 명시합니다. 반면 동일한 응답에 붙는 분석용 표식은 다른 요구입니다. 이는 설계 예시이며 실제 배포된 CloudFront 설정이나 사용자 데이터를 분석한 결과가 아닙니다.
2. 두 정책과 연결된 캐시 동작을 함께 대조한다
정책 이름만 확인하지 말고 해당 경로에 적용되는 캐시 동작, 캐시 키의 포함 항목, 오리진 요청에 추가할 항목을 나란히 기록합니다. 같은 이름처럼 보이는 정책이라도 다른 동작에 연결돼 있으면 기대한 경로에 적용되지 않습니다. 오리진 요청 정책을 사용할 때는 같은 캐시 동작의 캐시 정책도 확인하세요.
3. 캐시 적중과 미스를 나누어 검증한다
승인된 비개인화 시험 경로에서 요청 값을 바꾸고, 실제 응답 내용·캐시 상태와 오리진에서 관찰한 값을 함께 확인하는 계획을 세웁니다. 오리진 로그에 요청이 없다는 사실은 캐시 적중과 관련될 수도 있습니다. 한 번 성공한 응답이나 한 헤더만으로 전체 동작을 입증하지 말고 최초 요청과 반복 요청을 비교하세요. 이 글에서 CDN 배포나 캐시 시험은 수행하지 않았습니다.
TTL·개인정보·변경 시 주의
최소 TTL이 0보다 크면 오리진의 no-cache·no-store·private 지시가 있어도 그 최소 시간 동안 캐시될 수 있다는 공식 경고를 확인해야 합니다. 민감한 응답에 분석용 값의 예제를 그대로 사용하지 마세요. “키 항목을 줄이면 무조건 좋다”는 기준도 안전하지 않습니다. 이전 정책 연결과 원본 설정을 보존하고 시험 경로에서 검증한 뒤 승인된 범위만 변경합니다. 무분별한 전체 전달·전체 캐시 삭제로 문제를 덮지 말고 비용과 오리진 부하도 별도로 검토하세요.
FAQ
오리진에 보내면 자동으로 캐시가 나뉘나요? 추가 전달만으로 캐시 키에 들어가지는 않습니다. 두 정책의 역할을 구분하세요.
캐시 키에 포함한 값은 오리진에도 가나요? 해당 값은 오리진 요청에도 포함됩니다. 오리진 요청은 캐시 미스 등 오리진 통신이 일어나는 경우입니다.
개인화 응답도 같은 예제로 설정해도 되나요? 아닙니다. 인증·쿠키·응답별 분리와 캐시 금지 조건을 별도 설계·검증해야 합니다.
공식 출처와 관련 글
자료 확인일: 2026년 10월 22일. 공식 문서 기반 설계 안내입니다. AWS 계정 배포·성능·요금 실측을 수행하지 않았습니다.
'소프트웨어개발' 카테고리의 다른 글
| CloudTrail Event history와 Trail 선택: 조회 기간·이벤트 유형·보존 책임 구분 (0) | 2026.10.23 |
|---|---|
| rsync 복사 경로가 한 단계 달라질 때: 소스 끝 슬래시와 dry-run 확인 (0) | 2026.10.22 |
| gitignore가 적용되지 않을 때: 추적 파일과 규칙 일치를 따로 확인 (0) | 2026.10.22 |
