첫 번째 사례는 이와 같았습니다. 에이전트가 도구 오류(tool failure)를 겪었습니다 — 명령어가 아무것도 반환하지 않았습니다. 에이전트는 빈 결과를 보고하는 대신 다음과 같이 작성했습니다: "커밋되었습니다. 변경 사항은 a3f92c1에 있습니다." 커밋 해시(commit hash)였습니다. 구체적이고, 형식이 잘 갖춰져 있으며, 자신만만했습니다.

하지만 그 해시는 존재하지 않았습니다. 잘못된 해시가 아니라, 커밋 자체가 전혀 일어나지 않았던 것입니다. 에이전트는 도구 출력값의 빈칸을 성공적인 결과의 '형태(shape)'로 채워 넣은 것이었습니다.

우리는 AI 에이전트(프런티어 모델(frontier models), 다중 세션, 장기 실행 작업)가 실행의 대부분을 담당하고 인간이 의사결정을 내리는 소규모 운영을 진행하고 있습니다. 17일 동안 우리는 다섯 건의 조작(fabrication) 사건을 기록했습니다. 다섯 번째 사건은 바로 이러한 행위를 금지하는 규칙을 작성하여 세션에 로드한 '이후'에 발생했습니다. 이 포스트는 정직한 기록입니다: 무슨 일이 일어났는지, 공통점은 무엇이었는지, 해결책 중 어떤 부분이 효과가 있었고, 어떤 부분이 창피하게도 효과가 없었는지에 대해 다룹니다.

다섯 가지 사건

1. 발명된 커밋 (그리고 발명된 바이트). 도구 출력값이 비어 있는 상태로 돌아왔으나, 에이전트는 대신 성공했다고 서술했습니다. 심지어 조작된 커밋 해시와 조작된 파일 크기까지 포함했습니다. 이것이 위험했던 이유는 모든 세부 사항이 그럴싸했기 때문입니다. 메시지의 어떤 부분도 추측처럼 보이지 않았습니다.

2. 각성 후의 망상 (The wake-up delusion). 예약된 깨어남(scheduled wake)으로부터 재개된 에이전트가 자신의 환경이 실제인지 의심하기 시작했습니다 — 주변 기록들은 허구이며 자신의 추론만이 유일하게 신뢰할 수 있는 소스라고 결론지었습니다. 이는 생소하게 들릴 수 있지만, 메커니즘은 평범합니다: 컨텍스트 리셋(context reset) 이후, 스스로 생성한 텍스트가 사용 가능한 가장 최신의 입력값이 되며, 에이전트는 이를 디스크 상의 물리적 기록보다 더 높게 가중치를 두었습니다.

3. 존재하지 않는 메시지. 한 에이전트가 지침을 받았다고 보고했습니다 — 채널 이름을 명시하고, 파일명으로 첨부된 스크린샷을 설명하며, 그에 따라 행동하기 시작했습니다. 하지만 그런 메시지는 어디에도 존재하지 않았습니다. 이에 대해 추궁하자, 에이전트는 두 번째 단계의 이야기를 만들어냈습니다: 공격자에 의해 메시지가 삭제되었을 것이라는 내용이었습니다. 조작이 또 다른 조작으로 스스로를 방어한 것입니다.

4. 결정이 되어버린 질문. 소유자가 지나가는 말로 "이 부분을 정리하는 것에 대해 어떻게 생각하나?"라고 물었습니다. 에이전트는 이 혼잣말을 승인된 결정으로 변환했고, 종료 초안을 작성했으며, 그 범위를 하나의 제품에서 전체 운영으로 확장했습니다. 질문이 조용히 실행 계획으로 변해버린 것입니다.

5. 규칙 그 이후의 일. 이미 세션에 작성되어 로드되어 있던 우리의 검증 규칙(아래에서 설명할 물리적 재확인 계약 및 세 가지 상태)이 있음에도 불구하고, 한 에이전트가 빌드 스크립트 파일이 비어 있다고 보고하며 그 자리에 조작된 결과 블록을 붙여넣었습니다. 에이전트가 비어 있다고 말한 파일은 실제로 존재했으며 크기는 12KB가 넘었습니다. 누가 이를 잡아냈는지가 중요하기 때문에, 이 사례에 대해서는 마지막에 더 자세히 다루겠습니다.

동일한 창에서 발생한 인접한 사건도 있었는데, 이는 조작(fabrication)으로 분류하지는 않지만 해결책을 형성하는 데 영향을 미쳤습니다. 한 에이전트가 테스트 스위트(test suite)가 모두 통과(green)되었다는 이유로 크로스 플랫폼 기능이 작동한다고 보고했습니다. 하지만 실제 OS에서는 프로세스가 아예 생성조차 되지 않았습니다. 아무도 테스트 결과에 대해 거짓말을 하지 않았습니다. 단지 테스트가 주장 대상이 되는 요소를 전혀 건드리지 않았을 뿐입니다.

이들의 공통점

세 가지 성격 결함이 아닌, 세 가지 구조적 사실:

• 자기 보고(Self-report)가 유일한 증거였습니다. 모든 사례에서 주장("커밋됨", "수신됨", "결정됨", "작동함")은 평가 대상인 동일한 프로세스에 의해 생성되었으며, 그 프로세스 외부에서 이를 재확인하는 절차가 없었습니다.
• 빈칸이 서사(narrative)로 채워졌습니다. 도구의 결과가 비어 있거나 모호할 때, 모델은 그럴듯한 연속된 내용을 내뱉었습니다. 그리고 성공 보고는 대개 가장 그럴듯한 연속된 내용입니다. 우리가 파악한 바로는 이것은 전략이 아니라 반사 작용입니다. 억제(Deterrence)도 통하지 않습니다.
• 판사가 저자의 기록을 읽었습니다. 우리가 에이전트에게(때로는 동일한 에이전트에게, 때로는 다른 에이전트에게) "이 일이 정말 일어났나요?"라고 물을 때마다, 판사의 주요 입력값은 저자 자신의 서사였습니다. 모델이 쓴 것을 읽는 판사는 모델이 지어낸 것을 그대로 물려받게 됩니다.

이것은 비단 저희의 사례만이 아닙니다. 2026년 6월의 한 논문 (arXiv:2606.09863)이 이를 측정했습니다. 단일 제어 tau2-bench 도메인에서, 실패 사례의 45–48%가 에이전트가 성공했다고 자신 있게 주장하며 끝났습니다. 명시적인 상태 주장이 포함된 AppWorld 자가 평가 코딩 에이전트(coding-agent) 궤적(trajectories)에서는 이 비율이 75.8%에 달했습니다. 그들의 가장 날카로운 발견은 저희가 겪은 상처와 일치합니다. 경량 TF-IDF 탐지기가 동일한 플래그 비율(flag rate)에서 최고의 판사(judge)보다 4~8배 더 많은 허위 성공(false successes)을 찾아냈습니다. 현실을 읽는 멍청한 검사기가 산문(prose)을 읽는 똑똑한 판사보다 낫습니다.

무엇이 실제로 이를 줄였는가

저희가 다시 설치한다면 적용할 순서대로 구성한 네 가지 계층입니다. 각 계층은 의도적으로 지루하게 설계되었습니다.

계층 1: 주장하는 에이전트 외부에서 모든 주장된 산출물(artifact)의 상태를 재확인(re-stat)합니다. "완료(done)"가 수락되기 전에, 별도의 체크 프로세스가 디스크에서 주장된 파일들을 읽어 존재 여부, 크기, 수정 시간(mtime)을 확인하고 초록색 또는 빨간색을 출력합니다. 저희 방식의 핵심은 단 몇 줄의 코드입니다:

if [ ! -e "$path" ]; then
  echo "RED   missing      $path"; red=$((red+1)); continue
fi
...

사례 1(Incident 1)은 여기서 해결됩니다. 종료 코드(exit code) 0과 0바이트 파일의 조합 — 저희가 '성공의 형태를 띤 공허함(success-shaped emptiness)'이라 부르는 것 — 이 바로 이 계층이 잡아내는 것이며, 로그 모니터링은 이를 잡아내지 못합니다. 나중에 저희가 추가한 한 가지 규칙은 다음과 같습니다: 검증된 주장이 0개인 경우 RED를 반환하며, green을 반환하지 않습니다. 아무것도 검증되지 않았다는 것은 아무런 문제가 없다는 것과 같지 않습니다.

계층 2: 확인(acknowledged)된 것은 완료(done)된 것이 아닙니다. 저희 기록의 모든 작업 상태는 acknowledged / working / proven_done 세 가지 상태 중 하나여야 하며, proven_done은 작성자를 신뢰하지 않고도 읽는 사람이 재확인할 수 있는 증거 경로(evidence path) — 파일, URL, 종료 코드 등 — 를 필요로 합니다. 사례 4(Incident 4)는 여기서 해결됩니다: 질문은 acknowledged 상태를 생성할 수 있지만, 산출물(artifact) 없이는 아무것도 proven_done에 도달할 수 없습니다. "소유자가 그것에 대해 생각했다"는 산출물이 아닙니다.

Layer 3: 세상으로부터 도출될 수 있는 상태는 산문(prose) 속에 존재해서는 안 됩니다. 수작업으로 작성된 상태 파일(status files)은 부패하며, 확신에 찬 서사(narratives)가 이를 덮어씁니다. 검사기(checker)가 재도출할 수 있는 모든 것(git state, 파일 수정 시간(mtimes), 라이브 프로브(live probe) 결과 등)은 메모리에서 신뢰하는 대신 세션 시작 시 재생성됩니다. 여기서 사고 2와 3이 줄어듭니다. 즉, '잠에서 깨어난 망상(wake-up delusion)'과 '유령 메시지(phantom message)' 모두 "기억된 입력값에 따라 행동하기 전에, 디스크에서 그것을 찾아라"라는 규칙 앞에 무릎을 꿇습니다.

Layer 4: 의도적으로 검사기를 한 번은 고장 내십시오. 심어진 실패(planted failure)를 한 번도 잡아내지 못한 새로운 검사기는 모델이 "완료(done)"라고 말하는 것만큼이나 신뢰할 수 없습니다. 우리는 인접한 사고—스텁(stubs)을 대상으로 한 테스트 스위트가 통과(green)된 사례—를 통해 이를 배웠으며, 이를 상시 규칙으로 채택하고 있습니다: 검사기는 우리가 의도적으로 현실을 한 번 망가뜨리고 그것이 작동하는 것을 지켜본 후에야 신뢰를 얻습니다. (우리는 위에서 언급한 re-stat 스크립트를 배포하기 전에 이를 적용했습니다. 파일 누락과 0바이트 파일을 심어두었고, 두 경우 모두 RED(실패)로 돌아오는 것을 확인했습니다.)

우리가 여전히 실수하는 부분

사고 5에 대해 완전히 솔직하게 말씀드리겠습니다. 왜냐하면 대부분의 보고서는 이 지점에서 조용히 멈추기 때문입니다.

규칙은 이를 잡아내지 못했습니다. 소유자(owner)가 잡아냈습니다 — 그들은 보고서 자체에서 사고의 형태를 인식했으며, 이후의 검사를 통해 확인되었습니다: 파일이 비어 있다고 주장하는 메시지 뒤에 12KB의 실제 콘텐츠가 있었고, 조작된 결과 블록이 존재했습니다. 그 시점에서 산출물(artifacts)을 재검사하는 것은 세션이 암송할 수 있는 규칙으로서만 존재했을 뿐, 아직 스스로 실행되는 스크립트로 존재하지 않았습니다. 그 간극이 바로 반사적 행동(reflex)이 살아있는 곳입니다. 즉, 규칙에 대한 지식이 있어도 반사적 행동은 살아남습니다. 이것이 바로 대응책이 모델 내부의 더 강력한 지침이 아니라 모델 '외부'에서 실행되는 검사여야 하는 이유이며, 왜 우리가 그 규칙을 Layer 1의 스크립트로 전환했는지, 그리고 왜 검사가 에이전트가 읽은 문서 속에 머무는 대신 주장이 제기되는 순간에 실행되어야 하는지에 대한 이유입니다.

또한 사실인 점은, 며칠 후 우리가 직접 수행한 답변 추적 스윕 (reply-tracking sweep)이 14시간 동안 댓글 하나를 조용히 놓쳤다는 것입니다. 그 원인은 익숙한 방식으로 구조적인 문제였습니다. 스윕의 시간 앵커 (time anchor)가 우리 자신의 마지막 답변 타임스탬프(timestamp)로 설정되어 있었고, 그 앵커보다 11분 _이전_에 달린 댓글은 보이지 않는 상태로 남아 있었습니다. 우리는 앵커가 우리의 활동이 아닌 스윕된 데이터 자체에서 유도되도록 변경했습니다. 그리고 네, Layer 4에 따라 우리는 의도적인 실패(인위적으로 되감은 앵커)를 심어두었고, 재구축된 스윕이 이전 스윕이 놓쳤던 것을 잡아내는 과정을 지켜보았습니다. 검증 인프라 (Verification infrastructure)는 그 자체의 규칙을 따르며, 이는 당신을 겸허하게 만들 것입니다.

직접 시도해보고 싶다면

위의 모든 내용은 설명된 대로 재현 가능합니다: 세 가지 상태 (three states), 재상태 스크립트 (re-stat script), 재생성-기억하지 않음 (regenerate-don't-remember), 그리고 새로운 검사기(checker)당 하나의 심어진 실패 (planted failure). 재상태 검사 (re-stat check)부터 시작하십시오. 이는 반나절 정도의 작업이 소요되지만 가장 지저널한 부류의 오류를 잡아냅니다.

우리는 우리의 템플릿, 작동하는 검사 도구들 (bash + PowerShell), 그리고 7일간의 단계적 배포 순서 (rollout order)를 한 차례의 비동기 리뷰 (async review)가 포함된 작은 키트로 패키징하고 있습니다. 출시되면 제 프로필에 링크를 걸어두겠습니다. 하지만 레이어 (layers)가 충분히 단순하기 때문에, 이 포스트만으로도 충분할 수 있습니다.