책쓰자. Part1 - 4

Category: Private
Donghyuk Kim

4장. MCP vs LangChain vs AutoGen

에이전트를 구축하는 다양한 방법 중 MCP(Model Context Protocol), LangChain, AutoGen은 서로 다른 철학과 실행 구조를 갖는 대표적인 프레임워크이다. 이들은 모두 LLM 기반 에이전트를 구현하는 데 사용되지만, 도구를 선택하고 실행하는 방식, 제어 흐름 구성, 확장성과 유지보수 전략에서 큰 차이를 보인다.

LangChain은 체인 기반 워크플로우로, 미리 정의된 순서에 따라 도구를 연결하고 실행하는 구조를 따른다. 개발자가 각 단계의 흐름을 설계하며, 복잡한 로직을 구성하는 데 적합하다. AutoGen은 System과 Assistant라는 멀티 에이전트가 프롬프트와 코드를 주고받으며 협력하는 구조로, 대화형 흐름과 실행 제어를 분리할 수 있는 유연성을 제공한다. 반면 MCP는 LLM이 중심에서 도구를 선택하고 실행하는 구조로 설계되며, 명세 기반의 자동화, 확장성, 실행 흐름의 투명성에 중점을 둔다.

이 장에서는 세 가지 접근 방식이 실제로 어떻게 다르고, 어떤 상황에서 어떤 프레임워크가 더 적합한지를 비교 분석한다. 특히 각 방식이 도구를 선택하고 실행하는 데 있어 어떤 구조적 차이를 가지는지, 개발자와 모델이 각각 어떤 역할을 수행하는지를 명확히 설명하고자 한다.

비교는 크게 다섯 가지 관점에서 이루어진다:

  1. 실행 구조의 차이 (어떤 요소가 주도하는가)
  2. 실제 시나리오에서의 실행 흐름
  3. 제어 흐름과 디버깅 전략
  4. 개발자 관점에서의 구현과 유지보수
  5. 선택 기준과 프레임워크의 적합성 판단

이러한 비교를 통해, 독자는 단순한 기술적 차이를 넘어서, 자신이 구축하고자 하는 에이전트의 특성에 가장 적합한 실행 프레임워크를 스스로 판단할 수 있는 기준을 마련하게 될 것이다.

4.1 기본 실행 구조 비교

이 절에서는 MCP, LangChain, AutoGen 세 가지 프레임워크가 에이전트 실행 흐름을 어떻게 구성하는지 항목별로 비교한다. 각 프레임워크는 실행 주체의 위치, 도구 호출 방식, 제어 흐름 구조, 오류 처리 방식, 그리고 확장성 측면에서 서로 다른 철학을 반영하고 있다.

  • 실행 주체: MCP는 LLM이 실행의 주체가 된다. 즉, 모델 자체가 도구를 선택하고 실행하며 전체 흐름을 주도한다. 반면 LangChain은 개발자가 체인을 설계하고, 각 단계마다 실행 순서를 명시해야 한다. AutoGen은 System/Assistant라는 역할 분담이 있는 멀티에이전트 구조로, 각 에이전트가 번갈아 가며 제어권을 가진다.

  • 도구 호출 방식: MCP는 각 도구를 JSON 명세로 등록해두고, LLM이 그 중에서 적절한 도구를 선택해 JSON-RPC 형태로 호출한다. 반면 LangChain은 도구를 체인에 삽입하고 체인 실행 도중 순차적으로 호출되며, AutoGen은 프롬프트 내 코드 형태로 명시된 함수를 실행하는 방식이다. 따라서 MCP는 프롬프트 수정 없이 도구를 교체하거나 확장할 수 있는 반면, LangChain과 AutoGen은 도구 변경 시 체인 구성이나 프롬프트 수정이 필요하다.

  • 흐름 제어: MCP는 흐름 제어 역시 LLM이 담당한다. 사용자의 입력과 문맥 정보를 바탕으로 어떤 도구를 언제 호출할지를 결정한다. LangChain은 체인의 구조가 실행 순서를 고정하기 때문에 유연한 흐름 전환이 어렵고, AutoGen은 각 에이전트 간 메시지 흐름을 통해 실행이 전개되므로 상황에 따라 의도하지 않은 흐름으로 이어질 수 있다.

  • 오류 처리: MCP에서는 도구 실행 결과에 오류 정보가 포함되어 LLM이 그 문맥을 인식하고 대처 방안을 스스로 생성할 수 있다. 예를 들어 "파일을 찾을 수 없습니다"라는 오류 메시지를 받은 경우, LLM은 사용자에게 파일 재업로드를 요청할 수 있다. LangChain은 오류 발생 시 별도의 예외 처리 로직을 체인 외부에 작성해야 하고, AutoGen은 코드 실행 중 예외가 발생할 경우 해당 흐름을 복구하기 위한 추가 코드가 필요하다.

  • 확장성: MCP의 가장 큰 장점 중 하나는 명세 기반의 확장성이다. 새로운 도구를 추가할 때 해당 도구의 이름, 설명, 입력 스키마만 정의해 MCPServer에 등록하면 된다. LLM은 이를 문맥 기반으로 활용해 선택할 수 있으며, MCPClient는 도구 목록을 자동으로 가져와 모델에게 제공한다. LangChain은 체인 내부에 새로운 도구를 삽입하거나 흐름을 재설계해야 하며, AutoGen은 프롬프트 내 함수 호출 구조나 메시지 흐름 자체를 수정해야 한다.

즉, MCP는 모델 중심의 자동화 실행 구조를 지향하며, 문맥 추론과 도구 명세만으로 복잡한 작업 흐름을 단순화할 수 있다. 반면 LangChain과 AutoGen은 개발자가 실행 흐름을 설계하고 제어하는 구조이기 때문에 커스터마이징은 가능하나 자동화의 유연성은 상대적으로 제한적이다.

항목 MCP LangChain AutoGen
실행 주체 LLM (MCPClient가 조율) 사용자 정의 체인 System/Assistant 에이전트
도구 호출 방식 JSON 명세 기반 선택 및 실행 체인에 사전 삽입된 ToolCall 코드 기반 함수 호출 포함 프롬프트
흐름 제어 모델 중심 선택과 실행 체인 순서 기반 실행 에이전트 간 메시지 주고받기
오류 처리 LLM이 context 기반 판단 외부 제어 구조 필요 명시적 예외 처리 코드 필요
확장성 도구 명세만으로 확장 가능 체인 재설계 필요 프롬프트 및 코드 재작성 필요

4.2 실제 사용 시나리오 비교

"이 이미지를 분석해줘"라는 요청을 MCP, LangChain, AutoGen으로 각각 처리했을 때 실행 흐름이 어떻게 다른지 살펴본다. 아래 예제 코드는 단순히 코드 형태만 보여주는 것이 아니라, 각 시스템이 도구를 호출하고 응답을 생성하는 방식이 어떻게 구조화되어 있는지를 명확히 보여준다.

MCP 예시

아래 TypeScript 예제는 MCP 구조에서 LLM이 자동으로 적절한 도구를 선택하고 실행하는 전형적인 흐름을 보여준다. 사용자가 이미지를 분석해달라고 요청하면, MCPClient는 도구 목록을 수집해 LLM에 전달하고, LLM은 문맥 기반 추론을 통해 가장 적절한 도구를 선택한다. 이후 선택된 도구의 입력 스키마에 따라 인자값을 구성해 호출하며, 결과는 모델의 다음 응답 문맥에 반영된다.

import { OpenAI } from "openai";
import { mcpClient } from "./mcpClient";
import { getToolList } from "./toolRegistry";

const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

async function run() {
  const tools = await getToolList(); // MCPServer로부터 도구 명세 불러오기

  const messages = [
    { role: "user", content: "이 이미지를 분석해줘" },
  ];

  const response = await openai.chat.completions.create({
    model: "gpt-4-0613",
    messages,
    tools, // 도구 명세를 함께 전달
    tool_choice: "auto",
  });

  const toolCall = response.choices[0]?.message?.tool_calls?.[0];
  if (!toolCall) return;

  const result = await mcpClient.callTool(
    toolCall.function.name,
    JSON.parse(toolCall.function.arguments)
  );
  console.log("도구 실행 결과:", result);
}

run().catch(console.error);

LangChain 예시 (Python)

이 예제에서는 LangChain의 체인 구조를 사용해 analyze_image라는 도구를 사전에 정의한 뒤, 해당 체인을 통해 순차적으로 실행한다. 모델은 단지 사용자의 요청을 체인으로 전달하고, 체인 내에서 정의된 순서에 따라 도구가 호출된다. 도구 선택은 사전에 고정되며, 흐름 제어는 개발자가 직접 구성해야 한다.

from langchain.chat_models import ChatOpenAI
from langchain.agents import initialize_agent, Tool
from langchain.agents.agent_types import AgentType

def analyze_image(image_path):
    return f"'{image_path}' 이미지를 분석한 결과입니다."

tools = [
    Tool(
        name="analyze_image",
        func=analyze_image,
        description="이미지 경로를 받아 분석 결과를 반환하는 도구"
    )
]

llm = ChatOpenAI(temperature=0)
agent = initialize_agent(tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True)

result = agent.run("이 이미지를 분석해줘. 이미지 경로는 './example.png'야.")
print(result)

AutoGen 예시 (Python with autogen)

AutoGen은 에이전트 간의 메시지 흐름을 기반으로 동작한다. 이 예제에서는 사용자 프록시(UserProxyAgent)가 메시지를 보내고, 어시스턴트(AssistantAgent)가 해당 요청에 반응해 코드 내 등록된 analyze_image 함수를 호출한다. 도구 선택은 프롬프트 내에 명시되며, 자동화보다는 개발자가 작성한 함수와 흐름이 실행을 주도한다.

from autogen import AssistantAgent, UserProxyAgent

def analyze_image(file_path):
    return f"'{file_path}' 이미지를 분석한 결과입니다."

def setup():
    assistant = AssistantAgent(name="assistant", llm_config={"model": "gpt-4"})
    user_proxy = UserProxyAgent(
        name="user",
        code_execution_config={"use_docker": False},
    )

    @user_proxy.register_for_execution()
    def analyze_image_wrapper(file_path):
        return analyze_image(file_path)

    user_proxy.initiate_chat(assistant, message="이미지 './example.png'를 분석해줘.")

setup()

실행 흐름 비교 설명

다음은 동일한 사용자 요청을 처리하는 과정에서 세 프레임워크가 어떻게 다르게 작동하는지를 요약한 표이다:

항목 MCP LangChain AutoGen
도구 선택 모델이 문맥 기반으로 자동 선택 체인에 미리 지정된 도구 호출 프롬프트에 명시된 함수 실행
실행 흐름 제어 LLM이 주도적으로 판단 및 실행 순차적 체인 구성 사용자-에이전트 간 메시지 기반 처리
코드 유연성 도구 명세만 있으면 확장 가능 체인 수정 필요 함수/프롬프트 코드 수정 필요

  • MCP: 사용자의 요청을 받은 LLM이 도구 목록을 받아 문맥을 기반으로 적절한 도구를 선택하고 호출한다. 도구 호출 자체는 JSON 명세 기반이며, 실행 결과는 다음 메시지 문맥에 자동 반영된다. 이 과정은 LLM이 모든 제어 흐름을 담당한다는 점에서 가장 자율적이다.

  • LangChain: 사용자가 입력한 메시지는 체인을 통해 고정된 순서로 전달된다. 여기서는 analyze_image라는 도구가 미리 구성된 체인의 일부로 삽입되어 있고, 실행 시 순차적으로 호출된다. LLM은 흐름 제어보다는 응답 생성을 담당한다.

  • AutoGen: 사용자 프록시가 사용자의 요청을 전달하고, 어시스턴트가 코드 내 명시된 함수를 호출하는 방식이다. 메시지를 기반으로 도구 실행을 트리거하지만, 도구 선택이나 흐름 판단은 모두 사전에 정의된 스크립트 내에서 처리된다.

이처럼 세 방식은 코드 호출 방식만이 아니라 어디에서 판단이 이뤄지고, 어떻게 흐름이 제어되는지에서 본질적인 차이를 가진다. 특히 MCP는 모델이 중심이 되어 스스로 도구를 선택하고 실행하는 구조라는 점에서, 에이전트의 자율성과 확장성 측면에서 큰 차별성을 가진다.

4.3 제어 흐름과 디버깅 구조 비교

에이전트 시스템이 실제 운영 환경에서 안정적으로 작동하기 위해서는, 단순한 기능 실행을 넘어서 실행 흐름의 제어와 디버깅 구조가 중요하다. 특히 복잡한 사용자의 요구를 처리하는 과정에서는 중간 결과를 해석하고, 예외 상황을 감지하여 적절한 조치를 취할 수 있는 구조가 반드시 필요하다. 이 절에서는 MCP, LangChain, AutoGen이 각각 어떤 방식으로 흐름을 제어하고, 디버깅 및 리플레이 기능을 제공하는지 비교한다.

  • 흐름 제어 주체: MCP에서는 흐름 제어의 주체가 LLM이다. 모델은 사용자의 요청과 이전 결과를 바탕으로 현재 어떤 도구가 적절한지 스스로 판단하고 실행한다. 이러한 구조는 명시적인 조건문 없이도 유연한 흐름 제어가 가능하며, 상황 변화에 따라 자동으로 대응할 수 있다. 반면 LangChain은 미리 정의된 체인 순서에 따라 도구를 호출하므로, 흐름이 고정적이다. 조건 분기를 구현하려면 별도의 체인 조건 로직이 필요하다. AutoGen은 각 에이전트가 메시지를 주고받는 방식으로 흐름을 구성하므로, 대화 방식은 유연하지만 명확한 흐름 통제가 어렵다.

  • 중간 결과 처리: MCP는 각 도구의 실행 결과를 모델의 문맥(context)에 삽입함으로써 다음 도구 선택이나 응답 생성에 반영된다. 예를 들어, 이미지 분석 도구의 출력 결과가 자연어 형태로 LLM에게 전달되면, 이어지는 질의 응답에서 이를 자연스럽게 활용할 수 있다. LangChain은 중간 결과를 체인의 입력으로 전달하는 구조이지만, 문맥적으로 활용되기보다는 기능적 연결에 가깝다. AutoGen은 이전 메시지를 기억하는 형태로 중간 결과를 유지하지만, 각 에이전트가 별도 상태를 관리하기 때문에 일관된 흐름으로 사용하기는 어렵다.

  • 디버깅 용이성: MCP는 모든 도구 호출이 JSON-RPC 메시지로 기록되기 때문에 실행 경로, 입력 파라미터, 출력 결과, 오류 정보 등을 명확히 추적할 수 있다. 로그 기반으로 어떤 도구가 언제 호출되었고 어떤 입력을 받았는지 알 수 있어, 문제 발생 시 빠르게 원인을 분석하고 복원할 수 있다. LangChain은 체인 전체의 실행을 추적해야 하며, 각 도구의 로그는 별도로 추적하지 않으면 흐름을 파악하기 어렵다. AutoGen은 코드와 메시지 양쪽을 분석해야 하기 때문에, 디버깅이 상대적으로 복잡하다.

  • 리플레이 지원: MCP는 tool 호출 로그를 기반으로 동일한 실행을 재현할 수 있다. 예를 들어 특정 대화 흐름에서 도구 실행이 실패했을 경우, 동일한 입력과 문맥을 기반으로 재시도하거나 조건을 수정해 다시 실행할 수 있다. LangChain은 체인을 그대로 다시 실행하는 방식이지만, 상태 저장이나 파라미터 재사용에 제약이 있다. AutoGen은 대화 로그를 기반으로 재실행해야 하므로, 일관된 재현성이 떨어진다.

정리하면, MCP는 모델 중심의 제어 구조를 통해 흐름을 유연하게 구성하고, 실행 흐름의 투명성과 디버깅 가능성을 높은 수준으로 확보할 수 있다. 특히 복잡한 멀티툴 조합이나 반복적 자동화가 필요한 상황에서 MCP는 명세 기반 구조와 로그 중심 흐름 관리라는 강력한 이점을 제공한다.

항목 MCP LangChain AutoGen
흐름 제어 주체 LLM (Context 기반 추론) 체인 순서 및 조건문 명시적 에이전트 스크립트
중간 결과 처리 문맥 삽입 후 후속 도구 실행 체인 흐름 내에서 연결 메시지 전달 방식으로 유지
디버깅 용이성 실행 로그 및 tool 호출 내용 명확 체인 전체 실행 추적 필요 코드 및 메시지 구조 모두 파악 필요
리플레이 지원 호출 로그 기반 재실행 가능 체인 재실행 수동 스크립트 재작성 필요

4.4 개발자 관점의 차이

MCP, LangChain, AutoGen은 각각 다른 방식으로 에이전트를 구성하고 실행한다. 이 구조적 차이는 개발자의 역할과 책임, 시스템 설계 접근법, 그리고 도구 추가 및 유지보수 방식에 큰 영향을 준다. 이 절에서는 세 프레임워크에서 개발자가 어떤 작업을 담당하는지, 모델이 어떤 역할을 맡는지, 그리고 어떻게 확장을 고려해야 하는지를 중심으로 비교한다.

  • 개발자 책임: MCP에서 개발자의 주요 역할은 도구를 명세하고 이를 MCPServer에 등록하는 것이다. 도구의 이름, 설명, 입력 스키마만 명확히 작성하면, LLM이 이를 이해하고 활용할 수 있다. 이 구조는 도구 추가나 변경이 코드 수정 없이 가능하다는 점에서 유지보수가 쉽고, 협업 시 도구 관리의 일관성도 확보된다. 반면 LangChain은 각 체인을 직접 구성해야 하므로, 실행 흐름에 대한 명확한 설계가 필요하다. 체인이 복잡할수록 로직 설계와 테스트 부담이 커진다. AutoGen은 프롬프트 설계와 함수 작성 모두를 개발자가 수행해야 하며, 메시지 기반 로직이 섞이기 때문에 코드와 대화 문맥을 동시에 다뤄야 한다.

  • 모델 역할: MCP에서 LLM은 단순히 응답을 생성하는 수준을 넘어, 도구 선택과 실행까지 책임진다. 이를 통해 에이전트는 실질적인 실행 주체가 되며, 사용자의 요청을 분석하고 목표 달성을 위한 도구를 스스로 선택한다. LangChain의 LLM은 주어진 체인에 따라 문장을 생성하거나 도구를 순차적으로 실행하는 역할만 수행하며, 흐름 판단 능력은 없다. AutoGen의 LLM은 에이전트 간 대화를 통해 협업하나, 도구 실행 자체는 명시적 호출을 기반으로 하므로 구조적 판단보다는 스크립트에 따라 행동한다.

  • 유연성 확보 방식: MCP는 도구 명세만으로 기능을 확장할 수 있다. 예를 들어 새로운 기능을 가진 도구를 등록하면, 별도 코드 수정 없이도 LLM이 해당 도구를 인식하고 사용할 수 있게 된다. LangChain은 체인 구조를 직접 변경하거나, 도구 삽입을 위한 추가 코드를 작성해야 하며, 전체 흐름 변경 시 많은 수정이 필요하다. AutoGen은 프롬프트와 함수 코드를 동시에 변경해야 하므로, 프롬프트 설계의 복잡성이 높고, 테스트 과정에서 일관성을 유지하기 어렵다.

결국 MCP는 명세 중심, 모델 중심, 자동화를 지향하는 구조로, 개발자의 부담을 줄이고 확장성과 일관성을 극대화한다. 반면 LangChain과 AutoGen은 흐름 제어와 도구 실행을 개발자가 명시적으로 설계해야 하기 때문에, 자유도는 높지만 자동화에는 제약이 따른다.

역할 MCP LangChain AutoGen
개발자 책임 도구 명세 작성 및 MCPServer 구성 체인 구성 설계 프롬프트 및 함수 스크립트 작성
모델 역할 실행 주체 및 판단자 도구를 순차 처리 메시지 기반 협상자
유연성 확보 방식 명세 기반 도구 추가 체인 구조 유연화 메시지 구성 변경

4.5 언제 MCP를 선택할 것인가

에이전트를 구현하려 할 때, 어떤 프레임워크를 선택할지는 시스템의 복잡도, 자동화 수준, 확장성 요구 등에 따라 달라진다. 이 절에서는 LangChain, AutoGen과 비교했을 때 MCP가 어떤 환경에서 더 적합한지를 직관적으로 설명한다. 특히 도구 자동화, 문맥 기반 판단, 명세 중심 구조가 필요한 상황에서는 MCP가 강점을 가진다.

1. 도구가 반복적이고 구조화된 경우

MCP는 도구마다 고유한 이름, 설명, 입력 스키마(inputSchema)를 JSON 형식으로 정의한다. 이 명세는 LLM이 도구를 이해하고 선택하는 데 필요한 정보를 모두 담고 있다. 예를 들어 요약하기, 이미지 설명하기, 날짜 추출하기 등과 같이 일정한 형식을 갖는 도구를 자주 사용하는 시스템에서는, 도구 명세만 잘 작성해 두면 LLM이 자동으로 도구를 선택하고 실행할 수 있다. 이는 반복적이고 일관된 업무에서 큰 이점을 제공한다.

2. 모델이 도구를 선택해야 하는 경우

LangChain이나 AutoGen에서는 도구 호출을 프롬프트나 코드에서 명시적으로 지정해야 하는 경우가 많다. 반면 MCP는 LLM이 현재 문맥과 사용자의 요청을 보고 "어떤 도구를 사용할지" 스스로 결정할 수 있다. 예를 들어, 사용자가 "이 문서를 요약해줘"라고 하면, LLM은 요약 도구를 선택하고, "계약서에 있는 날짜들을 뽑아줘"라는 요청에는 추출 도구를 선택하게 된다. 이러한 구조는 사용자와의 상호작용이 복잡한 에이전트에서 매우 유용하다.

3. 흐름 추적 및 리플레이가 필요한 경우

MCP는 모든 도구 호출을 JSON-RPC 메시지로 처리하고, 입력과 출력, 오류까지 모두 기록한다. 덕분에 다음과 같은 활용이 가능하다:

  • 어떤 도구가 언제 호출되었는지 로그로 확인할 수 있으며, 실행 이력 기반의 분석이 가능하다.
  • 동일한 입력과 문맥으로 다시 실행해 결과를 재현하고 안정성을 검증할 수 있다.
  • 실패한 요청에 대해 입력값, 실행 시점, 오류 메시지를 바탕으로 원인을 추적할 수 있다.

예를 들어, 운영 중인 시스템에서 특정 입력에 대해 결과가 달라졌다면, 이전 호출 로그를 기반으로 재실행하거나 비교 분석을 쉽게 수행할 수 있다. 이는 특히 QA, 테스트 자동화, 고객지원 시나리오 등에서 유리하다.

4. 도구가 자주 추가/변경되는 환경

서비스 운영 중에는 기능이 점차 추가되거나, 기존 도구의 입력 스펙이 바뀌는 일이 흔하다. MCP는 도구 명세만 수정하면 모델이 이를 즉시 인식할 수 있으므로, 코드 수정이나 재배포 없이도 시스템 확장이 가능하다. LangChain은 체인 구성 자체를 수정해야 하고, AutoGen은 함수나 프롬프트 내용을 다시 작성해야 하는 번거로움이 따른다.

5. 여러 도구를 유연하게 조합해야 하는 경우

MCP는 LLM이 각 도구의 실행 결과를 기억하고, 이를 바탕으로 다음 도구를 자동으로 선택하는 흐름을 구성할 수 있다. 예를 들어:

  • 1단계: 이미지를 설명하는 도구 실행 → "이 사진은 뉴욕의 센트럴파크입니다."
  • 2단계: 위치 추정 도구 자동 선택 → "센트럴파크의 위도 경도는..." 이처럼 사용자의 발화가 복잡해져도, 도구 선택과 실행 흐름이 자연스럽게 이어진다.

6. 복잡한 시스템 통합이 필요한 경우

MCP는 Host–Client–Server 구조로 설계되어 있기 때문에, 다음과 같은 유연한 조합이 가능하다:

  • 하나의 MCPClient가 여러 MCPServer와 통신
  • 서로 다른 클라이언트가 동일한 도구 집합을 공유
  • 외부 시스템(API 등)과 연결된 도구도 동일한 방식으로 호출 가능

덕분에 마이크로서비스 아키텍처나 하이브리드 클라우드 환경에서도 무리 없이 MCP를 적용할 수 있다.

7. MCP를 선택하지 않아도 되는 경우

MCP는 강력한 자동화 구조를 제공하지만, 모든 상황에 적합한 것은 아니다. 다음과 같은 경우에는 LangChain이나 AutoGen 같은 다른 프레임워크가 더 단순하고 효과적일 수 있다:

  • 도구가 하나이거나 고정된 순서로 실행되는 경우: 단일 목적의 단순한 체인이나 워크플로우에는 LangChain의 선언적 체인 구조가 더 적합하다. 복잡한 도구 선택 로직이 필요 없다면, 오히려 MCP는 과한 설계일 수 있다.

  • 모델 판단보다 명시적인 흐름 제어가 중요한 경우: 사용자 요청에 따라 정확히 어떤 도구가 실행되어야 하는지가 명확하다면, AutoGen처럼 코드와 프롬프트를 통해 흐름을 직접 정의하는 방식이 더 직관적이고 예측 가능하다.

  • 빠른 프로토타이핑이나 실험 환경을 원하는 경우: AutoGen은 프롬프트와 함수만으로 손쉽게 실행 구조를 설계할 수 있어, 빠른 실험과 반복 작업에 유리하다. MCP는 명세와 서버 구성이 필요해 초기 설정이 다소 복잡할 수 있다.

  • 모델의 판단 능력을 신뢰하기 어려운 도메인: 예를 들어 법률, 의료 등 고신뢰성이 필요한 분야에서는 모델이 자유롭게 도구를 선택하는 방식보다, 사람이 제어 흐름을 고정하는 구조가 더 안전할 수 있다.

이러한 상황에서는 MCP의 자동화 장점보다는, 명시적인 구성과 제어가 가능한 구조가 더 설계 및 운영에 적합할 수 있다.

Tags

Navigation

← Previous: 책쓰자. Part1 - 5 에서 5.2까지Next: 책쓰자. Part1 - 3 →← Back to List