huny.log

기술 포스트 · AI·LLM

Function calling 설계 패턴 — LLM이 도구를 부를 때 마케터가 점검할 것

LLM이 광고 API·BigQuery·Slack을 직접 부르기 시작하면, 답변 품질보다 "어느 도구를 언제 부를지"가 운영 사고의 진앙이 됩니다. function calling의 한 줄 직관과 마케터가 점검할 5가지.

“이 캠페인 ROAS 보여줘”라고 묻자 챗봇이 BigQuery에 SQL을 던져 결과를 돌려줍니다. 마케터 입장에서는 마법 같은 일인데, 그 “마법”의 정체가 function calling입니다. 모델이 직접 데이터를 가져오는 게 아니라, 어느 도구를 어떤 인수로 부를지를 결정해 시스템에 넘기는 한 가지 능력입니다. 이 글은 function calling이 어떻게 동작하고, 운영에서 깨지는 자리, 그리고 마케터가 직접 점검할 5가지 체크포인트를 정리합니다.

마케터가 이 글을 읽어야 하는 이유: LLM 챗봇·에이전트가 사내 데이터에 직접 접근하기 시작하면, “답변이 맞다”보다 “어느 도구를 언제 불렀나”가 운영 사고의 1순위가 됩니다. 잘못된 도구를 부르면 잘못된 데이터로 답하고, 잘못된 인수를 넘기면 다른 캠페인의 데이터가 나옵니다. function calling의 작동 원리를 이해하면 이 사고들을 사전에 막을 수 있습니다.

LLM이 사용자 질문을 받아 도구를 선택하고 인수를 추출해 호출한 뒤 결과를 답변으로 통합하는 4단계 흐름
모델이 답을 만드는 게 아니라, 어느 도구를 어떤 인수로 부를지를 결정한다 — 이게 function calling의 본질.

1. Function calling의 한 줄 직관

전통적 LLM은 한 가지만 합니다 — 토큰 시퀀스 받아 다음 토큰 예측. 이 모델에 외부 도구를 붙이는 표준 방식이 function calling입니다.

모델이 답을 만드는 대신, “어느 도구를 어떤 인수로 부르라”는 구조화된 지시를 출력한다. 실제 실행은 호스트 시스템이 한다.

작동 흐름을 4단계로 쪼개면:

  1. 의도 파악 — 사용자 질문 의미 해석 (“이 캠페인 ROAS 알려줘” → 데이터 조회 의도)
  2. 도구 선택 — 등록된 도구 목록 중 적합한 것 결정 (get_campaign_roas)
  3. 인수 추출 — 함수 시그니처에 맞춰 JSON 인수 생성 ({"campaign_id": "M2026Q2-display"})
  4. 응답 통합 — 호스트가 실행한 결과를 받아 자연어로 답변 합성

각 단계가 모두 모델 출력에서 나옵니다. 의도 파악과 인수 추출은 attention이 텍스트를 풀어가는 과정이고, 도구 선택은 등록된 함수 schema와의 매칭입니다. 잘 이해하면 LLM이 마케팅 데이터·SaaS API·내부 시스템을 자연어로 조작할 수 있는 인터페이스가 됩니다.

2. 마케팅 자리에 흔한 5가지 도구

function calling은 추상적 기술이 아니라 마케팅 운영의 구체적 자리에 들어옵니다. 자주 등장하는 도구 패턴은 다음 5가지입니다.

도구 카테고리예시위험 자리
데이터 조회get_campaign_roas, query_bigquery잘못된 캠페인 ID·기간 추출
보고 생성generate_weekly_report, export_to_pdf형식 일관성·접근권한
액션 실행pause_campaign, update_budget의도 오해석으로 운영 중 캠페인 정지
외부 검색search_competitor, lookup_creative_db외부 API rate limit·환각
사내 알림send_slack, notify_oncall잘못된 채널·잘못된 사람 멘션

위험 자리에 공통으로 들어가는 단어가 “잘못된”입니다. 모델이 의도를 잘못 해석하거나 인수를 잘못 추출하면, 자연어 인터페이스의 편의가 그대로 운영 사고로 연결됩니다.

3. 도구 schema 설계의 작은 디테일

모델이 도구를 잘 부르려면 함수 schema가 잘 쓰여 있어야 합니다. 같은 도구라도 schema 한 줄 차이로 호출 정확도가 크게 달라집니다.

3-1. 이름이 의도를 담아야 한다

get_data 같은 모호한 이름은 모델이 어느 자리에 부를지 헷갈립니다. get_campaign_roas_by_id처럼 입력·출력·범위가 한 번에 보이는 이름이 호출 정확도가 높습니다.

3-2. description은 “언제 부르는가”를 명시

좋은 description은 함수가 무엇을 하는지가 아니라 언제 부르고 언제 안 부르는지를 적습니다. “분기·월·주 단위 캠페인 ROAS를 조회. campaign_id가 명확할 때만 사용. 캠페인 이름으로 조회해야 한다면 lookup_campaign_by_name을 먼저 부를 것”처럼 호출 조건과 선후 관계가 들어가야 모델이 도구 선택에서 헤매지 않습니다.

3-3. 인수에 enum과 default를 적극 사용

enum이 있으면 모델은 그 값들 중 하나만 선택하므로 임의 문자열로 인한 오류가 사라집니다. 예를 들어 기간 인수가 ["last_week", "last_month", "last_quarter", "ytd"] 네 값 중 하나로 제한되면, 사용자가 “지난 분기”라고 말했을 때 모델이 last_quarter로 정확히 매핑합니다. 자유 문자열로 두면 Q1 2025Q1 1분기 같은 다양한 표기로 깨집니다. default까지 있으면 사용자가 기간을 명시하지 않을 때 모델이 추측하지 않고 안전한 기본값을 씁니다.

4. 의도 오해석이 일어나는 자리

function calling의 사고 대부분은 모델이 도구를 “부른다 vs 안 부른다”의 경계에서 일어납니다.

4-1. 부를 도구가 없는데 억지로 부르는 케이스

사용자가 “지난 분기 분위기 어땠어?”처럼 모호한 질문을 하면, 모델이 적절한 도구가 없는데도 get_campaign_roas 같은 가까운 도구를 일단 호출합니다. 결과는 잘못된 컨텍스트를 깔고 환각이 시작됩니다. 방어책은 시스템 프롬프트에 “확신이 없으면 도구를 부르지 말고 사용자에게 명확화 질문을 하라”는 룰 명시입니다.

4-2. 도구는 맞는데 인수가 틀린 케이스

“이번 분기 ROAS”라고 했을 때 모델이 period: "last_quarter"로 부를지 period: "ytd"로 부를지 헷갈립니다. enum 값에 대한 description(“이번 분기는 last_quarter 아님, 현재 진행 중 분기는 별도 도구 사용”)을 붙이면 줄어듭니다.

4-3. 도구를 안 불러야 하는데 부르는 케이스

“우리 캠페인 ROAS는 보통 어느 정도가 좋아?”는 일반론 질문입니다. 도구를 부르지 않고 일반 답변을 해야 하는데, 모델이 “이 회사 데이터를 봐야 한다”고 오해하고 도구를 호출합니다. 시스템 프롬프트에 “일반론 질문은 도구 호출 없이 답한다” 명시 + few-shot 예시로 분리합니다.

5. 모델 출력 한 묶음 — 코드 예시 한 개

모델이 어떻게 도구 호출을 출력하는지 한 번만 보여드립니다. 이게 글에 박는 유일한 코드입니다.

import openai
client = openai.OpenAI()
tools = [{
"type": "function",
"function": {
"name": "get_campaign_roas",
"description": "분기·월·주 단위 캠페인 ROAS 조회. campaign_id가 명확할 때만 사용.",
"parameters": {
"type": "object",
"properties": {
"campaign_id": {"type": "string"},
"period": {"type": "string",
"enum": ["last_week", "last_month", "last_quarter"]},
},
"required": ["campaign_id"],
},
},
}]
resp = client.chat.completions.create(
model="gpt-5",
messages=[{"role": "user", "content": "M2026Q2-display 지난달 ROAS 알려줘"}],
tools=tools,
)
print(resp.choices[0].message.tool_calls[0].function)
# Function(name='get_campaign_roas',
# arguments='{"campaign_id":"M2026Q2-display","period":"last_month"}')

호스트가 이 출력을 받아 실제 함수를 호출하고, 결과를 다시 messages에 추가해 모델에게 자연어 답변을 만들게 합니다. 모델은 답을 만들지 않고 “어떻게 부를지”만 결정한다는 게 한 번에 보입니다.

6. 마케터가 점검할 5가지

function calling을 쓰는 챗봇·에이전트가 운영에 들어와 있다면 다음 5가지를 분기에 한 번씩 점검합니다.

6-1. 도구 호출 로그가 쌓이는가

도구 호출 한 번이 한 줄 로그로 저장되어야 합니다. 어느 시점에 어느 도구를 어떤 인수로 불렀는지의 흔적이 없으면, 사고가 났을 때 원인 추적이 불가능합니다. 최소 90일 보관 권장.

6-2. 호출 정확도(tool selection accuracy)

골든셋 50개 질문에 대해 “어느 도구를 부르는 게 정답인가”를 사람이 라벨링하고, 모델 출력과 비교해 정확도를 매주 모니터링합니다. 80% 이하로 떨어지면 schema·시스템 프롬프트 점검.

6-3. 인수 정확도(arguments accuracy)

도구는 맞게 골랐는데 인수가 틀린 비율을 별도로 추적합니다. enum 미사용·description 부족이 원인일 때가 많습니다.

6-4. 액션 도구의 confirm rate

pause_campaign 같은 액션 도구가 호출되기 전 사용자가 “예/아니오”로 확인한 비율. 이 게이트가 없으면 한 번의 자연어 오해석으로 캠페인이 멈춥니다.

6-5. 사용자 피드백 루프

답변 끝에 👍/👎 한 번만 있으면 됩니다. 👎가 모이는 패턴을 한 달에 한 번 검토하면 자주 깨지는 도구 호출이 한눈에 보입니다.

7. 다중 도구 호출 — 에이전트로 가는 길

function calling이 한 번에 여러 도구를 호출하면서 문제 해결까지 가는 흐름이 다중 도구 호출(multi-tool calling) 또는 ReAct 패턴입니다.

사용자: “지난 분기 ROAS 가장 높았던 캠페인 슬랙 공유해줘”

모델 1: get_top_campaign(period="last_quarter") 호출 시스템: 결과 반환 — campaign_id=“M2026Q1-search” 모델 2: get_campaign_roas(campaign_id="M2026Q1-search", period="last_quarter") 호출 시스템: 결과 반환 — ROAS 4.2 모델 3: send_slack(channel="#marketing", text="Q1 1위 캠페인은 M2026Q1-search, ROAS 4.2") 호출 모델 4: 자연어 답변 — “공유 완료했어요”

각 단계마다 모델이 도구를 부르고, 결과를 받아 다음 도구를 부릅니다. 이게 ai-agent의 골격입니다. 사고가 자주 일어나는 자리는 단계 간 결과 전달 — 한 도구의 출력이 다음 도구의 입력으로 흘러가는 자리입니다.

다중 호출의 운영 원칙:

  • 한 사용자 요청 안의 도구 호출을 최대 5-7개로 제한 (loop 방지)
  • 각 단계의 입력·출력을 로그로 남김
  • 액션 도구는 마지막에만, 데이터 조회는 앞쪽
  • 동일 도구 동일 인수 반복 호출 시 자동 차단

ai-agent 평가 전반은 LLM 에이전트 평가에서 더 깊이 다룹니다.

8. 마치며 — 자연어 인터페이스의 운영 책임

function calling은 LLM에 도구를 붙이는 단순한 기술 기능이 아닙니다. 자연어로 회사 시스템을 조작하게 하는 새로운 인터페이스이고, 그 만큼 새로운 운영 책임이 따릅니다. 모델이 답을 만들지 않고 “어떻게 부를지”만 결정한다는 직관 한 줄을 잡고, schema 한 줄을 다듬고, 5가지 체크포인트를 분기에 한 번씩 검토하면 사고를 사전에 막을 수 있습니다.

다음 분기에 한 번만 시도해 볼 만한 것은 사내 챗봇의 도구 호출 로그를 100건만 샘플링해 사람이 라벨링하는 흐름입니다. 의외로 사고의 절반이 description 한 줄 보강으로 사라진다는 걸 자주 확인하게 됩니다.

다음에 읽을 글

  • LLM 에이전트 평가 — 다중 도구 호출 에이전트의 평가 프레임워크
  • LLM 환각 — 도구를 부르지 않고 답할 때 모델이 환각하는 자리
  • 트랜스포머 직관 — function calling의 의도 파악·인수 추출이 attention의 무엇으로 작동하는지

참고

AI·LLM 카테고리의 다른 글

전체 보기 →