AI 선행 점검 운영법

헤르메스가 24시간 운영자로 일할 때 가장 위험한 순간은 실제 수정이 시작되기 직전입니다. 작업 지시가 자연어로 들어오면 AI 에이전트는 곧바로 파일을 바꾸거나 업로드를 시도하고 싶어 합니다. 그러나 좋은 운영자는 먼저 읽기 전용 선행 점검을 합니다. 이 단계는 일을 늦추는 절차가 아니라, 나중에 되돌리기 어려운 실수를 줄이는 안전장치입니다.

읽기 전용 선행 점검은 현재 상태를 증거로 고정하는 일입니다. 어떤 작업 범위인지, 이미 다른 자동화가 같은 영역을 만지고 있는지, 공개 사이트가 출발 전부터 깨져 있는지, 필요한 권한이 실제로 있는지, 민감정보를 보지 않고도 판단할 수 있는지 확인합니다. 이 점검을 마치면 에이전트는 “무엇을 바꿀지”보다 먼저 “무엇은 바꾸지 않을지”를 알게 됩니다.

왜 읽기 전용 점검이 첫 단계인가

24시간 AI 운영에서는 작은 착각이 연쇄 사고가 됩니다. 로컬에는 새 글이 있는 줄 알았지만 실제 공개 목록에는 이미 비슷한 글이 있을 수 있습니다. 어떤 테스트 실패가 이번 작업 때문이라고 생각했지만, 사실 출발 전부터 있던 실패일 수 있습니다. 반대로 출발 전 경고를 보지 못하면 정상 작업까지 원인으로 오해받습니다.

읽기 전용 점검의 핵심은 세 가지입니다. 첫째, 기준선을 만든다. 둘째, 충돌 위험을 발견한다. 셋째, 권한 경계를 확인한다. 이 세 가지가 있어야 이후의 변경, 업로드, 라이브 스모크, 요약 보고가 의미를 갖습니다. 기준선이 없으면 성공도 실패도 설명할 수 없습니다.

기준선은 완료 보고의 반대편이다

완료 보고는 “무엇이 끝났는가”를 말합니다. 기준선은 “시작할 때 무엇이었는가”를 말합니다. 운영자는 두 정보를 비교해야 합니다. 예를 들어 글을 하나 올리는 작업이라면 시작 전에 이미 같은 slug가 있는지, 목록 페이지가 정상 응답하는지, 공개 금지어가 보이지 않는지 확인합니다. 작업 후에는 같은 항목을 다시 확인해 변화가 의도한 범위 안에 있는지 봅니다.

기준선이 없다면 에이전트는 나쁜 소식을 숨기기 쉽습니다. “업로드는 성공했습니다”라는 말은 사실일 수 있지만, 시작 전부터 목록 페이지가 오래된 캐시를 보여주고 있었다면 공개 완료라고 말하기 어렵습니다. 읽기 전용 점검은 이런 모호함을 줄입니다.

운영 순서

읽기 전용 선행 점검은 길게 만들 필요가 없습니다. 중요한 것은 매번 같은 순서로 실행하고, 쓰기 작업으로 넘어가기 전에 중단 기준을 적용하는 것입니다.

이 순서에서 중요한 점은 “읽기 전용”이라는 단어입니다. 콘텐츠를 만들거나, 데이터베이스에 반영하거나, 캐시를 갱신하거나, 파일을 옮기는 행동은 아직 하지 않습니다. 먼저 보는 것, 세는 것, 비교하는 것, 마커를 고르는 것만 합니다.

작업 목적과 비목적

좋은 선행 점검은 작업 목적을 좁히면서 시작합니다. “헤르메스 콘텐츠 개선”은 너무 넓습니다. “헤르메스 운영 팁 한 건을 DB-only 방식으로 공개하고, 임시 원본을 정리한다”처럼 결과와 경계를 함께 써야 합니다. 비목적도 중요합니다. 예를 들어 이 작업은 코드 배포가 아니며, 크론 작업을 새로 만들지 않으며, 기존 콘텐츠를 대량 수정하지 않는다고 정합니다.

비목적이 없으면 AI는 품질을 높인다는 이유로 주변 작업을 계속 벌립니다. 운영자는 좋은 아이디어라도 이번 범위 밖이면 다음 큐로 넘겨야 합니다. 범위가 좁을수록 검증은 강해집니다.

공개 화면 출발점 확인

쓰기 전에 대표 경로의 응답을 확인합니다. 헤르메스 글이라면 목록과 기존 상세 글이 기본입니다. 사이트 운영 작업이라면 홈, Q&A, 헤르메스, 뉴스, 사전처럼 영향받을 수 있는 섹션을 봅니다. 이때 목표는 깊은 품질 감사가 아니라 출발 전 장애를 분리하는 것입니다.

예를 들어 목록이 200으로 응답하지만 첫 화면에 오류가 보인다면 새 글 업로드를 계속하기보다 먼저 장애 여부를 분류해야 합니다. 공개 페이지가 이미 흔들리는 상태에서 새 콘텐츠를 올리면 이후 문제의 원인이 섞입니다.

권한과 보안 경계

읽기 전용 점검은 보안에도 직접 연결됩니다. 에이전트가 작업을 시작하기 전에 어떤 값을 출력해도 되는지, 어떤 파일이나 설정은 존재 여부만 볼지, 어떤 명령은 이번 작업에서 금지되는지 정해야 합니다. 안전한 운영은 비밀값을 잘 보관하는 것만이 아니라, 보고서와 로그에 불필요한 식별자가 남지 않게 하는 것입니다.

권한 경계는 다음처럼 나눌 수 있습니다.

이 표는 에이전트에게 매우 유용합니다. “허용된 것만 한다”는 말보다 어떤 범주의 행동이 가능한지 더 분명하기 때문입니다. 특히 DB-only 운영에서는 코드 배포가 없으므로 공개 반영과 원본 정리의 경계가 흐려지기 쉽습니다. 업로드는 허용되더라도 Git 작업은 허용되지 않을 수 있고, 라이브 확인은 허용되더라도 민감 설정 출력은 허용되지 않습니다.

출력 경계는 검증 품질의 일부다

좋은 보고서는 많은 정보를 담는 것이 아니라 안전한 증거를 담습니다. 예를 들어 “대상 slug가 목록과 상세에서 확인됨”, “revalidate 응답이 정상으로 돌아옴”, “임시 JSON이 공개 콘텐츠 경로에 남지 않음”은 안전한 증거입니다. 반면 운영 환경의 실제 값, 개인 인증 문자열, 내부 연결 정보는 보고서에 필요하지 않습니다.

운영자는 에이전트가 실패했을 때도 같은 원칙을 지키게 해야 합니다. 실패 로그 전체를 붙여 넣는 대신, 실패 단계와 비민감 요약만 남깁니다. 필요하면 원본 로그는 로컬 비공개 보관 위치에 두고, 공개 보고에는 “검증 단계에서 스키마 오류 발생”처럼 충분한 수준으로 줄입니다.

상황별 예시

예시 1. DB-only 헤르메스 팁 발행

목표는 글 한 건을 공개하는 것입니다. 선행 점검에서는 먼저 같은 slug가 없는지, 최근 헤르메스 주제가 무엇인지, 이번 글이 기존 글과 다른 독자 문제를 해결하는지 확인합니다. 그다음 공개 목록이 정상 응답하는지 봅니다. 여기까지는 아무것도 바꾸지 않습니다.

초안이 만들어진 뒤에도 업로드 전에는 읽기 전용 품질 검사가 한 번 더 필요합니다. 본문이 충분한지, 상황별 예시와 운영 순서와 권한 경계와 검증 방법과 중단 기준이 들어 있는지, 공개 본문에 내부용 표현이나 민감한 단어가 남지 않았는지 확인합니다. 이 검사를 통과해야 업로드합니다. 업로드 후에는 목록과 상세에서 제목 마커를 확인하고, 임시 원본을 공개 콘텐츠 경로 밖으로 옮깁니다.

예시 2. 배포 검증 작업

배포 검증에서도 선행 점검은 중요합니다. 출발 전 대표 경로가 이미 실패하고 있다면 새 배포의 문제가 아닐 수 있습니다. 반대로 출발 전에는 정상인데 배포 후 특정 상세 페이지만 깨진다면 변경 범위를 좁힐 수 있습니다. 그래서 배포 전에는 대표 경로, 공개 금지어, 브라우저 콘솔, 단일 H1 같은 기본 상태를 읽기 전용으로 기록합니다.

이후 배포가 끝나면 같은 항목을 다시 봅니다. 차이가 생긴 곳만 원인 후보가 됩니다. 이 방식은 에이전트가 “전체 사이트가 이상하다”는 막연한 결론을 내리지 않게 합니다.

예시 3. 크론 작업 충돌 확인

자동화가 자주 도는 사이트에서는 같은 시간대에 여러 작업이 시작될 수 있습니다. 선행 점검은 내 작업이 다른 작업의 흔적을 덮어쓰지 않게 합니다. 예를 들어 임시 콘텐츠 파일이 이미 있다면 그것이 현재 작업의 이전 단계인지, 다른 작업의 산출물인지 구분해야 합니다. 구분할 수 없으면 진행을 멈추고 보고해야 합니다.

이때 중요한 것은 임의로 정리하지 않는 것입니다. 깨끗한 작업 공간을 만들겠다는 이유로 다른 작업의 파일을 지우면 충돌이 더 커집니다. 읽기 전용 점검은 발견과 분류를 위한 것이지, 남의 흔적을 제거하는 절차가 아닙니다.

검증 방법

읽기 전용 선행 점검 자체도 검증되어야 합니다. 운영자는 다음 네 가지 증거를 남기면 충분합니다.

첫째, 중복 검증입니다. 대상 slug가 기존 공개 콘텐츠와 충돌하지 않는지 확인합니다. 둘째, 품질 검증입니다. 필수 섹션과 본문 깊이와 FAQ 수와 렌더러 안전성을 확인합니다. 셋째, 공개 검증입니다. 목록과 상세 URL이 200으로 응답하고 제목 마커가 보이는지 봅니다. 넷째, 정리 검증입니다. 이번 작업이 만든 공개 콘텐츠 경로의 임시 파일이 남아 있지 않은지 확인합니다.

브라우저 확인도 가능하면 포함합니다. 문자열 검사는 빠르지만 화면에서 카드가 어떻게 보이는지, 본문이 지나치게 긴 제목처럼 렌더링되지 않는지, 콘솔 오류가 있는지는 브라우저가 더 잘 보여줍니다.

실패 시 중단 기준

읽기 전용 선행 점검에서 다음 신호가 보이면 작업을 멈춰야 합니다.

• 작업 목적이 한 문장으로 좁혀지지 않는다.
• 같은 slug나 거의 같은 주제가 이미 있다.
• 공개 목록 또는 상세 기본 경로가 출발 전부터 장애 상태다.
• 이번 작업과 무관한 변경 흔적을 안전하게 분리할 수 없다.
• 품질 검사에서 필수 섹션이나 상황별 예시가 빠졌다.
• 본문 또는 보고에 민감정보나 내부 전용 표현이 들어갈 위험이 있다.
• 업로드 후 목록이나 상세에서 제목 마커가 확인되지 않는다.
• 임시 원본을 정리하지 못해 공개 콘텐츠 경로가 더러워진다.

중단은 실패가 아닙니다. 중단 기준을 지킨 덕분에 더 큰 사고를 막은 것입니다. 헤르메스 운영에서 가장 나쁜 결과는 “모르지만 진행했다”입니다. 좋은 결과는 “여기까지 확인했고, 이 조건 때문에 멈췄다”입니다.

실수와 주의점

첫 번째 실수는 선행 점검을 체크박스로만 보는 것입니다. 명령 몇 개를 실행했더라도 판단이 없다면 점검이 아닙니다. “목록 200”이라는 결과는 “목록이 출발 전 정상”이라는 판단으로 이어져야 합니다.

두 번째 실수는 읽기 전용 단계에서 쓰기 행동을 섞는 것입니다. 예를 들어 중복 글을 발견하고 바로 지우거나, 실패한 임시 파일을 임의로 덮어쓰는 행동은 선행 점검이 아닙니다. 발견한 뒤에는 범위를 다시 정하거나 중단해야 합니다.

세 번째 실수는 공개 안전 스캔을 마지막에만 하는 것입니다. 마지막 스캔은 반드시 필요하지만, 초안 단계에서 이미 위험한 표현을 줄여야 합니다. 공개 글은 독자가 보는 문서입니다. 운영자만 이해하는 은어, 내부 작업장 같은 표현, 민감한 설정 이름은 독자에게 도움이 되지 않습니다.

네 번째 실수는 원본 정리를 잊는 것입니다. DB-only 운영은 Git 작업을 하지 않기 때문에 임시 JSON이 남아 있으면 다음 실행에서 중복 또는 local-only 혼란을 만듭니다. 성공한 원본은 비공개 보관 위치로 옮기고, 실패한 원본은 초안 보관 위치로 옮겨야 합니다.

검증 체크리스트

• 작업 목적과 비목적이 한 문장씩 정리됐는가?
• 기존 콘텐츠와 slug 중복을 확인했는가?
• 대표 공개 경로가 출발 전 정상인지 확인했는가?
• 이번 작업에서 금지된 행동을 확인했는가?
• 권한 경계와 출력 경계를 분리했는가?
• 상황별 예시가 최소 두 개 이상 있는가?
• 운영 순서가 읽기 전용 단계와 쓰기 단계를 구분하는가?
• 라이브 스모크에서 목록과 상세 제목 마커를 확인할 계획이 있는가?
• 실패 시 중단 기준이 명확한가?
• 임시 원본 정리까지 완료 조건에 포함했는가?

다음 단계

읽기 전용 선행 점검은 모든 운영 글의 앞단에 붙일 수 있는 공통 습관입니다. 콘텐츠 발행에는 중복과 품질 기준선을, 배포 검증에는 출발 전 공개 상태를, 크론 운영에는 충돌 위험을, 비용 관리에는 예상 작업량과 토큰 예산을 연결하면 됩니다.

처음에는 절차가 조금 느려 보일 수 있습니다. 그러나 운영이 반복될수록 선행 점검은 시간을 절약합니다. 실패 원인을 빠르게 좁히고, 다음 에이전트가 이어받을 증거를 남기며, 사람이 보지 않는 시간에도 AI가 멈춰야 할 때 멈추게 합니다. 헤르메스의 자율성은 더 많은 권한에서 나오지 않습니다. 읽고, 판단하고, 검증한 뒤에만 움직이는 습관에서 나옵니다.