09편에서 인스턴스마다 메모리가 격리된다는 것을, 10편에서 온디맨드 재검증이 Amplify에서 막혀 있다는 것을 확인했습니다. 두 편 모두 “이미 떠 있는 인스턴스”를 대상으로 한 실습이었습니다. 이번 편은 다른 축입니다. 재배포 자체가 캐시에 어떤 영향을 주는지 시간 순서대로 추적합니다.

이 편에서 만드는 파일

notice-board/
├── data/
│   └── notices.seed.json         (~, 공지 1건 추가)
└── scripts/
    └── track-invalidation.sh     (+)

개념 정리

재배포는 캐시를 지운다(공식 문서 기준)

AWS 공식 문서(Managing the cache configuration for an app)는 캐싱 동작을 정리한 표에서 다음 항목을 지원 여부와 함께 명시합니다.

“Each new CI/CD app deployment clears the cache.” — Yes(과거)/Yes(현재 모두 지원)

즉 Amplify Hosting은 Git 연동 배포로 새 빌드가 올라갈 때마다 CDN 캐시를 지우는 것을 표준 동작으로 보장합니다. 수동으로 무효화 요청을 보낼 필요가 없습니다.

무효화가 전파되는 순서

재배포 버튼을 누른 시점과 브라우저에 새 콘텐츠가 보이는 시점 사이에는 네 단계가 순서대로 일어납니다.

4단계는 이번 실습에서 직접 확인할 수 있는 부수 효과입니다. 10편에서 등록했던 공지는 재배포 후 사라지고, 09편에서 늘려뒀던 조회수도 0으로 돌아갑니다. 두 인메모리 저장소 모두 새 인스턴스에서 다시 시작되기 때문입니다(공지는 data/notices.seed.json 시드로, 조회수는 빈 Map으로). 이 문제는 13편에서 외부 공유 캐시로 해결합니다.

커스텀 헤더가 체감 시간에 주는 영향

05편에서 특정 경로에 Cache-Control: s-maxage=... 커스텀 헤더를 설정했다면, 그 값이 CDN 엣지에 남아있는 최대 시간을 늘립니다. 공식 문서는 재배포마다 캐시를 지운다고 명시하지만, 커스텀 헤더로 캐시 기간을 길게 설정한 SSR 경로에서 재배포 직후에도 잠시 이전 응답이 보였다는 사례가 커뮤니티에 다수 보고되어 있습니다(aws-amplify/amplify-hosting GitHub 이슈 #3186). 실습에서는 이 가능성을 염두에 두고, “즉시 안 바뀌면 실패”로 단정하지 말고 몇 차례 더 새로고침하며 타임라인을 기록합니다.

실습

curl -sI "https://main.d1234567890abc.amplifyapp.com/"
curl -s -X POST "https://main.d1234567890abc.amplifyapp.com/api/notices/1/views"

// data/notices.seed.json (배열 끝에 추가)
{
  "id": 8,
  "title": "10월 프로모션 사전 안내",
  "category": "공지",
  "author": "마케팅팀",
  "publishedAt": "2026-09-22",
  "content": "10월 프로모션 사전 신청을 시작합니다."
}

#!/usr/bin/env bash
# scripts/track-invalidation.sh
# 배포 직후 10초 간격으로 12번(약 2분) 응답을 확인합니다.
URL="https://main.d1234567890abc.amplifyapp.com/"
 
for i in $(seq 1 12); do
  timestamp=$(date +%H:%M:%S)
  headers=$(curl -sI "$URL")
  age=$(echo "$headers" | grep -i '^age:' | tr -d '\r')
  xcache=$(echo "$headers" | grep -i '^x-cache:' | tr -d '\r')
  hasNewNotice=$(curl -s "$URL" | grep -c '10월 프로모션')
  echo "$timestamp | $age | $xcache | 새 공지 노출: $hasNewNotice"
  sleep 10
done

bash scripts/track-invalidation.sh

직접 해보기

1. 05편에서 설정한 s-maxage 값을 크게(예: 3600) 바꾼 뒤 같은 재배포 실습을 반복해 봅니다. 무효화 체감 시간이 달라지는지 관찰합니다.

2. track-invalidation.sh의 간격을 10초에서 2초로 줄여 더 촘촘한 타임라인을 기록해 봅니다.

자주 하는 실수

확인 문제

참고 자료

• AWS Amplify Docs — Managing the cache configuration for an app 
• AWS Amplify Docs — Using the Cache-Control header to increase app performance 
• Amazon CloudFront Developer Guide — Manage how long content stays in the cache (expiration)