LangChain Tools 정의 및 활용 완벽 가이드

LangChain에서 AI 에이전트가 사용할 수 있는 도구(Tool)를 정의하고 활용하는 방법을 초급 개발자 눈높이에서 설명합니다. @tool 데코레이터부터 에러 핸들링, 내장 도구 활용까지 실무에서 바로 쓸 수 있는 핵심 내용을 담았습니다.

---

목차

1. @tool 데코레이터 사용법
2. 타입 힌트와 Docstring 필수
3. Pydantic으로 복잡한 스키마 정의
4. ToolRuntime으로 state와 context 접근
5. 도구 에러 핸들링
6. 내장 도구 활용하기

---

1. @tool 데코레이터 사용법

김개발 씨는 회사에서 처음으로 AI 챗봇 프로젝트를 맡게 되었습니다. "챗봇이 날씨도 알려주고, 계산도 해줬으면 좋겠어요"라는 요구사항을 받았는데, 도대체 어떻게 AI에게 이런 기능을 추가할 수 있는 걸까요?

@tool 데코레이터는 일반 Python 함수를 AI 에이전트가 사용할 수 있는 도구로 변환해주는 마법 같은 장치입니다. 마치 평범한 주방 도구에 '사용 설명서'를 붙여서 요리사가 바로 활용할 수 있게 만드는 것과 같습니다.

이것만 제대로 알면 AI에게 원하는 기능을 자유자재로 추가할 수 있습니다.

다음 코드를 살펴봅시다.

from langchain_core.tools import tool

# 가장 기본적인 도구 정의 방법
@tool
def multiply(a: int, b: int) -> int:
    """두 정수를 곱합니다. 계산이 필요할 때 사용하세요."""
    return a * b

# 도구 정보 확인하기
print(multiply.name)        # 'multiply'
print(multiply.description) # '두 정수를 곱합니다...'
print(multiply.args)        # {'a': {'type': 'integer'}, 'b': {'type': 'integer'}}

# 직접 호출도 가능합니다
result = multiply.invoke({"a": 5, "b": 3})
print(result)  # 15

김개발 씨는 입사한 지 6개월 된 주니어 개발자입니다. 어느 날 팀장님이 다가와 말했습니다.

"김개발 씨, 우리 고객 서비스 챗봇에 계산 기능을 추가해줄 수 있어요? 고객들이 가끔 제품 가격 계산을 요청하거든요." 김개발 씨는 당황했습니다.

AI 모델은 텍스트를 생성하는 건 잘하지만, 정확한 수학 계산은 어떻게 시키지? LLM은 가끔 간단한 곱셈도 틀리지 않던가요?

바로 이럴 때 필요한 것이 **도구(Tool)**입니다. 쉽게 비유하자면, 도구는 마치 스마트폰에 설치하는 앱과 같습니다.

스마트폰 자체는 범용적인 기기지만, 계산기 앱을 설치하면 계산을 할 수 있고, 지도 앱을 설치하면 길을 찾을 수 있습니다. 마찬가지로 LLM 자체는 범용적인 언어 모델이지만, 도구를 연결하면 특정 기능을 정확하게 수행할 수 있습니다.

LangChain에서 도구를 만드는 가장 간단한 방법이 바로 @tool 데코레이터입니다. 데코레이터란 Python에서 함수를 감싸서 추가 기능을 부여하는 문법입니다.

함수 위에 @tool이라고 한 줄만 추가하면, 그 함수는 AI 에이전트가 인식하고 호출할 수 있는 도구로 변신합니다. 위의 코드를 살펴보겠습니다.

multiply라는 함수는 원래 그냥 두 수를 곱하는 평범한 함수였습니다. 하지만 @tool 데코레이터를 붙이는 순간, 이 함수는 name, description, args 같은 속성을 갖게 됩니다.

AI 에이전트는 이 정보를 보고 "아, 이 도구는 두 정수를 곱할 때 쓰는 거구나"라고 이해합니다. 특히 주목할 점은 **독스트링(Docstring)**입니다.

함수 바로 아래에 작성한 설명문이 자동으로 도구의 description이 됩니다. AI는 이 설명을 읽고 언제 이 도구를 사용해야 할지 판단합니다.

따라서 독스트링을 명확하게 작성하는 것이 매우 중요합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 전자상거래 챗봇을 만든다고 가정해봅시다. 고객이 "3개에 15,000원인 상품 5개 사면 얼마예요?"라고 물으면, 챗봇은 multiply 도구를 호출해서 정확한 가격을 계산한 뒤 답변할 수 있습니다.

다시 김개발 씨 이야기로 돌아가 봅시다. @tool 데코레이터의 존재를 알게 된 김개발 씨는 금세 계산 기능을 구현할 수 있었습니다.

팀장님도 만족스러워하며 말했습니다. "역시 김개발 씨네요!"

실전 팁

💡 - 독스트링은 AI가 도구를 선택하는 핵심 기준이므로, 언제 사용해야 하는지 명확하게 작성하세요

• 함수 이름도 직관적으로 지어야 AI가 더 잘 이해합니다

---

2. 타입 힌트와 Docstring 필수

김개발 씨가 만든 도구가 자꾸 이상하게 동작했습니다. 분명 숫자를 넣어야 하는데 AI가 문자열을 넣기도 하고, 어떤 인자가 필수인지 선택인지도 헷갈려하는 것 같았습니다.

선배 박시니어 씨가 코드를 보더니 한마디 했습니다. "타입 힌트 안 썼네요?"

타입 힌트와 Docstring은 AI 에이전트에게 도구 사용법을 알려주는 설명서입니다. 마치 조립 가구를 살 때 설명서가 없으면 조립이 어려운 것처럼, 타입 힌트와 Docstring이 없으면 AI는 도구를 제대로 사용하지 못합니다.

이 두 가지는 선택이 아닌 필수입니다.

다음 코드를 살펴봅시다.

from langchain_core.tools import tool
from typing import Optional

@tool
def search_products(
    category: str,
    min_price: Optional[int] = None,
    max_price: Optional[int] = None,
    in_stock: bool = True
) -> str:
    """상품을 검색합니다.

    Args:
        category: 검색할 상품 카테고리 (예: '전자기기', '의류')
        min_price: 최소 가격 필터 (원 단위, 선택사항)
        max_price: 최대 가격 필터 (원 단위, 선택사항)
        in_stock: 재고 있는 상품만 검색할지 여부
    """
    # 실제로는 데이터베이스 검색 로직이 들어갑니다
    return f"{category} 카테고리에서 {min_price}~{max_price}원 상품 검색 완료"

김개발 씨는 상품 검색 도구를 만들었습니다. 그런데 테스트를 해보니 AI가 자꾸 엉뚱한 값을 넣었습니다.

가격에 "비싼 것"이라는 문자열을 넣기도 하고, 카테고리를 숫자로 넣기도 했습니다. 박시니어 씨가 코드를 살펴보더니 문제를 발견했습니다.

"타입 힌트가 없으니까 AI가 뭘 넣어야 할지 모르는 거예요." LangChain의 @tool 데코레이터는 함수의 타입 힌트를 분석해서 입력 스키마를 자동으로 생성합니다. category: str이라고 적으면 AI는 "아, 여기에는 문자열을 넣어야 하는구나"라고 이해합니다.

min_price: Optional[int] = None이라고 적으면 "정수를 넣을 수도 있고, 안 넣어도 되는구나"라고 파악합니다. 하지만 타입만으로는 부족합니다.

int가 가격인지, 수량인지, 상품 ID인지 AI는 알 수 없습니다. 바로 이때 Docstring이 빛을 발합니다.

Docstring에서 Args 섹션을 작성하면, 각 인자가 무엇을 의미하는지 AI에게 상세히 설명할 수 있습니다. 위 코드에서 category에 대해 "검색할 상품 카테고리 (예: '전자기기', '의류')"라고 적었습니다.

AI는 이 설명을 읽고 적절한 카테고리 문자열을 넣게 됩니다. 예시를 함께 적어주는 것도 좋은 방법입니다.

"예: '전자기기', '의류'"처럼 구체적인 예시가 있으면 AI가 훨씬 정확하게 인자를 채워넣습니다. 실무에서 주의할 점이 있습니다.

독스트링의 첫 줄은 도구의 전체 설명으로 사용됩니다. AI는 이 첫 줄을 보고 "이 도구를 지금 사용해야 할까?"를 판단합니다.

따라서 첫 줄에는 도구가 무엇을 하는지 한 문장으로 명확하게 작성해야 합니다. 김개발 씨는 타입 힌트와 Docstring을 꼼꼼하게 추가했습니다.

다시 테스트해보니 AI가 정확하게 인자를 채워넣었습니다. "category에는 '전자기기', min_price에는 10000, max_price에는 50000..." 완벽했습니다.

박시니어 씨가 웃으며 말했습니다. "타입 힌트와 Docstring은 사람을 위한 것이기도 하지만, AI 에이전트를 위한 것이기도 해요.

잘 작성할수록 AI가 도구를 더 잘 사용합니다."

실전 팁

💡 - Docstring 첫 줄은 도구의 목적을 명확하게 한 문장으로 작성하세요

• 예시 값을 함께 적어주면 AI가 더 정확하게 인자를 채웁니다
• Optional 타입을 활용해 필수/선택 인자를 명확히 구분하세요

---

3. Pydantic으로 복잡한 스키마 정의

프로젝트가 커지면서 김개발 씨에게 새로운 고민이 생겼습니다. 도구에 전달해야 할 데이터가 점점 복잡해진 것입니다.

주문 정보를 처리하려면 고객 정보, 상품 목록, 배송 정보를 한꺼번에 받아야 하는데, 이걸 일일이 인자로 나열하자니 코드가 너무 지저분해졌습니다.

Pydantic을 사용하면 복잡한 입력 데이터의 구조를 깔끔하게 정의할 수 있습니다. 마치 입사 지원서 양식처럼, "이름은 여기에, 연락처는 저기에" 하고 정해진 형식을 만들어두면 AI도 그 형식에 맞춰 데이터를 채워넣습니다.

데이터 유효성 검사까지 자동으로 해주니 일석이조입니다.

다음 코드를 살펴봅시다.

from langchain_core.tools import tool
from pydantic import BaseModel, Field
from typing import List

# 복잡한 입력 구조를 Pydantic으로 정의
class OrderItem(BaseModel):
    product_id: str = Field(description="상품 고유 ID")
    quantity: int = Field(description="주문 수량", ge=1)

class CreateOrderInput(BaseModel):
    """주문 생성에 필요한 정보"""
    customer_name: str = Field(description="고객 이름")
    items: List[OrderItem] = Field(description="주문할 상품 목록")
    shipping_address: str = Field(description="배송 주소")
    use_express: bool = Field(default=False, description="빠른 배송 여부")

@tool(args_schema=CreateOrderInput)
def create_order(customer_name: str, items: List[dict], shipping_address: str, use_express: bool = False) -> str:
    """새로운 주문을 생성합니다."""
    total_items = sum(item["quantity"] for item in items)
    return f"{customer_name}님의 주문 생성 완료: 총 {total_items}개 상품, 배송지: {shipping_address}"

김개발 씨의 챗봇이 인기를 끌면서 요구사항이 늘어났습니다. 이제 챗봇으로 주문까지 받아야 한다는 것이었습니다.

문제는 주문 데이터의 복잡함이었습니다. 고객 이름, 상품 목록, 각 상품의 수량, 배송 주소, 빠른 배송 여부...

인자가 한두 개가 아니었습니다. 처음에 김개발 씨는 모든 것을 함수 인자로 나열해보았습니다.

하지만 코드가 너무 길어지고, 특히 '상품 목록'처럼 배열 안에 또 객체가 들어가는 구조는 타입 힌트로 표현하기 어려웠습니다. 그때 박시니어 씨가 Pydantic을 추천했습니다.

Pydantic은 Python에서 데이터 검증과 설정 관리를 위한 라이브러리입니다. BaseModel을 상속받아 클래스를 만들면, 그 클래스가 데이터의 '틀'이 됩니다.

마치 공문서 양식처럼 어떤 필드가 있어야 하고, 각 필드의 타입은 무엇인지를 명확하게 정의합니다. 위 코드에서 CreateOrderInput 클래스를 보면, customer_name은 문자열, items는 OrderItem의 리스트, shipping_address는 문자열, use_express는 불리언으로 정의되어 있습니다.

특히 items 필드는 또 다른 Pydantic 모델인 OrderItem의 리스트입니다. 이렇게 중첩 구조도 자연스럽게 표현할 수 있습니다.

Field 함수는 각 필드에 대한 추가 정보를 제공합니다. description은 AI에게 이 필드가 무엇인지 알려주고, ge=1 같은 옵션은 "1 이상이어야 한다"는 유효성 검사 규칙을 추가합니다.

default 값을 지정하면 선택적 필드가 됩니다. 도구에 이 스키마를 연결할 때는 @tool(args_schema=CreateOrderInput)처럼 args_schema 옵션을 사용합니다.

이렇게 하면 AI 에이전트가 create_order 도구를 호출할 때 CreateOrderInput 형식에 맞춰 데이터를 구성합니다. 김개발 씨는 Pydantic으로 스키마를 정의하고 나니 코드가 한결 깔끔해졌습니다.

게다가 잘못된 데이터가 들어오면 Pydantic이 자동으로 에러를 발생시켜서, 일일이 유효성 검사 코드를 작성할 필요도 없었습니다.

실전 팁

💡 - Field의 description은 AI가 참고하므로 명확하게 작성하세요

• 중첩 구조가 필요하면 Pydantic 모델 안에 다른 모델을 참조하세요
• ge, le, min_length 등의 유효성 검사 옵션을 적극 활용하세요

---

4. ToolRuntime으로 state와 context 접근

김개발 씨는 새로운 문제에 봉착했습니다. 도구 안에서 현재 로그인한 사용자 정보를 알아야 하는데, 이걸 매번 인자로 받자니 이상했습니다.

AI가 사용자 ID를 직접 넣으면 보안 문제도 생길 수 있었습니다. "도구가 시스템 상태에 접근할 방법이 없을까요?"

InjectedToolArg를 사용하면 AI가 제공하는 것이 아니라 시스템에서 주입하는 값을 도구에 전달할 수 있습니다. 마치 회사 출입증처럼, 직원이 직접 만드는 것이 아니라 회사에서 발급해주는 것입니다.

이를 통해 사용자 인증 정보, 세션 상태, 설정 값 등을 안전하게 도구에 전달합니다.

다음 코드를 살펴봅시다.

from langchain_core.tools import tool, InjectedToolArg
from typing import Annotated

# 시스템에서 주입되는 컨텍스트 정보
@tool
def get_user_orders(
    status_filter: str,
    user_id: Annotated[str, InjectedToolArg]  # AI가 아닌 시스템에서 주입
) -> str:
    """현재 로그인한 사용자의 주문 목록을 조회합니다.

    Args:
        status_filter: 주문 상태 필터 ('all', 'pending', 'completed')
    """
    # user_id는 AI가 제공하지 않음 - 시스템에서 안전하게 주입됨
    return f"사용자 {user_id}의 {status_filter} 주문 목록입니다."

# 실제 호출 시 주입 값 전달
result = get_user_orders.invoke({
    "status_filter": "pending",
    "user_id": "user_12345"  # 런타임에 시스템이 주입
})

김개발 씨의 챗봇에는 "내 주문 내역 보여줘"라는 기능이 있었습니다. 그런데 문제가 있었습니다.

주문 내역을 조회하려면 사용자 ID가 필요한데, 이걸 AI에게 맡기면 어떻게 될까요? 악의적인 사용자가 "user_9999의 주문 내역 보여줘"라고 요청하면?

AI가 그대로 user_9999를 인자로 넣어버릴 수 있습니다. 심각한 보안 문제입니다.

박시니어 씨가 해결책을 알려주었습니다. "AI가 제공하면 안 되는 값은 InjectedToolArg로 표시해요.

그러면 AI는 그 인자를 볼 수 없고, 시스템에서 직접 주입합니다." InjectedToolArg의 작동 원리를 살펴보겠습니다. Annotated[str, InjectedToolArg]라고 타입 힌트를 작성하면, LangChain은 이 인자를 AI에게 보여주는 스키마에서 제외합니다.

AI는 status_filter만 채우면 되고, user_id는 존재조차 모릅니다. 그러면 user_id는 어디서 오는 걸까요?

도구를 실제로 호출하는 시점에 시스템이 직접 넣어줍니다. 보통 에이전트 실행 환경에서 현재 세션의 사용자 정보를 가져와서 주입합니다.

이 패턴은 여러 상황에서 유용합니다. 데이터베이스 연결 객체, API 인증 토큰, 현재 사용자의 권한 정보 등 AI가 직접 다루면 안 되는 모든 것에 적용할 수 있습니다.

실무에서 자주 쓰는 패턴 중 하나는 RunnableConfig를 주입받는 것입니다. RunnableConfig에는 현재 실행 컨텍스트의 다양한 정보가 담겨 있어서, 도구 안에서 유연하게 활용할 수 있습니다.

김개발 씨는 InjectedToolArg를 적용한 후 마음이 놓였습니다. 이제 사용자가 아무리 다른 사람의 ID를 언급해도, 시스템에서 주입된 진짜 사용자 ID만 사용됩니다.

보안과 편의성을 동시에 잡은 셈이었습니다.

실전 팁

💡 - 보안에 민감한 정보는 반드시 InjectedToolArg로 주입하세요

• AI에게 노출되면 안 되는 시스템 객체(DB 연결, 인증 토큰 등)에 활용하세요
• Docstring의 Args 섹션에서 주입되는 인자는 생략해도 됩니다

---

5. 도구 에러 핸들링

어느 날 챗봇이 갑자기 멈춰버렸습니다. 로그를 확인해보니 외부 API 호출이 실패하면서 예외가 발생한 것이었습니다.

김개발 씨는 당황했습니다. "도구에서 에러가 나면 어떻게 처리해야 하지?

AI에게 에러를 알려줘야 할까, 아니면 숨겨야 할까?"

도구에서 발생하는 에러를 적절히 처리하면 AI 에이전트가 더 똑똑하게 대응할 수 있습니다. 에러 메시지를 AI에게 전달하면, AI는 다른 방법을 시도하거나 사용자에게 상황을 설명할 수 있습니다.

반면 치명적인 에러는 명확하게 예외를 발생시켜 시스템이 적절히 대응하도록 해야 합니다.

다음 코드를 살펴봅시다.

from langchain_core.tools import tool, ToolException

@tool(handle_tool_error=True)  # 에러를 AI에게 전달
def fetch_weather(city: str) -> str:
    """도시의 현재 날씨를 조회합니다."""
    valid_cities = ["서울", "부산", "대구", "인천"]

    if city not in valid_cities:
        # ToolException은 AI에게 에러 메시지를 전달합니다
        raise ToolException(
            f"'{city}'는 지원하지 않는 도시입니다. "
            f"지원 도시: {', '.join(valid_cities)}"
        )

    # 실제로는 날씨 API 호출
    return f"{city}의 현재 날씨: 맑음, 22도"

# 커스텀 에러 핸들러 사용
def my_error_handler(error: ToolException) -> str:
    return f"죄송합니다, 문제가 발생했습니다: {error.args[0]}"

@tool(handle_tool_error=my_error_handler)
def risky_operation(data: str) -> str:
    """위험한 작업을 수행합니다."""
    # 작업 수행...
    raise ToolException("서버 연결에 실패했습니다")

김개발 씨의 챗봇에는 날씨 조회 기능이 있었습니다. 외부 날씨 API를 호출하는 간단한 도구였는데, 어느 날 API 서버가 다운되면서 문제가 터졌습니다.

예외가 처리되지 않아서 챗봇 전체가 멈춰버렸습니다. 사용자는 아무런 응답도 받지 못했고, 에러 로그만 쌓여갔습니다.

박시니어 씨가 조언했습니다. "도구에서 에러가 발생할 수 있다는 걸 항상 염두에 두어야 해요.

특히 외부 시스템을 호출하는 도구는 더더욱요." 에러 처리에는 두 가지 전략이 있습니다. 첫 번째는 에러를 AI에게 알려주는 것입니다.

handle_tool_error=True로 설정하면, 도구에서 ToolException이 발생했을 때 예외가 그대로 전파되는 대신 에러 메시지가 AI에게 전달됩니다. AI는 이 메시지를 읽고 "아, 이 도시는 지원하지 않는구나.

사용자에게 다른 도시를 추천해야겠다"라고 판단할 수 있습니다. 두 번째는 커스텀 에러 핸들러를 사용하는 것입니다.

handle_tool_error에 함수를 전달하면, 에러 발생 시 그 함수가 호출됩니다. 에러 메시지를 사용자 친화적으로 다듬거나, 로깅을 추가하거나, 대체 동작을 수행할 수 있습니다.

어떤 에러를 AI에게 알리고, 어떤 에러를 시스템 레벨에서 처리할지 판단하는 것이 중요합니다. 사용자 입력이 잘못된 경우(지원하지 않는 도시명 등)는 AI에게 알려서 사용자와 소통하게 하는 것이 좋습니다.

반면 치명적인 시스템 에러(데이터베이스 연결 실패 등)는 예외를 전파해서 시스템이 적절히 대응하도록 하는 것이 좋습니다. 김개발 씨는 모든 외부 API 호출 도구에 에러 핸들링을 추가했습니다.

이제 API가 다운되어도 챗봇은 멈추지 않고 "죄송합니다, 날씨 정보를 가져올 수 없습니다. 잠시 후 다시 시도해주세요"라고 안내합니다.

훨씬 안정적인 서비스가 되었습니다.

실전 팁

💡 - 외부 시스템 호출 도구에는 반드시 에러 핸들링을 추가하세요

• 사용자 입력 오류는 AI에게 알려서 안내하게 하고, 시스템 오류는 로깅 후 일반적인 에러 메시지를 전달하세요
• 에러 메시지에는 가능하면 해결 방법이나 대안을 포함하세요

---

6. 내장 도구 활용하기

김개발 씨는 매번 도구를 처음부터 만들어야 한다고 생각했습니다. 웹 검색 도구, 계산 도구, 파일 읽기 도구...

그런데 박시니어 씨가 말했습니다. "그거 다 만들 필요 없어요.

LangChain에 이미 다 있거든요."

LangChain은 자주 사용되는 기능을 내장 도구로 제공합니다. 웹 검색, 수학 계산, 위키피디아 조회 등 일반적인 기능은 직접 구현할 필요 없이 가져다 쓰면 됩니다.

마치 스마트폰에 기본으로 설치된 앱처럼, 바로 사용할 수 있어서 개발 시간을 크게 절약할 수 있습니다.

다음 코드를 살펴봅시다.

# LangChain 내장 도구 사용하기
from langchain_community.tools import DuckDuckGoSearchRun
from langchain_community.tools import WikipediaQueryRun
from langchain_community.utilities import WikipediaAPIWrapper
from langchain_core.tools import tool

# 웹 검색 도구 (설치: pip install duckduckgo-search)
search = DuckDuckGoSearchRun()
result = search.invoke("LangChain이란 무엇인가")

# 위키피디아 검색 도구
wiki = WikipediaQueryRun(api_wrapper=WikipediaAPIWrapper())
wiki_result = wiki.invoke("인공지능")

# 여러 도구를 에이전트에 바인딩
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4")
tools = [search, wiki]

# 도구가 바인딩된 모델
llm_with_tools = llm.bind_tools(tools)

김개발 씨는 챗봇에 웹 검색 기능을 추가해달라는 요청을 받았습니다. 머릿속에서 해야 할 일이 쭉 떠올랐습니다.

검색 API 찾기, API 키 발급받기, HTTP 요청 코드 작성하기, 결과 파싱하기... 그런데 박시니어 씨가 웃으며 말했습니다.

"그냥 DuckDuckGoSearchRun 가져다 쓰세요. 5분이면 끝나요." LangChain은 langchain_community.tools라는 패키지에 다양한 내장 도구를 제공합니다.

웹 검색, 위키피디아, 날씨, 계산기 등 자주 필요한 기능들이 이미 도구로 구현되어 있습니다. DuckDuckGoSearchRun은 DuckDuckGo 검색 엔진을 사용하는 웹 검색 도구입니다.

API 키 없이 무료로 사용할 수 있어서 개발 단계에서 특히 유용합니다. 인스턴스를 만들고 invoke 메서드로 검색어를 전달하면 검색 결과를 받아옵니다.

WikipediaQueryRun은 위키피디아에서 정보를 검색합니다. AI가 사실 정보를 확인해야 할 때 유용합니다.

LLM은 때때로 잘못된 정보를 생성할 수 있는데, 위키피디아 도구를 통해 사실을 검증할 수 있습니다. 내장 도구를 에이전트에 연결하는 것도 간단합니다.

bind_tools 메서드로 LLM에 도구 목록을 전달하면, LLM은 필요할 때 적절한 도구를 선택해서 호출합니다. 물론 모든 상황에 내장 도구가 맞는 것은 아닙니다.

회사 내부 데이터베이스를 조회하거나, 특수한 외부 API를 호출해야 한다면 직접 도구를 만들어야 합니다. 하지만 일반적인 기능은 내장 도구를 우선 검토해보세요.

바퀴를 재발명할 필요는 없으니까요. 김개발 씨는 내장 도구 덕분에 예상했던 것보다 훨씬 빨리 기능을 완성했습니다.

남는 시간에 더 중요한 비즈니스 로직에 집중할 수 있었습니다. "역시 이미 있는 걸 잘 활용하는 것도 실력이구나" 하고 깨달았습니다.

실전 팁

💡 - 새 도구를 만들기 전에 langchain_community.tools에 비슷한 게 있는지 확인하세요

• 내장 도구도 커스터마이징이 가능합니다. 소스 코드를 참고해서 필요에 맞게 수정하세요
• 프로덕션 환경에서는 API 제한과 비용을 고려해서 적절한 도구를 선택하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!