MCP와 API 차이: 우리 제품에는 무엇을 제공해야 할까

MCP는 API를 대체하지 않습니다. AI 클라이언트가 서비스의 툴을 탐색하고 호출할 수 있도록 표준화된 방식을 제공합니다. 앱과 AI 어시스턴트 양쪽에 서비스를 제공하는 제품이라면, MCP와 API를 비교할 때 핵심은 하나의 비즈니스 규칙을 공유하는 2개의 인터페이스를 어떻게 운영할지입니다. 애플리케이션 연동에는 기존 API를 유지하고, 고객이 이미 사용하는 AI 클라이언트에서 특정 업무를 처리할 필요가 있을 때 MCP를 추가하면 됩니다.

MCP란 무엇이며, API와는 어떤 차이가 있나요?

MCP와 API의 비교는 범용 소프트웨어 인터페이스와 AI 연동을 위한 특정 프로토콜의 비교입니다. API(Application Programming Interface)는 소프트웨어가 데이터나 작업을 요청하는 방식을 정의합니다. REST(Representational State Transfer)는 HTTP API에 널리 쓰이는 아키텍처 스타일입니다. MCP(Model Context Protocol)는 호환되는 AI 애플리케이션이 외부 기능에 접근하는 방식을 표준화합니다.

제품을 작업장에 비유해 보겠습니다. API는 이용 절차가 문서로 정리된 업무용 출입구입니다. MCP 서버는 여기에 안내 데스크를 더합니다. AI 클라이언트가 이미 이해하는 형식으로 어떤 작업을 요청할 수 있는지 설명해 주는 곳입니다. 실제 작업을 수행하는 사람과 그들이 따르는 규칙은 여전히 중요합니다.

개발자에게는 기존 기능을 감싸는 어댑터가 생기는 셈입니다. 제품 책임자에게는 고객이 제품을 이용할 접점이 하나 더 생깁니다. 운영자에게는 접근과 장애를 책임지고 관리해야 할 인터페이스가 추가됩니다.

MCP는 HTTP API를 호출하지 않고 로컬 기능을 직접 제공할 수도 있습니다. 기존 API를 감싸는 방식은 유용한 선택지이지 필수 조건은 아닙니다. MCP 아키텍처 문서는 AI 애플리케이션과 기능을 제공하는 서버를 구분합니다. 프로토콜의 기본 개념은 MCP란 무엇인가에서 확인할 수 있습니다.

MCP와 REST API의 차이 한눈에 보기

REST는 애플리케이션 간 직접 연동에 적합하고, MCP는 호환되는 AI 클라이언트가 사용할 수 있는 공통 툴 인터페이스를 더합니다. 어느 쪽을 선택하든 권한을 확인하고 비즈니스 로직이 올바르게 동작하도록 할 책임은 서비스에 있습니다.

이 구분은 REST API 설계 지침, MCP 전송 방식, MCP 권한 부여 명세를 따릅니다. 비즈니스 규칙을 공유하라는 마지막 행의 내용은 아키텍처 설계 권고입니다.

API도 이미 기계가 읽을 수 있는 스키마를 제공할 수 있습니다. OpenAPI Specification은 사람과 컴퓨터 모두를 위한 HTTP 인터페이스 명세입니다. MCP의 차별점은 매개변수를 설명하는 독점적인 능력이 아니라, AI 연동에 공통으로 쓰는 런타임 계약에 있습니다.

기존 API에 MCP를 더하면 무엇이 달라지나요?

MCP를 사용하면 호환되는 여러 호스트에서 같은 툴 인터페이스를 재사용할 수 있습니다. 호스트는 모델과 연결을 조율하는 AI 애플리케이션입니다. 서비스 개발자가 서버의 기능을 구현하면, 호스트는 자신의 MCP 클라이언트로 연결합니다.

실제로 추가되는 기능은 다음과 같습니다.

• 툴 탐색: tools/list로 연결된 클라이언트에 사용 가능한 작업을 알려 줍니다.
• 표준 툴 정의: 이름, 설명, 입력용 JSON Schema를 제공합니다. JSON Schema는 필요한 필드와 각 필드의 타입을 정의합니다. 툴은 출력 스키마도 선언할 수 있습니다.
• 공통 호출 방식: tools/call로 툴 이름과 인자를 전달하고, MCP 메시지 형식으로 결과를 반환합니다.

이 작업들은 툴 명세에 정의되어 있습니다. 예를 들어 티켓 서비스는 create_ticket을 툴 목록에 등록하고, 언제 사용하는지와 어떤 필드가 필요한지 설명할 수 있습니다. 그러면 호스트 자체에 티켓 서비스 전용 플러그인을 구현하지 않아도 클라이언트가 이 정의를 사용할 수 있습니다.

효용은 누가 호출하느냐에 따라 달라집니다. 자체 백엔드만 호출한다면 이미 연동 양쪽을 모두 통제하고 있을 수 있습니다. 반면 고객이 서로 다른 지원 대상 AI 앱에서 같은 업무를 처리하고 싶어 한다면 공통 프로토콜의 가치가 커집니다.

MCP 서버와 API를 어디에 배포할지는 별개의 문제입니다

MCP를 추가한다고 반드시 서비스를 하나 더 배포해야 하는 것은 아닙니다. API와 함께 MCP 핸들러를 둘 수도 있고, API를 호출하는 어댑터를 별도로 배포할 수도 있으며, 기존 서비스 계층을 직접 노출할 수도 있습니다. 격리 수준, 담당 조직, 릴리스 요구 사항에 맞춰 선택하면 됩니다.

stdio에서는 클라이언트가 프로세스를 실행하고 표준 입력과 출력으로 메시지를 주고받습니다. Streamable HTTP에서는 HTTP로 MCP 엔드포인트에 접속합니다. 이들은 표준 전송 방식이며, 네트워크 연결을 사용한다면 실제 클라이언트가 해당 주소에 접근할 수 있어야 합니다.

그림은 기존 API를 감싸는 구성을 보여 줍니다. MCP 경로에서도 동일한 권한 확인과 유효성 검사를 유지한다면, 공통 내부 서비스를 직접 호출하는 방식도 유효합니다.

같은 티켓 생성 작업을 API와 MCP로 처리하면 어떻게 될까요?

어느 인터페이스에서 요청하든 생성되는 티켓은 같아야 합니다. 가상의 이슈 관리 서비스에서 고객이 EXAMPLE 프로젝트에 “Login button fails”라는 제목의 티켓을 만들려 한다고 가정하겠습니다. 아래 이름과 필드는 설명을 위한 애플리케이션 계약의 예시이며, 특정 외부 서비스의 API가 아닙니다.

REST API로 요청하는 경우

애플리케이션은 인증된 POST /tickets 요청에 다음 JSON 본문을 담아 보냅니다. {"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}.

API는 호출자의 신원을 확인하고 프로젝트 접근 권한과 제목의 유효성을 검사한 뒤 티켓 생성 서비스를 호출합니다. 서비스는 생성된 티켓의 식별자와 상태를 반환합니다.

여기서 request_key는 애플리케이션이 정의한 멱등성 키입니다. 같은 논리적 요청을 같은 키로 재시도하면 티켓을 하나 더 만드는 대신 원래 결과를 반환해야 합니다. 이는 이 예시에서 선택한 설계이며, REST가 자동으로 제공하는 기능은 아닙니다.

MCP 서버로 요청하는 경우

서버는 create_ticket이라는 툴을 제공하고, 예를 들어 “현재 사용자가 접근할 수 있는 프로젝트에 티켓을 생성합니다”라고 설명합니다. inputSchema는 문자열 필드인 project_key, title, request_key를 필수로 요구합니다.

클라이언트는 툴을 탐색한 뒤 tools/call 요청을 보냅니다. 이때 매개변수는 {"name":"create_ticket","arguments":{"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}}입니다. 이는 호출 매개변수만 나타낸 것이며, 프로토콜 메시지 전체를 보여 주는 것은 아닙니다.

어댑터는 인자를 같은 티켓 서비스에 맞게 변환하거나 기존 POST /tickets 엔드포인트를 호출합니다. 그런 다음 티켓 식별자와 상태를 툴 실행 결과로 반환합니다. MCP가 표준화하는 것은 탐색과 호출 방식입니다. 티켓 생성의 구체적인 의미와 동작은 애플리케이션이 정의합니다.

반드시 함께 적용해야 하는 권한 경계

어댑터가 프로젝트 권한을 우회하는 통로가 되어서는 안 됩니다. 신뢰할 수 있는 인증 컨텍스트에서 호출자의 신원과 소속 조직을 확인한 뒤 프로젝트 접근 권한을 검사해야 합니다. 모델이 전달했다는 이유만으로 조직 식별자를 신뢰해서는 안 됩니다.

동일한 의도의 작업을 재시도할 때는 멱등성 키를 유지해야 합니다. 모델이 서로 다른 키로 요청을 반복하면 자동으로 중복 요청으로 처리되는 것은 아닙니다. 반복된 쓰기 작업을 어떻게 식별하고 검토할지는 애플리케이션에서 정의해야 합니다.

어떤 AI 클라이언트가 MCP 지원을 문서화하고 있나요?

Claude, ChatGPT, Cursor, GitHub Copilot은 모두 MCP 지원을 문서화하고 있지만, 연결 방식은 서로 다릅니다. 아래 내용은 2026년 10월 17일에 각 제품의 공식 온라인 문서를 확인한 결과입니다. 문서상 지원 여부를 확인한 것이며, 모든 서버·기능·프로토콜 버전의 상호운용성을 직접 시험한 결과는 아닙니다.

Claude

Anthropic의 AI 어시스턴트인 Claude는 사용자 지정 원격 MCP 커넥터를 지원합니다. 커넥터 문서에 따르면 연결은 Anthropic의 클라우드 인프라에서 시작됩니다. 따라서 이 방식을 사용하려면 자신의 노트북에서만 접근할 수 있는 엔드포인트로는 부족합니다. 누가 커넥터를 추가할 수 있는지는 조직의 관리 설정에도 영향을 받습니다.

호스팅형 제품이라면 연동을 보장하기 전에 서버 접근 가능 여부와 고객의 인증 흐름을 확인해야 합니다. 데스크톱의 로컬 서버 설정은 별도의 연결 방식입니다.

ChatGPT

OpenAI의 AI 애플리케이션인 ChatGPT는 Plugins를 통해 사용자 지정 MCP 서버를 연결하는 방법을 문서화하고 있습니다. OpenAI 빠른 시작 가이드에서는 HTTPS MCP URL을 추가하고 인증을 설정한 다음, 플러그인을 생성·설치해 채팅에서 호출합니다. 사용자 지정 시각적 인터페이스는 선택 사항입니다.

이 문서의 연결 방식에서는 ChatGPT가 서버에 접근할 수 있어야 합니다. 개발 안내는 서버를 공용 인터넷에 노출하는 방식으로 진행됩니다. 다른 클라이언트 설정에 쓰인 로컬 실행 명령을 그대로 대신 사용할 수는 없습니다.

Cursor

AI 코드 편집기인 Cursor는 stdio, Server-Sent Events(SSE), Streamable HTTP 연결을 문서화하고 있습니다. MCP 문서는 툴 지원, mcp.json을 통한 설정, OAuth가 필요한 서버의 인증을 설명합니다. SSE는 서버가 이벤트를 스트리밍하는 방식입니다.

따라서 로컬 개발 툴과 호스팅형 서비스는 서로 다른 경로로 연결할 수 있습니다. “Cursor에서 동작한다”는 말만으로 호환성 요구 사항을 모두 설명했다고 생각해서는 안 됩니다. 지원되는 전송 방식과 인증 설정에 맞춰 배포해야 합니다.

GitHub Copilot

GitHub의 AI 코딩 어시스턴트인 GitHub Copilot은 여러 제품 환경에서 MCP 지원을 문서화하고 있습니다. 지원 범위 문서는 통합 개발 환경(IDE), 명령줄 인터페이스, Copilot 앱, 클라우드 에이전트와 코드 리뷰를 위한 저장소 설정을 다룹니다. CLI는 로컬 서버와 원격 서버를 지원합니다. 편집기별 지원 범위는 다르며 조직 정책에 따라 접근이 제한될 수 있습니다.

특정 편집기의 Copilot처럼 지원하려는 사용 환경을 명확히 지정해야 합니다. CLI 연결에 성공했다고 해서 고객의 저장소 설정이나 조직 정책이 다른 환경에서도 같은 서버의 사용을 허용한다는 뜻은 아닙니다.

이미 제공되는 연동 사례는 추천 MCP 서버 가이드에서 살펴볼 수 있습니다. 여기서 판단할 문제는 자신의 제품에도 MCP 서버가 필요한지입니다.

MCP와 API, 언제 무엇을 제공해야 할까요?

고객이 이미 사용하는 AI 클라이언트에서 명확한 업무를 처리할 수 있게 해 줄 때 MCP를 제공할 가치가 있습니다. 프로토콜에 대한 관심만으로 지원해야 할 인터페이스를 하나 더 늘리기는 어렵습니다.

다음과 같다면 MCP를 제공할 만합니다.

• 고객이 기존 MCP 호환 AI 앱에서 제품의 데이터를 검색하거나 범위가 정해진 작업을 수행하고 싶어 합니다.
• 여러 호환 호스트에 같은 유용한 기능을 제공해야 합니다.
• 어시스턴트가 대화 맥락에 따라 설명이 명확한 작업 중 하나를 선택하는 방식이 해당 업무에 도움이 됩니다.
• 대상 클라이언트의 전송 방식, 인증, 설치 경로를 지원할 수 있고, 장애와 변경을 책임질 담당자도 정할 수 있습니다.

다음과 같다면 API만 유지하는 편이 적합합니다.

• 호출 주체가 애플리케이션, 예약 작업, 파트너 연동이며 업무 흐름이 이미 정해져 있습니다.
• AI 앱과 그 API 어댑터를 직접 통제하고 있어 외부 호스트와의 호환성이 필요하지 않습니다.
• 다른 클라이언트에 툴을 제공했을 때 더 나아지는 고객 업무를 구체적으로 제시할 수 없습니다.
• 권한 부여나 서비스 동작이 아직 안정적이지 않습니다. 인터페이스 계약을 추가하기 전에 먼저 안정화해야 합니다.

둘 다 제공할 때: 기존 방식의 연동이 계속 중요하면서 고객이 대화를 통한 접근도 원할 때입니다. 예를 들어 티켓 관리 제품은 웹 앱과 자동화를 위한 API를 유지하면서, 어시스턴트가 티켓을 검색하고 생성하도록 일부 기능을 MCP 툴로 제공할 수 있습니다.

개발자는 서비스 계층을 재사용해야 합니다. 제품 책임자는 지원할 업무와 클라이언트를 정해야 합니다. 운영자는 각 작업을 수행한 사용자를 확인할 방법과 접근 권한을 회수할 방법을 마련해야 합니다. 한 사람이 모두 맡더라도 각각은 별개의 책임입니다.

MCP, API, CLI는 어떻게 다른가요?

같은 서비스 위에서 호출 주체에 맞춰 서로 다른 인터페이스를 제공할 수 있습니다. 명령줄 인터페이스(CLI)는 사람과 스크립트가 실행할 명령을 제공합니다. API는 애플리케이션 코드가 사용할 프로그래밍 계약을 제공합니다. MCP는 호환되는 AI 호스트를 위한 공통 툴 인터페이스를 제공합니다.

배포 스크립트가 이미 안정적인 CLI나 API를 호출하고 있다면 MCP를 추가해도 나아지는 점이 없을 수 있습니다. 반면 고객이 자신의 어시스턴트에서 티켓 작업을 수행하고 싶어 한다면, MCP를 통해 호스트별 전용 연동을 만들 필요를 줄일 수 있습니다. 호출 주체에 맞는 인터페이스를 유지해야 합니다. 약어를 통일하려는 이유만으로 잘 작동하는 자동화를 옮길 필요는 없습니다.

추가 인터페이스에는 보안과 유지보수 책임이 따릅니다

MCP 코드가 API와 함께 배포되더라도, 지원하고 관리해야 할 경계가 하나 더 생긴다는 점이 핵심 부담입니다. 툴 설명, 스키마, 의존성, 인증 연동, 클라이언트 호환성을 지속적으로 관리할 담당자가 필요합니다.

자격 증명과 접근 권한을 구분해야 합니다

MCP의 권한 부여 명세는 HTTP 구현을 위한 OAuth 2.1 기반 프레임워크를 설명합니다. OAuth는 애플리케이션에 서비스의 제한된 접근 권한을 부여하는 프레임워크입니다. 프로토콜 수준에서 권한 부여 기능은 선택 사항이지만, 제품의 비공개 데이터를 보호하지 않아도 된다는 권고는 아닙니다. stdio의 자격 증명 전달 경로는 HTTP 프레임워크와 다릅니다.

어댑터는 MCP 서버에 들어오는 요청의 자격 증명과 기반 서비스로 보내는 요청의 자격 증명을 모두 다뤄야 할 수 있습니다. 토큰이 어떤 서비스를 대상으로 발급되었는지, 즉 대상 수신자(audience)를 검증하고 사용자에게 허용된 권한 범위를 유지해야 합니다. 보안 지침은 다른 리소스용 토큰을 확인 없이 받아 하위 서비스로 전달하는 행위를 금지합니다.

티켓 예시에서 광범위한 권한을 가진 서비스 자격 증명을 쓴다고 해서 연결된 모든 사용자에게 프로젝트 관리자 권한이 주어져서는 안 됩니다. 어댑터가 자격 증명을 어떻게 구성하든, 접근 권한 검사는 공통 비즈니스 작업 안에서 유지해야 합니다.

지원할 수 있는 업무를 중심으로 툴을 설계해야 합니다

유용한 작업을 명확한 범위로 제공해야 합니다. 임의의 URL, 메서드, 요청 본문을 모두 받는 무제한 툴보다 create_ticket이나 범위가 정해진 검색부터 시작하는 편이 좋습니다.

이는 프로토콜의 제약이 아니라 제품 설계 권고입니다. 인터페이스가 작을수록 설명, 권한 관리, 문제 해결이 쉽습니다. 생성기로 정의를 만들 수 있다는 이유만으로 모든 내부 엔드포인트를 툴 목록에 그대로 옮겨서는 안 됩니다.

툴 설명에는 작업의 목적과 작업에 수반되는 변경 사항을 명시해야 합니다. 결과를 식별하는 데 충분한 정보를 반환하되, 관련 없는 민감한 필드는 제외해야 합니다. 스키마는 데이터의 형식을 정할 뿐, 요청한 작업이 허용되거나 적절하다는 사실까지 입증하지는 않습니다.

두 인터페이스를 거치는 실패도 추적할 수 있어야 합니다

툴 호출부터 기반 서비스의 작업까지 흐름을 추적해야 합니다. 자격 증명이나 불필요한 민감 정보를 로그에 남기지 않으면서, 권한이 확인된 호출자의 신원, 툴 이름, 관련 요청 식별자와 결과를 기록해야 합니다.

유효성 검사 실패, 권한 거부, 호출 한도 초과, 의존하는 서비스의 장애를 구분해야 합니다. 쓰기 요청을 전송한 뒤 타임아웃이 발생했다면, 재시도 전에 공통 작업의 재시도 규칙에 따라 이미 완료되었는지 판단해야 합니다. MCP가 이 비즈니스상의 보장을 대신 만들어 주지는 않습니다.

로컬 서버에는 의존성과 실행 권한을 관리하는 일이 따릅니다. 호스팅 서버에는 배포와 가용성을 관리하는 일이 따릅니다. 어느 환경에서도 유지보수는 필요합니다.

버전과 한도: 프로토콜과 툴의 호환성을 각각 관리해야 합니다

프로토콜 호환성과 툴 호환성은 별개의 과제입니다. 2026년 10월 17일에 확인한 MCP 문서에서는 2026-07-28을 현행 프로토콜 버전으로 명시합니다. 버전 관리 문서는 요청별 버전 선언 방식과, 핸드셰이크를 사용하던 이전 버전과의 호환성을 설명합니다.

그렇다고 앞서 나열한 모든 클라이언트가 이 버전을 구현한다는 뜻은 아닙니다. 지원되는 소프트웨어 개발 키트(SDK)를 선택하고, 대상 클라이언트가 사용하는 버전과 기능을 테스트해야 합니다.

툴의 비즈니스 계약은 따로 살펴봐야 합니다. create_ticket이 프로젝트 키 대신 다른 식별자를 필수로 요구하도록 바뀌었다면, MCP 프로토콜 버전이 그대로라는 이유만으로 호환되는 변경이 되지는 않습니다. 마이그레이션 중에는 기존 계약을 유지하거나, 명확히 구분되는 대체 툴을 도입하면서 문서와 지원 종료 정책을 제공해야 합니다.

한도 역시 실제로 지원하는 서비스와 호스트를 기준으로 정해야 합니다. 결과 크기, 허용할 데이터 범위, 요청 처리 시간, 의존하는 서비스의 호출 한도가 여기에 해당합니다. 프로토콜 연결에 성공했다는 사실만으로 방대한 응답이 모델에 유용하다거나, 오래 걸리는 쓰기 작업을 안전하게 재시도할 수 있다고 판단해서는 안 됩니다.

MCP에 대한 기대 중 무엇이 과장되어 있나요?

MCP는 연동 방식의 차이를 줄여 주지만 연동 작업 자체를 없애지는 않습니다. 다음 주장들은 적용 범위를 더 정확히 짚어야 합니다.

• “AI가 API를 호출하려면 MCP가 필요합니다.” AI 애플리케이션은 자체 툴을 구현할 수 있습니다. OpenAI의 함수 호출 문서는 모델이 툴을 요청한 뒤 애플리케이션이 코드를 실행하는 방식을 명시적으로 설명합니다. MCP는 공통 클라이언트·서버 인터페이스가 필요할 때 유용합니다.
• “스키마가 있으면 작업은 안전합니다.” 형식이 올바른 요청도 접근이 금지된 프로젝트를 대상으로 하거나 원치 않는 쓰기 작업을 수행할 수 있습니다. 권한 확인과 검토는 여전히 애플리케이션의 책임입니다.
• “MCP가 백엔드를 대체합니다.” 프로토콜은 기능을 전달할 뿐, 티켓 처리 규칙이나 데이터베이스, 서비스 신뢰성을 제공하지는 않습니다.
• “MCP는 항상 상태를 유지합니다.” REST와 이런 식으로 일괄 대비하면 현행 명세의 요청별 처리 모델과 이전 연결 범위 세션을 다루는 방식을 놓치게 됩니다. 구현하려는 전송 명세 버전을 확인해야 합니다.

더 설득력 있는 약속은 소박하면서도 실용적입니다. 고객은 호환되는 호스트에서 지원되는 툴 인터페이스를 재사용하고, 서비스 제공자는 기반 서비스에 대한 통제권을 유지할 수 있습니다.

실제 제공을 위한 다음 단계

MCP 툴 목록을 작성하기 전에 고객의 업무와 대상 클라이언트부터 정해야 합니다. 티켓 생성 기능을 검토하는 제품 책임자라면 기존 API 담당 개발자와 함께 간단한 인수 기준 체크리스트를 만드는 것이 다음 단계입니다.

1. 1

   공통 작업을 정의합니다

   입력, 결과, 권한 경계, 중복 요청 처리 방식을 정의합니다. 이 규칙은 기존 서비스에서 관리합니다.

2. 2

   범위를 좁힌 툴을 제공합니다

   MCP 정의와 핸들러를 추가하고, 클라이언트 문서에 명시된 연결 방식을 선택합니다. 기존 API도 계속 사용할 수 있도록 유지합니다.

3. 3

   핵심 동작을 검증합니다

   허용된 요청, 프로젝트 접근 거부, 반복된 쓰기 작업, 의존하는 서비스에 대한 요청 실패를 확인합니다. 두 인터페이스가 같은 비즈니스 결과를 보장하는지 검증합니다.

구현 방법은 Python MCP 서버 가이드를 참고하면 됩니다. 첫 업무 흐름을 지속적으로 지원할 가치가 확인된 뒤 툴 목록을 확장하면 됩니다.

자주 묻는 질문

API가 있는데 MCP를 사용하는 이유는 무엇인가요?

고객이 호환되는 AI 애플리케이션에서 서비스를 이용할 수 있도록 표준화된, 탐색 가능한 툴 인터페이스가 필요할 때 MCP를 사용합니다. MCP는 API를 감싸는 경우가 많으므로, 기반 서비스를 교체하기보다는 접근 경로를 추가하는 선택에 가깝습니다.

API와 엔드포인트는 같은 뜻인가요?

아닙니다. API는 인터페이스 계약이고, 엔드포인트는 그 일부를 노출하는 주소입니다. 티켓 예시에서 API에는 작업과 데이터 규칙이 포함되며, /tickets는 작업에 사용되는 리소스 경로입니다. IBM의 API 설명도 계약과 요청 주소를 구분합니다.

API의 예시로는 무엇이 있나요?

티켓 생성, 주문 상태 조회, 계정 데이터 조회 등이 API 기능의 예입니다. MCP 서버는 이 중 일부 기능을 툴로 제공하고, 실제 구현은 기반 애플리케이션에 그대로 둘 수 있습니다.

API와 프록시는 어떻게 다른가요?

API는 소프트웨어가 서비스와 상호작용하는 방식을 정의합니다. 프록시는 요청을 전달하는 중개자입니다. MCP 어댑터는 클라이언트를 대신해 API를 호출할 수 있지만, MCP 툴 계약도 함께 제공합니다. HTTP 요청을 전달하는 것만으로 툴 탐색 기능이 생기지는 않습니다.

API의 네 가지 유형이란 무엇인가요?

보편적으로 통용되는 단일한 네 가지 분류는 없습니다. 공개·비공개·파트너는 접근 대상을 구분하고, 복합은 기반 작업들을 결합하는 방식을 나타냅니다. IBM의 API 개요도 이를 서로 다른 분류 기준으로 다룹니다. 이 분류만으로 HTTP API에 MCP를 추가할지 결정할 수는 없습니다.

AI를 활용한 제품 개발에서 실용적인 판단을 내리는 데 도움이 필요하다면 뉴스레터를 구독하세요.