디자이너와 PM을 위한 Model Context Protocol (MCP) 설명

엔지니어링 팀의 누군가가 스탠드업 미팅에서 "그 기능을 위해 MCP 서버를 추가하고 있어요"라고 말했을 때, 당신은 이해한 것처럼 고개를 끄덕였습니다. 사실 이해하지 못했어도 괜찮습니다. MCP에 대해 쓰여진 대부분의 글은 개발자가 개발자를 위해 작성된 것이며, 제품에 어떤 의미를 갖는지에 대해서는 아무것도 알려주지 않는 JSON 스니펫(snippets)과 SDK 참조로 가득 차 있기 때문입니다.

쉽게 설명하자면 이렇습니다: Model Context Protocol (MCP)은 AI 에이전트(AI agents)가 여러분이 이미 사용 중인 나머지 소프트웨어와 연결되는 방식에 있어 조용히 배선 표준(wiring standard)으로 자리 잡고 있습니다. 만약 당신이 에이전트 기반(agentic) 기능을 기획하는 PM이거나, 실제로 무엇이 가능한지 파악하려는 디자이너라면, 코드보다는 개념을 알아야 합니다.

MCP의 실체

잠시 USB-C를 생각해 보세요. USB-C가 존재하기 전에는 모든 기기마다 고유한 충전 케이블, 고유한 포트 모양, 고유한 어댑터가 필요했습니다. 그러다 하나의 표준이 등장하면서 갑자기 노트북, 휴대폰, 헤드폰이 모두 동일한 종류의 포트에 연결될 수 있게 되었습니다. MCP는 이 아이디어를 AI에 적용한 것입니다.

MCP 이전에는 AI 모델이 회사의 Notion 문서를 읽고, Slack을 확인하고, Jira 티켓을 생성하게 하려면, 누군가가 각각 별도의 인증, 별도의 데이터 형식, 별도의 유지보수 부담을 가진 세 개의 개별적인 커스텀 통합(custom integrations)을 구축해야 했습니다. 이를 회사가 출시하는 모든 도구와 모든 AI 제품에 적용해 보면 조합론적인 혼란(combinatorial mess)이 발생합니다. 즉, N개의 도구와 M개의 AI 제품이 곱해지면 N x M개의 커스텀 커넥터(connectors)가 생기며, 이들은 각각 취약하고 재사용할 수도 없습니다.

MCP는 이러한 혼란을 세 가지 정의된 역할로 대체합니다. **호스트 (Host)**는 Claude Desktop, IDE, 또는 팀이 구축한 커스텀 에이전트와 같이 사용자가 실제로 보는 애플리케이션입니다. **클라이언트 (Client)**는 호스트 내부에 존재하며 특정 서버와의 연결을 관리합니다. **서버 (Server)**는 Slack 통합 또는 데이터베이스 커넥터와 같은 외부 프로그램으로, 모델이 이해할 수 있는 표준 형식으로 자신이 할 수 있는 일을 노출합니다.

한 번 서버가 MCP를 지원하게 되면, 어떤 MCP 호환 호스트(host)라도 별도의 맞춤형 코드 없이 이를 사용할 수 있습니다. 새로운 AI 도구가 Slack과 통신하고 싶을 때마다 귀하의 Slack 커넥터를 매번 다시 만들 필요가 없습니다. 단지 한 번 프로토콜 (protocol)을 따르기만 하면 됩니다.

서버가 실제로 제공할 수 있는 세 가지 요소

이 부분은 제품 사고 (product thinking) 측면에서 가장 중요한 부분인데, 왜냐하면 에이전트 (agent)가 무엇을 할 수 있는지 그 형태를 정의하기 때문입니다.

서버는 세 가지 종류의 기능 (capability)을 노출합니다. **도구 (Tools)**는 모델이 수행할 수 있는 작업입니다: 메시지 전송, 레코드 생성, 쿼리 (query) 실행, 회의 예약 등입니다. 이것들은 에이전트가 단순히 말만 하는 것이 아니라 실제로 업무를 수행하고 있다는 느낌을 주는 요소들입니다. **리소스 (Resources)**는 모델이 컨텍스트 (context)로 가져올 수 있는 데이터입니다: 파일, 고객 기록, 문서, 지원 티켓 (support ticket) 등입니다. 이것은 에이전트가 추측하는 대신 실제 회사의 데이터에 기반하여 답변을 내놓는 (grounding) 방식입니다. **프롬프트 (Prompts)**는 서버가 제공하는 재사용 가능한 템플릿으로, 모델에게 "누군가 환불에 대해 물어보면 이런 방식으로 접근하세요"라고 말하는 표준화된 방식입니다. 이는 사용자에게는 덜 보이지만, 조직이 자신들만의 플레이북 (playbooks)을 에이전트의 행동 방식에 녹여내는 방법입니다.

기능의 범위를 정할 때 엔지니어가 "그것을 MCP 도구(tool)로 노출할 수 있습니다"라고 말한다면, 그 의미는 모델이 단순히 그 동작을 설명하는 것에 그치지 않고 실제로 그 동작을 수행할 수 있다는 뜻입니다. 이 차이점은 여러분이 기획서(spec)를 작성하는 방식을 바꿔 놓아야 합니다. 여러분의 주문 상태를 말해줄 수 있는 챗봇은 리소스(resource)의 문제이지만, 여러분의 주문을 취소할 수 있는 챗봇은 도구(tool)의 문제이며, 이 경우에는 완전히 다른 수준의 확인 UX, 에러 핸들링(error handling), 그리고 감사 로그(audit logging)가 필요합니다.

요청 여부와 상관없이 이것이 여러분의 로드맵에 등장하는 이유

MCP는 더 이상 소수의 개발자들만 선호하는 기술이 아닙니다. Anthropic이 2024년 말에 이를 도입한 이후, 생태계는 AI 기준에서도 진정으로 이례적인 속도로 성장했습니다. 2026년 3월 기준으로, 이 프로토콜의 월간 SDK 다운로드 수는 약 9,700만 건에 달했으며, 이는 약 18개월 만에 970배 증가한 수치입니다. 또한 공식 MCP 레지스트리(registry)는 9,600개 이상의 활성 서버를 추적하고 있습니다. Fortune 500 기업의 도입률은 2년도 채 되지 않아 약 28%에 도달한 것으로 보고되었으며, 분석가들은 2026년 중 기업용 애플리케이션 벤더의 거의 3분의 1이 자체적인 MCP 서버를 출시할 것으로 예상하고 있습니다.

더 구체적으로 말하자면, 여러분의 회사가 이미 사용 중인 도구들은 이제 퍼스트 파티(first-party) MCP 서버를 갖추고 있을 가능성이 높습니다. Slack의 서버는 에이전트(agent)가 스레드를 검색하고 업데이트를 게시할 수 있게 해줍니다. GitHub의 공식 서버는 에이전트가 리포지토리(repo)를 읽고, 이슈(issue)를 생성하며, 풀 리퀘스트(pull request)를 제출할 수 있게 합니다. Notion은 에이전트가 워크스페이스 전체에서 읽기, 쓰기 및 검색을 할 수 있는 서버를 출시했습니다. Zapier의 MCP 서버는 수천 개의 다른 앱으로 연결되는 가교 역할을 하므로, 팀은 네이티브 통합(native integration)을 기다리는 대신 즉시 "충분히 근접한" 연결성을 확보할 수 있는 경우가 많습니다.

제품 팀의 입장에서 이는 '직접 구축할 것인가(build) 아니면 연결할 것인가(connect)'에 대한 계산법을 변화시킵니다. 과거에는 전담 통합 스프린트(integration sprint)가 필요했던 기능이 이제는 기존의 MCP 서버를 연결하는 문제로 바뀔 수 있습니다. 이는 개발 속도(velocity) 측면에서 좋은 소식입니다. 또한, 제품의 차별화 포인트가 "Salesforce와 연결했다"는 점(점점 더 범용화/Commoditized 되고 있는 부분)에서, 에이전트가 해당 연결을 통해 수행하는 작업 주위의 경험을 얼마나 잘 설계하느냐로 이동하고 있음을 의미합니다. 즉, 확인 절차(confirmations), 보여주는 컨텍스트(context), 그리고 무언가 잘못되었을 때 복구하는 방식 등이 중요해집니다.

제품을 출시하기 전 던져야 할 질문들

여기는 마케팅 문구에는 나타나지 않는 부분입니다. MCP 서버는 설계상 모델에게 실제 행동을 취하고 실제 데이터를 가져올 수 있는 능력을 부여하며, 이는 제품 및 디자인 결정이 직접적으로 영향을 미치는 진정으로 새로운 리스크 표면(risk surface)을 생성합니다.

보안 연구원들은 비록 여러분이 직접 문제를 해결하는 사람이 아닐지라도, 이름을 알아둘 가치가 있는 몇 가지 구체적인 우려 사항들을 지적해 왔습니다. **과도한 권한 부여(Over-privileged access)**는 에이전트가 작업에 필요한 것보다 훨씬 더 넓은 권한을 가진 서버에 연결될 때 발생하며, 이는 제한된 계정을 설정하는 것보다 편하다는 이유로 인턴에게 관리자 비밀번호를 주는 것과 같습니다. **도구 오염(Tool poisoning)**은 공격자가 도구의 설명이나 메타데이터를 조작하여, 사용자가 인지하지 못하는 사이에 모델이 따를 수 있는 숨겨진 지침을 몰래 집어넣는 것을 말합니다. 오픈 소스 MCP 서버를 분석한 한 연구에 따르면 약 5.5%가 이러한 종류의 공격 패턴을 보였습니다. **간접 프롬프트 주입(Indirect prompt injection)**은 사용자의 직접적인 요청이 아니라 에이전트가 읽는 문서나 웹페이지에 악의적인 지침이 포함되어 전달되는 방식으로, 한 유명 보안 연구원의 표현을 빌리자면 업계가 수년 동안 알고 있었음에도 불구하고 아직 설득력 있는 해결책이 없는 문제입니다.

2026년 MCP 사양(spec) 업데이트에서는 점진적 범위 동의(incremental scope consent)가 도입되었습니다. 이는 클라이언트가 사전에 포괄적인 권한을 부여하는 대신, 특정 작업에 필요한 최소한의 액세스 권한만을 요청할 수 있음을 의미합니다. 이는 엔지니어링 측면의 해결책이지만, 동시에 디자인 측면에서도 기회입니다. 만약 당신의 제품이 온보딩(onboarding) 과정에서 사용자에게 "캘린더 전체 액세스 권한"을 한 번 요청하고 다시는 언급하지 않는다면, 당신은 취약한 버전을 만든 것입니다. 반면, 상황이 중요해질 때마다 문맥에 맞춰 "이 에이전트가 귀하의 캘린더에 이벤트 하나를 생성하려고 합니다. 허용하시겠습니까?"라고 묻는다면, 당신은 사용자 신뢰를 잃지 않고 사고 상황에서도 살아남을 수 있는 버전을 만든 것입니다.

PM(Product Manager)이나 디자이너로서 권한 시스템을 직접 설계할 필요는 없습니다. 하지만 엔지니어링 팀에 명시적으로 질문해야 할 것은 있습니다. 모든 MCP 서버 연결이 실제로 어떤 범위의 액세스 권한을 부여하는지, 그리고 사용자가 그 범위에 대해 전혀 인지하지 못하고 있는 것은 아닌지 확인해야 합니다. 이 질문 하나만으로도 당신은 현재 에이전트(agentic) 기능을 출시하고 있는 대부분의 팀보다 앞서 나갈 수 있습니다.

당신이 처한 상황

MCP는 인프라(infrastructure)이며, 인프라는 보통 고장 나거나 경쟁사가 당신보다 더 빠르게 출시하는 무언가를 가능하게 할 때까지는 보이지 않는 법입니다. 여기서 다룬 수준, 즉 호스트(host), 클라이언트(client), 서버(server), 도구(tools) 대 리소스(resources) 대 프롬프트(prompts)의 차이, 그리고 실제 행동을 취하는 에이전트와 함께 따라오는 동의(consent) 문제들을 이해하는 것만으로도, 기획 회의에서 단순히 고개를 끄덕이는 대신 적절한 질문을 던지기에 충분합니다.

다음 단계의 에이전트 제품 디자인에서 승리할 팀은 JSON-RPC 핸드셰이크(handshake)를 이해하는 팀이 아닙니다. "도구(tool)"란 실제 결과가 따르는 실제 행동임을 조기에 이해하고, 출시 후에 이를 깨닫는 대신 그 사실을 중심으로 경험을 설계한 팀이 승리할 것입니다.

👨‍💻 저와 연결하세요

Rohit Raghuvansh
💡 UX Thinker · AI Builder · 복잡한 기술을 인간 중심적으로 만듭니다

연결 및 팔로우

LinkedIn — Rohit Raghuvansh

📢 이 글이 도움이 되었나요?

이 글이 당신의 학습 여정에 가치를 더했다면:

✅ 당신의 네트워크에 공유하세요 ✅ 나중에 참고할 수 있도록 북마크하세요 ✅ 더 많은 정보를 위해 팔로우하세요

계속 배우고, 계속 만들고, 계속 성장하세요. 🚀