LLM 실전 활용 4: Tool Calling & Function Calling — “말하는 모델”을 “일하는 시스템”으로 바꾸는 순간

LLM 실전 활용 4: Tool Calling & Function Calling — “말하는 모델”을 “일하는 시스템”으로 바꾸는 순간

---

RAG까지 붙였을 때 이런 생각이 든다.

“이제 꽤 똑똑한데… 왜 실제로 일을 시키면 막히지?”

• 오늘 날짜 알려달라니까 틀리고
• DB 조회는 못 하고
• 계산은 불안하고
• 결국 사람이 중간에 다 해줘야 한다

여기서 깨닫는다.

👉 LLM은 ‘두뇌’지, ‘손’이 아니다.

이 간극을 메워주는 게 바로
Tool Calling / Function Calling 이다.

이번 글은
LLM을 “대답하는 챗봇”에서
실제로 업무를 수행하는 시스템 컴포넌트로 바꾸는 핵심 설계다.

---

1. 왜 LLM 혼자서는 실무가 안 되는가?

LLM의 태생적 한계는 명확하다.

❌ LLM이 못 하는 것

• 현재 시각 조회
• 데이터베이스 쿼리
• 외부 API 호출
• 정확한 계산
• 권한·정책 판단

이건 지능의 문제가 아니라 역할의 문제다.

LLM은 “무엇을 해야 하는지”는 잘 말하지만
“직접 실행”은 못 한다.

그래서 구조를 이렇게 바꿔야 한다.

---

2. Tool Calling의 핵심 아이디어

“결정은 LLM이 하고,
실행은 시스템이 한다.”

구조는 단순하다.

사용자 질문
 → LLM (의사결정)
 → 어떤 Tool을 쓸지 선택
 → 실제 함수 / API 실행
 → 결과를 다시 LLM에게 전달
 → 최종 응답

LLM은 컨트롤 타워,
Tool은 현실 세계와 연결된 팔·다리다.

---

3. Function Calling과 Tool Calling, 뭐가 다른가?

개념적으로는 거의 같다.
다만 관점 차이가 있다.

용어관점

Function Calling	“이 함수를 호출해라”
Tool Calling	“이 도구를 사용해라”

실무에서는 보통
함수(Function)를 Tool로 등록해서 쓴다.

---

4. 언제 Tool Calling이 필요한가? (판별 기준)

반응형

다음 질문이 나오면 무조건 Tool이다.

• “오늘 날짜 알려줘”
• “주문 번호 123 상태 조회해줘”
• “이 숫자 합계 계산해줘”
• “이 사용자 권한 확인해줘”
• “이 파일 업로드해줘”

👉 정확성·최신성·실행이 필요한 순간엔
LLM 단독 사용 ❌

---

5. Tool Calling의 전체 아키텍처 (실전)

[User]
  ↓
[LLM]
  ↓ (tool 필요 판단)
[Tool Schema 선택]
  ↓
[Backend Function 실행]
  ↓
[결과 반환]
  ↓
[LLM 최종 응답]

여기서 중요한 포인트는:

• LLM은 함수를 실행하지 않는다
• LLM은 “이 함수 써라”라고 요청만 한다
• 실행 책임은 백엔드에 있다

---

6. Tool 설계의 핵심 원칙 5가지

① Tool은 “작고 명확하게”

• 하나의 함수 = 하나의 책임
• DB 조회 + 계산 + 포맷 ❌

② 입력 스키마를 엄격히

• 타입 명확
• optional 최소화
• 이름은 사람이 읽기 좋게

③ 결과는 구조화

• 문자열 ❌
• JSON ⭕

④ 실패 케이스도 설계

• not found
• 권한 없음
• 시스템 오류

⑤ LLM에게 결과 해석만 맡긴다

• 판단 ❌
• 요약/설명 ⭕

---

7. 가장 단순한 Function Calling 예제 (Python)

아래 코드는 실제로 많이 쓰는 구조다.
(개념 검증용, 실행 가능)

def get_order_status(order_id: int):
    orders = {
        1001: "배송중",
        1002: "배송완료",
        1003: "주문취소"
    }
    return {
        "order_id": order_id,
        "status": orders.get(order_id, "주문 없음")
    }

이 함수를 Tool로 등록하고
LLM에게 이렇게 알려준다.

{
  "name": "get_order_status",
  "description": "주문 번호로 주문 상태를 조회합니다",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "integer",
        "description": "주문 번호"
      }
    },
    "required": ["order_id"]
  }
}

LLM은 이제:

• “이 질문엔 get_order_status가 필요하네”
• → 호출 요청
• → 백엔드 실행
• → 결과 전달
• → 사용자 응답 생성

---

8. Tool Calling + RAG, 같이 쓰면 진짜 강력해진다

실무에서는 이 조합이 정답이다.

예시 흐름

1️⃣ RAG로 규정 문서 검색
2️⃣ “가능하다”는 근거 확보
3️⃣ Tool로 실제 처리 실행

예:

• “연차 써도 돼?” → RAG
• “그럼 연차 신청해줘” → Tool

👉 의사결정과 실행을 분리했기 때문에 가능해진 구조다.

---

9. LLM이 Tool을 잘 고르게 만드는 법

프롬프트에서 딱 이것만 명확하면 된다.

다음 도구 중 필요한 것이 있으면 선택해라.
도구가 필요 없다면 직접 답변해라.

그리고 각 Tool 설명은:

• 언제 써야 하는지
• 무엇을 반환하는지

를 짧고 명확하게 써야 한다.

Tool 설명이 애매하면
LLM도 애매하게 고른다.

---

10. 실무에서 가장 흔한 실패 패턴

❌ Tool이 너무 큼
❌ Tool 책임 불분명
❌ 문자열 반환
❌ LLM이 계산까지 하게 둠
❌ Tool 호출 결과 검증 안 함

이러면:

• 디버깅 불가
• 예외 처리 지옥
• “왜 저 함수 불렀지?” 상태 발생

---

11. Tool Calling의 진짜 의미

Tool Calling은 기능 추가가 아니다.

LLM을 ‘결정 엔진’으로 격상시키는 설계다.

• 판단 → LLM
• 실행 → 시스템
• 책임 → 코드

이 분리가 되면:

• 서비스 안정성 ↑
• 확장성 ↑
• 유지보수 난이도 ↓

---

12. 이 글의 핵심 요약

개념본질

LLM	판단·의사결정
Tool	실행·현실 연결
Function Calling	실행 요청 인터페이스
좋은 설계	책임 분리
RAG + Tool	실무 최강 조합

---

 

LLM,ToolCalling,FunctionCalling,AI에이전트,LLM아키텍처,RAG,백엔드개발,AI서비스,생성형AI,LLM실무