AI 라이브 마커 점검법

헤르메스가 DB 업로드와 revalidate까지 성공했다고 해서 독자가 새 콘텐츠를 본다는 뜻은 아닙니다. 캐시가 남아 있을 수 있고, 목록은 갱신됐지만 상세가 예전일 수 있으며, 상세는 바뀌었지만 카드 제목이나 공유 메타는 따라오지 않을 수 있습니다. 그래서 무배포 콘텐츠 운영에는 라이브 마커 점검이 반드시 필요합니다.

라이브 마커는 공개 페이지에서 실제로 확인할 수 있는 짧은 증거입니다. 제목, slug, 핵심 문장, 발행일, 대표 태그, 특정 표 제목처럼 독자가 보는 화면에 남는 표시를 말합니다. 운영자는 이 마커를 기준으로 “데이터가 DB에 있다”가 아니라 “공개 화면까지 도착했다”를 판단합니다.

좋은 마커의 조건

좋은 마커는 세 가지 조건을 만족합니다. 첫째, 고유해야 합니다. 너무 흔한 단어는 다른 글에도 있을 수 있습니다. 둘째, 공개 화면에 실제로 보여야 합니다. 내부 JSON 필드에만 있는 값은 live smoke 마커가 아닙니다. 셋째, 너무 길지 않아야 합니다. 긴 제목은 목록 카드에서 잘릴 수 있으므로 slug와 짧은 핵심 문구를 함께 보는 편이 안전합니다.

예를 들어 Hermes Curator 글을 확인한다면 hermes-curator-release-ops-guide, Curator 실전 사용법, 승인 경계, 주간 운영 루틴 같은 마커를 고릅니다. 뉴스 글이라면 제목 일부, 공식 출처 섹션, 핵심 수치, slug를 함께 봅니다.

점검 순서

이 순서를 자동화할 수 있지만, 마지막에는 최소 한 번 브라우저로 보는 것이 좋습니다. HTML 문자열에는 존재하지만 실제 카드 레이아웃에서 잘리거나 이상하게 보이는 경우가 있기 때문입니다.

상황별 예시

뉴스 글은 제목이 길어 목록에서 줄임표로 잘릴 수 있습니다. 이때 목록 확인은 전체 제목이 아니라 slug 링크와 짧은 주제어로 확인합니다. Hermes 팁 글은 표와 체크리스트가 많으므로 표가 깨지지 않는지 봅니다. VIBE 코딩 팁은 단계별 절차가 번호나 문단으로 읽히는지 확인해야 합니다. 사전 항목은 관련 용어 링크가 깨지지 않는지 봅니다.

GitHub 프로젝트 목록은 페이지가 길어 브라우저 snapshot이 최신 항목까지 도달하지 못할 수 있습니다. 이때는 HTML marker scan으로 몇 개 프로젝트명을 먼저 확인하고, 브라우저에서는 상단 렌더링과 콘솔 오류를 확인하는 방식이 낫습니다.

실패했을 때의 판단

상세는 바뀌었는데 목록이 안 바뀌면 목록 경로 revalidate가 빠진 것입니다. 목록은 바뀌었는데 상세가 404면 DB row의 slug/category가 잘못됐거나 상세 경로가 잘못됐을 수 있습니다. 둘 다 바뀌었지만 OG가 예전이면 metadata 생성 경로를 봐야 합니다. 콘솔 오류가 있으면 콘텐츠가 아니라 렌더러 코드 문제일 수 있으므로 무배포 루프를 멈춰야 합니다.

헤르메스는 실패를 숨기면 안 됩니다. “업로드는 됐지만 live smoke에서 목록 마커가 확인되지 않아 공개 완료로 보지 않음”처럼 멈춘 이유를 말해야 합니다. 이것이 자동화의 신뢰를 지키는 방식입니다.

체크리스트

• 상세 URL 200을 확인했는가?
• H1 또는 title에 새 제목이 보이는가?
• 본문 핵심 문구가 실제 HTML에 있는가?
• 목록 카드에서 slug 또는 짧은 마커가 보이는가?
• 브라우저 콘솔 오류가 없는가?
• 내부 문구와 비밀정보가 없는가?
• OG/title 확인이 필요한 글이면 별도로 확인했는가?
• 실패 시 업로드 완료가 아니라 보류로 보고했는가?

라이브 마커 점검은 작은 절차지만, 헤르메스가 운영자로 일한다는 증거입니다. 작업의 끝은 파일 저장이나 DB upsert가 아니라 독자가 보는 화면에서 확인되는 순간입니다.

마커를 설계하는 실전 방법

글을 작성할 때부터 live marker를 같이 정하면 검증이 쉬워집니다. 제목 전체, slug, 첫 문단 핵심어, 중간 섹션 하나, 출처 섹션 하나를 후보로 둡니다. 너무 일반적인 단어는 피합니다. 예를 들어 “AI”, “운영”, “검증”만으로는 다른 글과 구분되지 않습니다. 대신 “Curator 실전 사용법”, “DB 업로드 후 revalidate”, “승인 경계와 중단 기준”처럼 글의 정체성을 드러내는 문구를 고릅니다.

목록 페이지용 마커와 상세 페이지용 마커도 나눠야 합니다. 목록은 카드 제목, excerpt, 태그 정도만 보일 수 있습니다. 상세는 본문 전체와 표, 출처까지 볼 수 있습니다. 목록에서 본문 중간 문장을 찾으려 하면 실패가 아니라 잘못된 마커 설계입니다.

자동 점검과 브라우저 점검의 역할 분리

자동 점검은 빠릅니다. HTTP 200, HTML 길이, slug 존재, 제목 마커, blocked term 부재를 몇 초 안에 확인할 수 있습니다. 하지만 자동 점검은 시각적 문제를 놓칠 수 있습니다. 제목이 너무 길어 카드가 깨지는지, 표가 모바일에서 읽히는지, 버튼이 어색한 위치에 있는지, 브라우저 콘솔에 hydration 경고가 있는지는 실제 브라우저 점검이 더 잘 잡습니다.

따라서 헤르메스는 두 가지를 모두 해야 합니다. 먼저 자동 marker scan으로 큰 실패를 빠르게 잡고, 그다음 브라우저로 대표 페이지를 열어 사용자가 보는 화면을 확인합니다. 자동화와 눈검수는 경쟁 관계가 아니라 서로 다른 위험을 잡는 도구입니다.

품질 마커까지 포함하기

전문 콘텐츠 운영에서는 반영 여부만 확인하면 부족합니다. 품질 마커도 있어야 합니다. 뉴스 글이라면 “참고한 공식 출처”, 핵심 수치, 제품명, 바뀐 점, 의미 분석이 보여야 합니다. Hermes 팁이라면 “실전 순서”, “상황별 예시”, “중단 기준”, “체크리스트”가 있어야 합니다. VIBE 코딩 팁이라면 “언제 쓰는지”, “실수와 주의점”, “검증 방법”이 보여야 합니다.

이렇게 하면 live smoke가 단순 배포 확인을 넘어 품질 확인으로 확장됩니다. 글이 공개되었지만 핵심 섹션이 빠졌다면 성공이 아니라 보강 필요입니다. 헤르메스가 진짜 운영자라면 “보인다”와 “좋다”를 구분해야 합니다.

보고 예시

좋은 보고는 짧아도 충분합니다. “/news/example 200, 목록 카드에서 slug 확인, 상세 H1 확인, 공식 출처 섹션 확인, blocked term 없음, 콘솔 오류 없음”처럼 말하면 됩니다. 문제가 있으면 “DB upload 성공, revalidate 성공, 그러나 /news 목록에서 새 카드 마커 미확인. 공개 완료로 보지 않고 재검증 필요”라고 말해야 합니다.

이런 보고 습관이 쌓이면 운영자는 헤르메스를 믿을 수 있습니다. 반대로 검증 없는 완료 보고가 반복되면, 아무리 많은 글을 올려도 운영자는 다시 사람이 하나하나 확인해야 합니다.

적용 전 확인

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

실행 중 관찰

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

완료 후 기록

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