MCP로 기업 AI를 운영하는 법
지난 1년 사이 LLM의 한계로 가장 자주 지적된 두 가지가 있습니다. 첫째, 외부 도구의 도움 없이는 실제 업무를 끝까지 처리하지 못한다. 둘째, 기업 시스템과 연결하려면 매번 맞춤형 통합 코드를 짜야 한다. 두 번째 문제를 표준화하려는 시도가 MCP(Model Context Protocol) 입니다.
MCP가 무엇인가
MCP는 2024년 11월 Anthropic이 공개한 오픈 프로토콜입니다. AI 모델이 외부 데이터·도구와 연결되는 방식을 표준화하는 것이 목적입니다. 흔히 “AI를 위한 USB-C”라는 비유가 쓰이지만, 저희는 “AI 모델과 외부 시스템 사이의 공용 계약서”라는 표현이 더 정확하다고 봅니다.
구조는 간단합니다. 어떤 AI 모델이든 MCP 클라이언트 역할을 하고, 외부 시스템(내부 DB, SaaS, ERP 등)은 MCP 서버 역할을 합니다. 두 쪽 모두 동일한 프로토콜로 대화하기 때문에, 서로가 누구인지 몰라도 대화가 성립합니다.
왜 지금 MCP가 필요한가
기업 AI를 운영해 본 팀이라면 익숙한 시나리오가 있습니다. CRM의 고객 데이터를 AI가 참고해야 합니다. CRM A사의 API 스펙, 인증 방식, 스키마를 학습한 어댑터를 만듭니다. ERP도 같은 일을 반복합니다. 재고 시스템, Slack, Gmail, 내부 문서 DB까지. 연동 대상이 N개, AI 모델이 M개면 구현해야 할 어댑터는 N×M이 됩니다.
MCP는 이 구조를 뒤집습니다. 각 시스템을 한 번만 MCP 서버로 감싸 놓으면, 어떤 AI 모델이 와도 그 시스템을 쓸 수 있습니다. N×M이 N+M으로 줄어듭니다.
AI 모델이 자주 교체되고 새 시스템이 계속 추가되는 기업 환경에서 이 차이는 작지 않습니다. 유지보수 비용의 상한선 자체가 달라집니다.
기존 API 통합과 무엇이 다른가
| 항목 | 기존 API 방식 | MCP 방식 |
|---|---|---|
| 연동 구조 | AI ↔ 각 시스템 (N×M 어댑터) | AI ↔ MCP ↔ 시스템 (N+M) |
| 재사용성 | AI 모델 교체 시 재구현 | AI 모델 교체와 무관 |
| 인증·권한 | 시스템마다 커스텀 구현 | 프로토콜 수준에서 표준화 |
| 도구 디스커버리 | 개발자가 일일이 문서화 | AI가 런타임에 스스로 조회 |
| 업데이트 비용 | 통합 어댑터 개별 갱신 | MCP 서버만 갱신 |
마지막 ‘도구 디스커버리’ 차이가 실무에서 가장 크게 체감됩니다. MCP 서버는 자신이 제공하는 도구·리소스 목록을 표준 포맷으로 노출하기 때문에, AI가 필요할 때 “이 시스템이 지금 쓸 수 있는 기능이 무엇인가”를 스스로 물어볼 수 있습니다. 개발자가 모든 가능성을 미리 프롬프트에 넣어 둘 필요가 없어집니다.
기업이 MCP를 도입할 때 마주하는 네 가지 현실
1. 기존 시스템은 MCP를 모른다
레거시 ERP, 사내 메신저, 자체 개발한 웹 포털 같은 시스템은 MCP를 들어본 적이 없습니다. 도입하려면 이 시스템들을 MCP 서버로 감싸는 래퍼가 필요합니다. 복잡도는 시스템 API의 성숙도에 따라 다르지만, 보통 처음 한 번의 투자가 가장 큽니다.
2. 권한 관리와 감사 로그는 여전히 기업 책임
MCP는 연결의 언어일 뿐 권한 정책을 대신 세워 주지 않습니다. 누가 어떤 시스템의 어떤 자원을 읽고 쓰는지, 누구의 요청인지, 언제 발생했는지를 추적하는 거버넌스 레이어는 여전히 기업이 직접 설계해야 합니다.
3. PII와 민감 정보는 프로토콜 바깥의 문제다
MCP 서버가 반환하는 데이터에 주민번호, 계약 조건, 급여 정보가 섞여 있다면, 그 마스킹·필터링·암호화는 기업이 직접 책임집니다. 프로토콜이 보안을 보장하지 않습니다.
4. ‘연결’이 곧 ‘활용’은 아니다
MCP로 모든 시스템이 연결돼도, AI가 그 데이터를 의미 있게 조합하려면 Ground Truth가 필요합니다. 온톨로지와 비즈니스 규칙이 없으면 MCP는 단지 더 편한 데이터 파이프로 남습니다. 연결을 활용으로 바꾸려면 그 위에 기업 고유의 의미 체계가 올려져야 합니다.
Company OS가 MCP를 다루는 방식
저희는 Company OS를 만들면서 처음부터 MCP를 1급 시민으로 취급했습니다. 세 가지 실전 결정이 있었습니다.
첫째, MCP Store에 54개 이상의 외부 시스템을 미리 연결했습니다. AWS, SAP ERP, Oracle ERP, NetSuite, Salesforce, HubSpot, Slack, Gmail 같은 주요 SaaS는 고객이 별도 구축 없이 바로 쓸 수 있습니다. 도입 초기의 가장 흔한 ‘연동부터 하다가 지치는’ 단계를 제거하는 것이 목적입니다.
둘째, 고객사 내부 시스템을 MCP 서버로 감싸는 구축 방법론을 표준화했습니다. FDE(Forward Deployed Engineer)가 현장에 들어가 5일에서 10일 사이 분석 기간 동안 시스템 스키마·권한·감사 정책을 함께 설계합니다. 기술만 넣고 운영 체계를 고객에게 떠넘기지 않습니다.
셋째, Action 레이어에서 MCP와 A2A(Agent-to-Agent) 프로토콜을 함께 씁니다. MCP가 “AI와 시스템”의 언어라면 A2A는 “AI와 AI”의 언어입니다. 복잡한 업무는 여러 에이전트가 역할을 나눠 협력해야 풀리기 때문에, 두 프로토콜의 결합이 실전에서 사실상 필수입니다.
MCP는 ‘연결’을 표준화하지만, ‘무엇을 연결할지’는 여전히 사람 몫이다
MCP는 엔지니어링 단에서 확실한 진전입니다. 어댑터 비용이 줄고, AI 모델을 바꿔도 통합 레이어가 살아남습니다. 이 차이가 장기적으로 기업 AI 인프라의 수명과 총비용을 바꿉니다.
하지만 MCP가 답하지 않는 질문이 있습니다. 어떤 시스템의 어떤 데이터를, 어떤 AI가, 어떤 권한으로, 무엇을 위해 써야 하는가. 이 질문은 여전히 사람의 몫이고, 사실 기업 AI 도입에서 가장 어려운 부분은 프로토콜이 아니라 이 질문을 잘 던지는 일입니다.
저희는 MCP를 토대로 이 질문에 답하기 좋은 구조(Company OS의 Nexus 온톨로지, Action 워크플로우, Sense 이상 감지)를 쌓아 올리는 중입니다. 연결의 언어는 이제 공통 표준이 생겼고, 그 위에 쌓는 기업 고유의 의미 체계가 실질적 차별점이 되는 시대입니다.