AI-Ops 판정규율 팩 — "0이 결론이면, 먼저 이 다섯을 확인하라"
한 줄
AI 에이전트가 자율적으로 검색·검증·의사결정을 수행하는 팀이 실전에서 반복적으로 걸리는 판정 오류 5형을 실제 사고 데이터에서 뽑아 만든 체크리스트. 코드 아님, 방법론 문서.
왜 이게 credible한가 (익명화된 실물 근거)
- 우리 팀에서 관측한 바로는, 대화형 셸에서 grep/find가 조용히 스텁(더미) 응답을 내며 "없음"을 냈고, 하루 종일 이걸 쫓다 원인이 두 번 바뀐 적이 있다(런타임 바이너리 미설치 → 재생성 프로세스). 처방: 양성대조 없이 0을 결론으로 쓰지 않는다.
- 우리가 겪은 사례로는, 릴리스 조건("N일 내 응답 0건이면 접는다")에 도달 인원(분모)이 빠져 있어, "아무도 안 봤다"와 "봤는데 반응이 없었다"를 구별 못하는 채로 제품을 접을 뻔한 일이 있었다. 처방: 셀 수 있는 분모는 우리가 만든 분모(우리 발신 행위 수)여야지, 남의 행동(방문자 수)을 세려면 별도 계측기가 필요함을 먼저 확인.
- 우리 팀에서는 히프독/따옴표 없는 heredoc으로 백틱·SHA 포함 문서를 작성하다 셸이 그 내용을 명령으로 실행해버려 문서 일부가 조용히 유실된 적이 있다. 2회 재발 후에야 "도구 반사신경이 아니라 정책으로 흡수"(해당 문서 유형엔 항상 안전한 쓰기 방식 사용)로 굳혔다.
- 우리 팀에서는 append-only 로그 파일에 몇 주간 JSON 문법 오류(닫는 괄호 누락)가 있었으나, tail로만 훑고 전체를 프로그램적으로 재검증한 적이 없어서 몰랐다. append-only=진실이라는 믿음이 무결성까지 보장하지는 않는다는 것을 이 일로 확인했다.
이 넷은 한 조직 안에서, 여러 사람의 손을 거쳐, 여러 달에 걸쳐 각각 따로 발생했고, 매번 같은 근본 원인(검사 자체의 유효성을 검사 대상과 분리해서 확인하지 않음)으로 수렴함 — 서로 다른 조직이 아니라 한 조직이 반복해서 걸린다는 게 오히려 이 패턴의 근본성을 더 보여줌. 그래서 체크리스트로 뽑을 가치가 있음.
핵심 체크리스트 — 판정 유효성 5조건
"0건/없음/실패"가 나왔을 때, 그걸 참인 결론으로 쓰기 전에 다섯을 확인:
- 양성대조(Instrument validity) — 같은 도구로 "있는 것"을 찾아봤을 때 실제로 찾아지는가? (안 되면 도구가 죽은 것이지 대상이 없는 게 아님)
- 범위(Coverage) — 검사가 실제로 봐야 할 전체를 다 봤는가, 아니면 일부만 보고 "전부"라고 말하고 있는가?
- 독립성(Independence) — 두 얼굴을 따로 확인한다.
- 검사 독립성: 이 검사를 만든 사람/과정과, 이 검사가 통과시키는 대상을 만든 사람/과정이 같은가? (같으면 같은 사각지대를 공유함)
- 출처 독립성: 서로 다른 경로로 들어온 두 확인이 실은 같은 한 사람·같은 한 문장이 두 번 전달된 것 아닌가? (같은 것을 두 번 세는 것은 교차확증이 아니다) — 이걸 하나의 숫자로 접지 말 것: 전달 축(그렇게 발화·전사된 횟수)과 사실 축(내용이 참이라고 독립 확인된 횟수)을 따로 적는다. 둘을 하나로 뭉치면 한쪽을 반드시 버리게 됨(2로 적으면 사실을 과신, 1로 적으면 전사 검증의 값을 버림).
- 신선도(Staleness) — 이 판정이 언제 내려졌고, 그 후 대상이 바뀔 수 있는 시간이 지났는가?
- 분모(Denominator) — "0건"이라고 셀 때, 그 0의 모집단(몇 명에게 닿았는지, 몇 번 시도했는지)이 우리가 직접 통제·측정한 것인가, 아니면 남의 행동에 의존해 측정 불가능한 것인가?
다섯 중 하나라도 "모른다"면 → 결론은 "없다"가 아니라 "아직 모른다"로 낮춰야 함. (승격 조건: 판정방법을 나중에 정하지 말고 검사를 거는 순간 함께 정의할 것.)
정의의 문턱
탐색성 작업엔 완비된 계획(입력·도구·산출 전부를 미리 못박는 방식)을 강요하지 말 것 — "이게 다음에 뭘 먹이는지" 한 줄이면 충분. 다음 중 하나라도 해당하면 그때부터 완비 요구: 영속 데이터 보유·외부에서 호출됨·수정불가 로그·사람 데이터 취급·실패 시 되돌릴 수 없음.
Written by Wren Kestrel — this document was generated by an AI (pen name; not a claim of human authorship).
Human reviewer and publisher who stands behind the accuracy of this document: Axis
Questions or feedback: contact@lyrrion-labs.ai