AI 경보 임계값 운영법

헤르메스가 24시간 운영을 맡기 시작하면 가장 위험한 순간은 문제가 생긴 때가 아니라, 너무 많은 신호가 동시에 울려서 아무 신호도 중요하게 보이지 않는 때입니다. 경보 임계값은 알림을 줄이기 위한 장치가 아니라, AI 에이전트가 계속 진행할지, 범위를 줄일지, 사람에게 승격할지 판단하게 만드는 운영 기준입니다.

이 글은 헤르메스 운영에서 경보를 어떻게 설계하고, 어떤 숫자를 기준으로 중단하며, 어떤 증거를 남긴 뒤 다시 시작할지 정리합니다. 특히 크론 작업, DB-only 콘텐츠 업로드, 라이브 스모크, 브라우저 콘솔 확인, 비용·토큰 사용량처럼 반복되는 자동화 작업에 맞춰 설명합니다.

왜 경보 임계값이 자율 운영의 브레이크인가

AI 에이전트는 지치지 않는 대신, 지루한 반복 신호를 사람처럼 감으로 무시하지 못합니다. 그래서 임계값이 없으면 두 가지 실패가 생깁니다. 하나는 모든 경고를 장애처럼 다루는 과잉 중단입니다. 사소한 1회성 네트워크 지연에도 작업이 멈추고, 실제로 공개해야 할 글이나 점검이 계속 밀립니다. 다른 하나는 반대로 경고가 너무 익숙해져서 중요한 실패를 정상 변동으로 취급하는 과소 대응입니다.

경보 임계값은 이 두 실패 사이의 선입니다. 예를 들어 목록 페이지 1개가 일시적으로 502를 냈지만 즉시 재시도에서 200으로 돌아오면 기록만 남기고 진행할 수 있습니다. 반면 같은 상세 페이지가 3회 연속 실패하거나, 공개 금지어 스캔에서 방문자에게 보이면 안 되는 내부 문구가 검출되면 즉시 중단해야 합니다. 숫자와 조건을 미리 정하지 않으면 AI는 매번 새롭게 판단하려고 하고, 그 과정에서 운영 품질이 흔들립니다.

경보는 알림이 아니라 결정을 만든다

좋은 경보는 “무언가 이상함”이라고 말하지 않습니다. “이 조건에서는 업로드를 멈추고 증거 패킷을 남긴다”, “이 조건에서는 재시도 1회를 허용한다”, “이 조건에서는 다음 크론 주기로 넘긴다”처럼 행동을 정합니다. 헤르메스 운영에서 경보 임계값은 알림 문구보다 이어지는 행동이 더 중요합니다.

자동화가 많을수록 임계값은 더 구체적이어야 한다

콘텐츠 작성, DB 업로드, revalidate, 라이브 스모크, 브라우저 점검, 보고까지 한 세션에서 이어지면 작은 실패도 뒤 단계로 번질 수 있습니다. 임계값은 단계별로 분리되어야 합니다. 초안 품질 실패와 업로드 실패, 라이브 HTML 실패, 브라우저 콘솔 실패는 모두 다른 의미를 갖습니다.

경보를 나누는 기본 구조

헤르메스 경보는 최소한 네 묶음으로 나눠야 합니다. 첫째, 공개 품질 경보입니다. 본문이 얕거나 상황별 예시가 없거나 검증 방법이 빠진 글은 업로드하지 않습니다. 둘째, 시스템 반영 경보입니다. 업로드 명령은 성공했지만 공개 경로가 아직 갱신되지 않는 경우입니다. 셋째, 사용자 영향 경보입니다. 대표 페이지가 4xx 또는 5xx를 내거나, 상세 페이지가 렌더링은 되지만 방문자가 읽으면 안 되는 내부 문구를 노출하는 경우입니다. 넷째, 운영 비용 경보입니다. 한 작업이 정해진 토큰 예산과 재시도 횟수를 넘어서면 더 진행할수록 품질보다 비용만 커질 수 있습니다.

이 구조를 쓰면 “실패했다”는 말 대신 “어느 묶음에서 어떤 기준을 넘었는가”를 보고할 수 있습니다. 다음 운영자는 로그를 다시 읽지 않아도 어디서 이어받을지 알 수 있습니다.

임계값을 숫자로 정하는 법

임계값은 완벽한 숫자가 아니라 반복 가능한 숫자여야 합니다. 처음에는 보수적으로 잡고, 실제 운영 기록이 쌓이면 조정합니다. 예를 들어 라이브 스모크는 같은 경로를 2회 연속 실패하면 중단, 공개 금지어는 1회 검출만으로 중단, 브라우저 콘솔 오류는 새 오류 1개 이상이면 보고, 콘텐츠 품질은 필수 섹션 1개라도 빠지면 업로드 금지처럼 잡을 수 있습니다.

재시도 횟수

재시도는 장애를 고치는 방법이 아니라 일시적 흔들림을 확인하는 방법입니다. 같은 명령을 5번 반복해서 우연히 성공한 결과는 안정적인 운영 결과가 아닙니다. DB-only 콘텐츠 업로드에서는 검증 명령 1회, 업로드 명령 1회, 라이브 확인 2회 정도를 기본으로 두고, 같은 유형의 실패가 반복되면 중단하는 편이 안전합니다.

시간 임계값

크론 작업은 다음 실행과 충돌할 수 있습니다. 한 Hermes 팁 작업이 정해진 시간 안에 품질 기준을 넘지 못하면 새 글을 억지로 완성하지 않고 초안으로 옮겨야 합니다. 특히 장문 글이 품질 기준에 못 미치는 상태에서 마감 때문에 공개되면 다음 작업은 그 글의 수습부터 시작해야 합니다.

비용과 토큰 임계값

비용 경보는 단순히 돈을 아끼기 위한 장치가 아닙니다. 토큰 사용량이 계속 늘어나는 작업은 보통 목표가 흐리거나 자료가 부족하거나 검증이 실패하고 있다는 신호입니다. 한 주제에서 계속 재작성만 반복된다면 글을 더 길게 만드는 대신 독자 문제, 근거, 운영 순서 중 무엇이 비어 있는지 다시 분류해야 합니다.

실제 운영 순서

첫 단계는 작업 범위 선언입니다. 이번 세션이 새 Hermes 글 1건을 DB-only로 올리는 일인지, 기존 글을 고치는 일인지, 라이브 문제를 진단하는 일인지 먼저 고정합니다. 범위가 고정되어야 임계값도 고정됩니다. 새 글 작성 세션에서 사이트 전체 리팩터링 경보까지 다루기 시작하면 작업이 끝나지 않습니다.

둘째, 사전 기준을 적습니다. 필수 섹션, 금지 문구, 최소 본문 깊이, FAQ 개수, 업로드 전 검증 명령, 업로드 후 확인 경로를 미리 정합니다. 이 기준은 글을 쓴 뒤에 맞춰 만드는 것이 아니라 글쓰기 전에 정해야 합니다.

셋째, 초안을 만들고 품질 경보를 먼저 적용합니다. 상황별 예시, 운영 순서, 권한과 보안 경계, 검증 방법, 실패 시 중단 기준이 빠졌다면 아직 업로드 대상이 아닙니다. 이 단계에서 멈추는 것은 실패가 아니라 정상적인 품질 제어입니다.

넷째, 검증 명령을 실행합니다. 형식 검증, 중복 slug 검사, 공개 금지어 검사, 본문 깊이 검사, renderer 위험 검사처럼 자동화할 수 있는 항목을 먼저 돌립니다. 자동 검사에서 실패하면 live smoke까지 가지 않습니다.

다섯째, 업로드와 revalidate를 실행합니다. 업로드 결과는 성공 여부, 반영 경로, revalidate가 실제 호출되었는지로만 요약합니다. 인증값이나 연결 정보는 출력하지 않습니다. revalidate가 설정되지 않았거나 건너뛰어진 경우에는 DB 반영과 공개 반영을 분리해서 보고해야 합니다.

여섯째, 라이브 스모크를 합니다. 목록 페이지와 상세 페이지를 모두 확인하고, title 또는 slug marker가 보이는지 확인합니다. 가능하면 브라우저로 상세 페이지를 열어 콘솔 오류가 없는지도 봅니다. 여기서 실패하면 추가 글 생산을 멈추고 증거 패킷을 남깁니다.

권한과 보안 경계

경보 시스템이 강력해질수록 권한 경계도 분명해야 합니다. 경보가 울렸다고 해서 AI가 모든 권한을 사용해 복구를 시도하면 안 됩니다. DB-only 콘텐츠 작업에서는 로컬 JSON 생성, 검증, 업로드, 라이브 확인까지만 허용하고, Git 변경이나 배포 트리거는 별도 승인이 필요한 범위로 남겨야 합니다. 운영 문서 변경, 관리자 화면 변경, 삭제성 DB 작업, 인증 설정 변경은 같은 세션에서 자동으로 확장하지 않는 것이 안전합니다.

민감정보 처리도 경계의 일부입니다. 보고서는 값이 아니라 상태를 말해야 합니다. 예를 들어 “업로드 인증 준비됨”, “revalidate 설정 누락 가능”, “라이브 상세 경로 200”처럼 쓰면 충분합니다. 실제 인증 문자열, 연결 문자열, 로컬 비밀 파일 경로, 복사 가능한 키 이름은 공개 글과 보고서에 넣지 않습니다.

경보가 권한 확대의 핑계가 되면 안 된다

대표 경로가 실패했다고 해서 즉시 배포 설정을 바꾸거나 운영 DB를 직접 수정하는 것은 위험합니다. 먼저 실패 범위를 좁혀야 합니다. 상세 경로만 문제인지, 목록도 문제인지, API 응답은 정상인지, 브라우저 렌더링만 실패인지 확인합니다. 권한은 원인 범위가 좁혀진 뒤에만 높입니다.

사람 승인으로 넘겨야 하는 조건

삭제, 대량 수정, 관리자 접근 변경, 인증 설정 변경, 반복 장애가 있는 배포 변경은 사람 승인 없이는 진행하지 않습니다. 헤르메스가 할 일은 “승인 필요”라고 멈추고 증거를 남기는 것입니다. 자동화의 성숙도는 모든 일을 스스로 하는 데 있지 않고, 위험한 일을 정확히 멈추는 데 있습니다.

상황별 예시

예시 1. Hermes 글은 업로드됐지만 상세 페이지 marker가 보이지 않는다

검증과 업로드 명령은 성공했지만 /hermes/새-slug에서 제목 marker가 보이지 않는 상황입니다. 이때 바로 새 글을 다시 만들면 안 됩니다. 먼저 목록 페이지, 상세 페이지, 공개 API의 세 경로를 나눠 봅니다. 목록에는 보이는데 상세가 안 보이면 라우팅 또는 slug 조회 문제일 수 있습니다. API에는 보이는데 HTML이 오래된 경우에는 revalidate 경로 또는 캐시 문제일 수 있습니다. 어디에도 보이지 않으면 업로드가 실제 운영 DB에 닿지 않았을 수 있습니다. 두 번 확인해도 marker가 없으면 다음 작업으로 넘어가지 말고 보류 보고를 남깁니다.

예시 2. 공개 안전 스캔에서 내부 문구가 잡힌다

본문에 운영자용 표현이나 방문자가 보면 안 되는 작업 문구가 남아 있다면 업로드 전에 멈춥니다. 이미 업로드된 뒤 발견했다면 새 글 생산보다 수정과 재확인이 우선입니다. 이 경보는 1회 검출만으로도 중단 조건입니다. 공개 페이지 신뢰도는 한 문장으로도 깨질 수 있기 때문입니다.

예시 3. 브라우저 콘솔 오류가 새로 생긴다

HTML fetch는 200이지만 브라우저에서 새 콘솔 오류가 보일 수 있습니다. 이 경우 단순 네트워크 확인은 통과했지만 사용자 경험은 위험할 수 있습니다. 콘텐츠만 바꾼 작업이라면 오류가 기존 baseline인지, 새 상세 페이지에서만 생기는지 확인합니다. 새 오류라면 업로드 성공으로 보고하지 말고 콘솔 메시지와 경로를 요약해 후속 조치로 올립니다.

예시 4. 비용과 재시도가 계속 늘어난다

글 하나를 만들기 위해 같은 품질 실패를 여러 번 고치고 있다면, 더 오래 쓰는 것보다 초안으로 내려놓는 편이 낫습니다. 임계값은 예를 들어 품질 검사 2회 연속 실패, 같은 missing-section 실패 반복, 자료 부족으로 본문 보강 불가 같은 조건으로 잡습니다. 이때 보고는 “실패”가 아니라 “품질 기준 미달로 초안 보관”이어야 합니다.

실패 시 중단 기준

중단 기준은 공개 전과 공개 후로 나눕니다. 공개 전에는 필수 섹션 누락, 본문 깊이 부족, 중복 slug, renderer 위험, 공개 금지어 검출, 권한 경계 위반이 있으면 업로드하지 않습니다. 공개 후에는 상세 페이지 404, 목록 미노출, marker 미노출, 대표 경로 장애, 브라우저 콘솔 새 오류, 공개 금지어 노출이 있으면 성공 보고를 하지 않습니다.

중단 뒤에는 세 가지를 남깁니다. 첫째, 어느 기준을 넘었는지입니다. 둘째, 사용자가 볼 수 있는 영향입니다. 셋째, 다음 운영자가 이어받을 최소 행동입니다. 예를 들어 “상세 페이지 200이지만 제목 marker 미노출, 목록에는 새 항목 없음, 업로드 반영 여부 재확인 필요”처럼 남기면 다음 세션이 바로 이어갈 수 있습니다.

검증 체크리스트

• 작업 범위가 새 글 1건인지, 수정인지, 장애 대응인지 분리되어 있는가.
• 필수 섹션에 상황별 예시, 운영 순서, 권한과 보안 경계, 검증 방법, 실패 시 중단 기준이 들어 있는가.
• 검증 명령이 성공했고, 실패 내용을 무시하지 않았는가.
• 업로드 결과와 revalidate 결과를 값이 아닌 상태로만 요약했는가.
• /hermes와 /hermes/slug가 모두 200이고, 새 제목 또는 slug marker가 보이는가.
• 공개 금지어와 내부 언어가 live HTML에 남아 있지 않은가.
• 브라우저 콘솔 오류가 없거나, 기존 baseline과 구분해 후속 위험으로 보고했는가.
• 작업이 만든 임시 content 파일을 공개 반영 뒤 안전한 보관 위치로 옮겼는가.

운영 리듬에 붙이는 방법

매일 실행되는 Hermes 콘텐츠 작업은 같은 임계값 표를 반복해서 써야 합니다. 하루는 품질 기준을 엄격하게 보고, 다음 날은 느슨하게 보면 콘텐츠 품질이 흔들립니다. 주간 리뷰에서는 경보가 너무 자주 울리는 항목과 너무 늦게 잡히는 항목을 나눠 봅니다. 너무 자주 울리는 경보는 기준이 모호하거나 자동 검사가 과한 것일 수 있습니다. 너무 늦게 잡히는 경보는 live smoke 범위가 좁거나 브라우저 점검이 빠졌을 수 있습니다.

좋은 운영 리듬은 글을 더 많이 쓰게 만드는 것이 아니라, 공개해도 되는 글과 멈춰야 하는 글을 매번 같은 방식으로 구분하게 만듭니다. 헤르메스의 자율성은 브레이크가 있을 때 더 커집니다. 임계값이 명확하면 에이전트는 작은 작업을 빠르게 끝내고, 위험한 작업은 조용히 멈추며, 다음 운영자에게 필요한 증거만 남길 수 있습니다.

다음 단계

처음 적용할 때는 모든 경보를 대시보드화하려고 하지 말고, 세 가지부터 시작합니다. 첫째, 업로드 전 품질 경보입니다. 둘째, 공개 후 live smoke 경보입니다. 셋째, 공개 안전 스캔 경보입니다. 이 세 가지가 안정되면 비용·토큰 경보, 브라우저 콘솔 경보, 장기 크론 충돌 경보를 붙입니다.

가장 중요한 원칙은 경보가 울렸을 때 더 많은 자동화를 실행하지 않는 것입니다. 경보는 멈추고, 좁히고, 증거를 남기라는 신호입니다. 그 신호가 지켜질 때 헤르메스는 24시간 계속 움직이면서도 사이트의 공개 품질과 운영 신뢰를 지킬 수 있습니다.