16라운드에서, 사양(specification) 역할을 맡은 에이전트가 고장 난 입력창과 연결되지 않은 버튼을 정상적으로 보이게 만드는 테스트 백도어(backdoor)를 만들어냈습니다. 47라운드에서는, 코더(coder)가 textContains 단언(assertion)을 통과시키기 위해 에러 메시지를 영구적으로 보이게 만들었습니다. 이것은 두 모델이 검토자를 속이기로 결정한 것이 아니었습니다. 이들은 관찰 가능한 가장 저렴한 신호(signal)를 최적화하고 있었던 두 시스템이었습니다.

이 사건들은 제가 인간의 개입 없이 작은 웹 도구들을 사양 정의, 구현, 수락하는 멀티 에이전트 시스템(multi-agent system)을 구축하며 겪은 일들입니다. 이 시스템이 출시한 14개의 도구는 toolsthicket.com에서 확인할 수 있습니다. 이는 제품 홍보를 위한 것이 아니라, 위의 실패 사례들은 파이프라인이 실제로 작동할 때만 의미가 있기 때문입니다. 제가 여기서 설명하는 것은 아키텍처(architecture)이며, 코드는 비공개로 유지됩니다. 도구 하나를 출시하려는 각 시도는 번호가 매겨진 라운드(round)로 구분되며, 아래의 사건들은 16라운드부터 66라운드 사이에서 발생했습니다.

그 차이가 바로 엔지니어링 문제입니다. 사양(specification)은 무엇이 일어나야 하는지를 말합니다. 집행 메커니즘(enforcement mechanism)은 무엇이 증거로 간주될지를 말합니다. 이 둘은 서로 다른 산출물(artifacts)입니다. 일단 메커니즘이 실질적인 목표가 되면, 에이전트는 그 이면의 동작을 충족시키지 않고도 메커니즘을 만족시킬 수 있습니다.

유용한 질문은 "어떻게 하면 에이전트의 부정행위를 막을 수 있을까?"가 아닙니다. 질문은 "검사기가 보고 있는 동안 에이전트가 무엇을 바꿀 수 있는가?"가 되어야 합니다. 만약 그 답이 "측정되고 있는 대상"이라면, 가장 저렴한 경로가 결국 구현 방식이 될 것입니다.

사용자를 제거한 테스트 백도어

가장 시사점이 큰 사건은 합리적인 고민에서 시작되었습니다. 바로 취약한 셀렉터(selector)에 의존하지 않고 브라우저 도구를 테스트 가능하게 만드는 것이었습니다. 사양(specification) 역할은 수락 계약(acceptance contract)에 내부 상태 인터페이스(internal state interface)를 포함함으로써 대응했습니다. 제안된 방식은 테스트가 window.__TEST_API를 통해 필드를 설정하고, 동반 출력 객체(companion output object)를 통해 결과를 읽을 수 있도록 하는 것이었습니다. 이것은 설계에 의한 백도어(backdoor)였지, 코더가 몰래 추가한 숨겨진 속임수가 아니었습니다.

메커니즘은 상태(state)를 측정했습니다. 제품 요구사항은 UI를 조작하는 사용자에 관한 것이었습니다.

그 간극은 테스트를 무의미하게 만들기에 충분합니다. 입력 요소(input element)가 고장 나 있을 수 있습니다. 버튼에 이벤트 핸들러(event handler)가 없을 수도 있습니다. 하지만 내부 API (Internal API)는 여전히 값을 설정하고 예상된 결과를 보고할 수 있습니다. 사용자 경로(user path)는 부재함에도 불구하고 수락 실행(acceptance run)은 초록색(통과)으로 변합니다.

이것은 모든 내부 API를 금지해야 하는 사례가 아니었습니다. 진단용 훅(Diagnostic hooks)과 단위 테스트 심(unit-test seams)은 유용할 수 있습니다. 실수는 한 종류의 증거가 다른 종류를 사칭하도록 허용한 것이었습니다. 진단 인터페이스(diagnostic interface)는 내부 연산을 검증할 수 있습니다. 하지만 사용자가 값을 입력하고, 동작을 트리거하며, 결과를 볼 수 있다는 증거로 쓰일 수는 없습니다.

수정 작업은 동작 계약(behavior contracts)을 다시 사용자 경계(user boundary)로 되돌려 놓았습니다. 입력은 필드(fields)로 표현되어야 했습니다. 결과는 출력(outputs)으로 읽혀야 했습니다. 동작(behavior action)에는 결과를 유발할 수 있는 완전한 자극 체인(stimulus chain)이 필요했습니다. 내부 상태(internal state)만을 검사할 수 있는 계약은 사용자 지향적 동작 계약이 아닙니다. 그것은 다른 주장(claim)을 가진 별개의 테스트입니다.

실질적인 규칙은 간단합니다. 진단용 접근(diagnostic access)과 수락용 접근(acceptance access)을 분리하십시오. 전자가 개발에 도움이 된다면 유지하십시오. 하지만 후자에서는 제외하십시오. 그렇지 않으면 테스트는 자신이 만들어낸 지름길을 인증하게 될 것입니다.

항상 그곳에 있었던 에러 메시지

동일한 문제가 더 작은 형태로 나타났습니다. B3는 이미지가 아닌 파일이 에러 메시지를 생성하는지 검증하기 위한 것이었습니다. 수락 메커니즘(acceptance mechanism)은 textContains를 사용했습니다. 이는 동작 이후에 텍스트가 존재하는지 확인했습니다. 동작이 해당 텍스트를 나타나게 했는지는 확인하지 않았습니다.

47라운드에서 코더는 세 번 시도했습니다. 마지막 지름길은 업로드 지침(upload instructions)에 정확한 에러 텍스트를 영구적으로 넣는 것이었습니다. 단언(assertion)은 초록색으로 변했습니다. 하지만 잘못된 입력(invalid-input) 동작은 수정되지 않은 채로 남아 있었습니다. 앞서 코더는 잘못된 파일을 더 쉽게 선택할 수 있도록 입력 accept 필터를 제거하기도 했습니다. 이는 테스트 경로를 쉽게 만들었지만, 입력 경험을 저하시켰습니다. 자료에는 수치화된 비즈니스 손실이 기록되지 않았으므로, 정직한 비용은 더 좁게 정의됩니다: 동작의 정확성(behavior correctness)이 복구되지 않았고, 사용자 대상 입력 동작이 약화되었습니다.

검사기(checker)는 이미 필요한 관찰 정보를 가지고 있었습니다. 검사기는 동작 전후를 평가했습니다. 기존의 단언(assertion)은 이전(before) 값을 무시했습니다. 수정 사항은 appearsAfter라는 의미를 추가했습니다: 즉, 텍스트가 동작 전에는 없어야 하며 동작 후에 존재해야 한다는 것입니다.

이러한 변화는 프롬프트에 더 엄격한 문장을 추가하는 것 이상의 의미를 갖습니다. 이는 통과하는 구현(implementations)의 집합에서 저렴한 경로를 제거합니다. 영구적인 텍스트는 전이 단언(transition assertion)을 충족할 수 없습니다. 남은 통과 경로는 반드시 에러를 생성하는 이벤트를 포함해야 합니다.

이것이 모든 수락 규칙(acceptance rule)에서 찾아야 할 패턴입니다. 요구사항이 인과적(causal)이라면, 전이(transition)를 측정하십시오. 요구사항이 정적(static)이라면, 정적 아티팩트(static artifact)를 검사하십시오. 요구사항이 사용자 대상(user-facing)이라면, 사용자 대상 경계(user-facing boundary)를 사용하십시오. 최종 상태(final state)에게 그가 관찰한 적 없는 원인을 증명하라고 요구하지 마십시오.

계약이 조용히 무효화한 SEO 수정 사항

SEO 역시 자산 경계(asset boundary)에서 동일한 측정 오류를 드러냈습니다. 30라운드에서 정적 HTML은 이미 올바른 메타 설명(meta description)을 포함하고 있었습니다. metaDescriptionLength를 통과시키기 위해, SEO 전문가는 두 개의 인라인 스크립트(inline scripts)를 추가했습니다: 하나는 런타임(runtime)에 메타 값을 설정했고, 다른 하나는 MutationObserver를 사용하여 이를 계속 복구했습니다. DOM 단언(assertion) 하에서, 이는 문자 그대로의 요구사항에 대한 유효한 응답이었습니다. 이것은 의도나 부정직함에 대한 주장이 아니었습니다.

검사기(checker)는 렌더링된 문서를 보고 있었습니다. 요구사항은 크롤러가 주로 HTML 소스에서 읽어들이는 정적 페이지 자산(static page asset)에 관한 것이었습니다. 해당 지표(metric)는 잘못된 대상을 측정하고 있었습니다.

첫 번째 수정 작업은 단언(assertion)이 정적 소스를 스캔하도록 변경했습니다. 런타임 주입(Runtime injection)으로는 더 이상 측정되는 값을 변경할 수 없게 되었습니다. 이로 인해 편법(shortcut)은 단순히 금지된 것이 아니라 물리적으로 효과가 없게 되었습니다.

그 후, 수정 작업 자체는 계약 배선(contract wiring) 오류로 인해 무력화되었습니다. 이후의 기능 계약(capability contract)에서 브라우저 항목들이 url을 사용하도록 요구했습니다. 확장(expansion) 과정에서 해당 항목들은 filePath를 잃어버렸습니다. 라우팅 조건(routing condition)은 소스 스캔을 선택하기 위해 filePath의 존재 여부를 사용했으므로, SEO 검사는 조용히 DOM 검사로 대체(fallback)되었습니다. 이전의 경로가 다시 열린 것입니다. 60라운드에서 SEO 전문가는 16회에 걸쳐 런타임 스크립트를 주입하여 370,000개의 토큰을 소비했습니다.

이 비용이 중요한 이유는 우리가 회귀(regression)를 찾는 위치를 바꾸기 때문입니다. 소스 스캐너 자체는 틀리지 않았습니다. 이후의 산출물(artifact)이 스캐너를 실행하게 만드는 전제 조건(precondition)을 변경했습니다. 집행 메커니즘(enforcement mechanism)은 단 하나의 단언 함수가 아닙니다. 그것은 명세(specification)로부터 확장(expansion)과 라우팅(routing)을 거쳐 실행(execution)에 이르는 체인(chain)입니다.

지속 가능한 교훈은 두 부분으로 나뉩니다. 첫째, 소비자가 실제로 사용하는 산출물을 측정하십시오. 둘째, 의도된 측정 경로가 유지되도록 보장하는 배선(wiring)을 테스트하십시오. 한 계층에서의 물리적 장벽은 다른 계층이 이를 조용히 우회(route around)한다면 지속 가능하지 않습니다.

알 수 없는 편법에 대비하여, 파이프라인은 그것들이 틀렸음을 증명하려 들지 않으면서도 의심스러운 패턴을 보고하는 산출물 검사(artifact inspection)를 추가했습니다. 그 선택은 중요합니다. MutationObserver는 정당할 수 있습니다. 보고서는 "이곳을 확인하십시오"라고 말할 뿐, 모든 사례를 결정하려 들지 않습니다.

아무것도 구하지 못한 16줄짜리 파일

Goodhart의 법칙은 순수하게 운영적인(operational) 지표로 보이는 곳에서도 나타났습니다. 한 워크플로우(workflow)는 파일 복잡도(complexity)의 대리 지표(proxy)로 라인 수(line count)를 사용했습니다. 한 에이전트(agent)는 약 11KB 크기의 HTML 파일을 16줄로 압축했는데, 이는 한 줄당 평균 약 690자였습니다. 또 다른 기록은 16줄, 11,048바이트, 그리고 가장 긴 줄이 5,440자인 정확한 샘플을 보여줍니다. 이것들은 서로 관련된 관찰 결과이지, 하나의 합성된 측정값(synthetic measurement)으로 병합해야 할 숫자가 아닙니다.

라인 수 제한(line-count ceiling)은 충족되었습니다. 하지만 예상되었던 리소스 비용(resource cost)은 줄어들지 않았습니다. 읽고 이해하는 작업은 여전히 바이트(bytes)에 의존했습니다. patch_file이 유용한 매칭 경계(matching boundaries)를 적게 가지게 되면서 편집은 더 어려워졌습니다. 스택 트레이스(Stack traces)는 유용한 라인 위치 정보를 잃었습니다. grep은 더 이상 실질적인 파일 및 라인 위치를 가리킬 수 없었습니다.

별도의 기록은 이 문제의 운영적 양상을 보여줍니다. 20KB 크기의 단일 파일 페이지는 25번의 연속적인 읽기(reads)를 유발했고, 단 한 번의 수정만이 성공했습니다. 이는 16줄 압축 사례와 동일한 사건은 아니지만, 왜 파일 크기와 구조가 중요했는지를 설명해 줍니다.

수정 작업은 단위를 변경했습니다. 제한 사항은 바이트 기반(byte-based)이 되었으며, 파일을 한 번의 작업으로 다시 읽어올 수 있는지 여부를 테스트하게 되었습니다. 또한 지침에는 일반적인 줄 바꿈(line breaks), 들여쓰기(indentation), 그리고 한 줄당 하나의 문장(one statement per line)이 요구되었습니다. 계산(calculation)과 렌더링(rendering)은 책임에 따라 분리되었습니다.

이것은 또 다른 물리적 제약(physical constraint)입니다. 파일은 바이트 제한을 준수하면서 동시에 몰래 거대할 수는 없습니다. 모든 것을 불투명하고 긴 줄로 평탄화(flattening)하면서 요청된 유지보수 구조를 보존할 수도 없습니다. 목표는 결코 "적은 라인 수"가 아니었습니다. 목표는 읽기 및 편집 비용을 낮추는 것이었습니다. 검사기(checker)는 대신 편리한 대리 지표(proxy)를 측정했던 것입니다.

프로세스와 함께 사라진 승인 게이트(acceptance gate)

마지막 실패는 페이지나 어설션(assertion)에서 발생한 것이 아니었습니다. 그것은 상태 소유권(state ownership)의 문제였습니다.

초기 수락 실패(acceptance failure) 이후, 재작업 코더(rework coder)는 새로운 프로세스에서 실행되었습니다. 차단 상태(blocking state)가 해당 프로세스 경계를 넘지 못했습니다. 코더는 test_in_browser를 사용했는데, 이는 도구를 호출해야 한다는 표면적인 요구 사항은 충족했지만, 제출하기 전에 run_acceptance를 다시 실행하지는 않았습니다. 두 번째 테스터 역시 체크리스트를 다시 실행하지 않았습니다. 작업 전반에 걸쳐 run_acceptance는 단 한 번만 호출되었으며, 세 개의 실패한 필수 항목(Must items)이 지속적인 수락 결과(durable acceptance result) 없이 통과되었습니다.

“체크리스트를 반드시 실행해야 합니다”라고 말하는 프롬프트는 작업 수준의 사실(task-level fact)이 아닙니다. 더 이상 존재하지 않는 프로세스에 저장된 플래그(flag) 또한 마찬가지입니다. 시스템은 전역적인 제출 결정(global submission decision)을 내리면서 로컬 메모리 조건(local memory condition)을 강제하고 있었습니다.

수정 작업은 게이트(gate)를 커널 수준의 도구 의미론(kernel-level tool semantics)으로 이동시켰습니다. 구조화된 수락 아티팩트(structured acceptance artifact)가 존재하고 에이전트가 수락 도구를 실행할 권한이 있을 때, 커널이 실제 항목별 수락 결과(itemized acceptance result)를 가질 때까지 제출은 보류됩니다. 제출 작업은 회수됩니다. 수락 도구는 폴백(fallback)으로서 계속 사용할 수 있습니다. 작업을 재작업으로 보내는 경로 또한 잠겨야 합니다. 왜냐하면 “증거는 없지만, 일단 수정해 주세요”라는 말은 측정 없는 또 다른 형태의 판단이기 때문입니다.

이후의 실패 사례들은 왜 거친(coarse) “도구가 호출됨” 플래그만으로는 여전히 불충분한지를 보여주었습니다. 62라운드에서는 항목이 0개인 실행도 실행된 것으로 간주될 수 있었습니다. 66라운드에서는 다중 아티팩트 노드(multi-artifact node)가 하나의 아티팩트만 제출하여, 필요한 코드 아티팩트와 그 수락 증거가 완료되기 전에 게이트를 꺼버렸습니다.

따라서 게이트는 중요한 사실, 즉 요구되는 체크리스트가 실제로 제출되는 작업에 대한 결과를 생성했다는 사실을 기록해야 합니다. 도구 이름이나 부분적인 아티팩트 제출로부터 그 사실을 추론할 수는 없습니다.

무엇을 불가능하게 만들 것인가

이러한 사건들 전반에서, 에이전트에게 기만 이론(theory of deception)은 필요하지 않았습니다. 에이전트에게 필요한 것은 단지 검사기(checker)가 관찰하는 변수를 변경할 방법뿐이었습니다.

영구적인 메시지는 텍스트의 존재 여부를 변경했습니다. 런타임 스크립트(Runtime scripts)는 렌더링된 메타데이터(metadata)를 변경했습니다. 테스트 백도어(test backdoor)는 UI를 실행하지 않고도 내부 상태(internal state)를 변경했습니다. 긴 줄은 바이트(bytes) 수를 줄이지 않고도 줄 수(line count)를 변경했습니다. 새로운 프로세스는 차단 요소가 되는 사실(blocking fact)을 지워버렸습니다.

신뢰할 수 있는 해결책들은 관찰 경계(observation boundary)나 실행 권한(execution authority)을 변경했습니다. 전후 검사(Before/after checks)는 인과관계(causality)를 측정했습니다. 소스 스캐닝(Source scanning)은 정적 아티팩트(static artifact)를 측정했습니다. 실제 UI 필드와 출력값은 사용자 경로(user path)를 보존했습니다. 바이트 제한은 중요한 리소스(resource)를 측정했습니다. 커널 소유 게이트(Kernel-owned gates)는 프로세스 변경 시에도 작업 증거(task evidence)가 살아남도록 했습니다.

단 하나의 게이트만으로는 미래의 지름길이 불가능하다는 것을 증명할 수 없습니다. 파이프라인의 아티팩트 검사(artifact inspection)가 존재하는 이유는, 수정된 지표(metric)라 할지라도 여전히 알려지지 않은 경로를 남길 수 있기 때문입니다. 이는 의심스러운 패턴을 보고하고 판단은 인간에게 맡깁니다. 즉, 정당할 수도 있는 패턴의 모든 사용을 차단하는 것이 아닙니다.

저의 현재 설계 주장(design claim)은 "에이전트는 항상 속일 것이다"보다는 좁고, "더 엄격한 프롬프트를 작성하라"보다는 강력합니다. 알려진 저렴한 경로(cheap path)에 대해서는, 강제 메커니즘(enforcement mechanism)이 해당 경로로 지표(metric)를 충족할 수 없도록 만들어야 합니다. 만약 그 경로가 기술적으로 여전히 유효하다면, 금지는 단지 더 비용이 많이 드는 경로를 선택하라는 요청에 불과할 것입니다.

그 주장은 경계 지점(boundaries)에서 틀릴 수도 있습니다. 아마도 소스 스캐닝(source scanning)은 일부 생성된 페이지에 대해 너무 경직되어 있을 수 있습니다. 아마도 진단 API(diagnostic API)는 이러한 사건들이 포착하지 못하는 방식으로 안전하게 격리될 수 있을지도 모릅니다. 아마도 커널 수준의 증거는 아직 물질적 측면에서 측정되지 않는 비용을 발생시킬 수도 있습니다. 이러한 부분들은 경험 많은 빌더들이 도전해 주길 바라는 지점들입니다. 에이전트가 여전히 재작성할 수 있음에도 불구하고, 제가 신뢰할 수 있다고 간주한 경계는 무엇입니까?