Function Calling 정확도를 높이는 스키마 설계

Function Calling에서 스키마 설계가 중요한 이유

거대언어모델(LLM) 기반의 AI 자동화 파이프라인에서 펑션 콜링(Function Calling 또는 Tool Calling)은 인공지능이 외부 시스템과 상호작용하는 핵심 통로입니다. 모델은 제공된 함수의 이름과 명세서(스키마)를 해석하여 어떤 함수를 실행할지, 그리고 어떤 인자값(Argument)을 채워 넣을지 결정합니다.

모델은 코드나 엄격한 규칙이 아니라 자연어 프롬프트와 정의된 텍스트 스키마를 읽고 추론을 수행합니다. 스키마가 모호하거나 복잡하면 인자값 누락, 잘못된 데이터 타입 지정, 존재하지 않는 매개변수를 지어내는 할루시네이션(환각 현상)이 빈번하게 발생하여 자동화 파이프라인이 중단됩니다. 펑션 콜링의 정확도를 결정짓는 가장 강력한 요인은 모델의 체급보다 ‘얼마나 명확하고 구체적으로 스키마를 설계했는가’에 달려 있습니다.

정확도를 극대화하는 JSON 스키마 설계 원칙

모델이 헷갈리지 않고 단 한 번에 정확한 형태의 JSON 구조를 출력하도록 유도하는 필수적인 스키마 작성 규칙이 존재합니다.

1. 동사 중심의 명확한 함수명과 기능 기술

함수의 이름(name)과 설명(description)은 모델이 이 도구를 선택해야 할지 판단하는 첫 번째 기준입니다.

• 불량 예시: func1, data_process, manage_user와 같이 추상적이거나 명사로만 나열된 이름은 모델의 오선택을 유발합니다.
• 모범 예시: fetch_user_purchase_history, update_order_delivery_status처럼 행위의 목적과 대상이 명확한 동사 형태의 스키마 명명법을 고수해야 합니다. 설명란에도 이 함수가 구체적으로 무엇을 반환하고 어느 시점에 구동되어야 하는지 명확히 한정해 주어야 합니다.

2. 매개변수 설명에 구체적인 제약 조건(Constraints) 명시

인자값의 이름만 적어두면 모델은 컨텍스트를 분석하다가 엉뚱한 값을 밀어 넣기 쉽습니다. 매개변수 설명란(description)에 데이터의 형식, 단위, 허용 범위를 명확히 규정해야 합니다.

• 포맷 제약: 날짜 데이터를 인자로 유도할 경우 단순 date라고 적기보다 YYYY-MM-DD 형식의 문자열로 정확히 지정합니다.
• 단위 제약: 금액이나 수치 데이터의 경우 원화(KRW) 기준의 정수형, 초(Second) 단위의 숫자와 같이 단위를 명기해야 모델이 단위를 오인하여 계산 착오를 일으키는 현상을 막을 수 있습니다.

3. Enum(열거형) 상수를 활용한 값의 범위 제한

인자값으로 들어올 수 있는 후보군이 정형화되어 있다면 반드시 enum 속성을 활용해 선택지를 좁혀주어야 합니다.

• 예를 들어 국가 코드를 받는 인자라면 자유롭게 텍스트를 적도록 방치하지 말고 ["KR", "US", "JP", "CN"]과 같이 유효한 상수 배열을 스키마에 정의합니다. 모델이 가상의 문자열을 창조해 내는 파라미터 할루시네이션을 원천적으로 차단하는 가장 효과적인 방법입니다.

펑션 콜링 오류를 차단하는 고급 스키마 기법

기본적인 JSON 작성법을 넘어, 복잡한 비즈니스 조건 속에서도 시스템이 강건하게 작동하도록 돕는 아키텍처적 기법들입니다.

1. Strict Mode 및 구조화된 출력(Structured Outputs) 활성화
   • 최신 AI API들이 지원하는 strict: true 옵션을 스키마 정의에 적극 반영해야 합니다. 이 옵션을 켜면 모델은 개발자가 지정한 JSON 스키마 규격을 100% 준수하는 제약 조건 아래에서만 토큰을 생성하므로, 필수 인자가 누락되거나 데이터 타입이 꼬이는 문법 오류를 완벽하게 방지할 수 있습니다.
2. 필수 매개변수(Required Fields)의 최소화 및 분리
   • 하나의 함수 안에 너무 많은 required 인자를 지정하면 모델은 필요한 정보를 컨텍스트 내에서 찾지 못했을 때 가짜 데이터를 채워 넣는 부작용을 보입니다. 필수 인자는 꼭 필요한 식별자(ID 등)로 최소화하고, 나머지 부가 정보는 선택(Optional) 항목으로 돌리거나 함수를 여러 개로 쪼개는 분할 설계가 안전합니다.
3. 스키마 복잡도 통제와 상호 배제
   • 한 파이프라인에 10개 이상의 너무 많은 함수 스키마를 동시에 주입하면 모델의 주의력이 분산되어 정확도가 급감합니다. 기능이 유사한 함수들은 통합하고, 역할이 겹치지 않도록 스키마 간의 경계를 명확히 분리하여 모델이 선택 장애를 겪지 않도록 조율해야 합니다.

실무적인 스키마 설계 구조 표준 예시

실제 기업용 주문 관리 자동화 시스템에서 오작동 없이 완벽하게 구동되는 표준적인 스키마 설계의 구조적 예시를 확인할 수 있습니다.

{
  "name": "cancel_pending_order",
  "description": "사용자가 요청한 주문 건에 대해 결제가 완료되기 전 대기 상태(pending)인 주문을 취소 처리합니다. 반드시 주문 번호와 취소 사유가 존재할 때만 호출해야 합니다.",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "알파벳 'ORD'로 시작하고 뒤이어 8자리 숫자로 구성된 고유 주문 식별 번호 (예: ORD12345678)"
      },
      "reason_code": {
        "type": "string",
        "enum": ["CUSTOMER_CHANGE", "PRICE_ISSUE", "DELIVERY_DELAY", "SYSTEM_ERROR"],
        "description": "주문을 취소하는 공식 사유 코드. 사용자의 발언 맥락에 맞추어 가장 적합한 코드를 선택해야 합니다."
      },
      "refund_immediately": {
        "type": "boolean",
        "description": "즉시 환불 프로세스를 가동할지 여부. 결제 수단이 무통장 입금인 경우는 false, 신용카드인 경우는 true로 자동 판별합니다."
      }
    },
    "required": ["order_id", "reason_code", "refund_immediately"]
  }
}

스키마 평가 및 최적화 워크플로우

성공적인 펑션 콜링 환경을 구축한 후에도 데이터 변경과 사용자 패턴에 맞추어 스키마를 지속적으로 고도화해야 합니다.

• Few-shot(소수 샘플) 패턴 매칭 결합: 스키마 정의 하단이나 프롬프트 내부에 “이러한 질문이 들어왔을 때는 해당 스키마 형태로 인자값을 채워 호출한다”는 모범적인 펑션 콜링 호출 JSON 샘플을 2개 이상 예시로 포함합니다. 복잡한 다중 조건을 다룰 때 정확도가 비약적으로 상승합니다.
• 실패 로그 기반의 디버깅 루프: 자동화 시스템 운영 중 툴 콜링 실패 에러가 발생하면, 모델이 출력한 잘못된 인자값 패턴을 분석해야 합니다. 특정 인자값에서 계속 에러가 난다면 스키마의 설명(Description) 문구가 모호하다는 증거이므로, 해당 항목에 ‘예외 상황 시 행동 지침’을 추가하여 스키마의 완성도를 촘촘하게 보완해 나갑니다.