AI 시간 제한 승인 운영법

24시간 헤르메스 운영에서 가장 위험한 순간은 AI가 아무 제약 없이 계속 실행되는 때가 아닙니다. 더 흔한 위험은 “이번 한 번만 열어 둔 승인”이 끝난 뒤에도 사실상 계속 열린 상태로 남는 상황입니다. 시간 제한 승인은 자동화가 멈춰야 할 시간을 먼저 정하고, 그 시간 안에서만 작업 범위와 권한을 인정하는 운영 방식입니다.

이 글은 모바일 원격 운영, 크론 실행, DB-only 콘텐츠 업로드, 배포 확인처럼 사람이 계속 화면 앞에 앉아 있지 않은 상황에서 헤르메스가 어디까지 자동으로 진행하고 어디서 멈춰야 하는지 정하는 실전 기준을 다룹니다. 핵심은 “신뢰하되 감시한다”가 아니라 “짧게 열고, 증거로 닫는다”입니다.

왜 시간 제한 승인이 필요한가

헤르메스 같은 AI 에이전트는 작업을 길게 이어 갈수록 맥락을 많이 모읍니다. 맥락이 많아지는 것은 장점이지만, 동시에 오래된 가정이 계속 살아남는 문제가 생깁니다. 처음에는 단순한 글 업로드였는데 중간에 검증 실패가 나오고, 검증을 고치려다 관련 없는 파일을 보고, 다시 라이브 페이지를 확인하다 보면 작업 범위가 서서히 넓어질 수 있습니다.

시간 제한 승인은 이 흐름을 끊습니다. 승인에는 시작 시간, 만료 시간, 허용 작업, 금지 작업, 검증 기준, 보고 기준이 함께 있어야 합니다. 승인 시간이 지나면 에이전트는 “조금만 더”가 아니라 “현재 증거를 보고하고 멈춤”을 기본값으로 삼아야 합니다.

특히 무인 cron-run에서는 이 기준이 중요합니다. 사용자가 옆에서 “그건 하지 마”라고 말할 수 없기 때문입니다. 운영자가 미리 정한 시간 상자와 중단 기준이 없으면 자동화는 성실하게 과도한 일을 하다가 오히려 공개 품질을 해칠 수 있습니다.

승인 단위는 작업이 아니라 책임이다

좋은 승인 문장은 “헤르메스 글 하나 작성”처럼 느슨하지 않습니다. 책임 단위로 쪼개야 합니다. 예를 들어 “Hermes 운영 팁 1건을 DB-only로 작성하고 검증, 업로드, live smoke, 원본 정리까지 수행한다”는 책임이 명확합니다. 반대로 “사이트를 개선한다”는 너무 넓습니다.

책임 단위에는 반드시 결과물이 있어야 합니다. 글이라면 slug, 제목, 검증 결과, 업로드 결과, 공개 URL, 정리 위치가 결과물입니다. 배포 확인이라면 대상 경로, HTTP 상태, 콘텐츠 marker, 브라우저 콘솔, 차단어 스캔, 단일 H1 여부가 결과물입니다. 비용 점검이라면 대상 기간, 작업 수, 재시도 수, 예상 낭비 원인, 다음 상한 조정안이 결과물입니다.

책임 단위가 명확하면 승인이 만료되어도 이어받기 쉽습니다. 다음 세션은 “무엇을 하려던 중이었나”가 아니라 “어떤 책임이 완료됐고 어떤 증거가 남았나”부터 판단하면 됩니다.

운영 순서

시간 제한 승인 운영은 아래 순서로 진행합니다.

1. 읽기 전용 선행 점검을 먼저 한다. 현재 작업 상태, 기존 콘텐츠, 공개 페이지, 이전 실패 신호를 확인한다.
2. 이번 승인 범위를 한 문장으로 고정한다. “한 건의 Hermes 운영 팁을 DB-only로 게시한다”처럼 작게 잡는다.
3. 만료 조건을 정한다. 시간, 재시도 횟수, 검증 실패 횟수, 공개 안전 실패, 외부 서비스 장애 같은 조건을 함께 둔다.
4. 허용된 쓰기 위치를 제한한다. 임시 JSON, 업로드 대상 DB, 무시되는 보관 폴더처럼 필요한 곳만 쓴다.
5. 품질 기준을 먼저 검사한다. 본문 깊이, 상황별 예시, 운영 순서, 권한 경계, 검증 방법, 실패 시 중단 기준을 확인한다.
6. 업로드와 revalidate를 분리해서 본다. DB 반영이 되었는지, 공개 캐시 갱신 요청이 성공했는지, live smoke가 통과했는지를 각각 기록한다.
7. 원본 정리와 최종 상태 확인으로 닫는다. content 경로에 새 untracked 파일이 남아 있지 않아야 하며, 보고는 짧고 증거 중심이어야 한다.

이 순서에서 중요한 것은 검증을 뒤로 미루지 않는 것입니다. “일단 올리고 나중에 보자”는 무인 운영에서 가장 위험한 습관입니다. 시간 제한 승인은 올리기 전 품질, 올린 뒤 공개 상태, 끝난 뒤 정리 상태를 모두 같은 작업 안에서 닫습니다.

상황별 예시

모바일에서 원격으로 승인하는 경우

운영자가 휴대폰으로 “오늘은 Hermes 팁 1건만 올려도 된다”고 승인했다고 가정해 봅시다. 이때 에이전트는 사이트 구조 변경, 기존 글 대량 수정, 새 cron 작업 생성까지 확대하면 안 됩니다. 모바일 승인은 보통 문맥이 짧고 화면 확인이 제한적이기 때문에 더 좁게 해석해야 합니다.

좋은 실행은 새 글 1건 작성, post validation, 품질 스캔, DB 업로드, /hermes 목록과 상세 페이지 확인, 원본 보관, 최종 보고입니다. 나쁜 실행은 글을 쓰다가 관련 테스트가 마음에 들지 않는다고 코드 구조를 바꾸거나, 배포까지 필요하다고 판단해 git 작업을 시작하는 것입니다. 시간 제한 승인은 모바일 승인일수록 더 강한 브레이크가 되어야 합니다.

cron-run이 이전 작업 흔적을 발견한 경우

무인 실행이 시작됐는데 content 경로에 이전 초안이 남아 있거나, 다른 작업이 만든 untracked 파일이 보일 수 있습니다. 이때 에이전트는 자동으로 지우거나 합치면 안 됩니다. 자신의 승인 범위에 해당하는 파일인지 먼저 판단해야 합니다. 현재 주제와 slug가 일치하고 실패한 초안임이 명확하면 이어받을 수 있지만, 관련성이 불확실하면 건드리지 않고 위험으로 보고해야 합니다.

시간 제한 승인의 핵심은 정리 욕심을 줄이는 것입니다. 깨끗한 작업 트리는 중요하지만, 남의 작업을 정리하는 것은 별도 승인입니다. DB-only 콘텐츠 작업의 책임은 자신이 만든 임시 JSON을 남기지 않는 데까지입니다.

업로드는 성공했지만 live smoke가 실패한 경우

DB 업로드가 성공했는데 상세 페이지가 500을 반환하거나 목록에서 새 글이 보이지 않을 수 있습니다. 이때는 새 글이 공개되었다고 보고하면 안 됩니다. 먼저 재검증 가능한 증거를 모읍니다. 상세 URL 상태, 목록 URL 상태, API 응답에서 slug 존재 여부, revalidate 응답, 차단어 스캔 결과를 나눠 봅니다.

만약 공개 페이지가 계속 실패하면 중단 기준에 도달한 것입니다. 같은 세션에서 무한 재시도를 하지 말고, 업로드 결과와 실패 증거를 보고해야 합니다. 임시 원본은 실패 원인 분석이 가능하도록 draft 보관 위치로 옮기고, 공개 페이지가 이미 부분 반영됐다면 그 사실을 명확히 남깁니다.

비용이 예상보다 커지는 경우

긴 글 작성과 검증은 토큰 예산을 빠르게 소모할 수 있습니다. 시간 제한 승인은 비용에도 적용됩니다. 초안이 품질 기준을 한 번 통과하지 못했다면 보강은 허용할 수 있지만, 같은 주제에서 반복적으로 깊이 부족이 나오면 새 주제를 고르는 것이 아니라 중단하고 품질 실패로 분류해야 합니다.

비용 통제의 핵심은 “조금 더 쓰면 좋아질 것 같다”는 감각을 절차로 제한하는 것입니다. 한 번의 보강으로 상황별 예시, 검증 방법, 실패 기준이 채워지지 않으면 그 초안은 공개 준비가 안 된 것입니다.

권한과 보안 경계

시간 제한 승인은 권한을 열어 주는 문서가 아니라 권한을 닫는 문서입니다. 에이전트가 사용할 수 있는 파일 경로, 실행할 수 있는 명령, 출력할 수 있는 정보, 변경할 수 있는 공개 영역을 미리 좁혀야 합니다. 민감정보는 값은 물론 식별 가능한 연결 문자열이나 인증 문구도 공개 보고에 남기지 않는 것이 원칙입니다.

DB-only 콘텐츠 운영에서는 권한 경계가 더 선명해야 합니다. 허용되는 쓰기는 임시 콘텐츠 파일 생성, 검증 통과 후 업로드, 성공 후 무시되는 보관 위치로 이동하는 정도입니다. git 작업, cron 설정 변경, 배포 트리거, 운영 문서 수정은 별도 승인 없이는 범위 밖입니다. 이 선을 지키면 콘텐츠 생산 속도와 저장소 안정성을 동시에 얻을 수 있습니다.

보안 경계는 보고 방식에도 적용됩니다. 최종 보고에는 결과와 상태만 담고, 로컬 설정 파일 이름이나 인증값을 유추하게 만드는 문장은 피합니다. “업로드 성공, revalidate 성공, live smoke 200”이면 충분합니다. 실패해도 “인증값이 없었다”처럼 값이 없는 상태만 말하고, 실제 값이나 토큰 모양은 절대 남기지 않습니다.

검증 방법

검증은 네 겹으로 나눕니다.

첫째, 구조 검증입니다. JSON shape, category, status, slug, SEO 필드, FAQ 수가 맞는지 확인합니다. 둘째, 품질 검증입니다. 본문이 충분히 깊고, 상황별 예시와 운영 순서가 있으며, 권한과 보안 경계, 검증 방법, 실패 시 중단 기준이 명시되어야 합니다. 셋째, 업로드 검증입니다. DB 반영과 revalidate 응답을 분리해서 확인합니다. 넷째, 공개 검증입니다. 목록 페이지와 상세 페이지가 200을 반환하고, 새 slug와 제목 marker가 보이며, 공개 금지어와 내부 문구가 노출되지 않아야 합니다.

브라우저 콘솔 확인도 가능하면 포함합니다. HTTP 200은 서버가 응답했다는 뜻이지 사용자가 오류 없이 읽을 수 있다는 뜻은 아닙니다. 목록에서 상세로 이동하는 사용자 흐름, 제목 렌더링, 본문 첫 섹션, FAQ 영역, 콘솔 오류를 함께 보면 공개 품질을 더 정확히 판단할 수 있습니다.

실패 시 중단 기준

아래 조건이 나오면 에이전트는 같은 승인 안에서 작업을 확장하지 말고 멈춰야 합니다.

• 품질 스캔이 두 번 이상 깊이 부족을 지적한다.
• 공개 금지어 또는 내부 언어가 live smoke에서 발견된다.
• 업로드는 성공했지만 상세 페이지가 반복해서 4xx 또는 5xx를 반환한다.
• revalidate가 실패했고 즉시 공개 반영을 약속할 수 없다.
• 다른 작업의 파일이나 상태와 충돌할 가능성이 있다.
• 허용 범위 밖의 git, cron, 배포, 스키마 변경이 필요해 보인다.
• 민감정보가 출력될 가능성이 있는 명령을 실행해야 한다.

중단은 실패가 아닙니다. 중단 기준을 지키는 것은 24시간 운영에서 사용자를 보호하는 방법입니다. 좋은 중단 보고는 “왜 못 했는지”보다 “어디까지 안전하게 끝냈고 무엇을 다음 승인에서 봐야 하는지”를 말합니다.

승인 만료 보고서 형식

마지막 보고는 길 필요가 없습니다. slug, 검증 결과, 업로드와 revalidate 상태, live smoke 결과, 원본 보관 위치, 작업 트리 상태, 남은 위험을 포함하면 충분합니다. 중요한 것은 모든 항목이 증거 기반이어야 한다는 점입니다. “정상 같음”이 아니라 “목록 200, 상세 200, API marker 확인, 차단어 0건”처럼 적어야 다음 운영자가 이어받을 수 있습니다.

보고서가 간결할수록 모바일에서도 읽기 쉽습니다. 헤르메스의 장점은 긴 작업을 대신하는 것이지만, 운영자에게 전달되는 결과는 짧아야 합니다. 시간 제한 승인은 실행을 제한하고, 증거 보고는 주의를 절약합니다.

운영 성숙도별 적용법

처음에는 시간 제한 승인을 너무 복잡하게 만들 필요가 없습니다. 1단계는 “한 세션, 한 책임, 한 보고”입니다. 예를 들어 Hermes 팁 하나를 작성한다면 그 글 하나만 범위로 삼고, 품질 검증과 공개 확인을 끝내면 바로 닫습니다. 이 단계에서는 승인 시간이 짧아야 합니다. 작업이 길어지면 글의 품질보다 작업 확장이 더 큰 위험이 됩니다.

2단계는 “상태 전환을 기록하는 승인”입니다. 초안, 검증 통과, 업로드 완료, live smoke 완료, 원본 보관 같은 상태를 명확히 나눕니다. 상태가 바뀔 때마다 증거가 있어야 합니다. 검증 통과는 명령 결과, 업로드 완료는 업로드 응답, live smoke 완료는 HTTP 상태와 marker, 원본 보관은 파일 위치로 증명합니다. 상태 전환이 증거 없이 말로만 남으면 다음 운영자가 다시 확인해야 하므로 자동화 이점이 사라집니다.

3단계는 “반복 작업의 시간 예산을 조정하는 승인”입니다. 어떤 종류의 글은 초안 작성보다 공개 안전 스캔에 시간이 더 걸리고, 어떤 작업은 업로드보다 브라우저 확인이 더 오래 걸립니다. 몇 번의 실행 기록이 쌓이면 승인 시간을 무작정 늘리는 대신 병목을 분리할 수 있습니다. 글 작성 1회, 보강 1회, 업로드 1회, live smoke 1회처럼 단계별 상한을 두면 무인 운영이 더 예측 가능해집니다.

체크리스트를 승인 문장으로 바꾸는 법

체크리스트는 많을수록 안전해 보이지만, 운영자가 읽기 어려우면 실행 중에 흐려집니다. 그래서 시간 제한 승인에서는 체크리스트를 짧은 승인 문장으로 바꾸는 것이 좋습니다. “이 세션은 Hermes 팁 1건만 다룬다. 새 코드와 git 작업은 하지 않는다. 품질 스캔, 업로드, 목록과 상세 live smoke, 원본 보관까지 완료하지 못하면 실패로 보고한다.” 이런 문장은 에이전트가 범위를 해석하기 쉽고, 사람이 결과를 검수하기도 쉽습니다.

반대로 “필요한 것은 알아서 처리” 같은 문장은 승인처럼 보이지만 실제로는 범위가 없습니다. AI 에이전트는 목표를 달성하려고 노력하기 때문에, 범위가 없으면 선의로 불필요한 변경을 시도할 수 있습니다. 좋은 승인 문장은 해야 할 일뿐 아니라 하지 말아야 할 일을 같이 말합니다.

다음 운영자를 위한 증거 패킷

시간 제한 승인의 마지막 산출물은 공개 페이지가 아니라 증거 패킷입니다. 공개 페이지가 정상이어도 증거가 없으면 다음 세션은 다시 처음부터 확인해야 합니다. 증거 패킷에는 작업 범위, slug, 검증 명령, 업로드 상태, revalidate 상태, live smoke 경로, 차단어 스캔 결과, 원본 보관 위치, 남은 위험이 들어갑니다.

증거 패킷은 길게 쓰는 것이 목적이 아닙니다. 핵심은 재현 가능성입니다. 다음 운영자가 같은 경로를 열어 같은 marker를 확인할 수 있어야 합니다. 실패한 경우에도 마찬가지입니다. 어디서 실패했는지, 업로드 전인지 후인지, 공개 페이지에 부분 반영이 있었는지, 원본이 draft로 보관됐는지를 남기면 복구 시간이 줄어듭니다.

흔한 실수와 예방책

첫 번째 실수는 승인 시간이 남았다는 이유로 다른 일을 시작하는 것입니다. 시간 제한 승인은 남은 시간을 모두 쓰라는 뜻이 아닙니다. 책임이 끝나면 즉시 닫아야 합니다. 남은 시간은 보너스가 아니라 안전 여유입니다.

두 번째 실수는 공개 확인 전에 원본을 치우는 것입니다. 업로드가 성공했더라도 상세 페이지가 정상인지 보기 전에는 원본이 아직 증거입니다. 공개 확인이 끝난 뒤에 보관 위치로 옮겨야 문제가 생겼을 때 같은 원본으로 다시 검증할 수 있습니다.

세 번째 실수는 실패를 고치기 위해 범위를 넓히는 것입니다. 예를 들어 live smoke가 실패했을 때 코드 수정이 필요해 보이면, 그것은 DB-only 콘텐츠 승인 범위를 넘어선 신호입니다. 이때는 실패 증거를 보고하고 별도 코드 작업 승인으로 넘겨야 합니다. 범위 밖 수정을 즉흥적으로 시작하면 시간 제한 승인의 의미가 사라집니다.

네 번째 실수는 민감정보 경계를 경고 문구 안에서 흐리는 것입니다. 공개 글이나 보고서에는 실제 인증값뿐 아니라 불필요하게 구체적인 내부 식별자도 남기지 않는 편이 안전합니다. 독자에게 필요한 것은 “민감정보를 출력하지 않는다”는 원칙과 “상태만 보고한다”는 절차이지 내부 설정의 생김새가 아닙니다.

운영자가 매주 볼 질문

반복 운영이 쌓이면 아래 질문으로 승인 정책을 조정합니다. 첫째, 어떤 작업이 항상 시간 안에 끝났는가. 둘째, 어떤 작업이 보강을 반복했는가. 셋째, live smoke 실패는 주로 업로드, 캐시, 렌더링, 공개 문구 중 어디에서 났는가. 넷째, 중단 기준이 너무 늦게 발동하지 않았는가. 다섯째, 최종 보고가 모바일에서 읽기 충분히 짧았는가.

이 질문들은 자동화를 줄이기 위한 것이 아니라 더 안전하게 늘리기 위한 것입니다. 시간 제한 승인이 잘 작동하면 운영자는 더 큰 범위도 작은 책임 단위로 나눠 맡길 수 있습니다. 반대로 증거가 부족하거나 중단이 늦다면 승인 시간을 늘리기보다 범위를 더 작게 쪼개야 합니다.

다음 단계

작은 승인부터 시작하세요. 한 번의 세션에 하나의 책임만 부여하고, 허용 경로와 중단 기준을 좁게 둡니다. 그 다음 반복 작업에서 성공률, live smoke 실패율, 보강 횟수, 중단 사유를 모으면 승인 시간을 더 현실적으로 조정할 수 있습니다.

시간 제한 승인이 익숙해지면 헤르메스는 더 많은 일을 할 수 있습니다. 역설적으로 권한을 좁히면 자동화는 안전해지고, 안전해지면 더 자주 맡길 수 있습니다. 24시간 AI 운영의 목표는 에이전트를 방치하는 것이 아니라, 짧은 책임을 계속 안전하게 완료하게 만드는 것입니다.