도구마다 연동을 새로 만드는 문제
AI에게 사내 시스템을 쓰게 하려면 연결이 필요합니다. 캘린더를 읽고, 티켓을 만들고, 데이터베이스를 조회하는 일입니다.
문제는 이 연결이 도구마다 따로였다는 점입니다. n8n용 노드, Flowise용 커스텀 툴, 직접 만든 함수. 같은 사내 시스템에 붙는 코드를 세 벌 만들고 세 벌 유지보수하는 상황이 흔했습니다.
MCP(Model Context Protocol)는 이 부분을 표준화합니다.
왜 표준이 되었는가
MCP는 AI 시스템이 외부 데이터와 도구에 접근하는 방식을 규정한 개방형 표준입니다. 2024년 말 실험적으로 시작해 2026년 현재는 사실상의 통합 계층이 됐습니다.
채택 속도가 이례적이었습니다. 2026년 3월 기준 월간 SDK 다운로드가 9,700만 건으로, 18개월 만에 970배 증가했습니다. Fortune 500 기업의 28%가 도입했습니다. Anthropic, OpenAI, Google, Microsoft가 모두 네이티브로 지원합니다.
거버넌스도 정리됐습니다. 2025년 12월 9일 Anthropic이 MCP를 리눅스 재단 산하에 새로 만들어진 Agentic AI Foundation에 기증했고, Anthropic·Block·OpenAI가 공동 창립사, AWS·Google·Microsoft·Cloudflare·Bloomberg가 플래티넘 멤버로 참여했습니다.
특정 회사 소유가 아니게 됐다는 점이 조직 도입 관점에서 중요합니다. 한 벤더에 묶이는 결정이 아니게 됐다는 뜻이니까요.
AX 관점에서 무엇이 달라지는가
기술 표준 자체보다, 이게 앞선 글들에서 다룬 문제를 어떻게 바꾸는지가 중요합니다.
도구 교체 비용이 내려갑니다
앞서 "바깥 흐름과 안쪽 판단을 분리하라"고 한 이유가 교체 가능성이었습니다. MCP는 그 분리선을 표준화합니다. 사내 시스템에 붙는 MCP 서버를 한 번 만들면, 그 위에 어떤 도구를 얹든 다시 만들지 않습니다.
권한 경계를 한곳에서 관리합니다
지식 응답 글에서 다룬 권한 문제가 여기서 구조적으로 풀립니다. 연동마다 흩어져 있던 접근 제어를 서버 단위로 모을 수 있습니다.
감사 추적이 가능해집니다
2026년 로드맵은 감사 로그, SSO 인증, 게이트웨이 패턴, 설정 이식성 같은 기업 운영 요건에 초점을 맞추고 있습니다. 2026년 7월 28일 사양은 스테이트리스 아키텍처로 전환해 대규모 배포의 마찰을 줄였습니다.
도입할 때의 판단 기준
먼저 만들 서버를 고르는 기준은 재사용 횟수입니다
여러 워크플로가 같은 시스템을 건드리고 있다면 그게 첫 대상입니다. 한 곳에서만 쓰는 연동을 MCP로 감싸는 건 대개 과합니다.
읽기부터 시작합니다
조회 전용 서버로 시작해 동작을 확인한 뒤 쓰기를 엽니다. 앞선 자율 수준 단계와 같은 논리입니다. 되돌릴 수 없는 작업을 처음부터 열지 마세요.
도구 설명을 공들여 씁니다
MCP 서버가 노출하는 각 도구에는 설명이 붙습니다. 모델은 이 설명만 보고 언제 쓸지 판단합니다. 설명이 모호하면 엉뚱한 때 호출됩니다. 이건 프롬프트 문제가 아니라 인터페이스 설계 문제입니다.
위험한 도구는 확인 단계를 붙입니다
삭제, 발송, 결제처럼 되돌리기 어려운 동작은 서버 쪽에서 승인 절차를 강제하는 편이 안전합니다. 모델 지시에만 의존하지 마세요.
과하게 기대하지 않기
MCP는 연결 방식의 표준일 뿐, 무엇을 자동화할지의 답이 아닙니다. 업무 지도를 그리지 않은 상태에서 MCP 서버를 늘리면 연결만 많고 정리는 안 된 상태가 됩니다.
또 하나. 표준이 빠르게 움직이는 중이라 사양 변화가 있습니다. 프로덕션에 올릴 때는 사용하는 SDK 버전과 사양 버전을 고정하고, 업그레이드를 계획된 작업으로 다루세요.
MCP가 해결한 건 연동의 개수 문제입니다. 붙일 때마다 새로 만들던 것을 한 번으로 줄였습니다.
다만 무엇을 붙일지, 어디까지 권한을 줄지는 그대로 남습니다. 표준이 생겨도 그 판단은 대신해 주지 않습니다.
연결이 쉬워질수록 무엇을 연결하지 않을지가 더 중요해집니다.
