AI 관측 신호 라우팅법

헤르메스가 24시간 운영되면 신호는 계속 쌓입니다. 작업 시작 로그, 검증 결과, 업로드 응답, revalidate 결과, 라이브 스모크, 브라우저 콘솔, 공개 안전 스캔, 실패 메시지, 비용 경고, 중복 작업 신호가 모두 한꺼번에 들어옵니다. 이 신호를 전부 같은 알림으로 보내면 운영자는 금방 무감각해집니다. 반대로 아무것도 알리지 않으면 AI 에이전트는 실패한 상태로 다음 작업을 이어갑니다.

관측 신호 라우팅은 신호를 모으는 기술이 아니라 신호의 목적지를 정하는 운영 설계입니다. 어떤 신호는 자동 재시도로 보냅니다. 어떤 신호는 요약 보고에만 넣습니다. 어떤 신호는 즉시 사람에게 알려야 합니다. 어떤 신호는 작업을 멈추고 원본 증거 패킷을 보존해야 합니다. 이 기준이 없으면 로그는 많지만 판단은 늦고, 알림은 많지만 책임은 흐려집니다.

왜 관측 신호 라우팅이 필요한가

AI 에이전트 운영의 위험은 조용한 실패입니다. 명령은 끝났다고 표시되지만 공개 페이지는 갱신되지 않았거나, 업로드는 성공했지만 캐시가 남아 있거나, 상세 페이지는 열리지만 본문에 내부 문구가 보일 수 있습니다. 이런 실패는 단순한 실행 로그만으로는 보이지 않습니다. 반대로 모든 세부 로그를 사람에게 보내면 중요한 장애 신호가 평범한 작업 메시지에 묻힙니다.

라우팅이 필요한 첫 번째 이유는 노이즈를 줄이기 위해서입니다. 성공한 검증 결과는 최종 보고에 남기면 충분합니다. 두 번째 이유는 중단 기준을 빠르게 적용하기 위해서입니다. 공개 안전 스캔에서 방문자에게 보이면 안 되는 내부 문구가 발견되면 더 많은 검증을 하는 것이 아니라 즉시 멈춰야 합니다. 세 번째 이유는 다음 실행의 품질을 높이기 위해서입니다. 이전 작업의 실패 신호가 어떤 유형인지 분류되어 있어야 다음 cron-run이 같은 실수를 반복하지 않습니다.

신호를 네 종류로 나누는 기본 구조

관측 신호는 중요도보다 먼저 행동 기준으로 나누는 것이 좋습니다. 중요도는 사람마다 다르게 해석되지만 행동은 명확합니다. 계속 진행할 신호, 요약만 남길 신호, 재시도할 신호, 즉시 멈출 신호로 나누면 에이전트와 사람이 같은 판단표를 사용할 수 있습니다.

이 표의 핵심은 로그의 양이 아닙니다. 신호가 발견됐을 때 무엇을 할지 미리 정해 두는 것입니다. “나중에 사람이 보면 알겠지”라는 방식은 24시간 자동화와 맞지 않습니다. 에이전트는 신호를 읽는 순간 다음 행동을 선택할 수 있어야 합니다.

운영 순서 설계

첫 단계는 작업 범위를 한 문장으로 고정하는 것입니다. 예를 들어 “헤르메스 운영 팁 한 건을 DB-only로 게시하고 live smoke까지 확인한다”처럼 범위가 정해져야 관측 신호도 정해집니다. 범위가 모호하면 어떤 신호가 실패인지 판단할 수 없습니다.

두 번째 단계는 경로별 필수 신호를 정하는 것입니다. 콘텐츠 DB-only 게시라면 임시 JSON 생성, post validation, 품질 스캔, upload 응답, revalidate 결과, 목록 페이지 marker, 상세 페이지 marker, 공개 안전 스캔, 브라우저 콘솔 확인이 핵심 신호입니다. 배포 작업이라면 빌드 결과, 배포 상태, 대표 경로 HTTP 200, 상세 페이지 단일 H1, OG 메타, rollback 기준이 핵심 신호가 됩니다.

세 번째 단계는 신호별 목적지를 정하는 것입니다. 성공 신호는 최종 보고로 보냅니다. 재시도 가능한 실패는 짧은 재시도 루프로 보냅니다. 보안과 공개 안전에 관련된 신호는 재시도보다 중단으로 보냅니다. 사람이 확인해야 하는 신호는 요약 보고의 맨 위로 올립니다.

네 번째 단계는 증거 패킷을 남기는 것입니다. 증거 패킷에는 실행한 검증, 결과, 실패한 경우의 원인 후보, 다음 재개 조건, 공개 화면 확인 여부가 들어갑니다. 단, 민감정보는 값이 아니라 상태만 기록합니다. 예를 들어 “인증 설정 있음”처럼 충분히 운영 판단이 가능한 수준으로 남기고 실제 값은 어떤 보고에도 쓰지 않습니다.

상황별 예시

DB-only Hermes 게시

임시 JSON을 만들고 validation을 통과한 뒤 업로드했습니다. upload 응답이 성공이고 revalidate가 실행됐으며 상세 페이지가 200을 반환합니다. 이때 진행 신호는 validation 통과, upload 성공, revalidate 성공, 상세 marker 확인입니다. 요약 신호는 목록 페이지 캐시가 몇 초 늦게 갱신된 정도입니다. 중단 신호는 상세 페이지에서 내부 운영 문구가 발견되거나, 본문이 너무 얕거나, 임시 JSON이 content 경로에 남아 있는 경우입니다.

이 상황에서 라우팅은 단순합니다. 성공 신호는 최종 보고에 압축합니다. 캐시 지연은 한 번 더 확인합니다. 공개 금지어가 발견되면 글을 수정해 다시 업로드하기 전까지 완료로 보고하지 않습니다. content 경로에 임시 파일이 남아 있으면 작업을 완료로 보지 않습니다.

배포 검증

코드 변경을 배포한 뒤 대표 경로가 모두 200입니다. 그러나 브라우저 콘솔에서 특정 상세 페이지의 런타임 오류가 보입니다. HTTP smoke는 진행 신호지만 브라우저 콘솔은 중단 신호입니다. 이때 “대부분 200이므로 정상”이라고 보고하면 안 됩니다. 사용자가 실제 화면을 열 때 문제가 생기기 때문입니다.

라우팅 기준은 사용자 영향입니다. 콘솔 오류가 분석 도구 경고처럼 기능 영향이 없으면 요약 신호로 낮출 수 있습니다. 하지만 렌더링 실패, 클릭 동작 실패, hydration 오류, 데이터 로딩 실패라면 중단 신호로 보고하고 rollback 기준을 검토해야 합니다.

모바일 원격 운영

운영자가 휴대폰으로 결과만 확인하는 상황에서는 신호가 더 짧아야 합니다. “정상”만 보내면 신뢰할 수 없고, 전체 로그를 보내면 읽을 수 없습니다. 모바일 보고에는 상태, 변경 대상, 검증 marker, 위험, 다음 행동만 들어가야 합니다. 예를 들어 “상태: 주의, 상세 marker 확인, 목록 캐시 재확인 필요, 공개 금지어 없음, 임시 파일 없음”처럼 판단 가능한 문장으로 압축합니다.

장기 cron-run 충돌

동시에 두 작업이 실행되면 같은 콘텐츠 영역을 건드리거나 검증 결과가 섞일 수 있습니다. 이때 dirty worktree, 이미 존재하는 임시 파일, 같은 slug, 같은 목록 페이지 캐시 지연은 충돌 위험 신호입니다. 충돌 위험은 바로 실패가 아니지만 요약 신호로만 묻으면 안 됩니다. 작업 범위가 겹치면 스코프를 줄이거나 멈추는 쪽으로 라우팅해야 합니다.

권한과 보안 경계

관측 신호 라우팅에서 가장 중요한 보안 원칙은 원본 값을 신호로 만들지 않는 것입니다. 인증값, 연결 문자열, 개인 정보, 관리자 전용 경로, 내부 파일 경로는 성공 여부나 존재 여부로만 다룹니다. 운영자가 필요한 것은 실제 값이 아니라 “설정이 있어서 업로드 가능했는가”, “권한이 부족해서 실패했는가”, “공개 화면에 노출됐는가”입니다.

두 번째 원칙은 쓰기 작업과 읽기 작업의 신호를 분리하는 것입니다. 읽기 smoke가 실패했을 때 곧바로 쓰기 복구를 시도하면 원인을 덮을 수 있습니다. 먼저 읽기 증거를 보존하고, 재시도 가능한지, 캐시 문제인지, 실제 DB 반영 문제인지 나누어야 합니다. 쓰기 복구는 승인 기준이 있을 때만 진행합니다.

세 번째 원칙은 공개 안전 스캔을 마지막 방어선으로 두는 것입니다. validation이 통과해도 공개 페이지에 내부 언어가 보이면 실패입니다. 브라우저 콘솔이 조용해도 본문이 방문자에게 부적절하면 실패입니다. 자동화는 내부 운영 편의를 위해 존재하지만, 공개 페이지는 방문자의 신뢰를 기준으로 판단해야 합니다.

검증 방법

검증은 세 층으로 나누면 안정적입니다. 첫째, 소스 검증입니다. JSON 구조, 필수 필드, 본문 깊이, FAQ 개수, 금지 문구, 중복 slug를 확인합니다. 둘째, 업로드 검증입니다. 업로드가 성공했는지, revalidate가 실행됐는지, 대상 slug가 API나 런타임 데이터에 보이는지 확인합니다. 셋째, 공개 검증입니다. 목록과 상세 페이지가 200인지, 제목과 slug marker가 보이는지, 공개 안전 스캔을 통과하는지, 브라우저 콘솔 오류가 없는지 확인합니다.

검증 결과는 원문 로그 전체가 아니라 판정 가능한 증거로 남깁니다. 예를 들어 “validation 통과, 품질 스캔 통과, upload 성공, revalidate 실행, /hermes 200, 상세 200, marker 확인, 공개 금지어 없음, 임시 파일 없음”이면 다음 운영자가 바로 상태를 이해할 수 있습니다. 반대로 “완료된 것 같음”은 증거가 아닙니다.

실패 시 중단 기준

다음 신호가 나오면 자동 진행을 멈춥니다. 첫째, 공개 페이지에 방문자에게 보여서는 안 되는 내부 문구나 민감정보 흔적이 보일 때입니다. 둘째, 업로드는 성공했지만 상세 페이지가 404 또는 오래된 내용으로 남을 때입니다. 셋째, 브라우저 콘솔이 사용자 기능 실패를 나타낼 때입니다. 넷째, 임시 파일이 content 경로에 남아 작업 범위를 오염시킬 때입니다. 다섯째, 같은 slug나 같은 주제를 다른 작업이 동시에 처리하고 있다는 충돌 위험이 확인될 때입니다.

중단은 실패 보고가 아니라 안전한 정지입니다. 중단 보고에는 현재 상태, 마지막으로 통과한 검증, 실패 신호, 보존한 증거, 재개 조건이 들어가야 합니다. 재개 조건은 “사람 확인 후 계속”처럼 모호하면 안 됩니다. “상세 페이지 marker가 새 제목으로 바뀌고 공개 안전 스캔이 통과하면 재개”처럼 검증 가능한 조건이어야 합니다.

운영 리듬에 붙이는 방법

매일 운영에서는 모든 신호를 자세히 보지 않습니다. 정상 신호는 일일 요약에 압축하고, 주의 신호는 다음 작업의 선행 체크에 넣고, 중단 신호는 즉시 별도 보고합니다. 주간 운영에서는 어떤 신호가 자주 발생했는지 봅니다. 캐시 지연이 반복되면 revalidate 흐름을 보강하고, 브라우저 콘솔 경고가 반복되면 렌더링 테스트를 강화하고, 공개 문구 지적이 반복되면 콘텐츠 품질 스캔을 강화합니다.

관측 신호 라우팅은 한 번 만든 표로 끝나지 않습니다. 실제 운영에서 자주 발생하는 신호를 보고 목적지를 조정해야 합니다. 중요한 것은 자동화가 더 많은 일을 하게 만드는 것이 아니라, 자동화가 멈춰야 할 순간을 더 빨리 알아보게 만드는 것입니다.

검증 체크리스트

• 작업 범위가 한 문장으로 고정되어 있는가
• 진행, 요약, 재시도, 중단 신호가 구분되어 있는가
• live smoke와 라이브 스모크 결과가 공개 화면 marker로 확인되는가
• 브라우저 콘솔과 HTTP smoke를 따로 판단하는가
• 공개 안전 스캔이 목록과 상세 페이지 모두를 확인하는가
• 민감정보는 값이 아니라 상태로만 보고되는가
• 재시도 횟수와 중단 기준이 사전에 정해져 있는가
• 증거 패킷에 검증 결과와 재개 조건이 남는가
• 임시 파일이나 작업 부산물이 content 경로에 남지 않는가
• 최종 요약이 모바일에서도 읽을 수 있는 판정 문장인가

운영 성숙도를 높이는 점검 질문

신호 라우팅은 표를 만들었다고 끝나지 않습니다. 매주 한 번은 실제 보고를 보며 세 가지 질문을 해야 합니다. 첫째, 즉시 알림으로 보낸 신호 중 사람이 읽지 않아도 됐던 것은 무엇인가입니다. 이런 신호는 다음부터 요약 신호로 낮춥니다. 둘째, 요약에만 남겼지만 나중에 장애의 원인이 된 신호는 무엇인가입니다. 이런 신호는 재시도 또는 중단 신호로 올립니다. 셋째, 에이전트가 같은 실패를 반복한 지점은 어디인가입니다. 반복 실패는 개별 작업 실수가 아니라 라우팅 규칙이 부족하다는 신호입니다.

좋은 운영자는 알림을 많이 받는 사람이 아니라 알림을 보고 바로 판단할 수 있는 사람입니다. 그래서 보고 문장도 신호 라우팅에 맞춰 짧아져야 합니다. “정상”이라고만 쓰지 말고 “검증 통과, 상세 marker 확인, 공개 안전 스캔 통과, 임시 파일 없음”처럼 판단 근거를 함께 씁니다. “주의”라면 “목록 캐시 지연, 상세는 정상, 1회 재확인 예정”처럼 다음 행동을 붙입니다. “장애”라면 “업로드 후 상세 404, 추가 게시 중단, 원본 JSON 보존, 재개 조건은 상세 200 확인”처럼 중단 상태와 재개 조건을 분리합니다.

또 하나의 성숙도 기준은 소유자 교대입니다. 24시간 운영에서는 같은 사람이 계속 보지 않습니다. 다음 사람이 보고를 받았을 때 원본 로그를 뒤지지 않고도 현재 상태, 마지막 성공 지점, 실패 신호, 안전 경계, 다음 검증을 알 수 있어야 합니다. 이것이 되면 관측 신호 라우팅은 단순 알림 설정을 넘어 운영 인수인계 장치가 됩니다.

다음 단계

처음부터 거대한 관측 시스템을 만들 필요는 없습니다. 오늘 운영하는 작업 하나를 골라 신호 표를 붙이는 것으로 충분합니다. 예를 들어 DB-only 콘텐츠 게시라면 validation, 품질 스캔, upload, revalidate, 목록 marker, 상세 marker, 공개 안전 스캔, 브라우저 콘솔, 임시 파일 정리를 필수 신호로 정합니다. 그다음 각 신호의 목적지를 진행, 요약, 재시도, 중단 중 하나로 지정합니다.

이 과정을 반복하면 헤르메스 운영은 단순한 자동 실행에서 판단 가능한 자동 운영으로 바뀝니다. 로그는 더 적게 읽어도 되고, 알림은 더 짧아져도 되며, 중요한 실패는 더 빨리 멈출 수 있습니다. AI 에이전트에게 필요한 것은 모든 것을 계속하는 용기가 아니라, 올바른 신호를 보고 멈출 수 있는 운영 감각입니다.