MCP vs 직접 API 호출 — 나의 에이전트 스택에는 MCP 서버가 하나도 없다

Model Context Protocol (MCP)이 지금 어디에나 있습니다. 모든 에이전트 튜토리얼은 "먼저, MCP 서버를 설정하세요"라는 문장으로 시작합니다. 하지만 제가 이 글을 쓰고 있는 기기에서 실행 중인 에이전트 스택 — 검색 모니터링, Telegram 알림, 소셜 포스팅, 음성 비서 — 에는 MCP 서버가 단 하나도 포함되어 있지 않습니다. 모든 것이 직접 API 호출 (direct API calls)을 통해 외부 서비스와 통신합니다.

이것은 MCP를 거부하는 것이 아닙니다. 그것은 프로토콜이지, 하나의 운동(movement)이 아닙니다. 그리고 에이전트 아키텍처(agent-architecture)에 관한 콘텐츠의 범람은 배관(plumbing)에 관한 결정을 정체성에 관한 결정으로 계속 바꾸어 놓습니다. 당신은 "MCP를 사용하는 곳"이거나 "뒤처진" 것이 아닙니다. 당신은 워크로드(workload)별 통합 방식을 선택하고 있는 것이며, 이는 두 가지 관문으로 요약됩니다. 하나는 MCP가 관련 카테고리인지 여부를 결정하고, 다른 하나는 그것이 오버헤드 (overhead)를 감수할 가치가 있는지를 결정합니다.

첫 번째 관문 — 관련성: 모델이 런타임 (runtime)에 도구를 선택하는가?

MCP는 특정한 문제를 해결하기 위해 존재합니다. 즉, 언어 모델 (language model)이 세션 중간에 어떤 도구를 사용할지 결정하는 문제입니다. 이 프로토콜은 모델이 도구를 발견하는 방식, 도구의 스키마 (schema)가 어떻게 생겼는지, 그리고 결과가 어떻게 돌아오는지에 대한 표준을 제공합니다. 그것이 MCP가 존재하는 유일한 이유입니다. 즉, 모델을 향한 프로토콜 (model-facing protocol)입니다. 만약 모델이 도구를 선택하는 일이 전혀 없다면, MCP는 관련 카테리아가 아닙니다. 그럴 때는 라이브러리를 공유하거나 일반적인 서비스를 구축하면 됩니다.

이제 대부분의 자동화가 실제로 무엇인지 살펴보십시오. 저의 아침 보고 파이프라인 (pipeline)은 다음과 같습니다:

1. 8:30에 Cron 실행
2. 스크립트가 Google Search Console API 호출
3. 스크립트가 수치 데이터 포맷팅
4. 스크립트가 Telegram에 게시

여기서 모델은 아무것도 결정하지 않습니다. 런타임 도구 선택이 없습니다. 이런 파이프라인에서 모델의 유일한 역할은 한 단계에서 데이터를 읽는 것이지, 데이터를 가져오는 것이 아닙니다. 호출 순서는 매일, 영원히 고정되어 있습니다. 이 워크로드에 있어서 MCP는 고려 대상이 아닙니다.

나중에 중요해질 미묘한 차이 하나는 다음과 같습니다. 첫 번째 관문(gate one)은 당신 앞에 놓인 워크로드(workload)가 아니라, **도구 인터페이스(tool surface)의 소비자(consumers)**를 기준으로 평가된다는 점입니다. 크론 파이프라인(cron pipeline)은 결코 이 관문을 통과하지 못할 것입니다. 하지만 그 아래에 있는 검색 데이터 접근 방식은 — 모델 기반 클라이언트(model-driven client)가 동일한 데이터를 원하게 되는 날 — 통과할 수도 있습니다. 파이프라인은 MCP의 후보가 아니지만, 그 인터페이스(surface)는 후보가 될 수 있습니다.

어느 쪽이든: 에이전트(agent)라는 사실 자체가 기준은 아닙니다. 수많은 에이전트 시스템(agentic systems)은 중간에서 모델이 해석을 수행하는 결정론적 파이프라인(deterministic pipelines)일 뿐입니다.

두 번째 관문 — 가치: 이 표준으로부터 누가 또 이득을 얻는가?

첫 번째 관문만으로는 충분하지 않다는 것을 깨닫게 해준 사례가 여기 있습니다. 저의 음성 비서(voice assistant)는 첫 번째 관문을 통과합니다. 모델이 제가 말하는 내용을 런타임(runtime)에 이 기기에 있는 스크립트 중 하나로 매핑하기 때문입니다. 이것은 진정한 도구 선택(tool selection)이며, 정확히 MCP의 영역입니다.

하지만 그럼에도 그곳에서 MCP를 사용할 가치는 여전히 없습니다. 모델은 단 한 대의 기기에서, 단 하나의 클라이언트 내에 있는, 제가 작성한 8개의 알려진 스크립트 중에서 선택합니다. 의도(intent)를 스크립트 경로로 매핑하는 사전(dictionary)만 있으면 20줄 내외로 작업을 수행할 수 있습니다. MCP를 도입한다면, 소비자가 단 한 명이고 작성자도 단 한 명뿐인 대상에 대해 표준화된 인터페이스(standardised interface)를 얻게 되는 셈입니다.

따라서 두 번째 관문에는 두 개의 문이 있으며, 그중 어느 하나라도 통과한다면 오버헤드(overhead)를 감수할 명분이 됩니다:

• 두 번째 소비자 (A second consumer). 코딩 에이전트(coding agent), 데스크톱 어시스턴트(desktop assistant), 그리고 채팅 인터페이스가 모두 당신의 데이터베이스에 접근해야 한다면, 이를 MCP 서버로 한 번 작성하는 것이 세 개의 맞춤형 통합(custom integrations)을 만드는 것보다 낫습니다. 표준화(standardisation) 자체가 곧 제품입니다.
• 당신이 작성하지 않은 도구들. 브라우저, 데이터베이스, SaaS 플랫폼과 같은 제3자(Third-party) MCP 서버들은 당신이 직접 API 클라이언트(API client)를 작성하지 않고도 기능을 제공합니다. 당신이 무엇을 구매하고 있는지 정확히 말하자면, 소유권(ownership)은 '작성(authoring)' 비용을 뒤집는 것이지, '운영(operating)' 비용을 뒤집는 것이 아닙니다. 당신은 여전히 연결, 인증(auth), 버전 고정(version pinning), 그리고 서버의 장애 표면(failure surface)을 관리해야 합니다 — 이에 대해서는 아래에서 더 자세히 다루겠습니다. 그럼에도 불구하고, 단일 소비자(single consumer) 상황이라면 클라이언트 코드를 작성하고 유지 관리하지 않는 것이 종종 더 나은 거래가 됩니다.
• 두 가지 모두에 해당하는 퇴보적 사례: 진정으로 개방적인 세션 (genuinely open-ended sessions). 다음 요청이 40여 개의 주로 제3자 도구 중 어떤 것을 필요로 할지 예측할 수 없는 대화형 에이전트 작업입니다. 그 정도 규모에서는 스키마 발견(schema discovery)과 통일된 호출(uniform invocation)이 단순한 격식(ceremony)을 넘어 유일하게 합리적인 선택지가 됩니다.

압축된 규칙: 모델이 선택을 내린다면 MCP가 관련성을 갖게 되며, 두 번째 소비자 — 또는 타인의 도구 — 가 있다면 그것을 사용할 가치가 생깁니다.

나의 스택은 실제로 어떻게 생겼는가

워크로드 (Workload)	관문 1: 모델이 선택하는가?	관문 2: 소비자 / 소유권	통합 방식 (Integration)
오전 검색 보고서	아니오 — 고정된 파이프라인 (fixed pipeline)	—	cron 스크립트를 통한 직접 API 호출
...

아무도 언급하지 않는 비용

관리형 플랫폼(managed platforms)에서 MCP 서버는 무료처럼 느껴지지만, 그곳에서의 "무료"는 다른 형태의 청구서를 의미합니다: 지연 시간(latency), 불투명성(opacity), 그리고 타인의 가동 시간(uptime)에 대한 결합(coupling)입니다. 베어 메탈(bare metal) 환경에서 비용은 숨겨져 있지 않습니다. 모든 MCP 서버는 또 하나의 프로세스입니다: 부팅 시 시작되거나 되지 않으며, 어딘가에 로그를 남기거나 남기지 않고, 자격 증명(credentials)을 보유하며, 버전이 있고, 멈출(hang) 수도 있습니다. 나의 모니터링 스택이 존재하는 이유는, 관리되지 않은 채 실행되는 것은 조만간 조용히 실패한다는 것을 배웠기 때문입니다. 내가 추가하는 각각의 통합은, 아침 보고서가 도착하지 않았을 때 오전 8시에 미래의 내가 디버깅해야 할 대상입니다.

cron 스크립트 내부의 직접적인 API 호출 (direct API call)은 실패 지점 (failure surface)이 스크립트 하나뿐입니다. 반면 MCP 통합은 클라이언트 (client), 서버 (server), 그리고 그 사이의 전송 계층 (transport)까지 총 세 가지의 실패 지점을 가집니다. 이것이 제3자 서버가 제거해주지 못하는 운영 비용입니다. 그들은 클라이언트를 작성하는 수고는 덜어주지만, 대신 계속 유지 관리해야 할 프로세스를 넘겨줍니다. 때로는 그 거래가 가치가 있을 수도 있습니다. 하지만 고정된 일일 파이프라인 (daily pipeline)의 경우에는 그렇지 않습니다.

내가 MCP를 고려하는 경우 — 그리고 내 원칙이 꺾이는 지점

만약 이 머신의 데이터에 두 번째 클라이언트를 연결해야 한다면 — 예를 들어 내 스크립트와 동일한 검색 데이터 접근 권한이 필요한 데스크톱 어시스턴트라면 — 그것이 바로 트리거 (trigger)입니다. 두 명의 소비자 (consumers), 하나의 도구 인터페이스: MCP 서버를 작성하고, 두 클라이언트 모두를 그곳으로 향하게 한 뒤, 중복된 글루 코드 (glue code)를 삭제하는 것입니다. 표준화 (standardisation)의 수혜자가 둘 이상이 되는 순간, 오버헤드 (overhead)는 레버리지 (leverage)로 전환됩니다.

범위에 대한 솔직한 주의사항이 하나 있습니다. "두 번째 소비자를 기다렸다가 마이그레이션(migrate)하라"는 전략은 제가 완전히 제어할 수 있는 머신을 사용하는 1인 운영자이기 때문에 합리적입니다. 트리거를 감지할 사람도 저 자신이며, 제가 교체하게 될 글루 코드의 모든 줄을 알고 있기 때문입니다. 팀 단위에서는 두 번째 소비자가 원래 작성자가 떠난 후에 예고 없이 나타나는 경우가 많으며, 미뤄둔 마이그레이션 비용은 글루 코드를 먼저 역공학 (reverse-engineer)해야 하는 사람에게 전가됩니다. 그러한 환경에서는 두 번째 게이트가 공식적으로 열리기 전에 추상화 (abstraction) 비용을 미리 지불하는 것이 옳은 결정일 수 있습니다. 게이트는 변하지 않지만, 그 앞에 서 있는 사람은 변합니다.

두 번째 소비자가 나타나기 전까지, 지루한 정답은 그대로 유지됩니다: cron, 스크립트, HTTP 호출, 그리고 로그 파일입니다. 모델이 선택을 내린다는 점이 MCP를 유의미하게 만듭니다. 다른 누군가가 그 표준으로부터 이득을 얻는다면 그것은 가치가 있습니다. 그 외의 모든 것은 튜토리얼일 뿐입니다.