기업 시스템에 MCP 연동하는 3가지 방법 — ERP·MES·그룹웨어 실전 가이드

기업 시스템에 MCP 연동하는 3가지 방법 — ERP·MES·그룹웨어 실전 가이드

Claude Code나 Cursor를 쓰다 보면 한 번쯤 "이걸 우리 회사 ERP나 그룹웨어에 붙일 수 있을까?"라는 질문을 만나게 됩니다. 이 글은 MCP(Model Context Protocol)가 기업 환경에서 ERP·MES·그룹웨어 같은 실제 시스템과 어떻게 연동되는지를 사례 중심으로 정리하고, 도입 시 반드시 챙겨야 할 보안 요구사항과 대책을 실측 수치와 함께 살펴봅니다. 개인 개발자용 로컬 설정 가이드나 프로토콜 스펙 상세는 다루지 않고, "조직에서 굴리려면 무엇이 필요한가"에 초점을 맞춥니다.

MCP가 기업 시스템 연동을 바꾸는 방식

MCP는 Anthropic이 2024년 11월에 공개한 오픈소스 표준입니다. AI 애플리케이션과 외부 시스템(DB·API·파일 등)을 표준화된 방식으로 연결하는 프로토콜로, USB-C 단자에 자주 비유됩니다. 한 번 구현하면 호환되는 모든 클라이언트에서 동일하게 동작한다는 의미입니다.^[1]

구조는 Host·Client·Server의 3-tier로 나뉩니다. Host는 Claude Desktop이나 Cursor처럼 AI를 실행하는 애플리케이션, Client는 프로토콜 연결을 유지하는 모듈, Server는 툴·리소스·프롬프트를 외부에 노출하는 경량 프로세스입니다. 기업 아키텍처에서는 Server가 ERP·MES·그룹웨어 API 앞단에 위치해 일종의 "AI용 입구" 역할을 합니다.^[5]

연동 비용 절감 효과도 두드러집니다. 기존에는 AI 에이전트가 10개의 비즈니스 툴과 붙으려면 10개의 커스텀 통합이 필요했지만, MCP를 도입하면 각 툴에 서버 1개만 구현하면 모든 호환 에이전트에서 동작합니다. 이 구조 덕분에 통합 비용을 60~70% 줄일 수 있다는 분석이 나옵니다.^[3]

생태계 확산 속도도 빠른 편입니다. 공개 후 1년 내에 OpenAI·Google·Microsoft·AWS·Linux Foundation이 지원에 합류했고, SDK 월 다운로드는 9700만 회를 넘어섰습니다. Deloitte는 2025년 기업의 25%가 에이전틱 AI 파일럿에 착수했고, 2027년에는 50%까지 늘어날 것으로 전망합니다.^[3]

ERP·MES·그룹웨어 연동 실전 사례

주요 ERP·CRM 벤더는 이미 MCP 서버를 공개한 상태입니다. 가장 대표적인 사례가 SAP입니다. SAP BTP를 통한 Level 2/3 비즈니스 프로세스 연동이 가능하고, 벤더 온보딩 시나리오에서는 MCP 서버가 SAP 시스템에 벤더를 생성하고, 외부 API로 검증하고, 누락 데이터를 식별하는 단계를 자율적으로 수행합니다. 기존에 수일이 걸리던 프로세스를 에이전틱 자동화로 옮기는 형태입니다.^[3]

SAP S/4HANA에서는 K2view 방식으로 HR·재무·공급망 모듈의 데이터를 단일 거버넌스 데이터 제품으로 묶은 뒤 MCP로 노출하는 패턴도 활용됩니다. Oracle은 Database MCP 서버를 공식 출시해 자연어로 엔터프라이즈 데이터 스토어를 쿼리할 수 있게 했습니다.^[3]

Microsoft Dynamics 365는 영업·고객 서비스·Business Central에 MCP 서버가 내장되어 있습니다. 예를 들어 다음과 같은 툴이 기본으로 노출됩니다.

• 리드 조회
• 리드 자격 평가
• 리드 요약 생성
• 이메일 아웃리치 관리

CRM과 ERP를 가로지르는 복합 쿼리도 가능합니다. "지난 2주간 고객 연락이 없었던 진행 중인 영업 기회는 무엇이고, 각 계정의 최신 지원 티켓 상태는?" 같은 질의를 던지면 MCP가 영업 모듈과 고객 서비스 모듈을 동시에 쿼리해 단일 응답을 만들어 줍니다.^[3]

그룹웨어·협업 도구도 라인업이 갖춰져 있습니다. Atlassian Jira(이슈 추적), Notion(데이터베이스·페이지), Salesforce Agentforce(CRM), HubSpot(마케팅·영업 자동화), Asana(태스크 관리) 등이 MCP 서버를 제공합니다. 다만 Asana는 2025년 6월 MCP 인스턴스 간 데이터 크로스 오염 사고가 발생한 적이 있어, 도입 시 격리 설계를 별도로 검토해야 합니다.^[3]

레거시 시스템도 손을 댈 수 있습니다. OpenAPI 명세를 파싱해 MCP 서버로 자동 변환하는 엔진을 사용하면, 기존 시스템을 변경하지 않고 2~3일 내에 AI 연동이 가능합니다. 기존 API를 MCP Tools 목록으로 자동 전환하기 때문에 시스템 재개발 없이도 시작점을 잡을 수 있다는 의미입니다.^[2]

// 의사 코드: OpenAPI 스펙을 MCP 툴로 자동 변환하는 흐름
const openapi = await loadOpenApiSpec("./legacy-erp-openapi.yaml");

const tools = openapi.paths.flatMap((path) =>
  path.operations.map((op) => ({
    name: op.operationId,        // 예: "getInventory", "createPurchaseOrder"
    description: op.summary,
    inputSchema: op.parameters,  // OpenAPI 파라미터 → MCP 입력 스키마
    invoke: async (args) => callLegacyApi(path.url, op.method, args),
  }))
);

await mcpServer.registerTools(tools);

위 흐름은 실제 변환 엔진들이 사용하는 일반적인 패턴을 의사 코드로 표현한 것입니다. 핵심은 "기존 API 계약을 그대로 두고 그 앞에 MCP 어댑터를 한 겹 얹는다"는 점입니다.

제조·물류 영역(MES 인접)에서는 IoT 통합 기반 예측 유지보수, 실시간 배송 추적, 공급망 최적화, 품질 관리 자동화 같은 시나리오가 보고되고 있습니다.^[3]

대기업 도입 사례 — Block·Amazon·Bloomberg

대형 기업들은 이미 내부 MCP 서버를 수십 개 단위로 운영하고 있습니다. 가장 적극적인 곳은 Block(Square·Cash App의 모회사)입니다. 내부 MCP 서버를 60개 이상 구축했고, 자체 AI 에이전트 Goose를 활용해 레거시 코드 리팩터링, DB 마이그레이션, 단위 테스트 자동 생성, 컴플라이언스 워크플로우 처리 같은 반복 업무를 위임하고 있습니다.^[3]

Amazon은 대부분의 내부 툴에 MCP 지원을 추가한 사례입니다. 엔지니어가 에이전트를 통해 티켓 검토, 이메일 처리, 위키 관리, CLI 운영을 자동화하는 식으로 업무 흐름이 재구성되고 있습니다.^[3]

Bloomberg는 효과를 시간 지표로 보고한 사례입니다. 전사 MCP 도입 이후 콘텐츠 제작 리드타임이 기존 수일에서 수분 단위로 단축되었다고 합니다.^[3]

세 사례의 공통점은 외부 SaaS 통합이 아니라 "내부 시스템·툴체인을 MCP로 표준화"하는 방향에 무게가 실려 있다는 점입니다. 결국 MCP는 외부 자동화 도구라기보다, 사내 시스템과 AI 사이의 공통 인터페이스 계층으로 자리잡아 가고 있습니다.

기업 MCP 보안 위협 — 실측 수치로 보는 현황

여기서부터는 분위기가 달라집니다. MCP는 연결을 쉽게 만들어 주지만, 보안을 보장하지는 않습니다. 공식 스펙도 보안을 프로토콜 수준에서 강제하지 않으며, 구현 책임은 전적으로 조직에 있다고 명시합니다.^[1]

실측 수치는 더 직설적입니다.

• 공개된 MCP 서버의 43%에 명령 삽입 취약점이 존재합니다.^[3]
• 33%는 무제한 URL 페치를 허용해 SSRF 위험이 있습니다.^[3]
• 10개 플러그인이 연결된 환경에서 익스플로잇 확률이 92%에 달한다는 분석도 있습니다.^[3]
• 공개된 MCP 서버 492개에는 기본 인증과 암호화가 적용되어 있지 않았습니다.^[5]
• OWASP Top 10 for LLM Applications 2025에서 프롬프트 인젝션은 1위 취약점으로 분류됩니다.^[1]

공격 패턴도 다양해지고 있습니다. Confused Deputy Problem은 공격자가 MCP 프록시 서버의 정적 client_id와 동적 클라이언트 등록을 동시에 악용해 사용자 동의 없이 인가 코드를 탈취하는 패턴입니다.^[1] Token Passthrough는 MCP 서버에 발행되지 않은 토큰을 그대로 수락·전달하는 안티패턴으로, 공식 스펙이 명시적으로 금지하고 있습니다. 감사 추적이 망가지고 신뢰 경계가 훼손되기 때문입니다.^[1]

2025년에 보고된 실제 사고만 모아 봐도 위험이 추상적이지 않다는 것이 드러납니다.

• Asana 데이터 누출(2025년 6월): MCP 인스턴스 간 고객 데이터 크로스 오염.^[3]
• mcp-remote RCE: 43만 7천 건 이상 다운로드된 환경에서 OAuth 인젝션으로 광범위한 침해.^[3]
• Supabase Cursor 에이전트: 지원 티켓을 매개로 한 SQL 인젝션으로 토큰 노출.^[3]
• 최초 악성 MCP 패키지(2025년 9월): 2주간 탐지되지 않은 상태로 이메일 데이터 유출.^[1]

Red Hat은 현재 스펙의 OAuth 구현 세부사항이 일부 현대 기업 관행과 충돌하는 부분이 있다고 지적했고, 커뮤니티에서도 같은 문제가 논의되고 있습니다.^[4] 결국 "프로토콜이 표준이라는 사실"과 "도입 환경이 안전하다는 사실"은 분리해 두고 보아야 합니다.

기업 도입을 위한 6가지 보안 통제

위협 목록을 그대로 두면 막막하기 때문에, 통제 항목을 6가지로 정리해 두는 편이 실무에 가깝습니다. Kiteworks와 TrueFoundry, Red Hat 가이드를 종합한 기준입니다.^[6][5][4]

1. OAuth 2.0 + PKCE 인증: 토큰은 OS 키체인 같은 보안 저장소에 보관하고, 평문 환경변수나 파일에 두지 않습니다.
2. 작업별 RBAC/ABAC 인가: 세션 단위가 아니라 개별 작업 단위로 권한을 검증하는 Per-Operation Authorization을 적용합니다. 특정 사용자가 특정 데이터에 특정 작업을 할 권한이 있는지를 매 요청마다 확인합니다.^[6]
3. 완전 귀속(attribution-level) 감사 로그: SOC 2 기준에 부합하도록 "누가, 언제, 어떤 도구로, 어떤 데이터에 무엇을 했는지"가 추적 가능해야 합니다.
4. 경로 제한 + 작업 화이트리스트: 서버가 접근 가능한 파일 경로와 호출 가능한 작업 목록을 좁게 고정합니다.
5. 사용자·세션별 rate limiting: 폭주성 요청과 자동화된 남용을 끊어 냅니다.
6. 데이터 반환 전 민감도 레이블 평가: 응답을 모델에 넘기기 전에 PII·기밀 레이블을 확인해 차단·마스킹합니다.

여기에 더해, On-Behalf-Of(OBO) 인증을 적용해 에이전트 요청이 공유 서비스 계정이 아닌 실제 요청 사용자의 권한을 위임받아 실행되도록 만드는 것이 권장됩니다. Okta·Azure AD 같은 기업 IdP 통합이 전제입니다.^[5]

네트워크 측면에서는 사설 IP 범위(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16)에 대한 접근을 차단하고, HTTPS를 강제하며, 이그레스 프록시를 두어서 외부로 나가는 트래픽을 통제하는 패턴이 자주 권고됩니다.^[1] 공급망 보안 측면에서는 SAST와 SCA를 빌드 파이프라인에 적용하고, 개발자 서명이 있는 MCP 컴포넌트만 사용하며, 버전을 고정해 변조 위험을 줄이는 것이 기본기입니다.^[4]

# 의사 코드: MCP 서버에 적용할 작업별 권한 정책 예시
tools:
  - name: get_invoice
    requires_role: [finance.viewer, finance.admin]
    rate_limit: 30/min
    sensitivity_check: pii_strict

  - name: create_purchase_order
    requires_role: [purchasing.admin]
    human_in_the_loop: true        # 명시적 사용자 승인 필요
    rate_limit: 5/min
    audit: full_attribution

위 정책은 한 줄의 설정으로 보이지만, 실제 구현은 IdP 토큰 검증·역할 매핑·감사 싱크 연동을 모두 포함합니다. 핵심은 "각 툴 호출이 자기만의 인가·로그·승인 규칙을 갖는다"는 점입니다.

배포 위치 선택도 통제의 일부입니다. 클라우드 호스팅 MCP는 빠르고 관리 부담이 낮지만, 규제 산업(의료·금융)에서는 HIPAA·GDPR 데이터 레지던시 요구를 위반할 위험이 있습니다.^[5] 반면 고객 자신의 클라우드(AWS·GCP·Azure) 내부에 거버넌스 통제를 함께 배포하면 데이터가 조직 네트워크 경계를 벗어나지 않아 컴플라이언스에 유리합니다. 다만 구축·운영 비용은 높아집니다.^[5]

컴플라이언스 적용 범위도 확인이 필요합니다. HIPAA는 환자 데이터 AI 쿼리에 "최소 필요(minimum necessary)" 기준을 적용하고, GDPR은 데이터 접근 문서화 요구사항을 AI가 시작한 검색 작업에도 적용합니다. FedRAMP는 감사 로깅 요구를 AI 시작 작업 전체로 확장하고, SOC 2는 귀속 수준 로깅 문서화를 요구합니다.^[6]

마지막으로 Human-in-the-Loop가 필요한 경계를 명확히 그어 두는 것을 권장합니다. DB 삭제, 외부 데이터 전송, 금융 거래, 대량 수정 같은 작업은 자동 실행이 아니라 명시적인 사람 승인을 거치도록 설계해야 합니다.^[5]

정리

이 글의 요점을 세 줄로 정리하면 다음과 같습니다.

• MCP는 기업 AI 연동의 공통 인터페이스로 자리잡고 있고, SAP·Oracle·Dynamics 365 같은 주요 벤더와 Block·Amazon·Bloomberg 같은 대기업이 이미 운영 중입니다.
• 레거시 시스템은 OpenAPI 자동 변환으로 2~3일 안에 연동을 시작할 수 있지만, 빠른 연동과 품질 사이의 트레이드오프는 사례별로 따져 봐야 합니다.
• MCP 프로토콜은 보안을 강제하지 않습니다. 공개 서버의 43%가 명령 삽입에 취약하다는 수치가 보여주듯, 보안 통제 설계는 도입 조직의 책임입니다.

레거시 우선 연동을 선택할지, 신중한 현대화 후 연동을 선택할지는 시스템의 중요도와 변경 위험도에 따라 갈립니다. 핵심 거래·결제계가 아니라면 OpenAPI 변환으로 빠르게 ROI를 확인하는 편이 합리적이고, 금융·의료 같은 규제 산업의 핵심 시스템은 MSA 전환과 보안 통제 설계를 먼저 마친 뒤 연결하는 쪽이 안전합니다.

다음 단계로는 MCP 공식 스펙의 보안 섹션과 Red Hat의 MCP 보안 통제 체크리스트를 함께 읽어 보는 것을 권합니다. 두 문서를 기준으로 본문의 6가지 통제를 자기 조직의 IdP·감사 시스템·배포 환경에 매핑해 두면, "도입하느냐 마느냐"가 아니라 "어떤 통제부터 적용하느냐"의 단계로 논의를 옮길 수 있습니다.

---

^[1] Model Context Protocol — Security Best Practices (Official Specification). modelcontextprotocol.io
^[2] MSAP — MCP 혁신: 레거시를 버리지 않고 AI를 도입하는 유일한 해법. msap.ai
^[3] Deepak Gupta — Model Context Protocol (MCP) Guide: Enterprise Adoption 2025. guptadeepak.com
^[4] Red Hat — Model Context Protocol (MCP): Understanding security risks and controls. redhat.com
^[5] TrueFoundry — MCP Security Risks & Best Practices: Enterprise Guide. truefoundry.com
^[6] Kiteworks — What Is the Model Context Protocol (MCP) and Why It Matters for Enterprise Data Security. kiteworks.com