Function calling과 도구 사용 입문
이 장에서 배울 것
이번 장에서는 LLM이 외부 도구를 사용하는 기본 구조를 배운다. 여기서 말하는 도구는 계산기, 날씨 API, 데이터베이스, 검색기, 사내 업무 시스템처럼 모델 바깥에 있는 기능을 뜻한다.
이 장을 마치면 다음을 설명할 수 있어야 한다.
Function calling이 무엇인지 설명한다.
LLM이 함수를 직접 실행하지 않는다는 점을 이해한다.
도구 정의에 함수 이름, 설명, 인자 스키마가 왜 필요한지 안다.
사용자 요청이 구조화된 함수 호출로 바뀌는 흐름을 이해한다.
도구 실행 전 검증, 권한 확인, 사용자 승인 절차가 왜 필요한지 설명한다.
Function calling과 agent의 차이를 구분한다.
왜 이 주제가 중요한가
앞 장에서 배운 RAG는 모델에게 근거 자료를 찾아 주는 방법이다. 사내 문서, 매뉴얼, 계약서, 회의록처럼 모델이 원래 알 수 없는 정보를 검색해 답변에 넣는다. 그러나 RAG만으로는 모든 업무를 처리할 수 없다.
예를 들어 사용자가 이렇게 요청했다고 하자.
"지난주 주문 3건의 배송 상태를 확인하고, 지연된 건은 고객센터 티켓으로 등록해 줘."
이 요청에는 세 가지가 섞여 있다. 주문 데이터베이스 조회, 지연 여부 판단, 티켓 생성이다. 문서를 검색하는 것만으로는 부족하다. 실제 시스템을 읽고, 필요하면 새 기록을 만들어야 한다.
LLM은 자연어를 이해하고 다음 행동을 고르는 데 강하다. 하지만 현재 배송 상태를 직접 조회하거나, 데이터베이스를 안전하게 수정하거나, 결제 취소 API를 실행하는 주체가 되어서는 안 된다. 모델은 "무엇을 해야 하는지"를 판단하고, 실제 실행은 애플리케이션 코드가 담당해야 한다. 이 분리가 Function calling의 핵심이다. 여러 자료에서도 Function calling은 모델이 함수를 실행하는 것이 아니라, 호출할 함수와 인자를 구조화해 반환하고 애플리케이션이 실행하는 방식으로 설명된다.1
쉽게 말해 LLM은 두뇌에 가깝고, API·DB·계산기는 손에 가깝다. 좋은 LLM 앱은 두뇌만 똑똑한 시스템이 아니라, 손이 안전하게 움직이도록 설계된 시스템이다.
핵심 개념 설명
Function calling은 LLM에게 "사용 가능한 도구 목록"을 알려 주고, 사용자의 요청에 따라 모델이 적절한 도구 이름과 필요한 인자를 생성하게 하는 방식이다. 보통 결과는 JSON 같은 구조화된 형식으로 나온다.
흐름은 다음과 같다.
개발자가 도구를 정의한다.
사용자 질문과 도구 목록을 LLM에 보낸다.
LLM이 도구가 필요한지 판단한다.
필요하다면 함수 이름과 인자를 생성한다.
애플리케이션이 인자를 검증하고 실제 함수를 실행한다.
실행 결과를 다시 LLM에 전달한다.
LLM이 사용자에게 자연어로 최종 답변한다.
예를 들어 사용자가 "서울 날씨 알려줘"라고 물으면 모델은 다음과 비슷한 출력을 만들 수 있다.
{
"name": "get_weather",
"arguments": {
"city": "서울",
"unit": "celsius"
}
}중요한 점은 이 JSON이 실행 자체가 아니라는 것이다. 모델은 get_weather를 실제로 호출하지 않는다. 애플리케이션 코드가 이 JSON을 읽고, 허용된 함수인지 확인하고, 인자를 검사한 뒤 날씨 API를 호출한다. LM Studio 문서도 도구 사용을 "모델은 함수 호출을 요청하는 텍스트를 출력하고, 실제 실행과 결과 반환은 사용자 코드가 담당하는 과정"으로 설명한다.2
도구가 특히 필요한 경우는 다음과 같다.
현재 날짜와 시간
실시간 날씨, 환율, 주가, 재고, 배송 상태
정확한 사칙연산과 통계 계산
데이터베이스 조회
사내 문서 검색 또는 특정 DB 검색
티켓 생성, 일정 등록, 주문 취소 같은 업무 처리
파일 변환, 코드 실행, 외부 API 호출
반대로 일반적인 개념 설명이나 글쓰기처럼 외부 상태가 필요 없는 요청은 도구 없이 답변해도 된다.
쉬운 비유 또는 사례
Function calling은 콜센터 상담원과 업무 시스템의 관계로 생각하면 쉽다.
상담원은 고객의 말을 이해한다.
"어제 주문한 노트북이 아직 출발도 안 한 것 같은데 확인해 주세요."
상담원은 이 말을 듣고 "주문 상태 조회"가 필요하다고 판단한다. 그리고 주문 번호나 고객 정보를 확인해 시스템에 입력한다. 하지만 상담원이 머릿속 기억으로 배송 상태를 말하지는 않는다. 반드시 주문 시스템을 조회한다.
LLM도 마찬가지다. 사용자의 자연어 요청을 해석해 어떤 도구가 필요한지 고른다. 그러나 실제 조회와 변경은 업무 시스템이 한다. 이 구조가 잘 지켜지면 모델의 언어 이해 능력과 시스템의 정확성을 함께 사용할 수 있다.
RAG와 Function calling의 차이도 이 비유로 구분할 수 있다. RAG는 상담원이 매뉴얼을 찾아 읽는 것이다. Function calling은 상담원이 주문 시스템, 일정 시스템, 티켓 시스템을 조작하는 것이다. 둘은 경쟁 관계가 아니다. "연차 규정상 가능한지"는 RAG로 확인하고, "그럼 연차 신청해 줘"는 Function calling으로 처리할 수 있다. 실제로 RAG 시스템에서 Function calling을 라우터로 사용해 여러 데이터베이스 중 어느 곳을 검색할지 고르는 패턴도 쓰인다.3
직접 해보는 실습
이번 실습에서는 부작용이 적은 세 가지 도구를 정의한다. 실제 돈이 이동하거나 데이터가 삭제되는 도구는 만들지 않는다.
calculate: 사칙연산 수행add_days: 기준 날짜에 며칠을 더한 날짜 계산get_weather_mock: 미리 정한 날씨 데이터 조회
먼저 도구 스키마를 생각해 보자. 도구 스키마는 모델에게 "이 함수는 언제 쓰고, 어떤 값을 넣어야 하는가"를 알려 주는 설명서다.
{
"name": "calculate",
"description": "두 숫자에 대해 안전한 사칙연산을 수행합니다.",
"parameters": {
"type": "object",
"properties": {
"a": { "type": "number", "description": "첫 번째 숫자" },
"b": { "type": "number", "description": "두 번째 숫자" },
"op": {
"type": "string",
"enum": ["add", "subtract", "multiply", "divide"],
"description": "수행할 연산"
}
},
"required": ["a", "b", "op"]
}
}이제 사용자가 "123 곱하기 456은?"이라고 입력하면 모델은 다음과 같은 함수 호출을 만들 수 있다.
{
"name": "calculate",
"arguments": {
"a": 123,
"b": 456,
"op": "multiply"
}
}애플리케이션은 다음 순서로 처리한다.
함수 이름이 허용 목록에 있는지 확인한다.
JSON이 유효한지 확인한다.
a,b,op가 스키마에 맞는지 검사한다.나눗셈이면
b가 0인지 확인한다.함수를 실행한다.
결과를 도구 메시지로 LLM에 돌려준다.
LLM이 "123 × 456 = 56,088입니다."처럼 최종 답변을 만든다.
실습 질문은 다음 세 개로 시작해 보자.
| 사용자 요청 | 기대되는 도구 |
|---|---|
| "123 곱하기 456 계산해 줘." | calculate |
| "2026-05-18에서 45일 뒤는 언제야?" | add_days |
| "서울 날씨 어때?" | get_weather_mock |
관찰할 것은 최종 답변보다 중간 과정이다. 모델이 어떤 함수를 골랐는가, 인자를 제대로 뽑았는가, 애플리케이션이 검증을 했는가를 기록하자.
흔한 실수와 오류 분석
첫 번째 실수는 모델이 만든 JSON을 항상 믿는 것이다. 모델은 스키마를 보고 꽤 그럴듯한 JSON을 만들지만, 항상 완벽하지는 않다. 필수값이 빠지거나, 숫자가 문자열로 들어오거나, 허용되지 않은 enum 값이 들어올 수 있다. 따라서 실행 전 검증은 필수다.
두 번째 실수는 사용자 입력을 그대로 SQL, API, 시스템 명령에 넣는 것이다. 사용자가 "고객 123 조회해 줘"라고 했을 때 모델이 만든 인자를 그대로 SQL 문자열에 붙이면 보안 문제가 생긴다. SQL은 파라미터 바인딩을 사용하고, 시스템 명령 실행은 가능하면 피해야 한다.
세 번째 실수는 권한 없는 도구까지 모델에 보여 주는 것이다. 모델에게 delete_all_users, refund_payment, send_email_to_all 같은 위험 도구를 아무 제한 없이 노출하면 안 된다. 사용자 권한, 업무 맥락, 승인 여부에 따라 도구 목록을 다르게 제공해야 한다.
네 번째 실수는 읽기 도구와 쓰기 도구를 같은 수준으로 다루는 것이다. 날씨 조회와 주문 취소는 위험도가 다르다. 조회 도구는 자동 실행할 수 있지만, 결제 취소나 외부 이메일 발송은 실행 전 사용자 확인을 받아야 한다.
다섯 번째 실수는 도구 결과를 검증하지 않는 것이다. 외부 API도 실패할 수 있고, 오래된 값을 반환할 수 있다. 도구는 성공과 실패를 구분해 구조화된 결과를 반환해야 한다.
{
"success": false,
"error_code": "TIMEOUT",
"message": "날씨 API 응답 시간이 초과되었습니다."
}이런 결과를 받으면 모델은 지어내면 안 된다. 사용자에게 "현재 날씨 조회에 실패했습니다. 잠시 후 다시 시도해 주세요."라고 말해야 한다.
Function calling과 agent의 차이
Function calling과 agent는 자주 섞여 쓰이지만 같은 말이 아니다.
Function calling은 개별 도구를 호출하기 위한 인터페이스다. 모델이 "어떤 함수에 어떤 인자를 넣어야 하는지"를 구조화해 내보내는 방식이다.
Agent는 더 넓은 설계다. 목표를 달성하기 위해 여러 번 생각하고, 도구를 고르고, 실행 결과를 관찰하고, 다시 계획하는 루프를 포함한다.
예를 들어 "서울 날씨 알려줘"는 단일 Function calling으로 충분하다. 하지만 "다음 주 출장 계획을 세우고, 항공편을 비교하고, 예산표를 만들고, 팀 캘린더에 등록해 줘"는 여러 단계의 도구 사용과 재계획이 필요하다. 이것은 agent 설계에 가깝다.
이 장에서는 단일 또는 짧은 도구 호출까지만 다룬다. 복잡한 자율 에이전트는 도구 선택 오류, 무한 루프, 비용 증가, 권한 문제를 함께 다뤄야 하므로 더 높은 수준의 설계가 필요하다.
요약
Function calling은 LLM을 텍스트 생성기에서 업무 시스템의 조정자로 확장하는 기본 기술이다. 하지만 모델이 함수를 직접 실행하는 것은 아니다. 모델은 호출할 함수 이름과 인자를 만든다. 애플리케이션이 검증하고 실행한다.
핵심은 역할 분리다.
LLM: 사용자 의도 이해, 도구 선택, 인자 추출, 결과 설명
애플리케이션: 인자 검증, 권한 확인, 실행, 오류 처리, 로그 기록
외부 도구: 계산, 조회, 검색, 업무 처리
좋은 Function calling 설계는 도구를 많이 붙이는 것이 아니다. 작고 명확한 도구를 만들고, 스키마를 엄격히 작성하고, 위험한 작업에는 승인 절차를 두는 것이다.
퀴즈
Function calling에서 LLM이 실제 함수를 직접 실행하지 않는 이유는 무엇인가?
다음 중 도구 사용이 더 적합한 요청은 무엇인가?
a. "Transformer가 무엇인지 설명해 줘."
b. "오늘 서울의 현재 기온을 알려줘."도구 정의에 JSON Schema가 필요한 이유는 무엇인가?
주문 취소 함수처럼 상태를 변경하는 도구를 실행하기 전에 어떤 절차가 필요한가?
Function calling과 agent의 차이를 한 문장으로 설명해 보라.
정답 예시:
실행 권한과 보안, 검증 책임은 애플리케이션이 가져야 하기 때문이다.
b
인자 타입, 필수값, 허용 범위를 명확히 해 모델 출력과 실행 전 검증을 가능하게 하기 위해서다.
사용자 권한 확인, 인자 검증, 위험도 판단, 사용자 승인, 실행 로그 기록이 필요하다.
Function calling은 도구 호출 인터페이스이고, agent는 여러 도구 호출과 관찰, 재계획을 반복하는 상위 구조다.
체크리스트
Function calling이 "모델의 직접 실행"이 아님을 설명할 수 있다.
도구가 필요한 작업과 필요 없는 작업을 구분할 수 있다.
함수 이름, 설명, parameters, required, enum의 역할을 설명할 수 있다.
모델이 만든 JSON을 실행 전 검증해야 한다는 점을 이해했다.
읽기 도구와 쓰기 도구의 위험도가 다르다는 점을 안다.
RAG와 Function calling의 차이를 설명할 수 있다.
Function calling과 agent를 구분할 수 있다.
다음 장 연결
이제 LLM 앱은 문서를 검색하고, 도구를 호출하고, 외부 시스템과 연결될 수 있다. 하지만 연결이 많아질수록 새로운 문제가 생긴다. 모델이 틀린 도구를 고르면 어떻게 알 수 있을까? 검색 결과를 잘못 해석하면 어떻게 평가할까? 도구 결과가 없는데도 그럴듯한 답을 만들면 어떻게 막을까?
다음 장에서는 LLM 평가와 hallucination을 다룬다. 답변이 그럴듯한지가 아니라, 실제로 맞는지 확인하는 방법을 배운다.
참고
3RAG with multiple Databases via Function Calling - Mistral AI Cookbook
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.