도구 선택 오류는 언제 파인튜닝 문제가 될까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 에이전트가 비슷한 도구 중 자꾸 엉뚱한 것을 고른다면, 프롬프트를 더 길게 써야 할까 아니면 작은 모델을 파인튜닝해야 할까?
• 핵심 출처:
  • A Guide to Fine-Tuning FunctionGemma - 게시일 2026-01-16, 확인일 2026-06-14
  • Fine-tuning with FunctionGemma - 게시일 미표기, 확인일 2026-06-14
  • Supervised fine-tuning | OpenAI API - 게시일 미표기, 확인일 2026-06-14
  • Function calling | OpenAI API - 게시일 미표기, 확인일 2026-06-14
  • Tool use with Claude - 게시일 미표기, 확인일 2026-06-14

1. 왜 지금 봐야 하나

최근 에이전트 개발에서 “도구를 붙인다”는 일은 점점 쉬워지고 있다. JSON Schema로 함수 인자를 정의하고, strict: true로 형식 오류를 줄이고, 도구가 많아지면 tool search로 필요한 도구만 뒤늦게 불러올 수도 있다. 그래서 겉으로는 문제가 해결된 것처럼 보인다.

하지만 실제 운영에서 자주 남는 실패가 하나 있다. 형식은 맞는데, 도구 선택이 틀리는 문제다.

예를 들어 사용자가 “출장 식비 한도가 얼마야?”라고 물었다고 하자. 모델은 search_google을 호출할 수도 있고, search_knowledge_base를 호출할 수도 있다. 둘 다 검색 도구이고, 인자도 {query: string}으로 비슷하다. 그런데 회사 서비스라면 정답은 보통 내부 지식베이스다. 이 차이는 JSON Schema만으로는 잘 드러나지 않는다. “어떤 도구를 쓸 수 있는가”가 아니라 “우리 조직에서는 어떤 상황에 어떤 도구를 먼저 써야 하는가”의 문제이기 때문이다.

Google의 FunctionGemma 자료가 흥미로운 이유가 여기에 있다. FunctionGemma는 Gemma 3 270M 기반의 작은 function-calling 모델인데, Google은 이 모델을 다시 파인튜닝해 내부 지식베이스 검색과 공개 웹 검색 사이의 선택 모호성을 줄이는 예제를 공개했다. OpenAI 문서도 SFT를 하기 전에 eval을 먼저 만들라고 강조하고, function calling 문서는 함수 정의가 컨텍스트와 비용을 차지하며 많은 함수나 어려운 작업에서는 fine-tuning을 고려할 수 있다고 설명한다.

오늘 볼 핵심은 “파인튜닝이 멋있다”가 아니다. 도구 호출 실패를 스키마 문제, 검색 문제, 정책 문제, 학습 문제로 나눠 보는 기준이다.

2. 핵심 개념

도구 호출에는 적어도 세 가지 능력이 섞여 있다.

첫째, 문법 능력이다. 모델이 올바른 JSON을 만들고, 필수 인자를 빠뜨리지 않고, enum 값을 맞추는 능력이다. 이 문제는 structured outputs, strict tool use, validation, retry로 상당 부분 다룰 수 있다.

둘째, 도구 발견 능력이다. 수십 개 또는 수백 개의 도구 중 현재 요청과 관련 있는 도구를 찾는 능력이다. 이 문제는 도구 이름과 설명을 정리하고, namespace를 나누고, tool search나 deferred loading을 쓰면 좋아질 수 있다.

셋째, 정책 판단 능력이다. 여러 도구가 모두 그럴듯할 때, 조직의 규칙과 제품 의도에 맞는 도구를 고르는 능력이다. “외부 검색보다 내부 규정을 먼저 본다”, “환불 금액이 일정 기준을 넘으면 자동 처리하지 않는다”, “개인정보가 포함된 질문은 로컬 분류기를 먼저 거친다” 같은 판단이다. 이 문제는 프롬프트만 길게 쓴다고 항상 안정화되지 않는다.

FunctionGemma 문서는 이 차이를 “도구를 어떻게 쓰는지에 대한 기계적 지식”과 “왜, 언제 그 도구를 써야 하는지에 대한 의도 판단”으로 나눈다. 작은 모델일수록 두 번째 능력이 약할 수 있고, 특정 조직의 정책은 공개 데이터에 없기 때문에 예시 기반 학습이 도움이 될 수 있다.

여기서 파인튜닝은 모델에게 새 지식을 주입하는 만능 수단이 아니다. 더 정확히는 반복되는 입력 패턴과 기대 행동의 매핑을 모델의 기본 습관으로 바꾸는 방법이다. RAG가 최신 문서를 가져오는 일에 가깝다면, SFT는 “이런 요청에서는 이런 형식과 이런 도구 선택을 선호하라”는 행동 경향을 바꾸는 일에 가깝다.

3. 최신 이슈와 연결

Google Developers Blog의 FunctionGemma 글은 2026년 1월에 작은 function-calling 모델을 특정 도구 선택 정책에 맞게 다시 훈련하는 흐름을 보여준다. 예제는 단순하다. search_knowledge_base와 search_google이라는 두 도구가 있고, 모델은 질문이 내부 정책·프로젝트·절차에 관한 것인지, 아니면 공개 지식에 관한 것인지 구분해야 한다.

Google AI for Developers 가이드는 같은 주제를 더 실습적으로 풀어낸다. 예제 데이터셋은 40개의 합성 샘플로 구성되고, 데모에서는 50% 학습·50% 테스트 분할을 사용한다. 문서에는 기본 모델이 낮은 성공률을 보이다가, 8 epoch SFT 후 테스트 성공률이 개선되는 예시가 나온다. 중요한 점은 숫자 자체가 아니라 평가 방식이다. 보지 않은 데이터에서 도구 선택이 나아졌는지를 확인해야 “정책을 외운 것”과 “패턴을 일반화한 것”을 구분할 수 있다.

OpenAI의 supervised fine-tuning 문서는 더 보수적인 기준을 제시한다. “Good evals first”가 핵심이다. 파인튜닝은 최소 10개 예제로 시작할 수 있지만, 보통 50개 안팎의 좋은 데모에서 개선을 보기 시작하며, 개선이 없으면 데이터를 더 넣기보다 task 정의나 프롬프트를 다시 보라고 한다. 또한 function calling 예제처럼 assistant의 tool_calls를 포함한 JSONL 포맷으로 원하는 호출 행동을 학습시킬 수 있음을 보여준다.

OpenAI function calling 문서와 Claude tool use 문서는 파인튜닝 전에 해야 할 기본기를 함께 알려준다. 함수 이름, 설명, schema, tool_choice, strict mode, namespace, 도구 개수 제한, 실행 위치, 결과 반환 루프가 먼저 정리되어야 한다. 이 기본기가 엉망이면 파인튜닝은 문제를 해결하기보다 버그를 모델 안에 굳혀버릴 수 있다.

4. 개발자 관점 해석

실무에서는 “모델이 도구를 틀렸다”는 로그만 보고 바로 파인튜닝으로 가면 위험하다. 먼저 실패를 분류해야 한다.

스키마 실패라면 파인튜닝보다 validation이 먼저다. 필수 필드 누락, 잘못된 enum, 추가 속성 생성, 타입 오류라면 strict: true, JSON Schema 단순화, 서버 측 validator, 재시도 정책이 더 직접적이다.

설명 실패라면 도구 문서가 먼저다. search, lookup, find처럼 이름이 모호하거나 설명이 “search things” 수준이면 모델이 맞히기 어렵다. 이 경우 도구 이름을 search_internal_policy처럼 바꾸고, 설명에 “사내 규정, HR, 비용 처리, 프로젝트 문서” 같은 trigger boundary를 적는 편이 낫다.

컨텍스트 실패라면 tool search나 도구 표면 관리가 먼저다. 모델에게 한 번에 200개 도구를 넣고 “알아서 골라”라고 하면 선택 오류가 늘어난다. 최근 글에서 다룬 것처럼 필요한 도구만 검색해 로드하거나, namespace별로 분리해야 한다.

정책 실패라면 파인튜닝 후보가 된다. 도구 이름과 설명이 이미 명확하고, eval에서도 같은 유형의 모호성이 반복되며, 프롬프트를 길게 써도 회귀가 잦다면 행동 학습을 검토할 수 있다. 예를 들어 “사내 정책 질문은 내부 KB를 먼저 검색한다”, “고객 환불은 order 상태 확인 후 refund preview를 먼저 호출한다”, “민감 정보 분류 전에는 외부 검색을 하지 않는다” 같은 규칙은 도구 선택의 습관으로 학습시킬 가치가 있다.

다만 파인튜닝에는 실패 모드도 있다. 데이터가 작고 편향되어 있으면 모델이 특정 문구에만 반응한다. train/test split이 잘못되면 실제로는 한쪽 도구만 학습하고 다른 도구는 테스트에서 처음 보게 된다. 합성 데이터가 너무 깨끗하면 운영 로그의 애매한 표현, 오타, 다국어 입력, 생략된 맥락에 약하다. 또한 도구 정책이 자주 바뀌는 조직이라면 모델 재훈련보다 prompt policy와 runtime rule이 더 관리하기 쉽다.

즉 파인튜닝은 마지막 카드가 아니라, 반복 가능하게 측정된 행동 실패에 쓰는 좁은 카드다.

5. 내 프로젝트에 적용할 체크포인트

아래 질문에 “예”가 많을수록 파인튜닝 검토 가치가 커진다.

1. 같은 유형의 도구 선택 오류가 운영 로그에서 반복되는가?
2. schema validation은 통과하지만, 선택한 도구의 도메인이 틀리는가?
3. 도구 이름과 설명을 명확히 바꿔도 개선이 제한적인가?
4. tool search나 namespace 분리로 후보 도구를 줄였는데도 모호성이 남는가?
5. 정답 도구를 판단하는 기준이 최신 지식보다 조직 정책·업무 절차에 가까운가?
6. 학습용으로 쓸 수 있는 실제 요청, 정답 도구, 정답 인자 로그가 있는가?
7. 파인튜닝 전후를 비교할 고정 eval set이 있는가?
8. 정책 변경 시 모델 재훈련 또는 adapter 교체를 운영할 수 있는가?

반대로 아래 상황이면 파인튜닝보다 다른 방법이 먼저다.

• 필드 누락과 JSON 오류가 주요 문제다 → strict schema, validator, retry
• 도구 설명이 모호하다 → 이름, 설명, 예제 정리
• 도구가 너무 많다 → tool search, namespace, deferred loading
• 지식이 자주 바뀐다 → RAG, 내부 문서 검색, 정책 파일
• 위험 액션이 문제다 → 권한, 승인, 감사 로그, allow/deny rule

작은 팀이라면 바로 모델을 훈련하기보다 “도구 선택 eval”부터 만드는 것이 좋다. CSV 한 장이면 충분하다. user_input, expected_tool, expected_args, risk_level, reason 정도만 있어도 baseline을 잴 수 있다.

6. 오늘 10분 액션

오늘은 코드를 많이 쓰지 말고, 내 에이전트의 도구 선택 실패를 10분만 분류해보자.

1. 최근 실패 로그 10개를 고른다.
2. 각 로그에 실패 유형을 붙인다: schema, description, too_many_tools, policy, permission, unknown.
3. policy로 분류한 것만 따로 모은다.
4. 각 항목에 “정답 도구를 고르는 규칙”을 한 문장으로 적는다.
5. 같은 규칙이 3번 이상 반복되면 eval 후보로 표시한다.

예시 표:

user_input	wrong_tool	expected_tool	failure_type	policy_rule
출장 식비 한도 알려줘	search_google	search_knowledge_base	policy	사내 규정 질문은 내부 KB 우선
주문 취소하고 환불해줘	refund_create	refund_preview	permission	금전 액션은 preview 후 승인
React useEffect 예시 찾아줘	search_knowledge_base	search_google	policy	공개 개발 지식은 외부 검색

이 표가 30~50개 정도 쌓이면 그때야 파인튜닝, few-shot prompt, rule router, tool search 중 무엇이 가장 싼 해결책인지 비교할 수 있다.

7. 더 볼 자료

• Google의 FunctionGemma 글은 작은 function-calling 모델을 특정 업무 정책에 맞추는 감각을 잡기 좋다.
• Google AI for Developers의 실습 문서는 데이터 분할, SFTTrainer, 테스트 성공률 비교를 확인하기 좋다.
• OpenAI supervised fine-tuning 문서는 “eval 먼저, 데이터는 현실적으로, 개선 없으면 task를 다시 보라”는 운영 기준을 준다.
• OpenAI function calling 문서는 strict mode, tool search, tool definition 비용, fine-tuning 고려 지점을 함께 보여준다.
• Claude tool use 문서는 tool_choice, client/server tool, 설명 기반 trigger boundary를 이해하는 데 유용하다.

중복 회피 메모

로컬 content/generated와 Supabase의 최근 ai_dev 글을 확인했다. 최근 글은 긴 컨텍스트 메모리, 에이전트 권한 계약, prefill/decode 지연, RAG 검색 품질, Tool Search 기반 도구 표면 관리, KV 캐시 양자화를 다뤘다. 이번 글은 도구 개수를 줄이는 문제가 아니라, 스키마와 도구 표면을 정리한 뒤에도 반복되는 도구 선택 정책 오류를 SFT·FunctionGemma·eval 관점에서 언제 파인튜닝 후보로 볼지에 집중한다.