AI 캐시 무효화 루프

AI가 만든 기능은 처음 배포될 때보다 “고쳤는데도 예전 화면이 계속 보이는 순간”에 더 크게 흔들립니다. 코드는 수정됐고 테스트도 통과했는데 사용자는 낡은 가격, 이전 문구, 오래된 권한 상태, 이미 삭제한 배너를 본다면 문제는 보통 로직이 아니라 캐시 경계에 있습니다. VIBE 코딩에서는 AI가 페이지, API, CDN, 이미지 최적화, service worker, ISR을 빠르게 붙여 주기 때문에 캐시 계층이 더 빨리 늘어납니다. 빠른 구현이 장점이지만, 어느 계층이 언제 갱신되는지 모르면 배포 후 원인 추적이 어려워집니다.

초보자는 캐시를 “다시 계산하지 않으려고 잠깐 저장해 두는 것”으로 이해하면 됩니다. 실무자는 한 단계 더 나아가야 합니다. 브라우저 cache, CDN edge, 서버 메모리, 데이터 패치 캐시, Next.js ISR, service worker offline cache, 이미지/정적 asset fingerprint, API 응답 ETag가 모두 다른 규칙으로 움직입니다. AI에게 “성능을 개선해 줘”라고만 요청하면 이 계층들이 섞인 채 추가될 수 있습니다. 그래서 캐시 무효화 루프는 성능 최적화의 부록이 아니라 배포 안전의 핵심 절차입니다.

핵심 결론

AI 캐시 무효화 루프의 목표는 “모든 캐시를 꺼서 안전하게 만드는 것”이 아닙니다. 목표는 어떤 데이터가 얼마나 오래 낡아도 되는지 정하고, 배포·수정·롤백 순간에 어떤 cache key와 surrogate key를 갱신하거나 CDN purge할지 미리 증명하는 것입니다. 캐시는 빠른 응답을 주지만, 무효화 기준이 없으면 사용자는 오래된 정보를 보고 팀은 이미 고친 버그를 다시 조사합니다.

실전 기준은 네 가지입니다. 첫째, 캐시 계층 지도를 먼저 그립니다. 브라우저, CDN, 서버 렌더링, API, service worker, 정적 asset을 분리합니다. 둘째, 각 계층에 Cache-Control, ETag, TTL, stale-while-revalidate, revalidation tag 같은 계약을 붙입니다. 셋째, 배포마다 content marker와 회귀 테스트로 새 버전이 실제로 보이는지 확인합니다. 넷째, canary와 rollback criteria를 정해 캐시가 잘못 퍼졌을 때 어느 시점에 purge나 롤백을 실행할지 숫자로 판단합니다.

AI에게 맡길 때의 핵심 지시문은 간단합니다. “성능 최적화를 하되 캐시 계층, cache key, TTL, 무효화 트리거, 배포 후 확인할 content marker, 롤백 기준을 함께 제안하라.” 이렇게 쓰면 AI가 단순히 캐시를 덧붙이는 대신 운영 가능한 계약을 설계하게 됩니다. 캐시는 빠르게 붙일수록 더 명시적으로 문서화하고 테스트해야 합니다.

왜 중요한가

사용자는 코드가 아니라 결과 화면을 본다

배포 로그에는 새 커밋이 올라갔다고 찍혀도 사용자가 보는 화면은 브라우저 cache나 CDN edge에 남은 이전 HTML일 수 있습니다. 마케팅 문구, 가격표, 정책 문구, 로그인 상태, 권한 메뉴, 검색 결과처럼 사용자가 바로 판단하는 정보가 낡아 보이면 “수정했다”는 설명은 의미가 없습니다. VIBE 코딩은 배포 속도가 빠르기 때문에 이런 불일치가 더 자주 드러납니다.

초보 팀은 문제가 생기면 서버 코드를 다시 봅니다. 하지만 캐시 문제는 서버 로그만 봐서는 찾기 어렵습니다. 특정 지역의 CDN edge, 특정 브라우저의 service worker, 특정 URL query, 특정 쿠키 조합에서만 재현될 수 있습니다. 따라서 캐시 무효화 루프는 기능 테스트와 별도로 사용자 관점의 live smoke를 포함해야 합니다. 새 문구가 실제 HTML에 있는지, 오래된 문구가 사라졌는지, 로그인 전후가 다르게 보이는지 직접 확인해야 합니다.

AI는 성능 목표를 받으면 캐시를 과감하게 늘릴 수 있다

AI 에이전트는 “느린 페이지를 빠르게 해 줘”라는 요청을 받으면 캐싱을 자연스럽게 제안합니다. API 응답을 오래 저장하거나, ISR 시간을 늘리거나, CDN 헤더를 강하게 주거나, service worker에 정적 자산을 저장하는 식입니다. 각각은 합리적일 수 있지만 전체 시스템으로 보면 위험할 수 있습니다. 권한별 데이터가 같은 cache key로 묶이면 다른 사용자에게 잘못된 정보가 보일 수 있고, 콘텐츠 수정 후 TTL이 너무 길면 새 글이 늦게 나타납니다.

전문가급 VIBE 코딩은 AI가 만든 최적화를 그대로 받아들이지 않습니다. “무엇이 빨라졌는가”와 “무엇이 오래 낡아도 되는가”를 함께 묻습니다. 공지 배너처럼 즉시 바뀌어야 하는 데이터와 블로그 카드 이미지처럼 조금 늦어도 되는 데이터는 다른 정책을 가져야 합니다. 이 구분을 테스트에 넣어야 AI가 후속 수정 때 캐시 계약을 깨뜨리지 않습니다.

캐시 버그는 롤백도 어렵게 만든다

일반 버그는 이전 코드로 되돌리면 끝나는 경우가 많습니다. 캐시 버그는 다릅니다. 잘못된 HTML, JSON, 이미지, service worker가 이미 사용자 기기와 CDN edge에 퍼졌을 수 있습니다. 롤백 커밋을 배포해도 사용자는 여전히 이전 캐시를 볼 수 있습니다. 그래서 rollback criteria에는 코드 롤백뿐 아니라 CDN purge, service worker 버전 교체, asset fingerprint 확인, API cache key 무효화가 포함되어야 합니다.

실제 작업 순서

1단계: 캐시 계층 지도를 먼저 만든다

새 기능이나 성능 개선을 시작하기 전에 데이터가 지나가는 경로를 적습니다. 예를 들어 글 상세 페이지라면 데이터베이스, 서버 렌더링, ISR, CDN, 브라우저 cache, 이미지 최적화, 클라이언트 라우터 캐시가 관련될 수 있습니다. 대시보드라면 사용자 권한, 쿠키, API 응답, 브라우저 메모리 상태가 더 중요합니다. 지도는 길지 않아도 됩니다. “어디에 저장되는가, 누가 갱신하는가, 얼마나 오래 유효한가” 세 줄이면 충분합니다.

AI 작업 지시서에는 이 지도를 만들게 해야 합니다. “이 변경에서 예상되는 캐시 계층을 표로 정리하고 각 계층의 cache key, TTL, 무효화 트리거를 제안하라”고 쓰면 좋습니다. 이 표가 없으면 성능 개선 PR을 승인하지 않는 규칙을 만들면 캐시 부채가 줄어듭니다.

2단계: 데이터 성격별 TTL을 분리한다

모든 데이터에 같은 TTL을 주면 either 느리거나 위험합니다. 프로필 이름, 결제 상태, 권한 메뉴, 관리자 승인 상태는 짧은 TTL이나 no-store가 필요할 수 있습니다. 공개 블로그 목록, 사전 용어, 이미지 썸네일은 더 긴 TTL과 stale-while-revalidate가 어울립니다. 중요한 것은 “정확성이 속도보다 중요한 데이터”와 “조금 늦어도 괜찮은 데이터”를 분리하는 것입니다.

Cache-Control은 이 결정의 문장입니다. 예를 들어 공개 정적 asset은 긴 max-age와 immutable을 사용할 수 있지만, 사용자별 API는 private 또는 no-store가 더 안전합니다. 공개 콘텐츠 목록은 짧은 max-age와 stale-while-revalidate로 응답성을 얻을 수 있습니다. VIBE 코딩에서는 AI가 이 헤더를 자동으로 넣을 때가 있으므로, 헤더 값이 데이터 성격과 맞는지 테스트로 확인해야 합니다.

3단계: cache key와 surrogate key를 명시한다

캐시 사고의 상당수는 key가 모호해서 생깁니다. 같은 URL이라도 언어, 권한, 로그인 상태, A/B 실험, 디바이스, 쿼리 파라미터에 따라 다른 응답이 필요할 수 있습니다. 이때 cache key가 URL만 바라보면 서로 다른 응답이 섞입니다. 반대로 불필요한 파라미터까지 key에 넣으면 캐시 효율이 떨어지고 purge 범위가 복잡해집니다.

CDN이나 edge 캐시를 쓴다면 surrogate key를 설계합니다. 글 상세는 post:slug, 목록은 category:vibe-coding, 홈 피드는 feed:home 같은 식으로 묶을 수 있습니다. 글 하나를 수정하면 해당 글과 관련 목록의 key를 함께 purge합니다. AI에게 “이 데이터가 변경될 때 어떤 surrogate key를 함께 무효화해야 하는가”를 묻는 습관이 중요합니다.

4단계: revalidation tag와 ISR 경계를 테스트한다

Next.js나 유사 프레임워크를 쓰면 ISR, revalidation tag, route segment cache 같은 기능이 성능을 크게 올려 줍니다. 하지만 어느 mutation이 어떤 tag를 갱신하는지 불명확하면 새 콘텐츠가 목록에는 보이지 않고 상세에는 보이는 이상한 상태가 생깁니다. 글 발행, 수정, 숨김, 삭제 같은 이벤트마다 갱신해야 할 tag를 정하고 테스트합니다.

테스트는 단순해도 됩니다. “새 글을 추가했을 때 목록 tag와 상세 tag가 모두 갱신 대상에 포함된다”, “비공개 전환 시 공개 목록 tag가 갱신된다”, “롤백 시 이전 content marker가 사라진다”를 확인합니다. 실제 외부 CDN을 테스트하기 어렵다면 내부 helper가 반환하는 purge 대상과 revalidation tag를 검증하는 단위 테스트부터 시작합니다.

5단계: 배포마다 content marker를 확인한다

캐시가 바뀌었는지 확인하려면 사람이 눈으로 보는 문장만으로는 부족합니다. 배포마다 새 버전을 식별할 수 있는 content marker를 정합니다. 새 글이라면 slug와 제목, 수정이라면 새 문장과 제거된 문장, UI 변경이라면 버튼 라벨과 사라져야 할 라벨입니다. live smoke는 이 marker가 실제 HTML에 있고 오래된 marker가 없는지 확인해야 합니다.

중요한 페이지는 canary처럼 먼저 검사합니다. 홈, 목록, 상세, 로그인 전후, 대표 API 응답을 순서대로 가져와 status code, Cache-Control, ETag, marker, blocked term을 확인합니다. 여기서 실패하면 전체 배포 성공으로 보고하지 않습니다. 배포 시스템의 success와 사용자 화면의 success는 다릅니다.

6단계: service worker와 browser cache를 별도 점검한다

PWA나 오프라인 기능이 있으면 service worker는 강력한 캐시 계층입니다. 문제는 서버 배포와 별도로 사용자 브라우저에 남는다는 점입니다. 오래된 service worker가 이전 JavaScript bundle이나 API 응답을 계속 줄 수 있습니다. 따라서 service worker version, update flow, cache cleanup 목록을 명확히 해야 합니다.

browser cache도 마찬가지입니다. asset fingerprint가 있으면 긴 캐시가 안전하지만, 파일명이 그대로인데 내용만 바뀌면 사용자가 오래된 코드를 받을 수 있습니다. 번들, 이미지, CSS, 폰트는 fingerprint나 version query가 있는지 확인합니다. 반대로 HTML 문서는 너무 오래 저장하지 않도록 해야 합니다. HTML은 새 asset을 가리키는入口이기 때문입니다.

7단계: 롤백 기준을 숫자로 정한다

캐시 문제는 “조금 기다리면 풀릴 것”이라는 말로 길어지기 쉽습니다. 그래서 rollback criteria를 숫자로 정합니다. 예를 들어 배포 후 10분 안에 대표 경로 5개 중 1개라도 이전 content marker를 반환하면 CDN purge를 실행합니다. purge 후 5분 안에 2개 지역 smoke가 통과하지 않으면 롤백합니다. 로그인 사용자 API에서 잘못된 Cache-Control이 발견되면 즉시 배포 중단으로 봅니다.

이 기준은 팀을 느리게 만들지 않습니다. 오히려 논쟁을 줄입니다. AI 에이전트에게도 “이 기준에 맞춰 배포 후 검증 스크립트와 실패 시 조치 순서를 작성하라”고 요청할 수 있습니다. 그러면 캐시 사고가 감정적 판단이 아니라 절차로 다뤄집니다.

상황별 예시

공개 글 목록이 새 글을 보여 주지 않는다

가장 흔한 상황입니다. 새 글 JSON이나 데이터베이스 row는 존재하고 상세 URL도 열리지만 목록에는 보이지 않습니다. 원인은 목록 페이지의 ISR TTL이 길거나, 목록 revalidation tag가 누락됐거나, CDN edge가 이전 HTML을 들고 있는 경우가 많습니다. 해결은 글 상세만 보지 말고 목록과 홈 feed의 cache key를 함께 확인하는 것입니다.

실전 루프는 이렇습니다. 새 글의 slug와 제목을 content marker로 잡습니다. 발행 이벤트가 post:slug, category:vibe-coding, feed:home 같은 tag를 갱신하는지 테스트합니다. 배포 후 /vibe-coding과 상세 페이지를 모두 가져와 marker를 확인합니다. 상세만 통과하고 목록이 실패하면 글 데이터 문제가 아니라 목록 캐시 문제로 분류합니다.

가격 또는 정책 문구가 늦게 바뀐다

가격, 환불, 보안 정책, 약관 안내는 늦게 바뀌면 신뢰 문제가 됩니다. 이런 데이터는 긴 stale-while-revalidate가 어울리지 않습니다. 공개 페이지라도 정확성이 중요하면 짧은 TTL, 수동 purge, 배포 후 marker 확인이 필요합니다. AI에게 “이 문구는 캐시해도 됩니다”라고 맡기지 말고 데이터 등급을 먼저 알려야 합니다.

좋은 작업 지시는 “가격 문구는 즉시성 등급 high, CDN TTL 60초 이하, 배포 후 이전 가격 marker 제거 확인, 실패 시 purge 실행”처럼 구체적입니다. 초보자에게는 복잡해 보이지만 실제로는 “틀리면 손해가 큰 정보는 오래 저장하지 않는다”는 원칙입니다.

사용자별 메뉴가 다른 사용자에게 보인다

이건 성능 문제가 아니라 보안 사고에 가까운 캐시 문제입니다. 로그인 여부, 권한, 조직, 구독 상태가 응답에 반영된다면 public CDN cache로 저장하면 안 됩니다. Cache-Control은 private 또는 no-store가 기본이고, Vary 헤더나 cache key 설계가 필요할 수 있습니다. AI가 서버 컴포넌트나 API route에 캐시 옵션을 넣을 때 가장 조심해야 하는 영역입니다.

검증은 권한 조합으로 합니다. 비로그인, 일반 사용자, 관리자, 만료된 구독자 같은 fixture를 만들고 서로 다른 marker가 섞이지 않는지 확인합니다. 한 사용자에게만 보여야 하는 메뉴가 공개 HTML에 남는다면 즉시 배포 중단 기준에 들어갑니다.

이미지와 정적 파일이 예전 버전으로 남는다

이미지, CSS, JavaScript는 asset fingerprint가 있으면 긴 cache가 가능합니다. 파일명이 내용 해시를 포함하면 내용이 바뀔 때 URL도 바뀌기 때문입니다. 반대로 동일한 경로에 파일만 덮어쓰면 browser cache와 CDN이 예전 파일을 계속 줄 수 있습니다. AI가 “파일만 교체하면 됩니다”라고 제안할 때 반드시 URL 전략을 확인해야 합니다.

이미지 최적화 계층도 확인합니다. 원본 이미지를 바꿨는데 최적화 캐시가 남아 있으면 사용자는 이전 썸네일을 볼 수 있습니다. 이때는 이미지 URL versioning, optimizer cache purge, 대표 이미지 marker 확인이 필요합니다. 소셜 공유용 OG 이미지도 같은 원리입니다. 새 제목이 반영됐는지 이미지 route를 직접 가져와 확인해야 합니다.

오프라인 기능이 오래된 화면을 고집한다

service worker가 있는 앱은 서버가 정상이어도 브라우저가 오래된 cache를 먼저 보여 줄 수 있습니다. 특히 navigation fallback이나 runtime caching 전략이 과하면 새 배포가 사용자에게 늦게 도착합니다. service worker는 install, activate, cache cleanup, clients claim 흐름을 테스트해야 합니다.

초보자는 “새로고침하면 되겠지”라고 생각하지만 모든 사용자가 강력 새로고침을 하지는 않습니다. 실무자는 버전 배너, 업데이트 알림, 이전 cache 삭제, 위험한 API 응답의 network-first 정책을 함께 설계합니다. AI에게 PWA 최적화를 맡길 때는 “오프라인 캐시는 어떤 URL만 저장하고, 인증 응답은 저장하지 말라”는 조건을 명시해야 합니다.

실수와 주의점

no-store와 긴 TTL을 감으로 섞는다

가장 흔한 실수는 헤더를 복사해서 붙이는 것입니다. 어떤 예제에서는 모든 API에 no-store를 쓰고, 다른 예제에서는 모든 공개 페이지에 긴 max-age를 씁니다. 둘 다 맥락이 빠지면 위험합니다. 캐시 정책은 데이터의 정확성 요구, 사용자별 여부, 변경 빈도, 장애 시 영향으로 결정해야 합니다.

AI에게는 “이 엔드포인트가 사용자별 데이터를 포함하는지 먼저 판단하고 Cache-Control을 제안하라”고 시키세요. 판단 근거 없이 헤더만 추가한 답변은 리뷰에서 되돌리는 것이 좋습니다.

purge를 수동 버튼 하나에 의존한다

CDN purge 버튼은 마지막 수단이지 운영 루프의 전부가 아닙니다. 버튼을 누른 사람이 어떤 key를 지웠는지, 관련 목록까지 지웠는지, purge 후 smoke가 통과했는지 남지 않으면 다음 사고에서 다시 헤맵니다. purge 대상은 코드나 설정에서 계산 가능해야 하고, smoke 결과와 연결되어야 합니다.

실무적으로는 purge helper가 어떤 surrogate key를 반환하는지 테스트하고, 운영 절차에는 “purge 후 확인할 경로와 marker”를 포함합니다. 자동화가 어렵다면 최소한 checklist로 남겨야 합니다.

stale-while-revalidate를 만능으로 본다

stale-while-revalidate는 사용자에게 빠른 응답을 주면서 뒤에서 새 데이터를 받아오는 좋은 전략입니다. 하지만 낡은 데이터를 보여 줘도 되는 경우에만 좋습니다. 가격, 권한, 보안 경고, 장애 공지처럼 즉시성이 중요한 정보에는 부적절할 수 있습니다. 또한 첫 요청자가 낡은 데이터를 볼 수 있다는 사실을 제품적으로 받아들일 수 있어야 합니다.

캐시 정책을 정할 때 “낡은 값이 몇 초까지 허용되는가”를 먼저 묻습니다. 허용 시간이 0에 가깝다면 stale 전략보다 재검증, 짧은 TTL, no-store, push update가 더 적합합니다.

테스트가 로컬 서버만 보고 끝난다

로컬 개발 서버는 CDN, edge, browser cache, production build와 다르게 움직입니다. 캐시 기능은 로컬에서 통과해도 운영에서 실패할 수 있습니다. 최소한 production build, 실제 배포 URL, 대표 지역 또는 반복 요청, 헤더 검사, content marker 검사를 포함해야 합니다. 브라우저 콘솔과 네트워크 탭에서 service worker가 개입하는지도 봐야 합니다.

VIBE 코딩 작업에서는 AI가 로컬 테스트 결과만 보고 “완료”라고 말할 수 있습니다. 작업 지시서에 “배포 후 live smoke와 공개 금지어 스캔까지 완료해야 한다”고 적으면 이 위험을 줄일 수 있습니다.

검증 체크리스트

코드 리뷰 전에 확인할 것

• 캐시 계층 지도가 있는가: browser cache, CDN, 서버, API, service worker, ISR을 구분했는가.
• 각 계층의 Cache-Control, ETag, TTL, stale-while-revalidate 기준이 데이터 성격과 맞는가.
• 사용자별 데이터가 public cache key에 섞이지 않는가.
• cache key와 surrogate key가 변경 이벤트와 연결되어 있는가.
• revalidation tag가 목록, 상세, 홈 feed처럼 관련 화면을 모두 포함하는가.
• 정적 asset fingerprint가 있고 HTML이 오래 캐시되지 않는가.
• service worker가 인증 응답이나 민감한 사용자 상태를 저장하지 않는가.

배포 후 확인할 것

• 대표 경로가 200으로 응답하고 새 content marker를 포함하는가.
• 제거되어야 할 이전 marker가 실제 HTML에 없는가.
• /vibe-coding 같은 목록과 상세 페이지가 같은 버전의 콘텐츠를 보여 주는가.
• Cache-Control과 ETag가 의도한 값으로 내려오는가.
• CDN purge가 필요했다면 purge 대상과 smoke 결과가 기록되었는가.
• service worker가 새 버전으로 교체되거나 안전하게 업데이트를 안내하는가.
• rollback criteria를 넘는 stale 응답 비율이나 시간 지연이 없는가.

AI 작업 지시서에 넣을 문장

AI에게는 다음처럼 요청합니다. “이 변경은 캐시 안정성이 중요하다. 구현 전에 캐시 계층 지도, cache key, TTL, 무효화 트리거, revalidation tag, CDN purge 대상, service worker 영향, content marker, rollback criteria를 제안하라. 구현 후에는 헤더와 marker를 검증하는 회귀 테스트를 추가하고, 배포 후 live smoke 절차를 보고하라.”

이 문장은 길지만 효과가 큽니다. AI가 단순 최적화가 아니라 운영 가능한 루프를 만들도록 방향을 바꿉니다. 특히 cache key와 rollback criteria를 요구하면 막연한 성능 개선이 아니라 검증 가능한 변경이 됩니다.

다음 단계

처음부터 모든 캐시 계층을 완벽히 자동화하려고 하지 마세요. 가장 자주 바뀌고 사용자 신뢰에 영향을 주는 화면 하나를 고릅니다. 예를 들어 공개 글 목록, 가격/정책 문구, 로그인 메뉴, 대시보드 카드, 이미지 썸네일 중 하나입니다. 그 화면의 cache key, TTL, marker, purge 대상만 먼저 정리합니다. 그다음 focused test와 live smoke를 붙입니다.

두 번째 단계는 공통 helper입니다. 데이터 변경 이벤트가 어떤 revalidation tag와 surrogate key를 갱신해야 하는지 한 곳에서 계산하게 만듭니다. 그러면 AI가 새 콘텐츠 타입을 추가할 때도 기존 패턴을 재사용할 수 있습니다. 테스트는 “새 콘텐츠 타입이 관련 목록 tag를 빠뜨리지 않는다”를 확인하면 됩니다.

세 번째 단계는 배포 보고서에 캐시 항목을 넣는 것입니다. 배포가 성공했는지뿐 아니라 대표 URL의 Cache-Control, ETag, content marker, stale 응답 여부를 기록합니다. 캐시 루프가 보고서에 들어오면 팀은 “아마 곧 갱신될 것”이라는 말 대신 증거를 보게 됩니다.

마지막으로, 성능 최적화와 캐시 무효화는 같은 작업의 양면이라는 점을 팀 규칙으로 만드세요. 빠른 응답을 얻는 순간 낡은 응답을 처리하는 책임도 생깁니다. VIBE 코딩의 장점은 AI가 이 책임까지 자동화할 수 있다는 것입니다. 단, 지시서와 테스트가 그 책임을 요구할 때만 가능합니다.