MCP 대 API: 기존 API가 AI 에이전트 구축에 한계를 보이는 이유

Google Cloud Tech의 영상을 기반으로, 왜 전통적인 API로는 AI 에이전트를 제대로 구축할 수 없는지, 그리고 MCP(Model Context Protocol)가 그 해답이 되는지를 정리해 봅니다.

"API면 충분하지 않나요?" — 가장 자연스러운 질문

AI 개발을 해오던 분이라면 MCP(Model Context Protocol)라는 새로운 표준이 등장했을 때 이런 생각을 해보셨을 겁니다.

"관심은 가는데, 왜 기존에 쓰던 API로는 안 되는 거지?"

표면적으로 보면 합리적인 질문입니다. LLM에 OpenAPI 스펙을 주고 적절한 요청을 하도록 하면 되지 않나요?

문제는 이 접근 방식이 현실에서 심각한 장애물에 부딪힌다는 점입니다. 인간 개발자를 위해 설계된 인터페이스와 AI 에이전트가 추론에 필요한 프로토콜은 근본적으로 다릅니다.

핵심은 이겁니다: 전통적인 API는 개발자를 위한 명령서입니다. MCP는 AI 에이전트를 위한 언어입니다.

기존 API가 AI 에이전트에 부족한 3가지 이유

1. "선택의 역설"이 성능을 망친다

에이전트에 더 많은 도구를 주면 더 똑똑해질 것이라고 생각하기 쉽습니다. 하지만 정반대입니다. 도구만 많아질 뿐, 에이전트는 더 혼란스러워집니다.

엔터프라이즈 API는 쉽게 75~100개 엔드포인트를 가집니다. LLM은 긴 목록에서 올바른 옵션을 고르는 데 놀랍도록 약합니다. 선택지가 너무 많으면:

응답 속도가 느려짐
유사한 도구 간 구별에 실패
잘못된 도구를 선택하거나 아예 동작하지 않음

결국 개발자가 수동으로 작은 도구 목록만 골라줘야 하는데, 이는 풍부한 API를 가진다는 의미를 무색하게 만듭니다.

2. 수동 번역의 부담

API 문서는 인간 개발자를 위해 작성됩니다. 맥락을 추론하고 구글에서 찾아보는 것이 가능합니다. AI 에이전트는 그런 일을 할 수 없습니다.

결과적으로 개발자는 풀타임 번역가가 됩니다:

각 도구마다 래퍼를 작성
목적, 파라미터, 출력을 상세히 기술
API가 바뀔 때마다 깨지는 fragile한 시스템

3. 에이전트는 맹목적으로 비행한다

에이전트가 API에게 "새로운 기능이 뭐가 있어요?" 또는 "제게 뭘 해줄 수 있나요?"라고 물을 수 없습니다. 하드코딩된 도구만 알 뿐입니다. 새로운 기능을 활용하거나 적응할 수 없으므로, 에이전트의 자율성과 유용성이 근본적으로 제한됩니다.

MCP는 어떻게 이 문제들을 해결하는가

MCP는 단순히 다른 API가 아닙니다. 에이전트가 "생각"하는 방식에 맞춰 설계된 완전히 다른 접근법입니다.

1. 복잡성을 추상화해 더 나은 추론을 가능하게 함

MCP의 가장 큰 강점입니다. 100개의 저수준 도구를 LLM에 과부하로 주기 대신, 소수의 고수준 기능을 제공합니다.

예를 들어 createUser, updateUserAddress, resetUserPassword 같은 개별 도구를 주기 대신, 하나의 manageUserProfile 기능을 제공합니다. 에이전트는 이 하나를 호출하면 되고, MCP 서버가 내부 로직을 처리합니다.

또 다른 예: LLM은 복잡한 SQL 작성이 약점입니다. 단일 run_sql 도구를 주기 대신, MCP는 여러 단계의 database_migration 기능을 제공할 수 있습니다 — 먼저 테스트 브랜치에 SQL을 스테이징하고, LLM이 검증하도록 요청한 후 최종 커밋합니다. 에이전트의 추론 수준에 맞춰 성공으로 이끄는 것입니다.

2. 동적 발견을 가능하게 함

에이전트가 실행 시점에 MCP 서버에 연결하여 "무엇을 할 수 있나요?"라고 물을 수 있습니다. 즉석에서 사용 가능한 기능을 학습합니다. 에이전트 코드를 재배포하지 않고도 새로운 도구를 추가할 수 있으므로, 전체 시스템이 훨씬 더 적응 가능해집니다.

3. 통신을 표준화함

"AI용 USB-C 포트" 비유처럼, MCP는 에이전트-도구 간 통신의 보편적 프로토콜을 만듭니다. 각 서비스마다 커스텀 래퍼를 작성할 필요가 줄어더므로, 더 견고하고 확장 가능한 생태계가 형성됩니다.

보안 질문: 이 에이전트는 대체 누구인가?

이 새로운 아키텍처는 새로운 보안 질문을 부각시킵니다. 에이전트가 스스로 도구를 발견하고 사용할 수 있게 되면 다음과 같은 질문에 답할 수 있어야 합니다:

에이전트가 특정 사용자를 위해 진정한 권한으로 행동하는지 어떻게 보장할까?
에이전트가 허용된 도구만, 서비스하는 사용자를 위해 사용할 수 있도록 세분화된 권한을 어떻게 강제할까?

이는 이론적 질문이 아닙니다. AI 보안의 다음 현실적 과제입니다. 해결을 위해서는 OAuth 2.0과 같은 검증된 패턴으로 토크 위임을 통해 에이전트에 구체적이고 제한된 권한을 부여하고, 사용자의 신원을 대화의 전체 라이프사이클에 안전하게 묶어야 합니다.

MCP는 AI 에이전트를 위한 올바른 인터페이스

궁극적으로 MCP는 기존 API를 대체하는 것이 아닙니다. 새로운 소비자 — AI 에이전트 — 를 위해 설계된 필수적인 추상화 레이어입니다.

효과적인 MCP 서버 구축은 OpenAPI 스펙을 한 번 클릭으로 변환하는 것 이상이 필요합니다. 등장 중인 모범 사례는 하이브리드 접근법입니다:

기존 스펙에서 시작
LLM을 압도하지 않도록 도구셋을 적극적으로 정리
저수준 엔드포인트를 고수준 작업 지향 기능으로 추상화
에이전트가 신뢰성 있게 작동하도록 지속적인 평가

이러한 신중한 설계가 자율적 AI 애플리케이션의 진정한 잠재력을 해방하는 열쇠입니다.

요약

MCP는 AI 에이전트 시대의 새로운 인터페이스 표준입니다. 기존 API를 버리는 게 아니라, AI가 이해할 수 있는 언어로 번역하는 층을 추가하는 것입니다.

출처: Google Cloud Tech — "MCP 대 API: 기존 API가 AI 에이전트 구축에 한계를 보이는 이유" (영상 링크) / Auth0 Blog — "Why Can't I Just Use an API? Because Your AI Agent Needs MCP" (링크) / MCP 공식 문서

AI Agent를 만들 때 OpenAI Assistants API와 LangChain 중 무엇을 써야 할지 고민이라면, 이 글이 도움이 될 것입니다. 두 접근법의 차이를 실용적인 관점에서 비교합니다.

OpenAI Assistants API

OpenAI가 직접 제공하는 에이전트 플랫폼입니다. 복잡한 코드 없이 Assistant를 생성하고 Thread(대화 스레드)를 관리할 수 있습니다.

장점

설정이 매우 간단, 빠른 시작 가능
Code Interpreter, File Search 등 내장 도구
OpenAI 인프라에서 관리되므로 운영 부담 없음
스트리밍, 스레드 관리 등 기본 제공

단점

OpenAI 모델만 사용 가능 (벤더 락인)
커스터마이징 자유도가 낮음
요금이 상대적으로 높음
데이터가 OpenAI 서버로 전송됨 (보안 민감 환경 부적합)

간단한 사용법

from openai import OpenAI
client = OpenAI()

# Assistant 생성
assistant = client.beta.assistants.create(
    name="데이터 분석가",
    instructions="CSV 파일을 분석하고 인사이트를 제공하세요.",
    tools=[{"type": "code_interpreter"}],
    model="gpt-4o"
)

# Thread 생성 및 메시지 전송
thread = client.beta.threads.create()
client.beta.threads.messages.create(
    thread_id=thread.id,
    role="user",
    content="첨부 파일의 매출 트렌드를 분석해줘"
)

LangChain 에이전트

장점

모든 LLM 지원 (OpenAI, Claude, Gemini, 오픈소스 모델)
완전한 커스터마이징 가능
로컬 실행 가능 (데이터 보안)
풍부한 생태계와 커뮤니티

단점

초기 설정 복잡, 학습 곡선 있음
직접 인프라 관리 필요
버전 업그레이드 시 Breaking Changes 발생 가능

선택 기준

상황	추천
빠른 프로토타입	Assistants API
프로덕션 서비스	LangChain
오픈소스 모델 사용	LangChain
데이터 보안 중요	LangChain (로컬)
OpenAI 전용 서비스	Assistants API
팀 규모 대, 장기 운영	LangChain

결론

개인 프로젝트나 빠른 POC는 Assistants API, 실제 서비스는 LangChain이 적합합니다. 두 가지를 모두 익혀두면 상황에 맞게 선택할 수 있는 유연성이 생깁니다.

House AI - Local LLM

페이지

2026/07/07