AI 블로그 자동화에서 캐시 우회 검증을 습관으로 만드는 법

요약

AI 블로그 자동화에서 가장 헷갈리는 순간은 빌드가 성공했는데 공개 사이트가 아직 예전 화면처럼 보일 때입니다. Futory처럼 content/posts/*.md 파일을 기준으로 Next.js가 페이지를 만들고, PM2 재시작으로 런타임을 갱신하는 구조에서는 파일 생성과 공개 반영 사이에 여러 신호가 있습니다. 이때 캐시를 우회하지 않고 브라우저 화면만 보면 실제 실패인지, 프록시나 브라우저가 오래된 응답을 보여 주는 것인지 구분하기 어렵습니다.

캐시 우회 검증은 거창한 배포 도구가 아니라 작은 운영 습관입니다. 새 글의 slug를 정하고, 테스트와 빌드를 통과한 뒤, 공개 상세 URL과 목록 URL에 query string을 붙여 요청합니다. 동시에 Cache-Control: no-cache와 Pragma: no-cache 헤더를 사용하면 “새 빌드가 독자에게 보이는가”를 더 정확히 확인할 수 있습니다. 이 글은 Futory의 바이브코딩 발행 루틴에서 캐시 우회 검증을 어떻게 안전하게 반복할지 정리합니다.

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

자동화는 빠르게 파일을 만들고 빌드할 수 있지만, 공개 웹은 항상 즉시 같은 상태를 보여 주지 않습니다. 브라우저 캐시, CDN, 리버스 프록시, Next.js 런타임 캐시, 오래된 PM2 프로세스가 모두 화면을 늦게 바꿀 수 있습니다. 그래서 운영자는 “파일이 있다”, “빌드가 성공했다”, “공개 URL이 새 글을 보여 준다”를 서로 다른 단계로 봐야 합니다.

빌드 성공과 공개 성공은 다르다

npm run build가 통과했다는 것은 Next.js가 현재 파일 트리를 해석할 수 있다는 뜻입니다. 하지만 그 결과가 실제 서비스 프로세스에 반영됐다는 뜻은 아닙니다. PM2가 이전 프로세스를 계속 들고 있거나, 공개 요청이 캐시된 HTML을 받으면 새 글은 아직 보이지 않을 수 있습니다. 따라서 빌드 뒤에는 .next 산출물에서 slug를 확인하고, PM2 재시작 뒤에는 공개 URL을 별도로 확인해야 합니다.

같은 URL만 반복해서 보면 놓치는 문제가 있다

운영자가 같은 상세 페이지나 목록 페이지를 여러 번 열면 클라이언트나 중간 캐시가 같은 응답을 돌려줄 수 있습니다. 이때 ?verify=타임스탬프 같은 query string을 붙이면 캐시 키가 바뀌어 최신 응답을 확인하기 쉬워집니다. 여기에 no-cache 헤더를 더하면 서버와 프록시에 “가능하면 다시 검증해 달라”는 의도를 전달할 수 있습니다.

Futory에 맞는 검증 순서

Futory의 반복 발행에서는 검증 대상을 slug 하나로 고정하는 것이 중요합니다. 오늘 날짜의 Markdown 파일이 만들어졌다면 그 파일명이 곧 공개 URL의 핵심입니다. 예를 들어 ai-blog-cache-busting-verification-routine.md는 /posts/ai-blog-cache-busting-verification-routine으로 확인합니다. 이후 모든 테스트, 빌드, 공개 요청은 같은 slug를 기준으로 연결합니다.

상세 페이지를 먼저 본다

가장 먼저 확인할 공개 신호는 상세 페이지의 HTTP 200입니다. 상세 페이지가 200을 반환하면 적어도 직접 URL 접근은 가능하다는 뜻입니다. 이 단계에서는 제목이나 날짜가 응답 본문에 포함되는지도 함께 보면 좋습니다. 상세 페이지가 404라면 목록을 보기 전에 빌드 산출물, 라우팅, PM2 재시작, 배포 경로부터 점검해야 합니다.

목록 페이지는 발견 가능성을 확인한다

상세 페이지가 열려도 홈, /posts, /vibe-coding 목록에 새 글이 보이지 않으면 독자가 발견하기 어렵습니다. 목록 검증에서는 오늘 날짜, slug, 제목 중 하나 이상이 포함되는지 확인합니다. Futory의 일일 발행 보고서에는 각 목록 URL의 상태 코드와 포함 여부를 짧게 남기는 편이 좋습니다. 이렇게 하면 다음 실행에서 “이미 공개됐지만 목록만 늦다”와 “아예 반영되지 않았다”를 구분할 수 있습니다.

운영 보고서에 남길 증거

캐시 우회 검증은 요청 자체보다 기록이 중요합니다. 자동화가 끝난 뒤에는 선택된 KST 시간, 생성 파일, 공개 URL, 콘텐츠 테스트 결과, 테마 테스트 결과, 빌드 결과, .next slug 확인, PM2 재시작 결과, 공개 상세·목록 검증 결과를 같은 slug 기준으로 남겨야 합니다. 보고서가 구체적이면 다음 크론이 중복 글을 만들지 않고 필요한 단계만 다시 확인할 수 있습니다.

실패 메시지는 다음 행동을 정해야 한다

공개 상세가 200이 아니면 새 글을 다시 만들지 말고 배포 경로와 런타임을 확인해야 합니다. 상세은 200인데 목록에서만 보이지 않으면 정렬, 목록 생성, 캐시 문제로 좁힐 수 있습니다. PM2 재시작이 실패했다면 빌드 성공을 공개 성공으로 말하면 안 됩니다. 이처럼 실패를 단계별로 나누면 운영자는 불필요한 수정 대신 정확한 복구 행동을 선택할 수 있습니다.

자주 묻는 질문

query string을 붙이면 실제 독자 화면과 달라지지 않나요?

query string은 검증 요청의 캐시 키를 바꾸기 위한 장치입니다. 독자가 보는 기본 URL도 중요하지만, 운영 검증에서는 최신 서버 응답을 확인하는 것이 우선입니다. cache-busting 요청으로 새 글이 보이면 기본 URL이 늦게 갱신되는 문제는 캐시 정책이나 프록시 설정 쪽으로 좁혀 볼 수 있습니다.

상세 페이지가 200이면 목록 검증은 생략해도 되나요?

생략하지 않는 편이 좋습니다. 상세 페이지 200은 직접 접근 가능성을 보여 주고, 목록 페이지 포함 여부는 발견 가능성을 보여 줍니다. 블로그 운영에서는 두 신호가 모두 필요합니다. 특히 매일 발행되는 글은 홈과 카테고리 목록에 제때 보이는지가 독자 경험에 큰 영향을 줍니다.

캐시 우회 검증이 실패하면 같은 날짜 글을 새로 만들까요?

아닙니다. 오늘 날짜의 Markdown 파일이 이미 있다면 그 파일이 기준입니다. 실패한 것은 글 생성이 아니라 반영이나 검증 단계일 수 있습니다. 같은 날짜의 새 글을 만들면 중복이 생기므로, 기존 파일과 slug를 기준으로 빌드, PM2, 공개 캐시를 다시 확인해야 합니다.

결론

AI 블로그 자동화에서 캐시는 보이지 않는 운영 변수입니다. Futory의 Next.js Markdown 발행 루틴은 파일 생성, 테스트, 빌드, PM2 재시작, 공개 검증을 순서대로 연결할 때 안정적입니다. 그중 캐시 우회 검증은 마지막 공개 신호를 더 믿을 수 있게 만드는 작은 장치입니다.

바이브코딩은 빠르게 만들고 바로 확인하는 흐름에 강합니다. 하지만 매일 반복되는 블로그 운영에서는 빠른 확인이 정확한 확인이어야 합니다. slug 하나를 기준으로 상세 페이지와 목록 페이지를 no-cache 요청으로 확인하고, 그 결과를 보고서에 남기면 자동화는 더 조용하게 중복을 피하고, 운영자는 공개 상태를 더 자신 있게 판단할 수 있습니다.