software

Virtual MCP Server 소개: 다중 MCP 워크플로를 위한 통합 게이트웨이

발행: (2025년 12월 12일 오전 12:59 GMT+9)
10 min read
원문: Dev.to

Source: Dev.to

문제: 연결 과부하

상황을 상상해 보세요. 여러분은 플랫폼 팀의 엔지니어이고, AI 비서는 코드용 GitHub, 티켓용 Jira, 알림용 Slack, 인시던트용 PagerDuty, 메트릭용 Datadog, 인프라용 AWS, 문서용 Confluence, 그리고 내부 지식 베이스 등 8개의 별도 MCP 서버에 접근해야 합니다. 각각은 10‑20개 이상의 도구를 노출합니다. 이제 AI의 컨텍스트 창은 80개가 넘는 도구 설명으로 가득 차 토큰을 소모하고, LLM이 방대한 목록 중에서 올바른 도구를 선택하는 데 어려움을 겪으며 성능이 저하됩니다.

각 MCP 서버 연결에는 다음이 필요합니다.

  • AI 클라이언트에서 개별 설정
  • 별도 인증 자격 증명
  • 여러 시스템에 걸친 작업 시 수동 조정
  • 동일한 파라미터 반복 입력(같은 레포, 같은 채널, 같은 데이터베이스)
  • 컨텍스트 부피와 토큰 낭비를 방지하기 위한 도구 필터링

프로덕션 인시던트를 조사하고 싶나요? 4개의 서로 다른 시스템에서 명령을 수동으로 실행하고 결과를 직접 조합해야 합니다. 앱을 배포하고 싶나요? PR 병합 → CI 대기 → 승인 요청 → 배포 → 팀에 알림 순서로 작업을 조율해야 합니다. 이는 번거롭고 오류가 발생하기 쉬우며 재사용이 어렵습니다.

해결책: 모든 것을 하나로 통합

vMCP는 이 8개의 연결을 하나로 변환합니다. 백엔드 서버들을 모두 집계하는 단일 MCP 엔드포인트를 설정하면 됩니다.

vMCP 이전:

{
  "servers": {
    "github": { "url": "..." },
    "jira": { "url": "..." },
    "slack": { "url": "..." },
    "pagerduty": { "url": "..." },
    "datadog": { "url": "..." },
    "aws": { "url": "..." },
    "confluence": { "url": "..." },
    "docs": { "url": "..." }
  }
}

vMCP 사용 시:

{
  "servers": {
    "company-tools": {
      "url": "http://vmcp.company.com/mcp"
    }
  }
}

하나의 연결, 하나의 인증 흐름, 모든 도구를 사용할 수 있습니다.

필요한 만큼 vMCP 인스턴스를 실행할 수 있습니다. 프론트엔드 팀은 자신들의 특정 도구와 연결된 하나의 vMCP에, 플랫폼 팀은 인프라 접근이 가능한 다른 vMCP에 연결합니다. 각 vMCP는 해당 팀이 필요로 하는 백엔드만 정확히 집계하며, 적절한 보안 정책과 권한을 적용합니다. 이는 보안을 강화하고(모두에게 모든 접근 권한을 부여하지 않음) 효율성을 높입니다(도구 수가 줄어 컨텍스트 창이 작아지고 토큰 비용이 감소, AI 성능이 향상).

vMCP가 하는 일

vMCP는 ToolHive Kubernetes Operator의 일부입니다. AI 클라이언트와 백엔드 MCP 서버 사이에 위치하는 지능형 집계 레이어 역할을 합니다.

Diagram of the basic vMCP architecture

1. 도구 필터링을 통한 다중 서버 집계

모든 MCP 도구가 단일 엔드포인트를 통해 나타나지만, 노출할 도구를 정확히 선택할 수 있습니다.

  • 예시: ToolHive 팀의 엔지니어는 다음과 같은 단일 vMCP 연결을 가집니다.
    • GitHub의 search_code 도구(오직 stacklok/toolhive 레포에만 제한)
    • ToolHive docs MCP 서버
    • Google Drive에 연결된 내부 docs 서버(ToolHive 설계 문서에만 필터링)
    • Slack(오직 #toolhive-team 채널만)

불필요한 도구가 LLM 컨텍스트를 어지럽히지 않으며, 사용되지 않는 도구 설명에 토큰이 낭비되지 않습니다.

여러 MCP 서버에 동일한 이름의 도구가 있을 경우(예: GitHub와 Jira 모두 create_issue 보유), vMCP는 자동으로 접두사를 붙입니다(github_create_issue, jira_create_issue). 필요에 따라 이름을 커스터마이징할 수 있습니다.

2. 선언형 다중 시스템 워크플로우

실제 작업은 종종 여러 시스템을 조율해야 합니다. vMCP는 조건부, 오류 처리, 승인 게이트를 포함한 병렬 실행 워크플로우를 정의할 수 있게 해줍니다.

인시던트 조사 워크플로우

→ 로깅 시스템에서 로그 조회
→ 모니터링 플랫폼에서 메트릭 가져오기
→ 트레이싱 서비스에서 트레이스 추출
→ 클라우드 제공자에서 인프라 상태 확인
→ 모든 정보를 수동으로 보고서에 결합
→ 조사 결과로 Jira 티켓 생성

vMCP는 쿼리를 병렬로 실행하고 데이터를 집계한 뒤 티켓을 생성합니다. 워크플로우를 한 번 정의하면 모든 인시던트에 재사용할 수 있습니다.

앱 배포 워크플로우

→ GitHub에서 풀 리퀘스트 병합
→ CI 테스트 통과 대기
→ 인간 승인 요청(MCP elicitation 사용)
→ 승인된 경우에만 배포
→ Slack에 팀 알림

3. 사전 구성된 기본값 및 가드레일

같은 파라미터를 반복 입력할 필요가 없습니다. vMCP에서 기본값을 한 번만 설정하면 됩니다.

  • 전: 모든 GitHub 쿼리에서 repo: stacklok/toolhive를 지정해야 함
  • 후: 레포가 사전 구성되어 있어 잘못된 레포에 쿼리하는 실수를 방지

기본값을 사전 구성하면 동작이 결정적이고, 보안 및 일관성이 보장됩니다.

4. 도구 커스터마이징 및 보안 정책

타사 MCP 서버는 종종 일반적이고 제한 없는 도구를 노출합니다. vMCP는 업스트림 서버를 수정하지 않고도 이를 래핑하고 제한할 수 있게 해줍니다.

  • 보안 정책 적용 – 웹사이트‑fetch 도구를 내부 도메인(*.company.com)에만 제한하고, 호출 전 URL을 검증하며 위반 시 명확한 오류 메시지를 제공합니다.
  • 단순화된 인터페이스 – 20개 이상의 파라미터를 가진 복잡한 AWS EC2 도구를 래핑해 프론트엔드 팀이 필요한 세 파라미터만 노출하고, 나머지는 안전한 기본값으로 설정합니다.

5. 중앙 집중식 인증

vMCP는 두 경계 인증 모델을 구현하고 완전한 감사 로그를 제공합니다. AI 클라이언트는 공식 MCP 사양에 정의된 OAuth 2.1 방식을 사용해 vMCP에 한 번 인증합니다. 이후 vMCP는 각 백엔드의 요구에 따라 독립적으로 권한을 부여합니다.

접근을 취소해야 할 경우, 아이덴티티 제공자에서 사용자를 비활성화하면 모든 백엔드 접근이 즉시 차단됩니다.

실제 효과

vMCP 없이

  • 순차적인 수동 명령 4개
  • 명령당 2‑3 분 소요
  • 결과 집계 및 포맷에 5‑10 분
  • 인시던트당 총 15‑20 분
  • 엔지니어마다 결과가 다르고, 프로세스가 문서화·재사용되지 않음

vMCP와 함께

  • 하나의 명령으로 워크플로우 실행
  • 병렬 처리: 약 30 초
  • 자동 집계 및 포맷
  • 매번 일관된 결과
  • 워크플로우가 코드 형태로 문서화되어 팀원 누구나 사용 가능

주당 20건의 인시던트를 처리하는 팀이라면, 시간 절감 효과는 주당 약 5 시간에 달하며, 토큰 비용 감소와 더 신뢰할 수 있는 인시던트 대응을 동시에 얻을 수 있습니다.

Back to Blog

관련 글

더 보기 »