AI 스킬 리뷰를 위한 MCP 정리
MCP 정확히
이해하기:
AI 스킬과 도구
연결 표준의 차이
MCP는 모델도, 스킬도, 플러그인 마켓도 아니다. LLM 애플리케이션이 외부 데이터와 도구를 표준 방식으로 발견하고 호출하도록 만드는 연결 프로토콜이다.
한줄 요약: MCP는 AI 스킬처럼 “일하는 방법”을 담는 패키지가 아니라, AI 애플리케이션이 외부 데이터와 도구를 안전하게 발견하고 호출하기 위한 표준 연결 규약이다.
왜 MCP를 따로 이해해야 하는가
회사에서 AI 스킬을 검토하다 보면 “이 기능은 스킬인가, 플러그인인가, MCP인가”라는 질문이 바로 나온다. 겉으로 보면 모두 AI에게 새로운 능력을 붙이는 방식처럼 보인다. 하지만 실제 설계 관점에서는 계층이 다르다. 스킬은 대체로 모델이 특정 업무를 더 잘 수행하도록 지침, 스크립트, 참고 자료를 묶는 패키지에 가깝다. 반면 MCP는 AI 애플리케이션과 외부 시스템이 런타임에 통신하는 방법을 정하는 프로토콜이다.
이 차이를 놓치면 리뷰 기준이 흐려진다. “문서 요약 스킬을 만들자”는 말과 “사내 문서 저장소 MCP 서버를 열자”는 말은 보안 범위, 운영 책임, 권한 설계, 장애 대응이 완전히 다르다. 전자는 모델에게 일하는 절차를 알려주는 문제에 가깝고, 후자는 모델이 실제 시스템에 접근하거나 작업을 실행할 수 있는 경로를 여는 문제다.
Google Cloud 문서는 LLM의 한계를 2가지로 설명한다. 하나는 학습 시점의 지식에 갇힌다는 점이고, 다른 하나는 외부 세계와 직접 상호작용할 수 없다는 점이다. MCP는 이 둘 중 특히 “외부 데이터와 도구에 안전하고 표준화된 방식으로 연결한다”는 문제를 다룬다. 그래서 MCP를 단순한 편의 기능으로 보면 안 된다. 사내 시스템, 데이터베이스, 파일, 결제, CRM, 코드 저장소와 연결되는 순간 MCP는 제품 기능이면서 동시에 보안 경계가 된다.
한 줄 요약: AI 스킬은 “모델에게 일을 시키는 방법”에 가깝고, MCP는 “모델이 외부 시스템과 대화하는 통로”에 가깝다. 둘은 함께 쓸 수 있지만 같은 개념은 아니다.
MCP의 정확한 정의
MCP는 Model Context Protocol의 약자다. 공식 스펙은 MCP를 LLM 애플리케이션과 외부 데이터 소스, 도구를 매끄럽게 통합하기 위한 개방형 프로토콜로 정의한다. 여기서 중요한 단어는 “프로토콜”이다. MCP는 새로운 LLM 모델이 아니고, 특정 회사의 앱스토어도 아니며, 단순한 프롬프트 템플릿도 아니다. AI 애플리케이션이 외부 컨텍스트와 기능을 어떤 메시지 형식으로 발견하고, 어떤 절차로 호출하고, 어떤 결과 형식으로 돌려받을지를 표준화한다.
Anthropic은 2024년 11월 25일 MCP를 공개하면서 AI 어시스턴트를 콘텐츠 저장소, 비즈니스 도구, 개발 환경처럼 데이터가 실제로 존재하는 시스템에 연결하기 위한 표준이라고 설명했다. 이후 MCP 공식 스펙은 여러 버전으로 갱신되었고, 2026년 5월 28일 기준 공식 스펙 페이지는 2025-11-25 버전을 최신으로 표시한다. 최신 문서에서는 JSON-RPC 2.0 메시지, 상태가 있는 연결, 클라이언트와 서버의 기능 협상, 도구와 리소스와 프롬프트 같은 프리미티브가 핵심 축으로 정리되어 있다.
MCP를 이해할 때 유용한 비유는 “AI 애플리케이션을 위한 표준 포트”다. 다만 이 비유에도 한계가 있다. USB-C가 물리적 포트라면 MCP는 메시지, 권한, 세션, 전송 방식, 도구 목록, 호출 결과를 다루는 소프트웨어 규약이다. 즉 MCP 서버를 연결한다는 말은 단순히 플러그를 꽂는다는 뜻이 아니라, AI가 볼 수 있는 기능 목록과 그 기능이 실행될 권한 경계를 설계한다는 뜻이다.
MCP가 해결하는 문제: 모델마다, 도구마다, 서비스마다 별도 커넥터를 만드는 방식은 금방 복잡해진다. MCP는 AI 앱과 외부 시스템 사이의 연결 방식을 통일해 중복 통합 비용을 줄이고, 같은 서버를 여러 MCP 호스트에서 재사용할 수 있게 한다.
호스트, 클라이언트, 서버 구조
MCP 문서에서 가장 자주 혼동되는 부분은 “클라이언트”라는 단어다. 일반 웹 개발에서는 사용자가 쓰는 앱을 클라이언트라고 부르지만, MCP에서는 AI 애플리케이션 전체를 보통 호스트라고 부른다. MCP 클라이언트는 그 호스트 내부에서 특정 MCP 서버와 연결을 유지하는 구성요소다. 하나의 호스트가 여러 MCP 서버에 연결하면, 일반적으로 서버마다 별도의 MCP 클라이언트 연결이 생긴다.
MCP Host
사용자가 실제로 상호작용하는 AI 앱이다. 예를 들면 AI IDE, 데스크톱 어시스턴트, 챗봇, 사내 에이전트 플랫폼이다.
MCP Client
호스트 내부에서 MCP 서버와 연결하고 기능 목록, 리소스, 호출 결과를 주고받는 프로토콜 어댑터다.
MCP Server
데이터, 컨텍스트, 실행 가능한 도구를 제공하는 프로그램 또는 서비스다. 로컬 프로세스일 수도 있고 원격 HTTP 서비스일 수도 있다.
MCP의 내부 구조는 크게 데이터 계층과 전송 계층으로 나뉜다. 데이터 계층은 JSON-RPC 2.0 기반 메시지, 초기화, 기능 협상, 도구 목록 조회, 도구 호출, 리소스 읽기, 알림 같은 의미론을 다룬다. 전송 계층은 이 메시지를 어떻게 이동시킬지 결정한다. 로컬에서는 stdio가 흔하고, 원격 서버에서는 Streamable HTTP가 중요하다.
이 구조는 단순해 보이지만 운영 설계에는 큰 영향을 준다. 로컬 stdio 서버는 빠르고 사용자 머신의 파일 시스템에 접근하기 쉽지만, 실행 명령 자체가 공격면이 된다. 원격 HTTP 서버는 여러 사용자가 공유하기 좋고 인증과 확장을 중앙화하기 쉽지만, 네트워크 인증, Origin 검증, 세션 관리, SSRF 방어를 신경 써야 한다. 따라서 “MCP 서버를 붙인다”는 결정은 기능 요구사항과 보안 모델을 동시에 검토해야 한다.
Tools, Resources, Prompts가 핵심이다
MCP 서버가 호스트에 제공할 수 있는 대표 기능은 Tools, Resources, Prompts다. 이 3가지를 구분하면 MCP가 단순한 API 호출 래퍼가 아니라는 점이 분명해진다.
| 구분 | 무엇을 제공하나 | 예시 | 리뷰 포인트 |
|---|---|---|---|
| Tools | 모델이 호출할 수 있는 실행 함수 | DB 조회, 이슈 생성, 파일 쓰기, 배포 트리거 | 권한, 승인, 입력 검증, 감사 로그 |
| Resources | 모델이나 사용자가 참고할 수 있는 컨텍스트 데이터 | 파일 내용, DB 스키마, API 응답, 문서 조각 | 민감정보 노출, 접근 범위, 캐싱 정책 |
| Prompts | 반복 가능한 작업 템플릿과 지침 | PR 리뷰 템플릿, 장애 분석 절차, SQL 작성 가이드 | 프롬프트 신뢰성, 버전 관리, 팀 표준 반영 |
대표적인 흐름은 다음과 같다. 먼저 호스트 안의 MCP 클라이언트가 서버와 초기화 요청을 주고받으며 프로토콜 버전과 기능을 협상한다. 이후 필요한 시점에 tools/list 같은 목록 조회를 수행한다. 모델이 특정 도구를 써야 한다고 판단하면 호스트가 도구 호출을 중간에서 가로채 MCP 서버에 tools/call 요청을 보낸다. 서버는 외부 시스템을 호출하거나 데이터를 읽은 뒤 구조화된 결과를 반환하고, 호스트는 그 결과를 대화 컨텍스트에 다시 넣어 모델이 최종 답변을 만들도록 한다.
1. 초기화
버전과 기능 협상
2. 발견
도구와 리소스 목록 확인
3. 선택
모델이 필요한 기능 판단
4. 호출
서버가 외부 시스템 실행
5. 응답
결과를 컨텍스트로 반영
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "weather_current",
"arguments": {
"location": "Seoul",
"units": "metric"
}
}
}중요한 점은 MCP 서버가 실제 작업을 수행할 수 있다는 것이다. Resources만 읽는 서버와 Tools로 쓰기 작업을 실행하는 서버의 위험도는 다르다. 단순 문서 검색용 서버는 주로 데이터 노출을 걱정하면 되지만, 티켓 생성, 코드 수정, 배포, 결제, 고객 정보 변경 같은 도구를 제공하는 서버는 승인 흐름과 롤백 설계까지 필요하다.
전송 방식: stdio와 Streamable HTTP
최신 MCP 스펙은 표준 전송 방식으로 stdio와 Streamable HTTP를 설명한다. stdio는 클라이언트가 MCP 서버를 로컬 하위 프로세스로 실행하고 표준 입력과 표준 출력으로 JSON-RPC 메시지를 주고받는 방식이다. 개발자 도구, 로컬 파일 시스템, 개인 워크스페이스처럼 사용자 머신 안에서 빠르게 동작해야 하는 경우에 적합하다.
Streamable HTTP는 독립 서버가 HTTP POST와 GET 요청을 처리하는 방식이다. 서버는 하나의 MCP 엔드포인트를 제공하고, 필요하면 Server-Sent Events를 사용해 스트리밍과 서버발 알림을 지원할 수 있다. 2025-11-25 스펙 문서는 Streamable HTTP가 2024-11-05 버전의 HTTP+SSE 전송을 대체한다고 설명한다. 따라서 새 원격 MCP 서버를 설계한다면 과거 SSE 방식이 아니라 최신 Streamable HTTP와 인증 모델을 먼저 검토하는 편이 낫다.
전송 방식 선택은 보안 리뷰의 출발점이다. 로컬 stdio 서버는 설치 명령과 실행 파일을 그대로 신뢰해야 하므로 공급망과 샌드박스가 중요하다. 원격 Streamable HTTP 서버는 인증, 토큰 범위, Origin 검증, 세션 ID 처리, 네트워크 정책이 중요하다. 특히 로컬에서 HTTP 서버를 띄운다면 공식 문서가 경고하는 것처럼 0.0.0.0에 열어 두지 말고 가능한 127.0.0.1에 바인딩해야 하며, 외부 웹사이트가 로컬 서버와 상호작용하는 DNS rebinding 위험도 고려해야 한다.
AI 스킬, RAG, 함수 호출과의 차이
MCP가 유행하면서 기존 개념과 섞여 쓰이는 경우가 많다. 특히 AI 스킬, RAG, 함수 호출은 모두 모델의 한계를 보완한다는 점에서 비슷해 보이지만, 각각 해결하는 문제가 다르다.
| 개념 | 핵심 목적 | MCP와의 관계 |
|---|---|---|
| AI 스킬 | 특정 업무를 잘 수행하도록 지침, 스크립트, 리소스를 묶는다. | 스킬 안에 MCP 사용 절차를 담을 수 있지만, 스킬 자체가 MCP는 아니다. |
| RAG | 답변 전에 관련 문서를 검색해 프롬프트 컨텍스트를 보강한다. | MCP 서버가 검색 도구나 문서 리소스를 제공하면 RAG 구성요소처럼 쓰일 수 있다. |
| 함수 호출 | 모델이 구조화된 함수 호출 형태로 의도를 표현하게 한다. | MCP는 함수 목록 발견, 호출 전달, 결과 반환을 호스트와 서버 사이에서 표준화한다. |
| 플러그인 | 사용자에게 설치 가능한 기능 묶음으로 배포한다. | 플러그인이 내부에 MCP 서버, 스킬, UI, 명령을 함께 포함할 수 있다. |
Claude Skills 문서는 스킬을 지침, 스크립트, 리소스가 들어 있는 디렉터리로 설명한다. 같은 문서의 비교 표는 MCP를 외부 서비스에 연결하는 기능으로 별도 구분한다. 이 구분은 실무적으로 중요하다. 예를 들어 “장애 회고 작성 스킬”은 회고 양식과 분석 절차를 담을 수 있다. 하지만 실제 로그 시스템에서 장애 시점의 로그를 조회하려면 MCP 서버나 별도 API 통합이 필요하다.
RAG와의 차이도 분명하다. RAG는 주로 “무엇을 알고 답할 것인가”에 초점을 둔다. MCP는 “무엇에 접근하고 무엇을 실행할 수 있는가”까지 포함한다. 물론 둘은 경쟁 관계가 아니다. 문서 검색 MCP 서버를 만들면 그 서버는 RAG 파이프라인의 검색 계층처럼 쓰일 수 있다. 반대로 RAG 시스템이 이미 있어도, AI 에이전트가 티켓을 생성하거나 고객 레코드를 수정하거나 배포 상태를 확인하려면 MCP 같은 도구 연결 계층이 별도로 필요하다.
함수 호출과 MCP의 관계는 계층 차이로 보면 된다. 함수 호출은 모델이 “이 함수를 이런 인자로 호출하라”는 구조화된 출력을 내는 방식이다. MCP는 그런 호출이 어떤 서버에 있는 도구를 대상으로 하는지, 목록은 어떻게 발견하는지, 호출은 어떤 JSON-RPC 메시지로 보내는지, 결과는 어떻게 돌려받는지를 다룬다. 즉 함수 호출은 모델과 호스트 사이의 표현 방식에 가깝고, MCP는 호스트와 외부 도구 서버 사이의 통신 규약에 가깝다.
MCP는 편하지만 자동으로 안전하지 않다
MCP의 장점은 외부 도구 연결을 표준화한다는 점이다. 그러나 바로 그 장점 때문에 위험도 커진다. 모델이 파일을 읽고, API를 호출하고, 데이터베이스를 조회하고, 코드를 실행할 수 있다면 보안 관점에서는 새로운 실행 경로가 생긴 것이다. 공식 스펙도 MCP가 임의 데이터 접근과 코드 실행 경로를 가능하게 하므로 구현자가 동의, 권한, 개인정보, 도구 안전성을 신중하게 다뤄야 한다고 설명한다.
보안 리뷰에서 가장 먼저 볼 것은 사용자 동의와 제어다. 어떤 도구가 어떤 데이터를 읽고 어떤 작업을 실행하는지 사용자가 이해할 수 있어야 한다. 읽기 도구와 쓰기 도구를 같은 승인 정책으로 묶으면 위험하다. 예를 들어 read_issue는 자동 실행을 허용할 수 있어도 delete_branch, send_email, deploy_production은 명시적 승인이 필요할 수 있다.
두 번째는 토큰과 범위다. MCP 보안 문서는 토큰 passthrough를 금지되는 안티패턴으로 다룬다. MCP 서버가 자신을 대상으로 발급되지 않은 토큰을 그대로 받아 하위 API에 전달하면 감사, 권한, 속도 제한, 토큰 audience가 흐려진다. 회사 환경에서는 “사용자 토큰을 그냥 넘겨도 되나”가 아니라 “MCP 서버용 토큰이 어떤 audience와 scope로 발급되는가”를 물어야 한다.
세 번째는 네트워크 공격면이다. OAuth 메타데이터 탐색, 리다이렉트, 원격 서버 연결은 SSRF 위험을 만들 수 있다. 클라이언트가 악성 MCP 서버가 제공한 URL을 따라가 내부 IP, 클라우드 메타데이터 엔드포인트, 로컬 서비스에 접근하면 데이터 유출로 이어질 수 있다. 운영 환경에서는 HTTPS 강제, 사설 IP 차단, 리다이렉트 검증, egress proxy 같은 방어가 필요하다.
네 번째는 로컬 MCP 서버 실행이다. 많은 MCP 예제는 npx나 로컬 바이너리를 실행한다. 이 방식은 편하지만 사용자의 권한으로 코드를 실행한다. 따라서 설치 명령 전체 표시, 출처 검증, 버전 고정, 샌드박스, 파일 시스템 범위 제한, 네트워크 제한, 업데이트 정책이 필요하다. 도구 설명도 무조건 신뢰해서는 안 된다. 서버가 제공하는 설명은 모델이 도구를 선택하는 근거가 되므로, 신뢰할 수 없는 서버의 설명은 프롬프트 주입이나 도구 오용의 경로가 될 수 있다.
회사 리뷰용 체크리스트
AI 스킬과 MCP를 함께 검토할 때는 “사용자가 체감하는 기능”보다 “경계와 책임”을 먼저 나누는 것이 좋다. 아래 체크리스트는 사내 리뷰에서 바로 질문으로 쓸 수 있는 형태로 정리했다.
1. 문제 정의
이 기능은 모델에게 절차를 가르치는 문제인가, 외부 시스템 접근을 여는 문제인가? 전자면 스킬, 후자면 MCP 또는 API 통합 검토가 필요하다.
2. 데이터 범위
서버가 읽을 수 있는 리소스는 무엇인가? 개인 정보, 고객 데이터, 소스 코드, 영업 정보, 운영 로그가 포함되는가?
3. 실행 권한
도구가 쓰기 작업을 수행하는가? 이메일 전송, 결제, 배포, 삭제, 권한 변경 같은 작업은 별도 승인과 로그가 필요하다.
4. 전송 방식
stdio 로컬 서버인가, Streamable HTTP 원격 서버인가? 로컬이면 실행 명령과 샌드박스를, 원격이면 인증과 Origin 검증을 본다.
5. 인증과 토큰
토큰 audience, scope, 만료, 회전, 저장 위치가 명확한가? 사용자 토큰을 그대로 전달하는 구조는 피해야 한다.
6. 운영 책임
서버 소유 팀, 버전 고정, 배포 롤백, 장애 알림, 감사 로그, 비용 추적, 사용 중지 절차가 정해져 있는가?
도입 기준은 간단하게 잡을 수 있다. “읽기 전용, 제한된 리소스, 명확한 사용자 승인, 감사 로그 있음”이면 파일럿에 적합하다. “광범위한 쓰기 권한, 불명확한 토큰 전달, 출처가 불명확한 로컬 실행, 로그 없음”이면 기능이 좋아 보여도 보류하는 편이 맞다. MCP는 연결을 쉽게 만들지만, 쉽게 연결된 시스템은 쉽게 사고를 만든다.
안티패턴
- 모든 사내 API를 하나의 거대한 MCP 서버에 몰아넣는다.
- 읽기 도구와 쓰기 도구를 같은 승인 정책으로 처리한다.
- 서버가 제공하는 도구 설명을 검토 없이 신뢰한다.
- 로컬 MCP 서버 설치 명령을 축약해서 보여준다.
- 토큰 scope를 넓게 발급하고 만료와 회전 정책을 두지 않는다.
- MCP 서버 장애가 최종 사용자 경험에 어떤 영향을 주는지 정의하지 않는다.
실무에서는 이렇게 구분하면 된다
AI 스킬 리뷰에서 MCP가 필요한지 판단하려면 다음 질문을 던지면 된다. 모델이 더 나은 지침만 있으면 되는가? 그렇다면 스킬이 먼저다. 모델이 외부 시스템의 최신 상태를 읽어야 하는가? 그렇다면 RAG, 검색 API, Resources 기반 MCP를 검토한다. 모델이 외부 시스템에 작업을 실행해야 하는가? 그렇다면 Tools 기반 MCP를 검토하되, 승인을 기본값으로 둔다.
예를 들어 “분기별 회고를 회사 문체로 작성하라”는 요구는 스킬이 잘 맞는다. 문체, 목차, 금지 표현, 예시 문단, 검토 절차를 스킬에 담으면 된다. 반면 “Jira에서 이번 분기 완료 이슈를 가져오고, GitHub PR을 매칭하고, Notion 회고 페이지를 생성하라”는 요구는 외부 시스템 3개에 접근해야 한다. 이 경우 스킬은 절차를 정의하고, MCP 서버는 Jira, GitHub, Notion 접근을 담당하는 식으로 역할을 나누는 편이 자연스럽다.
또 다른 예로 “사내 보안 정책에 맞춰 Terraform 코드를 리뷰하라”는 요구는 스킬과 정적 참고 자료만으로 시작할 수 있다. 하지만 실제 클라우드 계정의 IAM 정책, 네트워크 규칙, 배포 상태를 조회하려면 MCP 서버가 필요하다. 이때 MCP 서버는 읽기 전용으로 시작하고, 변경 작업은 별도 승인 도구로 분리하는 것이 안전하다.
추천 원칙: 스킬은 작업 절차와 판단 기준을 담고, MCP는 외부 시스템 접근을 담당하게 한다. 처음부터 쓰기 권한을 열지 말고, 읽기 전용과 좁은 scope로 시작한 뒤 실제 사용 로그를 보고 확장한다.
결론
MCP는 AI 스킬을 대체하는 개념이 아니다. 스킬이 모델에게 업무 방식과 판단 기준을 알려주는 레이어라면, MCP는 그 모델이 실제 외부 시스템과 연결되는 통신 레이어다. 따라서 “스킬을 만들 것인가, MCP 서버를 붙일 것인가”는 경쟁 선택지가 아니라 역할 분리의 문제로 봐야 한다.
회사 리뷰에서는 먼저 기능을 3가지로 나누면 된다. 지침과 절차만 필요하면 스킬로 충분하다. 최신 데이터 조회가 필요하면 읽기 전용 리소스나 검색 도구를 검토한다. 외부 시스템에 변경을 일으키는 작업이 필요하면 MCP Tools를 검토하되, 명시 승인, 좁은 scope, 감사 로그, 롤백 가능성을 기본 조건으로 둔다.
가장 안전한 도입 순서는 작게 시작하는 것이다. 읽기 전용, 제한된 데이터 범위, 검증된 서버, 버전 고정, 사용자 승인, 관찰 가능한 로그를 먼저 갖춘 뒤 실제 사용 패턴을 보고 쓰기 권한을 확장한다. MCP의 가치는 연결을 표준화하는 데 있지만, 그 연결이 곧 권한 경계가 된다는 점을 끝까지 놓치지 않는 것이 핵심이다.
최종 판단: MCP를 “AI에게 도구를 붙이는 편의 기능”으로만 보면 부족하다. 사내 시스템 접근을 여는 표준 인터페이스로 보고, 기능 리뷰와 보안 리뷰를 같은 테이블에서 진행해야 한다.
참고한 공식 문서
이 글은 아래 공식 문서와 제품 문서를 기준으로 작성했다. 특히 최신 스펙은 시간이 지나면 바뀔 수 있으므로, 구현 전에는 반드시 공식 스펙의 latest 버전과 changelog를 다시 확인해야 한다.
- Google Cloud: Model Context Protocol(MCP)이란 무엇인가요?
- Anthropic: Introducing the Model Context Protocol
- Model Context Protocol: Latest Specification
- Model Context Protocol: Architecture overview
- Model Context Protocol: Transports
- Model Context Protocol: Security Best Practices
- Claude Docs: Skills overview
- OpenAI Help: Build with the Apps SDK
- OpenAI Agents SDK: Model context protocol
FAQ
Q1. MCP는 AI 스킬과 같은 것인가요?+
아니다. 스킬은 보통 특정 작업을 수행하기 위한 지침, 스크립트, 리소스 묶음이다. MCP는 AI 애플리케이션이 외부 데이터와 도구에 연결되는 통신 프로토콜이다. 스킬 안에서 MCP를 사용하는 절차를 설명할 수는 있지만, 두 개념은 같은 계층이 아니다.
Q2. MCP를 쓰면 RAG가 필요 없나요?+
그렇지 않다. RAG는 관련 문서를 찾아 모델 컨텍스트를 보강하는 기법이고, MCP는 외부 시스템과 통신하는 표준이다. MCP 서버가 검색 도구나 문서 리소스를 제공하면 RAG의 일부로 활용할 수 있다. 반대로 RAG만으로는 외부 시스템에 쓰기 작업을 실행할 수 없다.
Q3. MCP 서버는 반드시 원격 서버여야 하나요?+
아니다. MCP 서버는 로컬 프로세스로 실행될 수도 있고 원격 HTTP 서비스로 운영될 수도 있다. 로컬에서는 stdio 전송이 흔하고, 원격에서는 Streamable HTTP가 핵심이다. 선택 기준은 지연 시간, 데이터 민감도, 사용자 수, 인증 방식, 운영 책임이다.
Q4. MCP를 도입할 때 가장 위험한 부분은 무엇인가요?+
쓰기 권한을 가진 도구, 과도한 토큰 scope, 검증되지 않은 로컬 실행 명령, 불명확한 사용자 승인, 로그 없는 자동 실행이 특히 위험하다. MCP는 모델에게 외부 세계와 상호작용할 길을 열어 주므로, 기능보다 권한 경계를 먼저 설계해야 한다.
Q5. 회사 파일 시스템 MCP 서버를 열어도 되나요?+
가능은 하지만 범위를 매우 좁혀야 한다. 특정 프로젝트 폴더만 허용하고, 홈 디렉터리, SSH 키, 브라우저 프로필, 비밀 키 파일, 다운로드 폴더처럼 민감한 위치는 제외해야 한다. 쓰기 작업은 기본 차단하고, 꼭 필요할 때만 명시 승인과 감사 로그를 붙이는 편이 안전하다.
Q6. MCP 서버 하나에 모든 도구를 넣는 것이 편하지 않나요?+
초기에는 편해 보이지만 권한과 운영 책임이 흐려진다. 도구 도메인, 데이터 민감도, 승인 정책, 소유 팀이 다르면 MCP 서버도 분리하는 것이 낫다. 최소한 읽기 전용 도구와 쓰기 도구는 분리해 리뷰하는 편이 좋다.
작성 메모: 이 글은 회사에서 AI 스킬과 MCP를 구분해 검토할 때 필요한 기준을 정리한 문서입니다. 단순 뉴스 요약이 아니라 실제 도입 검토 시 확인해야 할 보안 범위, 권한 설계, 운영 책임을 중심으로 정리했습니다.
MCP를 한 줄로 정리하면
MCP(Model Context Protocol)는 AI 애플리케이션이 외부 데이터, 도구, 업무 시스템과 연결되는 방식을 표준화한 프로토콜입니다. 모델 자체도 아니고, 프롬프트 모음도 아니고, 스킬 마켓플레이스도 아닙니다. 핵심은 LLM 애플리케이션이 외부 컨텍스트와 기능을 어떤 메시지 형식으로 발견하고 호출할지 정하는 연결 규약입니다.
공식 문서와 Google Cloud 설명을 기준으로 보면 MCP는 LLM이 외부 데이터, 애플리케이션, 서비스와 통신하도록 돕는 개방형 표준에 가깝습니다. 그래서 MCP를 도입한다는 말은 단순히 AI에게 새 작업 방식을 알려주는 수준이 아니라, AI가 실제 시스템에 접근할 수 있는 경로를 여는 일에 가깝습니다.
왜 AI 스킬과 헷갈리는가
요즘 AI 도구에서는 스킬, 플러그인, MCP, 에이전트, 함수 호출 같은 용어가 한꺼번에 등장합니다. 겉으로는 모두 “AI에게 능력을 붙이는 방식”처럼 보입니다. 하지만 실제로는 책임 범위가 다릅니다.
- AI 스킬은 보통 작업 절차, 산출물 형식, 검증 기준을 담은 실행 매뉴얼에 가깝습니다.
- MCP는 AI 애플리케이션과 외부 시스템이 런타임에 통신하는 프로토콜입니다.
- RAG는 문서나 데이터에서 관련 컨텍스트를 찾아 모델 입력에 붙이는 검색/검색증강 패턴입니다.
- 함수 호출은 모델이 정해진 함수 스키마에 맞춰 호출 인자를 만드는 기능입니다.
예를 들어 “기술 블로그 글쓰기 스킬”은 글의 목차와 톤, 체크리스트를 정하는 문제입니다. 반면 “사내 문서 저장소 MCP 서버”는 AI가 실제 사내 데이터에 접근할 수 있는 경로를 만드는 문제입니다. 후자는 권한, 로그, 감사, 장애 대응, 데이터 노출 범위까지 같이 검토해야 합니다.
MCP의 기본 구조
MCP는 보통 호스트, 클라이언트, 서버 구조로 이해하면 쉽습니다. 호스트는 Claude Desktop, IDE, 에이전트 실행 환경처럼 사용자가 직접 만나는 AI 애플리케이션입니다. 클라이언트는 호스트 내부에서 MCP 서버와 연결을 관리하는 구성요소입니다. 서버는 파일 시스템, 데이터베이스, SaaS, 내부 API 같은 외부 기능을 MCP 형식으로 노출합니다.
이 구조에서 중요한 점은 모델이 아무 시스템이나 직접 만지는 것이 아니라는 점입니다. 호스트와 클라이언트가 어떤 서버를 신뢰할지, 어떤 도구를 노출할지, 어떤 요청을 허용할지 통제해야 합니다.
Tools, Resources, Prompts의 차이
MCP 서버가 제공하는 대표적인 프리미티브는 Tools, Resources, Prompts입니다.
- Tools: 모델이 호출할 수 있는 동작입니다. 예를 들어 이슈 생성, 파일 검색, DB 조회, 빌드 실행 같은 작업이 여기에 들어갑니다.
- Resources: 모델이 읽을 수 있는 데이터입니다. 문서, 설정, 저장소 파일, 스키마, 로그 같은 읽기 대상입니다.
- Prompts: 특정 작업을 시작하기 위한 재사용 가능한 프롬프트 템플릿입니다.
실무에서 가장 조심해야 할 것은 Tools입니다. Resources는 읽기 권한 중심이라도 민감정보 노출 위험이 있고, Tools는 실제 변경 작업까지 이어질 수 있습니다. 그래서 MCP 서버를 검토할 때는 “무엇을 읽을 수 있는가”와 “무엇을 실행할 수 있는가”를 반드시 분리해서 봐야 합니다.
RAG와 MCP는 경쟁 관계가 아니다
RAG와 MCP는 서로 대체재라기보다 계층이 다릅니다. RAG는 검색된 문서를 모델 입력에 넣어 답변 품질을 높이는 패턴입니다. MCP는 그 검색 기능이나 외부 도구를 AI 애플리케이션에 표준 방식으로 연결하는 프로토콜입니다.
예를 들어 사내 위키 검색을 만든다고 가정하면, 벡터 검색과 랭킹은 RAG 파이프라인의 영역입니다. 그 검색 기능을 Claude Desktop이나 IDE 에이전트에서 표준 방식으로 호출하게 만들면 MCP 서버가 됩니다. 즉 RAG를 MCP 서버 뒤에 붙일 수도 있고, MCP 없이 애플리케이션 내부 기능으로 구현할 수도 있습니다.
함수 호출과 MCP의 차이
함수 호출은 모델 API 차원에서 “이런 이름과 파라미터를 가진 함수를 호출할 수 있다”고 알려주는 방식입니다. MCP는 특정 모델 API 하나에 묶이기보다, AI 애플리케이션과 외부 도구 사이의 연결을 표준화하려는 접근입니다.
함수 호출은 애플리케이션 코드 안에 도구 정의를 직접 넣는 방식으로 시작하기 쉽습니다. 반면 MCP는 도구 제공자를 별도 서버로 분리하고, 여러 호스트가 같은 서버를 재사용할 수 있게 만드는 데 강점이 있습니다.
도입 전 체크리스트
- 이 MCP 서버가 읽을 수 있는 데이터 범위는 어디까지인가?
- 쓰기, 삭제, 배포, 결제, 외부 전송 같은 변경 작업이 가능한가?
- 사용자별 권한이 서버에서 다시 검증되는가?
- 실행 로그와 감사 로그를 남길 수 있는가?
- 토큰, API 키, 개인정보가 모델 입력이나 로그에 섞일 가능성은 없는가?
- 도구 설명이 과도하게 넓거나 모호하지 않은가?
- 운영 중 장애가 발생했을 때 비활성화하거나 격리할 수 있는가?
내가 실무에서 보는 기준
MCP는 “편리한 자동화”보다 “권한이 있는 자동화”에 가깝게 봐야 합니다. 읽기 전용 문서 검색 서버와 운영 DB를 변경할 수 있는 서버는 같은 MCP라는 이름을 써도 위험도가 완전히 다릅니다.
그래서 처음 도입할 때는 읽기 전용 서버부터 시작하는 편이 낫습니다. 사내 문서 검색, 저장소 파일 읽기, 이슈 조회처럼 실패해도 영향이 제한적인 기능으로 시작하고, 쓰기 작업은 권한·승인·로그 체계가 잡힌 뒤에 붙이는 것이 안전합니다.
정리
MCP는 AI 스킬이나 프롬프트 템플릿이 아닙니다. AI 애플리케이션이 외부 시스템과 연결되는 표준 인터페이스입니다. 그래서 MCP를 평가할 때는 “모델이 더 똑똑해지는가”보다 “모델이 어떤 시스템에 접근할 수 있게 되는가”를 먼저 봐야 합니다.
개인 실험에서는 편의성이 먼저 보이지만, 회사 환경에서는 권한, 데이터 범위, 감사 로그, 장애 대응이 핵심입니다. MCP를 제대로 이해하면 AI 도구 도입을 더 명확하게 분리해서 판단할 수 있습니다.
참고 링크
'AI' 카테고리의 다른 글
| OpenClaw 다운로드 및 테스트 후기 (0) | 2026.05.29 |
|---|---|
| Nanoclaw 실사용후기: 개인 AI 에이전트로 써볼 만할까? (0) | 2026.05.28 |
| Superpowers? 그래서 그게 뭔데? AI 코딩 에이전트 스킬 프레임워크 정리 (0) | 2026.05.27 |
| DESIGN.md란 무엇이고 어떻게 사용하는가 (0) | 2026.05.27 |
| Gemini로 TOEIC 공부하자: YBM 퀴즈와 AI 피드백 루틴 (0) | 2026.05.27 |
