RUDA DIRECTOR · AI Agent — 30 DAYS / 90 ARTICLES · Day 02 · Learn 02
30초 답변: Tool Calling은 Model이 외부 API나 Function을 직접 실행하는 기능이 아니다. 일반적인 client-side Function Calling에서 Model은 어떤 Tool을 어떤 Arguments로 호출할지 구조화된 요청을 만들고, Application 또는 Runtime이 그 요청을 검증·승인·실행한 뒤 Tool Result를 다시 Model에 돌려준다. 따라서 신뢰성과 안전성의 핵심은 Model의 판단력만이 아니라 실행 경계를 어디에 두는가에 있다.
Tool Calling에서 실제로 실행하는 주체는 누구인가
OpenAI는 Function Calling을 Tool Calling이라고도 부르며, Tool Call을 “Model이 사용할 수 있도록 제공된 Tool을 사용해 달라는 요청”으로 설명한다. 공식 flow도 명확하다. Application이 사용 가능한 Tool을 Model에 제공하고, Model이 Tool Call을 반환하면, Application이 Tool Call의 입력으로 코드를 실행한 뒤 그 Tool Output을 다시 Model에 전달한다.
Anthropic도 같은 경계를 둔다. Client Tool에서는 Claude가 tool_use block을 반환하고, Application이 실제 연산을 수행한 뒤 tool_result를 돌려준다. Web Search나 Code Execution처럼 Provider가 실행하는 Server Tool도 있지만, 이 경우에도 “Model 자체가 Credential과 실행 권한을 소유한다”는 뜻은 아니다. 실행은 Provider Runtime의 정책과 권한 안에서 일어난다.
핵심 판단: Tool Schema는 “Model이 무엇을 요청할 수 있는가”를 정의한다. Permission과 Approval은 “그 요청을 실제로 실행해도 되는가”를 결정한다. 둘은 같은 층이 아니다.
Tool Calling, Function Calling, Structured Output은 어떻게 다른가
| 개념 | 핵심 역할 | 혼동하면 생기는 문제 |
|---|---|---|
| Tool Calling | Model이 사용할 Capability를 선택하고 호출 요청을 만든다 | Model이 실행 권한까지 가진다고 오해한다 |
| Function Calling | JSON Schema 등으로 정의된 Function Tool을 호출하는 Tool Calling의 대표 형태 | Function Schema를 Business Rule로 착각한다 |
| Structured Output | Model 출력의 형식을 Schema에 맞춘다 | 형식이 맞으면 실행도 안전하다고 착각한다 |
| Permission / Approval | 누가 어떤 Side Effect를 실행할 수 있는지 제한한다 | Prompt만으로 보안 경계를 대신한다 |
OpenAI의 Strict mode처럼 Schema 준수를 강제하는 기능은 매우 유용하다. 하지만 Schema Conformance는 Authorization이 아니다. 예를 들어 qty가 올바른 Integer라는 사실은 사용자가 200개를 발주할 권한이 있다는 뜻이 아니다. Tool Calling을 설계할 때 형식 검증과 Business Validation을 반드시 분리해야 한다.
Mechanism: Tool Call은 Agent Loop 안에서 어떻게 흐르는가
USER GOAL ↓ APPLICATION Prompt + available Tool definitions ↓ MODEL DECISION Answer directly OR request Tool Call ↓ TOOL CALL name + arguments + call identifier ↓ VALIDATION / PERMISSION / APPROVAL ↓ EXECUTION Function / API / Database / Service ↓ TOOL RESULT data / error / execution state ↓ MODEL Final answer OR another Tool Call ↺
여기서 실제로 움직이는 데이터는 세 종류다. 첫째, Tool Definition은 Model에게 가능한 Action Space를 알려준다. 둘째, Tool Call은 Model이 선택한 Action과 Arguments를 Runtime에 전달한다. 셋째, Tool Result는 외부 세계에서 관측된 결과를 다시 Context로 가져온다. 이 Result가 다음 Decision을 바꾸면 지난 글에서 본 Agent Loop가 닫힌다.
OpenAI 공식 문서는 이 과정을 다섯 단계로 설명한다: Tool을 포함해 Model에 요청 → Tool Call 수신 → Application side에서 코드 실행 → Tool Output을 포함해 다시 Model에 요청 → Final Response 또는 추가 Tool Call 수신. Tool Calling은 한 번의 Function 실행이 아니라 Model과 Runtime 사이의 왕복 Protocol에 가깝다.
Worked Example: 재고 확인과 발주 초안을 분리하라
아래는 구조를 설명하기 위한 가상 Trace다. 실제 운영 기록이나 고객 사례가 아니다.
User가 “A-17 부품 재고가 안전재고보다 적으면 200개 발주 초안을 만들어줘”라고 요청했다고 하자. System에는 읽기 Tool인 get_inventory와 쓰기 Tool인 create_purchase_draft가 있다.
| Step | 상태 | 결정 / 실행 주체 |
|---|---|---|
| 0 | Goal: 재고 확인 후 필요하면 초안 생성 | User |
| 1 | get_inventory({sku:"A-17"}) 요청 | Model |
| 2 | SKU 형식과 조회 권한 검증 후 Inventory API 실행 | Application |
| 3 | {available:80, safety_stock:150} 반환 | Tool / Service |
| 4 | create_purchase_draft({sku:"A-17", qty:200}) 요청 | Model |
| 5 | Write Action이므로 Permission과 Approval 확인. 아직 실행하지 않음 | Application Gate |
| 6 | 승인 전에는 발주 초안을 생성하지 않고 사용자에게 상태를 설명 | Runtime + Model |
이 예제에서 Model은 “재고가 안전재고보다 낮다”는 조건을 해석하고 다음 Tool을 선택할 수 있다. 하지만 발주를 실제로 만들어도 되는지는 별개의 문제다. System Prompt에 “위험한 행동은 조심해”라고 쓰는 것만으로는 Permission Gate를 대체할 수 없다.
Tool Calling이 실패하는 대표적인 5가지 방식
1. Tool Boundary가 겹쳐 잘못된 Tool을 선택한다
search_customer와 find_account처럼 기능이 겹치는 Tool이 동시에 노출되면 Model이 어떤 Tool을 써야 하는지 흔들릴 수 있다. Anthropic은 Tool마다 명확하고 구별되는 목적을 두고, Tool 수와 중복을 신중히 줄이라고 권한다. 선택 문제를 Prompt로만 해결하기보다 Capability Boundary부터 정리하는 편이 낫다.
2. Schema 통과를 Business Validation으로 착각한다
strict: true는 Function Call이 정의한 Schema에 안정적으로 맞도록 돕는다. 그러나 공급업체가 승인된 곳인지, 사용자가 구매 권한이 있는지, 수량 한도를 초과하는지는 다른 검증이다. 형식 검증은 실행 적합성 검증의 일부일 뿐이다.
3. Side Effect를 바로 실행해 Retry가 중복 작업을 만든다
Network Timeout 뒤 같은 요청을 다시 실행하면 주문·메일·결제·발행이 중복될 수 있다. Write Tool은 Idempotency, 현재 실행 상태 조회, Retry 가능 여부, Human Approval을 함께 설계해야 한다. “Model이 똑같은 Tool Call을 두 번 하지 않을 것”이라고 가정하면 안 된다.
4. 모든 Tool을 한꺼번에 노출해 Context와 선택 비용을 키운다
Tool 이름, 설명, Schema는 Model Context에 들어간다. Anthropic은 너무 많은 Tool이나 겹치는 Tool이 효율적인 전략 선택을 방해할 수 있고, Tool Result도 Context를 소비하므로 필요한 정보만 반환하도록 설계하라고 설명한다. 더 많은 Tool은 곧 더 많은 Capability이지만, 동시에 더 넓은 선택 면적과 Token 비용을 만든다.
5. Error를 한 줄 자연어로 삼켜 다음 Decision을 망친다
“실패했습니다”만 반환하면 Model은 재시도 가능한 실패인지, 입력을 고쳐야 하는지, 권한이 없는지 구분하기 어렵다. Error Type, Retryable 여부, 안전한 사용자 메시지, 실행 식별자를 구분하면 다음 Decision과 Observability가 좋아진다.
Tool 하나를 추가할 때 함께 늘어나는 비용
| 축 | 얻는 것 | 함께 늘어나는 것 |
|---|---|---|
| Quality | 최신 데이터와 실제 기능 접근 | 잘못된 Tool·Arguments 선택 가능성 |
| Reliability | 결정론적 Service 활용 | Network·API·부분 실패 처리 |
| Latency | 외부 조회·계산·Action | Model ↔ Tool 왕복 시간 |
| Cost / Context | 넓어진 Capability | Tool Definition·Result Token |
| Observability | Call 단위 Trace 가능 | Arguments·Result·상태 기록 설계 |
| Permission / Security | 현실 시스템에 Action 가능 | Credential·Scope·Approval Surface |
| Complexity | 동적인 Action 선택 | Retry·Timeout·Fallback·Stop Condition |
따라서 “Tool을 더 붙이면 Agent가 더 강해진다”는 식으로 설계하면 안 된다. 가장 작은 competent architecture가 기본값이다. 필요한 Capability만 노출하고, Tool Result는 다음 Decision에 필요한 신호만 남기는 편이 품질·비용·관찰 가능성을 함께 관리하기 쉽다.
언제 Tool Calling을 쓰지 않는 편이 나은가
- 입력된 문장을 요약·분류·재작성하는 등 외부 데이터와 Action이 필요 없는 작업
- 다음 단계와 Function이 이미 확정돼 있어 일반 Code가 직접 호출하면 되는 작업
- 실행 권한·감사 로그·중복 방지 장치를 만들 수 없는 위험한 Side Effect 작업
- Tool 왕복의 Latency와 Cost가 사용자 가치보다 큰 단순 조회
- 정답이 명시적 Rule로 정의돼 있어 Model이 Tool을 선택할 이유가 없는 계산
Model에게 Function 선택을 맡길 이유가 없다면 Application이 직접 Function을 호출하는 편이 더 단순하고 안정적이다. Agentic 선택은 Runtime에서 어떤 Action이 필요한지 사전에 확정하기 어려울 때 가치가 생긴다.
실무 설계 Checklist
- 이 작업은 정말 외부 데이터나 Action이 필요한가?
- 각 Tool은 다른 Tool과 겹치지 않는 명확한 목적을 갖는가?
- Tool 설명만 읽어도 언제 쓰고 언제 쓰지 말아야 하는지 알 수 있는가?
- Schema는 가능한 입력 범위를 충분히 좁히는가?
- Arguments를 Model 밖에서 다시 검증하는가?
- Permission과 Approval이 Prompt가 아니라 Runtime에서 강제되는가?
- Write Tool에 Idempotency와 Retry 판정이 있는가?
- Tool Result가 성공·Error·Retry 가능성을 구분하는가?
- 이번 Turn에 필요하지 않은 Tool을 덜 노출할 수 있는가?
- Call 수, Timeout, 사용자 중단 같은 Stop Condition이 있는가?
Design Rule: Model에게는 “무엇을 요청할지”를 맡기고, Runtime에는 “그 요청을 실행해도 되는지”를 남겨라.
이전 / 다음 / 관련 글
- Previous: Agent Loop란 무엇인가: AI Agent가 한 번의 답변으로 끝나지 않는 이유
- Next: Context — Tool Result와 대화 기록 중 무엇을 다음 Turn에 남겨야 하는가. (다음 학습 의존성)
- Related: AI Agent와 Workflow의 차이: 언제 Agent가 필요한가
- Foundation: AI Agent란 무엇인가: 챗봇과 무엇이 다른가
공식 참고 자료
- OpenAI — Function calling
- OpenAI Agents SDK — Tools
- Anthropic — Tool use with Claude
- Anthropic Engineering — Writing effective tools for agents
문서 확인일: 2026-09-28. API의 세부 필드와 지원 범위는 바뀔 수 있으므로 구현 시 최신 공식 문서를 다시 확인해야 합니다.