MCP(Model Context Protocol) — 연결의 표준
@vicky_grok의 X 아티클 Build Better AI Applications Using MCP을 개념이 쌓이는 순서로 다시 짠 메모다. 설치·코드 붙여넣기는 다루지 않는다.
초안 작성·문장 정리에 AI를 사용했다. 해석은 작성자 것이며 원문과 다를 수 있다.
- 출처: https://x.com/vicky_grok/status/2096948576731717922
- 작성자: Vikas gupta (@vicky_grok) — AI 엔지니어·콘텐츠 크리에이터
- 원제: Build Better AI Applications Using MCP (Model Context Protocol)
이 글이 푸는 문제
LLM은 똑똑하지만 바깥 세계와 끊겨 있다. 책 많이 읽은 천재가 흰 방에 갇힌 것과 같다. 바탕화면 PDF 요약, 사내 DB의 티켓 상태처럼 “내 데이터”를 물으면 기본적으로 모른다.
그래서 데이터를 연결해야 하는데, 예전에는 앱마다 맞춤 API 연동 코드를 따로 써야 했다. Google Drive용, DB용, Slack용이 제각각이라 지저분하고 보안·유지 비용이 컸다. 그 틈을 메우는 표준이 MCP(Model Context Protocol) 다. 모델만 바꿔도 연동 지옥이 사라지지는 않는다. 요청·응답의 공통 규칙이 있어야 한다.
맞춤 연동 vs MCP
| 앱마다 맞춤 API | MCP | |
|---|---|---|
| 연결 | Drive용·DB용·Slack용 glue code가 제각각 | 한 포트(표준)에 Server를 달아 여러 Host가 붙음 |
| 모델 교체 | 연동을 다시 짜기 쉬움 | MCP를 말하는 Host면 같은 Server를 재사용 |
| 비유 (원문) | 기기마다 다른 충전기 | AI의 USB-C |
요점만 말하면: AI가 데이터를 어떻게 요청할지, 데이터 쪽이 어떻게 답할지 의 공통 규칙을 정한다. 데이터에 MCP 포트를 달아 두면, MCP를 말하는 모델은 그 포트에 바로 붙을 수 있다.
세 부품: Host · Client · Server
보안을 이해하려면 이 세 층이 먼저다.
- MCP Host — 화면에 보이는 AI 앱. 예: Claude Desktop, Cursor 같은 IDE. 모델이 들어가 있고, 프롬프트를 받아 “밖에 물어봐야 하나”를 판단한다.
- MCP Client — Host 안의 “USB-C 케이블”. 모델이 바깥 데이터가 필요하다고 하면 Client가 연결을 연다.
- MCP Server — 데이터·도구 쪽 문지기. DB, 파일, API 앞에 서서 허용된 일만 수행하고 결과를 돌려준다.
모델이 DB를 직접 만지지 않고, Server를 통해서만 말한다는 점이 이후 보안 이야기의 축이다. MCP라는 이름만 켠다고 권한이 정리되지 않는다. 권한이 Server에 모이도록 설계해야 한다.
세 능력: Resources · Prompts · Tools
Server가 AI에게 줄 수 있는 능력은 세 종류로 나뉜다.
| 능력 | 한 줄 | 비유 |
|---|---|---|
| Resources | 읽기 전용 데이터 | 보고서에 쓰라고 준 PDF — 읽되 낙서 금지 |
| Prompts | 미리 다듬어 둔 프롬프트·워크플로 템플릿 | 같은 질문을 매번 잘 던지게 돕는 안내서 |
| Tools | 실행 가능한 동작 | 검색, 쿼리, 파일 쓰기처럼 “손을 쓰는” 일 |
헷갈리기 쉬운 경계: Resource는 읽을 데이터, Tool은 실행할 동작. Prompt는 둘을 언제·어떻게 쓸지 잡아 주는 템플릿에 가깝다.
초보·솔로에게 왜 중요한가
앞에서 말한 “한 포트에 여러 AI”가 여기서 이득이 된다. 한 번 서버를 만들면 Claude·OpenAI·로컬 모델처럼 MCP를 말하는 쪽에 다시 붙일 수 있다. 모델이 바뀔 때마다 연동을 다시 짜는 비용을 줄이니, 팀 규모와 상관없이 유지 부담이 작아진다.
MCP를 쓰는 시점 vs 스킬을 쓰는 시점
원문은 MCP 자체에 초점을 둔다. 아래는 그 위에 얹은 내 정리다. Cursor·에이전트 워크플로에서 「스킬」과 MCP를 언제 고를지 헷갈릴 때 쓴다.
| 스킬 (Skill) | MCP | |
|---|---|---|
| 본질 | 어떻게 생각하고 어떤 순서로 할지 적힌 플레이북·레시피 | 바깥 세계와 말하는 포트·프로토콜 |
| 담는 것 | 규칙, 체크리스트, 톤, 단계, “이 상황에서 이렇게” | Tool·Resource·Prompt를 노출하는 Server |
| 바깥 시스템 | 없어도 됨 — 텍스트만으로 동작 | 파일·DB·API·메신저 등 살아 있는 연결이 목적 |
| 결과 | 같은 질문을 매번 더 잘 던지게 함 | 실제 데이터를 읽고, 실제 동작을 실행함 |
스킬을 쓰는 시점은 “이미 아는 절차를 안정적으로 반복”하고 싶을 때다. 예: 블로그 게시 전 date-guard, 원문 해석 방향 고르기, PR 리뷰 순서. 밖에 새 서버를 붙일 필요가 없고, 말에 담긴 판단이 핵심이다.
MCP를 쓰는 시점은 “모델이 흰 방 밖으로 나가야” 할 때다. 예: 로컬 vault 검색, GitHub 이슈 조회, Slack 전송, DB SELECT. 절차를 외워도 권한이 있는 Server가 없으면 손이 닿지 않는다.
둘은 대체가 아니라 겹쳐 쓴다. 스킬이 “지금은 GitHub MCP로 PR 목록을 보고, 승인 전에는 merge하지 마라”라고 가르치면, MCP Server가 그 손을 실행한다. 스킬만 있으면 동선은 선명하지만 데이터는 없고, MCP만 있으면 포트는 열려 있지만 언제·무엇을·어디까지가 흔들린다.
스킬 대비 MCP가 강한 지점
스킬은 말로 절차를 고정한다. MCP는 그 절차가 닿아야 할 바깥을 표준으로 붙인다. 스킬과 나란히 둘 때 MCP 쪽 강점은 대략 넷이다.
- 진실이 문서가 아니라 시스템에 있을 때 — 스킬에 “어제 PR 상태”를 적어 두면 곧바로 낡는다. MCP Tool은 지금 GitHub·DB·파일을 조회한다. 절차 메모가 아니라 현재 상태를 가져오는 쪽이다.
- 재사용이 Host를 넘는다 — 스킬은 보통 그 에이전트·그 제품의 문맥에 묶인다. MCP Server는 스펙을 말하는 Host(Claude Desktop, Cursor 등)에 같은 포트로 다시 붙일 수 있다. “한 번 만든 연결”의 값이 스킬보다 넓다.
- 권한이 한곳에 모인다 — 스킬은 “DELETE 하지 마라”고 적을 수 있을 뿐이다. 막는 힘은 Server 규칙(SELECT만 허용 등)에 있다. 위험한 동작의 실제 브레이크는 MCP 층에 가깝다.
- 손이 필요한 일 — 검색·쿼리·파일 쓰기처럼 실행이 목표면 스킬 문장만으로는 부족하다. Resource·Tool이 그 손을 제공한다. 스킬의 Prompt 템플릿과 이름이 비슷한 MCP Prompts조차, Server가 배포·버전하는 쪽에 가깝다.
반대로 스킬이 이기는 구간도 분명하다. 톤, 게시 게이트, 해석 방향처럼 바깥 API가 없어도 되는 판단은 스킬이 가볍고 빠르다. MCP로 옮기면 서버·인증·실패 모드까지 짊어진다.
한 줄로: 판단·습관은 스킬, 연결·실행·권한 경계는 MCP. 스킬이 “무엇을 할지”를 가르치면, MCP는 “어디에 손을 대고, 어디는 못 대게 할지”를 담는다.
보안: 서버가 보디가드인 이유
“재무 DB에 연결하면 AI가 테이블을 지우거나 밖으로 메일을 보내지 않나?” 같은 걱정이 나온다. 여기서 Server는 문지기(bouncer) 다. 모델은 Server에만 요청하고, 개발자가 Server에 “SELECT만 허용, DELETE 거절” 같은 규칙을 둔다. 구조상 권한이 Server에 모인다. 다만 이것만으로 “절대 안전”은 아니다 — 설계 책임이 Server 쪽에 있다는 이야기다.
쓰임(개념만)
- 코딩 Host + 로컬 도구: 저장소·터미널에 연결된 Tool로 버그 찾기·수정·테스트까지 이어가기.
- 사내 오라클: Notion·GitLab·고객 DB처럼 흩어진 소스를 Server들로 묶고, 한 Host에서 질문하기.
- 개인 워크플로: 로컬 파일·캘린더·메신저 등도 같은 플러그 모델로 붙이기.
세부는 제품마다 다르니, 여기서는 “Host가 여러 Server Tool을 고른다” 정도만 남긴다. (Obsidian Local REST API + MCP처럼 파일·문서 옵션을 에이전트에 심는 이야기도 같은 축의 응용이다. 클릭 설치는 논외.)
데이터가 오가는 방식(개념)
에이전트는 요청 한 번에 끊기는 패턴과 잘 안 맞는다. 생각 → 도구 → 다시 생각처럼 짧은 왕복이 여러 번 이어진다. MCP는 그 메시지를 싣는 전송(transport) 을 정해 두었고, 지금 기준으로 쓰는 축은 둘이다.
- Stdio — Host가 Server를 같은 기기의 프로세스로 띄우고, 표준 입력·출력으로 JSON-RPC 메시지를 주고받는다. Claude Desktop·Cursor처럼 로컬 서버를 붙일 때 가장 흔하다.
- Streamable HTTP — Server가 원격 HTTP 엔드포인트로 뜨고, Client가 POST로 메시지를 보낸다. 짧은 응답은 JSON, 긴 흐름은 SSE 스트림으로 받을 수 있다. 네트워크 너머 서버·인증이 필요할 때 쓰는 쪽이다.
예전 원격 방식인 HTTP+SSE(엔드포인트가 둘로 나뉘던 형태)는 스펙에서 밀려 나갔고, 새 원격 서버는 Streamable HTTP를 본다. 초보 실습은 대개 Stdio부터면 된다.
한계
스킬과 MCP를 한 덩어리로 취급하면 “포트만 달면 절차도 해결”처럼 읽히기 쉽다. 위 비교절이 그 오해를 막는 축이다.
MCP는 연결의 언어이지, 좋은 Server·권한·Host 설계를 대신하지 않는다. Resource/Tool을 헐겁게 열면 “표준”이 오히려 공격면을 키운다. 전송 방식·제품 지원은 시점에 따라 바뀌므로, 이 메모의 Stdio·Streamable HTTP 구분은 원문·수집 시점 기준이다.
남는 한 줄
외운 천재(고립 모델)에서, 필요할 때 정확한 데이터를 가져오는 연결된 워커 로 옮기자는 방향이다. MCP는 그 연결을 표준 언어로 만들려는 축이다. 포트만 있다고 안전하거나 유용해지지는 않는다 — Host·Client·Server와 세 능력이 맞물리고, 스킬이 동선을 잡을 때 비로소 일한다.
학습용 정리. AI 보조 작성.
댓글