MCP vs API: AI 도구에 MCP와 HTTP를 쓰는 기준

AI 에이전트를 외부 도구 및 API에 연결하는 방법은 크게 두 가지입니다. 추상화 계층으로 Model Context Protocol(MCP)을 사용하거나, HTTP로 API를 직접 호출하는 방식입니다. 둘 다 작동합니다. 다만 유연성, 복잡성, 성능, 이식성에서 서로 다른 트레이드오프가 있습니다.

이 글에서는 구체적인 코드 예제, 지연 시간 분석, 선택을 위한 의사결정 프레임워크를 통해 두 접근 방식을 비교합니다.

두 가지 접근 방식

직접 HTTP 통합

AI 애플리케이션(또는 백엔드)이 표준 HTTP 요청을 사용해 외부 API를 직접 호출합니다. 개발자는 요청을 구성하고, 인증을 처리하고, 응답을 파싱하고, 결과를 LLM에 다시 전달하는 코드를 작성합니다.

┌──────┐     ┌──────────────┐                    ┌────────────┐
│ 사용자 │────▶│ AI 앱        │──── HTTP 요청 ────▶│ 날씨 API    │
└──────┘     │              │◀─── JSON 응답 ─────│            │
             │              │                    └────────────┘
             │              │── 결과를 컨텍스트로 ──▶ LLM
             │              │◀── 형식화된 답변 ───
             └──────┬───────┘
                    │
                    ▼
              사용자가 답변을 받음

MCP 통합

AI 애플리케이션은 외부 API를 감싸는 MCP 서버에 연결합니다. 애플리케이션은 MCP 프로토콜을 사용해 사용 가능한 도구를 검색하고, 이름으로 호출하고, 결과를 받습니다. MCP 서버는 외부 API에 대한 실제 HTTP 호출을 처리합니다.

┌──────┐     ┌────────────────────┐              ┌────────────┐     ┌──────────┐
│ 사용자 │────▶│ AI 앱/MCP 클라이언트 │── JSON-RPC ─▶│ MCP 서버    │────▶│ HTTP API │
└──────┘     │                    │◀─ JSON-RPC ──│            │◀────│          │
             │                    │              └────────────┘     └──────────┘
             │                    │── 결과를 컨텍스트로 ──▶ LLM
             │                    │◀── 형식화된 답변 ───
             └──────────┬─────────┘
                        │
                        ▼
                  사용자가 답변을 받음

핵심 차이는 다음과 같습니다. 직접 HTTP에서는 AI 애플리케이션이 API 통합 코드를 소유합니다. MCP에서는 MCP 서버가 이를 소유하고, AI 애플리케이션은 이름으로 도구를 호출하기만 합니다.

서버를 구축하지 않고도 이 다이어그램의 MCP 쪽을 사용할 수 있습니다. Quickchat AI는 모든 AI Agent에 대해 스트리밍 가능한 HTTP MCP 서버를 호스팅하며, 에이전트를 MCP 서버로 전환하는 작업은 AI 앱에 URL 하나를 붙여 넣는 것으로 끝납니다.

코드 비교

실용적인 예제로 두 접근 방식을 비교해 보겠습니다. GitHub 사용자의 저장소를 가져오는 예입니다.

직접 HTTP 통합

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """GitHub 사용자의 저장소를 가져옵니다."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        return [
            {
                "name": r["name"],
                "description": r["description"],
                "stars": r["stargazers_count"],
                "language": r["language"],
                "url": r["html_url"]
            }
            for r in repos
        ]

이를 LLM과 통합하려면 다음도 필요합니다.

LLM이 기대하는 형식의 도구 정의(OpenAI function calling schema, Claude tool use schema 등)
LLM의 도구 호출을 파싱하고, get_user_repos를 실행하고, 결과를 대화에 다시 주입하는 코드
HTTP 실패, 속도 제한, 인증 만료에 대한 오류 처리

MCP 서버

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("github-server")

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

@mcp.tool()
async def get_user_repos(username: str) -> str:
    """GitHub 사용자의 최근 업데이트된 저장소 10개를 가져옵니다.

    Args:
        username: 조회할 GitHub 사용자 이름
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {GITHUB_TOKEN}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        lines = []
        for r in repos:
            stars = r["stargazers_count"]
            lang = r["language"] or "알 수 없음"
            lines.append(f"- {r['name']} ({lang}, 별 {stars}개): {r['description'] or '설명 없음'}")
        return "\n".join(lines)

if __name__ == "__main__":
    mcp.run(transport="stdio")

MCP 버전은 API 호출, 인증, 응답 형식화를 서버 내부에 캡슐화합니다. MCP와 호환되는 모든 클라이언트는 GitHub API에 대해 알 필요 없이 이 도구를 사용할 수 있습니다.

AI 애플리케이션에서 달라지는 점

관심사	직접 HTTP	MCP
도구 정의	LLM의 네이티브 형식으로 작성(OpenAI schema 등)	MCP 서버에서 자동 생성
인증	AI 앱이 관리	MCP 서버가 관리
응답 파싱	AI 앱이 데이터를 추출하고 형식화	MCP 서버가 미리 형식화된 결과를 반환
오류 처리	AI 앱이 HTTP 오류를 처리	MCP 서버가 오류를 처리하고 구조화된 오류 메시지를 반환
새 도구 추가	AI 앱에 새 코드를 작성	새 MCP 서버에 연결(또는 기존 서버에 도구 추가)
LLM 전환	새 LLM 형식에 맞게 도구 정의를 다시 작성	변경 필요 없음

성능 비교

MCP는 AI 애플리케이션과 외부 API 사이에 계층을 하나 추가합니다. 이 계층에는 비용이 있습니다.

지연 시간

stdio transport(로컬 MCP 서버)의 경우 오버헤드는 매우 작습니다. 시작 시 프로세스 생성(일회성, 일반적으로 100ms 미만)과 메시지당 프로세스 간 통신(현대적인 시스템에서는 1밀리초 미만)이 전부입니다. 실제로는 외부 API 호출이 전체 지연 시간의 대부분을 차지합니다.

원격 MCP 서버(Streamable HTTP 또는 SSE)의 경우 클라이언트와 MCP 서버 사이에 HTTP 왕복이 한 번 추가되고, MCP 서버에서 외부 API로 가는 HTTP 왕복이 더해집니다. MCP 서버와 외부 API가 같은 위치에 있으면 이 오버헤드는 작습니다(한 자릿수 밀리초). 서로 다른 리전에 있으면 누적됩니다. 다만 사용자가 체감하는 것은 대부분 transport가 아닙니다. Notion의 호스팅 MCP 서버로 헬프 센터 에이전트를 구축할 때, 248회의 도구 호출은 평균 2.7초가 걸렸으며, 대부분은 중간 홉이 아니라 Notion 검색과 페이지 렌더링에 소요되었습니다.

구성	대략적인 추가 지연 시간
로컬 MCP 서버(stdio)	도구 호출당 < 1ms
원격 MCP 서버(API와 같은 리전)	도구 호출당 1-5ms
원격 MCP 서버(API와 다른 리전)	도구 호출당 10-50ms

대부분의 AI 에이전트 사용 사례에서는 LLM 추론에 500ms-5s가 걸리므로 MCP 오버헤드는 무시할 수 있는 수준입니다.

연결 관리

직접 HTTP: 애플리케이션이 각 외부 API에 대한 연결을 관리합니다. 즉 API별 연결 풀, 재시도 로직, 속도 제한을 처리해야 합니다.

MCP: 애플리케이션은 MCP 서버당 하나의 연결을 관리합니다. 서버가 외부 API 연결을 관리합니다. 3개의 MCP 서버에 10개의 도구가 분산되어 있다면, 10개 대신 3개의 연결을 관리하면 됩니다.

MCP를 사용할 때

여러 도구 통합

AI 애플리케이션이 5개 이상의 외부 서비스에 연결해야 한다면 MCP는 통합 부담을 줄입니다. 각 서비스에 대한 사용자 지정 API 클라이언트를 작성하고 유지 관리하는 대신 MCP 서버에 연결합니다. 이 중 많은 서버는 오픈 소스 프로젝트로 제공됩니다.

AI 플랫폼 간 이식성

도구용 MCP 서버를 구축하면 해당 서버는 모든 MCP 클라이언트에서 작동합니다. Claude Desktop, Cursor, Windsurf, 사용자 지정 애플리케이션, Quickchat AI 같은 플랫폼이 여기에 포함됩니다. 직접 HTTP를 사용하면 각 플랫폼의 형식에 맞게 도구 정의를 다시 구현해야 합니다.

동적 도구 검색

MCP는 tools/list를 통한 런타임 도구 검색을 지원합니다. AI 애플리케이션은 하드코딩된 설정 없이 서버에 연결해 사용 가능한 도구를 알 수 있습니다. 도구가 자주 바뀌거나 사용자가 설정할 수 있는 시나리오에 유용합니다.

관심사의 분리

서로 다른 팀이 서로 다른 도구를 소유한다면 MCP는 명확한 경계를 제공합니다. Salesforce 통합을 소유한 팀이 Salesforce MCP 서버를 구축하고 유지 관리합니다. AI 애플리케이션 팀은 Salesforce API를 이해할 필요 없이 여기에 연결합니다. Salesforce API 업데이트는 AI 애플리케이션을 건드리지 않고 MCP 서버에서 처리됩니다.

직접 HTTP를 사용할 때

하나 또는 두 개의 통합

AI 에이전트가 하나의 API만 호출하면 된다면(예: 데이터베이스 조회), MCP 서버를 실행하는 오버헤드는 불필요합니다. 직접 HTTP 호출이 더 단순하고 구성 요소가 적습니다.

요청을 직접 작성할 필요도 없습니다. 일반 영어 API Action 빌더는 문서화된 REST API를 읽고 method, URL, parameters, description을 생성한 다음, 활성화하기 전에 실제 응답을 테스트할 수 있게 해 줍니다.

요청에 대한 최대 제어

MCP 서버는 HTTP 세부 사항을 추상화합니다. 요청 구성에 대한 정밀한 제어가 필요하다면(특정 헤더, 쿼리 파라미터, 요청 서명 또는 비표준 인증), 직접 HTTP는 추상화 계층과 충돌하지 않고 그 제어권을 제공합니다.

지연 시간에 민감한 작업

모든 밀리초가 중요하다면(예: 도구 호출이 엄격한 시간 예산 안에 완료되어야 하는 실시간 음성 에이전트), MCP 계층을 제거하면 홉 하나를 없앨 수 있습니다.

AI가 아닌 HTTP 호출

HTTP 호출이 AI 에이전트에 의해 트리거되지 않는다면(예: 데이터를 동기화하는 백엔드 cron job), MCP는 관련이 없습니다. MCP는 AI와 도구 간 통신을 위해 특별히 설계되었습니다. 일반 백엔드 서비스는 일반 HTTP 클라이언트를 사용해야 합니다.

하이브리드 접근 방식

많은 프로덕션 시스템은 둘 다 사용합니다. 패턴은 다음과 같습니다.

대화 중 AI 에이전트가 호출하는 도구 통합에는 MCP 사용(CRM 조회, 티켓 생성, knowledge base 쿼리)
내부 백엔드 작업, 웹훅, 시스템 간 통신에는 직접 HTTP 사용

Quickchat AI 내부도 이런 방식으로 작동합니다. 플랫폼은 HTTP Request Actions(파라미터 템플릿을 지원하는 직접 API 호출)와 Remote MCP Actions(외부 MCP 서버 연결)를 모두 지원합니다. 각 통합에 맞는 접근 방식을 선택하면 됩니다.

통합 유형	권장 접근 방식
알려진 파라미터로 수행하는 단순 API 호출	HTTP Request Action
여러 관련 도구가 있는 복잡한 통합	Remote MCP Action
기존 MCP 서버가 있는 타사 서비스	Remote MCP Action
사용자 지정 인증이 있는 내부 API	HTTP Request Action
사용자가 설정할 수 있는 도구	Remote MCP Action

실제로 이것이 어떻게 작동하는지, OpenAI의 GPT Actions와 MCP의 차이를 포함한 자세한 비교는 GPT Actions vs MCP를 참조하세요.

의사결정 프레임워크

다음 흐름도를 사용해 선택하세요.

AI 에이전트가 도구를 호출하나요? 아니라면(백엔드 작업이라면) 직접 HTTP를 사용하세요.
몇 개의 외부 도구가 필요한가요? 1-2개라면 직접 HTTP가 더 단순합니다. 3개 이상이라면 MCP를 고려하세요.
해당 서비스에 미리 구축된 MCP 서버가 있나요? 있다면 이를 사용해 개발 시간을 줄일 수 있습니다.
통합이 여러 AI 플랫폼에서 작동해야 하나요? 그렇다면 MCP가 이식성을 제공합니다.
지연 시간이 중요하나요(도구 호출에 100ms 미만 예산)? 그렇다면 MCP 오버헤드를 벤치마크하고 그에 따라 결정하세요.
서로 다른 팀이 서로 다른 통합을 소유하나요? 그렇다면 통합별 서버를 두는 MCP 모델이 소유권 경계에 도움이 됩니다.

실제로 외부 서비스와 상호작용해야 하는 AI 에이전트를 구축한다면 MCP가 점점 기본 선택지가 되고 있습니다. 미리 구축된 서버 생태계가 충분히 커졌기 때문에 서버 코드를 전혀 작성하지 않고도 시작할 수 있는 경우가 많습니다.

더 읽어보기

AI Agent를 Remote MCP Server에 연결하기: 에이전트에 실시간 도구를 단계별로 제공
Model Context Protocol 작동 방식. MCP 설명: MCP 소개
GPT Actions vs MCP: OpenAI 접근 방식과의 비교
MCP Specification: 공식 프로토콜 사양
HubSpot AI Actions: HTTP 기반 AI actions의 실제 예
OpenAI Hugging Face 사건, 실제로 일어난 일: 사건을 단계별로 살펴보고, 해킹이 실제로 무엇을 의미하는지 설명합니다.