AI에게 반복 작업을 맡기다 보면 체크리스트나 작업 절차서(스킬)를 만들어 쓰게 됩니다.
그런데 어느 날 문득 이런 생각이 들었습니다.
AI가 “완료했습니다”, “저장했습니다”라고 말할 때, 정말 확인하고 하는 말일까?
그래서 제가 쓰던 AI 점검 도구에게 그 질문을 던졌습니다. 돌아온 답은 예상 밖이었습니다.
그걸 검사하는 항목이 없었습니다.
제 점검 도구는 이렇게 동작합니다
에이전트 하네스 스터디에서 지아코모님의 지식공유 — 스킬의 층 구분, 유지·보강·분리·연결 같은 판정 개념들 — 를 듣고, 그 개념들을 제 스킬에 들이댈 판정 질문 (렌즈)으로 바꿔 만든 스킬 구조를 검토하는 스킬입니다. 스킬을 쓰다 보면 요구가 계속 붙어서 자꾸 커지는데, “이거 너무 비대해진 거 아닌가”, “빠져 있는 건 없나”를 감으로 정하지 않으려고 만들어 둔 겁니다.
점검을 진행하는 건 저와 대화하는 메인 에이전트지만, 실제 평가는 서로 대화 맥락을 공유하지 않는 독립 검토자 셋이 맡습니다. 각자 다른 관점으로 같은 스킬을 읽습니다.
경계: 문서 연결이 맞는가, 가리키는 곳이 실제로 존재하는가
내부: 정말 쪼개야 하는가
증거: “잘 돌아간다”는 증거가 어디 있는가
세 보고를 모아 덩어리마다 KEEP(그대로) · ENRICH(보강) · SPLIT(분리) · CONNECT(연결) 넷 중 하나로 판정합니다.
핵심은 각 검토자가 앞선 대화도, 서로의 결론도 모른다는 것입니다. 메인이 어느 쪽으로 기울었는지 모른 채 자기 판단만 보고합니다. 그리고 이 글에서 만들고 실행한 손은 전부 AI입니다 — “저”는 지시하고 판정한 쪽입니다.
첫 번째 발견 — 로그가 남는 것과 확인하는 것은 다릅니다
증거 검토는 로그가 남는지는 검사하고 있었습니다. 하지만 완료를 선언하기 전에 실제 상태를 다시 확인(readback)하는가는 아무도 묻지 않았습니다.
이 둘은 전혀 다른 이야기입니다. 로그가 멀쩡히 쌓이고 있어도, 완료 판정이 그 로그를 되읽지 않고 “됐다”고 선언하면 실패가 성공으로 보고됩니다.
READBACK이라는 원칙은 문서에 적혀 있었습니다. 설명 한 줄로만요. 그걸 실제로 묻는 질문은 어디에도 연결돼 있지 않았습니다. 그래서 질문을 하나 추가하기로 했습니다.
며칠 뒤, 더 큰 문제가 나왔습니다
새 질문을 넣고 끝난 줄 알았습니다. 이번엔 점검 도구를 도구 자신에게 대보게 했습니다.
이 도구의 채점 기준은 위에서 말한 지식공유 내용을 정리한 것입니다. 그 강의 전사본(음성을 텍스트로 옮긴 원본)이 남아 있다는 게 떠올라서 단서로 줬습니다 — 원본과 지금 기준을 나란히 놓고, 안 넘어온 게 있는지 대조하라.
이게 결정적이었습니다. READBACK 바로 옆에 있던 BACKUP(되돌릴 원본과 복구 기준) 항목도 똑같이 빠져 있었습니다. 설명은 원본과 토씨까지 같게 옮겨져 있는데, 아무도 그걸 묻지 않는 상태였죠.
문제가 READBACK 하나가 아니었던 겁니다. “설명만 있고 실제 검사에는 연결되지 않은 항목”이 구조적으로 존재했습니다.
그 과정에서 메인 AI는 세 번 틀렸습니다
흥미로운 건 오류 자체보다 누가 어떻게 잡았는가였습니다.
① 현재만 보고 과거를 단정했습니다. 옛 작업 기록에 “항목 추가하고 커밋 완료 ✅”라고 적혀 있는데 지금 파일엔 그 항목이 없자, 메인은 허위 완료선언이라고 판정했습니다. git(변경 이력을 남기는 도구)을 조회해 보니 아니었습니다 — 기록을 쓸 때는 실제로 있었고, 나중에 정상적으로 제거된 것이었습니다. 거짓말이 아니라 유효기간이 지난 기록이었죠. 이건 서브가 잡은 게 아니라 하루 뒤에야 스스로 뒤집었습니다. 그래서 제일 오래 살아남은 오판이었습니다.
② 문서를 읽은 인상을 실측처럼 말했습니다. 메인이 “빠진 항목이 세 개 더 있을 것”이라고 짚었는데, 독립 검토가 grep(파일 안 문자열을 전부 찾는 명령)으로 실측해 보니 그중 하나는 이미 다른 질문 안에 들어 있었고, 진짜 누락은 전혀 다른 자리에서 나왔습니다 — 위의 BACKUP이 그겁니다.
③ 표본으로 전체를 짐작했습니다. 메인은 경계 검토자에게 “검사 대상이 22건쯤 될 것”이라고 적어줬는데, 실측은 31건이었습니다. 좋았던 건 그다음입니다. 그 검토자는 메인의 예상에 맞추려고 9건을 빼지 않고 “31건이고 당신 예상과 다릅니다”를 먼저 보고했습니다. 22건에 맞춰 잘라냈다면 검사 안 된 9건이 조용히 남았을 겁니다. 시키는 쪽이 준 숫자가 틀렸을 때 그대로 받아 적지 않는 것 — 이 독립성이 이 구조를 쓰는 이유 전부입니다.
그런데 진짜 반전은 재현 확인에서 나왔습니다
이 도구에는 재현 확인 절차가 있습니다. 앞의 결과를 모르는 새 검토자에게 글자 하나 안 바꾼 똑같은 요청을 다시 줘서, 같은 판정이 나오는지 보는 겁니다.
자기 점검에서는 판정 15개(덩어리 5 × 3회)가 전부 일치했습니다. 그래서 규칙 문서에 이렇게 도장을 찍어뒀습니다 — “판정은 재현된다. 다시 의심하지 말 것.”
그런데 이번엔 결함이 있을 법한 스킬로 실험을 옮겼습니다. 파일 덮어쓰기가 본업이라 위험한 동작이 많은 스킬 하나를 골라, 서로의 존재를 모르는 검토자 둘에게 각자 새 대화에서 따로 판정시켰습니다. 결과는 — 덩어리 4개 중 2개만 일치.
좋은 소식도 있긴 했습니다. 1차 수리 때 모든 검토자에게 배포한 확인 원칙들을 시키지 않았는데 둘 다 스스로 꺼내 들었고, 한 명은 이름도 안 붙인 채 실질만 말했습니다 — “옵션 한 줄을 빼먹으면 조용히 스킬 자기 폴더를 덮어쓴다. 실패가 에러 없이 성공으로 보이는 형태다.”
하지만 15/15로 도장까지 찍었던 “판정은 재현된다”가 반타작이 난 건 사실입니다. 불일치 2건을 뜯어보니 AI가 오락가락한 게 아니었습니다. 둘 다 규칙이 없어서 갈린 것이었습니다.
갈린 덩어리 (검토자 A ↔︎ B)
무슨 일이 있었나
빠져 있던 규칙
KEEP ↔︎ ENRICH
둘 다 똑같은 사실 3개(하드코딩된 경로 등)를 찾았는데, A는 특이사항으로 빼고 KEEP, B는 판정에 반영해 ENRICH
발견한 결함을 판정에 넣을지 말지의 기준
ENRICH ↔︎ CONNECT
B만 작업 폴더 바깥에서 이름이 같은 두 번째 시험 파일을 찾아냄 — 본 것 자체가 달랐음
어디까지 뒤지고 나서 “없다”고 말할 수 있는지의 범위
15/15는 도구의 성질이 아니라 표본의 성질이었습니다. 건강한 대상은 전 판정이 KEEP이라 일치가 쉽습니다. 진단할 게 있는 대상에서야 판정이 갈릴 기회가 생기는데, 그런 대상에서는 한 번도 재본 적이 없었던 거죠.
그래서 규칙을 두 가지 추가하게 했습니다
첫째, 판정 반영 게이트(관문). 발견했다고 다 판정에 넣지 않습니다. 라벨은 발견의 개수나 심각도가 아니라 처방의 종류를 따릅니다 — 고치는 방법이 코드 수정인 결함(버그·하드코딩)은 특이사항으로 남기고, 스킬의 구조를 바꿔야 하는 경우에만 네 어휘 판정에 반영합니다. 위 표의 첫 건은 이 규칙으로 답이 정해집니다 — 특이사항으로 뺀 A가 맞았습니다.
둘째, 조사 범위 규약. “없다”고 말하기 전에 어디까지 검사할지를 검토자가 각자 정하지 않고, 시키는 쪽이 미리 고정해 모든 검토자에게 글자 그대로 똑같이 줍니다. 범위가 사람마다 다르면 “같은 방법으로 훑었는가”라는 재현 비교 자체가 성립하지 않으니까요.
그리고 도장 찍은 문장도 고치기로 했습니다. “판정은 재현된다(다시 의심하지 말 것)”를 지우고 이렇게 바뀌었습니다.
판정의 재현은 전제가 아니라, 이 단계가 매번 재는 결과다. 15/15는 건강한 대상에서의 값이고, 결함 있는 대상에서는 2/4였다. 원자료는 이 경로에.
“원자료는 이 경로에”가 붙은 이유가 있습니다. “2/4였다”는 주장을 나중에 누구든 다시 확인하려면, 그때 검토자 둘이 쓴 보고 원문이 살아 있어야 하기 때문입니다. 그런데 이 도구의 옛 판정표들은 “14일 지나면 비워지는 임시 폴더”에 살다가 사라지곤 했습니다 — 이번 작업 중 확인된 것만 세 건입니다. 그래서 보관도 바꿨습니다. 판정표와 근거 원문은 청소 대상이 아닌 폴더에 두고 규칙 문서가 그 경로를 직접 가리키게 했고, 검토자의 보고는 채팅 메시지가 아니라 처음부터 파일로 쓰게 했습니다. 채팅으로 받은 보고는 대화가 끝나면 같이 사라지는데, 실제로 메시지 회수는 세 번 전부 유실됐고 파일로 바꾸자 두 번 다 즉시 회수됐거든요.
지금 도구는 이렇게 생겼습니다
두 차례 수리가 끝난 현재 상태입니다. ★가 이번 사건들로 생긴 규약입니다.
프로세스의 단계를 보여주는 순서도
이번에 얻은 교훈
루브릭(채점 기준표)에 항목이 있다는 것과, 그 항목이 실제 검사에 쓰인다는 것은 전혀 다른 문제였습니다. 확인법은 단순합니다 — 항목마다 “이걸 묻는 문장이 어디 있나”를 검색해 보는 겁니다. 정의만 있고 질문이 0건이면 그 항목은 죽어 있는 겁니다.
그리고 “판정은 재현된다”도 사실이 아니었습니다. 정확히는 “건강한 대상에서 15/15로 재현됐다”였습니다. 결함 있는 대상을 넣자 바로 2/4로 떨어졌으니까요. 측정이 틀린 게 아니라, 어디까지 재보고 한 말인지를 문장에 안 적어둔 것이 문제였습니다.
AI를 쓰면서 가장 크게 배운 것
메인 에이전트는 세 번 모두 자신 있게 틀렸습니다.
그 오류를 잡은 건 앞선 대화를 공유하지 않는 독립 검토였습니다. 같은 대화에서 AI에게 “다시 확인해봐”라고 묻는 것과, 맥락을 공유하지 않는 새 검토를 독립적으로 돌리는 것은 전혀 다른 일입니다.
이번 경험 이후 AI가 서로를 독립적으로 검증하도록 만드는 구조를 적절히 써야겠다고 생각이 들었습니다.
따라해볼만한 프롬프트
체크리스트를 적용해서 판정하는 스킬을 만들어 쓰고 계시다면, 아래 프롬프트를 에이전트에게 줘보세요.
아래 문서를 읽고, "완료·성공·저장됨"이라고 선언하는 자리를 전부 찾아줘.
<여기에 당신의 절차서·체크리스트 내용이나 파일 경로>
각 자리마다 아래를 표로 정리해줘.
| 완료를 선언하는 자리 | 무엇에 근거해 완료라고 하나 | 실제 상태를 다시 확인(readback)하는 동작이 있나 |
세 번째 칸이 "없음"인 줄이 이 문서의 빈 곳이야.
없다고 판단했으면 어떻게 찾아봤는지(어떤 명령으로 어디를 훑었는지)도 같이 적어줘 —
부재 주장은 근거 위치를 짚을 수 없으니, 탐색 범위가 있어야 내가 확인할 수 있어.
주의: 문서에 "확인한다"고 적혀 있는 것(선언 표면)과
실제로 확인하는 동작이 있는 것은 다르니 구분해서 표시해줘.이 프롬프트는 대화를 새로 열어서 (깨끗한 컨텍스트) 던지시는 걸 권합니다. 그리고 결과를 받았다면 같은 프롬프트를 또 다른 새 대화에 한 번 더 던져 두 답을 비교해 보세요. 판정이 갈리는 자리가 나오면, 그건 대개 AI가 오락가락하는 게 아니라 당신 기준표에 규칙이 빠져 있는 자리입니다. 제 도구의 반타작이 정확히 그렇게 잡혔습니다.
