흩어져 있는 AI 자산, ‘MCP stdio’로 헤쳐모여!

1 week ago 10

우리는 여러 사람이 각자의 장비로 여러 개의 서비스와 저장소를 관리하고, 또한 여러 개의 도구를 사용합니다. 모두가 다른 환경에서 각자 작업하면서도, 일관된 방식으로 일을 하거나 결과물을 만드는 것은 아주 중요한 만큼 우리에게 익숙한 과정입니다.

AI 자산이란?
여기서 자산이란 영어 단어 assets를 번역한 표현입니다. 일반적으로 쓰이는 용어는 아니나 이 문서에서는 AI 도구를 활용하기 위해 작성하는 여러 종류의 문서나 스크립트, 예를 들면 시스템 프롬프트, 스킬, 페르소나 등을 총칭합니다.

AI 자산도 이를 피해 갈 수 없습니다.

제한된 사용량을 피해 이 도구 저 도구를 유랑하다 보면, 혹은 여러 저장소에서 이 프롬프트 저 프롬프트를 복사해서 사용하다 보면, 어느 것이 최신 프롬프트인지, 어떤 스킬이 유용했는지 구분하기 어려워집니다. 더욱이 이런 AI 자산은 아주 긴 마크다운 문서, 혹은 복잡한 스크립트로 작성되어 있기 때문에 일일이 내용을 살펴보며 그 용도나 버전을 파악해 내기가 아주 피곤합니다.

흩어져 있는 여러 AI 자산을 중앙화하여 관리하고, 구성원들이 걱정 없이 최신화된 AI 자산을 언제 어디서든 쉽게 사용할 수 있는 방법, 있지 않을까요?

AI 자산 중앙화를 구현하는 대표적인 방법으로는 Agent Sync와 MCP stdio가 있습니다.

본 문서에서는 두 방식의 장담점을 비교하고, 특히 완전한 중앙화 모델에 더 가까운 MCP stdio의 활용법과 실무 경험을 공유하고자 합니다.

Agent Sync

Agent Sync는 중앙 저장소에 AI 자산 파일을 관리하고, 각 프로젝트로 다운로드하는 방식입니다.

필요할 때에 사용자가 사용처에서 명령어를 실행하여 중앙에서 관리하는 AI 자산을 로컬로 다운로드하고, 다운로드한 AI 자산을 에이전트를 통해 활용할 수 있습니다.

장단점

Agent Sync를 사용하면 다운로드한 파일이 로컬에 있어 프롬프트 내용을 바로 확인할 수 있고, 필요하면 목적에 따라 쉽게 커스텀할 수 있습니다. 다만 자동으로 동기화되지 않기 때문에 버전 차이로 팀의 규칙이 쉽게 무너질 수 있으며, 동일한 자산이 여러 저장소에 중복되어 생성되기 때문에 체계적인 관리가 어렵습니다.

MCP stdio

MCP 서버를 만들고 AI 자산을 각 사용처에서 사용하는 방식입니다. 더불어 MCP에서 지원하는 여러 통신 수단 중 하나인 stdio(표준 입출력)를 사용하여 MCP 서버를 운용하는 비용과 난이도를 최소화합니다.

최초 한 번, 사용자의 AI 도구에 MCP 서버를 등록해두면 자동으로 최신 버전의 AI 자산을 에이전트를 통해 활용할 수 있습니다.

stdio란?
stdio는 Standard Input/Output의 약어로, HTTP가 네트워크 소켓을 이용한다면 stdio는 Linux의 기본 입출력 통로인 stdin과 stdout을 활용합니다. 덕분에 별도의 서버 구축 없이도 운영체제의 표준 스트림을 활용하여 복잡한 네트워크 설정 없이 로컬 프로세스 간의 데이터 통신을 구축할 수 있습니다.

장단점

MCP stdio를 사용하면 중앙에서 한 번 배포한 여러 IDE/CLI 환경에 빠르게 최신 자산을 일관되게 적용할 수 있습니다. 또한 표준 MCP 설계를 사용하기 때문에 텍스트 프롬프트뿐 아니라 도구 호출, 로컬/외부 연동 같은 실행 로직까지 함께 확장하기 쉽습니다.

이 방식은 MCP를 지원하는 도구에서만 사용할 수 있다는 제약이 있으나, 최근에는 많은 도구들이 기본적으로 지원하고 있습니다. 또한 Agent Sync에 비해 AI 자산의 개별 커스텀은 어렵지만, 관리의 중앙화라는 본연의 목적을 달성하기에는 더욱 적합합니다.

한눈에 비교해 볼까요?

구분 Agent Sync MCP stdio
핵심 방식 중앙 자산을 로컬 파일로 복제 중앙 패키지를 실행 시점에 직접 로드
장점 파일 가시성 높음, 로컬 커스텀 쉬움, 오프라인 사용 가능 최신 자산 자동 반영, 저장소 오염 적음, 도구 확장 용이
단점 수동 동기화 누락 시 드리프트, 파일 중복 관리 부담 MCP 지원 도구 필요, 로컬에서 자산 내용 확인/수정 어려움
추천 상황 로컬 커스텀 편의성, 별도의 설정 없이 간단하게 사용하는 경우 중앙 통제와 최신성, 확장성을 우선하는 경우

우리는 비교적 작은 규모의 조직에서 최신의 AI 자산을 걱정 없이 사용할 수 있는 환경을 희망하고 있습니다. 이 경우는 MCP stdio 방식이 적절해 보입니다. 그럼 MCP stdio를 구현하고 사용하는 방법을 간단하게 알아볼까요?

MCP stdio는 중앙 패키지 준비 - 패키지 배포 - IDE MCP 등록 - 에이전트 사용 순서로 구현하고 사용할 수 있습니다.

1. 중앙 패키지 구성

예를 들어 몇 가지 코딩 규칙과 스킬을 포함하는 패키지의 폴더 구조를 다음과 같이 설계할 수 있습니다.

central-mcp-agent/ ├── rules/ │ └── coding-standards.md ├── skills/ │ ├── dependency-search.md │ └── commit-impact-analysis.md ├── src/ │ └── index.ts └── package.json

1-1. AI 자산 모으기

central-mcp-agent/ ├── rules/ 👈 ├── skills/ 👈 ...

흩어져 있는 AI 자산을 중앙 저장소의 rules/* 혹은 skills/* 위치에 적절하게 옮겨옵니다.

자산은 마크다운 형태의 단순 문서가 될 수도 있고, 스크립트를 포함한 스킬이 될 수도 있습니다. MCP 표준을 따르기 때문에 에이전트가 이해할 수 있는 어떠한 형태의 자산도 포함될 수 있습니다.

1-2. MCP stdio 서버 엔트리 작성

central-mcp-agent/ ├── ... ├── src/ │ └── index.ts 👈 ...

src/index.ts는 IDE와 stdio로 통신하는 MCP 서버의 시작점입니다. 어떤 리소스 문서를 노출할지, 요청 시 어떤 내용을 반환할지를 이 파일에서 연결합니다.

보통 아래 순서로 구성합니다.

  1. MCP Server 생성
  2. resources 핸들러 등록
  3. MCP Server 실행
import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { ListResourcesRequestSchema, ReadResourceRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; /* 1. MCP Server 생성 */ const server = new Server( { name: "ai-assets-mcp", version: "1.0.0" }, { capabilities: { resources: {} } }, ); /* 2. `resources` 핸들러 등록 */ server.setRequestHandler(ListResourcesRequestSchema, async () => { const assets = await loadAssets([ "./rules/coding-standards.md", "./skills/dependency-search.md", "./skills/commit-impact-analysis.md", ]); return { resources: assets, }; }); /* 2. `resources` 핸들러 등록 */ server.setRequestHandler(ReadResourceRequestSchema, async (request) => { const asset = await loadAsset(request.params.uri); return { contents: [asset], }; }); /* 3. MCP Server 실행 */ async function main() { const transport = new StdioServerTransport(); await server.connect(transport); console.error("Weather MCP Server running on stdio"); } main();

  • 본 예제에서는 가시성을 위해 직접 마크다운 파일을 리소스로 등록했습니다. 실제로는 skills/*.md 혹은 rules/*.md 위치에 존재하는 파일을 파일시스템으로 탐색하고 그대로 노출하여 마크다운 문서만 추가하면 새로운 자산이 추가되도록 편의성을 고려합니다.
  • 본 예제에서는 resources 핸들러만 사용하였지만, 도구에 따라 MCP를 지원하는 범위가 다르므로 동일한 자산을 사용하되 prompts 핸들러를 추가로 구성하는 것도 좋습니다.

2. npm 패키지 배포

central-mcp-agent/ ├── ... └── package.json 👈

중앙 저장소를 사내 레지스트리 또는 npm 레지스트리에 npm 패키지의 형태로 배포합니다.

{ "name": "@example/ai-assets-mcp", "version": "0.1.0", "private": false, "type": "module", "description": "Centralized MCP stdio package for shared agent rules and document-based skills.", "main": "./dist/index.js", "bin": { "ai-assets-mcp": "./dist/index.js" }, ... }


이 문서에서는 프론트엔드 개발자에게 익숙한 npm 기반 환경을 사용했습니다. Java, Python 등 다른 운영 방식이 궁금하다면 Model Context Protocol 기술 가이드에서 쉽게 확인할 수 있습니다.

3. IDE에 MCP 서버 등록

사용하는 도구에서 배포한 npm 패키지를 MCP 서버로 아래와 같이 등록합니다.

{ "mcpServers": { "ai-assets-mcp": { "command": "npx", "args": ["-y", "@example/ai-assets-mcp@latest"] } } }

  • Cursor는 ~/.cursor/mcp.json 파일에 위 JSON을 추가하면 프로젝트와 관계없이 모두 일관되게 MCP 서버를 사용할 수 있습니다.
  • Claude Code는 CLI를 통해서 MCP 설정을 추가할 수 있습니다. 자세한 방법은 Claude Code 공식 문서를 통해 확인하실 수 있습니다.
  • 패키지의 버전으로 @latest를 사용하면, 개발자가 별도 동기화 명령을 실행하지 않아도 다음 실행 시 최신 자산을 사용하게 됩니다.

4. 에이전트에서 리소스 사용

개발자는 평소처럼 / 커맨드를 사용하여 에이전트에게 요청하면 됩니다. 에이전트를 통해 연결된 AI 자산의 목록을 확인하거나, 코드베이스에서 도구를 실행할 수 있습니다. 정상적으로 연동되었다면 아래 스크린샷처럼 각 도구에서 AI 자산을 확인할 수 있습니다.

기본적으로 모든 구성원은 MCP 서버를 각자의 AI 도구에 설정해 사용합니다.

필요에 따라 로컬에서 자신만의 새로운 규칙이나 스킬을 만들어 활용하기도 합니다. 그리고 주기적인 팀 미팅에서 자신이 만든 스킬이 팀에 유용하다고 생각되면 제안하고 중앙 저장소 반영 여부를 함께 결정합니다.

모든 AI 자산을 중앙화하여 관리할 필요는 없습니다.

다만 팀의 커뮤니케이션이나 워크플로에 영향을 주는 자산이라면 중앙 저장소 반영을 우선적으로 고려합니다. 예를 들어 코드 병합 문서를 생성하는 스킬은 중앙화했을 때 효과가 큽니다. 코드 리뷰 가독성이 높아지고, 팀 생산성 향상에도 도움이 됩니다.

기본적으로 MCP 서버이기 때문에 다른 MCP 서버를 도구로 내재하도록 설정할 수도 있습니다.

회사에서 사용하는 여러 도구에서 제공하는 MCP 서버들을 엮어서 구성해두면 Wiki에서 기획서 읽기 - 코드 작성하기 - Git 저장소에 MR 작성하기처럼 팀에 적합한 워크플로를 만들어 많은 부분을 한 번에 자동화할 수도 있습니다.

MCP는 에이전트가 실행할 수 있는 프로토콜이기 때문에, 에이전트가 필요하지 않다고 판단하면 실행되지 않을 수 있습니다.

이 구조적 한계 때문에 로컬에 있는 프롬프트처럼 모든 에이전트의 동작에 대해 반드시 실행되도록 강제하는 것은 어렵습니다. 따라서 MCP 내에 공통된 규칙을 작성해 두더라도, 모든 에이전트 실행이 이를 참조한다고 보장할 수는 없습니다.

이 한계는 로컬에 있는 프롬프트도 동일하게 존재합니다. 다만 그 확률이 낮을 뿐입니다. 따라서 MCP를 사용하면서 겪는 이 한계점도 로컬 프롬프트의 문제와 동일한 방식으로 보완할 수 있습니다.

예를 들어 Cursor를 사용한다면 상단에 YAML 프론트 매터를 추가하고 AI 자산 MCP를 항상 사용하도록 하는 프롬프트를 로컬에 추가하여 에이전트의 실행 시 최대한 MCP 규칙의 실행을 보장할 수 있습니다. 다만 컨텍스트양이 늘어나는 트레이드오프는 반드시 고려해야 합니다.

--- description: 에이전트 기본 행동 지침 (언어, 포맷팅) globs: ["*"] alwaysApply: true --- # Prerequisites - MUST: 코드 작성 전 `ai-assets-mcp/rule.coding-standards`를 반드시 참조한다.

팀의 AI 자산을 중앙화하여 관리하고, 구성원들이 어려움 없이 최신화된 AI 자산을 사용할 수 있는 환경을 MCP stdio 방식으로 구현하는 방법을 알아보았습니다.

이 방법은 구성원 간의 원활한 소통이 가능한 소규모 조직에서 AI 자산을 체계적으로 관리하기에 가장 적합합니다. 각 팀의 자율성이 중요하고 느슨한 중앙화를 목표로 한다면 Agent Sync 방식이 보다 나은 해결책일 것입니다.

AI의 발전 속도가 너무나 빠르기에 이 방법 역시도 금방 필요하지 않은 시점이 올지도 모르겠습니다. 다만 먼저 중앙화를 구축해 두면 변화하는 시점에 더 나은 방법으로 빠르게 갈아탈 수 있는 데에 도움이 되겠지요!

  • 우아한형제들 웹 프런트엔드 개발자
    손으로 무언가를 만드는 걸 좋아하다 보니 쓰고 그리고 만들다가 개발을 하고 있습니다.

Read Entire Article