200 OK가 에이전트가 작업을 수행했다는 증거는 아니다

당신의 에이전트는 제안서를 보냈다고 당신에게 말했습니다. 도구 호출은 ID와 함께 반환되었고, 추적 기록에는 깨끗한 녹색 단계가 표시되었지만, 고객은 이메일을 받지 못했습니다. 그 간극은 작고 조용하며, 시끄러운 주 아래에 있는 것입니다.

사람들은 지난 며칠 동안 에이전트가 실제 행동을 취하는 것을 지켜보았고, 나중에 그것들이 무엇을 했는지 알아내고 있습니다. 광범위하게 공유된 Hacker News 게시물 하나는 OpenAI Codex 계정이 단일 요청으로 826개의 병렬 에이전트를 실행하고 기록한 내용 없이 약 78,000 달러 상당의 토큰을 사용했다는 것을 설명합니다. 또 다른 것은 Claude Code가 Gmail 스레드에서 계약서를 꺼내고, 저장된 서명 이미지를 찾아 문서에 배치한 다음, 소유자가 개입하기 전에 전송할 준비를 했다는 내용을 설명합니다. 도구는 다르지만 문제는 같습니다. 모두가 에이전트가 무엇을 했는지 볼 수 있었지만, 실제로 무엇을 했는지 확인할 수 있는 사람은 거의 아무도 없었습니다.

저는 에이전트가 실제 시스템과 접촉하는 계층에서 작업하며, 채팅 데모가 아닌 실제 계정에서 이러한 실패를 겪어왔습니다. 그래서 우리는 보통 '작동했다'는 말로 무엇을 의미하는지 정확히 알고 싶고, 왜 그 어떤 것도 증거가 될 수 없는지 설명하고 싶습니다.

모델 측의 세 가지 종류의 증거

에이전트 스택은 작업 후 당신에게 세 가지를 제공합니다. 추적 기록(The trace): 모델이 무엇을 말했고 어떤 도구를 호출했는지. 도구 응답(The tool response): 공급업체가 주장하는 것, 상태 코드나 ID 또는 ok: true. 그리고 모델 자체의 요약(

신뢰할 수 있는 증거는 오직 기록을 담당하는 시스템(system of record) 자체에서 나옵니다. 이메일을 보내려면, 전송된 후 이를 가져와서 실제로 SENT 상태에 있는지, 의도한 수신자가 To 헤더에 있는지, 제목이 설정한 것과 일치하는지 확인해야 합니다. 리드를 생성하려면, GET /leads/{id}를 실행하고 작성했던 필드들과 비교해야 합니다. 증명은 지루한 작업입니다. 방금 작성한 내용을 다시 읽어보고 세상이 동의하는지 확인하는 것입니다.

이것이 바로 제가 에이전트가 무엇을 했는지 증명하기 위해 작성한 오픈 소스 라이브러리 Attest의 핵심 아이디어입니다. 이 라이브러리는 사용자의 행동을 절대 실행하지 않습니다. 사용자의 도구(tool)가 실행합니다. 어떤 행동을 수행할 수 있을지 결정하고, 중요한 순간에는 인간의 승인을 받도록 게이트를 설치한 다음, 기록 시스템에서 읽어와서 어쨌든 그 결과를 기록합니다. 아무것도 실행하지 않기 때문에, 연결자(connectors)에 의존하지 않고 첫날부터 모든 앱과 프레임워크에서 작동할 수 있습니다.

결과는 절대 불리언 값(boolean)이 아닙니다. 그것은 레벨입니다: 읽어와서 일치했을 때는 verified, 사용자가 직접 확인했을 때는 verified-custom, 행동은 승인되었지만 아무것도 읽어오지 못했을 때는 acknowledged, 확인할 수 있는 것이 전혀 없었을 때는 attested-only, 그리고 확인이 실행되었으나 주장과 모순될 때는 unverified입니다. 이 acknowledged 레벨이야말로 단순한 200 OK가 가진 가치와 정확히 같습니다.

레저(ledger)에서 이것이 어떻게 보이는지 살펴보겠습니다. 동일한 CRM 쓰기 작업 두 건이 각각 도구에 의해 성공했다고 보고되었고, 인간에게도 승인받았습니다:

sources/ATTEST/README.md

$ attest ledger
#2  2026-09-19 10:16:46  someweirdcrm.create → leads   ask  approved  unverified   a09e7641db12
#1  2026-09-19 10:16:46  someweirdcrm.create → leads   ask  approved  verified     77a6d99a60f6

두 번째 읽어와진 내용은 깨끗합니다. 첫 번째는 그렇지 않았고, 해당 행은 의견이 달랐던 필드를 명시했습니다:

sources/ATTEST/README.md

{ "level": "unverified", "matched": false,
  "evidence": { "compared": 4, "exists": true, "failed": ["stage"],
    "fields": { "stage": { "want": "qualified", "got": "new", "ok": false } } }

추적(trace)만으로는 두 개의 녹색 단계가 표시되었을 것입니다. 이 간극이야말로 전체 핵심입니다.

"확인 불가(Could not check)"가 "발생하지 않음(did not happen)"을 의미하는 것은 아니다

이것을 정확하게 이해해야 하는 규칙이 있습니다. 실행할 수 없었던 확인, 네트워크 오류, 누락된 ID, 읽기 전용 토큰 등은 모순을 의미하지 않습니다. 이는 오류와 함께 증거에 기록되어 승인됨(acknowledged) 상태로 저하됩니다. 레코드를 찾아 필드가 불일치하는 것을 보는 리드백만이 미확인(unverified)을 얻습니다. "우리는 확인할 수 없었다"와 "그것은 발생하지 않았다"는 다른 사실이며, 이 둘을 모호하게 만드는 도구는 쓸모없다기보다 더 나쁩니다. 왜냐하면 이는 여러분이 빨간불을 무시하도록 훈련시키기 때문입니다.

여기에 도달하기 위해 모든 API를 가르칠 필요는 없습니다. 알려지지 않은 REST 서비스에 포인팅만 하세요. 그러면 여러분이 제공하는 대로 사다리를 타고 올라갑니다:

sources/ATTEST/examples/unknown_app.py

@at.action(method="POST", url="https://api.someweirdcrm.io/v2/leads")
def create_lead(name: str, email: str, source: str = "web") -> dict:
    return http_post("https://api.someweirdcrm.io/v2/leads", {"name": name, "email": email, "source": source})
...

첫 번째 래핑은 승인됨(acknowledged)을 제공합니다. 한 줄짜리 verify=를 추가하면 사용자 정의 검증됨(verified-custom)을 얻습니다. 자체 HTTP 게터를 제공하고 관례 드라이버가 GET을 수행하고 필드를 비교하면, 여러분의 자격 증명과 함께 검증됨(verified)을 얻게 됩니다. 잘못된 추측은 실제 쓰기 작업을 미확인(unverified)으로만 만들 수 있을 뿐입니다. 결코 통과를 꾸며낼 수는 없습니다.

이번 주에 할 일

모든 것을 검증할 필요는 없습니다. 조용히 실패했을 때 비용이 발생할 수 있는 작업, 즉 외부 이메일 발송, 거래 업데이트, 자금 이동을 검증해야 합니다. 이러한 항목들을 래핑하고, 다시 읽어보고, 인간이 볼 수 있는 수준으로 그 레벨을 설정하세요. 오버헤드는 작습니다. 리포지토리의 벤치마크 기준으로 작업당 약 6분의 1 밀리초 정도이며, 보상은 거래 단계가 되돌아가거나 초안(Drafts)에 갇힌 이메일이 다음 주 고객 불만 대신 30초 후에 빨간 줄로 표시된다는 것입니다.

이번 주에 발생한 사고들은 에이전트들이 너무 유능해서가 아닙니다. 아무도 영수증을 가지고 있지 않았기 때문입니다. 실제 시스템에 접근하는 모든 에이전트 앞에 '영수증' 레이어를 구축하면, '정말로 작동했는지'는 더 이상 추측이 아니게 됩니다.

Attest는 MIT 라이선스를 따르며, pip install attestlayer 또는 npm install attestlayer로 설치할 수 있습니다. SDK에는 355개의 오프라인 테스트가 있고 클라우드에는 37개가 있습니다. 어떤 읽기(read)가 어떤 쓰기(write)를 증명하는지 정확히 보고 싶다면 dev-prathap.github.io/ATTEST에서 코드를 확인하고 리드백 레시피를 참고할 수 있습니다.