AI Agent 도구 체인 설계: 단일 도구에서 도구 생태계로 진화하는 가이드

지난주 한 업계 동료가 물었습니다. “네 Agent는 CRM, 데이터베이스, 코드 저장소, 메일 시스템을 동시에 연결할 수 있어?” 저는 당연히 된다고 답했습니다. 다만 시스템마다 어댑터 코드를 따로 써야 했습니다. CRM은 Salesforce API를 호출하고, 데이터베이스는 PostgreSQL에 연결하고, 코드 저장소는 GitHub와 연동하고, 메일 시스템은 SMTP를 거치는 식이었습니다. 그는 웃으며 다시 물었습니다. “그럼 어댑터를 몇 개나 썼는데?”

세어 보니 열두 개였습니다.

어댑터 하나를 디버깅하는 데 평균 반나절이 걸렸고, 더 오래 걸린 것도 있었습니다.

그가 한마디 더 했습니다. “왜 Agent가 이런 도구를 직접 호출하는 법을 배우게 하지 않고, 너가 매번 연결을 손으로 짜야 해?”

솔직히 말해, 이 질문에 잠깐 멈칫했습니다.

2026년의 한 조사에 따르면 개발자의 84%가 여러 AI 코딩 도구를 동시에 사용합니다. 하지만 Agent가 실제 기업 프로덕션 환경으로 들어가야 할 때, 여러 도구를 조합하는 일 뒤에는 또 다른 현실적인 통증이 숨어 있습니다. 외부 시스템마다 맞춤 어댑터 계층을 작성해야 한다는 점입니다.

바로 이 문제가 MCP 프로토콜(Model Context Protocol)이 해결하려는 지점입니다. 비유하자면, 예전에는 기기마다 충전 단자가 달랐지만 이제는 USB 표준이 생긴 것과 같습니다. 한 번 개발하면 여러 기기에서 재사용할 수 있습니다.

이 글에서는 AI Agent 도구 체인 설계의 핵심 문제를 이야기하려 합니다. “단일 도구 호출”에서 “도구 생태계”로 진화하는 논리, MCP 프로토콜이 실제로 해결하는 문제, 주요 프레임워크를 선택하는 관점, 그리고 엔터프라이즈급 도입 과정에서 밟았던 함정까지 다룹니다.

Agent 시스템을 만들고 있거나 “어떤 프레임워크를 골라야 할지”, “도구 인터페이스를 어떻게 설계해야 할지” 고민 중이라면, 이 글이 실전 관점의 힌트를 줄 수 있을 것입니다.

1장: 도구 체인의 본질 - 왜 “도구 호출”에서 “도구 생태계”로 올라가야 하는가

1.1 세 계층 아키텍처: Agent의 뼈대

먼저 기본 인식부터 정리하겠습니다. Agent 아키텍처는 대체로 세 계층으로 나뉩니다.

가장 아래는 Model 계층입니다. 대형 모델의 추론 능력, 즉 GPT-5, Claude 3.7, Gemini 2.0 같은 부분입니다. 이 영역은 이미 상당히 상품화되었습니다. 어느 회사를 고르든 큰 틀에서는 비슷하고, 차이는 능력의 본질보다 가격과 속도에 있습니다.

중간 계층은 Agent Harness라고 부르며, 어떤 사람들은 “Agent 운영체제”라고도 합니다. 이 계층은 세 가지를 관리합니다. 도구 스케줄링, 상태 관리, 컨텍스트 전달입니다. 비유하자면 Model 계층이 엔진이라면 Harness는 변속기입니다. 엔진이 아무리 강해도 변속기 설계가 좋지 않으면 차는 빠르게 달리지 못합니다.

가장 위는 Skills 계층입니다. Agent의 전문 지식 베이스와 워크플로입니다. 금융 Agent에는 컴플라이언스 점검 Skills가 있고, 고객지원 Agent에는 응대 스크립트 라이브러리가 있으며, 개발 Agent에는 코드 리뷰 규칙이 있습니다. 이 계층이 Agent의 차별화를 결정합니다. 두 Agent가 같은 Model을 사용하더라도 Skills가 다르면 성능은 크게 달라집니다.

도구 체인 설계는 주로 Harness 계층에서 일어납니다.

1.2 단일 도구의 실제 곤경

저도 한 번 제대로 당한 적이 있습니다. 처음에는 LangChain의 내장 도구로 간단한 질의응답 Agent를 실행했습니다. 이후 요구사항이 복잡해졌습니다. 회사 내부 ERP, BI 시스템, 프라이빗 데이터베이스를 연결해야 했습니다.

당시 LangChain에는 600개가 넘는 내장 도구가 있었습니다. 그런데 결과가 어땠을까요? 기업 내부 시스템은 하나도 커버하지 못했습니다.

방법이 없어서 직접 작성했습니다. 첫 번째 커스텀 도구는 비교적 순조롭게 끝났습니다. 하지만 다섯 번째, 열 번째 도구를 작성할 때쯤 몇 가지 문제가 드러나기 시작했습니다.

첫 번째 문제: 도구 정의가 흩어져 있습니다.

각 도구의 파라미터 Schema, 오류 처리, 로그 기록이 서로 다른 파일에 흩어져 있었습니다. 한 도구를 다른 Agent 프로젝트에서 재사용하려면 코드를 복사해 붙이고, 파라미터 이름을 고치고, 예외 포착 로직을 다시 손봐야 했습니다.

두 번째 문제: 상태를 공유할 수 없습니다.

Agent가 CRM 도구를 호출해 고객 정보를 조회한 뒤 다음 단계에서 메일 도구를 호출해 후속 메일을 보내야 합니다. 그런데 메일 도구는 CRM 도구가 반환한 고객 이메일 주소를 얻지 못합니다. Agent 메인 프로그램에서 상태를 수동으로 전달해야 합니다.

세 번째 문제: 라이프사이클을 관리하는 사람이 없습니다.

도구 버전이 업데이트되었을 때 어떤 Agent가 아직 구버전을 쓰고 있는지 알 수 없습니다. 도구가 장애를 내면 어떤 Agent가 연쇄적으로 실패할지도 알 수 없습니다.

이것도 최악은 아닙니다. 가장 힘든 점은 외부 시스템이 하나 추가될 때마다 어댑터 코드를 한 번 더 써야 한다는 것입니다. 처음에 말한 열두 개 어댑터가 바로 이렇게 생겼습니다.

1.3 도구 생태계: “수작업 공방”에서 “산업화”로

도구 생태계는 무엇을 해결할까요? 한 문장으로 말하면 “도구”를 “서비스”로 바꾸는 것입니다.

전통적인 방식에서 도구는 특정 Agent에 딸린 코드 조각입니다. 도구 생태계 방식에서 도구는 독립 서비스이며, 자신만의 API, 버전, 문서를 가집니다. Agent는 마이크로서비스를 호출하듯 도구를 호출합니다.

이 방식에는 몇 가지 핵심 이점이 있습니다.

표준화된 인터페이스. MCP 프로토콜은 통일된 데이터 형식과 호출 방식을 정의합니다. MCP Server 하나를 작성하면 MCP를 지원하는 모든 프레임워크가 곧바로 호출할 수 있습니다. LangChain, CrewAI, AutoGen은 물론 직접 작성한 Agent Harness도 마찬가지입니다.

재사용 메커니즘. 회사 내부에 MCP Server 라이브러리를 만들고 CRM Server, ERP Server, 메일 Server를 각각 둡니다. 새 Agent 프로젝트가 CRM을 연결하고 싶다면 설정 한 줄이면 됩니다. 어댑터 계층을 다시 쓸 필요가 없습니다.

거버넌스 능력. 도구에 독립 라이프사이클이 생깁니다. 버전 관리, 호출 감사, 성능 모니터링을 할 수 있습니다. 어떤 도구에 문제가 생겼는지 한눈에 보입니다.

조합 가능성. Skills 계층은 여러 도구를 워크플로로 묶을 수 있습니다. 예를 들어 “고객 불만 처리”라는 Skill은 CRM 조회 + 티켓 생성 + 메일 알림을 이어 붙입니다. 아래에는 세 개의 독립 도구가 있고, 위에는 하나의 비즈니스 프로세스가 있습니다.

비유하자면 예전에는 주문 하나마다 처음부터 두드려 만드는 수작업 공방이었다면, 이제는 표준화된 부품 라이브러리로 조립하는 방식입니다.

2장: MCP 프로토콜 - AI Agent의 “USB 표준”

2.1 MCP는 정확히 무엇인가

MCP의 전체 이름은 Model Context Protocol입니다. Anthropic이 2024년 말에 제안했고, 2026년에는 Agent 도구 체인의 주류 표준이 되었습니다.

공식 정의는 AI Agent와 외부 시스템 및 데이터 소스를 연결하기 위한 개방형 표준입니다.

쉽게 말하면 MCP는 “도구 설명 규격”과 “호출 프로토콜”을 정의합니다. Agent가 어떤 도구를 호출하려 할 때 도구의 구체 구현을 알 필요가 없습니다. MCP 설명 파일만 읽으면 됩니다. 그 설명 안에는 도구 이름, 파라미터 Schema, 반환 형식, 권한 요구사항이 들어 있습니다.

이는 USB 표준과 매우 비슷합니다. USB는 인터페이스 모양, 전압, 데이터 전송 프로토콜을 정의합니다. 마우스 제조사는 컴퓨터마다 드라이버를 따로 쓸 필요가 없고 USB 표준만 따르면 됩니다. 컴퓨터 제조사도 모든 마우스마다 별도 인터페이스를 만들 필요 없이 USB 포트만 제공하면 됩니다.

MCP도 같은 논리입니다. 도구 제공자 또는 우리가 MCP 표준을 따라 MCP Server를 작성합니다. Agent 프레임워크 제공자는 MCP 표준을 따라 MCP Client를 구현합니다. 양쪽이 맞물리면 호출이 통합니다.

2.2 MCP의 세 가지 “프리미티브”

MCP는 세 가지 핵심 프리미티브(primitives)를 정의합니다. 각각 제어권의 귀속이 다릅니다.

Tools(모델 제어). Agent가 능동적으로 호출하는 도구입니다. 예를 들어 “데이터베이스 조회”, “메일 발송” 같은 것입니다. Agent는 작업 요구에 따라 언제 어떤 Tool을 호출할지 결정합니다.

Resources(애플리케이션 제어). 외부 데이터 소스가 Agent에 노출하는 정보입니다. 예를 들어 “회사 지식 베이스”, “고객 파일” 같은 것입니다. Agent가 능동적으로 호출하는 것이 아니라 Resources가 Agent의 컨텍스트로 푸시되거나 인덱싱됩니다.

Prompts(사용자 제어). 사용자가 미리 정의한 지시 템플릿입니다. 예를 들어 “한국어로 공식 비즈니스 메일 작성” 같은 것입니다. 사용자가 특정 Prompt를 선택하면 Agent가 해당 작업을 수행합니다.

이 세 가지 프리미티브의 구분은 본질적으로 제어권의 구분입니다. Tools는 Agent가 결정하고, Resources는 외부 시스템이 결정하며, Prompts는 사용자가 결정합니다.

2.3 MCP가 해결하는 실제 문제

MCP를 쓰기 전과 후를 비교해 보면 몇 가지 통증은 실제로 사라졌습니다.

통증 1: 어댑터 폭증.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

이전: 외부 시스템 하나마다 어댑터 하나, 시스템 열두 개면 코드도 열두 세트였습니다.
지금: 외부 시스템 하나마다 MCP Server 하나를 두고 Agent는 MCP Client를 설정해 호출합니다. 열두 개 Server를 여러 Agent가 공유할 수 있어 재사용률이 올라갑니다.

통증 2: 컨텍스트 단절.

이전: CRM 도구가 반환한 데이터를 메일 도구가 가져오지 못했습니다.
지금: MCP는 통일된 Context 전달 메커니즘을 정의합니다. Agent의 컨텍스트 풀을 모든 도구가 읽고 쓸 수 있습니다. CRM 도구가 고객 이메일을 기록하면 메일 도구가 컨텍스트 풀에서 직접 읽습니다.

통증 3: 도구 정의 혼란.

이전: 도구마다 파라미터 Schema를 제각각 정의했습니다. 어떤 것은 JSON Schema를 쓰고, 어떤 것은 TypeScript interface를 쓰며, 어떤 것은 주석만 남겼습니다.
지금: MCP는 OpenAPI 3.1 호환 Schema를 강제합니다. 형식과 검증이 통일되고, 도구 정의는 표준화된 문서가 됩니다.

통증 4: 프라이빗 배포의 어려움.

이전: 기업 내부 시스템은 시장에 기성 어댑터가 없어 직접 작성해야 했습니다.
지금: MCP Server를 프라이빗하게 배포할 수 있습니다. 기업 내부에 MCP Server 라이브러리를 구축하면 외부 서비스 제공자에 의존하지 않고 데이터 보안을 통제할 수 있습니다.

2.4 2026년 MCP 생태계 현황

2026년 4월 기준 MCP 생태계의 몇 가지 데이터입니다.

• GitHub modelcontextprotocol 조직에는 이미 150개 이상의 오픈소스 MCP Server가 있습니다
• 주요 Agent 프레임워크는 모두 MCP를 지원합니다: LangChain, CrewAI, AutoGen, Semantic Kernel, OpenClaw
• Anthropic이 공식 유지하는 MCP Registry에는 도구, 데이터베이스, API, 파일 시스템 등의 카테고리가 수록되어 있습니다

하지만 반드시 직시해야 할 문제가 있습니다. MCP에는 보안 취약점이 있습니다.

2026년 초 Infosecurity Magazine은 MCP 프로토콜에 시스템적 설계 결함이 있으며 잠재 위험이 150M 다운로드에 영향을 미친다고 공개했습니다. 구체적인 취약점에는 도구 호출 권한 경계의 모호함, 악성 MCP Server가 Agent 컨텍스트 데이터를 탈취할 수 있다는 점이 포함됩니다.

이 부분은 뒤의 보안 장에서 자세히 다루겠습니다. 여기서는 한 가지만 먼저 말하겠습니다. MCP는 완벽한 해법이 아니며, 사용하기 전 보안 평가가 필요합니다.

2.5 MCP 모범 사례(시행착오 요약)

MCP를 반년 넘게 쓰며 몇 가지 함정을 밟았습니다. 세 가지 실천법으로 정리할 수 있습니다.

첫째: 도구 정의는 명확할수록 좋습니다.

MCP는 OpenAPI Schema를 요구하지만, 많은 사람이 모호하게 작성합니다. 예를 들어 어떤 도구의 파라미터 description에 “고객 ID”라고만 쓰고 CRM의 내부 ID인지 외부 번호인지 설명하지 않습니다. Agent가 호출할 때 잘못된 파라미터를 넘기고, 도구는 빈 결과를 반환하며, Agent는 고객을 찾지 못했다고 판단해 작업이 실패합니다.

지금 제 습관은 각 파라미터의 description에 출처, 형식, 예시를 명확히 쓰는 것입니다. 예를 들어 “고객 ID: CRM 시스템의 내부 고유 식별자, 형식은 CUST-XXXXX, 예시: CUST-00123”처럼 씁니다.

둘째: 권한 경계 설계를 먼저 해야 합니다.

MCP의 Tools 프리미티브는 Agent가 능동적으로 호출할 수 있습니다. 하지만 모든 도구를 Agent가 자율 호출하게 해서는 안 됩니다. 예를 들어 “고객 기록 삭제” 같은 작업에 Agent가 자율 권한을 가져서는 안 됩니다.

MCP Server를 설계할 때는 먼저 “자율 호출 가능” 작업과 “사람 확인 필요” 작업을 분리합니다. 전자는 Tools로 노출하고, 후자는 Resources(읽기 전용)나 Prompts(사용자 트리거)로 노출합니다.

셋째: 호출 로그는 반드시 켜야 합니다.

MCP 호출 경로는 Agent → MCP Client → MCP Server → 외부 시스템입니다. 중간에 두 계층이 있어 문제가 생기면 추적하기 어렵습니다.

저는 OpenTelemetry로 체인 추적을 합니다. 호출마다 완전한 trace를 기록합니다. Agent 시작 시간, 파라미터 내용, Server 처리 시간, 반환 결과, 예외 정보를 모두 남깁니다. 문제를 조사할 때 trace 로그를 보는 것이 코드를 추측하는 것보다 훨씬 빠릅니다.

3장: 프레임워크 선택 - 어떤 도구 체인이 내 시나리오에 가장 맞는가

3.1 주요 프레임워크 비교 매트릭스

여기는 바로 핵심만 보겠습니다. 주요 프레임워크의 차이는 다음과 같습니다.

몇 가지 비교 차원을 나누어 보겠습니다.

학습 곡선. LangGraph가 가장 가파릅니다. 상태 그래프, 노드, 엣지, 조건 분기 같은 개념이 많아 익숙해지는 데 일주일 정도 걸립니다. CrewAI는 가장 완만합니다. Agent 역할 몇 개를 정의하고 작업을 배정하면 반나절 만에 실행할 수 있습니다. AutoGen은 중간입니다. 대화형 협업 모델은 직관적이지만 설정 파라미터가 많습니다.

프로덕션 성숙도. LangChain 계열은 오래된 프레임워크라 커뮤니티가 크고 이미 여러 차례 문제가 검증되었습니다. CrewAI는 안정적이지만 기능이 단순화되어 복잡한 시나리오를 버티기 어렵습니다. AutoGen은 초기 버전에서 안정성 문제가 있었고 2026년에 많이 개선되었지만, 여전히 고동시성 프로덕션에는 적합하지 않습니다.

MCP 지원. LangChain과 LangGraph의 MCP 통합이 가장 완전합니다. Tools, Resources, Prompts 세 가지 프리미티브를 모두 지원합니다. CrewAI와 AutoGen은 기본 Tools 호출은 지원하지만 Resources와 Prompts는 직접 어댑터 계층을 작성해야 합니다.

내장 도구 수. LangChain에는 600개 이상의 내장 도구가 있어 주요 API와 데이터베이스를 커버합니다. CrewAI는 약 20개로 흔한 시나리오 중심입니다. AutoGen에는 내장 도구 라이브러리가 없어 모두 직접 정의해야 합니다.

3.2 선택 의사결정 프레임워크

프레임워크 선택에는 “최고”가 없습니다. “가장 적합한 것”만 있습니다. 저는 네 가지 질문으로 결정합니다.

질문 1: Agent가 단일 작업인가요, 다중 Agent 협업인가요?

단일 작업: CrewAI나 LangChain이면 충분합니다.
다중 Agent 협업: LangGraph(상태 그래프 오케스트레이션)나 AutoGen(대화형 협업)이 적합합니다. CrewAI의 Crew 모드도 다중 Agent를 할 수 있지만 오케스트레이션 능력은 약합니다.

질문 2: 빠른 프로토타입이 필요한가요, 프로덕션급 배포가 필요한가요?

빠른 프로토타입: CrewAI입니다. 반나절 만에 실행할 수 있고 데모에는 충분합니다.
프로덕션급 배포: LangGraph입니다. 상태 관리가 엄격하고 LangSmith를 통한 관측 가능성이 완전합니다. CrewAI도 프로덕션에 쓸 수 있지만 복잡한 시나리오에서는 버티기 어렵습니다.

질문 3: 팀의 기술 스택은 무엇인가요?

Python 중심: LangChain, CrewAI, AutoGen, OpenClaw 모두 가능합니다.
.NET / 마이크로소프트 생태계: Semantic Kernel이 Azure와 Visual Studio에 네이티브로 통합됩니다.
JavaScript / TypeScript: LangChain에는 JS 버전이 있지만 생태계는 Python 버전보다 작습니다.

질문 4: 몇 개의 외부 시스템을 연결해야 하나요?

5개 미만: 프레임워크 내장 도구 + 소량의 커스텀 도구로 충분하고 MCP까지 고려할 필요는 없습니다.
5개 초과: MCP 사용을 권합니다. LangChain의 MCP 통합이 가장 완전하며 CrewAI는 직접 어댑터 계층을 써야 합니다.

3.3 조합 전략: 개발자의 84%는 여러 도구를 사용한다

앞에서 언급한 조사에 따르면 개발자의 84%가 여러 AI 코딩 도구를 동시에 사용합니다. 이는 “프레임워크 하나를 고르면 충분하다”가 아니라 조합해서 쓴다는 뜻입니다.

제가 써 본 조합 중 하나는 LangGraph(핵심 오케스트레이션) + CrewAI(작업 실행)입니다.

구체적인 시나리오는 이렇습니다. Agent 시스템에는 요구 분석, 설계안 작성, 코드 생성, 테스트 검증 등 여러 단계가 있습니다. LangGraph는 전체 상태 전이를 관리합니다. 요구 → 설계 → 코드 → 테스트 흐름입니다. 각 단계 내부에서는 CrewAI로 빠르게 실행합니다. CrewAI의 역할-작업 모델은 단일 단계의 병렬 협업에 적합합니다.

이 조합의 논리는 LangGraph가 뼈대(상태 그래프, 조건 분기, 예외 복구)를 담당하고, CrewAI가 근육(단일 단계의 다중 역할 협업)을 담당한다는 것입니다. 뼈대는 성숙한 프레임워크를 고르고, 근육은 가벼운 프레임워크를 고릅니다. 각자의 장점을 취하는 방식입니다.

또 다른 흔한 조합은 IDE Agent(일상 작업) + 터미널 Agent(어려운 문제)입니다.

IDE Agent는 VSCode나 JetBrains 안에 통합되어 일상적인 코드 작성, 리팩터링, 문서 검색에 사용합니다. 터미널 Agent는 독립 프로세스로 복잡한 문제를 처리합니다. 예를 들어 서비스 간 호출 디버깅이나 성능 병목 분석 같은 일입니다. 둘은 MCP로 도구 라이브러리를 공유합니다. IDE Agent가 호출한 도구를 터미널 Agent도 사용할 수 있습니다.

4장: 단일 도구에서 도구 생태계로 가는 진화 경로

이 부분은 제 진화 과정을 예로 들어 네 단계로 나누어 설명하겠습니다.

4.1 1단계: 단일 프레임워크 프로토타입

처음 Agent를 만들 때 저는 CrewAI를 골랐습니다. 이유는 단순했습니다. 문서가 짧고 예제가 명확하며 반나절이면 실행할 수 있었습니다.

그때 요구사항은 아주 단순했습니다. 고객지원 질의응답 Agent 하나가 지식 베이스를 조회하고 자주 묻는 질문에 답하면 됐습니다. CrewAI의 내장 도구로 충분했습니다. 지식 베이스 조회는 Search Tool, 답변은 Response Tool이었습니다.

이 단계의 목표는 먼저 돌아가게 만들고 Agent가 실제 문제를 해결할 수 있는지 검증하는 것입니다. 아키텍처, 확장성, MCP를 고려할 필요는 없습니다. 프로토타입을 만들어 제품 매니저에게 보여주면 됩니다.

제가 밟은 함정은 CrewAI의 기본 설정을 그대로 사용한 것입니다. 나중에 파라미터에 기본값이 있지만 제 시나리오에는 맞지 않는다는 사실을 알았습니다. 예를 들어 지식 베이스 검색의 top_k 파라미터는 기본적으로 결과 5개를 반환했습니다. 제 지식 베이스는 항목이 적어 3개면 충분했습니다. 결과가 많으면 Agent가 혼란스러워했습니다. 이 파라미터가 설정 파일 깊은 곳에 숨어 있다는 것을 찾느라 반나절을 썼습니다.

교훈은 이렇습니다. 프레임워크의 기본 설정이 최적은 아닙니다. 시나리오에 맞게 조정해야 합니다. 프로토타입 단계에서도 문서를 더 읽고 게으름을 피우지 않아야 합니다.

4.2 2단계: 커스텀 도구 개발

프로토타입이 돌아간 뒤 요구사항이 하나 추가되었습니다. Agent가 CRM 시스템에서 고객 정보를 조회해야 했습니다.

CrewAI에는 CRM 내장 도구가 없었기 때문에 직접 작성해야 했습니다. 첫 커스텀 도구를 쓰는 데 반나절이 걸렸습니다. 파라미터 Schema를 정의하고, API 호출 로직을 쓰고, 예외를 처리하고, 로그를 붙였습니다.

첫 번째는 순조로웠습니다. 이후 요구사항이 계속 추가되었습니다. ERP 조회, BI 리포트 조회, 메일 알림 발송, 티켓 생성 등이 붙었습니다.

다섯 번째 커스텀 도구를 작성할 때쯤 문제를 느끼기 시작했습니다.

코드가 중복됩니다. 각 도구의 예외 처리 로직, 로그 형식, 파라미터 검증은 비슷하지만 서로 다른 파일에 흩어져 있습니다. 코드를 재사용하려면 복사해 붙이고 파라미터 이름을 바꿔야 했습니다.

정의가 혼란스럽습니다. 어떤 도구는 JSON Schema로 파라미터를 정의하고, 어떤 도구는 TypeScript interface를 쓰며, 어떤 도구는 주석만 작성했습니다. 형식이 통일되지 않아 Agent가 호출할 때 파라미터를 잘못 넘기기 쉽습니다.

디버깅이 어렵습니다. Agent가 어떤 도구를 호출했는데 빈 결과가 돌아오면 도구가 죽었는지, 파라미터가 틀렸는지, 외부 시스템에 데이터가 없는지 알기 어렵습니다. 도구 로그를 봐야 하지만 로그가 여러 파일에 흩어져 있어 추적이 느립니다.

이 단계의 전환점은 “도구 인터페이스를 통일할 수 없을까”라고 생각하기 시작한 순간입니다.

4.3 3단계: MCP 도입

LangChain 문서를 보다가 MCP 소개를 보고 시도해 보기로 했습니다.

첫 번째 단계는 기존 커스텀 도구 다섯 개를 MCP Server 형식으로 다시 쓰는 것이었습니다.

MCP는 OpenAPI 3.1 호환 Schema를 요구합니다. JSON Schema와 주석을 표준 형식으로 바꾸고, 파라미터 예시, 반환 예시, 오류 코드 정의를 추가하는 데 이틀이 걸렸습니다.

두 번째 단계는 Agent Harness 안에 MCP Client를 통합하는 것이었습니다.

LangChain에는 이미 MCP Client 구현이 있어 설정 몇 줄로 연결되었습니다. 하지만 CrewAI에는 없었기 때문에 제가 직접 MCP Client 어댑터 계층을 작성해야 했습니다. 이 작업에 사흘이 걸렸습니다.

세 번째 단계는 재사용 검증이었습니다.

새 Agent 프로젝트가 CRM을 조회해야 할 때 기존 MCP Server를 그대로 설정했습니다. 코드 한 줄이면 충분했습니다. 어댑터 로직을 다시 쓰거나 파라미터 Schema를 수정할 필요가 없었습니다. 재사용은 실제로 가능했습니다.

이 단계의 이익은 다섯 개 도구를 MCP Server로 다시 쓰고 나면 이후 새 Agent 프로젝트에서는 설정만으로 호출할 수 있다는 점입니다. 재사용률은 올라가고 유지 비용은 내려갑니다.

하지만 비용도 있습니다. 재작성에 이틀, CrewAI용 MCP Client 어댑터에 사흘이 걸렸습니다. 합쳐서 닷새입니다. 커스텀 도구 다섯 개를 쓰는 데 걸린 이틀 반보다 더 길었습니다.

투자 대비 효과 판단: Agent 프로젝트가 하나뿐이라면 MCP는 수지가 맞지 않습니다. 재작성 비용이 이익보다 큽니다. Agent 프로젝트가 여러 개라면 MCP는 가치가 있습니다. 재사용 이익이 재작성 비용을 분산하기 때문입니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

당시 제 판단은 이후 Agent 프로젝트가 더 많아질 것이므로 MCP 투자가 가치 있다는 것이었습니다.

4.4 4단계: 도구 생태계 구축

MCP를 도입한 뒤 내부 MCP Server 라이브러리를 만들기 시작했습니다.

첫 번째 단계: 도구 분류.

기존 도구를 비즈니스 도메인별로 분류했습니다. CRM 계열(고객 조회, 고객 업데이트), ERP 계열(주문 조회, 재고 조회), 알림 계열(메일, SMS, 티켓)입니다. 각 카테고리마다 MCP Server 디렉터리를 만들었습니다.

두 번째 단계: 버전 관리.

각 MCP Server에는 버전 번호(v1.0, v1.1, v2.0)를 둡니다. Agent가 호출할 때 버전을 지정해 도구 업데이트 뒤 Agent 동작이 갑자기 바뀌지 않게 합니다. 저는 Git으로 버전을 관리하고 각 버전을 하나의 브랜치로 둡니다.

세 번째 단계: 호출 모니터링.

OpenTelemetry Tracing을 붙여 MCP 호출마다 완전한 경로를 기록했습니다. 모니터링 대시보드에서 호출 빈도, 평균 지연, 예외율, 실패 도구 순위를 볼 수 있습니다. 어떤 도구에 문제가 생겼는지 한눈에 보입니다.

네 번째 단계: 권한 거버넌스.

“고객 기록 삭제” 작업은 Tools로 노출하지 않고 Resources(읽기 전용)로만 노출합니다. Agent는 고객 조회를 자율 호출할 수 있지만 고객 삭제는 반드시 사람이 확인해야 합니다.

이 단계의 목표는 “도구 라이브러리”를 “도구 거버넌스 체계”로 바꾸는 것입니다. 도구는 단순한 코드가 아니라 라이프사이클, 모니터링, 권한 경계를 가진 자산이 됩니다.

4.5 5단계: 다중 Agent 협업(저는 아직 여기까지 가지 않았습니다)

계획 중인 다음 단계는 단일 Agent에서 다중 Agent 오케스트레이션으로 가는 것입니다.

이 영역에서는 LangGraph의 상태 그래프 모델이 주류입니다. 여러 Agent 노드를 두고 상태 그래프로 전이 조건, 분기 논리, 예외 복구를 정의합니다.

도구 체인 쪽에서는 다중 Agent 협업에 두 가지 새 문제가 생깁니다.

도구 공유 vs 권한 격리.

여러 Agent가 같은 MCP Server를 공유하지만 각자 권한은 다릅니다. 예를 들어 Agent A는 CRM을 조회할 수 있고 Agent B는 ERP를 조회할 수 있지만, 서로 상대방의 도구를 호출하면 안 됩니다.

이 부분에서는 MCP 권한 경계 설계가 선행 조건입니다. 4단계에서 해 두었다면 5단계에서 바로 재사용할 수 있습니다.

상태 전달.

Agent A가 CRM을 호출해 고객 이메일을 찾았고, Agent B가 이 이메일로 메일을 보내야 합니다. 상태는 어떻게 전달할까요?

LangGraph의 상태 풀은 모든 Agent 노드가 공유합니다. MCP의 컨텍스트 메커니즘도 도구 간 상태를 전달할 수 있습니다. 두 가지를 결합하면 상태 전달이 가능합니다.

이 부분은 아직 조사 중이라 여기서는 더 길게 펼치지 않겠습니다.

5장: 엔터프라이즈 도입 - 개념에서 프로덕션으로

5.1 금융 시나리오: 보험 청구 파이프라인

은행에서 일하는 친구가 2026년에 보험 청구 Agent를 만들었습니다.

시나리오: 고객이 보험금 청구를 제출하면 Agent가 자동으로 처리합니다. 보험 계약 조회, 의료 기록 조회, 지급 금액 계산, 청구 보고서 생성, 고객 알림까지 이어집니다.

도구 체인 설계:

• 보험 계약 조회 MCP Server: 보험 핵심 시스템에 연결
• 의료 기록 MCP Server: 병원 데이터 인터페이스에 연결
• 계산 엔진 MCP Server: 내부 지급 규칙 라이브러리
• 알림 MCP Server: 메일 + SMS + APP 푸시

아키텍처:

LangGraph가 상태 전이를 관리합니다. 신청 → 보험 계약 조회 → 의료 조회 → 계산 → 보고서 → 알림 흐름이고, 각 노드 안에서 MCP Server를 호출합니다.

이익:

보험 청구 처리 시간이 평균 3일에서 8시간으로 줄었습니다. 사람 개입률은 40%에서 15%로 낮아졌습니다. 대부분의 표준화된 청구는 Agent가 자동 처리하고 복잡한 케이스만 사람이 검토합니다.

밟은 함정:

컴플라이언스 감사입니다. 금융 시나리오에서는 모든 도구 호출에 감사 기록을 남겨야 합니다. 그들은 MCP Server에 감사 계층을 추가했습니다. 호출마다 시간, 호출자, 파라미터, 반환 결과, 감사자 ID를 기록합니다.

SLA 보장도 필요했습니다. 보험 청구 Agent에는 SLA 요구사항이 있었습니다. P99 응답 <872ms(SITS2026이 정의한 3단계 임계값)입니다. 그들은 MCP Server 성능 최적화를 했습니다. 보험 계약 데이터 캐싱, 의료 인터페이스 비동기 호출, 지급 금액 사전 계산을 적용했습니다.

5.2 고객지원 시나리오: Voice Agent 도구 생태계

2026년 고객지원 영역의 AI Agent 침투율은 72%에 도달했습니다.

한 지능형 고객지원 업체는 Voice Agent를 만들었습니다. 고객이 전화를 걸면 Agent가 직접 처리하고 상담원에게 넘기지 않습니다.

도구 체인 설계:

• CRM MCP Server: 고객 정보와 주문 기록 조회
• 주문 MCP Server: 주문 상태와 물류 정보 조회
• 티켓 MCP Server: 애프터서비스 티켓 생성과 처리 진행 조회
• 지식 베이스 MCP Server: 제품 문서와 FAQ 조회

아키텍처:

Voice Agent는 Semantic Kernel을 사용합니다. Azure Speech Services와 통합되고, MCP Client가 네 개 Server를 호출합니다.

성능 데이터:

• 평균 응답 시간: 500ms
• 자율 처리율: 85%(고객 문제는 Agent가 직접 해결하고 15%만 상담원에게 전환)
• 상담원 개입 후 처리 시간: 순수 상담원 처리 대비 30% 단축

기술 포인트:

응답 속도가 핵심입니다. Voice Agent는 고객을 오래 기다리게 하면 안 됩니다. 그들의 MCP Server는 모두 로컬 캐시를 두었습니다. 인기 제품 FAQ처럼 자주 조회되는 데이터는 Agent 메모리에 캐싱하고, MCP 호출 시 먼저 캐시를 확인한 뒤 캐시 미스일 때 외부 시스템을 호출합니다.

5.3 제조업 시나리오: 설비 점검 Agent

제조 기업에 있는 친구는 설비 점검 Agent를 만들었습니다.

시나리오: 공장 설비를 정기 점검하고 Agent가 센서 데이터를 자동 수집해 설비 상태를 판단합니다. 점검 보고서를 생성하고 이상이 있으면 자동으로 수리를 요청합니다.

도구 체인 설계:

• 센서 MCP Server: IoT 데이터 플랫폼에 연결
• 설비 파일 MCP Server: 설비 유지보수 기록 조회
• 수리 요청 MCP Server: 유지보수 티켓 생성과 담당자 알림
• 보고서 MCP Server: 점검 보고서 생성과 보관

아키텍처:

CrewAI가 Agent 본체를 담당합니다. 점검 작업이 구조화되어 있기 때문입니다. MCP Client는 네 개 Server를 호출합니다.

이익:

점검 효율이 40% 향상되었습니다. 사람이 점검하면 2시간 걸리던 일이 Agent로는 45분이 걸렸습니다. 누락 점검률은 5%에서 1%로 줄었습니다. Agent가 센서 데이터를 자동으로 수집하므로 센서를 빠뜨리지 않습니다.

밟은 함정:

IoT 데이터 형식이 엉망이었습니다. 장비마다 센서 데이터 형식이 달랐습니다. 어떤 것은 JSON, 어떤 것은 CSV, 어떤 것은 사유 바이너리 프로토콜이었습니다. 그들의 센서 MCP Server는 형식 어댑터 계층을 두어 모두 JSON으로 통일한 뒤 Agent에 전달했습니다.

5.4 기업 도입의 공통 요소

몇 가지 시나리오에는 공통점이 있습니다. 작게 시작하고 통증에서 출발한다는 것입니다.

금융 Agent는 “보험 청구 프로세스를 뒤엎자”가 아니라 “청구 시간을 줄이자”에서 시작했습니다. 고객지원 Agent는 “상담원을 대체하자”가 아니라 “자율 처리율을 높이자”에서 출발했습니다. 제조 Agent는 “공장 전체를 자동화하자”가 아니라 “점검 단계를 최적화하자”에서 시작했습니다.

2026년의 업계 공감대는 Agent의 ROI 기대치를 현실로 되돌려야 한다는 것입니다. “모든 것을 뒤엎는다”가 아니라 “구체적인 문제를 해결한다”입니다.

도입의 핵심 요소는 다음과 같습니다.

요소 1: SLA가 명확해야 합니다.

금융 Agent에는 SLA(P99 <872ms)가 있고, 고객지원 Agent에는 SLA(평균 <500ms)가 있습니다. Agent 도구 체인은 SLA를 버틸 수 있어야 합니다. 캐시, 비동기, 사전 계산은 모두 이를 위한 수단입니다.

요소 2: 감사와 컴플라이언스.

금융과 고객지원 시나리오에서는 모든 도구 호출에 기록을 남겨야 합니다. MCP Server에 감사 계층을 추가하는 것이 표준입니다.

요소 3: 작은 범위에서 시작.

처음부터 큰 Agent 시스템을 만들지 마세요. 구체적인 시나리오 하나를 고르고 단일 Agent를 만들어 이익을 검증한 뒤 확장하세요.

요소 4: 3-6개월 주기.

Agent 도입은 일주일 만에 끝나는 일이 아닙니다. 금융 친구의 프로젝트는 프로토타입에서 프로덕션까지 6개월이 걸렸습니다. 고객지원 친구의 프로젝트는 4개월, 제조 친구의 프로젝트는 3개월이 걸렸습니다. 기대치를 합리적으로 잡아야 합니다.

6장: 보안과 거버넌스 - 도구 체인의 “레드라인”

6.1 MCP 보안 취약점 경고

이 부분은 진지하게 말해야 합니다. MCP는 완벽한 해법이 아니며, 2026년 초 보안 취약점이 공개되었습니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

Infosecurity Magazine의 보고서에 따르면 MCP 프로토콜에는 시스템적 설계 결함이 있고 잠재 위험이 150M 다운로드에 영향을 미칩니다.

취약점 1: 도구 호출 권한 경계가 모호합니다.

MCP의 Tools 프리미티브는 Agent가 자율적으로 호출할 수 있습니다. 하지만 프로토콜 자체는 권한 경계를 정의하지 않습니다. 악성 MCP Server가 “모든 데이터 삭제” 같은 위험한 작업을 노출할 수 있고, Agent가 인지하지 못한 채 호출할 수 있습니다.

취약점 2: 컨텍스트 데이터 유출.

MCP의 컨텍스트 메커니즘은 모든 도구가 읽고 쓸 수 있습니다. 악성 MCP Server는 Agent의 컨텍스트 데이터를 읽을 수 있습니다. 여기에는 사용자 입력, 다른 도구가 반환한 민감 정보가 포함됩니다.

취약점 3: 공급망 공격.

오픈소스 MCP Server에는 악성 코드가 있을 수 있습니다. 개발자가 GitHub에서 MCP Server를 내려받고 감사 없이 사용하면, 악성 Server가 데이터를 훔치거나 반환 결과를 변조할 수 있습니다.

6.2 도구 체인 보안 설계 원칙

저는 MCP를 쓸 때 세 계층의 보안 방어를 추가했습니다.

첫 번째 계층: 의도 명확성.

MCP의 도구 정의에는 “이 도구가 무엇을 하는지”, “어떤 위험이 있는지”가 명확히 쓰여 있어야 합니다. 저는 OpenAPI의 description 필드를 사용해 각 도구에 보안 설명을 씁니다.

예를 들어 “고객 기록 삭제” 도구의 description에는 이렇게 씁니다. “CRM의 고객 기록을 삭제합니다. 작업은 되돌릴 수 없으며 사람의 확인이 필요합니다. 호출 전 권한 검토가 필요합니다.”

Agent는 도구를 호출하기 전에 description을 읽고 위험을 압니다. 그런 다음 자율 호출할지, 사람 확인으로 넘길지 결정합니다.

두 번째 계층: 상태 격리성.

MCP의 컨텍스트 풀은 모든 도구가 읽고 쓸 수 있습니다. 이 부분에 저는 격리를 적용했습니다. 각 MCP Server에는 독립 컨텍스트 영역을 두고, 다른 Server의 영역을 읽거나 쓸 수 없게 했습니다.

Agent가 CRM 도구를 호출해 반환한 데이터는 CRM 도구와 메일 도구만 읽을 수 있습니다. 수리 요청 도구 같은 다른 도구는 읽을 수 없습니다. 민감 데이터가 확산되지 않습니다.

세 번째 계층: 관측 가능성 우선.

모든 MCP 호출에 완전한 trace를 기록합니다. 호출자, 파라미터, 반환, 예외를 남깁니다. OpenTelemetry Tracing은 표준입니다.

문제가 생기면 trace 로그를 보고 빠르게 위치를 찾습니다. 보안 감사에서도 trace 로그는 증거가 됩니다.

6.3 엔터프라이즈급 거버넌스 프레임워크

기업 내부 MCP Server 라이브러리에는 거버넌스 프레임워크가 필요합니다.

거버넌스 1: 라이프사이클 관리.

각 MCP Server에는 버전 번호, 출시 시간, 책임자, 의존성 목록이 있습니다. 도구 업데이트는 심사 프로세스를 거칩니다. 새 버전을 아무렇게나 푸시하지 않습니다.

Agent는 호출할 때 버전을 고정합니다. 자동 업그레이드하지 않아 동작 변화를 피합니다.

거버넌스 2: 호출 감사.

모든 MCP 호출은 감사 로그를 기록합니다. 시간, 호출자, 파라미터, 반환, 감사자를 남깁니다. 금융 시나리오에서는 이것이 컴플라이언스 요구사항입니다.

거버넌스 3: SLA 모니터링.

MCP Server의 응답 시간, 예외율, 가용성을 지속적으로 모니터링합니다. SLA가 기준을 충족하지 못하면 알림을 보내고 자동으로 강등합니다. 예를 들어 예비 Server로 전환합니다.

거버넌스 4: 권한 매트릭스.

Agent 역할 vs 도구 권한 매트릭스를 둡니다. Agent A는 CRM 도구를 호출할 수 있고 Agent B는 호출할 수 없습니다. 작업 유형 vs 권한 매트릭스도 둡니다. “조회” 작업은 Agent가 자율 호출할 수 있고, “삭제” 작업은 사람 확인이 필요합니다.

이 거버넌스 프레임워크는 저는 문서 하나로 관리합니다. MCP Server마다 한 페이지를 두고 버전 이력, 권한 매트릭스, 감사 요구사항, SLA 목표, 책임자를 기록합니다.

정리

길게 이야기했지만 핵심은 몇 가지입니다.

첫째, 도구 체인 설계는 Agent가 “장난감”에서 “생산성 도구”로 넘어가는 분기점입니다.

프로토타입 단계에서는 단일 도구로 충분합니다. 프로덕션 단계에서는 도구 생태계가 필수입니다. 도구 생태계가 없으면 Agent는 20%의 시나리오만 해결할 수 있습니다. 도구 생태계가 있으면 80%를 해결할 수 있습니다.

둘째, MCP는 AI 시스템의 “USB 표준”이 되어 가고 있으며 학습할 가치가 있습니다.

2026년에 MCP 생태계는 성숙했고 주요 프레임워크가 모두 지원합니다. 하지만 MCP는 완벽한 해법이 아닙니다. 보안 취약점이 있으므로 사용 전 평가해야 합니다. 이익(재사용, 거버넌스)과 비용(재작성, 보안)을 비교해야 합니다.

셋째, 프레임워크 선택은 시나리오에 달려 있으며, 2026년의 주류는 단일 선택이 아니라 조합입니다.

LangGraph는 복잡한 프로덕션에, CrewAI는 빠른 프로토타입에, AutoGen은 다중 Agent 대화에 적합합니다. 단일 프레임워크로 부족하면 조합해서 사용합니다. 개발자의 84%가 이미 그렇게 하고 있습니다.

넷째, 기업 도입의 핵심은 현실성입니다. 작은 범위에서 시작하고 통증에서 출발해야 합니다.

금융 Agent는 보험 청구 단계에서, 고객지원 Agent는 Voice 시나리오에서, 제조 Agent는 점검 단계에서 시작했습니다. ROI 기대치는 현실로 돌아왔고, 3-6개월 주기와 SLA 및 감사가 표준입니다.

실행 제안

Agent 시스템을 만들고 있다면 다음 제안을 참고하세요.

첫 번째 Agent 프로토타입 단계라면:

CrewAI를 선택해 반나절 안에 실행해 보세요. 내장 도구 + 소량의 커스텀 도구를 사용합니다. MCP는 잠시 미루고, 먼저 Agent가 실제 문제를 해결할 수 있는지 검증하세요.

다중 Agent 협업이 필요하다면:

LangGraph + MCP가 안정적인 선택입니다. LangGraph는 상태 전이를 관리하고 MCP는 도구 재사용을 관리합니다. 투입 비용은 중간 정도이며 장기적으로 이익이 분산됩니다.

이미 단일 도구를 갖고 있지만 요구사항이 복잡해졌다면:

MCP Server 라이브러리를 계획하세요. 커스텀 도구를 MCP Server로 다시 쓰면 초기 비용은 크지만 이후 재사용 이익이 비용을 분산합니다. 전제는 여러 Agent 프로젝트가 있어 재사용할 가치가 있다는 것입니다.

기업 프로덕션을 목표로 한다면:

금융, 고객지원, 제조업 사례를 참고하세요. SLA를 명확히 하고, 감사와 컴플라이언스를 갖추며, 작은 범위에서 시작하고, 3-6개월 주기를 잡으세요. 보안 거버넌스를 먼저 설계하고 도구 권한 경계는 선행 조건으로 다뤄야 합니다.