회사에서 AI에게 “지난달 상담 기록을 찾아 미응답 고객을 정리해 줘”라고 요청하려면 AI가 고객관리 시스템을 찾고, 필요한 자료를 읽고, 결과를 표로 돌려줄 수 있어야 합니다. 예전에는 사용하는 AI와 업무 도구의 조합마다 이 연결을 따로 만들어야 했습니다.
MCP(Model Context Protocol)는 AI가 문서함·데이터베이스·업무 서비스의 기능을 같은 방식으로 발견하고 사용할 수 있게 만든 공개 연결 규칙입니다. 연결 개발은 줄여주지만 접근 권한, 사람 승인, 감사 기록과 허용할 업무까지 대신 결정하는 만능은 아닙니다.
MCP는 흔히 ‘AI용 USB 규격’에 비유됩니다. 서로 다른 제조사의 기기가 같은 단자를 쓰면 연결할 때마다 새 케이블을 만들 필요가 없는 것처럼, 업무 서비스가 MCP 서버로 기능을 제공하면 여러 AI 애플리케이션이 공통 방식으로 그 기능을 찾고 호출할 수 있습니다. 다만 USB에 꽂았다고 파일을 누구에게나 공개해도 되는 것은 아닙니다. MCP에서도 연결 가능함과 사용을 허용함은 다른 문제입니다.
MCP가 실제로 표준화한 것
MCP는 AI가 사용할 수 있는 정보를 크게 세 종류로 표현합니다.
- 도구(Tools): 검색, 문서 생성, 메일 발송처럼 실행할 수 있는 기능
- 자료(Resources): 파일, 데이터베이스 기록, 업무 문서처럼 읽을 수 있는 정보
- 프롬프트(Prompts): 특정 작업을 시작할 때 사용하는 미리 정한 절차나 양식
AI 애플리케이션은 MCP 클라이언트가 되고, 업무 기능을 제공하는 쪽은 MCP 서버가 됩니다. 서버는 “내가 제공하는 기능은 무엇이고 어떤 입력이 필요한가”를 공통 형식으로 설명합니다. 클라이언트는 이 설명을 읽어 사용 가능한 기능을 사용자에게 보여주거나 작업 과정에서 호출합니다.
이 구조의 장점은 도구 하나를 여러 AI에 연결할 때 드러납니다. 고객관리 시스템이 MCP 방식으로 고객 조회 기능을 한 번 제공하면, 이를 지원하는 각 AI 제품을 위해 완전히 다른 연결 프로그램을 반복해서 만들 필요가 줄어듭니다. AI 제품을 바꿀 때도 기존 업무 시스템 전체를 다시 고치는 부담이 작아집니다.
2026년 7월 28일 확정된 MCP 최신 명세는 연결을 일반적인 웹 인프라에서 운영하기 쉽게 바꿨습니다. 요청마다 필요한 정보를 담는 구조, 오래 걸리는 작업을 다루는 확장 기능, 사용자의 추가 입력이나 승인을 중간에 받을 수 있는 방식, 인증 과정의 보완 등이 포함됐습니다. 이것은 “초안 기술이 완성됐다”는 뜻이라기보다, 실제 운영에서 발견된 문제를 반영하며 표준이 계속 성숙하고 있다는 신호에 가깝습니다.
왜 이제 특정 회사의 기능으로만 보기 어려운가
MCP는 Anthropic이 시작했지만 지금은 특정 AI 회사만의 연결 방식으로 보기 어렵습니다. 프로젝트는 Linux Foundation 산하 Agentic AI Foundation에서 다뤄지고 있으며, 2026년 8월 이 재단은 전 세계 회원 조직이 247곳으로 늘었다고 발표했습니다. 금융기관, 클라우드 기업, 소프트웨어 회사와 연구기관이 함께 참여합니다.
9월에는 Linux Foundation이 MCP 아키텍처·보안·거버넌스를 다루는 벤더 중립 자격 과정도 공개했습니다. 당시 발표에서 Tier 1 SDK의 월간 다운로드가 5억 회에 가까워지고 있다고 밝혔습니다. 다운로드 수를 실제 기업 도입 수로 읽을 수는 없지만, 여러 제품이 공통 연결 방식에 투자하고 있다는 정황으로는 충분합니다.
공개 MCP 서버를 찾을 수 있는 공식 MCP Registry도 운영됩니다. 그러나 공식 목록에 등록됐다는 사실이 모든 서버의 보안과 품질을 보증한다는 뜻은 아닙니다. 레지스트리는 발견과 배포 방식을 표준화하는 역할을 하고, 조직이 실제로 사용할 서버를 검토하는 책임은 남습니다.
표준이 생기면 무엇이 쉬워지는가
일반 조직의 입장에서 변화는 세 가지입니다.
첫째, 연결을 다시 만드는 일이 줄어듭니다. 이메일, 문서함, 고객관리 시스템 같은 도구가 공통 규격을 제공하면 AI 제품을 추가하거나 교체할 때 기존 연동을 재사용할 가능성이 커집니다.
둘째, AI가 쓸 수 있는 기능을 목록으로 관리하기 쉬워집니다. 어떤 서버가 어떤 도구와 자료를 제공하는지 같은 형식으로 볼 수 있기 때문에, 여러 자동화에 흩어진 연결을 한곳에서 관리할 기반이 생깁니다.
셋째, 도구 호출 기록을 공통 관문으로 모으기 쉬워집니다. 최신 명세는 요청을 라우팅하고 측정하기 위한 정보를 표준화하고, 분산 추적을 위한 방식도 문서화했습니다. 여러 서비스에서 발생한 호출을 하나의 작업 흐름으로 따라갈 수 있는 토대입니다.
이 세 가지는 모두 자동화 비용을 낮춥니다. 그동안 사람이 고객관리 시스템에서 주소를 복사해 메일 도구에 붙여 넣거나, 보고서에 넣을 숫자를 여러 서비스에서 모았다면 에이전트가 그 이동을 맡을 수 있습니다. 다만 도구 사이를 오가는 시간이 줄어든다고 판단과 책임까지 사라지는 것은 아닙니다.
MCP가 결정하지 않는 것
MCP는 연결 규칙입니다. 회사의 업무 규정은 아닙니다.
| MCP가 제공하는 기반 | 조직이 별도로 정할 내용 |
|---|---|
| AI가 사용할 도구와 입력 형식을 설명 | 어떤 부서와 사용자에게 그 도구를 열어줄지 |
| 인증·권한 위임을 구현할 공통 절차 | 읽기·수정·삭제·발송 중 어디까지 허용할지 |
| 작업 중 추가 입력이나 승인을 요청하는 방식 | 어떤 행동에서 누구의 승인을 받을지 |
| 호출을 추적하고 기록할 수 있는 정보 | 기록을 얼마나 보관하고 누가 검토할지 |
| 공개 서버를 발견하는 레지스트리 | 실제 도입할 서버의 운영자와 코드를 신뢰할지 |
예를 들어 MCP가 메일 발송 도구의 호출 방법을 표준화해도, 고객에게 바로 보낼지 담당자 확인 후 보낼지는 정하지 않습니다. 파일 삭제 기능이 있다는 사실은 알려주지만 어느 폴더에서만 허용할지도 회사가 결정해야 합니다.
공식 MCP 보안 모범 사례는 사용자 동의 우회, 다른 서비스용 토큰의 재사용, 내부 네트워크로 향하는 악성 요청 등 여러 공격 경로를 별도로 설명합니다. 명세에 보안 조항이 있다는 사실만으로 안전한 구현이 자동으로 만들어지지 않기 때문입니다. 특히 다른 서비스에서 받은 토큰을 검증 없이 전달하는 방식은 금지된 안티패턴으로 다뤄집니다.
연결 전에 허용 목록부터 만든다
MCP를 도입할 때 흔한 출발점은 “어떤 서비스를 연결할 수 있는가”를 조사하는 것입니다. 그러나 실제 운영에서는 “어떤 업무를 어떤 조건으로 허용할 것인가”를 먼저 정해야 합니다.
다음과 같이 한 업무를 작은 단위로 나누면 판단하기 쉽습니다.
| 행동 | 첫 도입 때 권장 범위 | 확인할 통제 |
|---|---|---|
| 문서 검색·조회 | 지정 폴더와 읽기 전용 계정 | 검색 범위와 민감정보 노출 기록 |
| 자료 요약·분류 | 내부 초안으로만 저장 | 사용한 자료와 분류 기준 표시 |
| 문서·표 작성 | 별도 초안 폴더에 생성 | 기존 파일 덮어쓰기 금지 |
| 메일·메시지 작성 | 초안 생성까지만 자동화 | 수신자와 본문을 사람이 확인 |
| 발송·삭제·결제 | 초기에는 자동 실행 금지 | 명시적 승인과 즉시 중단 수단 |
처음부터 전체 드라이브와 메일 발송 권한을 연결하는 대신, 읽기 전용 자료 한 곳과 결과를 저장할 새 폴더부터 여는 편이 안전합니다. 효과가 확인되면 업무 단위로 권한을 넓힙니다. 에이전트 권한을 좁게 시작하는 기준은 AI 에이전트 제로 트러스트 운영 원칙에서 더 자세히 설명했습니다.
공개 Registry에서 바로 서버를 설치하기보다 조직에서 승인한 서버 목록을 별도로 두는 것도 필요합니다. 다음 항목을 확인한 뒤 목록에 올리는 방식입니다.
- 서버 운영 주체와 공식 저장소가 분명한가
- 최근 업데이트와 보안 패치가 이어지고 있는가
- 요청하는 권한이 제공 기능에 비해 과도하지 않은가
- 도구 설명이나 기능이 업데이트될 때 변경 내용을 검토할 수 있는가
- 장애 시 연결을 끊고 토큰을 회수할 수 있는가
- 호출 기록에서 사용자와 실행 결과를 구분할 수 있는가
개인 계정과 승인되지 않은 자동화가 공식 관문을 우회하면 공통 표준의 장점도 사라집니다. 이런 상황은 섀도우 오퍼레이션으로 이어질 수 있습니다.
MCP 도입 여부를 판단하는 간단한 기준
MCP가 모든 연결 문제의 답은 아닙니다. 한 AI 제품과 한 업무 서비스만 안정적으로 쓰고 있고 연결을 바꿀 계획이 없다면 기존 공식 연동이 더 단순할 수 있습니다. 반대로 여러 AI와 여러 업무 도구를 함께 사용하거나, 특정 공급자에 묶이지 않고 연결을 재사용하려는 조직에는 가치가 커집니다.
도입 전에는 다음 질문에 답해보는 것이 좋습니다.
- 같은 업무 도구를 두 개 이상의 AI 제품에서 사용할 필요가 있는가
- 현재 연결을 유지하거나 다시 만드는 비용이 반복해서 발생하는가
- 승인된 서버와 도구 목록을 관리할 담당자가 있는가
- 읽기와 쓰기 권한을 업무별로 나눌 수 있는가
- 발송·삭제·결제 전에 사람 승인을 강제할 수 있는가
- 연결을 중단하고 자격증명을 회수하는 절차가 있는가
앞의 두 질문에만 답하고 뒤의 네 질문을 비워두면 MCP는 연결을 늘리는 도구에 그칩니다. 여섯 질문을 함께 다뤄야 연결이 조직의 운영 자산이 됩니다.
MCP가 바꾼 것은 AI와 업무 도구 사이의 공통 문법입니다. 앞으로는 허용할 연결을 고르고, 필요한 권한만 주고, 실행을 확인할 수 있는 능력이 연결 개수보다 중요해집니다.
