헤르메스 무배포 콘텐츠 운영 루프

헤르메스가 사이트 운영자가 되면 가장 먼저 분리해야 할 것은 작성과 배포입니다. 글은 자주 보강되어야 하지만 코드는 신중하게 배포되어야 합니다. 두 흐름을 한 덩어리로 묶으면 콘텐츠 하나를 고칠 때마다 Production 빌드가 발생하고, 다른 개발 작업과 충돌하며, 자동화가 늘어날수록 운영자가 원하지 않는 배포가 생깁니다.

무배포 콘텐츠 운영 루프는 이 문제를 해결하기 위한 기본 구조입니다. 로컬 JSON을 원본으로 두고, 검증을 통과한 글만 런타임 DB에 업로드하고, 관련 공개 경로를 revalidate한 뒤, 실제 페이지에서 live smoke를 확인합니다. 코드가 바뀌지 않았다면 git push와 Vercel 배포는 하지 않습니다.

이 루프가 필요한 상황

이 루프는 데이터만 바뀌는 콘텐츠에 적합합니다. AI 뉴스, VIBE 코딩 팁, Hermes 팁, 앱 소개, 사전 항목처럼 렌더러 구조가 그대로이고 본문 데이터만 바뀌는 경우가 대표적입니다. 반대로 라우팅, 컴포넌트, 스키마, 렌더러, OG 이미지 생성 로직이 바뀌면 코드 변경이므로 정식 배포 루프가 필요합니다.

판단 기준은 단순합니다. “이 변경을 되돌리려면 DB row만 되돌리면 되는가?” 그렇다면 무배포 후보입니다. “코드 빌드 결과나 페이지 구조가 달라지는가?” 그렇다면 배포 후보입니다. 헤르메스는 작업 시작 전에 이 경계를 먼저 선언해야 합니다.

표준 운영 순서

이 순서를 줄이면 빠르게 보이지만 결국 운영 비용이 늘어납니다. 특히 live smoke를 생략하면 DB에는 반영됐지만 사용자는 예전 화면을 보는 상황을 놓칠 수 있습니다.

상황별 예시

뉴스 기사를 보강하는 경우에는 /news, /news/slug, 홈 피드, sitemap을 확인합니다. Hermes 팁이면 /hermes와 /hermes/slug가 핵심입니다. VIBE 코딩 팁이면 /vibe-coding과 상세 페이지를 봅니다. 앱 소개라면 /apps와 앱 상세, 검색/목록 카드 문구까지 확인해야 합니다.

예를 들어 제목을 고쳤는데 상세 페이지에는 새 제목이 보이고 목록 카드에는 예전 제목이 남아 있다면 revalidate 범위가 부족한 것입니다. 본문은 바뀌었는데 OG title이 예전이면 공유 메타 경로를 별도로 봐야 합니다. 글은 정상인데 콘솔에 hydration 오류가 있다면 콘텐츠 문제가 아니라 렌더러 문제가 될 수 있습니다.

헤르메스가 멈춰야 하는 기준

무배포 루프라고 해서 모든 것을 자동으로 밀어 넣으면 안 됩니다. 글에 출처가 부족하거나, 공식 출처와 다른 사실이 있거나, 내부 운영 문구가 들어갔거나, 공개 페이지에서 렌더링이 깨지면 업로드를 멈춰야 합니다. 또한 수정 도중 코드 변경이 필요해지는 순간에는 무배포 루프를 중단하고 배포 루프로 전환해야 합니다.

가장 중요한 원칙은 완료 보고를 증거 중심으로 하는 것입니다. “업로드했습니다”가 아니라 “검증 통과, DB upsert 성공, revalidate 성공, live detail 200, 목록 마커 확인, 콘솔 오류 없음”처럼 말해야 운영자가 신뢰할 수 있습니다.

체크리스트

• 이 변경은 데이터만 바뀌는가?
• 로컬 JSON이 원본으로 남아 있는가?
• 글이 얕은 요약이 아니라 독자의 문제를 해결하는가?
• 공식 출처 또는 검증 가능한 근거가 있는가?
• 내부 문구와 비밀정보가 공개되지 않는가?
• 목록·상세·홈·sitemap revalidate 경로가 맞는가?
• 실제 공개 페이지에서 제목과 핵심 문구가 보이는가?
• 실패하면 되돌릴 기준이 있는가?

무배포 콘텐츠 운영은 배포를 피하는 꼼수가 아닙니다. 코드 배포와 데이터 반영의 책임을 분리해, 헤르메스가 자주 일해도 사이트가 흔들리지 않게 만드는 운영 구조입니다.

운영 성숙도 단계

처음에는 수동 업로드와 수동 smoke만으로도 충분합니다. 중요한 것은 자동화를 서두르는 것이 아니라 증거를 남기는 습관입니다. 두 번째 단계에서는 업로드와 revalidate를 스크립트로 묶고, 실패 응답을 명확히 출력하게 합니다. 세 번째 단계에서는 섹션별 revalidate 경로와 live marker를 작업 카드에 자동으로 채웁니다. 네 번째 단계에서는 품질 게이트를 추가해 얕은 글, 공식 출처 없는 뉴스, 내부 문구가 있는 글은 DB 업로드 전에 멈추게 합니다.

가장 높은 단계는 “자동 게시”가 아니라 “자동 보류”를 잘하는 상태입니다. 좋은 헤르메스 운영은 문제가 있는 글을 억지로 공개하지 않습니다. 글이 짧거나 출처가 부족하거나 독자가 바로 실행할 수 없는 경우에는 게시를 멈추고 보강 후보로 돌립니다. 이 원칙이 없으면 무배포 루프는 빠른 쓰레기 생산기가 됩니다.

운영자가 보고받아야 할 결과 형식

완료 보고에는 최소한 네 가지가 들어가야 합니다. 첫째, 어떤 파일 또는 post id를 다뤘는지. 둘째, DB 업로드와 revalidate가 성공했는지. 셋째, 어떤 공개 URL에서 어떤 마커를 확인했는지. 넷째, 남은 위험이 있는지입니다. 예를 들어 “/hermes/example 200, 제목 마커 확인, 목록 카드 확인, 콘솔 오류 없음, 공개 금지어 없음”처럼 짧지만 구체적이어야 합니다.

나쁜 보고는 “완료했습니다”입니다. 더 나쁜 보고는 검증하지 않았는데 완료했다고 말하는 것입니다. 운영자는 AI의 자신감이 아니라 증거를 믿어야 합니다. 헤르메스가 사이트 운영자라면 모든 공개 변경은 증거와 함께 끝나야 합니다.

실수 사례와 예방

첫 번째 실수는 로컬 JSON만 고치고 DB 업로드를 잊는 것입니다. 이 경우 저장소에는 새 글이 있지만 라이브 사이트에는 보이지 않습니다. 두 번째 실수는 DB 업로드는 했지만 revalidate를 빠뜨리는 것입니다. 이 경우 상세는 우연히 보일 수 있어도 목록과 홈은 예전 상태일 수 있습니다. 세 번째 실수는 live smoke에서 상세만 보고 목록을 보지 않는 것입니다. 방문자는 대부분 목록 카드에서 글을 발견하므로 목록 확인이 중요합니다.

네 번째 실수는 코드 변경이 필요한 상황을 무배포 루프로 억지 처리하는 것입니다. 렌더러가 표를 깨뜨리거나 metadata가 잘못 생성된다면 데이터 업로드로 해결할 수 없습니다. 이때는 즉시 코드 변경 루프로 전환해야 합니다. 다섯 번째 실수는 자동화가 성공했다고 품질 검토를 생략하는 것입니다. 스키마가 맞아도 글이 얕으면 사이트 신뢰도는 떨어집니다.

다음에 자동화할 수 있는 부분

이 루프가 안정되면 post validation, DB upload, revalidate, live marker scan을 하나의 명령으로 묶을 수 있습니다. 하지만 최종 품질 판단은 여전히 기준이 필요합니다. 글이 전문적인지, 독자에게 도움이 되는지, 공식 출처가 충분한지, 내부 문구가 없는지는 단순 성공 코드만으로 판단하기 어렵습니다. 그래서 자동화는 “검증을 대신하는 것”이 아니라 “검증 증거를 더 빨리 모으는 것”으로 설계해야 합니다.

적용 전 확인

먼저 작업 범위와 성공 기준을 한 문장으로 적는다. Hermes가 무엇을 바꿀 수 있고 무엇을 바꾸면 안 되는지, 공개 반영 전에 어떤 검증을 통과해야 하는지 정하지 않으면 자동화는 속도보다 혼란을 만든다.

실행 중 관찰

실행 중에는 로그의 성공 메시지만 보지 말고 변경 파일, 데이터 반영 위치, 예상 marker, 브라우저 콘솔, 사용자에게 보이는 문구를 함께 확인한다. 이상 신호가 보이면 범위를 넓히지 말고 현재 단계에서 멈춘다.

완료 후 기록

완료 보고에는 변경 내용, 검증 명령, 공개 확인 결과, 남은 위험, 다음 운영자가 이어받을 조건을 남긴다. 이 기록이 있어야 장기 운영에서 같은 실수를 반복하지 않고 Hermes의 판단 기준도 안정된다.