패스트캠퍼스 환급챌린지 38일차 : 테디노트의 RAG 비법노트 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

 

LLM에 도구 바인딩(Binding Tools)

LLM 모델이 도구(Tool)를 호출할 수 있으려면 chat 요청을 할 때 모델에 도구 스키마(tool schema)를 전달해야함. 

→ 도구 호출(tool calling) 기능을 지원하는 LangChain Chat Model은 .bind_tools() 메서드를 구현하여 LangChain 도구 객체, Pydantic 클래스 또는 JSON 스키마 목록을 수신하고 공급자별 예상 형식으로 채팅 모델에 바인딩(binding)함.
→ 바인딩(binding)된 Chat Model의 후속 호출은 모델 API에 대한 모든 호출에 도구 스키마를 포함함. 

 

LLM에 바인딩할 Tool 정의

→ 실험을 위한 도구(Tool) 정의.

• get_word_length : 단어의 길이를 반환하는 함수
• add_function : 두 숫자를 더하는 함수
• naver_news_crawl : 네이버 뉴스 기사를 크롤링하여 본문 내용을 반환하는 함수

도구 호출 에이전트(Tool Calling Agent)

> 도구 호출 에이전트란?

LLM은 기본적으로 텍스트를 이해하고 생성하는 모델인데, 실제 서비스 환경에서는 단순히 문장을 만들어내는 것만으로는 부족하다. 데이터베이스를 조회하거나, 외부 API를 호출하거나, 파일을 읽고 쓰는 등의 작업을 수행해야 하는 경우가 훨씬 많다. 이 때 등장하는 개념이 '도구 호출(tool calling)'이고, 이를 기반으로 한 도구 호출 에이전트(Tool Calling Agent) 이다. 

1. 도구 호출( Tool Calling)

도구 호출이란, 모델이 스스로 '이 요청은 외부 도구가 필요하다'고 판단하고 미리 정의된 도구(tool)를 정확한 형식으로 호출하는 기능을 의미한다. 

 

[기존 방식의 한계]

과거에는 모델이 자연어로 'API를 호출해야 합니다'라고 응답하고, 개발자가 응답을 피싱하여 조건문(if/else)로 API를 호출하여 결과를 다시 모델에 전달하는 방식이 일반적이었다. 이 방식은 파싱 오류가 잦고, 출력 형식이 일관되지 않으며, 모델의 의도를 정확히 해석하기 어렵다는 문제점이 있었다. 

 

2. 도구 호출 API의 핵심 목표

도구 호출 API는 일반 텍스트 완성이나 채팅 응답보다 더 안정적이고, 더 구조화된 방식으로 유효하고 실행 가능한 도구 호출 생성을 목표로 한다. 이를 위해 모델은 단순 문장이 아니라, 다음과 같이 구조화된 출력을 생성한다. 

{
  "tool_name": "get_weather",
  "arguments": {
    "location": "Seoul",
    "date": "2025-12-20"
  }
}

이 구조 덕분에 파싱이 필요 없고, 입력 값 검증이 쉬우며, 바로 함수나  API로 연결할 수 있다. 

 

3. 모델의 도구 호출 시점

모델은 질문에 대한 판단을 수행하고, 도구 호출 시점을 감지하여, 텍스트 응답 대신 도구 호출을 선택한다. 

[판단 수행]

• 이 요청에 대해 내 지식만으로 답할 수 있는가?
• 외부 데이터가 필요한가?
• 계산, 검색, 저장, 조회 같은 행동(action)이 필요한가?

(예시)

• 오늘 서울 날씨 알려줘 → 날씨 API 필요
• 사용자 주문 내역 조회해줘 → DB 조회 필요
• 이 파일 요약해줘 → 파일 읽기 도구 필요

4. 여러 도구를 바인딩

도구 호출의 강점은 여러 도구를 동시에 모델에 바인딩 할 수 있다는 점이다. 도구 예시로는 검색도구, 데이터베이스 조회 도구, 계산기, 파일 저장 도구, 이메일 발송 도구가 있으며, 모델은 이 중에서 어떤 도구를, 어떤 순서로, 어떤 인수(arguments)로 호출할지 스스로 선택한다. 

5. 도구 호출 에이전트(Tool Calling Agent)

에이전트는 단순히 한 번 도구를 호출하는 존재가 아니라, 문제가 해결될 때까지 '도구 호출 → 결과 수신 → 추가 판단 → 다음 도구 호출'을 반복하는 실행을 주체한다. 즉, 상태를 기억하고, 계획을 수정하며, 반복적으로 행동하는 구조다. 

6. 반복적 도구 호출 흐름

[도구 호출 에이전트의 일반적인 흐름]

1) 사용자 쿼리 입력

2) 모델이 문제를 해석

3) 필요한 도구 선택

4) 도구 호출(구조화된 JSON)

5) 도구 실행 결과 반환

6) 결과를 다시 모델에 입력

7) 부족하다면 다음 도구 호출

8) 최종 답변 생성

⇒ 쿼리가 해결됙때까지 반복되는 과정

 

7.  OpenAI 도구 에이전트와의 관계

OpenAI는 특정한 도구 호출 스타일과 에이전트 패턴을 제공하지만, 위에서 설명한 구조는 특정 벤더(OpenAI)에 종속되지 않는 일반화된 개념을 말한다. 즉, LLM+도구+반복적 추론 = 에이전트 이다. 

8. 이 개념의 중요성

도구 호출 에이전트는 LLM을 '말하는 모델'에서 '일하는 시스템'으로 바꾸는 역할을 수행한다. 이는 실제 서비스 자동화, 업무 프로세스 대체, 데이터 기반 의사 결정, 복합 작업 수행을 가능하게 한다. 즉, AI를 단순한 챗봇이 아니라 실행 가능한 소프트웨어 구성요소로 만드는 핵심 기술이라는 것을 의미한다.

---

RAG 강의를 수행하기 전에는 그저 LLM을 일종의 '검색 모델'로 생각했던 것 같아요. 하지만 이 강의를 듣다보면, 단순히 텍스트를 생성하는 것만으로는 분명히 한계가 존재한다는 것을 알 수 있었어요. 데이터를 조회해야 하고, 외부 API를 호출해야 하며, 결과를 다시 정리해 사용자에게 전달해야 하는 꽤 복잡한 구조를 갖고 있죠. 이때, 도구 호출과 도구 호출 에이전트 개념은 LLM 활용의 방향을 완전히 바꿔 놓았다는 것을 알 수 있어요.

기존의 챗봇 구조에서는 모델이 'API를 호출해야 합니다', '데이터베이스 조회가 필요합니다'와 같은 설명만 할 뿐, 실제 행동을 하지 못해서, 개발자가 모델의 자연어 응답을 해석하고, 조건문으로 나누고, 직접 API를 호출해서 다시 결과를 모델에 넣는 구조를 짜야 했어요. 이 과정은 너무 번거롭고, 불안정하며, 모델의 추론 흐름이 코드 밖으로 분산되는 느낌이 강했어요. 이를 해결해준 방식이 '도구 호출'이죠. 모델이 언제 도구가 필요한지를 스스로 판단해서 의사결정을 내리는 시스템에 가까워졌죠. 모델은 더이상 무조건 텍스트를 생성하지 않고, 필요하다면 구조화된 형태(JSON)으로 정확한 인수(arguments)를 포함해서 '이 도구를 호출해' 라고 명확히 지시합니다. 이 구조 덕분에 출력 형식이 흔들리지 않고 파싱 오류가 거의 없으며, 바로 코드 실행으로 연결할 수 있게 된다는 겁니다. 이 개념을 이해하니, LLM을 볼 때 '이 모델이 어떤 도구를 언제 호출하게 만들 수 있나'를 고려할 수 있게 되었어요. AI를 단순히 '기능'이 아니라 '시스템'으로 인식하게 만든 전환점이 되었죠. 앞으로 AI 서비스에서 경쟁력을 가르는 요소는, 모델 성능보다도 '어떤 도구를 어떻게 연결하고, 에이전트에게 어떤 판단 권한을 줄 것인가'가 될 것 같아요.

커리어 성장을 위한 최고의 실무교육 아카데미 | 패스트캠퍼스