MCP, AI 애플리케이션의 표준화 노력 하지만 완벽한 해결책은 아냐

MCP는 마법의 만병통치약이 아니다 - 향후 인공지능 기술로 MCP는 아직 마법의 만병통치약은 아닙니다. MCP 웨이브가 잦아들면서, MCP 프로토타입을 구축하면서 얻은 교훈들을 현실적으로 검토할 시간이 된 것입니다. 이 글은 인터넷에 이미 많은 자료가 있으므로, MCP의 핵심 구성요소와 실용적인 관련성, 그리고 앞으로의 방향을 간략히 설명하겠습니다. MCP란 무엇인가? MCP는 LLM(대형 언어 모델) 에이전트와 상호작용하기 위한 표준 사양을 설정하는 프로토콜입니다. MCP의 주요 구성 요소는 무엇인가? - MCP 서버: 원격 서버에서 LLM 에이전트에게 리소스, 프롬프트, 도구를 게시하도록 설계된 메커니즘입니다. - MCP 클라이언트: MCP 서버에 연결되어 LLM 인터페이스에 결합하여 예상 결과를 달성하도록 설계된 객체입니다. - MCP 호스트: 사용자가 MCP 클라이언트와 상호작용할 수 있는 최종 애플리케이션(네이티브 또는 웹)입니다. - 전송 계층: 클라이언트와 서버 간 통신을 위한 표준으로, 로컬 프로세스에서는 Stdio, 클라이언트-서버 및 서버-클라이언트 통신에서는 HTTP와 SSE를 지원합니다. 즉, MCP 서버는 LLM 애플리케이션을 엔지니어링하는 표준입니다. LLM 에이전트란 무엇인가? LLM 에이전트는 "고도화된 컨텍스트 엔지니어링"을 위한 추상화입니다. 이 부분에 대해 별도의 글을 작성할 가치가 있지만, 이미 많은 내용이 논의되었습니다. 따라서, MCP는 기본적으로 '컨텍스트 엔지니어링'을 위한 표준입니다! MCP가 기업용 AI 애플리케이션에 어떤 이점을 제공하나? 일반적인 기업 애플리케이션은 내부 및 외부의 다양한 서비스에 연결되어 다양한 비즈니스 결과를 위한 포괄적(종종 복잡한) 솔루션을 제공해야 합니다. MCP는 이러한 서비스 간 일관성을 제공하여 LLM 애플리케이션이 원활하게 작동할 수 있도록 합니다. 입력 컨텍스트(리소스)와 출력 액션(도구)뿐만 아니라 프롬프트를 통해 호출 클라이언트에게 특정 지침을 제공할 수 있습니다. MCP는 클라이언트(LLM 앱)와 분산 서버(리소스와 도구를 제공하는 원격 서비스)를 분리한 아키텍처를 제공합니다. 이는 모듈성과 확장성을 높이며, LLM 앱이 다양한 서비스에 동적으로 연결될 수 있도록 '플러그 앤 플레이' 서비스를 가능하게 합니다. 즉, 서버에 추가되거나 제거되는 서비스를 최종 클라이언트 애플리케이션에 큰 영향을 미치지 않고 동적으로 발견할 수 있게 합니다. 그렇다면 MCP는 정말 AI 애플리케이션의 만병통치약인가? MCP가 제공하는 위의 장점들은 확실히 필요하지만, 개발자들이 고려해야 할 몇 가지 핵심 문제는 MCP 스펙을 넘어서 있습니다. 리소스/도구 폭발: LLM 에이전트가 올바른 리소스나 도구를 선택하거나 복잡한 문제를 해결하기 위한 계획을 생성하는 방법을 어떻게 가르치나? 이는 모든 AI 애플리케이션의 핵심 과제로, RAG, 함수 호출, 미세 조정, 추론 시간 확장 등의 다양한 해결책이 제시되고 있습니다. MCP 스펙으로 LLM 에이전트를 이전한다고 해서 이러한 근본적인 도전이 해결되지는 않습니다. 하지만, 모델이 컨텍스트 제한과 함수 호출 능력을 확장하면서 이러한 혁신이 빠르게 진행되고 있어, MCP 서버/도구 집합이 이에 희망을 걸고 있습니다. 다중 에이전트 시스템에서 MCP의 역할: 여러 에이전트가 상호작용하는 시스템에서 MCP와 에이전트 레지스트리는 아직 로드맵 항목입니다. 그러나, 다양한 디자인 패턴을 탐색해 보았습니다. 여러 MCP 서버의 도구를 단일 DB인 사용자 정의 MCP 레지스트리에 저장하여 RAG 기반 도구 발견을 가능하게 하는 방법입니다. 이는 좋은 아이디어지만, 여전히 문제 해결의 선택 폭이 넓다는 점에서 고려해야 합니다. 각 MCP 서버를 독립적인 에이전트로 취급하고, 애플리케이션이 계층적으로 요청을 처리하여 자체 도구와 리소스를 관리하는 모듈화된 에이전트를 구축하는 방법입니다. 그러나, 이는 현재 시점에서 가능한 한계입니다. 워크플로우 스타일 실행 vs 단순 위임: 대부분의 기업 시나리오에서 AI 워크플로우가 완전 자율 에이전트보다 산업 채택을 주도하고 있습니다. 순차적인 흐름 관리, 중간 개입 및 승인, 상태 관리 등을 지원하기 위해 에이전트 협력이 필요합니다. MCP 서버를 활용해 이러한 워크플로우를 지원하는 진정한 에이전트를 구축하는 것은 여전히 도전적인 과제로, 로드맵 항목(상호 작용형 워크플로우, 에이전트 그래프 등)으로 남아 있습니다. 서버 발견: 에이전트 생태계가 성장함에 따라, 다양한 에이전트와 상호작용하여 최종 목표를 달성하는 것이 필수적입니다. 에이전트 수가 증가하면(인터넷의 웹사이트처럼), 에이전트 발견은 구글 같은 솔루션을 요구하는 다음 큰 이슈가 될 것입니다. MCP 아키텍처는 표준의 기반을 마련했으며, MCP 서버의 동적 도구 및 리소스 업데이트를 가능하게 했습니다. 그러나 에이전트 자체의 동적 발견에 대한 강력한 솔루션은 여전히 로드맵 항목(MCP 레지스트리)입니다. 중앙 레지스트리가 허브-앤-스포크 모델을 지원하는 것처럼, 산업에서는 피어-투-피어 에이전트 발견을 가능하게 하는 다른 표준이 등장하고 있습니다. 마지막으로, 눈앞의 코끼리: MCP 서버의 보안, 안전성, 거버넌스: 이미 보안 결함과 필요한 위험 완화 계획에 대해 많은 논의가 이루어졌습니다. 생산 등급 배포를 고려한다면, MCP를 사용할 때 신중하게 접근해야 합니다. 보안은 본인 스스로 책임져야 합니다. MCP 서버는 자체 인증 계층, 신뢰 관리(사용자와 에이전트, 에이전트 간), 세션 관리, AI 모델 탈옥 대책 등을 통해 알려진 위험을 완화해야 합니다. 이러한 측면을 MCP 클라이언트, 호스트, 서버 주변에 엔지니어링하는 것은 필수적입니다. 일부는 MCP 로드맵의 일부이지만, 그때까지 개발팀이 이를 채워야 합니다. 결론적으로, MCP는 에이전트 세계의 산업 표준을 설정하고 생각의 리더십을 선도하는 위치에 있습니다. 개발자 커뮤니티의 광범위한 채택을 통해 더욱 발전하고 채택될 가능성이 높습니다. 현재의 장점과 단점(임시적으로)을 고려해 개발자들에게 권장할 수 있는 것은 옵션을 평가하고 신중한 결정을 내리는 것입니다. 추가 보안 조치 등이 마련된 상태에서 이를 선택하는 것이 더 바람직합니다. MCP 이후로 더 많은 표준이 등장했으며, 가까운 미래에 더 많은 표준이 등장할 것으로 예상됩니다. MCP는 에이전트의 내부 연선에 대한 표준을 정의하는 데 좋은 출발을 했지만, 진정한 에이전트 간 상호작용을 위한 표준의 발전이 시급합니다. 이 부분에 대한 여러분의 의견과 실험 결과를 들어보는 것이 좋겠습니다. 부록: - https://www.latent.space/p/why-mcp-won - https://techcommunity.microsoft.com/blog/microsoft-security-blog/understanding-and-mitigating-security-risks-in-mcp-implementations/4404667 - https://equixly.com/blog/2025/03/29/mcp-server-new-security-nightmare/