함수 콜링 · 0to1

LLM 도구AI 입문5분

한눈에

함수 콜링 = LLM에게 도구를 쥐여주는 것 (모델은 부를 뿐, 실제 실행은 앱이 한다)
LLM = 지시하는 셰프, 함수 = 주방기구·보조 (셰프가 믹서를 돌리라 말할 뿐 직접 믹서가 되진 않는다)
도구 정의 = 이름·설명·인자 스키마 (모델은 설명만 읽고 부를지 판단하므로 설명이 곧 사용 설명서)
한 번 호출 = 왕복 (모델이 호출을 요청 → 앱이 실제 실행 → 결과를 되먹임 → 최종 답)
MCP = 함수 콜링의 포장 (알맹이는 함수 콜링, MCP는 표준 규격으로 감싼 껍데기)

LLM은 글만 쓸 줄 안다. 오늘 날씨도 모르고, 내 DB도 못 읽고, 메일도 못 보낸다. 배운 것 안에서 그럴듯한 문장을 뽑을 뿐이다. 함수 콜링은 그 LLM에게 도구를 쥐여주는 방법이다. 모델한테 "이런 도구가 있어 — 이름은 이거고, 이럴 때 쓰고, 이런 값을 넣으면 돼" 하고 알려주면, 모델이 필요한 순간 "그 도구 좀 불러줘" 하고 요청한다.

핵심은 여기 있다. 모델은 도구를 부를 뿐, 실행은 앱이 한다. 주방을 떠올리면 쉽다. LLM은 지시하는 셰프고, 함수는 주방기구와 보조다. 셰프가 "믹서 3초 돌려서 갖다줘"라고 말하지, 자기가 직접 믹서가 되진 않는다. 셰프는 주문을 내고, 보조가 실제로 믹서를 돌려 결과를 셰프에게 준다. 셰프는 그걸 받아 접시를 완성한다. 함수 콜링에서 셰프의 주문이 "호출 요청"이고, 보조가 믹서를 돌리는 게 "앱의 실행"이다.

모델은 왜 도구가 필요한가

모델은 학습이 끝난 시점까지의 세상만 안다. 그 뒤의 일도 모르고, 학습에 없던 내 회사 데이터도 모른다. 게다가 숫자 계산이나 정확한 조회는 원래 약하다 — 그럴듯하게 지어내는 쪽에 가깝다. 도구가 없으면 "아마 이럴 것"이라고 상상해서 답하고, 그게 바로 환각(hallucination)이 되기 쉽다.

도구를 쥐여주면 이야기가 달라진다. 날씨는 날씨 API에 물어보고, 재고는 DB를 조회하고, 계산은 계산기에 시킨다. 모델은 "생각"을 맡고, 사실 확인과 실제 행동은 도구에 넘긴다. 자기가 모르는 걸 상상하는 대신, 진짜로 알아보게 되는 것이다.

도구를 어떻게 알려주나

도구 하나를 정의한다는 건 모델에게 메뉴판 한 줄을 건네는 것과 같다. 무엇이 들어가는지 보자.

이름(name) — 모델이 호출할 때 부르는 함수 이름. get_weather 같은 것

설명(description) — 언제 이 도구를 쓰는지 자연어로 적는다. 모델은 이 설명만 읽고 부를지 말지 판단하므로, 설명이 곧 사용 설명서다

인자 스키마(input schema) — 넣어야 할 값의 형태를 JSON으로. 가령 location은 문자열, unit은 섭씨/화씨 중 하나

실행 코드는 여기 없다 — 정의는 어디까지나 메뉴판일 뿐, 실제 함수 본체는 내 앱이 들고 있다

그래서 좋은 도구는 설명을 잘 쓴 도구다. 모델은 코드 내부를 보지 못하고 오직 설명과 인자 형태만 보고 판단한다. 설명이 모호하면 엉뚱한 때 부르거나 아예 안 부른다.

한 번 부르면 이렇게 오간다

함수 콜링은 한 방에 끝나는 게 아니라 왕복이다. 모델과 앱이 공을 주고받는다.

도구를 쥐여줌

이름·설명·인자 스키마를 질문과 함께 모델에 넘긴다

모델이 호출을 요청

필요하다 싶으면 tool_use로 '이 함수를 이 값으로 불러줘'라고 답한다

앱이 실제로 실행

모델 대신 내 코드가 API·DB를 진짜로 호출한다

결과를 되먹임

실행 결과를 tool_result로 모델에게 돌려준다

최종 답 생성

받은 결과를 녹여 사람에게 줄 답을 쓴다

여기서 모델이 뱉는 건 "함수를 부르겠다는 의사"지 실행 결과가 아니다. 실행은 언제나 앱 몫이고, 그 결과를 다시 넣어줘야 모델이 최종 답을 만든다. 도구가 여러 개면 이 왕복을 몇 번 돌기도 한다 — 그게 흔히 말하는 에이전트의 뼈대다.

MCP랑 뭐가 다른가

함수 콜링을 이해하면 MCP플레이북MCP프롬프트로 못 미치는 자리에 도구를 붙인다.가 쉬워진다. 함수 콜링이 알맹이고, MCP는 포장이다. 함수 콜링은 "모델에게 도구를 어떻게 알려주고 어떻게 부르게 하는가"라는 알맹이 규칙이다. 문제는 도구가 늘고 앱이 많아지면 이 정의가 제각각이 된다는 것. MCP는 그 함수 콜링을 표준 규격으로 포장해서, 도구를 내주는 쪽(서버)과 모델을 부리는 쪽(호스트)이 역할을 나눠 갖게 한 것이다. 도구를 USB처럼 꽂았다 뺐다 하는 그림. 알맹이는 그대로 함수 콜링이고, MCP는 그걸 남들과 나눠 쓰기 좋게 규격화한 껍데기다.

우리 프로젝트에선

noon-desktop개인 제품noon-desktop워치 noon의 눈을 얹은 macOS 반려 AI. 전문가 모드가 이 함수 콜링을 네이티브로 쓴다. 모델에 search_minecraft_wiki라는 도구를 쥐여주고, 마인크래프트 질문이 오면 모델이 그 도구를 불러 위키를 실제로 읽은 다음 답한다. MCP를 거치지 않은 순수 tool-use다 — 상상 대신 진짜 문서를 근거로 답하게 만든 것.

반대 방향으로 쓰는 데도 있다. saegim-eval은 도구를 부르는 대신 구조화 출력을 강제한다. 모델이 자유 문장이 아니라 정해진 스키마(점수·근거)에 딱 맞춰 답하게 못박는 것. 같은 스키마 기술을 "행동"이 아니라 "형식"에 쓰는 셈이다. 도구 정의로 모델의 출력 형태를 붙잡는다는 점은 함수 콜링과 한 뿌리다.

더 읽기

개념을 코드와 그림으로 더 풀어놓은 글들. 알맹이가 잡히면 나머지는 응용이다.

Tool use with Claude — Anthropic 공식 문서 — 도구가 어디서 실행되고 모델이 언제 부르는지, tool_use ↔ tool_result 왕복을 원전으로
Function Calling: LLM이 외부 세계와 소통하는 방법 — SK DevOcean — 개념부터 오픈소스 모델 구현 코드까지, 한국어로 차근차근
LLM과 외부 세계를 연결하는 새로운 기술: Function Calling, MCP — 삼성 기술블로그 — 함수 콜링과 MCP를 나란히 놓고 개발자 관점에서 정리