에이전트 툴 콜링 모범 사례: 에이전트가 잘못된 도구를 고르는 이유

에이전트 툴 콜링 모범 사례: 에이전트가 잘못된 도구를 고르는 이유

에이전트 툴 콜링 모범 사례는 작동하는 데모와 프로덕션에서 조용히 잘못된 도구를 호출하는 에이전트를 가르는 경계입니다. Anthropic 엔지니어링 팀은 설명 하나를 다시 작성해 도구 결과 하나를 206토큰에서 72토큰으로 줄인 사례를 측정했고, Claude Code는 이제 모든 도구 응답을 25,000토큰으로 강제 제한합니다. 토큰 누수가 실제로 일어나기 때문입니다. 에이전트는 네 가지로 실패하며, 잘못된 도구, 잘못된 인자, 폭주 루프, 토큰 누수 각각에 이번 주에 적용할 수 있는 해결책이 있습니다.

핵심 요약:

• 에이전트 툴 콜링은 정확히 네 가지로 실패합니다. 잘못된 도구, 잘못된 인자, 폭주 루프, 토큰 누수입니다.
• 도구 설명은 모델이 선택 시점에 보는 유일한 지시이므로, 잘못된 도구 호출의 대부분을 고칩니다.
• 납작하고 작업에 맞춘 스키마에 검증된 입력을 쓰면 잘못된 인자 실패의 대부분이 사라집니다.
• 간결한 도구 응답과 변경마다 실행하는 평가 루프가 토큰 비용과 회귀를 측정 가능하게 유지합니다.

왜 에이전트 툴 콜링은 프로덕션에서 실패할까?

에이전트 툴 콜링은 네 가지로 실패합니다. 모델이 잘못된 도구를 고르고, 잘못된 인자를 작성하고, 폭주 루프를 돌거나, 비대 응답으로 토큰을 누수합니다. 각 실패는 호출 루프의 서로 다른 단계에서 발생하므로 고치는 순서가 중요합니다. 잘못된 도구 선택은 이후 모든 단계를 오염시키므로 선택부터 시작하세요.

한눈에 보는 전체 처방:

이 순서대로 진행하세요. 실천법 1과 2는 오후 반나절이면 끝나며, 오늘 보이는 잘못된 도구·잘못된 인자 실패의 대부분을 제거합니다. 도구 설명은 문서가 아닙니다. 모델이 선택 시점에 받는 유일한 지시입니다.

1단계: 모델이 실제로 쓸 수 있는 도구 설계하기

에이전트 툴 콜링에서 가장 저렴하게 신뢰성을 얻는 곳은 프롬프트도 모델 선택도 아닌 도구 정의입니다. 모델은 여러분의 API 문서나 README를 절대 읽지 않습니다. 이름, 설명 문자열, JSON 스키마만 보고 그것만으로 결정합니다. 이 세 가지를 바로잡으면 다른 것을 건드리기 전에 선택 정확도가 움직입니다.

실천법 1: 모델이 실행할 수 있는 설명 작성

도구 설명은 API 문서가 아니라 모델에게 주는 지시로 작성하세요. 인간 개발자를 만족시키는 설명("users 엔드포인트의 REST 래퍼")은 모델에게 판단 근거를 전혀 주지 못합니다. Anthropic의 도구 작성 엔지니어링 가이드와 도구 정의 모범 사례 모두 같은 패턴을 권합니다. 도구를 언제 쓰는지, 무엇을 반환하는지, 언제 쓰지 말아야 하는지를 명시하세요.

{
  "name": "get_user",
  "description": "Fetches a user profile. Use ONLY when you already have a user_id. Do NOT use to search or list users; call search_users instead. Returns name, email, plan. Errors if user_id is not a valid UUID."
}

대부분의 팀이 출시하는 버전과 비교하면:

{
  "name": "get_user",
  "description": "Gets a user."
}

여기서는 두 가지 규칙이 대부분의 일을 합니다. 첫째, 파라미터 이름은 의미가 모호하지 않게 지으세요. user나 id가 아니라 user_id로 지어야 합니다. user는 모델이 UUID가 들어갈 자리에 이름이나 이메일을 넘기도록 유도합니다. 둘째, 제외 조건을 명시적으로 적으세요. "사용자 검색에 쓰지 말 것"이라는 한 줄이 아무리 많은 긍정적 설명보다 잘못된 도구 호출을 더 많이 막습니다. 모델은 단일하고 경계가 분명한 도구보다 겹치는 도구를 훨씬 자주 혼동합니다. 이 정의가 OpenAI, Anthropic, Google API에 도달하는 공급자 수준 메커니즘은 멀티 프로바이더 함수 콜링 가이드에서 확인하세요.

실천법 2: 스키마를 납작하고 작업에 맞게 유지

입력 스키마는 납작하게 유지하고, 작업에 실제로 필요한 필드만 넣고 필요 없는 필드는 빼세요. 선택 분기가 있는 중첩 객체는 잘못된 인자 실패가 번식하는 곳입니다. 모델은 예시를 한 번도 보지 못한 구조를 추론해야 합니다. OpenAI 함수 콜링 가이드는 임의의 JSON Schema를 허용하지만, 관대하다는 것과 신뢰할 수 있다는 것은 다릅니다.

{
  "name": "create_ticket",
  "parameters": {
    "type": "object",
    "properties": {
      "ticket": {
        "type": "object",
        "properties": {
          "details": {
            "type": "object",
            "properties": {
              "title": { "type": "string" },
              "meta": { "type": "object" }
            }
          }
        }
      }
    }
  }
}

작업에 맞게 납작하게 펴세요:

{
  "name": "create_ticket",
  "parameters": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "assignee_id": { "type": "string" }
    },
    "required": ["title", "priority"]
  }
}

값의 집합이 한정된 필드에는 자유 텍스트보다 enum이 낫습니다. required 배열은 모든 것을 선택으로 두는 것보다 낫습니다. 모델이 거의 항상 필요한 필드라면, API에서는 선택이라 해도 도구 스키마에서는 required로 만드세요. 여러분은 API를 그대로 옮기는 것이 아닙니다. 특정 모델 하나가 정확히 채울 수 있는 표면을 설계하는 것입니다.

2단계: 도구만이 아니라 도구 세트 관리하기

에이전트가 손에 꼽을 만큼보다 많은 도구를 가지면 개별 도구의 품질만으로는 부족해집니다. 모델이 읽는 목록의 크기가 커질수록 선택 오류도 늘어나기 때문입니다.

실천법 3: 다단계 API 시퀀스를 원자적 도구로 감싸기

고정된 API 호출 시퀀스는 하나의 원자적 도구로 합치세요. Anthropic의 엔지니어링 포스트는 schedule_event와 get_customer_context를 모델로 제시합니다. 전체 작업을 한 번에 끝내는 호출 하나가, 에이전트가 매번 올바르게 연결해야 하는 세 번의 호출보다 낫습니다. 체인의 각 고리는 모델이 멈추거나, 잘못 재시도하거나, 루프에 빠질 수 있는 또 한 번의 턴입니다.

# What the agent does WITHOUT an atomic tool: 3 calls, 3 chances to fail
calendar = call_tool("list_calendars", {})
free = call_tool("find_free_slot", {"calendar_id": calendar["items"][0]["id"], "duration": 30})
call_tool("create_event", {"calendar_id": calendar["items"][0]["id"], "start": free["start"]})

# One atomic tool: the sequence lives in your code, not the model's head
call_tool("schedule_event", {"duration": 30, "attendees": ["[email protected]"]})

경험칙: 모델이 항상 A 다음에 B를 호출해야 한다면, A와 B는 두 벌의 옷을 입은 하나의 도구입니다.

실천법 4: 도구에 네임스페이스를 부여하고 가지치기·동적 필터링

모든 도구 이름에 네임스페이스를 부여하고, 각 에이전트에는 현재 작업에 필요한 하위 집합만 보여주세요. 일반적인 이름은 통합을 두 개 연결하는 순간 충돌합니다. search라는 도구를 노출하는 두 MCP 서버에 연결된 에이전트를 떠올려 보세요. 동일한 동사 두 개가 생기고 구분할 방법이 없습니다. Anthropic은 접두사 네임스페이싱으로 측정 가능한 평가 개선을 기록했습니다.

가지치기도 이름 짓기만큼 중요합니다. 지원 에이전트는 비밀번호 질문에 답하는 동안 결제 도구를 로드할 필요가 없습니다. 플래너가 작업을 관련 도구만 로드하는 워커로 라우팅하는 플래너-워커 패턴이 표준 해결책입니다. LangGraph의 동적 도구 로드 방법이 구현을 안내합니다. 도구는 몇 개부터 너무 많을까요? 에이전트당 5~10개를 법칙이 아닌 실무 범위로 보세요. 목록이 커지면 정확도는 떨어지며, 해법은 더 큰 모델이 아니라 필터링입니다. 라우팅·필터링 계층 자체를 고르는 중이라면 최고의 함수 콜링 라이브러리 라운드업에서 선택지를 비교하세요.

3단계: 돌아오는 것과 나가는 것 제어하기

루프는 양방향으로 흐르지만, 대부분의 팀은 나가는 쪽 절반만 설계합니다. 도구가 무엇을 반환하느냐가 콘텍스트 윈도우 중 다음 턴까지 살아남는 양을 결정하고, 검증이 무엇을 거부하느냐가 모델이 실수에서 배우는지 반복하는지를 결정합니다.

실천법 5: 간결하고 신호가 높은 결과 반환

모델이 처리할 수 있는 가장 작은 결과를 반환하고, 원시 ID 대신 사람이 읽을 수 있는 식별자를 쓰세요. Anthropic의 엔지니어링 포스트는 기본 결과가 206토큰이던 도구를 기록했습니다. 간결한 response_format 설정 하나로 같은 결과가 72토큰으로, 약 3분의 1 크기로 줄었습니다. 여기에 작업당 수십 번의 호출을 곱하면, 에이전트가 끝까지 마칠 수 있는지 자체가 결정됩니다.

// Before: 206 tokens (shape per Anthropic's documented example)
{
  "status": "success",
  "data": {
    "id": "8f14e45f-ceea-3f9c-a2f3-90c1b5e0a7d2",
    "object": "task", "created_at": "2026-07-02T09:14:00Z",
    "updated_at": "2026-07-11T16:40:12Z", "completed_at": null,
    "assignee": {"id": "c9a1...f2", "object": "user"},
    "projects": [{"id": "b7d3...91", "object": "project"}],
    "permalink": "https://app.asana.com/0/.../f"
  }
}

// After: 72 tokens
{ "task": "Fix login redirect", "assignee": "Dana Kim", "project": "Web App", "due": "2026-07-20" }

같은 출처의 세부 사항 두 가지가 더 있습니다. Anthropic은 도구 정의에 response_format enum(detailed 대 concise)을 지원하므로, 쏟아지는 데이터를 파싱하는 대신 원하는 형태를 선언할 수 있습니다. 그리고 Claude Code는 도구 응답을 25,000토큰으로 제한하는데, 이는 어떤 경우든 비대 결과를 잘라내는 강제 상한입니다. Anthropic은 또한 자체 발견으로, UUID를 의미 있는 이름으로 해석하면 검색 환각이 측정 가능하게 줄었다고 보고합니다. 위 "after" 페이로드가 c9a1...f2가 아니라 "Dana Kim"이라 적힌 이유입니다. 비대 응답은 비용 문제이기도 합니다. 전체 그림은 LLM API 비용 절감 가이드에서 확인하세요.

실천법 6: 모든 호출을 검증하고 오류가 모델을 가르치게 하기

모든 도구 호출을 서버 측에서 검증하고, 해결책을 담은 오류를 반환하세요. Martin Fowler의 함수 콜링 글은 단도직입적으로 말합니다. 모델의 출력을 절대 믿지 마세요. 모델은 enum이 들어갈 자리에 문자열을 넘기고 존재하지 않는 ID를 지어냅니다.

def create_ticket(args):
    if args.get("priority") not in {"low", "medium", "high"}:
        return {"error": f"priority must be one of: low, medium, high. Got '{args.get('priority')}'. Pass priority='medium' for normal issues."}
    if not is_valid_uuid(args.get("assignee_id")):
        return {"error": "assignee_id must be a UUID. Call list_team_members to get valid IDs, then retry."}
    return db.create_ticket(**args)

오류 문자열이 전부입니다. 비교해 보세요:

# Unhelpful: the model retries the same bad call
{"error": "invalid input"}

# Helpful: the model knows exactly what to change
{"error": "priority must be one of: low, medium, high. Got 'urgent'. Use 'high'."}

도구가 반환하는 모든 검증 오류는 모델의 다음 시도를 위해 여러분이 작성하는 프롬프트입니다. 제약 조건을 이름으로 밝히고 교정 도구를 가리키는 오류는 재시도 루프를 한 번에 회복시키는 지시로 바꿉니다. 이는 또한 첫 번째 보안 방어선이기도 합니다. LLM 가드레일 가이드에서 깊이 다룹니다.

4단계: 어떻게 안전하게 만들고, 그다음 측정 가능하게 만들까?

안전과 측정은 같은 단계입니다. 게이트 없는 파괴적 동작과 측정하지 않은 회귀 모두, 미리 보지 못한 장애로 나타나기 때문입니다. 되돌릴 수 없는 동작에 게이트를 둔 뒤, 모든 것을 계측해 다음 도구 변경이 희망이 아니라 근거를 갖춘 결정이 되게 하세요.

실천법 7: 파괴적 동작은 사람 뒤에 게이트 두기

읽기 도구와 쓰기 도구를 분리하고, 파괴적인 모든 것에 사람 확인 게이트를 두세요. MCP 사양의 도구 어노테이션이 정확히 이를 위해 존재합니다. destructiveHint는 파괴적 업데이트를 수행하는 도구를 표시하고, openWorldHint는 외부 시스템에 닿는 도구를 표시해 클라이언트가 실행 전에 확인을 요청할 수 있게 합니다. 이걸 쓰세요.

이 실패 모드는 가상이 아닙니다. Laurent Kubaski는 2025년 7월 툴 콜링 글에서 원본 보고서를 링크하며 한 사례를 기록했습니다. 사용자가 Excel의 Copilot에게 4행을 처리하라고 요청했는데 에이전트가 대신 8행을 처리한 경우입니다. 잘못된 행과 쓰기 사이에 확인 게이트는 없었습니다. 해결책은 AWS가 Bedrock Agents에 대해 문서화한 패턴입니다. 에이전트가 동작을 준비하고, 승인을 위해 반환하고, 사람이 확인한 후에만 실행합니다. Cursor도 파일 편집에 같은 방식을 씁니다. 읽기만으로 충분한 작업에서는 자격 증명을 읽기 전용으로 제한하고, 확인 게이트를 인젝션 표면의 일부로 다루세요. 이 주제는 프롬프트 인젝션 방지 가이드에서 다룹니다.

실천법 8: 도구 변경마다 평가 루프 실행

도구 변경 전후마다 작은 평가 스위트를 실행하고, 지표를 고정된 순서로 읽으세요. Paragon의 최적화 가이드는 채택할 만한 네 가지 지표 체계를 제안합니다.

실제 Slack 및 Asana MCP 평가 위에 구축된 Anthropic의 도구 평가 쿡북은 좋은 평가 작업과 나쁜 평가 작업이 어떻게 생겼는지 보여줍니다.

# Weak: vague, many valid paths, impossible to score
"Use the Asana tools to organize some work."

# Strong: one correct tool, checkable arguments, binary outcome
"Create a task titled 'Renew TLS cert' in project 'Infra' assigned to [email protected], due 2026-08-15. Expect exactly one create_task call with those four fields."

저희의 해석임을 분명히 밝힙니다. 공개된 수치는 작업 순서를 알려줍니다. 먼저 도구 정확성을 확인하세요. Anthropic의 자체 측정 결과가 설명과 이름 변경이 이를 직접 움직인다고 보여주기 때문입니다(206에서 72토큰으로의 재작성, UUID에서 이름으로의 환각 발견). 작업 효율은 마지막에 두세요. 대부분 앞의 세 지표가 이미 잡아낸 실패를 반영하기 때문입니다. 시작용 스위트로는 15~30개 작업을 설계하세요. 도구당 두세 개씩, 각각 단일 기대 호출과 이진 통과 조건을 둡니다. 그 정도 규모면 일주일간의 라벨링 없이도 설명 재작성으로 인한 회귀를 잡기에 충분하며, 저희는 쿡북의 Slack·Asana 구성을 이렇게 작은 스위트가 의도된 시작점이지 지름길이 아니라는 증거로 읽습니다. 더 깊은 메커니즘은 프로덕션 AI 에이전트 평가 가이드에 있고, 평가 결과가 도구 자체는 괜찮지만 오케스트레이션이 문제라고 말한다면, 그때 최고의 AI 에이전트 프레임워크와 비교해 프레임워크 선택을 다시 검토할 때입니다.

에이전트 툴 콜링 vs MCP: 차이는 무엇일까?

MCP는 전송 및 레지스트리 표준이지 신뢰성 계층이 아니므로, 도구가 MCP로 도달하든 인라인으로 정의되든 같은 여덟 가지 실천법이 적용됩니다. 네이티브 툴 콜링은 모델 프로바이더 계약입니다. 모델이 tool_call을 내보내고 tool_result을 읽는 방식이죠. MCP는 도구가 모델에 도달하는 방식을 표준화하지만, 모델이 올바른 도구를 고르는지에 대해서는 아무것도 하지 않습니다.

search라는 이름에 "searches things"라는 설명을 단 도구를 노출하는 MCP 서버는, 같은 방식으로 정의된 인라인 함수와 똑같이 실패합니다. 정의를 먼저 고치고, 그다음 전송을 걱정하세요. Model Context Protocol 가이드가 프로토콜 측면을 처음부터 끝까지 다룹니다.

Techsy는 이 여덟 가지 실천법을 어떻게 적용하는가

모든 클라이언트 에이전트 빌드에서 저희는 다른 것이 출시되기 전에 이 중 세 가지를 강제합니다. 지시로 작성된 설명(실천법 1), 모든 쓰기 도구에 검증 게이트(실천법 6), 그리고 장애 이후가 아니라 배포 전에 실행되는 평가 스위트(실천법 8)입니다. 이 세 가지는 잘못된 도구 호출, 잘못된 인자 호출, 그리고 둘을 다시 불러오는 회귀를 덮으며, 저희가 디버깅한 모든 프로덕션 에이전트 장애는 여기서 시작됐습니다. 나머지 다섯 가지 실천법은 에이전트가 성장하면서 따라옵니다. 에이전트가 데모 단계를 지나 잘못된 도구를 고르고 있다면, 무료 상담을 받으세요. 여덟 가지 중 무엇을 먼저 고쳐야 할지 알려드리겠습니다.

저자 소개

Mert Batur는 Techsy.io의 공동 창업자로, 팀은 B2B 클라이언트를 위한 AI 에이전트, 자동화 시스템, 음성/SDR 파이프라인을 출시합니다. 그는 Techsy 팀이 프로덕션에서 실제로 사용하는 LLM 툴링 스택에 대해 씁니다. LinkedIn에서 연결하세요.

자주 묻는 질문

에이전트 툴 콜링이란 무엇인가?

에이전트 툴 콜링은 LLM이 외부 함수 호출을 결정하고, 구조화된 tool_call을 내보내고, 여러분의 코드가 추론에 쓸 tool_result를 반환하기를 기다리는 메커니즘입니다. 채팅 모델을 데이터베이스 조회, API 호출, 동작 수행이 가능한 에이전트로 바꾸는 것이 바로 이것입니다. 모델이 도구와 인자를 고르면, 여러분의 실행기가 그것을 실행합니다.

에이전트 툴 콜링 루프는 어떻게 동작하나?

루프는 다섯 단계입니다. 사용자 요청이 모델에 도달하고, 모델이 도구를 골라 tool_call을 작성하고, 여러분의 실행기가 그것을 실행하고, tool_result가 모델로 돌아오고, 모델은 답변하거나 다른 호출을 발행합니다. 이 주기는 작업이 끝날 때까지 반복됩니다. 이 가이드의 네 가지 실패 모드는 각각 이 루프의 특정 단계에 자리합니다.

왜 내 에이전트는 잘못된 도구를 고르나?

보통 두 도구가 겹치는데 설명이 어느 것이 어느 것인지 말하지 않기 때문입니다. 모델은 이름과 설명만으로 선택하므로, "gets a user"와 "finds users"는 서로 바뀌어 읽힙니다. 제외 문구("검색에 쓰지 말 것"), 네임스페이스가 있는 이름, 콘텍스트 내 도구 수 줄이기로 고치세요. Kubaski의 네 모델 테스트는 강력한 모델조차 모호한 목록에서는 잘못 라우팅함을 보여줬습니다.

툴 콜링 에이전트가 출력을 구조화하게 강제하려면?

프롬프트가 아니라 스키마를 제약하세요. 한정된 필드에는 enum을, 작업에 필요한 모든 것에는 required 배열을, 중첩 객체보다 납작한 객체를 쓰세요. 도구 호출이 아니라 최종 답변에는 OpenAI의 structured outputs나 Anthropic의 tool-choice 모드 같은 프로바이더 기능이 특정 형태를 강제합니다. 구조화된 출력 가이드가 두 경로 모두를 코드로 다룹니다.

에이전트 툴 콜링 vs MCP: 차이는 무엇인가?

네이티브 툴 콜링은 여러분의 코드와 하나의 모델 프로바이더 사이의 계약입니다. tool_call과 tool_result 메시지 형식이죠. MCP는 도구가 발견되어 호환되는 모든 클라이언트에 전달되는 방식을 표준화하는 프로토콜 계층입니다. MCP는 배관을 바꾸지 신뢰성을 바꾸지 않습니다. 설명이 나쁜 도구는 어느 경로로든 같은 방식으로 실패합니다. Model Context Protocol 가이드가 이를 설명합니다.

LLM 에이전트에 도구는 몇 개부터 너무 많나?

에이전트당 5~10개를 법칙이 아닌 실무 범위로 보세요. 보이는 목록이 커질수록, 특히 이름이나 설명이 겹칠수록 선택 정확도는 떨어집니다. 해법은 더 큰 모델이 아니라 필터링입니다. 플래너-워커 분할로 현재 작업에 필요한 하위 집합만 로드하세요. 모든 것에 네임스페이스를 부여해 두 통합이 둘 다 맨몸의 search를 노출하지 않게 하세요.

툴 콜링에 가장 좋은 모델은 무엇인가?

단일한 정답은 없으며, 공개된 벤치마크는 이 분야에서 빠르게 낡습니다. OpenAI, Anthropic, Google의 프론티어 모델은 모두 기본 도구 사용 작업을 통과하지만, 잘 설계된 도구와 짝지어진 작은 모델은 토큰 비용의 일부만으로 거의 같은 빈도로 작업을 완료하곤 합니다. 실천법 8의 15~30개 작업 평가 스위트를 만들고, 여러분 자신의 도구로 후보를 테스트하세요.

툴 콜링으로 인한 토큰 비용을 줄이려면?

돌아오는 것을 줄이세요. 원시 API 페이로드 대신 간결하고 신호가 높은 결과를 반환하세요. Anthropic은 response_format 변경 하나로 206에서 72토큰으로 줄인 사례를 기록했습니다. UUID를 이름으로 해석하고, 모델이 절대 쓰지 않는 필드를 버리고, 모든 도구 결과가 이후 모든 턴에서 콘텍스트 윈도우에 다시 들어간다는 점을 기억하세요. 원자적 도구로 호출 수를 줄이면 결과 전체가 청구서에서 사라집니다.

툴 콜링 품질은 어떻게 평가하나?

네 가지 지표를 순서대로 채점하세요. 도구 정확성(올바른 도구?), 입력 정확도(유효한 인자?), 작업 완료(목표 달성?), 작업 효율(토큰 수와 호출 수?)입니다. 15~30개 작업을 작성하고, 각각 검증 가능한 인자를 가진 단일 특정 호출과 이진 통과 조건을 기대하게 하세요. 도구 변경 전후마다 스위트를 실행해 설명 재작성이 측정 없이 출시되지 않게 하세요.

결론

최적화 전에 진단하세요. 에이전트는 네 가지 이유 중 하나로 잘못된 도구를 고르며, 위 여덟 가지 실천법 중 세 가지, 즉 설명, 납작한 스키마, 필터링이 대부분의 프로덕션 장애를 일으키는 선택 실패를 고칩니다. 거기부터 시작하세요. 오후 반나절이면 되고, 이 문제가 애초에 고칠 수 있는 이유이기 때문입니다. 검증 오류는 유익하게 유지하고, 파괴적인 것은 무엇이든 사람 뒤에 게이트를 두고, 변경마다 평가 루프를 실행해 모델을 바꾸기 전에 측정하세요. 잘못된 도구 문제는 모델 문제가 아닙니다. 도구 설계 문제이며, 설계는 여러분의 손에 있습니다.