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

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

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

모델이 답을 만드는 게 아니라, 어느 도구를 어떤 인수로 부를지를 결정한다 — 이게 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·내부 시스템을 자연어로 조작할 수 있는 인터페이스가 됩니다.

📌 이 글의 전제

독자가 LLM·챗봇·에이전트라는 단어는 일상에서 쓰고, GPT/Claude API를 한 번이라도 들어봤다고 가정합니다. 코드를 직접 짜본 적 없어도 OK이고, "도구를 부른다"는 개념의 의미는 받아들인다고 가정합니다.

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	잘못된 채널·잘못된 사람 멘션

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

⚠️ 액션 도구는 두 단계 게이트

데이터 조회 도구는 잘못 불러도 잘못된 답이 나오고 끝납니다. 하지만 액션 도구(pause_campaign, update_budget)는 잘못 부르면 캠페인이 멈추거나 예산이 바뀝니다. 액션 도구는 반드시 사용자 명시 확인 단계(confirm: true 같은 추가 인수)를 끼워두세요.

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까지 있으면 사용자가 기간을 명시하지 않을 때 모델이 추측하지 않고 안전한 기본값을 씁니다.

💡 schema 한 줄을 다듬는 ROI

모델 교체나 프롬프트 엔지니어링보다 schema 한 줄을 다듬는 게 호출 정확도 개선에 더 빠릅니다. 도구 description을 "언제 부르고 언제 안 부른다"로 다시 쓰는 30분이 모델을 GPT-4o → GPT-5로 교체한 효과보다 클 때가 흔합니다.

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. 모델 출력 한 묶음 — 코드 예시 한 개

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

python