MCP 대 함수 호출 대 ChatGPT 플러그인: 2026년에 API 팀이 실제로 필요로 하는 것

팀들이 AI 에이전트에 API를 연결하기 시작하면서, 세 가지 용어가 함께 등장하여 혼용되고 있습니다. 바로 함수 호출(function calling), ChatGPT 플러그인(ChatGPT plugins), 그리고 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)입니다. 이들은 스택의 서로 다른 계층이며, 이들을 대안으로 취급하면 두 번째 에이전트 클라이언트와 접촉했을 때 살아남지 못하는 아키텍처를 초래합니다. 여기서는 각 요소가 무엇을 실제로 해결하는지, 그리고 OpenAPI 문서가 어떻게 모든 것의 출처가 되는지에 대한 계층적 분석을 제공합니다.

함수 호출은 모델 기능이다

함수 호출은 채팅 완료(chat completion)의 기능입니다. 사용자는 모델에게 JSON Schema 입력이 가능한 사용 가능한 함수 목록을 전송하고, 모델은 구조화된 호출을 내보내기로 결정하며, 애플리케이션이 이를 실행하고 결과를 다시 피드백합니다. 이 계약은 프롬프트 시간 요청에 존재하며, 도구를 발견하는 네트워크 프로토콜도, 표준 전송 방식도, 영속성도 없습니다. 즉, 애플리케이션 개발자인 사용자가 다음을 소유합니다:

• 도구 카탈로그와 그것이 조립되는 방식.
• 기반 API에 대한 인증.
• 위험한 동작에 대한 실행, 재시도(retries), 시간 초과(timeouts) 및 확인.
• 결과를 대화로 다시 매핑하는 작업.

따라서 함수 호출은 통합 표준이 아니라 에이전트 런타임 내부의 원시 기능입니다. 동일한 모델과 API를 사용하는 두 애플리케이션이라도 여전히 서로 다른 도구 통합을 작성합니다. 이러한 중복성이 바로 아래에서 제거하려고 시도하는 문제입니다.

ChatGPT 플러그인은 배포 실험이었다

플러그인 시스템(2023년에 발표되었으나, 이후 GPTs와 더 광범위한 도구 생태계에 밀려 제품 라인으로 폐기됨)은 ChatGPT가 ai-plugin.json 매니페스트를 통해 OpenAPI 문서를 가리키는 API를 발견할 수 있는 방법을 정의했습니다. 이는 모델이 붙여넣은 문서가 아닌 계약(contract)으로부터 HTTP 작업을 발견해야 한다는 아이디어를 검증했다는 점에서 역사적으로 중요했지만, 하나의 호스트, 하나의 제품의 리뷰 및 배포 모델, 그리고 하나의 대화 표면과 연결되어 있었습니다. 교훈은 살아남았지만, 크로스 벤더 표준으로서의 플러그인 프로토콜은 그렇지 못했습니다. 만약 2026년의 통합 가이드에서 플러그인을 참조하는 것을 본다면, 그것은 레거시 경로를 설명하고 있는 것입니다.

MCP는 클라이언트-서버 프로토콜입니다

Model Context Protocol(MCP)은 함수 호출 계층이 수동으로 구현하던 대화를 표준화합니다. MCP 서버는 정의된 전송 방식(로컬 프로세스를 위한 stdio, 원격 서비스를 위한 HTTP(스트리밍 가능))을 통해 도구(JSON Schema 입력이 가능한 호출 함수), 리소스(읽기 가능한 컨텍스트), 프롬프트를 노출합니다. MCP 클라이언트(IDE 에이전트, 채팅 앱, CLI)는 연결하여 도구를 나열하고 이를 호출하며, 서버는 사용자의 API를 대상으로 실행하고 결과를 반환합니다.

업무 분담이 중요한 부분입니다:

세 가지 비교 방법

OpenAPI 문서는 이미 호출 가능한 작업(callable operations)의 유형화된 입력 및 출력 카탈로그이며, 이는 MCP 도구 목록과 거의 동일한 형태입니다. 매핑은 기계적입니다: 작업(operation)을 도구(tool)로, 매개변수와 요청 본문(request body)을 inputSchema로, 보안 스키마를 런타임 주입 자격 증명(runtime-injected credentials)으로, 응답을 도구 결과(tool results)로 변환합니다. 사양(spec)으로부터 MCP 서버를 생성한다는 것은 다음을 의미합니다:

• 단일 진실 공급원(One source of truth). 문서, 목업(mocks), SDK, 에이전트 도구가 네 개의 수동으로 유지 관리되는 설명 대신 동일한 문서에서 파생됩니다.
• 사전 검증(Pre-flight validation). 서버는 HTTP 호출 전에 스키마를 위반하는 인수를 거부하여, 모델의 실수 유형을 즉각적이고 수정 가능한 도구 오류로 바꿉니다.
• 일관된 인증(Consistent auth). 토큰은 범위별 청중(scopes per audience)과 함께 서버 구성에 저장되며, 프롬프트는 자격 증명을 볼 수 없습니다.
• 스트리밍 포함. 이벤트 계약(event contracts)이 문서화된 SSE 작업은 스트림을 열고 수집된 이벤트를 반환하는 도구가 되어, 대기 상태로 멈추지 않습니다.

대안인 사양의 내용을 반복하는 MCP 도구 래퍼를 직접 작성하는 것은 프로토콜이 제거하려 했던 정확한 중복성을 재현하며, 첫 번째 스키마 변경에서부터 구식이 됩니다.

여전히 사용자 정의 도구를 작성해야 하는 경우

모든 에이전트 기능이 API 작업인 것은 아니며, 모든 것을 OpenAPI가 생성하는 표면(surface)을 통해 강제하는 것이 또 다른 실수입니다. 사용자 정의 MCP 도구는 복합적이고 도메인 수준의 작업(

1. 실제 설명(description), 열거형(enums), 예시를 포함한 정확하고 최신 OpenAPI 3.2 문서를 유지하세요. 이 문서는 이제 단순히 문서를 읽는 사람뿐만 아니라 액션을 선택하는 기계에 의해 소비됩니다.
2. 이를 MCP 엔드포인트로 제공하세요: 개발자를 위해 로컬에서(사양 파일에 대한 stdio 방식) 제공하고, 파트너 및 내부 에이전트를 위해서는 범위가 지정된 토큰과 함께 호스팅합니다.
3. 도구 설명을 API 설계처럼 취급하세요: 동사 우선 이름(verb-first names), 언제 호출해야 하는지 상태를 명시하고, 기계가 읽을 수 있는 형식으로 오류를 문서화하세요(problem+json의 type 값은 에이전트가 스스로 수정하도록 합니다).
4. 자격 증명과 파괴적 액션 정책은 서버에 유지하고, 프롬프트에는 절대 넣지 마세요.
5. 새로운 플러그인 형태의 벤더 종속성은 무시하세요. MCP의 다중 클라이언트 지원이 핵심입니다.

Powerduck은 설계(design), 목업(mocks), 테스트에 사용된 동일한 로컬 사양으로부터 MCP 서버를 생성하고, 하나의 개정판에서 문서와 함께 호스팅되는 토큰 범위가 지정된 MCP 엔드포인트를 게시합니다. 단계별 변환 워크스루는 작업(operation) 대 도구 매핑을 자세히 다루며, 데모에서는 제공(serve) 액션을 보여줍니다.

다음으로 읽어볼 것: MCP를 통해 내부 API에 Cursor 및 Claude Code 연결하기는 실습 설정이며, 당신의 API가 에이전트가 필요로 하는 도구를 이미 설명하고 있다는 발견(discovery) 주장을 심도 있게 다룹니다.