MCP가 급상승하는 이유와 디자인·영상·3D 작업 적용법

Model Context Protocol(MCP)은 AI 애플리케이션을 외부 시스템에 연결하는 개방형 표준입니다. Model Context Protocol 공식 문서는 이를 AI 앱용 USB-C 포트에 비유합니다. 기기마다 달랐던 커넥터를 하나의 규격으로 묶었듯이, AI 앱이 로컬 파일과 데이터베이스, 검색 엔진과 계산기 같은 도구, 특정 작업용 프롬프트에 닿는 방식을 하나로 맞춘다는 설명입니다.

공식 문서가 드는 활용 예는 이 사이트 독자의 작업과 가깝습니다. Claude Code가 Figma 디자인을 바탕으로 웹 앱 전체를 생성하고, AI 모델이 Blender에서 3D 디자인을 만들어 3D 프린터로 출력하며, 에이전트가 Google Calendar와 Notion에 접근해 개인 비서처럼 일하는 식입니다. 지원 클라이언트로는 Claude, ChatGPT, Visual Studio Code, Cursor 등이 문서에 올라 있습니다. 한 번 만든 서버를 여러 AI 앱에서 재사용할 수 있다는 점이 핵심 약속입니다.

언급이 한 주 만에 1건에서 11건으로 늘며 급상승 단계에 들어섰습니다

Muckle 레이더에서 MCP의 신호 점수는 61.5/100이고 단계는 급상승입니다. 최근 7일 언급은 11건으로 그 전 7일의 1건에서 크게 늘었고, 30일 누적 16건 가운데 11건이 최근 한 주에 몰려 있습니다. 회자한 채널은 3곳, 언급한 사람·사이트는 11곳으로 직전 주의 1곳에서 늘었습니다. 처음 포착된 시점은 2025년 3월 7일이어서 새로 등장한 개념이라기보다 이미 알려진 표준이 여러 곳에서 동시에 다시 다뤄지기 시작한 흐름입니다. 건수 자체는 작아 대중적 폭발로 읽기는 어렵고, 서로 다른 발신처가 같은 주에 같은 주제를 꺼냈다는 점이 신호의 실질입니다.

최근 언급의 주제를 분류해 보면 크게 다섯 갈래입니다. 도구 설명을 조작하는 공격과 공급망 위험을 다루는 보안 글, 명세 개정과 클라이언트 호환성 글, 사내 API를 권한 범위가 있는 에이전트 도구로 바꾼 기업 사례, 브라우저 환경으로 MCP를 넓히는 시도, 그리고 국내 개발자를 위한 설정 방법과 국내 서비스의 MCP 출시 소개입니다. 개정된 명세의 구체적 변경점은 공식 문서의 명세 페이지를 기준으로 읽어야 하며, 이 리포트가 그 목록을 대신하지는 않습니다.

규모 지표도 참고할 만하지만 해석에 주의가 필요합니다. 학술 문헌은 2025년에 주간 SDK 다운로드 800만 회 이상, 2026년 초에 활성 서버 1만 개 이상과 월간 다운로드 9,700만 회를 인용하고, 또 다른 연구는 수집 기준에 따라 고유 서버 64,611개를 보고합니다. 단위와 시점, 집계 정의가 달라 성장률이나 실제 사용자 수로 환산할 수는 없습니다. Claude Code의 구조를 분석한 연구가 MCP를 네 가지 확장 메커니즘(MCP, 플러그인, 스킬, 훅) 중 하나로 기록했다는 점은, 개발 도구 안에서 MCP가 기본 확장 경로로 자리 잡았음을 보여 줍니다.

서버가 기능을 노출하고 AI 앱이 그것을 호출하는 구조로 작동합니다

MCP는 클라이언트-서버 구조입니다. AI 앱 쪽 클라이언트가 서버에 연결하면 서버는 세 종류를 내놓습니다. 실행할 수 있는 기능인 도구(tools), 읽을 수 있는 데이터인 리소스(resources), 특정 작업에 쓰는 프롬프트 틀(prompts)입니다. 여러 서버를 동시에 연결하면 모델이 각 서버의 도구를 조합해 워크플로를 구성할 수 있습니다. 학술 문헌은 통신이 JSON-RPC 기반이라고 서술하고, 서버 수명주기를 생성, 운영, 업데이트 세 단계로 나눠 단계별 보안·프라이버시 위험을 분석합니다.

실무에서 기억할 점은 모델이 도구를 고르는 근거가 서버가 적어 둔 설명이라는 것입니다. 설명이 부실하면 엉뚱한 도구를 부르거나 필요한 도구를 찾지 못합니다. 같은 서버라도 어떤 모델과 클라이언트 조합이냐에 따라 체감 성능이 크게 달라지는 이유입니다.

공식 문서가 제시하는 시작점은 세 가지입니다. 데이터와 도구를 노출하는 서버 만들기, 서버에 연결하는 앱 만들기, AI 클라이언트 안에서 돌아가는 인터랙티브 앱인 MCP Apps 만들기입니다. 연결 순서, 전송 방식, 인증 절차 같은 현행 세부 사항은 문서의 Architecture와 Security 페이지가 기준입니다.

디자인, 3D, 콘텐츠 운영, 서버 개발에서 이런 흐름으로 쓸 수 있습니다

UI 디자인에서 코드로. 디자인 도구에 연결된 서버를 코딩 에이전트에 붙이고, 특정 프레임을 읽어 컴포넌트로 구현하라고 지시합니다. 생성된 코드를 프로젝트에 반영한 뒤 디자이너가 시안과 시각 차이를 비교합니다. 공식 예시는 웹 앱 전체 생성까지 말하지만, 처음에는 화면 하나나 컴포넌트 하나 단위로 자르는 편이 검수하기 쉽습니다. 디자인 파일에는 읽기 권한만 주는 구성이 안전합니다.

3D 장면 작업. Blender 서버가 장면 생성과 수정 기능을 도구로 노출하면, 자연어로 기본 형태를 만들고 재질과 배치를 조정하는 요청을 이어 갈 수 있습니다. 공식 문서는 3D 디자인을 만든 뒤 3D 프린터로 출력하는 시나리오를 소개합니다. 작업 파일의 복제본에서 시작하고, 장면을 바꾸거나 파일을 내보내는 단계마다 확인을 거는 구성을 권합니다.

영상·콘텐츠 운영. 캘린더와 노트 도구를 읽어 촬영 일정, 콘티 메모, 에셋 목록을 모아 체크리스트 초안을 만드는 용도가 현실적입니다. 소셜·협업 계정 같은 개인 도구를 다루는 벤치마크는 최신 에이전트도 개인화된 도구 사용에서 큰 어려움을 겪는다고 보고합니다. 조회와 정리부터 맡기고, 게시와 삭제, 초대 발송처럼 되돌리기 어려운 동작은 사람이 승인하는 순서가 맞습니다.

자사 서비스를 도구로 내놓는 개발. 서버 15개를 분석한 산업 경험 연구는 반복되는 구조를 다섯 가지로 정리했습니다. 리소스 게이트웨이, 도구 오케스트레이터, 상태 유지 세션 서버, 프록시 집계기, 도메인 특화 어댑터입니다. 에셋 관리 API나 렌더 큐를 노출하려는 팀이라면 도메인 특화 어댑터에서 출발해 도구 수를 천천히 늘리는 설계가 자연스럽습니다. 저장소를 MCP 서비스로 자동 변환하려는 연구 프레임워크도 제안돼 있으나, 이는 제안 단계이며 채택 사례는 아닙니다.

함수 호출, 직접 연동, 브라우저 에이전트와 비교하면 MCP의 자리가 보입니다

문헌은 함수 호출을 외부 데이터나 API 결과를 컨텍스트에 넣는 방식으로, MCP를 공급자마다 달랐던 도구 인터페이스를 표준화하려는 시도로 설명합니다. 두 방식은 보완 관계로 서술됩니다. 에이전트 간 위임을 맡는 A2A와도 함께 언급되는데, MCP는 도구 호출 쪽을 담당합니다.

비교 근거로 쓸 만한 연구 결과가 두 가지 있습니다. 실제 서비스의 REST API를 감싼 18,000개 이상의 도구 환경에서 도구 검색을 붙인 모델은 브라우저 기반 에이전트와 비슷하거나 나은 성능을 보였지만, 작은 모델은 검색된 도구를 충분히 활용하지 못했고 복잡한 기업 환경에서는 최상위 모델도 고전했습니다. 또 코딩 에이전트 두 종과 과제군 두 종의 네 조건 실험에서 단일 코드 실행 도구는 세 조건에서 가장 저렴하거나 비용이 통계적으로 같았고 통과율은 같았습니다. 나머지 한 조건에서는 방향상 14.4% 더 비쌌으나 통계적으로 유의하지 않았습니다. 두 결과 모두 평가 조건에 묶여 있어 선택 기준 전체로 삼기는 어렵습니다.

도구가 늘수록 정확도가 떨어지고 보안 검토 범위도 넓어집니다

도구 수와 설명 품질. 한 산업 논문은 컨텍스트당 도구 수가 늘면 선택 정확도가 떨어지고, 90% 아래로 내려가는 구간이 Claude Haiku 4.5에서 1015개, Sonnet 4에서 2030개라고 보고합니다. 856개 도구를 분석한 연구에서는 도구 설명의 97.1%가 최소 하나의 결함을 갖고 있었습니다. 설명을 보강하면 과제 성공률 중앙값이 5.85%포인트 올랐지만 실행 단계가 67.46% 늘었고, 16.67%의 사례에서는 오히려 성능이 떨어졌습니다. 설명을 길게 쓰면 무조건 좋아지는 구조가 아니므로, 대표 작업으로 직접 시험하며 다듬어야 합니다.

비용과 성공률. 11개 서버, 6개 도메인 벤치마크에서는 상호작용 단계가 늘수록 입력 토큰이 빠르게 증가했고, 에이전트가 서버의 정확한 사용법을 잘 모르는 문제가 확인됐습니다. 벤치마크별 최고 성공률도 78.95%와 43.72%로 크게 갈립니다. 과제와 서버 구성, 판정 방식이 달라 직접 비교할 수 없는 수치이고, 앞쪽 벤치마크의 자동 판정은 사람 검토자와 81% 일치였습니다.

보안. 악성 MCP 서버를 널리 쓰이는 집계 플랫폼 세 곳에 업로드할 수 있었고, 참가자 20명 대상 연구에서 사용자들이 악성 서버를 식별하기 어려워했다는 보고가 있습니다. 평가한 모든 모델이 MCP 대상 공격에 취약했다는 벤치마크 결과도 있습니다. 오픈소스 서버 1,899개를 분석한 연구는 일반 취약점 7.2%, 도구 포이즈닝 5.5%를 보고했고, 서버 10,655개에 대한 정적 분석은 민감정보 노출 비율이 10%를 넘는다고 밝혔습니다. 반면 기존 스캐너의 경고를 수동 검증한 연구에서는 표본 경고의 절반 미만만 실제 양성이었습니다. 이 수치들은 표본과 측정 대상이 서로 달라 하나의 위험률로 합칠 수 없고, 정적 분석 결과는 실제 실행 중 유출률도 아닙니다. 다만 도구 결과와 로그에 키, 토큰, 개인정보가 섞여 나가는지 점검할 이유로는 충분합니다. 약 2,000개 서버를 스캔했더니 모두 인증이 없었다는 보고도 있으니, 외부에 열린 서버라면 인증 구성을 먼저 확인해야 합니다.

라이선스와 요구 사양. 명세, SDK, 개별 서버의 라이선스와 요구 환경은 구성 요소마다 다릅니다. 쓰려는 서버와 SDK의 저장소 설명에서 라이선스, 지원 클라이언트, 필요한 런타임을 각각 확인해야 합니다. 보안 확장으로 제안된 연구들은 공식 명세의 변경이 아니라 연구자의 제안이며, 대부분 자체 실험 결과입니다.

윤리와 권한. 서버는 사용자 대신 계정에 접근하고 행동합니다. 클라이언트의 작업 범위를 필요한 계정과 작업으로 제한하고, 타인의 에셋이나 개인정보가 담긴 파일을 서버에 열기 전에 사용 허락 범위를 따져 봐야 합니다.

작은 작업 하나로 시작해 도구 수를 늘려 가는 순서가 안전합니다

1. 공식 문서의 개요와 Architecture 페이지로 서버, 클라이언트, 도구·리소스·프롬프트의 관계를 먼저 잡습니다.
2. 이미 쓰는 클라이언트(Claude, ChatGPT, Visual Studio Code, Cursor 등 문서에 지원으로 적힌 앱)에서 서버를 하나만 연결합니다. 출처가 분명하고 유지되는 서버를 고릅니다.
3. 조회 위주의 작업 하나를 정해 도구 목록, 호출 결과, 소요 단계를 확인합니다. 기존 API 연동이나 수작업과 시간·비용·성공률을 비교해 봅니다.
4. 상태를 바꾸는 도구(게시, 삭제, 파일 쓰기)에는 실행 전 승인을 켜고, 권한은 필요한 최소 범위로 줍니다.
5. 자사 기능을 노출해야 한다면 공식 문서의 Build servers와 Security 페이지를 읽고, 필요한 도구부터 소수로 내놓은 뒤 대표 작업으로 설명과 결과를 시험합니다.

Muckle의 판단은 읽기 중심 작업부터 도입하고 도구 수는 천천히 늘리라는 것입니다

MCP는 AI 앱이 디자인, 3D, 일정, 자사 API 같은 작업 환경에 닿는 방법이 표준화되고 있다는 점에서 이미 실무 후보입니다. 반면 도구가 늘수록 정확도가 떨어지고 서버 신뢰성 문제가 따라오므로, 지금은 조회와 초안 작성처럼 되돌릴 수 있는 작업에서 효과를 확인하는 단계입니다. 한 주 사이 언급이 늘어난 흐름은 보안과 명세 개정 논의가 함께 달아오르는 국면으로 읽히니, 도입 전에 공식 문서의 Security 페이지와 사용할 서버의 저장소 설명을 확인하세요.