단일 MCP (Model Context Protocol) 서버를 통해 284개의 서로 다른 AI 도구를 서비스할 때 직면하는 아키텍처 과제는... 여러분이 예상하는 것과는 다릅니다.

저는 약 1년 동안 CHROMATIC-MCP를 운영해 왔습니다. 실제 운영 환경에서 제대로 작동하는 멀티 스킬 AI 플랫폼을 구축하며 배운 점들을 공유합니다.

컨텍스트 윈도우 (Context Window) 문제

284개의 도구를 보유했을 때 가장 먼저 무너지는 부분은 바로 tools/list 응답입니다. 대부분의 AI 클라이언트는 컨텍스트 윈도우 (Context Window) 제한을 가지고 있습니다. 만약 284개의 도구 설명을 한꺼번에 쏟아부으면, 사용자가 질문을 던지기도 전에 가용 컨텍스트의 40%를 소진하게 됩니다.

우리의 해결책: 2계층 디렉토리 (Two-layer directory)

{
  "tools": [
    {"name": "discover_skills", "description": "카테고리 또는 키워드로 사용 가능한 스킬 검색"},
...

클라이언트는 처음에 약 10개의 도구만 봅니다. 특정 기능이 필요할 때, 전체 카탈로그를 검색하기 위해 discover_skills를 호출합니다. 이를 통해 컨텍스트 오버헤드(Context overhead)를 12K 토큰에서 2K 미만으로 줄였습니다.

프롬프트 엔지니어링 (Prompt Engineering)보다 중요한 설명 엔지니어링 (Description Engineering)

여기서 직관에 반하는 교훈이 있습니다. 도구 내부의 프롬프트 (Prompt)보다 도구의 설명 (Description)이 더 중요하다는 점입니다.

AI 모델은 오로지 설명을 바탕으로 당신의 도구를 호출할지 여부를 결정합니다. 나쁜 설명은 곧 보이지 않는 도구를 의미합니다.

효과가 없었던 사례:

"description": "성격 분석"

효과가 있었던 사례:

"description": "MBTI 성격 코칭 - 사용자의 MBTI 유형(예: INFJ, ENTP)이 주어지면, 맞춤형 커리어 조언, 관계 통찰력 및 개인적 성장 전략을 제공합니다. 입력: {type: string, question: string}. 구조화된 코칭 응답을 반환합니다."

호출률을 개선한 핵심 요소들:

1. 그것이 무엇인지(명사구)로 시작할 것
2. 입력 형식을 명시적으로 설명할 것
3. 출력이 어떤 모습인지 설명할 것
4. 설명 자체에 2~3개의 예시 사용 사례를 포함할 것

우리는 50개의 스킬에 대해 설명(Description)을 A/B 테스트했습니다. 좋은 설명은 호출률을 3~4배 증가시켰습니다.

로컬 실행 (Execute-Locally) 패턴

모든 스킬이 서버 측 LLM 실행을 필요로 하는 것은 아닙니다. 50개의 무료 스킬의 경우, 우리는 "로컬 실행 (execute-locally)" 패턴을 사용합니다:

1. 클라이언트가 스킬 이름과 함께 tools/call을 호출합니다.
2. 서버는... SKILL.md 문서를 반환합니다 (LLM 응답이 아님).
3. 클라이언트 자체의 LLM이 해당 문서를 지침 (instructions)으로 사용합니다.
4. 실행은 전적으로 클라이언트 측에서 이루어집니다.

이는 다음과 같은 의미를 갖습니다:

• 무료 스킬에 대한 서버 측 컴퓨팅 비용 제로 (Zero server-side compute cost)
• 사용자가 어떤 로컬 모델 (Ollama, ChatGLM 등)로도 실행 가능
• 무료 티어의 경우 API 키가 필요 없음
• 완전한 개인정보 보호 - 사용자의 기기 외부로 아무것도 나가지 않음

과금 (Billing): 토큰 단위가 아닌 작업 단위

우리는 의도적으로 토큰 단위 (per-token) 대신 작업 단위 (per-task) 과금을 선택했습니다:

• 작업 성공 → 과금 (복잡도에 따라 ¥1.29-6.99)
• 작업 실패, 타임아웃, 또는 쓰레기 값 생성 → 과금 없음

구현에는 "완료 인증서 (completion certificate)" 패턴을 사용합니다:

요청 (Request) → 처리 (Processing) → 검증 게이트 (Validation Gate) → 인증서 발급 (Certificate Issued) → 과금 트리거 (Billing Triggered)
                         ↓
                    실패 (Failure) → 인증서 없음 (No Certificate) → 과금 없음 (No Charge)

이는 인센티브를 일치시킵니다. 우리는 작업이 성공하기를 원하고 (그래야 수익이 발생하므로), 사용자는 실험하는 것에 두려움을 느끼지 않습니다 (실패는 무료이므로).

프로덕션 모니터링 (Monitoring in Production)

284개의 스킬을 운영하려면 관측 가능성 (observability)이 필요합니다. 우리의 설정은 다음과 같습니다:

• 스킬 호출당 JSONL 구조화된 로그
• 주요 지표 (Key metrics): call_count, success_rate, p95_latency, certificate_issued
• 주간 파레토 분석 (Pareto analysis): 상위 20개 스킬이 트래픽의 80%를 차지함

현재 수치 (솔직하게):

• 일일 요청 약 500건
• 작업 성공률 85%
• P95 지연 시간 (latency): <2초
• 대부분의 트래픽은 미국에서 발생 (중국 내수 성장을 위해 작업 중)

내가 다르게 했을 것들

1. 더 적은 스킬로 시작하기. 284개는 유지보수의 지옥입니다. 20개로 시작하여 그것들을 완벽하게 만든 다음 확장하세요.
2. 초기에 설명 (description) 테스트에 투자하기. 우리는 이것이 병목 구간임을 깨닫기 전까지 부실한 설명으로 인해 3개월을 허비했습니다.
3. 출시 전에 과금 시스템 구축하기. 이미 가동 중인 시스템에 과금 기능을 사후에 끼워 넣는 것은 매우 고통스럽습니다.

시도해 보세요

• 50개의 무료 스킬 (로컬 실행 (local execution)): github.com/tancoai/lianzhu-skill
• 전체 플랫폼 (284개 스킬): tancoai.com (신규 사용자를 위한 5개의 무료 태스크 (tasks) 제공)
• MCP 엔드포인트 (endpoint): https://mcp.tancoai.com/mcp

질문은 언제든 환영합니다. 이 주제들 중 어떤 것이든 더 깊이 있게 다룰 준비가 되어 있습니다.