research

Tool vs MCP — fundamental 차이와 공유 메커니즘

Tool vs MCP — fundamental 차이와 공유 메커니즘

"Tool vs MCP"는 잘못된 대립. 둘은 경쟁 관계가 아니라 layer 다름. MCP가 function calling을 사용하는 형태. 이 노트는 가정 4 결정의 fundamental reference. tool 공유의 ecosystem 마찰을 정량 비교한다.

한 줄

Function calling = LLM의 능력 (tool 호출 mechanism). Tool = 실행 가능한 함수 단위. MCP = tool 정의를 server로 외부화하는 protocol. "non-MCP tool 공유"는 같은 stack 안에서는 OK이지만 cross-language·cross-product에서는 마찰 폭발.

가장 흔한 오해 — 그리고 fundamental 정리

오해: "Function calling과 MCP는 대안이다"

사실: 둘은 layer가 다르다. MCP가 function calling을 사용한다.

핵심 비유:

Function Calling = "함수를 호출하는 *문법*"
                   (LLM이 'X 함수에 Y 인자' 형태로 출력)

Tool             = "함수 자체"
                   (실행 가능한 코드 단위)

MCP              = "함수 모음을 host-server 사이에 주고받는 *protocol*"
                   (어디에 어떤 tool 있는지, 어떻게 호출하는지)

non-MCP tool     = "함수를 AI app 안에 박는 형태"
                   (function calling은 똑같이 사용, 다만 tool 정의가 internal)

MCP tool         = "함수를 별 server로 띄우는 형태"
                   (function calling은 똑같이 사용, 다만 tool 정의가 external)

→ MCP는 function calling을 대체하지 않음. tool 정의·발견·호출의 위치를 바꿈.

추상적 작동 구조 — 두 형태 비교

non-MCP tool (자체 정의)

특징:

  • tool definitions이 AI app 코드 안에 있음
  • AI app만 그 tool 정의를 알고 있음
  • 다른 AI app이 같은 tool 사용하려면 코드 import 필요

MCP tool

특징:

  • tool definitions이 별 server에 있음
  • 어떤 AI app이든 protocol로 query해서 사용 가능
  • server를 config 한 줄로 다른 AI app에 추가 가능

공유 메커니즘 비교 — 정량 분석

non-MCP tool 공유 — 3가지 방식

방식어떻게한계
A. SDK packagenpm/pip/cargo로 distribution같은 언어 stack만. cross-language 안 됨
B. Plugin formatproduct specific format (VS Code ext, Cursor rules)product silo. 다른 product에서 사용 불가
C. HTTP API + 매번 wrappingtool을 REST API로 노출, AI app이 wrappingtool description·call format 매번 재발명

MCP tool 공유 — 1가지 방식

방식어떻게한계
MCP server distributionnpm/pip/Docker로 server 배포(없음 — protocol 표준이라 cross-everything)

공유 마찰 차원별 비교

차원non-MCP (자체 tool)MCP
Distribution 자체가능 (npm/pip/cargo)가능 (npm/pip/Docker)
Cross-language❌✅
Cross-product (Claude Code ↔ Cursor ↔ Goose)❌ silo✅ 표준
Discovery 표준❌ (각 product 자체)✅ (list_tools)
Auth/credential 표준❌✅ (OAuth, API key 표준화)
Versioning자체spec 표준
Tool description formatvendor specific표준 JSON Schema
Capability negotiation❌✅
학내 marketplace 형성어려움 (silo)✅
다른 학내로 복제자체 tool 재작성server 그대로 사용

→ 공유 마찰은 MCP가 압도적으로 적음. 이게 ecosystem 폭발의 이유.

약점 / 한계

non-MCP tool의 공유 약점

  1. 언어 silo — JS tool은 JS app만, Python tool은 Python app만
  2. product silo — VS Code ext는 VS Code만, Cursor rule은 Cursor만
  3. Discovery 재발명 — 어떤 tool 있는지를 매 product가 자체 정의
  4. Auth 매번 새로 — credentials 관리 표준 없음
  5. Versioning 자체 — breaking change 표시 표준 없음
  6. 사용자 학습 매번 — 다른 product 가면 다시 학습

→ 결과: ecosystem 형성 어려움. silo가 클 수 있지만 cross-silo 공유는 거의 불가.

non-MCP tool의 현실적 사례

사례silo 크기한계
VS Code extensions1.5만 개VS Code only
Cursor rules수천 개Cursor only
Cline custom tools수백 개Cline only
pi-mono Extension API소수 (npm)TypeScript only
Aider edit formatN/AAider only

→ silo 안에서 큰 ecosystem 가능. 하지만 cross-product 공유는 사실상 불가.

MCP의 token 부담 (이전 논의)

  • tool definition이 verbose (200~500 tokens/tool)
  • 70 extension = 14~35k tokens/turn
  • → 답: lazy loading + skill index pattern (Anthropic)

대안 흐름 — non-MCP의 진화 시도

A. Open standard 시도들

  • AGENTS.md — agent definition 표준 (cross-product)
  • agentskills.io SKILL.md — skill 정의 표준
  • Tool Use API (OpenAI 표준화 시도) — function calling spec 통일
  • → 부분적 성공. 하지만 tool 자체가 아니라 agent/skill 메타데이터 표준

B. Tool gateway / proxy 패턴

  • non-MCP tool을 MCP server로 wrapping
  • 예: Anthropic의 mcp-server-dev plugin (SKILL.md → MCP)
  • → "한 번 작성, 여러 형태로"

C. WebRL / AutoSkill (학술)

  • tool을 trace에서 추출해서 표준화
  • → production 미적용

D. ACP (Agent Client Protocol)

  • agent ↔ client 상위 protocol
  • MCP보다 한 layer 위
  • → MCP와 보완 관계

학내 segment 적용

비개발자 다수 시나리오

non-MCP tool 공유 가능?

✅ 가능. 단, 같은 product 안에서만.

예: 학내 학생이 내 Cursor에서 작성한 custom rule을 다른 학내 학생의 Cursor에 공유.

한계:

  • 학내 marketplace를 Cursor만 쓴다고 가정해야
  • 다른 product (Claude Code, Goose, Continue 등) 사용 학생은 사용 불가
  • 학내 전공별 차이 (공대는 Cursor, 인문대는 Claude Code 등)

MCP tool 공유:

✅ 어떤 product를 쓰든 사용 가능. 학내 marketplace에 MCP server 올리면 모두 사용.

→ 비개발자 다수 + 학내 marketplace 형성 의도 = MCP가 결정적으로 유리.

개발자 학생 + 비개발자 학생 혼합

non-MCP: 개발자 학생이 각 product마다 tool 작성. 비개발자는 그 product 사용 시만 사용 가능.

MCP: 개발자 학생이 MCP server 1번 작성. 비개발자는 어느 product든 config로 사용.

→ 혼합 segment에서 MCP가 사실상 필수. 개발자 1명의 노력이 99명에게 그대로 도달.

v1.0 결정에 영향 — 가정 4 답의 근거 강화

사용자가 주장하는 시나리오

"non-MCP + tool 기반에서 사용자 tool 자체를 공유하는 방식?"

답:

  • ✅ 가능 (npm/pip로 distribute)
  • ⚠️ 단, language stack silo에 갇힘
  • ⚠️ product silo에 갇힘 (Cursor에서 만든 거 Claude Code에서 못 씀)
  • ❌ Cross-language·cross-product 공유는 사실상 불가

MCP보다 어려운가?

같은 stack/product 안에서: 비슷 Cross-language: 훨씬 어려움 (사실상 불가) Cross-product: 훨씬 어려움 (사실상 불가) ecosystem 형성: 훨씬 어려움

학내 segment의 결정

결정 조건적합 옵션
학내 사용자가 한 product만 쓸 것이라 가정non-MCP OK
학내 사용자가 여러 product를 쓸 것이라 가정MCP 결정적으로 유리
다른 학내로 복제 의도MCP 결정적으로 유리
비개발자가 기존 ecosystem(70+ MCP server) 활용MCP 결정적으로 유리

종합 답

"non-MCP로 tool 공유 가능?" → 같은 stack/product 안에서는 OK. Cross-everything에서는 거의 불가.

"MCP보다 어려운가?" → ecosystem 형성·cross-product 공유 측면에서 훨씬 어려움. silo 안에서는 비슷.

v1.0의 결정 input:

  • 학내 segment에 비개발자 다수 + 다른 product 사용 가능성 + 학내 marketplace 형성 의도가 있다면
  • → MCP가 현재 시점 가장 강력한 답
  • → 단, token 부담은 lazy loading + Skills 패턴으로 90% 해소
  • → 결과: MCP + Skills 패턴 (옵션 4-5) 가 비개발자 segment + ecosystem 둘 다 만족

fundamentals 학습 자료 — 더 깊이 가려면

이 주제는 ai-era-fundamentals 새 프로젝트에서 protocol vs implementation, standard vs library 같은 fundamentals로 깊이 갈 가치 있음.

학습 자료:

관련

Sources

← research 목록으로홈으로