「LLM에게 복잡한 태스크를 맡기고 싶지만, 단일 프롬프트로는 한계가 있는데…」 「외부 도구와 연계시키고 싶지만, 어떻게 설계해야 할지 모르겠어…」라고 느끼고 계시지 않나요?

많은 엔지니어가 직면하는 이 과제는, LLM 단체로는 어려운 복잡한 태스크를 여러 에이전트가 연계하여 해결하는 **멀티 에이전트 시스템 (Multi-Agent System)**과 외부 도구 연계의 핵심인 Function Calling (또는 Tool Calling)을 효과적으로 활용함으로써 극복할 수 있습니다. 이 기사에서는 이러한 설계 사상과 실천적인 구현 방법을 심층적으로 파고들어, 고도화된 AI 애플리케이션 개발에 도움이 될 구체적인 지견을 제공합니다.

이 섹션에서는 **멀티 에이전트 시스템 (Multi-Agent System)**의 기본적인 개념과, 왜 현대의 복잡한 AI 애플리케이션 개발에서 중요하게 여겨지는지를 해설합니다.

단일 LLM으로는 주어진 프롬프트의 범위 내에서만 추론 및 행동할 수 있습니다. 하지만 현실 세계의 태스크는 많은 경우 여러 단계, 서로 다른 전문 지식, 외부 데이터에 대한 액세스, 그리고 상황에 따른 유연한 판단을 필요로 합니다. 여기서 진가를 발휘하는 것이 멀티 에이전트 시스템입니다.

멀티 에이전트 시스템은 각각 특정 역할이나 전문 지식을 가진 여러 AI 에이전트가 협조 및 분담하며 하나의 목표 달성을 지향하는 구조입니다. 인간 사회의 팀워크와 유사하며, 정보 공유, 토론, 역할 분담을 통해 단일 에이전트로는 이룰 수 없는 고도의 문제 해결 능력을 발휘합니다.

주목받는 배경:

• 복잡한 태스크에 대한 대응: 여러 서브 태스크(Sub-task)로 분해하여 각각 특기 있는 에이전트가 처리함으로써 전체적인 문제 해결 능력이 향상됩니다.
• 전문 지식의 통합: 서로 다른 도메인 지식을 가진 에이전트를 조합함으로써 다각적인 관점에서의 추론이나 의사결정이 가능해집니다.
• 유연성과 적응성: 상황에 따라 에이전트 간의 연계 패턴이나 역할을 동적으로 변경할 수 있기 때문에 변화가 심한 환경에도 대응하기 쉽습니다.

이 섹션에서는 Function Calling의 메커니즘과 주요 LLM (OpenAI, Google Gemini, Anthropic Claude)에서의 대응 상황에 대해 심층적으로 파고듭니다.

Function Calling (Anthropic에서는 Tool Use, Google에서는 Function Calling)은 LLM이 외부 도구 또는 API를 호출하기 위한 기능입니다. LLM은 주어진 프롬프트와 이용 가능한 도구의 사양에 기반하여, 어떤 도구를 어떤 인자(Argument)로 호출해야 할지를 판단하고, 그 정보를 구조화된 JSON 형식으로 반환합니다. 애플리케이션은 그 JSON을 받아 실제 도구를 실행하고, 그 결과를 다시 LLM에 피드백함으로써 LLM은 외부 시스템과 연계된 행동이 가능해집니다.

Function Calling의 메커니즘:

• 도구 정의의 제공: 애플리케이션 측에서 이용 가능한 외부 도구(함수)의 이름, 목적, 인자 스키마 (타입, 필수/선택 등)를 LLM에 전달합니다. 이는 OpenAPI 3.0 포맷이나 프레임워크 고유의 형식으로 기술됩니다.
• LLM의 추론: LLM은 사용자의 프롬프트와 도구 정의를 고려하여 "이 태스크를 해결하려면 이 도구가 필요하다"라고 판단합니다.
• 도구 호출 요청 생성: LLM은 호출해야 할 도구의 이름과 해당 도구에 필요한 인자를 JSON 형식으로 생성합니다.
• 애플리케이션에 의한 실행: 애플리케이션은 이 JSON을 받아 실제로 지정된 도구를 실행합니다.
• 결과의 피드백: 도구 실행 결과를 LLM에 피드백하며, LLM은 이를 바탕으로 다음 행동을 결정하거나 최종적인 답변을 생성합니다.

주요 LLM의 대응 상황:

• OpenAI Function Calling: 가장 빠르게 기능을 제공하였으며, 많은 프레임워크에서 표준적으로 이용되고 있습니다. ToolSpec 사양은 공식 문서에서 상세히 설명되어 있습니다 (https://platform.openai.com/docs/guides/gpt/function-calling). -
  Google Gemini API Function Calling: Gemini API에서도 Function Calling을 이용할 수 있습니다. OpenAPI 3.0 표준 포맷을 통한 API 서비스 사양 기술을 지원합니다 (https://ai.google.dev/docs/function_calling). -
  Anthropic Claude Tool Use: Anthropic에서는 Function Calling을 「Tool Use」라고 호칭하며, 유사한 기능을 제공합니다 (https://docs.anthropic.com/claude/docs/tool-use).

이러한 기능들은 LLM을 단순한 챗봇에서 외부 시스템과 연계하여 구체적인 액션을 실행하는 「에이전트 (Agent)」로 진화시키기 위한 기반이 됩니다.

이 섹션에서는 Python의 LangChain과 Google Gemini API를 조합한 Function Calling의 구체적인 구현 사례를 통해, 멀티 에이전트 대화의 기초를 학습합니다.

Function Calling의 구현은 LLM에 이용 가능한 함수를 이름, 설명, 입력 스키마 (Input Schema)와 함께 전달하고, LLM이 해당 사양을 이해하여 최적의 파라미터 (Parameter)로 함수를 호출하는 흐름으로 진행됩니다.

다음 코드는 get_current_weather라는 날씨 정보를 가져오는 도구 (Tool)를 정의하고, 이를 LLM 에이전트가 이용하도록 하는 예시입니다. 사용자가 날씨를 물으면, LLM이 도구 호출을 판단하고 그 결과에 기반하여 응답합니다.

import os
import time
from typing import List, Dict, Union
...

이 예시에서는 weather_agent가 get_current_weather 도구를 이용하여 사용자의 질문에 답하는 반면, general_agent는 도구를 가지고 있지 않기 때문에 일반적인 응답만 할 수 있습니다. 이와 같이 에이전트마다 이용 가능한 도구를 한정함으로써, 역할에 따른 행동을 유도할 수 있습니다.

이 섹션에서는 견고하고 효율적인 **멀티 에이전트 시스템 (Multi-Agent System)**을 구축하기 위한 설계 원칙, 흔히 발생하는 과제와 회피책, 그리고 베스트 프랙티스 (Best Practice)에 대해 해설합니다.

도구의 상세 사양 정의의 번거로움:-
주의할 점 (Pitfalls): 각 도구의 입력, 출력, 에러 처리의 상세 사양 정의는 특히 도구의 수가 늘어남에 따라 번거로워지기 쉽습니다. LLM이 이해할 수 있는 설명문을 작성하고 개선하는 것, API 변경에 대한 추종, 도구 간의 의존 관계 관리도 과제가 됩니다. -
회피책:
OpenAPI 3.0 등의 표준 포맷으로 API 서비스 사양을 기술하여, 구조화된 정의를 철저히 합니다. 이를 통해 도구 정의의 재사용성과 유지보수성을 향상시킬 수 있습니다.

• LangChain의 @tool 데코레이터와 같이, 프레임워크를 활용하여 도구 정의를 간소화합니다. -
  공식 문서 확인 필요: MCP (Model Context Protocol)와 같은 표준화 움직임도 있으나, 현시점에서는 OpenAPI나 프레임워크의 도구 정의 기능을 활용하는 것이 현실적입니다.

Function Calling 미지원 모델 이용 시의 신뢰성·유지보수성·보안 문제:
주의할 점 (ハマりどころ): Function Calling을 지원하지 않는 LLM으로 유사한 처리를 구현하려고 하면, 프롬프트 엔지니어링 (Prompt Engineering)을 통해 JSON 형식을 생성하도록 유도해야 합니다. 이는 신뢰성 저하 (실패나 부정확한 동작의 증가), 유지보수의 어려움 (프롬프트나 출력 형식의 붕괴), 보안상의 불안 (부정확한 출력을 처리해 버릴 리스크), 확장성 (Scalability)의 한계 (복잡한 유스케이스에서의 설계 복잡화)와 같은 높은 비용을 발생시킵니다. -
회피책:
OpenAI GPT-4 Turbo, Anthropic Claude 3, Google Gemini 1.0 Pro 등 Function Calling 기능이 있는 LLM을 활용하는 것을 강력히 권장합니다. 이러한 모델들은 도구 호출 (Tool Calling)의 정확도와 신뢰성이 격단히 향상되어 있습니다.
Function Calling이 지원되지 않는 경우에는 재귀적인 상호작용을 수동으로 제어해야 하며, 구현이 복잡해지므로 그 비용을 충분히 고려해야 합니다.

API 비용과 응답 속도 악화:
주의할 점 (ハマりどころ): 안이하게 에이전트를 늘리거나 계획 없이 도구를 호출하면, LLM으로의 API 호출 횟수가 증대되어 API 비용 증가와 응답 속도 (Latency) 악화를 초래하며, ROI (투자 대비 효과)를 크게 해칠 가능성이 있습니다. -
회피책:
모델의 하이브리드 구성: 복잡한 추론이나 고도의 판단이 필요한 태스크에는 고성능 대규모 모델 (예: GPT-4 Turbo, Claude 3 Opus), 데이터 정제나 경량 정보 추출 등의 루틴 워크 (Routine Work)에는 소형이며 빠른 모델 (예: GPT-3.5 Turbo, Gemini Nano)을 할당하여, 정확도와 API 비용 사이의 트레이드오프 (Trade-off)를 최적화합니다. -
가드레일 (Guardrails): "동일한 검색을 3회 반복하면 강제 종료한다", "루프 횟수의 상한을 둔다", "일정 시간 응답이 없으면 타임아웃한다"와 같은 안전장치를 시스템 레벨에서 구축하여, 무한 루프나 불필요한 API 호출을 방지합니다. -
상태 관리 (State Management): 대화 이력이나 현재 실행 중인 태스크 상황을 "상태 (State)"로서 일원 관리하며, 각 단계에서 명시적으로 유지 및 업데이트합니다. LangGraph와 같은 프레임워크는 이러한 상태 관리에 탁월하며, 불필요한 재계산이나 컨텍스트 (Context)의 비대화를 방지합니다.

멀티 에이전트 시스템에서는 항상 몇 가지 트레이드오프를 고려해야 합니다.

정확도 vs 비용/레이턴시 (Latency):

• 고성능 LLM은 정확도가 높지만, API 비용이 높고 응답 속도가 느려지는 경향이 있습니다.
• 경량 LLM은 저비용이며 빠르지만, 정확도가 떨어질 수 있습니다.

해결책: 복잡한 추론에는 고성능 모델을, 데이터 정제 등의 루틴 워크에는 소형 모델을 구분하여 사용하는 "deep/quick 2층 모델" 방식이 유효합니다.

정보 전달 형식 (구조화 vs 자연어):

• 구조화된 문서로 정보를 전달하면 "전언 게임에서의 정보 열화 (Telephone Effect)"를 회피할 수 있습니다.
• 자연어로 에이전트 간 토론을 진행하면, 깊은 추론과 다양한 관점의 통합을 촉진합니다.

해결책: 전달은 구조화된 방식으로, 토론은 자연어로 하는 구분 방식이 정보 손실과 추론 깊이 사이의 균형을 맞춥니다.

Workflow형 vs Agent형:
Workflow형: 사전에 정의된 코드 경로로 LLM과 도구를 편성하며, 처리 흐름은 설계자가 제어합니다. 예측 가능하고 디버깅하기 쉽다는 장점이 있습니다. -
Agent형: LLM 스스로가 프로세스와 도구 사용을 동적으로 제어하며, 언제, 어떤 도구를, 어떻게 사용할지를 판단합니다. 유연하고 복잡한 태스크에 대응할 수 있지만, 예측이 어려워질 수 있습니다. -
해결책: 단순하고 예측 가능한 태스크에는 Workflow형을, 복잡하고 동적인 판단이 필요한 태스크에는 Agent형을 적용합니다. LangGraph는 이 두 가지의 하이브리드 접근을 가능하게 하는 프레임워크입니다.

Function Calling의 단계적 도입:

• 우선 하나의 읽기 전용 도구(Read Tool)를 Function Calling으로 테스트합니다.
• 입력·출력 검증, 권한 확인, 판단·실행 로그, 에러 처리를 추가합니다.
• 연결 대상이 늘어나면 OpenAPI와 같은 표준 포맷으로 도구 정의를 공통화합니다.
• 여러 단계의 절차가 필요한 경우에만 에이전트 루프(Agent Loop)를 추가합니다.
• 전송이나 변경 작업에 실행 시 승인(Runtime Approval)을 추가하는 메커니즘을 검토합니다.
• 대표적인 태스크로 성공률, 오실행, 단계 수, 비용을 평가하며 개선을 반복합니다.

에이전트 간의 정보 전달:

• 에이전트는 구조화된 문서(Structured Document)로 정보를 전달하여 정보의 열화를 방지합니다.
• 토론 시에만 자연어(Natural Language)를 사용하여 깊은 추론과 다양한 관점의 통합을 가능하게 합니다.

리플렉션(Reflection)·메모리(Memory)의 활용:

• 과거의 실행 결과나 학습 내용을 기록하고 이를 다음 프롬프트에 주입함으로써, 에이전트가 경험으로부터 학습하고 더 똑똑해지는 메커니즘을 구축합니다. LangChain의 Memory 모듈 등이 유효합니다.

도구의 재사용성:

• 적절하게 문서화되고 충분히 테스트되어 재사용 가능한 도구는 발견 가능성(Discoverability)을 높이고, 버전 관리를 용이하게 하며, 중복된 정의를 방지합니다.

LLM의 역할 이해:

• LLM은 '실행하는 존재'가 아니라 '실행 가능한 구조 안에서 의사결정을 하는 존재'임을 이해해야 합니다. 외부 시스템과의 연결을 통해 LLM이 의사결정을 내리고, 외부 시스템이 이를 실행하는 구조를 구축하는 것이 중요합니다.

RAG (Retrieval-Augmented Generation)와 Function Calling의 구분 사용:

• Function Calling: 어떤 처리를 자동화하고 싶을 때(데이터 취득, 보고서 작성, 알림 전송), 사용자의 지시에 따라 API를 호출해야 할 때, LLM을 '업무 어시스턴트' 또는 '실행 에이전트'로 사용하고 싶을 때 적합합니다.
• RAG: 방대한 문서나 지식(Knowledge)으로부터 필요한 정보를 검색·답변하게 하고 싶을 때, 최신 정보나 기업 고유 데이터에 기반한 자연스러운 대화가 필요할 때, FAQ 챗봇이나 사내 지식 QA 등을 구축할 때 적합합니다.
• 두 기술은 목적에 따라 구분해서 사용해야 하는 기술이며, 어느 하나가 더 우월한 것이 아닙니다. 대부분의 경우, 두 가지를 조합하여 더욱 강력한 시스템을 구축할 수 있습니다. 예를 들어, RAG로 정보를 취득하고 그 정보에 기반하여 Function Calling으로 액션을 실행하는 식의 연계가 가능합니다.

이 기사에서는 LLM 멀티 에이전트 시스템과 Function Calling의 설계 원칙, 실전적인 구현 사례, 그리고 개발 시의 트레이드오프(Trade-off)와 베스트 프랙티스(Best Practice)에 대해 설명했습니다.

• 멀티 에이전트 시스템은 복잡한 태스크를 여러 전문 에이전트가 분담하고 협력하여 해결하는 강력한 패러다임입니다.
• Function Calling은 LLM이 외부 도구나 API를 호출하기 위한 필수적인 기능이며, 주요 LLM에서 지원됩니다.
• LangChain과 같은 프레임워크는 이러한 기능들을 쉽게 구현할 수 있도록 추상화(Abstraction)를 제공합니다.
• 설계 시에는 도구의 상세한 정의, 대응 모델의 선택, API 비용 및 응답 속도의 최적화가 중요합니다.
• RAG와 Function Calling은 상호 보완적인 관계에 있으며, 목적에 따른 구분 사용과 조합이 더욱 고도화된 AI 애플리케이션을 실현합니다.

LLM 단독으로는 어려웠던 과제들도 멀티 에이전트 시스템과 Function Calling을 결합함으로써 더욱 유연하고 강력한 AI 애플리케이션을 구축할 수 있습니다. 여러분의 프로젝트에서 이러한 설계 원칙과 실전적인 접근 방식을 꼭 시도해 보시기 바랍니다.

다음 단계로, LangChain의 Agent 문서 (https://www.langchain.com/)나 LangGraph의 상태 관리(State Management)에 관한 상세 내용 (https://langchain-ai.github.io/langgraph/)을 참조하여, 더욱 복잡한 워크플로우와 에이전트 간의 협력 설계에 도전해 보시는 것을 권장합니다.