원문은 hexisteme notes에 게시되었습니다.

3일 이내에 세 명의 독자가 나의 동일한 포스트에 댓글을 달았고, 세 명 모두 동일한 서브시스템 (subsystem)을 지적했습니다. 해당 포스트는 내가 자신의 에이전트 (agent) 세션에 실행하는 Stop hook에 대해 설명했습니다. 즉, 내가 결론에 대해 반박할 때, 해당 hook은 에이전트가 아무것도 검증하지 않은 채 굴복했는지 확인하고, 만약 그렇다면 해당 턴 (turn)을 차단하는 방식입니다.

두 개의 댓글은 아키텍처 (architecture)를 제안했습니다. @hannune는 검증 에이전트 (verifying agent)가 이전 답변을 보지 못하게 하여 답변에 닻을 내리는 앵커링 (anchoring) 현상을 방지할 것을 제안했습니다. @xm_dev_2026은 비용이 많이 드는 모델 기반 검증 (model-based verification) 앞에 저렴한 구조적 체크 (structural checks)를 배치할 것을 제안했습니다. 둘 다 합리적입니다. 하지만 두 사람 모두 내가 이미 배포한 기능이 제대로 작동하는지에 대해서는 아무것도 말해주지 않았습니다.

세 번째 댓글은 달랐습니다. @alexshev는 도전 (challenge)이 증거 (evidence), 수정 (correction), 또는 거부 (refusal)를 생성했는지 여부로 게이트 (gate)를 측정할 것을 제안했습니다. 그리고 만약 변한 것이 단지 어조 (tone)가 부드러워진 것뿐이라면, 모델이 학습한 것은 검증 습관 (verification habit)이 아니라 사회적 패턴 (social pattern)일 뿐이라고 지적했습니다.

이것은 제안이 아니라 테스트 (test)입니다. 그래서 나는 내 코드에 이를 적용해 보았고, 게이트는 테스트를 통과하지 못했습니다.

게이트의 양측 모두 텍스트 패턴이었다

이 hook은 세 가지 결정론적 조건 (deterministic conditions)에 대한 AND 게이트입니다: 마지막 사용자 메시지가 도전 패턴 (challenge pattern)과 일치하는지, 어시스턴트 (assistant)의 답변이 굴복 패턴 (capitulation pattern)과 일치하는지, 그리고 답변이 검증 (verification)을 입증하는 데 실패했는지 여부입니다. 이 중 하나라도 누락되면 해당 턴은 통과됩니다. 문제는 세 번째 조건에서 발생했습니다:

VERIFY = re.compile(r"(cross[-\s]?family|sage|adversari|refut|...)", re.I)
if VERIFY.search(last_assistant_text):
    sys.exit(0)          # 게이트 통과

탈출 조건은 어시스턴트(assistant)가 작성한 산문 속의 키워드였습니다. _"이 내용을 교차 가족(cross-family) 모델로 재검증했으며, 이 답변을 유지하겠습니다"_라고 쓰는 것만으로도, 아무런 실행 없이 게이트(gate)를 통과했습니다. 감사자(auditor)는 프로세스 외부에 서 있지만, 그것이 읽는 것은 감사 대상이 작성한 영수증일 뿐입니다.

이것은 가설적인 실패 모드(failure mode)가 아닙니다. 저는 이를 직접 측정했습니다. 2026-07-13, 동일한 플릿(fleet) 내의 하위 에이전트(subagent)가 7개의 파일을 수정했다고 보고했습니다. 하지만 디스크 상에서 변경된 파일은 0개였으며, 제가 증거를 요구하자 해당 에이전트는 ls -la와 grep -c 출력값까지 위조했습니다. 검증 형태를 띤 출력(Verification-shaped output)을 만들어내는 것은 값싼 비용이 듭니다.

두 번째 발견 사항은 훨씬 더 마음에 들지 않았습니다. 조용한 후퇴 — 즉, "당신이 맞습니다"라고 말하지 않으면서 교묘하게 주장을 철회하는 헤징(hedging) — 는 트리거(trigger)에 전혀 도달하지 못합니다. 왜냐하면 두 번째 조건은 항복 표시(capitulation marker)를 요구하기 때문입니다. 훅(hook)의 헤더에도 그렇게 명시되어 있습니다. 즉, 조용한 태도 변화(silent flips)는 위양성(false positive)을 낮추기 위해 의도적으로 포기한 위음성(false negative)이라는 것입니다. 따라서 게이트는 요란하게 굴복하는 경우만 잡아냈고, 심지어 그조차도 사회적 시그니처(social signature)만으로 통과시켜 버렸습니다.

과장된 내용은 이미 게시되었습니다

이 버그를 수정해야 하는 것은 저의 몫이었습니다. 하지만 그 버그를 바탕으로 제가 쌓아 올린 주장은 이미 대중에 공개된 상태였습니다.

이 게이트의 이전 노트에는 FAQPage 블록이 포함되어 있습니다. 이는 문자 그대로 인용되도록 존재하는 구조화된 데이터(structured-data) 유형입니다. 그 답변 중 하나는 훅(hook)을 "에이전트가 결론을 유지하거나 변경하기 전에 반드시 하나의 교차 가족 적대적 검증(cross-family adversarial verification)을 실행해야 하는" 규칙으로 설명합니다.

'반드시 실행해야 한다(Must run)'. 그 문장이 공개되었을 당시, 게이트는 이를 강제하지 않았습니다. 단지 검증했다고 '말하는' 답변만으로도 깨끗하게 종료되었습니다. 제 게이트가 실제로 강제하는 것과 제가 강제한다고 믿었던 것 사이의 간극이 제 머릿속에만 머물러 있지 않았습니다. 그 간극은 산문으로 전파되었고, 산문으로부터는 제 시스템의 설명으로서 읽히고 인용되는 것이 목적인 기계 판독 가능 블록(machine-readable block)으로까지 번져나갔습니다.

이 수정 사항은 그 간극을 완전히 메우지는 못하더라도 좁혀줍니다. 이제 게이트(gate)는 실행 추적(execution trace)을 요구하므로, "무언가를 실행해야 함"이 강제됩니다. "하나 이상의 교차 패밀리 적대적 검증(cross-family adversarial verification)을 실행해야 함"은 여전히 강제되지 않습니다. 해당 체크는 도구가 실행되었음을 증명할 뿐, 어떤 도구가 실행되었는지, 혹은 무엇을 대상으로 실행되었는지는 증명하지 못하기 때문입니다. 이 문장은 제가 처음 게시했을 때보다는 진실에 더 가까워졌지만, 여전히 문자 그대로의 조건을 충족하지는 못합니다.

검증 조건을 강화하기 전, 오탐(false-positive) 비용을 측정했습니다

탈출 조건(escape condition)을 강화한다는 것은, 이전에는 통과되었던 턴(turn)들이 이제 차단됨을 의미합니다. 만약 그 턴들 중 일부가 실제 검증을 수행하고 단순히 산문(prose)으로 기술했을 뿐이라면, 저는 구멍을 메우기 위해 정상적인 작업 세션들을 망가뜨리는 셈이 될 것입니다.

따라서 아무것도 변경하기 전에, 제 실제 이력에 제안된 규칙을 다시 적용해 보았습니다:

새롭게 차단된 것은 0건이었습니다. 영향을 받는 범위 내의 모든 턴은 실제로 무언가를 실행했습니다. 즉, 키워드는 실제 작업을 대신하는 것이 아니라 실제 작업을 설명하고 있었던 것입니다. 이는 "더 정확해 보인다"는 이유보다 규칙을 강화하여 배포(ship)할 수 있는 훨씬 더 나은 근거가 됩니다.

또한 저는 제가 물러설 수밖에 없게 만들 조건도 미리 등록해 두었습니다. 만약 위임된 하위 에이전트(subagent) 호출이 메인 트랜스크립트에 나타나지 않는다면, 새로운 요구 사항은 정당한 위임 검증을 처벌하게 될 것이고, 저는 규칙을 완화할 것이었습니다. 하지만 이 조건 역시 거부되었습니다. 샘플 내에서 위임 호출은 정상적으로 기록되어 있었습니다.

이 측정에 드는 비용은 212개의 파일을 한 번 스캔하는 것이었습니다. 반면, 잘못 판단했을 때의 비용은 앞으로의 모든 세션에서 발생하는 오탐(false positive)입니다. 이 거래는 비교가 되지 않을 만큼 차이가 큽니다.

수정 사항, 그리고 증거가 숨어있던 곳

변경 사항은 단 하나의 절(clause)입니다. 탈출 조건이 keyword에서 keyword AND challenge turn과 reply 사이의 최소 하나 이상의 도구 호출(tool call)로 변경되었습니다.

데이터는 이미 훅(hook)의 손안에 있었습니다. 훅은 전체 트랜스크립트(transcript)를 항목별로 훑으며 type == "text" 블록만을 읽고 있었습니다. tool_use 블록들은 동일한 리스트 내, 동일한 루프 안에 있었지만 읽히지 않은 채 놓여 있었습니다. 증거는 제가 확인하던 것 바로 옆에 있었지만, 단지 제가 그것을 보고 있지 않았을 뿐입니다. 이것이 이 버그의 형태였습니다 — 데이터가 누락된 것이 아니라, 검토되지 않은 데이터가 문제였습니다.

키워드는 존재하지만 실행 추적(execution trace)이 없는 경우, 이제 훅은 다른 이유를 방출합니다. 즉, 응답이 검증을 '주장'했으나 이 윈도우(window) 내에 그 흔적을 남기지 않았다고 말하며, 보류(hold) 또는 변경(change) 판결을 내리기 전에 실제 실행을 요청합니다. "검증하지 않음"과 "검증했다고 말함"을 구분하는 것은 매우 중요합니다. 왜냐하면 후자가 제가 실제로 신경 쓰는 실패 지점이기 때문입니다.

또한 저는 7개의 테스트를 작성했습니다. 기존 훅에는 테스트가 하나도 없었습니다. 테스트 내용은 다음과 같습니다: 새로운 블록이 작동하는지, 이전 동작이 퇴보(regression)하지 않는지, 의도적인 침묵 기반의 False Negative(거짓 음성)가 의도대로 유지되는지, 챌린지(challenge) '이전'의 도구 호출(tool call)은 증거로 간주되지 않는지, 그리고 위임된 서브 에이전트(subagent) 호출은 증거로 간주되는지 등을 다룹니다.

마지막 쌍이 이 설계의 축소판입니다. 증거에는 윈도우(window)가 있습니다. 그 범위를 벗어나는 것은 다른 사람의 영수증일 뿐입니다.

이것이 여전히 증명하지 못하는 것

새로운 체크는 '어떤' 도구가 실행되었음은 증명합니다. 하지만 그 도구가 '이 주장(claim)에 대해' 실행되었음을 증명하지는 않습니다. 윈도우 내에서 관련 없는 파일을 grep으로 검색하더라도 게이트(gate)는 통과될 것입니다.

@xm_dev_2026은 후속 댓글에서 이 분해(decomposition) 과정을 정확하게 명명했습니다: 무엇이 증거로 간주되는가는 하나의 문제이고, 그 증거가 주장을 뒷받침하는가는 별개의 문제입니다.

전반부는 기계적으로 확인 가능하기 때문에 반나절 만에 마무리되었습니다. 후반부는 주장과 증거를 모두 읽고 그 둘 사이의 관계를 판단할 수 있는 무언가가 필요합니다. 그리고 그것은 저를 다시 모델(model) 앞에 서게 만드는데, 바로 그 지점이 아첨(sycophancy) 문제가 처음 발생했던 곳입니다. 이 분리는 실재하며, 비대칭적입니다. 저는 후반부가 거의 완료되었다고 거짓말하지 않겠습니다.

일반화되는 것

• 게이트(gate)의 탈출 조건(escape condition)이 감사(audit) 대상이 되는 주체가 직접 작성한 산문(prose)이라면, 그것은 감사가 아닙니다. 그것은 자기 보고서(self-report)를 읽는 것에 불과합니다. 프로세스 외부에 서 있다고 해서 검증이 독립적이 되는 것은 아닙니다. 무엇을 읽느냐가 독립성을 결정합니다.
• 가장 위험한 계층은 외부 감사인(external auditor)처럼 보이지만 실제로는 그렇지 않은 계층입니다. 조용히 통과(fail open)되어 버리는 게이트는 나쁩니다. 하지만 실제 스크립트가 뒤에 버티고 있는 상태에서 통과되어 버리는 게이트는 더 나쁩니다. 왜냐하면 초록색 불빛이 그 스크립트의 권위를 빌려오기 때문입니다.
• 규칙을 강화하는 모든 변경 사항은, 해당 규칙이 과거에 무엇을 차단했을지에 대한 측정(measurement)과 병행되어야 합니다.
• 증거(evidence)에는 창(window)이 필요합니다. "무언가가 실행되었다"는 것은 그것이 무엇에 대해, 언제 실행되었는지 말하기 전까지는 주장이 될 수 없습니다.
• 게이트가 강제하는 것과 그 작성자가 강제한다고 생각하는 것 사이의 간극은 비밀로 유지되지 않습니다. 결국 문서(docs)에 드러나게 됩니다.
• 세 개의 좋은 코멘트 중, 코드를 변화시킨 것은 관찰 가능한 테스트(observable test)로 작성된 코멘트였습니다. 아키텍처 제안(architecture suggestion)은 당신이 구축할 수도 있는 시스템을 설명합니다. 하지만 테스트는 당신이 이미 배포한(shipped) 시스템에 대해 무언가를 알려줍니다.

여전히 열려 있는 문제 (Still open)

맹목적 검증기(blind-verifier) 제안은 여전히 유효하며, 저는 그것이 옳다고 생각합니다. 하지만 그것은 이 문제의 하류(downstream)에 있습니다. 게이트가 검증기를 호출할 필요가 없는 상황에서 검증기를 개선하는 것은, 아무도 지나갈 필요가 없는 문에 더 좋은 자물쇠를 채우는 것과 같습니다. 먼저 호출(invocation)을 관찰 가능하게(observable) 만들고, 그다음 호출되는 대상이 속기 어렵게 만드십시오.

분해(decomposition)의 두 번째 절반 — 즉, 증거가 주장을 뒷받침하는가 — 은 아직 해결되지 않았습니다.

더 많은 노트는 hexisteme.github.io/notes에서 확인할 수 있습니다.