LLM 도구 호출의 설계와 운영

도구·함수 호출은 LLM이 외부 함수, API, 파일시스템, 데이터 소스와 연결되는 기본 인터페이스다. 이 에피소드는 schema 설계, parallel 호출, MCP, BFCL 평가, 보안과 silent failure까지 운영 관점에서 정리한다.

Layer: L12
Duration: 길이 미정
Generated: 2026. 5. 25. 오후 4:33:33

원본 문서 읽기 오디오 파일 열기

Script Companion

오디오와 함께 스크립트 보기

01
도구·함수 호출은 agent를 이해할 때 거의 출발점에 놓이는 개념이다. tool 없는 agent는 없다고 말할 수 있을 만큼, LLM이 실제 외부 세계와 만나려면 함수, API, 데이터베이스, 파일시스템, web, 이메일 같은 실행 지점이 필요하다. 이 연결은 LLM의 knowledge cutoff를 보완하지만, 동시에 잘못 호출하면 데이터 손실, 비용 폭증, 외부 사고로 이어진다. 그래서 tool calling은 단순한 편의 기능이 아니라, 호출 정확도와 action 보안을 함께 설계해야 하는 운영 인터페이스다.
02
기본 구조는 비교적 단순하다. LLM에 tool 명세를 주면, 모델은 어떤 함수를 어떤 파라미터로 호출할지 JSON 형태로 반환한다. Provider마다 이름과 포맷은 다르다. OpenAI는 function calling에서 tools 안의 function parameters를 쓰고, Anthropic은 tool use에서 input schema를 쓰며, Gemini는 function declarations 안의 parameters를 쓴다. LangChain은 @tool decorator와 Pydantic, dataclass, Zod로 schema 생성을 돕고, LiteLLM은 OpenAI 호환 방식으로 provider 추상화를 제공한다.
03
여기서 공통분모는 대부분 JSON schema 기반이라는 점이다. 형식이 완전히 같지는 않아도 인터페이스는 거의 호환되며, LiteLLM이나 LangChain 같은 provider abstraction 라이브러리를 쓰면 어느 정도 통일할 수 있다. 다만 호환된다는 말이 schema를 대충 써도 된다는 뜻은 아니다. LLM은 자연어 설명과 schema 제약을 보고 호출 여부와 파라미터를 결정하므로, tool 명세 자체가 모델 행동을 유도하는 중요한 입력이 된다.
04
좋은 tool schema는 호출 정확도를 크게 좌우한다. description은 짧은 라벨보다 상세한 동작, 입력 조건, 반환 형태를 말해 주는 편이 낫다. 예를 들어 도시 날씨를 가져온다는 식의 짧은 설명보다, 도시 이름을 받아 현재 기온, 습도, 강수 확률을 JSON으로 반환하고 city는 영문 도시명이어야 한다고 적는 쪽이 더 명확하다. parameter에는 의미와 예시를 넣고, required와 optional을 구분하며, unit처럼 선택지가 제한되는 값은 enum으로 묶어야 한다.
05
tool 이름도 동작을 표현해야 한다. get_user_email_by_id처럼 결과와 기준이 드러나는 이름은 fetch 같은 넓은 표현보다 모델이 선택하기 쉽다. tool 개수도 경계 조건이다. 보통 20개 이하가 권장되며, 30개 이상으로 늘어나면 hallucinated tool 호출 위험이 커진다. agent가 너무 많은 tool을 가져야 한다면 한 agent에 모두 밀어 넣기보다 sub-agent로 나누는 판단이 필요하다. tool registry도 prompt처럼 버전 관리와 회귀 평가가 필요한 코드 자산으로 봐야 한다.
06
Parallel tool calling은 한 번의 turn에서 여러 tool을 동시에 호출하게 하는 방식이다. OpenAI, Anthropic, Gemini 모두 지원하며, 독립적인 정보를 동시에 수집할 때 latency를 줄일 수 있다. 하지만 모든 호출이 병렬에 맞는 것은 아니다. 한 호출의 결과가 다음 호출의 입력이 되거나, 같은 상태를 읽고 쓰는 작업이 섞이면 sequential agent처럼 순차 처리해야 한다. 특히 read-only tool은 병렬 허용이 상대적으로 안전하지만, delete, update, send처럼 상태를 바꾸는 tool은 병렬 실행이 사고로 이어질 수 있다.
07
Parallel 호출의 위험은 응답만 보면 정상처럼 보이는 silent failure에서 더 커진다. 문서에는 gpt-4.1-nano-2025-04-14가 parallel 활성 시 같은 tool을 의미 없이 2회에서 3회 중복 호출하는 회귀가 보고된 사례가 나온다. 비용과 rate-limit은 폭주하지만 모델 응답만 보면 성공처럼 보일 수 있다. 또 같은 사용자를 수정하는 write tool과 삭제하는 write tool을 한 turn에서 병렬로 결정하면, 클라이언트 실행 순서에 따라 결과가 비결정적이 된다. OpenAI는 parallel_tool_calls: false, Anthropic은 disable_parallel_tool_use: true로 turn당 최대 1개 tool만 부르게 막을 수 있다.
08
MCP, Model Context Protocol은 LLM, 도구, 데이터 소스 사이를 잇는 오픈 프로토콜이다. Anthropic이 2024년 11월 공개했고, JSON-RPC 기반으로 동작한다. 핵심 개념은 읽을 데이터인 Resources, 실행할 액션인 Tools, 재사용 가능한 prompt template인 Prompts다. MCP의 가치는 tool마다 따로 SDK를 작성하지 않고, MCP 호환 server 하나를 여러 MCP 호환 client에서 쓸 수 있다는 데 있다. 2025년 기준 GitHub, Slack, Notion, Postgres 등 200개 이상의 official 또는 community MCP server가 언급된다.
09
MCP를 쓸지 자체 SDK를 유지할지는 신호로 판단해야 한다. GitHub, Slack, Postgres, Notion처럼 공식 MCP server가 이미 있거나, Claude Desktop, Cursor, 사내 IDE 플러그인 같은 외부 client에서 우리 tool을 부를 가능성이 있거나, tool이 5개 이상이고 client마다 권한과 sandboxing이 달라지는 멀티 tenant 상황이면 MCP 쪽 신호가 강하다. 반대로 tool이 1개나 2개이고 단일 앱 안에서만 LLM 호출이 일어난다면 MCP server, client, transport 3계층이 over-engineering일 수 있다.
10
자체 SDK가 더 나은 경우도 명확하다. 사내 protobuf, gRPC, tenant별 JWT 권한 분리, 비공개 schema가 핵심 자산이라면 JSON-RPC와 stdio, SSE로 옮기는 비용이 더 클 수 있다. audit log와 rate limit을 자체 미들웨어에서 강제하던 경로가 있으면, MCP server proxy 쪽에 별도 구현을 끼워야 기존 운영 통제가 유지된다. transport도 현실적인 제약이다. MCP 공식 사양의 stdio, SSE, Streamable HTTP 옵션을 확인해야 하며, 사내 네트워크에서 stdio 자식 프로세스 허용이 막혀 있으면 채택 자체가 어려울 수 있다.
11
Tool calling 평가는 BFCL, Berkeley Function Calling Leaderboard가 대표 기준이다. BFCL v3는 2024년 9월 19일 출시되고 2024년 12월 10일 마지막 업데이트가 언급된 표준 벤치마크이며, 4,441개 평가 항목으로 구성된다. Non-Live Single-Turn은 1,390건으로 Simple, Multi-function, Parallel 호출 정확도를 보고, Live Single-Turn은 2,251건으로 production 유사 시나리오를 본다. Multi-Turn 800건은 단순 파라미터 매칭이 아니라 API 시스템의 실제 상태 변화를 검증하는 state-based 평가를 사용한다. Hallucination 영역은 존재하지 않는 tool 호출 여부를 본다.
12
BFCL 점수는 0에서 1 사이의 정확도 값이다. 2025년 4월 기준 리더보드 1위권 모델은 대략 0.77에서 0.80 수준, 전체 모델 평균은 대략 0.70 수준으로 제시된다. 다만 85 이상이면 통과, 70 미만이면 실패 같은 임계값은 공식 기준이 아니라 커뮤니티 경험적 추정이다. BFCL v3 공식 문서에는 합격이나 불합격 임계값이 없으므로, 운영에서는 리더보드 순위와 자체 도메인 평가를 함께 봐야 한다. Claude 4.x, GPT-4o, o3, Llama 4처럼 tool-heavy 작업에 적합한 후보를 고를 때도 이 점을 잊지 않아야 한다.
13
운영자가 자주 만나는 실패는 조용하게 발생한다. LLM이 존재하지 않는 hallucinated tool을 호출하면 클라이언트가 그냥 무시할 수 있고, age에 문자열 twenty를 넣는 식의 parameter type 오류는 JSON schema validation에서야 드러난다. 필요한 tool을 호출하지 않고 단답만 하는 경우에는 description이 부족하거나 prompt가 약할 수 있으며, 같은 tool을 반복하는 agent loop는 max iteration 제한이 없을 때 길어진다. stale data는 cache TTL이 불명확할 때 생기고, tool 안에서 비싼 LLM 호출이 다시 일어나면 cost explosion으로 이어질 수 있다.
14
Silent failure를 복구하려면 증상, 원인, 대응을 분리해서 봐야 한다. LLM이 tool을 호출하지 않으면 description을 개선하고 tools를 사용해야 한다는 요구를 더 명시한다. 잘못된 tool을 부르면 유사 이름이 많거나 설명이 모호한 경우가 많으므로 tool을 분리하고 description 차이를 분명히 한다. parameter 오류가 잦으면 enum, required, JSON schema strict를 강화한다. tool 무한 반복은 max_iter 제한과 scratchpad의 history 명시로 줄이고, error message가 사용자에게 노출될 때는 tool error를 LLM에게만 보여 주고 사용자에게는 sanitize된 메시지를 내보내야 한다.
15
보안에서는 최소 권한 원칙이 기본이다. tool마다 필요한 권한만 주고, 어떤 user가 어떤 tool을 호출할 수 있는지 allowlist로 명시해야 한다. 코드 실행 tool은 E2B, Modal, Anthropic Code Execution sandbox 같은 격리된 환경에서만 다루며, 이메일 전송, 결제, DB 삭제처럼 비가역 액션은 confirmation을 거친다. 모든 tool 호출은 audit log로 남겨 사고 분석이 가능해야 한다. 또 tool result 안에는 prompt injection이 숨어 있을 수 있으므로, trusted와 untrusted 데이터를 분리하는 방어가 필요하다.
16
Computer Use와 Code Execution은 tool use의 확장된 형태로 볼 수 있다. Anthropic Computer Use API는 2024년 10월 공개된 패러다임으로, LLM이 화면을 보고 마우스와 키보드를 제어한다. 일반 GUI 자동화에 쓸 수 있지만 화면당 LLM 호출이 필요해 latency가 크고, 정확도와 보안 위험의 한계가 있다. Code Execution as Tool은 LLM이 코드를 작성하고 sandbox에서 실행한 결과를 답변에 활용하는 방식이다. OpenAI Code Interpreter, Advanced Data Analysis, Anthropic Code Execution, E2B, Modal, Daytona가 언급되며, 데이터 분석, 계산, 시각화에 강하지만 격리 sandbox가 필수다.

같은 레이어

L12에서 이어 듣기

원본 문서: content/topics/L12/tool-and-function-calling.md
오디오 파일: /podcasts/l12-tool-and-function-calling.mp3