기업 환경에 필요한 '좋은 MCP'의 조건

 

MCP(Model Context Protocol)는 AI 에이전트가 외부의 데이터와 도구, 시스템을 연결하여 활용할 수 있게 해주는 핵심 기술로, 기업의 AX 전환을 가속하는 중요한 요소입니다. 최근에는 AI 코딩 도구를 활용해 누구나 손쉽게 MCP를 만들 수 있지만, 잘못 설계된 MCP는 에이전트 간 호환성 문제나 기존 MCP와의 충돌, 과도한 토큰 사용과 비용 증가를 유발할 수 있습니다.

따라서 개발자는 단순히 MCP를 만드는 방법을 넘어, 다양한 환경에서 안정적이고 효율적으로 동작하는 '좋은 MCP'를 만드는 방법을 이해할 필요가 있습니다. 이 글에서는 좋은 MCP를 만들기 위한 핵심 설계 원칙들과 기업 환경에서 MCP를 확산하기 위한 Gateway, 보안, Apps, Tasks, Skills 등의 흐름을 살펴봅니다.

​

'좋은 MCP'를 만드는 설계 원칙

원칙 1. AI에게 모든 Tool과 데이터를 보여주지 않는다

MCP의 가장 흔한 문제 중 하나는 기존 API를 그대로 Tool로 만들어 AI에게 모두 제공하는 것입니다. 사내 시스템에 100개의 API가 있다면 이를 100개의 MCP Tool로 노출하는 식입니다.

하지만 Tool이 많아질수록 에이전트는 수많은 Tool의 이름, Description, 입력 스키마를 읽고 어떤 Tool을 사용할지 판단해야 합니다. 이 과정에서 처리해야 할 Context가 증가하고 토큰이 과도하게 소비되며, 오히려 Tool 선택 오류도 증가합니다. Tool 실행 결과로 대량의 데이터까지 반환한다면 에이전트가 처리해야 할 불필요한 Context와 토큰 소비 문제는 더욱 커집니다.

따라서 최근에는 Search → Context → Act와 같이 필요한 것만 단계적으로 제공하는 설계가 중요해지고 있습니다.

예를 들어, 사내 복지 시스템에 100가지 정도의 제도가 있을 때, 직원이 "결혼하는데 뭐 받을 수 있어요?"라고 물으면서 에이전트에게 100가지 제도와 Description을 전달하게 되면 비효율적이고 오답 확률도 그만큼 커지게 됩니다. 하지만 Search 단계에서 "결혼"이라는 키워드로 경조사 지원금, 신혼여행비 지원 등 관련 제도와 시스템 몇 개만 선정하고, 나머지는 검토 대상에서 제외합니다. Context 단계에서는 전체 규정 대신 지급 금액과 신청 조건 같은 핵심 정보만 요약해 전달하고, 필요할 때만 상세 정보와 절차를 추가로 불러오도록 합니다. Act 단계에서는 직원에게 필요한 사항만 정확하게 처리합니다.

핵심은 의도부터 좁히고(Search), 필요한 만큼만 압축해 제공한 뒤(Context), 실제 처리를 맡기는(Act) 흐름으로 자원 낭비를 줄이면서 더 정확한 처리가 가능해집니다.

즉, 좋은 MCP는 많은 정보를 제공하는 MCP가 아니라, 필요한 정보를 필요한 순간에 제공하는 MCP로 설계되어야 합니다.

​

원칙 2. API를 그대로 Tool로 만들지 말고 '업무' 단위로 재설계한다

MCP를 처음 만들 때 가장 쉬운 방법은 기존 API를 하나씩 MCP Tool로 변환하는 것입니다. 하지만 이러한 얇은 Wrapper 방식은 실제 업무에서는 많은 Tool Chaining을 발생시킵니다. 예를 들어 "장애/고객 문의를 종료하기" 위해 기존 API를 MCP Tool로 전환한 방식에서는 AI가 ①"상태를 '해결됨'으로 바꿔줘" → ②"해결 내용을 등록해줘" → ③"고객에게 알림을 보내줘" → ④"이력을 저장해줘"를 매번 스스로 판단해 네 번 호출해야 합니다. 매 단계마다 AI의 판단과 Tool 호출이 반복됩니다. 그만큼 토큰과 시간이 증가하고 중간 실패 가능성도 커집니다.

반면, resolve_incident(ticket_id, 해결 내용) 하나의 MCP Tool로 묶으면, AI는 "이 티켓을 이 내용으로 해결해줘"라는 요청 하나만 전달합니다. 이후 단계들(상태 변경 → 해결 내용 등록 → 고객 알림 → 이력 저장)은 MCP 서버 내부에서 하나의 흐름으로 완료되고, 실패 시 롤백(Rollback)까지 포함해 처리할 수 있습니다.

​

원칙 3. AI는 사용자 의도에 따라 답변하고, 서버는 사실을 책임진다

중요한 판단이나 검증도 가능한 한 MCP 서버나 백엔드가 담당하는 것이 좋습니다. AI 클라이언트에게 원시 데이터를 모두 넘기고 판단을 맡기기보다, 서버가 정책과 데이터를 검증한 뒤 구조화된 결과와 근거를 반환하는 방식입니다.

예를 들어 서버의 CPU·메모리·응답 시간 로그 원본을 그대로 넘겨주고 "이 서버 지금 괜찮은 거야?"를 AI가 매번 스스로 판독하게 하는 것이 아니라, 모니터링 시스템(서버)이 미리 정해진 임계치 기준으로 판단해 "정상/조치 필요/판단 불가(데이터 부족)"라는 결론과 근거 지표만 AI에게 전달하는 것과 같습니다. AI는 이 결과를 보고 사용자에게 어떻게 안내할지, 어떤 후속 조치를 제안할지만 판단하면 됩니다.

​

이는 AI의 역할을 줄이는 것이 아니라 역할을 명확하게 나누는 것입니다. AI는 사용자의 의도를 이해해 답변을 생성하고, 정해진 규칙과 정책에 따라 처리해야 할 검증과 실행은 MCP 내부 로직을 담당하는 시스템에서 처리하도록 책임과 경계를 분명하게 해야 합니다.

​

원칙 4. 특정 AI에서 동작한다고 개발이 끝난 것은 아니다

MCP가 표준 프로토콜이라고 해서 모든 AI 에이전트가 완전히 동일하게 동작하는 것은 아닙니다.

실제 환경에서는 Tool Description을 처리하는 방식과 길이, 많은 Tool을 가져오는 방식, 인증, 세션 유지, 진행 상태 표시 등에서 클라이언트별로 차이가 발생할 수 있습니다. 따라서 Codex에서는 잘 동작하는 MCP가 Cursor나 다른 클라이언트에서는 일부 Tool을 인식하지 못하거나 예상과 다르게 동작할 수 있습니다.

Tool Description 역시 무조건 길고 자세하게 작성하는 것이 좋은 것은 아닙니다. 이 Tool이 무엇을 하는지, 언제 사용해야 하는지, 언제 사용하면 안 되는지, 실행 전에 무엇을 확인해야 하는지를 짧고 명확하게 전달하는 것이 중요합니다.

기업 공통 MCP라면 특정 모델이나 클라이언트 하나만을 기준으로 개발해서는 안 됩니다. 실제 사용될 주요 AI 환경과 모델을 대상으로 동일한 업무 시나리오를 반복 검증해야 합니다.

결국 좋은 MCP는 특정 AI에서만 잘 동작하는 MCP가 아니라, 다양한 AI 환경에서 예측 가능하게 동작하는 MCP입니다.

​

좋은 MCP를 넘어, 믿고 쓸 수 있는 Enterprise MCP로

앞의 네 가지가 개별 MCP를 잘 만드는 원칙이라면, MCP가 조직 전체로 확산되면서 다른 문제가 등장합니다. 수십~수백 개의 MCP를 어떻게 찾고 연결할 것인지, 어떻게 안전하게 실행할 것인지, 그리고 Tool 호출을 넘어 더 복잡한 업무 경험을 어떻게 제공할 것인지의 문제입니다.

​

MCP Gateway: 수많은 Tool을 어떻게 전달할 것인가

CRM, ERP, 인프라, 운영, 보안 등 여러 영역에서 만든 MCP가 목록(List) 형태로 제공되면 에이전트가 모든 MCP와 Tool을 직접 연결하고 관리하기 어려워집니다.

이때 기업 환경에서는 MCP Gateway와 같은 관리 계층과 Tool Discovery가 중요한 역할을 합니다. 모든 Tool을 에이전트에 제공하는 대신 Gateway가 사용자의 목적과 권한에 맞는 Tool을 찾아 필요한 것만 제공하는 방식입니다.

업무 목적에 따라 Reporting, Infrastructure Management 등으로 Tool을 작은 그룹으로 나누어 제공할 수도 있습니다. 이를 통해 AI가 선택해야 할 Tool의 수를 줄이는 동시에 사용자가 접근할 수 있는 업무 영역도 명확하게 통제할 수 있습니다.

따라서 MCP가 몇 개일 때는 '좋은 MCP를 어떻게 만들 것인가'가 중요하지만, MCP가 수백 개가 되면 '필요한 MCP를 어떻게 찾아 적절한 사용자와 AI에게 전달할 것인가'가 새로운 문제가 됩니다.

이 관점에서 MCP Gateway는 단순한 Proxy가 아니라 Tool 검색과 라우팅, 인증·인가, 정책 적용, 모니터링을 담당하는 기업 AI의 공통 실행 플랫폼으로 볼 수 있습니다.

​

Security & Trust: AI가 실제 업무를 실행하기 시작한다면

MCP가 단순한 정보 조회를 넘어 시스템을 변경하기 시작하면 보안과 신뢰성은 더욱 중요해집니다.

AI가 결제, 인프라 변경, 고객 정보 수정과 같은 작업을 수행한다면 반드시 사용자 권한에 따라 실행 가능한 Tool을 제한해야 합니다. 삭제, 결제, 배포와 같이 영향도가 높은 작업은 Human-in-the-loop를 통해 사람의 승인을 받은 뒤 실행하도록 구성할 수도 있습니다.

또한 네트워크 타임아웃으로 AI가 동일 요청을 다시 수행했을 때 실제 업무가 중복 실행되지 않도록 멱등성(Idempotency), 트랜잭션, 상태 관리와 같은 기존 엔터프라이즈 시스템의 설계 원칙도 필요합니다.

누가 어떤 AI를 통해 어떤 Tool을 실행했고 어떤 결과가 발생했는지를 추적하는 가시성(Observability) 확보와 감사(Audit) 기능 역시 중요합니다.

결국 Enterprise MCP의 보안은 완전히 새로운 문제가 아닙니다. 기존 기업 시스템에서 축적해 온 인증·인가, 권한, 승인, 트랜잭션, 감사와 운영 관리의 원칙을 AI의 Tool 실행 환경까지 확장하는 것에 가깝습니다.

​

Tasks, MCP Apps, Skills: Tool 호출을 넘어서는 MCP

MCP의 활용 범위도 단순한 Tool 호출에서 계속 확장되고 있습니다.

Tasks는 영상 분석이나 대규모 데이터 처리처럼 오랜 시간이 걸리는 작업을 다루기 위해 도입된 MCP 공식 Extension입니다. AI가 요청을 보낸 뒤 계속 연결을 유지하는 대신 작업 상태를 관리하고 완료 여부를 확인할 수 있습니다.

MCP Apps 역시 공식 MCP Extension으로, Tool의 호출 결과를 텍스트로만 전달하는 것에서 벗어나 인터랙티브 UI로 확장합니다. 예를 들어 서버 운영 상태와 요약 결과를 텍스트로 보여주는 대신 그래프나 대시보드 같은 시각적 화면으로 만들어 AI 인터페이스 안에서 직접 보여주는 방식입니다. 주식 정보, 지도 검색, 쇼핑 결제 등 기존에 사용자에게 친숙한 GUI 화면을 보여주어 사용자의 이해와 판단이 보다 명확해질 수 있습니다. 이렇게 만들어진 화면은 특정 서비스에 종속되지 않고, MCP Apps 표준을 지원하는 클라이언트에서는 동일한 방식으로 화면을 제공할 수 있습니다.

Agent Skills는 MCP와는 별도의 기술이지만, 상호 보완적으로 활용할 수 있습니다. 쉽게 표현하면 MCP가 AI에게 '무엇을 할 수 있는가'를 제공한다면 Skills는 '그 일을 어떤 순서와 방법으로 하는가'를 알려줍니다. MCP를 통해 Jira나 Slack에 접근하는 통로를 제공한다면, Skills를 통해 회사의 복지 시스템을 사용하는 업무 절차와 공통으로 사용하는 문서 작성 규칙을 제공하는 식입니다.

앞으로 기업의 AI 환경은 단순히 기존 API를 그대로 변환한 거대한 MCP 서버가 모든 것을 처리하기보다, MCP + Gateway + Skills + Tasks + Apps가 각각 연결, 관리·통제, 업무 절차와 실행 방법, 장시간 실행, 사용자 경험이라는 역할을 나누는 방향으로 발전할 가능성이 높습니다.

​

'동작하는 MCP'에서 '좋은 MCP'로

AI 코딩 도구의 발전으로 MCP를 만드는 일은 앞으로 더욱 쉬워질 것입니다. 기존 API와 문서만 제공해도 MCP 서버의 상당 부분을 자동으로 만드는 것도 가능해지고 있습니다. 그렇기 때문에 앞으로 더 중요한 것은 'MCP를 만들 수 있는가'가 아니라 '좋은 MCP인가'입니다.

이를 위해서는 "필요한 Tool과 Context만 제공하는가?", "여러 번의 Tool 호출을 하나의 업무 단위로 줄일 수 있는가?", "AI가 판단해야 할 영역과 시스템이 보장해야 할 영역을 구분했는가?", "다양한 AI 클라이언트와 모델에서도 안정적으로 동작하는가?" 등을 고민해 설계해야 합니다.

그리고 기업 전체로 확대한다면 "수많은 MCP를 어떻게 안전하게 관리하고, 필요한 AI에게 적절하게 제공할 것인가?"와 같은 고민도 추가되어야 합니다.

MCP는 AI와 외부의 데이터, 도구, 시스템을 연결하는 인터페이스에서 시작했지만, 활용 범위가 확대될수록 AI와 실제 기업 시스템을 연결하는 중요한 실행 계층으로 발전하고 있습니다.

결국 좋은 MCP를 만든다는 것은 Tool을 많이 만드는 것이 아니라, AI가 필요한 도구와 맥락을 정확하게 발견하고 최소한의 호출로 안전하게 업무를 수행할 수 있도록 만드는 것입니다.

​

FabriX의 Enterprise MCP 플랫폼

FabriX MCP는 이러한 흐름에 맞춰, 기업에서 MCP를 안전하게 공유하고 업무에 활용할 수 있는 플랫폼으로 발전해 나갈 예정입니다.

우선 최신 MCP 규격과의 호환성을 확보하고, 향후 Tasks, MCP Apps 등 확장 기능을 단계적으로 지원하여 MCP의 활용 범위를 넓혀 나갈 계획입니다. 또한 Websearch MCP와 같이 실제 업무 생산성을 높이는 핵심 MCP(Killer MCP)를 발굴·제공할 예정입니다. 검증된 MCP는 Marketplace를 통해 조직 내에서 쉽게 찾고 공유하며, 업무와 AI Agent에 활용할 수 있도록 지원하겠습니다.

아울러 기업 환경에 필요한 MCP 보안 점검 체계를 강화할 계획입니다. 소스 코드와 오픈소스 구성요소의 취약점, API Key 등 인증 정보(Credential)의 노출 여부를 점검하여 보다 안전하고 안정적인 MCP 활용 환경을 마련하겠습니다.

궁극적으로 FabriX MCP는 유용한 MCP를 발굴·검증하고, 필요한 사용자와 AI Agent에게 안전하게 제공하는 Enterprise MCP Platform으로 발전해 나갈 것입니다.