나는 내 프로젝트에서 발견된 모든 오류를 번호가 매겨진 레지스터(register)로 기록한다. 각 오류에 대해 나는 한 가지 질문을 던졌다: 무엇이 그것을 잡아냈는가?

제로(Zero). 내가 작성한 11가지 규칙 — 측정 없이 아무것도 단언하지 말 것, 누락된 것을 찾을 것, 절대 캐시(cache)에서 시작하지 말 것 — 중 그 어떤 것도 오류가 발생한 후에 그것을 잡아낸 적이 없다.

그 숫자는 실제다. 하지만 그것은 또한 세 가지 측면에서 오해의 소지가 있으며, 그 이유를 파악하는 과정에서 나는 무언가를 배웠다.

이 레지스터가 무엇을 다루는지에 대해 한 마디 덧붙이자면. 이 레지스터는 약 2주 동안 존재해 왔다. 17개의 항목은 짧은 기간 동안 축적되었으며, 그중 몇 개는 코퍼스(corpus)를 감사하는 동안 발견된 오래된 결함들을 기록한 것이다. 이것은 프로젝트 전체 오류의 총합이 아니다. 프로젝트는 4개월 동안 운영되어 왔다. 이것은 추적된(traced) 오류의 총합이다. 그 차이점은 이 포스트에서 세 번 다시 등장한다.

내가 실행 중인 것

두 명의 큐레이터 에이전트(curator agents)가 예술 작품을 평가하고, 서로 입찰하며, 퍼블릭 체인(public chain)에서 거래를 정산한다. 테스트 네트워크이므로 실제 가치는 없다. 에이전트는 자유롭게 협상한다 — 한 번의 결투에서 오프체인(off-chain)으로 10개의 제안이 교환된다 — 하지만 가치를 이동시키는 단일 단계는 에이전트가 접근할 수 없는 장치에서 발행되는 인간의 서명을 필요로 한다.

그것이 물질적(material) 측면이다. 모두가 패턴을 작성하는 부분이다.

다른 측면은 에이전트가 말하는 것이다. README에 게시된 잘못된 문장은 자금을 집행하지 않고, 지출 한도를 넘지 않으며, 어떤 fail-closed 메커니즘도 이를 막지 못한다. 그 표면은 첫 번째 측면보다 더 넓다 — 공개 문서는 대부분 기술적인 문장들로 이루어져 있으며 — 그리고 거의 아무도 이를 계측(instrument)하지 않는다.

양쪽 모두 동일한 원칙을 따른다: 제약 조건은 에이전트가 도달할 수 없는, 에이전트 외부에서 존재해야 한다.
에이전트를 신뢰할 수 있게 만드는 것이 아니다. 에이전트가 혼자서는 해를 끼칠 수 없도록 만드는 것이다.

왜 "제로"가 명백한 결론을 허용하지 않는가

오류 레지스터(error register)는 오직 사후에 포착된(caught after the fact) 결함만을 기록합니다. 결함이 발생하지 않도록 막는 규칙은 아무런 흔적도 남기지 않습니다. 결코 작성되지 않은 문장에 대해서는 로그 라인이 존재할 수 없습니다.

따라서 정직한 해석은 _자가 점검 규칙(self-check rules)이 쓸모없다_가 아닙니다. 더 좁게 정의하자면, 그 규칙들은 이미 발생한 결함을 잡아내지 못한다는 것입니다. 그 예방적 효과는 이러한 종류의 측정 방식으로는 보이지 않으며 — 저는 이것이 그 어디에서도, 그 어떤 사고 레지스터(incident register)에서도 보이지 않는다고 주장하고 싶습니다.

제가 예상하지 못했던 두 번째 편향(bias)이 있습니다. 저는 두 번의 커밋(commit)을 기준으로 관찰 창(observation window)을 설정했습니다. git이 정확한 타임스탬프를 제공하기에 자연스러운 선택이었습니다. 하지만 해당 기간 중 가장 중요한 예방 사례는 관찰 창의 외부에 위치해 있었습니다. 왜냐하면 그것을 잡아낸 행위가 바로 관찰 창의 시작을 정의하는 커밋을 지연시켰기 때문입니다.

성공적인 예방은 그것을 포함했어야 할 경계선을 이동시켜 버립니다. 발행 이벤트(publication events)를 기준으로 창을 설정하는 모든 방법론은, 가장 효과적이었던 예방 사례들을 체계적으로 검열하게 됩니다.

보이지 않는 절반을 측정하기

한 종류의 예방은 흔적을 남깁니다. 오류가 커밋되기 직전에 에이전트가 멈췄고, 그 멈춤이 기록된 경우입니다. 산업 안전 분야에서는 이를 **아차 사고(near-misses)**라고 부릅니다.

전체 트랜스크립트(transcript)가 포함된 30시간 43분 동안의 연속된 세션 동안 저는 9건을 집계했습니다. 이는 가장 밀도가 높은 구간은 아니었지만, 추적 가능한(traceable) 구간이었습니다.

저는 시작할 때 깔끔한 가설을 가지고 있었습니다. 아티팩트(artefacts)는 잡아내고, 자가 점검(self-checks)은 예방한다. 이 표는 그 가설을 반박합니다. 이 예방 사례 중 3건은 아티팩트(artefacts)로부터 발생했습니다. 두 범주 모두 예방을 수행합니다.

유효한 구분

의구심을 일으키는 것과 의구심을 해결하는 것을 분리하십시오.

9가지 사례 전반에 걸쳐, 정답을 _확립(established)_한 것은 7번의 경우 아티팩트(artefact) 또는 인간이었고, 2번의 경우 주의 깊은 읽기였으며, 단순한 의견만으로 결정된 적은 단 한 번도 없었습니다.
자기 점검 규칙(Self-check rules)은 일관되게 **트리거(triggers)**로서 나타납니다. 즉, 작성을 중단하고 측정을 수행하도록 만듭니다.
이 규칙들은 결정을 내리는 주체로 나타나지 않습니다.

자기 평가 제약 조건(Self-evaluative constraints)은 쓰기 전에 측정을 트리거할 뿐, 결코 무엇인가를 종결짓지 못합니다. 가드(Guards)는 쓰기 후에 종결짓습니다. 판결은 언제나 아티팩트(artefact)가 내립니다. 규칙은 단지 그것을 소환하기로 결정할 뿐입니다.

한 가지 결과, 이는 발견이라기보다는 추측에 가깝습니다: 에이전트가 자신의 출력을 비판하는 성찰(reflection) 패턴은 트리거로 작동할 수는 있지만, 결코 판사(judge)로 작동할 수는 없습니다. 이는 검증(verification)이 아닌 두 번째 의견(second opinion)을 생성할 뿐입니다.

실제로 나의 오류를 반박한 것은 두 번째 사례가 아니라, 첫 번째 사례가 가지지 못한 측정에 접근할 수 있는 도구화된(tooled) 사례였습니다. 이 차이는 에이전트 한 명 대 두 명의 차이가 아닙니다.
그것은 의견(opinion) 대 도구 출력(tool output)의 차이입니다.

에이전트를 구축할 때 고려해야 할 세 가지

패턴 목록을 만들기 전에 위협 모델(threat model)을 작성하십시오. 이미 발표된 분류 체계들은 무엇으로부터 보호하는지를 전혀 언급하지 않은 채 패턴만을 나열합니다.
그 순서대로라면, 어떤 패턴이 필요한지 알 수 없습니다.

에이전트가 무엇을 하는지뿐만 아니라, 에이전트가 무엇을 주장(asserts)하는지에도 도구를 갖추십시오. 내가 읽은 모든 프레임워크는 행동(actions)을 제한합니다.
하지만 주장(assertions)을 제한하는 것은 없었습니다. 이번 달 나의 가장 최악이었던 두 가지 오류는 문장이었습니다. 그것들은 비용이 들지 않았고, 어떤 제한도 넘지 않았으며, 7시간 33분 동안 공개 페이지에 머물렀습니다.

작성하는 모든 규칙을 트리거로 취급하고, 그 판사(judge)를 별도로 구축하십시오. 만약 제약 조건이 에이전트 스스로가 이를 충족했다고 결정함으로써만 만족될 수 있다면, 그 제약 조건은 문제가 실제로 중요해지는 순간 직전까지 유지될 것입니다.
이를 읽을 수 있는 출력물을 생성하는 무언가와 결합하십시오: 카운트(count), 해시(hash), 디프(diff), 또는 종료 코드(exit code)와 같은 것들 말입니다.

비용의 비대칭성(cost asymmetry)은 우리가 왜 그렇게 하지 않는지를 설명해 줍니다. 규칙을 작성하는 데는 몇 분이 걸립니다. 하지만 매칭을 수행할 판정기(judge)를 구축하는 데는 한 시간이 걸립니다.
절약되는 부분은 명확합니다. 판정기가 없는 규칙은 아무것도 잡아내지 못하며, 절약된 시간은 그 대신 내용을 읽어야 하는 인간에게 이자까지 붙어 되돌아옵니다.

마지막 발견, 내가 예상하지 못했던 것

규칙의 코퍼스(corpus)는 텍스트입니다. 따라서 그것은 자신이 방지하기 위해 존재하는 인식론적 손상(epistemic damage)에 노출됩니다.

여기 두 가지 오래된 사례가 있습니다. 한 매체에서 다른 매체로 전달된 규칙이 아무도 작성하지 않은 금지 사항으로 굳어져, 하루 종일 강제 집행된 사례가 있습니다.
그리고 이 포스트의 근거가 된 분석을 작성하는 과정에서, 결과 테이블 자체에 계산 오류(counting error)가 발생했습니다. 이 오류는 카운터(counter)의 사용을 이론화하는 텍스트 내에서 기계적 카운터에 의해 포착되었습니다.

[

두 번째 사례가 더 교훈적입니다. 설명된 패턴이 그것을 설명하는 텍스트 내부에서 재현되었고, 해당 텍스트가 권장하는 메커니즘에 의해 중단되었습니다. 오류 패턴을 형식화(formalising)하는 것이 그 패턴으로부터 보호해 주는 것은 아닙니다. 오직 그것을 계측(instrumenting)하는 것만이 보호해 줍니다.

이 수치들이 의미하지 않는 것

세 번째 편향(bias)은 가장 단순하며, 제가 이를 반복하는 이유는 이것이 다른 모든 것에 영향을 미치기 때문입니다:
레지스터(register)는 젊습니다. 프로젝트가 시작된 지 한참 후에 생성되었습니다. 초기 몇 달 동안 발생한 오류들은 집계되지 않았으며, 그 오류들은 매우 많았습니다. 17이라는 숫자는 프로젝트의 전체 점수가 아니라, 추적된 것들의 점수입니다.

아슬아슬하게 피해 간 사례(near-misses)도 마찬가지입니다: 63번의 세션 중 1번 세션에서 9건이 발생했습니다. 다른 사례들도 동일한 종류의 현상을 만들어냈지만, 저널 기록(journal entries), git 히스토리(git history), 타임스탬프(timestamps)와 같이 파생된 흔적(traces)만이 생존해 있습니다. 저는 전체에 대한 부분적인 수치를 보고하기보다는, 제한된 기간 내의 철저한 샘플을 보고하는 쪽을 택하겠습니다. 이 9건은 관찰된 방지 사례의 총합이 아닙니다. 오직 감사 가능한(auditable) 사례들뿐입니다.

이를 비율(rate)로 읽지 마십시오.

두 명의 에이전트(agents), 한 명의 운영자(operator), 하나의 테스트 네트워크, 그리고 4개월의 시간. 또한 이 기록 자체는 내부적입니다. 공개된 파일들과 온체인 트랜잭션(on-chain transactions)만이 제3자에 의해 검증 가능합니다.

두 문서 모두 공개되어 있습니다:
AGENT-GOVERNANCE.md
— 각각의 오류와 쌍을 이루는 11가지 규칙 — 그리고
PATTERNS-SECURITE-AGENTIQUE.md
물질적 측면을 다룬 문서(프랑스어로 작성됨).

네 번의 확정된 경매 사이클(auction cycles)이 진행되었으며, 모든 트랜잭션은 Base Sepolia에서 목록화되어 검증 가능합니다. 컨트랙트(Contract) 0x471796C1644d87f30AD81D36f6d4A56f0e270c23, 소스 코드 검증 완료.

수작업으로, 단독 진행했습니다. 만약 여러분도 동일한 벽에 부딪혔다면 — 특히 방지 사례를 측정할 방법을 찾았다면 — 꼭 소식을 듣고 싶습니다.

     Avp9.