AI 결정 로그 운영법

헤르메스가 24시간 움직일 때 가장 위험한 순간은 큰 사고가 난 순간만이 아닙니다. 오히려 작은 판단이 여러 번 이어질 때 위험이 커집니다. “이 테스트 실패는 무시해도 되나”, “이 공개 문구는 방문자에게 안전한가”, “업로드는 성공했지만 revalidate가 애매한데 계속 진행해도 되나” 같은 결정이 기록 없이 지나가면 다음 세션은 같은 질문을 다시 풀어야 합니다.

결정 로그는 AI 에이전트의 운영 판단을 남기는 짧은 운영 기록입니다. 감상문이 아니라, 왜 그 순간 계속 진행했는지 또는 왜 멈췄는지를 다음 운영자가 재현할 수 있게 만드는 증거입니다. 잘 만든 결정 로그는 작업 속도를 늦추지 않습니다. 오히려 불필요한 재탐색을 줄이고, 중단 기준을 명확히 하며, 모바일 원격 운영에서도 안전하게 이어받을 수 있게 합니다.

왜 결정 로그가 24시간 운영의 안전장치인가

AI 에이전트는 긴 문맥을 다룰 수 있지만, 운영 현장은 문맥이 계속 바뀝니다. 크론 실행이 겹칠 수 있고, 이전 작업이 남긴 임시 파일이 있을 수 있으며, 라이브 사이트는 로컬 소스와 다른 데이터베이스 상태를 보여줄 수 있습니다. 이런 상황에서 “아마 괜찮겠지”라는 판단은 누적 위험이 됩니다.

결정 로그는 세 가지를 분리합니다. 첫째, 관찰한 사실입니다. 예를 들어 목록 페이지는 200을 반환했고 상세 페이지에서 새 slug가 보였다는 기록입니다. 둘째, 그 사실을 바탕으로 내린 판단입니다. 예를 들어 DB 업로드는 성공했지만 공개 차단어가 발견되어 재업로드 전까지 완료로 보지 않는다는 판단입니다. 셋째, 다음 행동입니다. 예를 들어 임시 JSON을 보관할지, 보강 후 다시 업로드할지, 사람 승인 없이 멈출지입니다.

기록이 없으면 다음 세션은 같은 증거를 다시 모으거나, 더 나쁘게는 증거 없이 진행합니다. 결정 로그가 있으면 다음 운영자는 “무엇을 확인했고 무엇을 아직 확인하지 않았는지”를 바로 알 수 있습니다.

결정 로그의 기본 구조

좋은 결정 로그는 길 필요가 없습니다. 다만 빠뜨리면 안 되는 칸이 있습니다.

핵심은 “결정”과 “근거”를 분리하는 것입니다. 관찰 결과가 있어도 판단이 틀릴 수 있고, 판단이 맞아도 다음 행동이 모호하면 운영이 흔들립니다. 결정 로그는 이 세 부분을 따로 남겨야 나중에 검토할 수 있습니다.

실제 운영 순서

1단계. 시작 전 상태를 먼저 잠근다

작업을 시작할 때는 현재 상태를 짧게 남깁니다. 예를 들어 Git working tree가 이미 더러운지, 이번 작업이 만든 파일이 아닌 untracked 파일이 있는지, 로컬 소스와 라이브 데이터가 다를 가능성이 있는지 확인합니다. DB-only 운영에서는 git 명령으로 소스를 바꾸지 않는 것이 원칙이므로, 기존 dirty 상태와 이번 작업이 만든 임시 파일을 반드시 구분해야 합니다.

결정 로그 예시는 다음과 같습니다.

시작 상태: main은 origin/main과 일치. 기존 untracked 앱 JSON 1건은 이번 Hermes 작업 범위 밖. 이번 작업은 content/posts/hermes 임시 JSON만 만들고 업로드 후 .tmp로 이동한다.

이 한 줄이 있으면 종료 시 “왜 git status가 완전 clean이 아닌가”를 혼동하지 않습니다. 작업이 만든 파일을 남기지 않았는지와 기존 병행 작업의 흔적이 있는지는 서로 다른 문제입니다.

2단계. 검증 결과를 감상이 아니라 증거로 쓴다

검증은 “잘 됨”으로 끝나면 안 됩니다. 어떤 명령이 통과했는지, 어떤 live URL이 200이었는지, 어떤 marker를 확인했는지 적어야 합니다. 특히 Hermes DB-only 글은 validation, 품질 스캔, upload, revalidate, live smoke가 서로 다른 단계입니다. 하나가 통과했다고 전체가 성공한 것은 아닙니다.

좋은 기록은 이런 형태입니다.

검증 결과: post validate 통과. 품질 스캔에서 본문 7천자 이상, FAQ 5개, 상황별 예시와 중단 기준 확인. upload ok, revalidate status 200. /hermes와 /hermes/slug 모두 200, 제목 marker 확인, 공개 차단어 없음.

반대로 “업로드 성공”만 적으면 revalidate와 라이브 반영을 확인했는지 알 수 없습니다. 다음 운영자는 같은 확인을 반복하거나, 확인하지 않은 상태를 성공으로 오해할 수 있습니다.

3단계. 결정은 네 가지 중 하나로 제한한다

운영 판단은 복잡해 보이지만 실제로는 계속 진행, 보류, 재시도, 중단 네 가지로 줄일 수 있습니다.

계속 진행은 모든 필수 검증이 통과했을 때만 사용합니다. 보류는 주제나 방향은 맞지만 품질이 부족할 때 사용합니다. 재시도는 외부 네트워크, revalidate, 브라우저 확인처럼 일시적 실패 가능성이 있을 때 사용합니다. 중단은 공개 안전, 민감정보, 데이터 손상, 인증 실패, 사용자 영향 같은 위험이 확인됐을 때 사용합니다.

이 네 가지를 섞지 않는 것이 중요합니다. 예를 들어 품질 미달 글을 “재시도”로 분류하면 같은 얕은 글이 다시 올라갑니다. 민감정보 가능성이 있는 출력을 “보류”로만 두면 누군가 나중에 실수로 공개할 수 있습니다. 결정 로그는 상태 이름을 엄격하게 써야 합니다.

상황별 예시

예시 1. DB 업로드는 됐지만 목록에 새 글이 늦게 보이는 경우

DB-only 콘텐츠 운영에서는 upload가 성공해도 캐시와 revalidate 상태 때문에 목록 반영이 즉시 보이지 않을 수 있습니다. 이때 결정 로그는 업로드와 공개 확인을 분리해야 합니다.

좋은 판단은 “업로드 성공, 공개 확인 미완료, 목록 marker 재확인 필요”입니다. 다음 행동은 상세 URL 직접 확인, 목록 페이지 재요청, API 응답에서 slug 확인입니다. 이 확인은 라이브 스모크로 기록하고, 결과는 요약 보고에 남깁니다. 중단 기준은 4xx, 잘못된 카테고리, 공개 차단어 발견, revalidate 실패가 됩니다.

이 상황에서 바로 완료 보고를 하면 사용자는 실제 공개 상태를 알 수 없습니다. 반대로 무작정 다시 업로드하면 중복 업데이트나 불필요한 revalidate를 만들 수 있습니다. 결정 로그는 기다릴지, 재확인할지, 수정할지를 구분해 줍니다.

예시 2. 품질 스캔은 통과했지만 공개 문구가 어색한 경우

운영 글은 내부 기준을 설명하다 보면 방문자에게 딱딱한 표현이 남기 쉽습니다. “운영자용 라벨”, “관리 처리”, “내부 토큰” 같은 표현은 실제 비밀이 아니어도 공개 글의 신뢰를 떨어뜨릴 수 있습니다. 이때 결정은 보류 또는 수정 후 재검증이어야 합니다.

좋은 기록은 “본문 깊이는 충분하나 공개 문구가 내부자 중심이라 visitor-facing 표현으로 수정 후 재검증”입니다. 다음 행동은 문구 수정, validation 재실행, live smoke 재확인입니다. 이 과정을 남겨야 다음 세션이 같은 문구를 다시 허용하지 않습니다.

예시 3. 모바일 원격 운영 중 긴 명령 결과를 다 볼 수 없는 경우

휴대폰으로 알림을 받는 운영자는 긴 로그를 끝까지 읽기 어렵습니다. 결정 로그는 모바일에서 한눈에 봐도 판단 가능한 형태여야 합니다. 정상, 주의, 장애 중 하나로 시작하고, 그 아래에 증거 3개와 다음 행동 1개를 붙이면 좋습니다.

예를 들어 “주의: upload ok, detail 200, 목록 marker 미확인. 다음 행동: /hermes 목록 재요청 후 marker 확인”처럼 쓰면 됩니다. 모바일 운영에서는 완벽한 로그보다 중요한 판단 단서가 먼저 보여야 합니다. 상세 로그는 필요할 때만 보게 하고, 민감정보는 절대 보고에 포함하지 않습니다.

예시 4. 병행 cron-run이 같은 저장소를 만진 흔적이 있는 경우

동시 작업은 24시간 운영에서 흔합니다. 내 작업과 무관한 untracked 파일이 이미 있거나, 다른 작업이 빌드 중일 수 있습니다. 이때 결정 로그는 “내 작업이 만든 것”과 “기존 또는 병행 작업 흔적”을 분리해야 합니다.

좋은 판단은 “이번 Hermes 작업은 임시 JSON 생성과 DB 업로드만 수행. 기존 앱 JSON은 범위 밖이므로 수정하지 않음. 종료 시 Hermes 임시 파일만 archive 처리”입니다. 이 기록이 없으면 누군가 전체 clean을 만들려고 다른 작업의 파일을 삭제할 수 있습니다.

권한과 보안 경계

결정 로그는 비밀을 보관하는 장소가 아닙니다. 환경 변수 값, 토큰, 데이터베이스 연결 문자열, 개인 인증 정보, 관리자 URL은 기록하지 않습니다. 필요한 것은 값이 아니라 상태입니다. 예를 들어 “업로드 인증 사용 가능”, “revalidate 설정 존재”, “DB 클라이언트 사용 가능”처럼 상태만 남깁니다.

출력 경계도 중요합니다. 운영 보고에는 명령 전체 로그를 붙이지 말고, 성공 여부와 안전한 marker만 남깁니다. 오류가 발생했을 때도 원문을 그대로 복사하지 않습니다. 인증 문자열, 내부 경로, 사용자 입력에 섞인 민감정보가 있을 수 있기 때문입니다.

권한 경계는 결정에도 반영해야 합니다. DB-only 글 업로드는 허용되어도 git commit은 금지된 세션일 수 있습니다. 공개 글 수정은 허용되어도 관리자 API 호출은 별도 승인 대상일 수 있습니다. 결정 로그는 “이번 세션에서 허용된 행동”과 “멈춰야 하는 행동”을 함께 적어야 합니다.

실패 시 중단 기준

결정 로그가 제 역할을 하려면 중단 기준이 숫자와 조건으로 보여야 합니다. 다음 조건 중 하나라도 나오면 자동 진행을 멈춥니다.

첫째, 공개 페이지에서 민감정보 또는 내부 운영 문구가 보이는 경우입니다. 실제 토큰 값이 아니어도 방문자에게 관리자 작업장이 노출되는 느낌을 주면 수정 후 재검증해야 합니다. 둘째, validation이나 품질 스캔이 실패한 경우입니다. 글이 얕거나 필수 섹션이 빠졌다면 업로드하지 않습니다. 셋째, live smoke가 실패한 경우입니다. 상세 페이지 4xx, 목록 marker 누락, API에서 slug 미확인, 브라우저 콘솔 오류가 있으면 완료로 보고하지 않습니다. 넷째, 작업 범위가 바뀌는 경우입니다. 글 하나를 올리는 세션에서 코드 수정이 필요해졌다면 즉시 중단하고 별도 작업으로 분리합니다.

중단 기준은 책임 회피가 아닙니다. 자동화가 안전하게 오래 일하기 위해 필요한 브레이크입니다. 멈출 수 없는 에이전트는 운영자가 아니라 사고를 빨리 만드는 도구가 됩니다.

검증 체크리스트

결정 로그를 남긴 뒤에는 다음 질문으로 품질을 확인합니다.

• 작업 범위가 한 문장으로 적혀 있는가?
• 관찰 결과와 결정이 분리되어 있는가?
• validation, 품질 스캔, upload, revalidate, live smoke가 각각 구분되어 있는가?
• 상황별 예시가 최소 한 개 이상 있는가?
• 권한 경계와 보안 경계가 상태 중심으로 적혀 있는가?
• 실패 시 중단 기준이 조건으로 적혀 있는가?
• 다음 운영자가 바로 이어서 할 행동이 보이는가?
• 민감정보 값, 내부 인증 문자열, 불필요한 원문 로그가 없는가?
• 모바일 원격 운영자가 한 화면에서 정상, 주의, 장애를 판단할 수 있는가?

체크리스트가 모두 통과하면 결정 로그는 운영 품질을 높입니다. 하나라도 빠지면 로그는 장식이 됩니다.

운영 리듬에 붙이는 방법

결정 로그는 매 작업 끝에만 쓰는 것이 아니라 운영 리듬 안에 들어가야 합니다. 시작 전에는 범위와 중단 기준을 적고, 검증 뒤에는 증거와 판단을 적고, 보고 직전에는 다음 행동을 적습니다. 이렇게 하면 로그가 별도 문서가 아니라 운영 순서의 일부가 됩니다.

주간 회고에서는 결정 로그를 모아 반복되는 보류 사유를 찾습니다. 계속 같은 이유로 글이 얕다고 판정된다면 초안 지시가 약한 것이고, 계속 같은 live smoke에서 막힌다면 검증 절차가 늦게 실행되는 것입니다. 결정 로그는 과거를 저장하기 위한 기록이 아니라 다음 자동화 품질을 높이는 입력입니다.

다음 단계

처음부터 거창한 운영 시스템을 만들 필요는 없습니다. 오늘부터는 모든 Hermes DB-only 작업 끝에 세 줄만 남겨도 충분합니다. 첫 줄은 상태, 둘째 줄은 증거, 셋째 줄은 다음 행동입니다. 예를 들어 “정상: validate/upload/live smoke 통과. 증거: 목록과 상세 200, slug marker 확인, 공개 차단어 없음. 다음 행동: 원본 JSON archive 후 clean 상태 확인”처럼 기록합니다.

익숙해지면 결정 로그를 주제별로 나눌 수 있습니다. 콘텐츠 결정 로그, 배포 결정 로그, 사고 대응 결정 로그, 비용 결정 로그처럼 나누면 나중에 회고가 쉬워집니다. 중요한 것은 AI가 무엇을 했는지가 아니라, 왜 그 판단을 했고 어디서 멈출 수 있었는지를 남기는 것입니다. 그것이 헤르메스가 24시간 운영자로 신뢰받기 위한 기본 언어입니다.