CloudFront 캐시는 성능 기능이 아니라 운영 기능이다

AWS 실전 운영 시리즈 2/12

CloudFront를 처음 쓸 때는 캐시를 성능 기능으로만 생각하기 쉽다.

사용자 가까운 엣지에서 파일을 제공하니 더 빠르다. 트래픽이 줄고, origin 부하도 줄어든다.

맞는 말이다.

하지만 운영 콘솔에서 CloudFront 캐시는 성능 기능이면서 동시에 운영 기능이다.

캐시 정책에 따라 배포 반영 속도, 데이터 최신성, 장애 대응 방식이 달라지기 때문이다.

문제 상황

React SPA를 S3에 올리고 CloudFront로 서빙했다.

정적 파일은 잘 캐시되었고, 화면 로딩도 빨랐다.

그런데 운영 중에는 이런 질문들이 생겼다.

• 배포했는데 왜 이전 화면이 보일까?
• JSON 데이터가 바뀌었는데 왜 화면에 반영되지 않을까?
• 어떤 파일은 오래 캐시해도 되고 어떤 파일은 짧게 해야 할까?
• 매번 invalidation을 해야 할까?
• 공개 페이지와 운영자 페이지의 캐시 정책은 같아도 될까?

이 질문에 답하려면 캐시를 성능이 아니라 운영 관점에서 봐야 한다.

파일마다 캐시 전략이 다르다

SPA 배포물에는 여러 종류의 파일이 있다.

index.html
static/js/main.abc123.js
static/css/main.def456.css
data/latest.json
public/calendar-2026-05.json

이 파일들은 같은 캐시 정책을 쓰면 안 된다.

파일	성격	캐시 전략
hashed JS/CSS	파일명이 바뀌면 새 버전	길게 캐시 가능
index.html	앱 진입점	짧게 캐시 또는 배포 시 무효화
최신 JSON	운영 데이터	짧은 TTL
공개 월별 JSON	일정 기간 유지	중간 TTL 가능
감사 백업	직접 조회 드묾	캐시 중요도 낮음

정적 자산은 오래 캐시할수록 좋다.

하지만 index.html이 오래 캐시되면 새 JS 파일을 참조하지 못할 수 있다.

운영 JSON이 오래 캐시되면 화면이 오래된 데이터를 보여준다.

그래서 CloudFront 앞단에서는 경로를 기준으로 캐시 정책을 나눠 생각한다.

캐시 정책은 파일 확장자보다 업무 의미에 가깝다. 같은 JSON이라도 운영자가 보는 최신 데이터인지, 외부 공개용 월별 스냅샷인지에 따라 TTL이 달라질 수 있다.

캐시는 오래된 데이터를 보여줄 수 있다

캐시는 빠르게 보여주는 대신 오래된 것을 보여줄 수 있다.

이것이 캐시의 본질이다.

운영 콘솔에서는 이 trade-off를 명확히 정해야 한다.

• 몇 분 정도 지연은 괜찮은가
• 배포 직후 즉시 반영되어야 하는가
• 데이터 변경이 사용자 판단에 영향을 주는가
• 공개 페이지는 얼마나 최신이어야 하는가
• 내부 운영자 화면과 외부 공개 화면의 기준이 다른가

이 질문에 따라 TTL을 정한다.

무조건 짧게 하면 캐시 이점이 줄어든다.

무조건 길게 하면 운영 중 혼란이 생긴다.

invalidation은 운영 절차다

CloudFront invalidation은 단순 명령어가 아니다.

배포 절차의 일부다.

aws cloudfront create-invalidation --distribution-id DISTRIBUTION_ID --paths "/*"

이 명령은 CloudFront 엣지에 캐시된 객체를 무효화한다.

내부 운영 콘솔처럼 배포 빈도가 높지 않고, 배포 후 즉시 반영이 중요한 경우에는 배포 스크립트에 invalidation을 포함하는 편이 실용적이다.

다만 무조건 전체 경로를 무효화할 필요는 없다.

규모가 커지면 다음처럼 나눌 수 있다.

• /index.html
• /static/*
• /public/*
• /latest/*

처음에는 단순하게 시작하고, 필요가 생기면 세분화하는 것이 좋다.

cache hit와 cache miss를 구분하기

데이터가 반영되지 않을 때는 먼저 캐시 문제인지 확인해야 한다.

브라우저 Network 탭이나 응답 헤더에서 CloudFront cache 상태를 볼 수 있다.

일반적으로 다음을 확인한다.

• 응답이 CloudFront에서 온 것인가
• cache hit인가 miss인가
• 응답의 Age가 큰가
• S3 origin에는 새 파일이 올라가 있는가
• 브라우저 캐시가 아니라 CDN 캐시인가

이 구분이 중요하다.

S3에는 새 파일이 있는데 CloudFront가 이전 파일을 주고 있다면 invalidation 또는 TTL 문제다.

S3에도 새 파일이 없다면 배포나 동기화가 실패한 것이다.

공개 페이지와 운영자 페이지의 캐시

공개 페이지와 운영자 페이지는 캐시 전략이 다를 수 있다.

공개 페이지는 많은 사용자가 같은 데이터를 읽고, 약간의 지연을 허용할 수 있다면 캐시를 적극적으로 쓸 수 있다.

운영자 페이지는 내부 판단에 쓰이는 데이터라면 더 짧은 TTL이 필요할 수 있다.

경로를 나누면 정책도 나눌 수 있다.

/admin/*   -> 짧은 TTL 또는 인증 정책
/public/*  -> 긴 TTL 가능
/static/*  -> 긴 TTL
/latest/*  -> 짧은 TTL

이렇게 경로별 정책을 둘 수 있다는 점이 CloudFront를 앞단에 두는 이유 중 하나다.

데이터 파일과 정적 파일을 같은 방식으로 배포하지 않기

정적 파일은 개발자가 배포한다.

데이터 파일은 자동화 스크립트나 백엔드가 갱신할 수 있다.

둘은 배포 주체가 다르다.

같은 bucket에 있더라도 배포 방식은 달라야 한다.

정적 배포 스크립트가 데이터 파일을 삭제하면 안 된다.

반대로 데이터 동기화가 정적 파일을 건드려서도 안 된다.

캐시 정책도 마찬가지다.

정적 자산은 배포 시점 기준이고, 데이터 JSON은 업무 상태 기준이다.

캐시 정책은 문서화해야 한다

캐시는 눈에 보이지 않는다.

그래서 문서화가 중요하다.

운영 문서에는 다음이 있어야 한다.

• 어떤 경로가 CloudFront를 통해 제공되는가
• 각 경로의 TTL은 어떻게 다른가
• 배포 후 invalidation이 필요한가
• 데이터 갱신 후 invalidation이 필요한가
• 캐시 문제를 확인하는 방법은 무엇인가
• 캐시 때문에 생길 수 있는 증상은 무엇인가

문서가 없으면 운영자는 "새로고침하면 되나요?" 수준에서 멈춘다.

CDN 캐시와 브라우저 캐시와 origin 파일 상태를 구분할 수 있어야 한다.

정리

CloudFront 캐시는 성능 기능만이 아니다.

운영 기능이다.

캐시 정책은 다음에 영향을 준다.

• 배포 반영 속도
• 데이터 최신성
• 공개 페이지 안정성
• 장애 대응 방식
• origin 부하
• 운영자의 확인 절차

좋은 캐시 전략은 모든 것을 오래 저장하는 것이 아니다.

파일의 성격에 따라 다르게 보는 것이다.

정적 자산은 길게, 진입점과 운영 데이터는 짧게, 중요한 변경은 invalidation으로 즉시 반영한다.

이 기준을 정해두면 CloudFront는 단순 CDN이 아니라 운영을 안정시키는 계층이 된다.

함께 볼 GitHub 저장소

• aws-console-operations-notes