MCP vs Function Calling: AI Agent 도구 호출은 무엇이 다를까? JSON Schema, API와 Tool Calling 전면 비교

MCP의 2026년 7월 28일 공식 규격은 요청 처리 방식과 인증 구조까지 확장했지만, MCP가 모델의 함수 호출 기능을 대신한다는 뜻은 아닙니다. 공식 규격 변경 안내에 따르면 이번 버전도 핵심 역할은 애플리케이션과 도구 사이의 표준 연결입니다. 따라서 MCP vs Function Calling의 결론은 단순한 승자 선택이 아니라 계층 조합입니다. Function Calling은 모델이 호출할 도구와 인자를 표현하고, MCP는 애플리케이션이 여러 도구를 발견하고 연결하는 방식을 표준화합니다. 도구가 적은 단일 애플리케이션은 Function Calling만으로 시작하고, 여러 Agent나 클라이언트가 같은 도구를 공유할 때 MCP를 추가하는 편이 안전합니다.

이 글은 세 부류의 개발자를 대상으로 합니다.

단일 애플리케이션을 만드는 개발자: 과도한 구조 설계를 피하려는 경우입니다.
여러 모델을 운영하는 플랫폼 팀: 모델별 호출 형식과 Schema 차이를 흡수해야 하는 경우입니다.
MCP 전환을 맡은 아키텍처 담당자: 기존 Function Calling 코드를 어디까지 유지할지 결정해야 하는 경우입니다.

MCP vs Function Calling은 서로 다른 계층에서 작동합니다

Function Calling의 기본 흐름은 비교적 단순합니다. 애플리케이션이 모델에게 함수 이름과 매개변수 Schema를 전달합니다. 모델은 실행 결과를 직접 만들지 않고, 호출할 함수와 인자를 구조화된 형태로 반환합니다. 실제 API 실행과 결과 검증은 애플리케이션의 책임입니다. Google의 Function Calling 문서는 함수 선언, 모델 요청, 애플리케이션 실행, 실행 결과 재전달의 흐름을 명시합니다. OpenAI의 함수 호출 안내는 strict: true를 사용할 때 지원되는 Schema 조건 안에서 생성 인자가 제공된 JSON Schema와 일치하도록 보장한다고 설명합니다.

MCP는 이보다 바깥쪽의 연결 계층입니다. 공식 구조는 호스트, 클라이언트, 서버로 구성됩니다. 호스트가 연결 수명과 권한을 관리하고, 클라이언트가 특정 MCP Server와 연결하며, 서버가 도구와 리소스와 프롬프트를 노출합니다. MCP 아키텍처 문서에 따르면 서버는 로컬 프로세스일 수도 있고 원격 서비스일 수도 있습니다.

둘의 관계를 실행 순서로 정리하면 다음과 같습니다.

MCP Client가 Server에 연결합니다.
Server가 사용할 수 있는 도구와 각 도구의 Schema를 제공합니다.
애플리케이션이 이 목록을 모델이 이해할 수 있는 Function Calling 형식으로 변환합니다.
모델이 Tool Calling을 결정하고 도구 이름과 인자를 반환합니다.
애플리케이션 또는 MCP Client가 해당 도구를 실행합니다.
실행 결과가 다시 모델의 다음 입력으로 전달됩니다.

즉, Function Calling은 모델과 애플리케이션 사이의 호출 표현이고, MCP는 애플리케이션과 도구 제공자 사이의 연결 표준입니다. MCP가 모델 능력이거나 자체적으로 업무 API를 실행하는 엔진은 아닙니다.

한 개 Agent라면 MCP가 필요하지 않은 경우가 많습니다

도구가 한정된 단일 Agent라면 MCP를 먼저 도입할 이유가 약합니다. 예를 들어 고객 조회, 주문 상태 확인, 알림 발송처럼 애플리케이션 안에서 관리하는 함수가 소수라면 다음 구조로 충분합니다.

모델 요청에 함수 선언을 직접 포함합니다.
애플리케이션에서 인자 Schema를 검증합니다.
허용된 함수 이름만 내부 라우터에 연결합니다.
업무 API의 인증과 최종 권한 검사를 실행합니다.
결과와 오류를 모델에 다시 전달합니다.

이 방식은 연결 계층이 짧고 장애 지점이 적습니다. MCP Server를 별도로 운영하지 않아도 되므로 배포, 로그 수집, 버전 호환, 연결 인증을 추가로 관리할 필요가 없습니다. 특히 한 Agent만 사용하는 도구를 표준화한다는 이유로 MCP를 넣으면, 실제 재사용 가치는 작고 운영 비용만 늘어날 수 있습니다.

다만 처음부터 내부 도구 인터페이스를 없애면 안 됩니다. 함수 이름, 입력 Schema, 반환 오류 형식을 애플리케이션 코드 곳곳에 직접 흩뿌리지 말고 내부 호출 이벤트로 묶어야 합니다. 예를 들면 다음 필드를 고정합니다.

tool_name
schema_version
arguments
request_id
actor_id
approval_state
result 또는 error

이 내부 형식은 나중에 모델을 바꾸거나 MCP Server를 추가할 때 완충 지점이 됩니다. Function Calling 형식은 모델 공급자마다 필드 이름과 메시지 흐름이 다를 수 있습니다. Anthropic의 도구 사용 API도 tool_use, tool_result, input_schema를 별도 메시지 블록으로 처리합니다. 공식 도구 사용 구현 문서에서 확인할 수 있듯이, 같은 도구라도 모델 측 이벤트 형식은 직접 통합이 필요합니다.

MCP는 Function Calling을 대체하지 않고 연결 범위를 넓힙니다

MCP가 유리해지는 시점은 도구의 기능 수보다 도구를 사용하는 주체의 수가 늘어날 때입니다. 하나의 업무 API를 여러 Agent, 코드 편집기, 데스크톱 클라이언트, 자동화 작업이 함께 사용한다면 각 클라이언트에 연결 코드를 반복해서 작성하는 비용이 커집니다.

MCP Server는 도구를 한 번 정의하고, 여러 MCP 호스트가 같은 방식으로 발견하도록 만들 수 있습니다. MCP 공식 문서는 도구를 모델이 사용할 수 있는 실행 가능한 기능으로 정의하며, 서버가 데이터 조회나 API 요청 같은 동작을 제공할 수 있다고 설명합니다. 서버 기능 개요에는 도구뿐 아니라 리소스와 프롬프트의 역할도 구분되어 있습니다.

그러나 MCP를 추가하면 해결해야 할 문제가 생깁니다.

Server별 권한 범위와 사용자 식별을 관리해야 합니다.
도구 목록과 Schema의 버전을 호환시켜야 합니다.
원격 연결에서는 인증, 네트워크 장애, 재시도, 감사 로그를 운영해야 합니다.
같은 이름의 도구가 여러 Server에서 노출될 때 충돌을 막아야 합니다.
서버가 반환하는 오류를 모델이 오해하지 않도록 오류 유형을 표준화해야 합니다.

MCP는 연결 방식의 반복을 줄이지만, 모델 공급자별 Function Calling 차이까지 없애지는 않습니다. 여러 모델을 지원하는 팀이라면 MCP 앞뒤에 내부 적응층을 두는 편이 좋습니다. MCP에서 받은 도구 목록을 내부 Schema로 정규화하고, 모델별 요청 형식으로 변환한 뒤, 모델의 응답을 다시 내부 호출 이벤트로 되돌리는 구조입니다.

주의: JSON Schema가 문법적으로 맞아도 사용자가 해당 작업을 승인했다는 뜻은 아닙니다. Schema 검증은 입력 형태를 확인할 뿐이며, 결제·삭제·배포 같은 작업에는 별도의 승인과 업무 권한 검사가 필요합니다.

원격 도구와 고위험 작업은 연결과 실행을 분리해야 합니다

MCP가 직접 업무 API를 실행한다고 이해하면 설계가 위험해집니다. 실제 실행 주체는 MCP Server에 구현된 코드입니다. Server가 내부 API를 호출할 수는 있지만, API의 인증·인가·멱등성·트랜잭션 검사는 업무 시스템이 최종적으로 담당해야 합니다.

원격 MCP Server를 운영할 때는 다음 순서로 확인하는 것이 좋습니다.

첫 번째 단계: 도구 경계를 정의합니다

읽기 도구와 쓰기 도구를 분리합니다. get_invoice와 cancel_invoice를 하나의 범용 함수로 합치면 모델의 선택 범위와 권한 검사가 모호해집니다.

두 번째 단계: 내부 Schema를 고정합니다

모델 공급자별 형식보다 내부 이벤트를 기준으로 삼습니다. 각 호출에 Schema 버전과 요청 식별자를 넣어야 이전 버전의 Agent가 잘못된 인자를 보내도 추적할 수 있습니다.

세 번째 단계: 실행 전 검증을 추가합니다

필수 필드, 열거값, 문자열 길이, 숫자 범위를 검증합니다. JSON Schema 검증이 통과한 뒤에도 계정 소유자, 조직, 역할, 리소스 상태를 업무 API에서 다시 확인해야 합니다.

네 번째 단계: 승인 지점을 둡니다

읽기 작업은 자동 실행할 수 있지만, 삭제·송금·배포·권한 변경은 사용자 확인이나 운영자 승인을 거치게 합니다. MCP의 도구 모델도 도구 호출에 대한 사람의 거부 권한을 두는 방향을 권고합니다. MCP 도구 안전 지침은 도구 호출 전 사람의 개입을 둘 수 있어야 한다고 설명합니다.

다섯 번째 단계: 오류 경로를 별도로 시험합니다

시간 초과, 인증 만료, 중복 요청, 부분 성공, 잘못된 반환 Schema를 각각 시험합니다. 모델에게 자연어 오류만 반환하면 재시도 여부를 판단하기 어렵습니다. AUTH_REQUIRED, RATE_LIMITED, CONFLICT, APPROVAL_REQUIRED처럼 애플리케이션이 처리할 수 있는 오류 코드를 함께 반환해야 합니다.

여섯 번째 단계: 원격 배포 조건을 확인합니다

원격 MCP는 인증서, 비밀값 저장소, 네트워크 정책, 접근 로그, 호출량 제한을 갖춰야 합니다. macOS 전용 빌드나 Xcode, 시뮬레이터, 서명 도구처럼 운영체제 자원이 필요한 도구는 관리되는 원격 Mac에 배치할 수 있지만, 이것은 MCP의 필수 조건이 아니라 실행 환경의 선택입니다. 단기 테스트나 격리된 개발 환경이라면 클라우드 맥 대여 방식을 먼저 검토할 수 있습니다.

도구 규모보다 클라이언트 수와 거버넌스로 경로를 선택합니다

아래 평가는 기능의 우열이 아니라 아키텍처 선택을 위한 편집 판단 점수입니다. 점수는 높을수록 해당 조건에 유리합니다. MCP의 공식 구조와 각 모델의 도구 호출 문서를 기준으로 구성했으며, 실제 호환성은 사용하는 클라이언트와 API 버전을 다시 확인해야 합니다. MCP 기본 메시지는 JSON-RPC 2.0 형식을 사용합니다. 기본 프로토콜 문서에도 이 조건이 명시되어 있습니다.

선택 경로	Function Calling 역할	MCP 역할	적합한 상황	운영 복잡도	재사용성	편집 판단
Function Calling만 사용	모델의 도구 선택과 인자 생성	없음	단일 Agent, 내부 도구, 짧은 연결 경로	낮음	낮음	5점
Function Calling + 내부 적응층	모델별 형식을 내부 이벤트로 통일	없음	여러 모델, 공통 권한과 로그가 필요한 플랫폼	중간	중간	5점
Function Calling + MCP	모델 호출 형식 담당	도구 발견, 연결, Server 관리	여러 Agent와 클라이언트가 같은 도구를 공유	높음	높음	5점

점수는 어느 경로가 항상 더 좋다는 뜻이 아닙니다. 단일 Agent인데 MCP를 선택하면 재사용성을 얻지 못한 채 운영 복잡도만 부담할 수 있습니다. 반대로 여러 클라이언트가 같은 macOS 도구를 사용하고, 도구 권한과 감사 로그를 중앙에서 관리해야 한다면 Function Calling만 고집하는 편이 반복 구현을 키울 수 있습니다.

마이그레이션은 기존 함수부터 내부 호출 이벤트로 감쌉니다

기존 Function Calling 코드를 MCP로 옮길 때 모든 함수를 한 번에 Server로 옮기면 장애 원인을 분리하기 어렵습니다. 다음 순서가 현실적입니다.

현재 함수 목록과 실제 API 권한을 분리해서 기록합니다.
함수별 입력과 반환값을 JSON Schema로 고정합니다.
모델별 응답을 내부 호출 이벤트로 변환합니다.
기존 실행기를 그대로 둔 채 MCP Server가 같은 내부 실행기를 호출하게 합니다.
동일한 도구를 직접 호출하는 경로와 MCP 경로에서 비교 테스트합니다.
인증 실패와 사용자 승인 누락을 양쪽 경로에서 같은 오류 코드로 반환합니다.
로그와 추적 ID가 유지되는 것을 확인한 뒤 클라이언트 하나씩 전환합니다.

이 방식이면 MCP 도입이 실패해도 직접 Function Calling 경로로 되돌릴 수 있습니다. 반대로 MCP Server가 업무 로직과 권한을 모두 떠안으면, 프로토콜 변경과 업무 규칙 변경이 한 배포에 묶입니다.

현재 팀이 로컬 개발 도구와 원격 실행 환경을 함께 관리한다면 Mac 지원 문서에서 실행 환경의 접근 방식과 책임 범위를 먼저 분리하는 것이 좋습니다. 원격 Mac을 상시 운영하는 구조라면 맥 서버와 VPS 선택 기준도 비용보다 연결 안정성과 회수 가능한 환경이라는 관점에서 검토해야 합니다.

결국 직접 Function Calling은 구현이 빠르지만 클라이언트가 늘수록 연결 코드와 권한 코드가 반복됩니다. 반대로 MCP는 도구 공유와 발견성을 높이지만 Server 운영, 인증, 버전 호환이라는 비용을 추가합니다. 장기적으로 안정적인 업무 시스템이라면 둘 중 하나를 지우기보다 모델 호출과 도구 연결을 분리하는 편이 낫습니다. 특히 공유해야 할 도구가 macOS 전용이고 원격 MCP Server를 일정 기간만 운영해야 한다면, 물리 장비를 직접 구매하는 방식보다 격리하고 회수할 수 있는 원격 Mac 환경이 더 맞을 수 있습니다. 이 경우 Zilmac의 클라우드 맥 대여 환경을 테스트용 또는 임시 운영용 후보로 비교해 볼 수 있습니다. 단, 장기간 고정 부하를 계속 처리하거나 특정 물리 포트와 로컬 장비가 필요한 팀이라면 직접 Mac을 보유하는 편이 더 적합합니다.