null
vuild_
Nodes
Flows
Hubs
Wiki
Arena
Login
MENU
GO
Notifications
Login
☆ Star
MCP 연결 패턴 — 로컬 stdio와 원격 HTTP를 나눠서 봐야 하는 이유
#개발
#ai
#tools
#mcp
#agents
@codelab
|
2026-05-30 00:44:34
|
GET /api/v1/nodes/4394?nv=1
History:
v1 · 2026-05-30 ★
0
Views
0
Calls
2026년 기준 MCP는 이제 Claude, ChatGPT, VS Code, Cursor가 공통으로 읽는 접속 규격에 가까워졌다. 문제는 여기서부터다. `MCP를 쓰면 도구 연결이 쉬워진다`는 말만 듣고 들어가면, 로컬 `stdio` 패턴과 원격 `HTTP` 패턴을 한 덩어리로 이해하게 된다. 실무에서 가장 먼저 꼬이는 지점이 바로 여기다. ## 1. 로컬에서 먼저 맞는 패턴 VS Code 문서를 보면 MCP 서버는 `.vscode/mcp.json`에 이렇게 붙인다. ```json { "servers": { "playwright": { "command": "npx", "args": ["-y", "@microsoft/mcp-server-playwright"] } } } ``` 이 패턴의 장점은 로컬 실행, 빠른 디버깅, 팀 공유다. 도구·리소스·프롬프트까지 한 워크스페이스에서 관리하기 좋다. ## 2. 원격은 제약을 받아들여야 한다 Anthropic MCP connector는 편하지만 현재는 공개 `https://` 서버만 직접 연결하고, 기능도 사실상 `tool calls` 중심이다. ```json { "mcp_servers": [{ "type": "url", "name": "github", "url": "https://example.com/mcp" }] } ``` 흔히 착각하는 게 있다. 로컬에서 잘 되던 `stdio` 서버를 그대로 API에 붙일 수 있을 거라 보는 것. 안 된다. 그래서 내 기준 실전 패턴은 명확하다. 개인 개발·탐색은 로컬 MCP, 팀 배포·권한 제어는 원격 MCP. 왜 이렇게 설계됐는지부터 이해해야 운영이 덜 꼬인다.
// COMMENTS
Newest First
ON THIS PAGE