AI 블로그 자동화에서 캐시 우회 검증을 표준화하는 법

요약

Futory처럼 AI가 평일마다 Markdown 글을 만들고 Next.js 빌드, PM2 재시작, 공개 확인까지 이어 가는 블로그에서는 “빌드가 성공했다”와 “독자가 새 글을 보고 있다” 사이에 작은 간격이 있습니다. 이 간격을 가장 자주 흐리는 요소가 캐시입니다. 로컬 .next 산출물에는 새 slug가 들어 있지만, 공개 URL을 읽는 순간 이전 HTML이 돌아오거나 목록 페이지가 늦게 갱신된 것처럼 보일 수 있습니다. 캐시 우회 검증은 이 혼선을 줄이기 위해 상세 글, 홈, 전체 글 목록, 카테고리 목록을 같은 방식으로 확인하는 운영 루틴입니다.

핵심은 복잡한 CDN 지식이 아니라 일관된 증거입니다. 새 글을 만든 뒤에는 캐시 우회 쿼리 문자열을 붙이고, 요청 헤더에 Cache-Control: no-cache를 넣어 공개 HTML을 다시 읽습니다. 상세 페이지에서는 200 상태와 제목을 확인하고, 목록 페이지에서는 오늘 날짜나 slug가 포함되는지 확인합니다. 바이브코딩은 빠르게 만드는 방식이지만, 공개 검증은 빠르면서도 재현 가능해야 합니다. 같은 검증 방식이 반복되면 “아직 캐시인가, 배포가 안 된 건가”라는 판단을 더 빨리 내릴 수 있습니다.

캐시 우회 검증이 필요한 이유

자동 발행 파이프라인은 파일 시스템, 빌드 산출물, 런타임 프로세스, 공개 네트워크 경로를 차례로 지나갑니다. 각 단계가 모두 성공해야 독자가 새 글을 안정적으로 읽습니다. 그런데 공개 확인 단계에서 캐시가 끼어들면 실제 상태와 관측 결과가 어긋날 수 있습니다.

빌드 성공만으로는 공개 상태를 단정할 수 없다

npm run build가 성공하고 .next 안에서 새 slug가 발견되면 로컬 배포 산출물은 준비된 상태입니다. 하지만 실행 중인 PM2 프로세스가 새 산출물을 읽어야 하고, 공개 도메인에서 라우팅되는 HTML도 갱신되어야 합니다. 이때 이전 응답이 캐시에 남아 있으면 새 글이 없는 것처럼 보일 수 있습니다. 그래서 빌드 검증과 공개 검증은 서로 다른 증거로 남겨야 합니다.

목록 페이지는 상세 페이지보다 더 쉽게 헷갈린다

상세 URL은 새 slug 하나만 확인하면 됩니다. 반면 홈, /posts, /vibe-coding 같은 목록 페이지는 정렬, 필터, 렌더링 캐시의 영향을 함께 받습니다. 상세 페이지가 200이어도 목록에 날짜가 보이지 않으면 독자 탐색 흐름은 아직 완전하지 않습니다. Futory의 발행 완료 보고에는 상세 페이지와 목록 페이지가 모두 들어가야 합니다.

Futory에서 표준으로 삼을 검증 절차

캐시 우회 검증은 매번 같은 순서로 실행하는 편이 좋습니다. 순서가 고정되어 있으면 실패 지점이 로그에 선명하게 남고, 다음 실행이나 사람이 개입할 때 판단 비용이 줄어듭니다.

1. 새 slug를 기준으로 상세 페이지를 확인한다

공개 URL은 /posts/<slug> 형식으로 정합니다. 요청에는 ?v=YYYYMMDDHHMMSS 같은 일회성 쿼리 문자열을 붙이고, Cache-Control: no-cache 헤더를 함께 보냅니다. 응답 상태가 200인지 확인한 뒤 HTML 안에 제목이나 slug와 연결되는 본문 일부가 있는지 봅니다. 이 단계는 새 글이 직접 링크로 접근 가능한지를 확인하는 가장 기본적인 증거입니다.

2. 홈과 전체 글 목록을 확인한다

다음은 /와 /posts입니다. 홈은 최신 글 진입점이고, 전체 글 목록은 독자가 날짜순으로 글을 찾는 기준입니다. 두 페이지에서 오늘 날짜 YYYY-MM-DD 또는 새 slug가 보이면 발행 결과가 탐색 경로에 반영되었다고 볼 수 있습니다. 만약 상세 페이지는 성공하지만 목록에서 보이지 않는다면 콘텐츠 인덱싱, 정렬 기준, 런타임 캐시를 따로 확인해야 합니다.

3. 카테고리 페이지를 확인한다

Futory의 반복 글은 category: "바이브코딩"을 사용하므로 /vibe-coding도 검증 대상입니다. 이 페이지에서 오늘 날짜나 slug가 보이면 카테고리 분류까지 정상입니다. 태그나 카테고리 문자열이 조금만 어긋나도 목록에서 빠질 수 있으므로, 카테고리 페이지 검증은 frontmatter 검증의 공개 버전이라고 볼 수 있습니다.

보고에 남기면 좋은 캐시 증거

캐시 우회 검증은 실행했다는 사실보다 어떤 방식으로 확인했는지가 중요합니다. 보고에는 공개 URL, 사용한 slug, 각 페이지의 HTTP 상태, 오늘 날짜나 slug 포함 여부를 간단히 남깁니다. 가능하면 캐시 우회 쿼리를 사용했다는 점도 적어 둡니다. 그러면 나중에 같은 URL을 브라우저에서 열었을 때 결과가 달라도, 당시 자동화가 어떤 조건으로 확인했는지 추적할 수 있습니다.

실패 보고도 같은 형식으로 남긴다

검증이 실패하면 “안 보임”으로 끝내지 말고 어느 페이지에서 무엇이 빠졌는지 남겨야 합니다. 상세 URL이 404라면 라우팅이나 빌드 산출물 문제일 가능성이 큽니다. 상세 URL은 200인데 목록에 없다면 인덱스 생성이나 캐시 문제를 의심할 수 있습니다. 홈은 보이지만 카테고리에서 빠지면 frontmatter의 category 값 또는 카테고리 라우팅을 확인해야 합니다. 실패를 분류할 수 있어야 다음 조치가 작아집니다.

자주 묻는 질문

캐시 우회 쿼리를 붙이면 실제 독자 경험과 달라지지 않나요?

완전히 같지는 않습니다. 하지만 발행 직후 운영 검증에서는 최신 런타임이 새 콘텐츠를 제공할 수 있는지를 먼저 확인해야 합니다. 캐시 우회 검증이 통과하면 원천 배포는 정상이라는 강한 증거가 됩니다. 이후 일반 URL에서 늦게 보인다면 캐시 만료나 중간 계층을 따로 보면 됩니다.

매번 네 페이지를 모두 확인해야 하나요?

네. 상세 글, 홈, 전체 목록, 카테고리 목록은 서로 다른 실패를 잡습니다. 네 페이지 확인은 시간이 오래 걸리지 않지만, 빠뜨리면 공개 완료를 과하게 낙관할 수 있습니다. 반복 자동화에서는 작은 확인을 매번 같은 방식으로 하는 것이 가장 큰 안정성을 만듭니다.

캐시 검증이 실패하면 글을 다시 만들어야 하나요?

아닙니다. 오늘 날짜의 Markdown 파일이 이미 있다면 새 글을 만들지 말고 같은 파일을 기준으로 빌드, 재시작, 공개 검증을 다시 이어 가야 합니다. 중복 글을 만드는 것은 캐시 문제를 해결하지 못하고 운영 상태만 더 복잡하게 만듭니다.

결론

AI 블로그 자동화에서 캐시 우회 검증은 공개 확인의 잡음을 줄이는 표준 절차입니다. Futory의 Next.js Markdown 흐름에서는 새 파일 작성, 콘텐츠 테스트, 테마 테스트, 빌드, .next 산출물 확인, PM2 재시작 이후에 상세 URL과 주요 목록 페이지를 캐시 우회 방식으로 읽어야 합니다.

바이브코딩은 빠른 제작과 빠른 배포를 장점으로 삼지만, 빠른 공개는 검증 가능한 공개일 때 의미가 있습니다. 매번 같은 캐시 우회 검증을 남기면 새 글이 실제로 독자 경로에 올라왔는지 확인할 수 있고, 실패했을 때도 캐시, 빌드, 런타임, frontmatter 중 어디를 봐야 하는지 빠르게 좁힐 수 있습니다. 그렇게 Futory의 평일 발행 루틴은 단순한 자동 작성이 아니라 재현 가능한 운영 시스템으로 성장합니다.