Ruby UTCP — The scalable, secure alternative to MCP for tool calling
Ruby UTCP — MCP를 대체하는 확장 가능하고 안전한 도구 호출 프로토콜
Ruby UTCP는 AI 에이전트가 별도의 래퍼 서버 없이 JSON 매니페스트로 네이티브 API와 도구를 호출하도록 하는 Universal Tool Calling Protocol(UTCP) 1.1의 Ruby 구현입니다. HTTP, CLI, WebSocket, gRPC, GraphQL, MCP, WebRTC 등 12개 전송 방식을 지원해 Ruby 애플리케이션에서 도구 검색·인증·스트리밍·다중 도구 워크플로를 표준화하려고 합니다.
- 주제
AI 요약
Ruby UTCP는 AI 에이전트가 다양한 도구를 같은 방식으로 검색하고 호출할 수 있도록 하는 Universal Tool Calling Protocol(UTCP) 1.1의 Ruby 구현입니다. 소개문은 UTCP를 Model Context Protocol(MCP)에 대한 가벼운 대안으로 제시하며, 애플리케이션과 에이전트가 네이티브 프로토콜을 직접 사용하도록 해 별도의 래퍼 계층에서 발생하는 지연과 구현 부담, 이른바 “wrapper tax”를 줄이는 것을 핵심 방향으로 설명합니다.
■ JSON 매니페스트로 네이티브 API 직접 호출
Ruby UTCP의 기본 사용 방식은 도구 목록과 호출 정보를 담은 단순한 JSON 매니페스트를 연결 지점으로 사용하는 것입니다. 일반적인 방식처럼 도구마다 별도의 래퍼 서버를 세우는 대신, 매니페스트를 통해 HTTP API나 CLI 같은 기존 네이티브 인터페이스를 직접 호출할 수 있다고 설명합니다. 이 구조에서는 AI 에이전트가 어떤 도구를 사용할 수 있는지 표준화된 방식으로 발견하고, 각 도구가 제공하는 네이티브 전송 계층을 그대로 이용할 수 있습니다.
페이지는 UTCP를 플러그인 프로토콜로도 설명합니다. 도구가 HTTP API인지, CLI인지, 또는 다른 전송 방식을 사용하는지와 관계없이 애플리케이션이 동일한 방식으로 호출할 수 있도록 하는 것이 목적입니다. UTCP 1.0.0에서는 작은 핵심 사양(lean core), 프로토콜 플러그인, 더 정리된 설정 구조를 제공해 도구 사용 규모가 커질 때 팀이 접착 코드(glue code)를 직접 관리해야 하는 부담을 줄이려 했다고 소개합니다.
■ 12개 전송 방식과 부가 기능
Ruby UTCP는 HTTP, CLI, WebSocket, gRPC, GraphQL, MCP, WebRTC를 포함해 총 12개의 전송 방식(transports)을 지원한다고 밝히고 있습니다. 한 라이브러리 안에서 여러 전송 계층을 다룰 수 있도록 하며, 여기에 스트리밍(streaming), 인증(auth), OpenAPI 기반 도구 검색(OpenAPI discovery), CodeMode를 함께 제공합니다. CodeMode는 여러 도구를 조합하는 프로그래밍 가능한 다중 도구 워크플로를 위한 기능으로 설명됩니다.
따라서 이 프로젝트가 제공하려는 범위는 단순한 Ruby용 호출 클라이언트에 그치지 않습니다. 도구를 발견하는 과정, 인증이 필요한 호출, 결과를 스트리밍하는 방식, 여러 도구를 하나의 프로그래밍 가능한 흐름으로 연결하는 작업까지 UTCP 규격 안에서 다루려는 구성입니다. 프로젝트는 오픈 소스로 제공되며 Ruby 생태계에서 AI 에이전트와 도구 사이의 연결 방식을 표준화하는 것을 목표로 합니다.
■ MCP와 비교되는 통합 방식
소개문은 MCP가 일상적인 도구와 LLM을 연결하는 사용성을 확산시키는 데 기여했다고 평가하면서도, UTCP는 처음부터 더 나은 사양과 보안을 갖춘 방향으로 확장하려 한다고 설명합니다. 특히 Ruby 환경에서는 MCP를 사용할 때 별도의 서버 프로세스를 실행해야 하는 경우가 일반적이라고 언급하며, UTCP의 매니페스트 기반 접근은 이 계층을 건너뛰고 네이티브 전송 방식으로 직접 호출할 수 있다는 점을 차이점으로 제시합니다.
다만 페이지의 설명은 MCP를 완전히 배제하는 방식만을 제안하지는 않습니다. UTCP가 MCP 전송도 지원하는 목록에 포함하고 있으며, 소개 내용에는 UTCP 표준이 MCP와 함께 구현되기를 바란다는 관점도 담겨 있습니다. 즉, 현재 익숙한 MCP 기반 도구와의 연결 가능성을 남겨 두면서, 도구 호출을 별도의 클라이언트·서버 구조에만 의존하지 않는 선택지를 제공하려는 형태입니다.
■ 문서와 실제 도입 시 고려할 점
커뮤니티 소개 내용에서는 12개 전송 방식을 각각 설명하는 문서는 잘 갖춰져 있지만, 사용 사례에 따라 어떤 전송 방식을 선택해야 하는지 안내하는 결정 가이드가 추가되면 좋겠다고 지적합니다. MCP와 비교해 도입을 검토하는 개발자에게는 HTTP, CLI, WebSocket, gRPC, GraphQL, WebRTC 등 여러 선택지 가운데 어떤 방식을 골라야 하는지가 초기 평가의 핵심이 될 수 있기 때문입니다.
또한 여러 전송 방식을 하나의 오픈 소스 라이브러리에서 일관되게 유지해야 한다는 점도 소개 내용에서 언급됩니다. 페이지는 이처럼 넓은 지원 범위가 문서상으로는 대체로 정리되어 있다고 설명하지만, 실제 사용자는 각 전송 방식의 특성과 인증·스트리밍 지원 여부, OpenAPI 검색 및 CodeMode의 적용 범위를 사용 사례별로 확인해야 합니다. Ruby 애플리케이션에서 AI 에이전트가 여러 종류의 기존 도구를 호출해야 하고, 별도 래퍼 서버 없이 구성하려는 경우를 주요 적용 대상으로 제시하는 프로젝트입니다.
■ 관련 제품 Hexis
같은 소개에는 Hexis도 함께 언급됩니다. Hexis는 회사의 AI 스킬, 도구, 지식을 Git 위에서 중앙 관리하는 계층으로 설명되며, 검토와 접근 제어를 거친 내용을 어떤 AI 에이전트에서도 사용할 수 있도록 하는 제품입니다. Hexis는 내부적으로 UTCP를 도구 호출에 사용한다고 밝히고 있어, UTCP가 개별 애플리케이션의 호출 라이브러리뿐 아니라 조직 차원의 AI 도구 관리 계층에도 연결될 수 있음을 보여주는 사례로 제시됩니다.
원문: Product Hunt / 번역·요약: Trawling