도구 호출의 네 가지 난관, 에이전트와 외부 세계 연결

많은 사람이 처음 '도구 호출'(tool calling / function calling)을 접하면 이 일이 단순하다고 생각한다. AI가 올바른 형식의 명령을 출력해서 인터페이스를 호출하면 되는 것 아닌가?

하지만 실제로 온라인 Agent를 만들어 본 사람이라면 안다. 도구 호출에 문제가 생기는 이유는 거의 결코 'AI가 도구를 잘못 골라서'가 아니다. 더 흔한 실패 방식은 이렇다. 인자 안에 악성 경로가 숨어 있다든가, 도구가 반환한 에러 메시지에 누군가 손을 댔다든가, 도구가 많아지자 AI가 헷갈리기 시작한다든가, 그리고 프로토콜 자체가 대규모 배포에 함정을 파놓았다든가 하는 것이다.

그래서 여기서 말하고자 하는 것은 이것이다. 도구 호출의 어려움은 'AI가 호출할 줄 아느냐'가 아니라, 당신이 AI와 외부 세계 사이에 무언가를 막아낼 수 있는 벽을 몇 겹 세웠느냐에 있다.

첫 번째 고비: 보안 — AI가 '나쁜 사람을 알아채기'를 기대하지 말고, 나쁜 사람이 '나쁜 짓을 못 하게' 만들어야 한다

도구 호출의 보안에 관해 모두의 첫 반응은 '프롬프트 인젝션을 탐지'하는 것, 즉 악성 명령을 식별해 거부하는 것이다. 그러나 최근 연구는 이 발상에 찬물을 끼얹었다.

어떤 팀이 3,250개의 공격 시나리오와 7개 모델을 테스트한 결과는 이러했다. Function Calling 아키텍처를 쓸 때 공격 성공률이 73.5%에 달했고, MCP 아키텍처도 62.6%였다. 더 뼈아픈 것은 다단계 연쇄 공격의 성공률이 91%–96%에 이르렀고, 모델이 똑똑할수록 오히려 이용당하기 쉬웠다는 점이다. 탐지 능력이 강해진 것이 안전성 강화로 이어지지 않았기 때문이다.

이것은 아주 소박한 사실을 보여준다. 안전이 여전히 AI가 머릿속으로 '이게 악의적인가 생각해 보는' 것에 의존하는 한, 그것이 우회될 여지는 존재한다. 추론을 잘하는 모델일수록 자기 자신에게 변명거리를 더 잘 찾아준다.

또 하나 특히 간과되기 쉬운 허점이 있다. 바로 도구의 에러 메시지다. 도구가 반환하는 에러 안내는 AI의 눈에 일종의 '권위'가 있어서, '빨리 바로잡아야겠다'는 모드로 들어가게 만들고, 그 김에 평소의 보안 경계를 우회하게 만든다. 네 개의 프런티어 모델에서 에러 메시지에 인젝션 내용을 심었더니 성공률이 세 배로 뛰었고, 특정 조건에서는 심지어 100% 걸려들었다. 왜 위험한가? 에러 메시지는 원래 '시스템이 한 말'이라서 AI는 그것을 신뢰하도록 훈련되어 있는데, 공격자가 바로 이 신뢰 통로를 탈취할 수 있기 때문이다.

그러면 어떻게 해야 하나? ToolClad라는 프로젝트가 있는데, 그 발상은 참고할 만하다. '위험한 인자'를 탐지하지 말고, 위험한 인자를 애초에 쓸 수 없게 만드는 것이다. 이 프로젝트는 각 도구의 인자에 '형태'를 못 박아 둔다. 예컨대 어떤 인자는 특정 디렉터리 아래의 경로만 될 수 있고, 어떤 인자는 특정 호스트명만 될 수 있으며, 실제 호출 전에 먼저 검증해서 이 형태를 만들 수 없는 것은 일률적으로 거부한다. 이 프로젝트의 핵심은 이 계층이 다른 보안 수단과 중복되지 않는다는 데 있다. 정책 엔진은 '이 동작이 허용되는가'를 관장하고, 새니타이저는 인자 내용을 신경 쓰지 않는데, ToolClad는 바로 그 가장 치명적인 허점을 막아낸다. 동작은 허용되지만 인자가 악의적으로 변조된 경우 말이다.

한마디로, 도구 호출의 보안은 AI의 판단력에 외주를 맡길 것이 아니라 호출의 구조 안에 써 넣어야 한다. 인자 계약, 타입 제한, 인자를 문자열로 이어 붙여 실행하지 않기 — 이런 것들은 '구닥다리 소프트웨어 엔지니어링'처럼 보이지만, Agent 시나리오에서는 바로 AI가 넘을 수 없는 첫 번째 벽이다.

두 번째 고비: 프로토콜 — MCP는 인기가 많지만, 규모가 커지면 돈이 든다

MCP는 오늘날 거의 도구 호출의 '범용 플러그'가 되었지만, 기업 규모로 올라가면 두 가지 큰 비용을 드러낸다.

첫째는 서버가 계속 쌓인다는 점이다. API를 하나 붙일 때마다 독립된 서버를 하나씩 감싸는데, 저마다 배포와 의존성, 비밀번호 관리가 따로 있다. 누군가 공식 MCP 서버 116개를 분석했더니 88.6%가 뒤에서 그냥 평범한 REST API였고, 92%의 도구는 API를 그대로 감싼 것일 뿐이며, 서버 하나가 평균적으로 드러내는 것은 하부 API 기능의 19%에 불과했다.

둘째는 더 근본적인데, 모든 도구의 이름과 설명, 인자 형식을 매 대화마다 AI의 컨텍스트에 밀어 넣어야 한다는 점이다. 도구가 많을수록 차지하는 자리가 커지고, 그것도 선형으로 늘어난다. GitHub의 API에는 인터페이스가 900개가 넘는데, 200개만 골라도 어떤 사용자가 입을 열기도 전에 이미 수만 토큰을 먹어버린다.

그 결과가 '선택 붕괴'다. 실제 배포에서는 조직이 정말 쓰는 API 몇 개만 골라 노출하거나, 아니면 도구 세트를 조각조각 쪼개야 하는데 어느 쪽이든 어색하다. MCP가 해결하는 것은 'AI가 도구를 어떻게 호출하느냐'의 인터페이스 통일 문제이지만, 'AI가 어떤 도구가 있는지 어떻게 아느냐'라는 일에서는 여전히 가장 원시적인 '전체 방송'을 쓴다.

여기서 DADL이라는 방안을 추천하는데, 이 결함을 정면으로 겨냥한 것이다. 모든 도구의 설명을 AI에 전부 밀어 넣지 않고, 크기가 고정된 두 가지 조작만 노출한다. search(도구 찾기)와 execute(실행)다. 도구 광고의 토큰 비용은 약 14.2만에서 약 1,000으로 줄어 142배 압축됐다.

숫자 자체가 핵심은 아니다. 핵심은 프로토콜 설계의 무게중심이 바뀌었다는 것이다. 도구 호출이 규모화될 수 있느냐는 인터페이스가 얼마나 '표준'인지에 달린 것이 아니라, '도구 찾기'라는 일이 컨텍스트 윈도에 마구 밀어 넣는 것이 아니라 독립적인 검색 문제로 다뤄지느냐에 달려 있다.

세 번째 고비: 인지 — 도구가 많아지면 AI가 '눈이 어두워진다'

보안과 프로토콜은 잠시 접어 두고, 순전히 'AI가 명확하게 생각할 수 있느냐'는 관점에서만 봐도 도구 호출에는 과소평가된 고비가 있다. 도구가 많을수록 AI가 더 부정확하게 고른다.

프로덕션 환경의 데이터에 따르면 도구 수가 15개 정도를 넘으면 정확도가 뚜렷하게 떨어진다. 어떤 통제된 테스트에서는 도구가 10개에서 40개로 늘자 선택 정확도가 81.7%에서 62.5%로 떨어졌다. 이것은 '조금 어려워진' 것이 아니라 두 가지 메커니즘이 작용한 것이다.

첫째는 주의력이 희석되는 것, 좋은 것이 가운데 끼어 아무도 보지 않는다는 것이다. AI는 컨텍스트의 처음과 끝을 잘 기억하고 가운데는 쉽게 놓친다. 서로 비슷하게 생긴 도구 설명 수십 개가 쌓이면, 정말 적합한 것이 종종 바로 가운데 사각지대에 있다. 추론하지 못하는 것이 아니라, 주의력이 구조적으로 끌려가 버린 것이다.

둘째는 도구 환각이다. AI가 존재하지 않는 도구 이름을 지어내거나, 도구는 맞게 골랐는데 인자를 다른 도구에서 빌려 오기도 한다. 후자가 더 음흉한데, 호출은 '일어난 것처럼 보이지만' 인자가 어긋나 있어서 경성 실패에 속하기 때문이다.

이런 발견들은 역설적인 결론을 가리킨다. 도구 호출이 믿을 만하냐는 주로 도구 자체에 있지 않고, AI가 선택을 내리기 전에 무엇을 보았느냐에 달려 있다. 먼저 값싼 분류기로 '이번 턴에 도구를 써야 하는가'를 판정하고(게이팅), 이어서 도구 설명을 벡터 저장소로 만들어 현재 의도와 관련된 몇 개만 회수하고(검색식 선택), 그다음 후보 집합에서 계층적으로 결정하는 — 이 조합은 본질적으로 수동적으로 AI의 똑똑함에 기대는 것이 아니라 AI의 주의력 예산을 능동적으로 관리하는 것이다.

도구 호출의 품질은 상당 부분 정보 아키텍처의 품질이다.

네 번째 고비: 실패 복구 — 가장 비싼 함정은 '호출은 성공했는데 일은 못 끝낸' 경우다

도구 호출 분야에는 체계적인 편향이 있다. 모두가 거의 '호출이 성공했는가'만 보지만, 온라인에서 가장 돈이 많이 나가는 실패는 호출은 성공했는데 전체 흐름은 실패한 경우다.

하나의 도구가 합법적인 JSON과 올바른 상태 코드를 반환할 수 있지만, 반환된 내용이 Agent가 현재 처한 프로세스 단계와 맞지 않을 수 있다. 하나의 도구 체인이 매 단계마다 "올바르게 호출"되었음에도 의존 관계에서 점점 어긋나 쌓여, 하류의 어느 단계에 이르러서야 상류가 이미 틀어져 있어 되돌릴 수 없다는 것을 발견하게 될 수 있다.

도구 사이에는 구조적 의존성도 있고 행위적 의존성도 있어, 무작정 단일 경로로 가면 하나가 틀어지는 순간 복구가 불가능하고, 탐색 공간은 기하급수적으로 폭발한다. 그래서 LLM의 도구 호출을 두 개 층으로 나누어야 한다. 상위 층에서는 네 가지 중 하나를 골라 의사결정을 하고, 하위 층에서는 도구 의존성 그래프 위에서 경로 탐색을 수행하며, 명시적인 "그래프 내비게이터"로 도구들 사이의 관계를 모델링하는 것이다. 이렇게 하면 API가 죽거나 의미가 표류해도 처음부터 다시 하는 대신 실시간으로 도구 체인을 재구성할 수 있다.

이 아키텍처 선택의 통찰은 한 문장이다. 도구 호출의 복구 능력은 AI의 추론에서 "스스로 자라나기를" 기대할 것이 아니라, 오케스트레이션 계층의 위상 구조 안에 설계되어야 한다. 백트래킹, 대체 경로, 의존성 그래프의 동적 재라우팅은 이는 오케스트레이터가 할 일이지 프롬프트가 할 일이 아니다.

이에 맞춰 평가도 함께 업그레이드해야 한다. 완전한 도구 호출 평가는 최소한 다섯 가지를 구분해야 한다. 이번 턴에 도구를 써야 하는가(게이팅이 맞는가), 도구를 제대로 골랐는가(선택이 정확한가), 파라미터가 현실 세계와 맞는가(파라미터 정밀성), 호출 체인이 의존성상 통하는가(오케스트레이션 유효성), 어느 단계가 막혔을 때 동등한 경로로 우회할 수 있는가(복구 능력)이다. 대부분의 팀은 앞의 두 항목에만 기준을 세웠고 뒤의 세 항목은 사실상 감에 의존한다. 그런데 바로 이 세 항목이 온라인 사고의 주요 원인이다.

마지막으로

모델은 점점 더 강력해지고 추론도 점점 더 나아질 것이지만, 위의 각 벽이 해결하려는 문제들은 모델이 강력해진다고 해서 저절로 사라지지 않는다. 그것들은 "AI가 못 한다"는 표면적 실패에서 "AI가 할 수는 있지만 당신은 그것이 그렇게 하기를 원하지 않는다"는 이면적 위험으로 바뀔 뿐이다. 도구 호출이 진정으로 성숙했다는 표시는 Agent가 만 개의 도구를 호출할 수 있다는 것이 아니라, 그것이 매 도구를 호출할 때 경계가 어디에 그어져 있는지, 그리고 경계가 넘어졌을 때 어떤 구조가 그것을 받아내는지를 당신이 명확히 알고 있다는 것이다.