200 OK가 결과가 아니다: AI 에이전트 워크플로우에서 놓치기 쉬운 점검 사항

에이전트가 올바른 도구를 호출합니다. API는 200 OK를 반환합니다. 추적(trace)은 녹색입니다. 에이전트는 작업 완료를 보고합니다.

이제 이 작업이 변경되어야 했던 장소를 검사해 보세요.

대상(target)이 잘못되었을 수 있습니다. 또는 결과가 불완전할 수 있습니다. 또는 증거가 더 이전 상태에 속할 수 있습니다. 또는 작업을 시작한 권한 주체가 변경되었을 수 있습니다.

성공 응답 그 어떤 것도 거짓일 필요는 없습니다. 실수는 그 응답을 더 강력한 주장, 즉 **권한 부여된 결과(authorised outcome)가 검증되었다(VERIFIED)**로 승격시키는 것입니다.

저는 복잡한 전문 소프트웨어 내부에서 AI가 실제로 '작업'을 수행하도록 만드는 고급 Director Bridge 및 AI Production Suite를 구축하는 과정에서 이 문제에 직면했습니다. 저는 챗봇에게 답변을 요청하고 있던 것이 아니었습니다. 채팅 창 너머의 무언가를 변경하는 작업을 시스템에 수행하도록 요청하고 있었습니다.

제 배경은 기계식 및 컴퓨터 제어 장비를 진단하는 분야입니다. 그 세계에서는 액추에이터(actuator)에 대한 명령, 켜진 표시등, 그리고 액추에이터의 실제 위치가 서로 다른 사실입니다. 실제 부하 조건에서 기계를 점검합니다. 이 습관은 소프트웨어로 이어졌습니다.

결국 UAEP — Universal Agent Execution Platform이 되었습니다. 이 플랫폼은 모델(model), 도구(tool), 워크플로우 엔진(workflow engine) 또는 외부 권한 시스템을 대체하는 것이 아니라, 이기종 시스템 전반에 걸친 실행 보증(execution assurance)을 목표로 합니다.

개발자들이 종종 하나로 간주하는 네 가지 사항

에이전트가 “완료”라고 말할 때, 실제로 어떤 사실이 확립되었는지 물어보세요:

1. 요청이 수락되었다. 서비스가 입력을 승인했습니다.
2. 작업이 실행되었다. 도구 또는 워크플로우가 실행 결과를 생성했습니다.
3. 대상(destination)이 변경되었다. 필요한 외부 상태가 의도된 대상에서 실제로 존재합니다.
4. 그 결과가 현재 정당화된다. 관찰된 내용이 권한 부여된 목표에 적용 가능하며, 조용히 오래되거나 관련성이 없어지지 않았습니다.

자체 시스템에서 간단한 검토 연습을 해보세요. 에이전트가 평소의 도구 경로를 완료하도록 하되, 의도된 목적지를 독립적인 관찰에 사용할 수 없게 만드세요. 이때 시스템이 여전히 “검증됨(verified)”이라고 말할까요? 그렇다면 그 상태는 증거가 뒷받침하는 것보다 더 많은 것을 주장하고 있는 것입니다.

다음으로 다른 경우를 시도해 보세요. 이전 행동이 실제로 성공했지만, 목표나 권한의 근거가 변경되었을 때, 캐시된 영수증이 나중 행동에 대한 지속적인 허가로 취급되는지 확인하세요. 역사적 증거는 다음에서 무슨 일이 일어날지 승인하지 않은 채 진실할 수 있습니다.

이것들은 HTTP 클라이언트가 작동하는지에 관한 질문이 아니라, 성공의 _의미_에 관한 질문입니다.

정직한 경계가 말해야 하는 것들

중요한 행동의 경우, “최근에 확인했다”는 것이 “효과가 확정되었을 때 이것이 승인되었다”와 반드시 같지는 않습니다. 만약 그 순간들 사이에 권한이 변경될 수 있다면, 외부 실행 경로는 관련 경계에서 강제 가능한 조건(enforceable condition)을 필요로 합니다. 보증 시스템은 나중에 그 효과를 잘못 분류했다는 이유만으로 방심한 외부 효과를 막았다고 진실하게 주장할 수 없습니다.

이러한 구분은 UAEP 자체 테스트에서도 중요했습니다. 외부 개발자들이 위조 사례(falsification cases)를 제기했기 때문입니다. 첫 번째 사례는 외부 보증 경계에서 실제 취약점을 노출시켰습니다. 나중에 더 광범위한 캠페인에서는 외부 강제 실패를 발견했습니다. 저는 예상되는 답변을 변경하는 대신, 이러한 결과를 보존하고 영향을 받은 경계를 수정하여 적대적 사례들을 재실행했습니다.

최종 **경계가 설정되고 자체 실행된 합성 후속 캠페인(bounded, self-run synthetic successor campaign)**은 테스트된 엄격한 경로에서 29/29 사례를 기록했으며, 프로토콜 오류는 0개, 잘못된 VERIFIED 결론은 0개, 그리고 잘못 승인된 중요한 효과는 0개였습니다. 총 열일곱 개의 합법적인 승인된 효과가 확정되었습니다. 이것은 독립적인 감사(independent audit), 보편적 보증(universal guarantee) 또는 프로덕션 보안 인증이 아닌 내부 측정 결과입니다.

유용한 원칙은 숫자로 표현하는 것보다 더 간단합니다:

계획의 확장이 권위의 확장이 되어서는 안 된다. 실행 성공이 가정에 의해 검증된 목적지 현실이 되어서는 안 된다.

팀에 다시 가져가야 할 질문

에이전트가 작업을 완료할 때마다 "도구가 성공을 반환했는가?"에서 멈추지 마십시오. 다음을 물어보십시오:

어떤 외부 상태가 승인되었는가? 현재 어떤 상태가 존재하는가? 그 사실을 확립하는 관찰은 무엇인가? 그 관찰이 이 실행과 현재의 목표에 적용되는가?

목적지를 확립할 수 없다면, UNKNOWN이 유용한 답변입니다. 자신감 있는 완료 메시지로부터 VERIFIED를 만들어내는 것보다 훨씬 안전합니다.

저는 독립적인 호주 발명가인 Adam Mangan입니다. UAEP는 그 질문에서 성장한 실행 보증(execution-assurance) 플랫폼입니다. 제가 상업적 옵션을 탐색하는 동안 이 플랫폼의 구현은 기밀로 유지되고 있습니다. 호주 임시 특허 출원이 2026년 9월 16일에 제기되었으며, 출원 번호는 2026907889입니다.

저의 전체 발명가 이야기 읽기 및 공개 UAEP 사이트 탐색하기. 만약 주장된 VERIFIED 결과에 대한 유한하고 재현 가능한 반례를 가지고 있다면, 저에게 알려주십시오.