AI 검증 루프 운영법

헤르메스가 작업을 끝냈다고 말하기 전에 운영자는 한 가지를 물어야 합니다. “무엇으로 확인했는가?” AI 에이전트는 빠르게 파일을 고치고, 글을 쓰고, DB를 업데이트할 수 있지만, 검증 없는 완료 보고는 운영 리스크입니다. 검증 루프는 헤르메스 작업의 끝을 정의하는 절차입니다.

검증 루프의 목적

완료 선언보다 증거가 먼저다

검증은 단일 테스트 명령이 아닙니다. 작업 범위가 맞는지, 결과가 실제로 반영됐는지, 공개 페이지가 깨지지 않았는지, 내부 정보가 노출되지 않았는지, 실패했을 때 어디서 멈췄는지를 확인하는 전체 흐름입니다. 좋은 검증 루프는 에이전트의 자신감 대신 증거를 남깁니다.

예를 들어 글을 보강했다면 JSON validation, DB upload, revalidate, 상세 페이지 200, 목록 카드 확인, 콘솔 오류 없음이 증거입니다. 코드 변경이라면 lint, build, tests, local preview, live smoke까지 필요합니다. 사전 항목을 고쳤다면 relatedSlugs 무결성과 detail page 렌더링을 확인해야 합니다.

검증의 네 단계

이 네 단계를 통과하지 못하면 완료가 아니라 보류입니다. 특히 자동화된 콘텐츠 운영에서는 런타임 검증과 안전 검증을 생략하면 얕은 글과 내부 문구가 공개됩니다.

상황별 검증 기준

섹션마다 통과 기준을 다르게 둔다

AI 뉴스는 공식 출처, 제목의 사실성, 본문 깊이, 출처 섹션을 봐야 합니다. Hermes 팁은 실제 사용 순서, 상황별 예시, 중단 기준, 체크리스트가 있어야 합니다. VIBE 코딩 팁은 독자가 따라 할 작업 순서와 실패했을 때 확인할 방법이 필요합니다. GitHub 프로젝트는 별점보다 “왜 이 프로젝트가 VIBE 코딩에 도움이 되는가”를 설명해야 합니다.

검증 기준은 섹션별로 달라야 합니다. 모든 글에 같은 템플릿을 강제하면 전문성이 떨어집니다. 하지만 공통 기준도 있습니다. 얕은 요약 금지, 내부 문구 금지, 출처 없는 주장 금지, live smoke 없는 완료 보고 금지입니다.

중단 기준

실패를 감추지 않는 것이 운영 능력이다

헤르메스는 검증 실패를 고집으로 밀어붙이면 안 됩니다. 테스트가 실패했는데 원인을 모르면 중단해야 합니다. 공개 페이지에 내부 문구가 보이면 업로드를 멈춰야 합니다. DB 업로드는 됐지만 목록 마커가 확인되지 않으면 공개 완료로 보고하면 안 됩니다. 코드 변경이 필요한데 데이터 루프로 해결하려고 하면 안 됩니다.

중단은 실패가 아니라 운영 능력입니다. 사람 운영자에게 “여기서 멈춰야 합니다”라고 말할 수 있어야 헤르메스가 신뢰받습니다.

증거 패킷으로 보고하기

완료 보고에는 변경 대상, 실행한 검증, 결과, 남은 위험이 들어가야 합니다. “수정했습니다”가 아니라 “post:validate 통과, DB upload 성공, revalidate 성공, /hermes/slug 200, 목록 marker 확인, console error 0”처럼 말해야 합니다. 실패 보고도 마찬가지입니다. “안 됨”이 아니라 “상세 200, 목록 marker 미확인, revalidate 범위 재검토 필요”라고 남겨야 다음 작업자가 이어받을 수 있습니다.

체크리스트

• 작업 범위가 원래 요청과 일치하는가?
• 변경 파일이 의도한 범위 안에 있는가?
• 필수 validation/test를 실행했는가?
• 실제 공개 URL에서 200과 marker를 확인했는가?
• 브라우저 콘솔 오류를 봤는가?
• 내부 문구와 비밀정보가 없는가?
• 실패 시 중단 기준을 지켰는가?
• 완료 보고가 증거 중심인가?

검증 루프는 속도를 늦추는 장치가 아닙니다. 검증이 있어야 헤르메스가 더 많은 일을 맡아도 운영자가 다시 전부 확인하지 않아도 됩니다. AI 자동화의 진짜 생산성은 빠른 생성이 아니라 믿을 수 있는 완료에서 나옵니다.

검증을 작업 유형별로 다르게 설계하기

콘텐츠 작업은 스키마와 live smoke가 핵심입니다. 제목, slug, category, 본문, 출처, 공개 금지어, 목록 노출을 확인합니다. 코드 작업은 lint, build, test, diff review, local preview가 핵심입니다. 데이터 작업은 row count, 대상 id, rollback 가능성, 공개 반영 경로를 확인합니다. 외부 API나 계정이 관련된 작업은 권한 범위와 실패 시 비활성화 방법을 반드시 봐야 합니다.

모든 작업에 같은 검증을 적용하면 느리고 부정확합니다. 반대로 작업마다 검증을 대충 고르면 빠르지만 위험합니다. 좋은 운영은 작업 유형별 최소 검증 세트를 미리 정해두는 것입니다. 헤르메스는 작업 시작 시 “이 작업은 콘텐츠 변경이므로 post validation, DB upload, revalidate, live smoke를 실행한다”처럼 검증 계획을 먼저 세워야 합니다.

브라우저 검증이 필요한 이유

HTTP 200은 충분하지 않습니다. 페이지가 200이어도 제목이 잘리거나, 표가 모바일에서 깨지거나, 내부 문구가 카드에 보이거나, 콘솔에 hydration 오류가 있을 수 있습니다. 브라우저 검증은 이런 사용자 경험 문제를 잡습니다. 특히 Q&A, Hermes, VIBE 코딩처럼 긴 본문과 목록 카드가 함께 있는 페이지는 HTML 문자열 검사만으로 부족합니다.

브라우저 검증에서는 H1, 첫 문단, 대표 표, 링크, 콘솔 오류를 봅니다. 필요하면 스크린샷까지 남길 수 있습니다. 자동화된 검사는 빠른 필터이고, 브라우저 검증은 방문자 시점의 최종 확인입니다.

검증 실패를 다루는 태도

검증 실패가 나오면 바로 고치는 것이 항상 정답은 아닙니다. 원인이 현재 작업 범위 안에 있으면 고칩니다. 그러나 다른 작업자가 만든 dirty worktree, unrelated test failure, 기존 접근성 문제처럼 범위를 벗어나면 현재 작업에 섞지 말고 별도 follow-up으로 분리해야 합니다. 검증 루프는 모든 문제를 한 번에 고치기 위한 것이 아니라, 현재 변경이 안전한지 판단하기 위한 것입니다.

헤르메스가 사이트 운영자라면 이 구분을 잘해야 합니다. 작은 콘텐츠 보강을 하다가 unrelated 코드 리팩터링까지 건드리면 오히려 사고가 납니다. 검증은 범위를 넓히는 핑계가 아니라 범위를 지키는 장치입니다.

완료 보고의 품질

전문적인 완료 보고는 사용자가 다시 물어보지 않아도 됩니다. 무엇을 고쳤고, 어디에 반영됐고, 어떤 검증을 통과했고, 무엇이 남았는지 한 번에 보여줘야 합니다. “테스트는 못 했지만 아마 될 것” 같은 표현은 운영 보고가 아닙니다. 못 했으면 못 한 이유와 위험을 말해야 합니다.

완료 보고는 짧아도 됩니다. 하지만 증거는 있어야 합니다. URL, 상태 코드, 마커, 테스트 이름, 실패 없음, 남은 이슈를 포함하면 충분합니다. 이것이 쌓이면 다음 작업자가 과거 작업을 다시 추측하지 않아도 됩니다.