기능 플래그를 끄고도 새 화면이 보였던 캐시 확인 기록

플래그 값보다 오래된 HTML이 문제였다

새 편집 화면을 일부 사용자에게만 열기 위해 기능 플래그를 사용했다. 테스트가 끝나 플래그를 껐는데도 한 팀원의 브라우저에는 계속 새 화면이 나타났다. 서버 로그에서 플래그 값은 false였기 때문에 처음에는 쿠키나 사용자 식별자를 의심했다.

개발자 도구의 Network 탭을 새로고침하면서 Age와 x-cache 헤더를 보니, 서버가 아니라 CDN에서 이전 HTML을 받고 있었다. 브라우저 캐시만 지우는 것으로는 해결되지 않는 종류였다.

값을 읽는 위치를 먼저 분리했다

플래그가 어디에서 결정되는지 세 층으로 나눠 기록했다.

1. 요청 쿠키 또는 계정 정보
2. 서버가 렌더링한 HTML
3. 클라이언트가 하이드레이션 뒤 읽는 설정

새 화면의 버튼이 HTML에 이미 포함되어 있다면 클라이언트 코드만 고쳐서는 늦다. 반대로 HTML은 이전 화면인데 자바스크립트가 새 화면을 그린다면 정적 번들 캐시나 런타임 설정을 봐야 한다.

캐시 무효화와 재발 방지

문제 배포에서는 해당 경로의 CDN 캐시를 purge하고, 원본 응답의 캐시 헤더를 확인했다.

curl -sS -D - -o /tmp/page.html https://example.com/editor \
  | grep -Ei 'cache-control|age|x-cache|etag'

기능 플래그가 사용자별로 달라지는 페이지에 공개 캐시가 적용되지 않도록 Cache-Control: private, no-store를 사용했다. 정적 파일처럼 플래그와 무관한 자산은 해시 파일명으로 길게 캐시해도 괜찮았다.

다음 배포에 넣은 체크

• 플래그를 끈 직후 새 브라우저와 기존 브라우저에서 각각 확인한다.
• 원본과 CDN 응답의 헤더를 비교한다.
• 사용자별 응답에 Vary가 필요한지 캐시 정책 담당자와 정한다.
• 플래그 만료일과 제거 담당자를 코드 옆에 남긴다.

기능 플래그는 조건문 하나로 끝나지 않는다. 그 값을 담은 HTML이 어디에서 캐시되고, 언제 바뀌는지까지 확인해야 “껐는데도 보이는” 상황을 설명할 수 있었다.