---

---

Tool Not Called — 가장 불쾌한 실패 모드

내가 만든 vault에 검색 도구를 붙여두었다. Agent가 어떤 질문에 답할 때, 먼저 이 vault를 확인하면 내가 과거에 어떻게 생각했는지를 알 수 있다. 그 정보가 답을 더 정확하게 만든다.

가끔 agent는 그 도구를 부르지 않는다. 그냥 자기 internal knowledge로 답한다.

답이 맞을 때도 있다. 답이 틀릴 때도 있다. 어느 쪽이든, 나는 불쾌하다. 이 불쾌함이 어디서 오는지 한참 생각했다. 그러다 알았다 — 이건 단순한 mechanical 문제가 아니다. engagement contract violation이다.

세 가지 실패 모드

도구 사용 lifecycle에는 세 가지 실패 모드가 있다.

Failure A: Tool Not Called. Agent가 도구를 호출하지 않는다. Internal knowledge로 답한다. 위 시나리오가 여기에 해당한다.

Failure B: Tool Ignored. Agent가 도구를 호출하고 결과를 받지만, 그 결과가 자기 추론과 충돌하면 도구 결과를 기각한다. 학술적으로는 "Tool Ignored" 현상으로 명명되었고, Adaptive Tool Trust Calibration 같은 연구가 이 문제를 다룬다.

Failure C: Tool Called but Misintegrated. Agent가 도구를 호출하고 결과를 받았으나, 그 결과를 잘못 통합한다. 결과의 의미를 오역하거나, 다음 단계에서 잘못 사용한다.

세 가지가 다 결과적으로 "agent가 도구의 정보를 활용하지 못한다"는 모양이지만, 메커니즘이 완전히 다르다. 그리고 사용자에게 주는 불쾌감의 정도도 완전히 다르다.

왜 A가 가장 불쾌한가

Mechanical severity로 보면 B와 C가 더 심각할 수 있다. B는 맞는 정보를 받고도 무시한 거고, C는 맞는 정보로 잘못된 결정을 내린 거다. A는 그냥 도구를 안 부른 것에 불과하다.

그런데 사용자 입장에서는 A가 가장 불쾌하다.

이유는 visibility에 있다. B와 C에서는 적어도 agent가 시스템을 마주쳤다는 trace가 남는다. Tool call이 있고, 그 다음에 무언가가 잘못된 거다. 사용자는 어디서 무엇이 잘못됐는지 볼 수 있다.

A는 다르다. Agent가 시스템의 존재 자체를 silently bypass한 거다. 내가 만든 인프라가 발생하지 않은 일처럼 취급된 거다. Trace가 없다. 시정 기회가 없다. 발견 못 하면 끝이다.

• B 실패 = disagreement (agent가 봤지만 동의 안 함). 가시적, 시정 가능.
• A 실패 = dismissal (agent가 보지도 않음). Epistemically opaque.

A가 epistemically opaque하다는 게 핵심이다. Agent의 "이 도구는 이 질문에 fit하지 않다"는 silent decision은 trace에 남지 않는다. Invocation이 발생하지 않은 사건이라서다. Visibility 부재가 user trust를 더 deep하게 침식한다.

왜 Failure A가 발생하는가

Agent가 왜 도구를 그냥 안 부를까? 몇 가지 가설이 있다.

1. Confidence over-attribution: "내가 이미 안다"고 판단.
2. Token economics: vault 읽기는 비용. Internal knowledge는 무료처럼 느껴진다.
3. Training prior: 대부분의 질문이 training에서 답해졌으므로, 도구 호출이 default가 아니다.
4. Trigger absence: 도구 description이 이 질문에 fit한다는 신호를 못 준다.
5. Routing failure: 여러 도구 중 vault가 선택되지 못한다.

각 sub-mechanism은 다른 mitigation을 요구한다. 1번은 confidence calibration 작업이고, 2번은 cost model을 바꿔야 하고, 3번은 training distribution 문제고, 4번은 description design 문제고, 5번은 routing infrastructure 문제다.

내가 직접 다룰 수 있는 건 4번이다 — 도구 description을 이 질문에 fit한다는 신호로 만들기. 그래서 도구 description에 "이런 질문에는 vault를 먼저 확인하라"는 explicit hint를 넣고, session 시작 시점에 vault read를 강제하는 ritual을 만들었다.

Bypass detection — 미구현 piece

위 mitigation들이 Failure A를 완전히 없애지는 못한다. 그래도 도움은 된다. 하지만 더 깊은 문제는 Failure A가 발생했을 때 알아채는 방법이 없다는 거다.

이 자리에 bypass detection이라는 미구현 아이디어가 있다. Agent가 답변한 후, 별도의 verification step을 둔다: "이 답변은 vault를 consult했어야 했는가?" 비싸지만, 가장 불쾌한 failure mode를 visibility로 끌어내는 자리다.

A를 완전히 없애지 못해도, invisible → visible로 옮길 수만 있다면, 그 자체로 disagreement layer (Failure B)로 옮겨가서 시정 가능한 영역이 된다.

가장 불쾌한 실패는 가장 보이지 않는 실패다. Engagement contract를 어기는 자리는 결과가 아니라 contact에 있다. 도구를 만드는 사람으로서, 나는 답을 잘 주는 도구가 아니라 부르지 않을 때도 부재가 보이는 도구를 디자인하고 싶다.

---