Deep Dive · 중급

MCP란 무엇인가? Function Calling과 차이 및 기업 AI 에이전트 통합 설계

MCP는 AI 애플리케이션과 외부 도구·리소스·프롬프트 서버 사이의 연결을 표준화하지만 기존 API·인증·정책을 대체하지 않으므로, 기존 업무 API 위에 최소 권한 MCP 서버와 중앙 정책·승인·감사 계층을 두어야 한다.

발행 2026-04-21AI Agent10분 읽기

30초 답변

MCP(Model Context Protocol)는 AI 애플리케이션이 외부 시스템의 도구, 리소스와 프롬프트를 발견하고 사용하는 연결 방식을 표준화하지만, 기존 업무 API나 인증·권한·감사 정책을 대신하지는 않는다. 기업에서는 CRM·ERP·문서 시스템의 기존 API를 그대로 기준 시스템으로 두고, 업무 영역별 MCP 서버가 안전한 작업만 좁게 노출하도록 설계해야 한다. 그 앞단의 호스트 또는 정책 계층은 사용자 신원, 도구 허용 목록, 최소 권한, 사람 승인, 비용 한도와 추적을 강제해야 한다.

이 글의 핵심

Function Calling은 모델이 어떤 도구를 어떤 인자로 호출할지 표현하는 방식이고, MCP는 AI 호스트와 외부 서버 사이의 발견·연결·호출 계약을 표준화하는 프로토콜이다.
MCP 서버는 기존 API를 “AI가 쓰기 좋은 도구”로 포장하는 어댑터이자 보안 경계다. 업무 규칙과 데이터 원본을 새로 복제하지 않는다.
서버가 제공하는 도구 목록을 그대로 모델에 노출하지 말고 사용자·업무별 허용 목록과 위험 정책을 적용한다.
사용자 토큰을 하위 API로 그대로 전달하는 token passthrough를 피하고, MCP 서버 대상 토큰과 하위 시스템 자격 증명을 분리한다.
명세의 기능 지원은 클라이언트·서버마다 다르므로 초기 capability 협상과 호환성 테스트를 해야 한다.

기존 Tool Calling 기반 AI Agent 설계 전략이 도구의 역할과 실패 처리를 다뤘다면, 이 글은 여러 AI 호스트와 기업 도구 사이의 연결 계약, 신뢰 경계와 운영 수명 주기에 집중한다.

MCP는 어떤 문제를 해결하나

AI 애플리케이션이 사내 시스템을 쓰려면 도구 이름, 입력 스키마, 연결 방식, 인증, 결과 형식을 런타임마다 붙여야 한다. 시스템과 AI 호스트가 늘어날수록 같은 연결을 반복 구현하기 쉽다.

MCP 공식 아키텍처는 다음 세 역할을 구분한다.

호스트: 사용자가 쓰는 AI 애플리케이션. 정책, 사용자 경험과 여러 연결을 관리한다.
클라이언트: 호스트 안에서 특정 MCP 서버와 세션을 유지하는 프로토콜 구성 요소.
서버: 도구, 리소스, 프롬프트 같은 기능을 노출하는 프로그램 또는 서비스.

서버가 제공하는 핵심 요소는 다음과 같다.

Tools: 데이터 조회, API 호출, 계산, 파일 변경처럼 모델이 선택해 실행할 수 있는 기능
Resources: 파일, 스키마, 문서처럼 호스트가 컨텍스트로 사용할 데이터
Prompts: 사용자가 선택할 수 있는 재사용 가능한 작업 템플릿

이 표준화 덕분에 호스트는 서버가 제공하는 기능을 발견하고 정해진 메시지로 호출할 수 있다. 그러나 “연결 가능”과 “기업 정책상 사용 가능”은 다른 판단이다.

MCP와 Function Calling은 경쟁 기술이 아니다

구분	Function Calling	MCP
중심 질문	모델이 어떤 함수와 인자를 요청하는가	AI 호스트가 외부 서버의 기능을 어떻게 발견하고 호출하는가
범위	모델 호출과 애플리케이션 런타임 내부	호스트·클라이언트와 외부 서버 사이 프로토콜
도구 제공	애플리케이션이 정의를 모델 요청에 포함	서버가 tools/list로 도구를 노출하고 클라이언트가 가져옴
실행	애플리케이션이 함수·API를 호출	클라이언트가 tools/call로 서버에 요청
추가 기능	런타임별 도구 호출 기능에 따름	tools 외 resources, prompts와 프로토콜 기능 제공
보안 책임	애플리케이션·API가 설계	호스트, MCP 서버, 인증 서버, 하위 API가 나눠 가짐

실제 흐름에서는 둘이 함께 쓰인다. MCP 클라이언트가 서버에서 도구 정의를 가져오고, 호스트가 허용된 도구를 모델에 제공한다. 모델이 도구 호출을 선택하면 호스트가 이를 MCP tools/call 요청으로 변환하고 결과를 다시 모델에 전달한다. OpenAI Agents SDK의 MCP 문서도 MCP 도구를 에이전트의 도구로 연결하고 필터링, 캐싱, 승인과 추적을 적용하는 구현 방식을 제공한다.

따라서 “Function Calling을 버리고 MCP로 전환한다”보다 “기존 함수·API 도구를 어떤 MCP 서버 경계로 표준화할 것인가”가 더 정확한 질문이다.

MCP가 적합한 경우와 그렇지 않은 경우

적합한 경우

같은 업무 도구를 여러 AI 호스트나 에이전트 런타임에서 재사용해야 한다.
도구 목록과 스키마가 변경될 때 중앙 서버에서 수명 주기를 관리하고 싶다.
문서·데이터 리소스와 작업 프롬프트까지 공통 방식으로 제공해야 한다.
도구 제공 팀과 AI 애플리케이션 팀의 소유권을 명확히 나누고 싶다.
원격 서버와 로컬 도구를 일관된 프로토콜로 연결할 필요가 있다.

먼저 기존 방식이 나은 경우

한 애플리케이션 안의 함수 한두 개만 호출한다.
극도로 짧은 지연과 단순한 호출 경로가 최우선이다.
도구 계약이 아직 불안정해 표준 서버로 운영할 준비가 없다.
MCP를 도입해도 인증, 권한, 버전 관리와 관측성을 맡을 팀이 없다.
기존 API 게이트웨이만으로 목적과 재사용 범위를 충분히 충족한다.

MCP는 에이전트를 자동으로 만들어 주지도 않는다. 실행 경로가 고정된 업무라면 MCP 도구를 쓰는 워크플로일 뿐이다. 먼저 AI 에이전트 vs 워크플로 자동화의 기준으로 자율 판단이 필요한지 확인한다.

권장 기업 참조 구조

1. 사용자·채널 계층

웹, 메신저, IDE 같은 채널에서 사용자 인증과 요청을 받는다. 최초 요청자, 테넌트, 역할, 현재 업무 목적을 최상위 실행 컨텍스트에 유지한다.

2. Agent Host와 오케스트레이션

모델, 대화 상태, RAG, 도구 선택과 실행 루프를 관리한다. 단일 또는 멀티에이전트 선택은 도구 수가 아니라 병렬성·컨텍스트 격리와 평가 결과로 정한다. 자세한 기준은 단일 에이전트 vs 멀티에이전트를 참고한다.

3. 정책 집행 계층

호스트와 MCP 연결 지점에서 다음을 강제한다.

사용자·테넌트별 서버 및 도구 허용 목록
도구 인자 검증과 데이터 분류
읽기·쓰기·삭제·외부 전송·금전·권한 위험 등급
요청·분당·작업당 호출과 비용 한도
고위험 작업의 사람 승인
모델에 전달할 결과의 크기·민감정보 필터
trace_id, task_id, user_id를 연결한 감사·추적

정책 판단을 모델 프롬프트에만 두지 않는다. 서버 또는 게이트웨이가 결정론적으로 실행을 차단할 수 있어야 한다.

4. MCP 서버 카탈로그와 신뢰 관리

승인된 서버의 소유자, 배포 위치, 코드·패키지 출처, 지원 명세 버전, 도구 목록, 데이터 등급, 필요한 scope, 연락처와 폐기 일정을 등록한다. 서버 URL을 사용자가 임의 입력해 바로 연결하는 구조는 피한다.

카탈로그는 단순 목록이 아니라 allowlist다. 새 도구가 서버에 추가돼도 자동으로 모든 에이전트에 공개하지 않고 검토 후 정책에 반영한다.

5. 업무 영역별 MCP 서버

CRM, ERP, 문서, 개발 도구처럼 신뢰 경계와 소유 팀 단위로 나눈다. 한 서버에 전사 API를 모두 모으면 침해 범위와 도구 선택 혼선이 커진다. 서버는 다음 원칙을 지킨다.

기존 업무 API와 정책 엔진을 호출하고 원본 데이터를 복제하지 않는다.
모델 친화적인 이름·설명·입력 스키마를 제공한다.
사용자 신원과 업무 목적을 검증한다.
하위 API 오류를 구조화해 반환하고 민감한 내부 정보를 숨긴다.
변경 작업은 멱등성 키와 결과 조회 기능을 갖는다.

6. 기존 API·데이터 계층

ERP, CRM, IAM, 문서 저장소가 최종 기록 시스템이다. MCP 서버가 비즈니스 검증을 우회하지 못하도록 기존 API의 권한, 유효성 검증과 감사 로그를 유지한다.

도구 계약은 모델과 운영자 모두 이해할 수 있어야 한다

MCP 2025-11-25 Tools 명세는 도구 이름, 설명과 JSON Schema 기반 입력을 정의하고 tools/list와 tools/call 흐름을 규정한다. 기업 도구에는 다음을 추가로 설계한다.

하나의 도구는 하나의 분명한 결과를 만든다

“manage_customer”처럼 조회·수정·삭제를 한 도구에 넣지 말고 “get_customer”, “draft_customer_note”, “save_customer_note”로 나눈다. 그래야 모델 선택과 승인 정책을 독립 적용할 수 있다.

입력은 업무 식별자와 제한을 명시한다

자유 텍스트 하나로 SQL, 경로 또는 수신자를 만들게 하지 않는다. customer_id, document_id, allowed_folder, maximum_results처럼 검증 가능한 필드를 사용하고 enum, 길이, 형식과 필수값을 제한한다.

출력은 구조화 결과와 사용자용 요약을 분리한다

성공 여부, 결과 ID, 변경 전후 버전, 재시도 가능성, 출처 링크를 구조화한다. 긴 원문을 무조건 반환하면 컨텍스트 비용과 데이터 노출이 커진다. 페이지네이션, 필드 선택, 요약과 상세 조회 도구를 나눈다.

annotation은 보안 정책의 근거가 아니다

2025-11-25 스키마에는 readOnly, destructive, idempotent 같은 도구 annotation 힌트가 있지만, 공식 스키마는 신뢰되지 않은 서버의 힌트를 근거로 의사결정하지 말라고 명시한다. 기업 카탈로그의 검토된 정책이 기준이어야 한다.

인증과 권한: 사용자 신원을 끝까지 보존하되 토큰은 분리한다

원격 HTTP MCP에서 인증을 지원할 때는 MCP 2025-11-25 Authorization 명세를 기준으로 구현 상태를 확인한다. 핵심 흐름은 다음과 같다.

사용자가 기업 IdP를 통해 호스트에 로그인한다.
MCP 클라이언트는 특정 MCP 서버를 resource로 지정해 해당 서버용 토큰을 얻는다.
MCP 서버는 서명, 발급자, 만료뿐 아니라 토큰 audience와 scope를 검증한다.
서버는 호출 도구와 인자에 대해 사용자·테넌트 권한을 다시 판단한다.
하위 API를 호출할 때는 그 API용 별도 토큰 또는 안전한 위임 교환을 사용한다.

MCP Security Best Practices는 클라이언트가 준 토큰을 검증 없이 하위 API로 전달하는 token passthrough를 금지된 안티패턴으로 설명한다. 토큰의 대상 서비스가 섞이면 권한 경계, 감사 추적과 침해 범위가 무너질 수 있다.

사람 대신 백그라운드 작업이 실행되는 경우에도 “누가 시작했는가”와 “어떤 서비스 권한으로 실행되는가”를 분리해 기록한다. 사용자 위임 토큰의 만료 후 재개 정책을 정하고, 서비스 계정 하나에 전사 관리자 권한을 몰아주지 않는다.

MCP Enterprise-Managed Authorization 확장은 기업 IdP에서 MCP 서버 접근 정책을 중앙 관리하는 방식을 제공한다. 다만 확장은 선택 사항이고 문서도 클라이언트 지원이 달라질 수 있다고 명시하므로, 도입 전 사용하는 호스트·서버의 지원 행렬을 확인해야 한다.

보안 경계에서 반드시 확인할 것

도구 결과와 설명도 신뢰되지 않은 입력이다

악성 문서나 서버의 도구 설명이 모델에게 다른 도구 호출 또는 데이터 반출을 지시할 수 있다. 도구 출력은 데이터로 표시하고 시스템 정책처럼 취급하지 않는다. 결과 크기, 콘텐츠 유형, 링크, 민감정보를 검사하고 다음 도구 호출의 권한을 별도 평가한다.

최소 기능·최소 권한·최소 자율성을 함께 적용한다

OWASP Top 10 for Agentic Applications 2026은 목표 탈취, 도구 오용, 신원·권한 남용, 공급망, 메모리 오염 같은 위험을 다룬다. MCP 서버를 연결할 때는 필요한 도구만 노출하고, 각 도구 권한과 에이전트의 자동 실행 범위를 함께 줄인다.

로컬 서버는 설치 패키지가 아니라 실행 코드다

stdio 방식의 로컬 MCP 서버는 호스트 프로세스의 파일·네트워크 권한을 물려받을 수 있다. 출처와 서명을 검증하고 버전을 고정하며, 샌드박스에서 필요한 디렉터리·네트워크만 허용한다. 설치 명령이나 패키지 이름을 신뢰만으로 자동 실행하지 않는다.

원격 연결은 SSRF와 egress를 통제한다

승인되지 않은 서버 URL, OAuth 메타데이터 URL과 리디렉션을 따라 내부 네트워크나 클라우드 메타데이터에 접근하지 않도록 URL·DNS·IP를 검증한다. 서버 측 MCP 클라이언트에는 egress proxy와 목적지 allowlist를 고려한다. 자세한 공격과 완화책은 MCP Security Best Practices에 정리되어 있다.

단계별 도입 순서

1단계: 재사용 가치가 높은 읽기 업무 하나를 고른다

여러 AI 호스트에서 공통으로 필요한 문서 검색이나 티켓 조회처럼 부작용이 없는 도구부터 시작한다. 기존 직접 API 방식과 품질·지연·운영 비용을 비교한다.

2단계: 기존 API 위에 얇은 서버를 만든다

업무 로직을 MCP 서버로 복제하지 않는다. 입력을 검증하고 기존 API를 호출한 뒤 결과를 모델 친화적으로 줄이는 어댑터 역할에 집중한다.

3단계: 카탈로그·allowlist·버전 정책을 만든다

서버와 도구 소유자, 데이터 등급, 지원 버전, scope, 장애 연락처를 등록한다. 스키마 변경은 새 버전과 호환성 기간을 두고, 호스트별 계약 테스트를 자동화한다.

4단계: 사용자 위임 인증과 테넌트 격리를 검증한다

정상 사용자뿐 아니라 권한 없음, 다른 테넌트, 만료·잘못된 audience 토큰, 비활성 계정, 퇴사자 접근을 테스트한다.

5단계: 쓰기 도구를 별도 이름과 승인 정책으로 추가한다

읽기 도구를 쓰기 도구로 확장하지 말고 독립 도구로 만든다. 실행 전 미리 보기와 Human-in-the-loop 승인, 멱등성, 되돌리기와 결과 확인을 붙인다.

6단계: 관측성과 장애 격리를 운영한다

호스트 trace_id, MCP 요청 ID, 하위 API 요청 ID를 연결한다. list_tools 실패, 인증 오류, 정책 거부, 도구 시간 초과, 모델 선택 오류, 하위 API 오류를 구분한다. 서버 하나의 장애가 모든 에이전트를 멈추지 않도록 timeout, circuit breaker와 대체 사용자 경로를 둔다.

사용자 경험·실패 시나리오

실패 1: 연결했더니 사용자가 알지 못한 도구가 자동 실행된다

서버의 전체 도구 목록을 무조건 모델에 노출하지 않는다. 사용자가 현재 대화에서 허용된 연결과 데이터 범위를 볼 수 있게 하고, 도구 필터를 사용자·업무별로 적용한다.

실패 2: 승인 화면에 서버 이름만 보인다

“CRM MCP 호출 승인”으로는 판단할 수 없다. “고객 A의 연락처를 변경”처럼 실제 대상, 변경 전후 값, 외부 영향과 되돌리기 가능성을 보여준다. 승인 설계는 프로토콜이 아니라 호스트 제품의 책임이다.

실패 3: 권한 오류를 모델이 사실 없음으로 설명한다

403 권한 부족, 404 데이터 없음, timeout을 서로 다른 구조화 오류로 반환한다. 모델이 “자료가 없습니다”라고 잘못 단정하지 않도록 사용자에게 권한 요청, 다시 시도, 관리자 문의 등 가능한 복구 경로를 제시한다.

실패 4: 도구가 바뀌어 어제 되던 요청이 실패한다

도구 목록과 스키마를 캐시할 때 변경 알림과 TTL을 설계하고, 계약 테스트와 단계적 배포를 운영한다. 삭제·필수 필드 변경은 호환 기간과 마이그레이션 안내 없이 배포하지 않는다.

실패 5: 긴 작업이 시간 초과 후 중복 실행된다

호스트 timeout과 업무 완료는 다를 수 있다. 작업 ID, 상태 조회, 취소와 멱등성 키를 제공한다. 2025-11-25 Tasks를 사용할 때도 상대방 capability와 실험 상태를 확인하고, 미지원 클라이언트에는 기존 비동기 작업 API를 노출한다.

실패 6: 서버가 너무 많아 모델이 잘못 고른다

카테고리·사용자 역할·현재 업무로 서버와 도구를 사전 필터링하고, 필요할 때만 도구를 로드한다. 이름과 설명의 중복을 줄이고 오선택률을 평가한다. 서버 수가 많다는 이유만으로 멀티에이전트로 전환하지 않는다.

실무 체크리스트

자주 묻는 질문

Q1. MCP를 도입하면 기존 REST·GraphQL API를 없애도 되는가?

아니다. MCP 서버는 일반적으로 기존 API를 AI 호스트에 적합한 도구·리소스로 노출하는 계층이다. 모바일, 웹, 배치와 기존 서비스는 계속 업무 API를 사용하고, MCP 서버도 그 API의 검증과 권한을 재사용하는 편이 일관적이다.

Q2. MCP 서버에 연결하면 모델이 모든 도구를 자동으로 안전하게 선택하는가?

아니다. 프로토콜은 도구 발견과 호출 형식을 제공하지만 업무 적합성, 권한, 위험, 승인과 결과 검증은 애플리케이션과 서버가 설계해야 한다. 사용자와 현재 업무에 필요한 도구만 노출하고 잘못된 선택과 금지 행동을 평가해야 한다.

Q3. 사내 시스템이면 인증 없이 내부망 MCP 서버를 운영해도 되는가?

권장할 수 없다. 내부망에도 침해된 단말, 잘못 구성된 서비스, 다른 테넌트와 과도한 서비스 권한이 존재할 수 있다. 사용자 또는 서비스 신원, 최소 scope, audience 검증, 네트워크 제한과 감사 로그를 적용해야 한다. stdio 로컬 서버도 실행 프로세스 권한과 샌드박스가 필요하다.

근거 자료

Model Context Protocol, Architecture overview — 호스트·클라이언트·서버 역할과 tools, resources, prompts의 기본 구조.
Model Context Protocol 2025-11-25, Tools — 도구 발견·호출, 입력 스키마, 사용자 상호작용과 안전 지침.
Model Context Protocol 2025-11-25, Authorization — OAuth 기반 원격 인증, resource 지정, 토큰 대상 검증 요구사항.
Model Context Protocol, Security Best Practices — confused deputy, token passthrough, SSRF, 로컬 서버와 세션 위험 및 완화책.
Model Context Protocol, Enterprise-Managed Authorization — 기업 IdP 중심 접근 정책 확장과 선택적 클라이언트 지원 주의사항.
OpenAI Agents SDK, Model context protocol — MCP 서버 연결, 도구 필터, 승인, 캐싱, 추적과 전송 방식의 실제 구현 문서.
OWASP Gen AI Security Project, Top 10 for Agentic Applications 2026 — 도구 오용, 신원·권한 남용, 공급망과 메모리 오염을 포함한 에이전트 보안 위험 체계.

KMWorks AI Tech Lab은 기업 환경에서 검증·운영할 수 있는 AI 시스템 설계 기준을 공유합니다.