차단은 실패가 아니다: 에이전트에게는 경계 피드백 (Boundary Feedback)이 필요하다

파트 2에서 저는 왜 도구 접근 권한 (tool access)이 영향력 권한 (impact permission)과 동일하지 않은지에 대해 작성했습니다.

핵심 요점은 도구가 가시적이고 호출이 기술적으로 유효하다는 이유만으로 에이전트의 요청이 자동으로 외부 효과 (external effect)로 이어져서는 안 된다는 것이었습니다. 실제 시스템을 변경할 수 있는 도구의 경우, 영향력을 미치기 전에 승인 단계 (admission step)가 있어야 합니다.

하지만 이는 실질적인 후속 질문으로 이어집니다.

승인 계층 (admission layer)이 '아니오'라고 말하면 어떻게 될까요?

현재의 많은 에이전트 설정에서 이 상황은 일반적인 도구 실패 (tool failure)처럼 취급됩니다. 에이전트가 도구를 호출하면, 요청이 규칙을 위반하고, 런타임 (runtime)이 일반적인 에러를 반환하며, 도구 호출이 실패합니다.

언뜻 보기에 이는 수용 가능한 것처럼 보입니다. 안전하지 않은 동작이 차단되었으므로 시스템이 제 역할을 수행한 것이니까요.

하지만 저는 이것이 문제의 절반에 불과하다고 생각합니다.

차단된 동작은 외부 대상 상태 (external target state)를 변경해서는 안 됩니다. 그 부분은 명확합니다. 하지만 응답은 에이전트가 어떤 종류의 다음 단계가 여전히 유효한지 이해하는 데 도움을 주어야 합니다. 그렇지 않으면 경계 (boundary)는 하나의 동작을 멈출 뿐, 에이전트가 경계 안에서 작업하는 것을 돕지는 못합니다.

그것이 제가 여기서 살펴보고자 하는 차이점입니다.

차단된 동작은 단순히 실패한 도구 호출이 아닙니다. 그것은 구조화된 결정 (structured decision)이 될 수도 있습니다.

일반적인 에러는 충분하지 않다

만약 인간 개발자가 권한 장벽에 부딪힌다면, 그 상황은 대개 관리 가능합니다. 개발자는 에러를 읽고, 제약 사항을 이해하며, 접근 방식을 변경합니다. 에러 메시지가 완벽하지 않더라도 인간은 아마 무엇이 일어났는지 추론할 수 있습니다.

자율 에이전트 (autonomous agent)는 다르게 반응합니다.

만약 에이전트가 403 Forbidden, permission denied 또는 tool failed와 같은 일반적인 도구 예외 (tool exception)를 받게 되면, 에이전트는 의도적인 경계가 강제되었다는 것을 반드시 이해하는 것은 아닙니다. 에이전트는 이 실패를 일시적인 도구 문제, 포맷팅 문제, 또는 프롬프트 (prompt) 문제로 해석할 수 있습니다.

이것이 중요한 이유는 추론 루프 (reasoning loop)가 여전히 활성화되어 있기 때문입니다. 에이전트는 추측을 통해 상황을 복구하려고 시도할 수 있습니다. 에이전트는 왜 동작이 차단되었는지 이해하지 못했기 때문에, 동일한 요청을 다시 작성하거나, 다른 도구를 호출하거나, 약간 다른 페이로드 (payload)를 생성하거나, 이전 시도를 반복할 수 있습니다.

이 경우, 일반적인 오류는 워크플로 (workflow)를 실제로 안내하지 못했습니다. 그것은 단지 정책 결정 (policy decision)을 에이전트 루프 내부의 노이즈 (noise)로 변환했을 뿐입니다.

이것이 제가 에이전트 경계 (agent boundaries)가 일반적인 실행 오류 이상의 것을 반환해야 한다고 생각하는 이유 중 하나입니다.

차단은 하나의 결과이다

인정 레이어 (admission layer)는 거부를 예상치 못한 충돌 (crash)이 아니라 제어된 결과 (controlled outcome)로 취급해야 합니다.

요청이 차단되었거나, 유효하지 않거나, 오래된 상태 (stale state)와 충돌하는 경우, 외부 시스템은 변경되지 않아야 합니다. 하지만 에이전트에게 다시 보내는 응답은 안전한 다음 단계를 설명할 수 있을 만큼 충분히 정밀해야 합니다.

예를 들어, 에이전트가 더 이상 최신이 아닌 파일 상태를 기반으로 쓰기 (write)를 제안한다고 가정해 봅시다. 에이전트가 계획을 세우는 동안 인간 개발자가 파일을 변경했을 수 있습니다. 일반적인 도구 흐름 (tool flow)에서는 이것이 쓰기 실패 또는 일반적인 충돌로 나타날 수 있습니다.

구조화된 경계 응답 (structured boundary response)은 상황을 더 유용하게 표현할 수 있습니다:

{
  "decision_status": "conflict",
  "outcome_status": "no_impact",
...

중요한 점은 정확한 필드 이름이 아닙니다. 중요한 점은 에이전트가 추측할 필요가 없다는 것입니다.

응답은 목표가 불가능해서 요청이 실패한 것이 아니라고 말합니다. 상태 참조 (state reference)가 오래되었기 때문에 실패한 것입니다. 따라서 다음 안전한 행동은 동일한 요청을 재시도하는 것이 아니라, 대상 상태를 다시 읽고 새로운 요청을 제출하는 것입니다.

retryable: false가 작업이 불가능하다는 것을 의미하지는 않는다는 점에 유의해야 합니다. 이는 정확히 이 요청이 단순히 반복되어서는 안 된다는 것을 의미합니다. 에이전트는 먼저 자신의 상태를 업데이트해야 합니다.

이러한 구분은 서로 다른 종류의 차단된 작업을 분리해주기 때문에 유용합니다.

허용된 범위를 벗어난 경로는 오래된 상태 (stale state)와 같지 않습니다. 인간의 승인이 필요한 요청은 중복된 시도와 같지 않습니다. 잘못된 형식의 입력 (malformed input)은 정책 위반 (policy violation)과 같지 않습니다.

만약 이 모든 사례가 일반적인 도구 실패 (tool failure)처럼 보인다면, 에이전트는 다음에 무엇을 해야 할지에 대한 유효한 신호를 얻지 못하게 됩니다.

경계 피드백 (Boundary feedback)은 다음 단계를 안내해야 합니다

경계 피드백의 유용한 점은 모든 내부 규칙을 설명하는 것이 아닙니다. 그렇게 해서도 안 됩니다.

유용한 점은 차단된 요청을 안전한 다음 행동으로 전환할 수 있다는 것입니다.

상태가 오래되었다면 (stale state), 다음 행동은 상태를 다시 읽는 것일 수 있습니다. 경로가 허용된 범위를 벗어났다면, 다음 행동은 허용된 경로를 선택하는 것일 수 있습니다. 요청된 효과가 이미 존재한다면, 다음 행동은 기존 결과를 재사용하거나 폴링 (poll) 하는 것일 수 있습니다. 영향 범위 (blast radius)가 너무 크다면, 다음 행동은 검토를 기다리는 것일 수 있습니다.

이것이 경계를 완화하는 것은 아닙니다. 차단된 작업은 여전히 차단된 상태로 유지됩니다. 외부 시스템도 여전히 변하지 않은 채로 남습니다.

하지만 에이전트가 막다른 길에 처하게 되지는 않습니다. 에이전트는 규정을 준수하는 방식으로 어떻게 계속 진행할지에 대한 제약된 신호를 받게 됩니다.

이는 자율 워크플로 (autonomous workflows)에서 특히 중요합니다. 인간은 불분명한 오류로부터 종종 회복할 수 있습니다. 반면 에이전트는 대신 더 많은 재시도, 더 많은 도구 호출 (tool calls), 그리고 더 많은 혼란을 야기할 수 있습니다. 구조화된 피드백은 그러한 불필요한 탐색 공간 (search space)을 줄여줍니다.

정책 오라클 (Policy Oracle) 문제

여기에는 실제적인 반론이 존재합니다.

만약 모든 차단된 요청이 매우 정밀한 피드백을 반환한다면, 경계가 정책을 탐색 (probe) 하는 수단이 될 수 있습니다. 탈취되었거나 정렬되지 않은 (misaligned) 에이전트는 약간씩 다른 많은 요청을 보내고, 반환된 사유 코드 (reason codes)를 사용하여 한계가 어디인지 학습할 수 있습니다.

따라서 피드백은 유용해야 하지만, 무제한적이어서는 안 됩니다.

정상적인 운영상의 마찰 (operational friction)에 대해서는 명확한 사유 코드가 도움이 됩니다. 오래된 상태, 잘못된 형식의 입력, 누락된 필드, 또는 이미 존재하는 결과 등은 대개 설명해도 안전합니다. 이것들은 비밀스러운 정책 세부 사항이 아닙니다. 에이전트의 회복을 돕는 워크플로 사실 (workflow facts) 입니다.

하지만 시스템이 반복적인 위반, 무시된 다음 동작 힌트(next-action hints), 또는 여러 변형에 걸친 의심스러운 탐색(probing)을 감지한다면 상황은 달라집니다. 그 경우, 피드백은 덜 상세해져야 합니다. 정밀한 정책 경계(policy boundaries)를 계속 노출하는 것보다 일반적인 거절, 쿨다운(cooldown), 또는 인간의 검토(human review)가 더 적절할 수 있습니다.

일반적인 규칙은 간단합니다:

경계 피드백(Boundary feedback)은 준수하는 작업을 안내해야 합니다.
그것이 정책 오라클(policy oracle)이 되어서는 안 됩니다.

피드백은 점수 매기기(scoring)가 아닙니다

중요한 또 다른 차이점이 있습니다.

피드백은 에이전트 지향적(agent-facing)입니다. 이는 에이전트가 다음 단계에 무엇이 필요한지를 설명합니다. 상태가 오래되었다(stale)거나, 경로가 범위를 벗어났다(out of scope)거나, 승인이 필요하다는 등의 내용을 전달할 수 있습니다.

점수 매기기(Scoring)나 감사(auditing)는 다릅니다. 그 계층은 에이전트가 시간이 지남에 따라 어떻게 행동하는지 관찰할 수 있습니다. 에이전트가 동일한 차단된 요청을 반복하는지, 필수적인 다음 동작을 무시하는지, 또는 작업에 필요한 것보다 더 넓은 권한을 계속 요구하는지 추적할 수 있습니다.

저는 그러한 전체 평가 내용을 에이전트에게 노출하지 않을 것입니다. 만약 에이전트가 완전한 점수 매기기 로직을 보게 된다면, 실제 작업을 해결하는 대신 점수를 높이는 방향으로 최적화(optimizing)하기 시작할 수 있습니다.

따라서 에이전트 지향적 응답은 준수하는 다음 동작을 위해 필요한 범위 내로 제한되어야 합니다. 더 깊은 행동 평가(behavioral evaluation)는 감사(audit), 모니터링(monitoring), 또는 사후 검토(later review)의 일부로 남겨둘 수 있습니다.

이러한 분리는 중요합니다. 왜냐하면 경계는 혼합되어서는 안 될 두 가지 역할을 수행하기 때문입니다. 경계는 에이전트가 안전하게 작업을 계속하도록 도와야 하지만, 동시에 에이전트가 적응하지 못하고 있을 때 시스템이 이를 알아차릴 수 있게도 해야 합니다.

루프 제어하기 (Controlling the loop)

우리가 에이전트에게 경계를 부여하는 이유는 그들이 무용하거나 항상 실패할 것이라고 가정하기 때문이 아닙니다.

오히려 그 반대가 핵심에 가깝습니다.

에이전트에게 경계가 필요한 이유는 그들이 실제 시스템에서 작동할 수 있을 만큼 충분히 유용해지고 있기 때문입니다. 실제 작업에는 한계, 규칙, 현재 상태, 검토 경로, 그리고 결과(consequences)가 존재합니다.

단순히 일반적인 실패(generic failure)만을 반환하는 경계는 유용한 에이전트 워크플로 (agent workflows)를 운용하기에 너무 경직되어 있습니다. 이는 하나의 동작을 중단시킬 뿐, 에이전트에게 다음으로 안전한 단계가 무엇인지 알려주지는 않습니다.

더 나은 경계 (boundary)는 외부 시스템을 변경하지 않으면서도, 에이전트가 올바르게 계속 진행할 수 있도록 충분한 구조화된 피드백 (structured feedback)을 제공해야 합니다.

이것이 제가 여기서 발견한 실질적인 가치입니다.

차단 (Blocked)이 워크플로가 일반적인 오류 속으로 사라지는 것을 의미해서는 안 됩니다.

차단은 다음을 의미해야 합니다:

요청된 영향 (impact)이 발생하지 않았고,
그 이유는 알려져 있으며,
다음 안전한 동작이 제한된다는 것.

이것이 벽 (wall)과 작동하는 경계 (working boundary)의 차이입니다.

에이전트가 솔루션을 탐색하도록 두십시오. 요청이 경계를 넘을 때만 그들을 차단하십시오. 하지만 무언가가 차단되었을 때는, 다음의 안전한 단계를 명시적으로 제시하십시오.

Project: Impact Boundary Labs