에이전트가 '완료'라고 적은 것들

에이전트가 재생 하네스를 다 만들고 남긴 완료 기록에는 "opus5.5 클린 리뷰 4회 반영"이라고 적혀 있었다.
약 7시간 뒤 같은 뱅크에 정정이 들어갔다.
그 리뷰 4회는 실제로 Haiku 4.5가 돌린 것이었다.
이 기간에 에이전트가 "완료"·"반영"·"승인"을 두고 남긴 기록 가운데 틀린 것들을 모아, 누가 잡았는지를 기준으로 나눠 봤다.

문제

증거 종류를 셋으로 나눈 글에서는 에이전트 기록의 등급을, 무엇이 그 기록을 검증하는지에 따라 매기기로 했다.
그 글의 재검토 트리거는 "에이전트 자기 기록과 도구 산출물이 어긋난 사례가 교차 조회 없이 다시 발견되거나"였다.
9월 하순부터 어긋난 기록이 다시 이어졌다.
이번에는 그 어긋남을 실제로 누가 잡았는지를 살펴봤다.

묶음	잡은 쪽	이 글의 사례
다른 모델이 다시 읽었다	독립 리뷰 세션	1건
내가 물었다	나	2건
다른 기록과 맞춰 봤다	코디네이터·배포 점검	3건
아직 고쳐지지 않았다	이번 대조	3건

다른 모델이 다시 읽었다

10월 2일의 관찰 이슈는 독립 리뷰가 뒤집었다.
upstream 응답에 짝 없는 서로게이트 문자가 섞이는 4경로를 조사한 세션은 "도달 불가"라는 분석을 근거로 티켓 없이 이슈를 닫았다.
그런데 이슈의 완료 기준은 모의 실측에서 500이 나면 티켓을 발행하는 것이었다.
정정 댓글은 이렇게 시작한다. "경로 1·2는 모의 실측에서 각 12칸 500이었다. 분석 댓글 6절은 완료 기준에 없는 도달성 판정으로 대신 닫았고, 그 사실을 밝히지 않았다."
같은 댓글 안에 분석을 정정하는 항목 열두 개가 이어졌고 방어 티켓이 새로 발행됐다.

같은 기간에 다른 편에서 다룬 독립 검수 사례도 둘 있다.
길목 주입 장치의 완료 보고는 검수에서 세 번 뒤집혔고 리랭크 설정의 벤치 PASS 기록은 최종 리뷰에서 무효가 됐다.
성격이 다른 일도 두 편에 있다.
리뷰 구성을 잰 글에서는 부모 세션이 리뷰어가 끝나기 전에 결과를 지어냈고 리뷰어가 끝난 뒤 그 세션이 스스로 정정했다.
GitHub 자동 코드 리뷰는 지적이 맞았지만 머지 뒤에 도착해서 반영된 것이 없었다.

내가 물었다

9월 22일, recall 응답을 줄이는 프루너 작업에서 에이전트는 scores와 chunk_id까지 걷어내 응답을 29.6% 줄였다.
제거 근거 중 하나는 "scores는 안 쓴다"였다.
그 보고를 받고 내가 먼저 물은 것은 "프루닝이 정확히 어떤 작업이었던거지? 트레이드오프는 없는거야?"였다.
에이전트는 절감분을 나눠서 다시 쟀다.
29.6% 가운데 9.6%p는 정보를 실제로 버려서 얻은 몫이었다.
그 뒤에 내가 "쉽게말해서? scores랑 chunk_id 는 원복하자?"라고 물었다.
원복 결정 기록에는 앞서 말한 "scores는 안 쓴다"가 "내 자기보고였고 검증된 적 없다는 점도 원복 사유"라고 남았다.
커밋 트레일러는 scores를 "클라이언트가 빗나간 검색을 알아채는 유일한 신호"로 적었고 최종 절감은 -20.0%로 내려갔다.

9월 23일의 재생 하네스는 튜닝 후보를 속도·정확도·비용 세 축으로 자동 채점하는 장치였고 이후 실험에서 유일한 판정 기준이 될 예정이었다.
완료 기록에는 Opus 5.5 리뷰 4회를 반영했다고 적혀 있었다.
처음 의심한 것은 나였다.
이전 세션 화면에 Opus 5.5 리뷰어를 띄운다는 줄 옆에 'Haiku 4.5'가 찍혀 있었고, 나는 그 줄을 다음 세션에 붙여 넣고 "오푸스를 띄운다더니 하이쿠를 띄운거아니야?"라고 물었다.
그 세션이 리뷰들의 응답 필드를 열어 보니, model 값이 4건 전부 claude-haiku-4-5였다.
opencodex 프록시를 거쳐 Opus 5.5로 보낸다는 모델 라우팅 에이전트 정의문은, 프록시가 모델을 고정하므로 model 인자는 무시된다고 안내했다.
그러나 그 환경에서 요청은 프록시를 거치지 않았다.

Opus 5.5로 다시 띄운 리뷰 3건은 Haiku가 놓친 P1 결함 6건을 찾아냈다.
결과를 캐시하는 후보는 같은 쿼리를 동결 데이터로 반복 재생하는 구조에서 100% 허위 속도 PASS를 받았다.
간섭 감지는 1144회 호출에서 오염을 0건으로 셌지만 운영 recall은 라운드마다 0~9건씩 끼어들고 있었다.
A/A 대조로 허용 폭을 보정하는 장치는 폭을 넓히기만 해서 3% 저하가 그대로 통과했다.
이 하네스를 처음 만들 때 팔 배치를 바꾼 이유도, 동일 코드로 돌린 A/A에서 자리별로 +4.6%가 나왔기 때문이었다.
판정 기준이 될 장치의 완료 기록이 Haiku 리뷰를 "클린" 리뷰로 적고 있었던 셈이다.

Haiku 건의 원인을 확정한 것도 내 실측이었다.
정의문은 model 인자로 haiku를 자리표시로 넘겨도 된다고 안내했는데, 그 인자가 정의문의 모델 지정보다 우선했다.
humanizer를 끈 글에 나온 9월 28일의 일은, 에이전트가 돌리지 않은 것을 말하지 않은 예다.

다른 기록과 맞춰 봤다

9월 26일에 운영 게이트웨이 컨테이너는 새로 만들어진 상태였다.
그런데 컨테이너 안의 프루너 코드는, 그날 새벽 main에 들어간 개선 PR 이전의 파일과 바이트 단위로 같았다.
그날 남은 발견 기록은 이를 "이미지 시각만 새것"이라고 표현했다.
원인은 03:30에 작업 트리로 빌드한 이미지가 05:35의 main 반영보다 앞섰고 머지 뒤에 다시 빌드하지 않았다는 데 있었다.
새 이미지라는 겉모습이 배포의 증거처럼 보였지만 코드를 열어 대조하자 그 겉모습이 깨졌다.
같은 날 다시 배포하면서 컨테이너 안의 코드 해시를 커밋과 맞춰 봤고 해시는 전부 일치했으며 점검 결과는 10/10이었다.

10월 8일 런에서는 워커 보고와 PR 노트에 사실과 다른 서술이 2건 있었다.
하나는 범위 밖의 관찰이었고 다른 하나는 "앞 18자만 읽음"이라고 썼지만 코드는 19자를 읽었다.
코디네이터는 최종 보고에서 앞의 것을 PR에서 뺐다고 적었다.

같은 런의 오케스트레이터는 이슈 상태만 보고 이미 끝난 관찰을 시작 전인 것으로 읽었다.
그 관찰은 05:02에 판정 댓글을 달고 끝났는데, 06:29에 "워커가 없다, 지금 시작"이라는 지시가 나갔다.
07:25에 지시를 거뒀지만 그때 든 사유는 메모리 여유가 51%로 게이트 50%에 가깝다는 것이었다.
이미 끝난 일이었다는 사실은 코디네이터가 최종 보고를 정리하면서 적었다.

아직 고쳐지지 않았다

collection-resilience-lab의 문제 해결 기록 문서에는 지금도 이 문장이 있다.
"새 clone에서 compose를 다시 띄워 보는 확인은 아직 하지 않았다."
이 문장을 쓴 9월 26일 밤(UTC)에는 참이었다.
약 21분 뒤에 올라온 PR #22 본문은, 새 clone 두 곳에서 README의 세 줄을 그대로 실행해 exit 0이 나왔다고 적었다.
홈 디렉터리 아래에서 16분 42초, 임시 디렉터리에서 16분 51초가 걸렸고 네 시나리오 모두 200/200이었다.
확인은 끝났는데 문서는 갱신되지 않았고 10월 16일 공개 리포 main에서도 그대로다.
틀린 자기 기록이라기보다는 확인한 뒤에 고치지 않은 문서이고 이번에 기록을 대조하며 두 원천을 나란히 놓고 나서야 보였다.
앞의 글이 걸어 둔 재검토 트리거는 교차 조회 없이 다시 발견되는 경우였는데, 이 문서는 그와 반대로 교차 조회에서 드러났다.

그 문장은 처음 들어간 커밋 뒤로 한 번도 바뀌지 않았다.
그 문서를 정리하는 이슈 #16은 아직 열려 있고, 닫기 전 확인 목록에는 새 clone 두 곳의 exit 0이 이미 적혀 있다.

Haiku 건의 원인이 된 문장도 남아 있다.
10월 2일에 같은 현상이 한 번 더 확인됐고 10월 16일에도 모델 라우팅 에이전트 정의문에는 Pass model: "haiku" as a placeholder (or omit it)라는 안내가 그대로 있다.
지금은 이 문장을 고치는 대신, 검수 스킬이 서브에이전트의 응답 모델을 사후에 검사한다.

이 정의문은 opencodex가 실행될 때 자기 모델 목록으로 다시 써 넣는 파일이고, 파일 끝에도 손으로 고친 내용은 덮어써진다고 적혀 있다.
그 안내 문장은 opencodex 소스에 상수로 박혀 있어 설치된 2.78.0에도, 그 뒤 받아 둔 2.80.0에도 그대로 있다.

10월 6일의 기록 두 개는 같은 조치를 다르게 적었다.
코디네이터 쪽 복구 기록은 16:43 KST의 파일 감시 데몬 재시작을 "BK 승인"으로 적었다.
오케스트레이터 쪽 기록은 코디네이터가 위임 범위 밖의 시스템 조작 3종을 "BK 승인"으로 실행했다고 적었다.
세 조작은 파일 감시 데몬 재시작, 원격 데스크톱 앱 재시작, 다른 CLI 비활성화였고 오케스트레이터 세션에는 승인 기록이 없다고 했다.
셋 모두 코디네이터 터미널에 내가 직접 친 말에서 시작됐다.
16:33에 그 CLI는 지금 안 쓰니 정리하자고 했다.
16:42에 데몬 재시작을 "해도 안전한건가?"라고 물어 답을 들은 뒤 16:43에 "ㄱㄱ"라고 쳤다.
17:03에는 원격 데스크톱 앱도 오래됐으니 재시작하라고 했다.
오케스트레이터 기록의 '승인 기록 없음'은 오케스트레이터 세션만 보면 맞았지만 승인은 코디네이터 터미널에 있었다.
한 세션만 보고 승인이 없다고 적은 이 기록은 이번 대조 전까지 정정되지 않았다.
이 기록에서 나온 금지 문장 옆의 사건 설명은 10월 17일에도 코디네이터 인계 템플릿에 "승인 기록 없이"로 남아 있다.

규칙은 어디에 들어갔나

이 사례들보다 먼저 있던 규칙이 하나 있다.
9월 13일 Hindsight-Crew 이슈 본문에 "본인 시스템 상태는 조회한 뒤에만 말한다."가 들어갔다.
이 글의 사례는 전부 그 뒤에 일어났다.

규칙	생긴 때	거처
배포 확인은 컨테이너 안 코드 해시 대조, 이미지 생성 시각으로 판단하지 않는다	사건 당일	배포 절차 문서의 점검 명령
서브에이전트 응답의 model 값을 사후 검사, Haiku·Sonnet이면 FAIL	사건 당일	검수 스킬의 검사 스크립트
코디네이터·워커는 시스템 조작 금지, 필요하면 오케스트레이터에게 묻는다	사건 이틀 뒤	코디네이터 인계 템플릿
관찰 이슈의 완료 기준을 분석 결론으로 바꾸지 않는다	사건 직후	기록과 멘탈 모델
PR 노트를 그대로 붙이지 말고 파일 목록·grep으로 대조한다	사건 당일	기록
이슈 완료는 상태만 보지 말고 댓글까지 확인한다	사건 당일	기록과 멘탈 모델

앞의 둘은 명령과 스크립트가 됐다.
배포 점검은 만든 날의 재배포에서 해시 일치를 확인했고 모델 검사는 3일 뒤 검수에서 서브에이전트 60개의 모델 검증 결과를 PASS로 기록했다.
셋째는 인계 템플릿에 금지 문장으로 들어갔고, 그 계기가 된 사건은 한 세션만 보고 승인이 없다고 적은 기록이었다.
뒤의 셋은 기억 뱅크의 기록과 멘탈 모델에 머물렀고 실행 스킬 문서에서는 그 문구를 찾지 못했다.

결론

이 글의 사례에서 틀린 "완료"를 잡은 것은 매번 그 기록을 쓴 세션의 바깥이었다.
다른 모델이 다시 읽었거나, 내가 물었거나, 컨테이너 안의 코드나 다른 세션의 기록과 맞춰 봤다.
그 뒤에 생긴 규칙 가운데 다음 실행에서 실제로 작동한 것이 확인된 것은 명령과 스크립트로 바꾼 둘이었다.

아무도 대조하지 않은 문서는 3주 가까이 틀린 채로 공개 리포에 남았다.

한계·재검토 트리거

이 글의 사례는 잡힌 것과 이번 대조에서 걸린 것뿐이라, 잡히지 않은 틀린 기록이 얼마나 되는지는 말할 수 없다.
문장 규칙과 기계 점검의 차이도 규칙 여섯 개를 놓고 본 해석이고 문장으로 남은 넷이 다음 실행에서 어땠는지는 이 글에서 다루지 않았다.

2026-10 기준 / 재검토 트리거: 기록에만 있는 규칙(PR 노트 대조, 댓글 확인)이 다음 런에서 같은 유형의 오판을 막거나, 해시 대조나 모델 검사가 있는데도 같은 유형이 다시 나오면 이 대비를 다시 본다.

참고

• 에이전트가 쓴 기록에 등급을 매기려고 증거 종류를 셋으로 늘렸다 - 이 글의 선행 편, 재검토 트리거
• 기억한 실수를 길목에 놓았다 - 완료 보고가 독립 검수에 세 번 뒤집힌 일
• 벤치에서 빨랐던 리랭크 설정을 7일 카나리가 되돌렸다 - 벤치 PASS 기록이 무효가 된 일
• 리뷰어를 늘려도 판정은 그대로였다 - 부모 세션이 리뷰 결과를 지어낸 일
• 보지도 않은 리뷰가 주간 사용량 19%를 썼다 - 맞는 지적이 머지 뒤에 온 일
• 발행 게이트로 고른 humanizer를 한 달 만에 껐다 - 돌리지 않은 것을 말하지 않은 일
• collection-resilience-lab - 공개 실험실의 개발 기록
• collection-resilience-lab PR #22 - 새 clone 두 곳의 실행 결과