본문으로 건너뛰기

Vespa Cloud용 공개 MCP 서버 구축기

Vespa Cloud MCP server가 CLI보다 적은 시도로 애플리케이션 운영에 성공한 과정을 기록했습니다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Vespa의 네 인턴은 Claude나 Codex 같은 AI assistant가 Vespa Cloud 애플리케이션을 배포하고 조회하며 로그와 Grafana 지표를 확인할 수 있는 공개형 Model Context Protocol server prototype을 만들었습니다. 서버는 API를 그대로 노출하지 않고 상대 시간, 심각도 필터, 반복 로그 병합, 응답 크기 제한 같은 인터페이스를 제공해 LLM의 잘못된 호출과 불필요한 context 사용을 줄입니다. 파일 업로드와 장시간 배포 작업에는 MCP의 한계가 있어 별도 HTTP upload endpoint와 timeout을 사용했으며, Data Plane 인증은 애플리케이션별 token 문제로 아직 production 수준에 이르지 못했습니다. 세 차례 평가에서 MCP agent는 결정론적 검증 97%로 Vespa CLI agent의 95%를 앞섰고, 성공 배포까지 평균 시도 횟수도 1.40 대 2.87로 적었지만, 공개 출시 전 security review와 다중 tenant 인증 보완이 남아 있습니다.

섹션별 상세

01
Model Context Protocol은 AI assistant와 외부 시스템 사이의 인터페이스를 Resources, Tools, Prompts로 표준화합니다. Vespa Cloud는 이 중 Tools와 Resources를 중심으로 Control Plane 기능을 공개형 standalone server에 연결해 Claude나 Codex가 사용자의 tenant와 애플리케이션을 다루도록 구성했습니다. 애플리케이션별로 서버를 다시 배포하거나 각 개발자 컴퓨터에 로컬 서버를 설치할 필요가 없다는 점이 이 구조의 핵심 이점입니다.
LLM과 Vespa 사이에 MCP Server가 위치한 구조를 단순화한 그림입니다.
Diagram이미지는 LLM이 MCP Server를 중간 인터페이스로 거쳐 Vespa Cloud에 연결되는 양방향 구조를 나타냅니다. 글의 standalone MCP server는 이 연결을 통해 Vespa Cloud의 배포, 조회, 검사, 관측 기능을 AI assistant의 tool 호출로 바꿉니다.
MCP server가 LLM에 schema 조회, documentation 조회, query 실행 기능을 연결하는 개념도입니다.
Diagram그림은 MCP server가 LLM과 여러 실행 가능한 기능 사이의 연결점으로 작동하는 구조를 나타냅니다. Get schemas, Get documentation, Execute query 같은 tool이 분리돼 있어 agent가 시스템의 기능을 발견하고 단계적으로 호출하는 글의 tool design 논지와 연결됩니다.
02
MCP tool의 품질은 API 기능의 개수보다 LLM이 올바른 입력과 순서를 선택하도록 인터페이스를 다듬는 데 좌우됩니다. `vespa_get_logs`는 epoch milliseconds 대신 `now-1h` 같은 상대 시간과 ISO 8601 문자열을 받고, 심각도 필터와 concise 또는 detailed 응답을 선택하게 하며, 반복 이벤트를 `count`와 `first_seen`으로 합칩니다. 이 처리는 대량 로그를 그대로 context에 넣어 추론 지연과 token 비용을 키우는 문제를 줄이고, 필요할 때만 상세 정보를 요청하게 만듭니다.
python
@mcp.tool(...)
async def vespa_get_logs(...):
    """Search a deployed instance's logs.
    Defaults to warning-and-above from the last hour.
    Repeated events (identical except for their timestamp) are collapsed into one entry carrying `count` and `first_seen`.
    The response is capped to a fixed size budget; when it overflows, the oldest events drop first.
    Args:
        start_time: Start of the time range. Accepts relative expressions ("now-1h", "now-7d") or ISO datetime strings. Defaults to "now-1h".
        end_time: End of the time range. Accepts the same formats as start_time. Defaults to "now".
        min_level: Minimum severity, most-to-least severe: fatal, error, warning, info, config, event, debug, spam. Pass "info" for normal logs, None for all.
        contains: Case-insensitive substring over service, component, and message.
        limit: Max events returned, most recent kept (default: 100, range: 1-100). Values outside this range are clamped and reported in the response warnings.
        detail: "concise" (time, level, service, message) or "detailed" (adds host, pid, component).
        ...
    """

로그 시간 범위와 심각도에 따라 결과를 요약하거나 상세 로그로 반환하는 MCP tool의 인터페이스입니다.

03
MCP server는 Vespa CLI를 감싼 수준을 넘어 도구의 입력 구조, 오류 메시지, 허용된 작업을 통제하고 Grafana 지표처럼 CLI에 없는 기능도 추가합니다. 사용자는 애플리케이션의 목적을 자연어로 입력하고, LLM이 schema를 만들고 배포한 뒤 검색 결과를 조정하도록 할 수 있으며, 운영자는 여러 지표와 로그를 묶어 scaling 필요성이나 노드 재시작 원인을 확인하게 할 수 있습니다. 실제 실험에서 LLM은 17번의 tool call로 active documents 증가가 노드 재시작과 관련 있음을 찾아냈습니다.
LLM prompt를 이용해 Vespa 검색 애플리케이션을 생성하고 검색 화면을 구성하는 시연 화면입니다.
Screenshot화면은 LLM assistant에 검색 애플리케이션을 요청하고 생성된 블로그 검색 페이지를 확인하는 흐름을 담고 있습니다. 본문에서 자연어 요구만으로 Vespa Cloud application과 웹 페이지를 만들고 연결한 사례와 직접 이어집니다.
Vespa Cloud의 Grafana dashboard에서 health와 resource pressure 지표를 조회하는 화면입니다.
Screenshot화면에는 Core Dumps, Restarts, Feed Blocked, 노드 가용성과 resource pressure 같은 운영 지표가 패널로 표시됩니다. MCP server는 이 Grafana panel의 구조, 설명, 시간별 데이터를 LLM이 조회하도록 연결해 scaling과 장애 원인 파악에 활용합니다.
LLM assistant에 Vespa 애플리케이션의 scaling 필요성을 묻는 대화 화면입니다.
Screenshot화면은 애플리케이션을 scale up해야 하는지 자연어로 질문하는 사용 흐름을 보여줍니다. 본문에서는 LLM이 여러 resource usage metric을 조회한 뒤 upscaling이 필요하지 않다고 판단한 실험으로 이어집니다.
LLM assistant에 active documents 수가 갑자기 증가한 원인을 묻는 디버깅 화면입니다.
Screenshot화면은 특정 Vespa application의 active documents 급증 원인을 자연어로 질문하는 상황을 담고 있습니다. 본문에서 LLM은 17번의 tool call로 metrics, deployments, logs를 확인해 content node 재시작과 Vespa Cloud host의 작업 가능성을 연결했습니다.
04
MCP의 파일 업로드와 장시간 작업 모델은 prototype 구현에서 병목이 됐습니다. 파일을 JSON에 넣으면 매번 전체 package를 다시 작성해야 하고 binary 파일을 다루지 못했으며, Base64 방식은 LLM의 정확한 복사에 취약해 별도 HTTP endpoint에서 zip package를 `curl`로 업로드하는 방식을 선택했습니다. 배포 tool은 token을 아끼기 위해 결과를 기다리되 timeout을 두었고, 이후 추가된 long-running tasks 기능이 널리 채택되면 이 구조를 바꿀 계획입니다.
05
공개 MCP server의 가장 큰 보안 공백은 애플리케이션별 token이 필요한 Data Plane 접근입니다. Control Plane은 Auth0와 OAuth proxy로 연결했지만, Data Plane은 테스트 tenant의 사전 생성 token을 고정하는 임시 방식을 사용해 여러 tenant로 확장할 수 없으며 token을 tool parameter로 받는 방법은 안전하지 않고 MCP spec에도 맞지 않습니다. 따라서 현재 prototype은 Control Plane 중심으로 공개 가능성을 검토하는 단계이고, security review와 안전한 tool guardrail 설계가 선행돼야 합니다.
06
MCP의 효과는 최종 성공률만으로 판단하기 어려워 실제 API 결과를 확인하는 결정론적 검증과 작업 과정을 평가하는 LLM judge를 함께 사용했습니다. 세 차례 전체 평가에서 MCP agent는 deterministic assertions 97%, Vespa CLI agent는 95%를 통과했으며, 성공 배포까지 평균 시도 횟수는 MCP 1.40회, CLI 2.87회였습니다. MCP는 tool discovery와 description을 context에 유지하는 비용을 추가하지만, 이 비용을 사전에 지불해 잘못된 CLI 명령과 복구 작업을 줄이는 방식으로 더 복잡한 작업에서 이점이 커질 수 있습니다.
MCP server와 Vespa CLI agent의 검증 통과율, 시나리오 성과, rubric 점수, 성공 배포 시도 횟수를 비교한 그래프입니다.
Chart그래프는 MCP의 deterministic assertions가 97%, CLI가 95%였고, 평균 rubric score가 94% 대 90%였음을 나타냅니다. 성공 배포까지의 평균 시도 횟수도 MCP 1.40회, CLI 2.87회로 표시돼 MCP가 tool discovery 비용을 치르는 대신 잘못된 경로를 줄였다는 본문의 결론을 뒷받침합니다.

용어 해설

Model Context Protocol
Model Context Protocol은 LLM과 외부 데이터·시스템·환경을 연결하는 개방형 표준입니다. 서버가 Resources, Tools, Prompts라는 인터페이스를 제공하면 호환되는 AI assistant가 별도 통합 없이 기능을 호출할 수 있습니다. 이 글에서는 Vespa Cloud의 애플리케이션 관리와 관측 기능을 연결하는 통로로 사용됩니다.
Control Plane
Control Plane은 애플리케이션과 배포 같은 Vespa Cloud 관리 작업을 처리하는 영역입니다. 이 글의 MCP server는 Auth0 기반 인증을 재사용해 사용자의 애플리케이션 접근 권한을 확인하고, 공개 서버에서 안전하게 제공할 수 있는 기능의 중심으로 삼습니다.
Data Plane
Data Plane은 배포된 Vespa Cloud 애플리케이션에 실제로 질의하는 영역입니다. 애플리케이션별 토큰이 필요해 Control Plane 인증만으로는 접근할 수 없으며, 글의 prototype은 사전 생성 토큰을 고정하는 임시 방식에 머물러 다중 tenant와 production 사용을 지원하지 못합니다.
OAuth Proxy
OAuth Proxy는 클라이언트 요청을 인증 시스템으로 전달하면서 인증 흐름을 중간에서 연결하는 서버입니다. Vespa MCP server는 클라이언트를 먼저 등록한 뒤 Auth0로 넘겨 Control Plane 접근 권한을 부여하는 구조를 사용합니다.
Grafana
Grafana는 시간 범위별 운영 지표를 패널 형태로 조회하는 관측 도구입니다. Vespa Cloud Console의 Grafana endpoint를 MCP tools에 연결하면 LLM이 리소스 사용량, 노드 상태, 재시작과 같은 지표를 로그 및 배포 정보와 함께 조회할 수 있습니다.
결정론적 검증(Deterministic Assertion)
결정론적 검증은 실제 API 상태와 기대 결과를 직접 비교하는 평가 방식입니다. 애플리케이션 존재 여부, 노드 상태, 배포된 schema의 field 같은 사실을 고정된 조건으로 확인하므로 LLM judge가 놓칠 수 있는 결과 검증을 보완합니다.
LLM Judge
LLM Judge는 정답 하나를 고정하기 어려운 agent의 도구 사용 과정을 rubric에 따라 평가하는 별도 언어 모델입니다. 이 글에서는 올바른 개념을 선택했는지와 실제 문제를 해결했는지를 판단하며, API로 직접 확인할 수 있는 사실은 결정론적 검증에 맡깁니다.

기술

  • Model Context Protocol
  • Vespa Cloud
  • Vespa CLI
  • Grafana
  • Auth0
  • Python
  • Java
  • Claude
  • Codex
  • HTTP
  • OAuth
  • Base64
  • curl

활용 사례

  • 자연어만으로 Vespa Cloud 검색 애플리케이션 생성과 배포
  • 로그 필터링과 반복 이벤트 요약을 통한 애플리케이션 디버깅
  • Grafana 지표와 배포 기록을 이용한 scaling 판단
  • 노드 재시작으로 인한 active documents 변화 추적
  • MCP server와 Vespa CLI를 비교하는 agent 평가
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 09. 13.수집 2026. 09. 13.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.