AI 에이전트용 API: MCP부터 커스텀 엔드포인트까지

LLM이 함수를 호출하게 되었을 때

GPT-3 시대에는 LLM과 상호작용한다는 것은 프롬프트를 입력하고 텍스트를 받는다는 의미였습니다. 모델의 지식은 방대했지만 정적이었고, 학습 데이터에 포함된 내용에 고정되어 있었습니다. 양자 컴퓨팅을 설명하거나 이메일 초안을 작성해 달라고 요청하면 그럴듯한 텍스트를 생성할 수 있었습니다. 하지만 오늘의 날씨를 확인하거나, 데이터베이스를 조회하거나, 현실 세계에서 어떤 작업을 수행할 수는 없었습니다.

이를 바꾼 기능은 놀라울 정도로 덜 주목받았습니다. 이 기능은 모델에 텍스트 생성과 함수 호출 사이의 선택지를 제공했습니다. 항상 다음 토큰을 생성하는 대신, 이제 모델은 함수 이름과 인수를 지정하는 구조화된 JSON 객체를 출력할 수 있게 되었습니다. 런타임은 해당 함수를 실행하고, 결과를 다시 모델에 전달하며, 모델은 그 지점부터 계속 진행합니다. ReAct 논문(Yao et al., 2022)은 이를 Thought-Action-Observation 루프로 정식화했습니다. 모델은 무엇을 할지 추론하고, 행동을 수행하며(도구를 호출), 결과를 관찰한 뒤 반복합니다. 2026년의 모든 주요 AI 에이전트는 이 패턴의 어떤 버전 위에서 실행됩니다.

루프

Claude Code, OpenClaw, Codex, Devin 및 수십 개의 다른 에이전트형 시스템은 모두 같은 방식으로 동작합니다. 도구를 호출하고, 결과를 관찰하고, 다음에 할 일을 결정한 뒤 반복합니다. Simon Willison은 이를 잘 표현했습니다: “LLM 에이전트는 목표를 달성하기 위해 루프 안에서 도구를 실행한다.”

예를 들어 Claude Code는 멀티 에이전트 스웜이나 복잡한 오케스트레이션 그래프 없이 단일 스레드 마스터 루프를 사용합니다: while(tool_call) -> execute -> feed results -> repeat.

AI 에이전트 루프

Anthropic의 에이전트 자율성 연구에 따르면 Claude Code의 턴 지속 시간이 3개월 동안 25분에서 45분 이상으로 거의 두 배가 되었습니다. 사용자는 점점 더 루프가 스스로 실행되도록 신뢰하고 있습니다. 데이터는 숙련된 사용자가 더 자주 개입한다는 점을 보여줍니다(행동별 승인에서 전략적 모니터링으로 이동). 반면 에이전트 자체가 명확화를 요청하는 빈도는 사용자가 개입하는 빈도의 두 배 이상입니다.

이 루프 패턴은 코딩 에이전트, 고객 지원 봇, 로보틱스 컨트롤러 등 어디에서나 나타납니다.

무엇을 도구로 볼 것인가?

LLM은 도구가 어느 추상화 수준에서 작동해야 하는지 결정하는 데 상당한 자유를 제공합니다. 한쪽 극단에는 매우 구체적인 API 엔드포인트가 있습니다: “이 12개 필드로 HubSpot 연락처 만들기.” 다른 한쪽에는 “이 bash 명령 실행” 또는 “이 Python 코드 실행” 같은 도구가 있습니다. 이는 본질적으로 “원하는 것은 무엇이든 하라”는 의미입니다.

Devin은 세 가지 도구, shell, 코드 편집기, 브라우저로 동작합니다. Claude Code의 기본 도구도 shell입니다. OpenClaw는 동적 스킬 플러그인 시스템을 사용합니다. 에이전트형 코딩 도구의 추세는 많은 특화 도구보다 더 적고 더 범용적인 도구로 향하고 있습니다.

Simon Willison은 코딩 에이전트에서 bash가 보편적 도구이기 때문에 MCP가 “처음에는 폭발적으로 확산되었지만 이후 덜 중심적으로 느껴졌다”고 관찰했습니다. 파일과 스크립트는 완전한 MCP 서버 구현보다 오버헤드가 낮은 기본 요소입니다. 에이전트가 코드를 작성하고 실행할 수 있다면, 전용 도구 정의 없이도 거의 모든 것을 할 수 있습니다.

하지만 범용 도구는 범용 에이전트에 적합합니다. 도메인 특화 AI 에이전트(고객 지원, 영업, 내부 운영)의 경우 도메인 특화 도구가 필요합니다. 지원 에이전트가 주문 상태를 확인하기 위해 Python을 작성해서는 안 됩니다. 명확한 파라미터와 예측 가능한 응답을 가진 잘 정의된 API 엔드포인트를 호출해야 합니다. 도구 세트의 설계는 제품 의사결정이 됩니다.

접근 방식	예시	제어	유연성	사용 사례
범용 도구	Bash, Python 인터프리터	최소	최대	코딩 에이전트, 개인 비서
프로토콜 번들(MCP)	Shopify MCP, GitHub MCP	중간	중간	빠른 통합, 프로토타이핑
단일 API 엔드포인트	”HubSpot 연락처 만들기”	최대	최소	프로덕션 고객 대면 에이전트

지금 API 엔드포인트가 의미하는 것

AI 에이전트에게 API 엔드포인트는 기능 선언으로 작동합니다. 하나를 게시한다는 것은 이제 여러분(또는 여러분의 AI 에이전트)이 이전에는 불가능했던 일을 할 수 있다는 뜻입니다.

이는 양방향으로 작동합니다. 소프트웨어 공급업체는 다른 사람들이 자사 제품과 통합할 수 있도록 API를 게시합니다. 하지만 AI 에이전트도 문서를 검색하고, OpenAPI 사양을 읽거나, 말 그대로 어떤 작업을 수행하는 방법을 구글링하여 스스로 엔드포인트를 발견할 수 있습니다.

MCP 서버는 API 엔드포인트를 선별해 묶은 번들이며, 사용 방식에 대한 사전 개념을 포함합니다. MCP 작성자는 이미 어떤 엔드포인트를 노출할지, 어떤 이름을 붙일지, 어떤 파라미터를 표면화할지, 그리고 암묵적으로 어떤 워크플로를 지원할지 결정했습니다. 이 선별은 강점(편의성, 표준화)이자 약점(경직성, 의견이 반영된 범위 지정)입니다. Notion의 서버는 구체적인 예입니다. 28개의 도구를 게시하며, 헬프 센터 에이전트는 그중 네 개가 필요합니다. 이는 두 개의 연결로 나뉩니다.

MCP는 제어를 사용 편의성과 맞바꿉니다. 2026년에는 AI가 대부분의 통합 코드를 작성합니다. 에이전트가 API 문서를 읽고 통합을 직접 작성할 수 있다면, MCP의 “사용 편의성” 주장은 약해집니다. MCP 계층은 도구가 모델의 역량을 따라잡지 못한 전환기에 가장 중요할 수 있습니다. Anthropic의 도구 사용 설계 패턴 가이드는 MCP를 사용하든 개별 엔드포인트를 사용하든 도구 스키마를 구조화하는 데 실용적인 참고 자료입니다.

관련된 발전도 있습니다. llms.txt는 웹사이트가 AI 모델을 고가치 리소스로 안내하기 위해 /llms.txt 파일을 게시하는 제안 표준입니다. Anthropic, Cloudflare, Docker, Stripe가 이를 채택했습니다. MCP는 도구 호출을 표준화하고, llms.txt는 문서 발견을 표준화합니다. 둘 다 서로 다른 각도에서 웹을 기계가 더 잘 읽을 수 있도록 만들려는 시도입니다.

AI 에이전트의 맥락에서 API 엔드포인트란 무엇인가요?

API 엔드포인트는 구조화된 입력을 받아 구조화된 출력을 반환하는 특정 URL입니다. AI 에이전트에게 각 엔드포인트는 에이전트가 현실 세계에서 수행할 수 있는 개별 기능을 나타냅니다. 엔드포인트의 설명, 파라미터 정의, 오류 응답은 에이전트의 사용 설명서 역할을 합니다. 엔드포인트가 더 잘 문서화될수록 에이전트는 이를 더 안정적으로 사용할 수 있습니다.

튜토리얼을 읽고 반복적으로 디버깅할 수 있는 인간 개발자와 달리, 에이전트는 한 번의 올바른 호출을 만들기 위해 엔드포인트의 스키마와 설명에 의존합니다. 이것이 AI 소비를 위해 설계된 API 문서가 그 어느 때보다 중요한 이유입니다. 현재 개발자의 89%가 워크플로에서 AI를 사용하고 있음에도, AI 에이전트를 염두에 두고 API를 설계하는 개발자는 24%에 불과합니다.

MCP(Model Context Protocol)란 무엇인가요?

MCP는 AI 에이전트가 외부 도구와 데이터 소스에 연결하는 방식을 표준화하는 Anthropic이 도입한 오픈 프로토콜입니다. AI를 위한 USB-C라고 생각하면 됩니다. 모든 도구 제공자가 구현할 수 있고 모든 AI 에이전트가 사용할 수 있는 단일 커넥터입니다. MCP 서버는 표준화된 스키마를 가진 도구 세트(본질적으로 API 엔드포인트)를 노출하며, MCP 클라이언트(에이전트)는 커스텀 통합 코드 없이 이를 발견하고 호출할 수 있습니다. 더 깊은 기술적 설명은 MCP Explained 글을 참고하세요. 프로덕션에서 MCP를 사용한 실제 사례는 Shopify의 MCP 기반 구축에서 마주한 실제 과제에 대한 분석을 참고하세요.

Quickchat AI에서의 제어 스펙트럼

Quickchat AI는 AI Agent에 외부 도구를 장착하는 세 가지 방법을 제공합니다. 이들은 가장 자동화된 방식부터 가장 제어 가능한 방식까지 하나의 스펙트럼 위에 있습니다. 각 접근 방식은 설정 속도와 동작의 정밀성 사이에서 서로 다른 절충을 만듭니다.

Remote MCP: 연결하고 바로 사용하기

Remote MCP는 AI Agent를 외부 기능에 연결하는 가장 빠른 방법입니다. MCP 서버 URL을 제공하면 Quickchat AI가 이에 연결하고, 사용 가능한 모든 도구를 발견한 뒤, 에이전트가 어떤 도구를 사용할지 선택할 수 있게 합니다.

설정 방법:

Quickchat AI dashboard에서 AI Actions로 이동합니다
“Add Remote MCP”를 클릭합니다
MCP 서버 URL을 붙여넣습니다(예: https://mcp.example.com/sse)
선택적으로 인증 토큰 또는 커스텀 헤더를 추가합니다(두 옵션은 상호 배타적입니다)
“Connect.”를 클릭합니다. Quickchat AI가 사용 가능한 모든 도구를 발견하고 이름을 표시합니다
개별 도구를 켜거나 끄면서 에이전트가 사용할 수 있는 도구를 제어합니다
새로 발견된 도구를 자동으로 활성화할지 비활성화할지 제어하려면 “default tool is active” 플래그를 설정합니다

Quickchat AI의 Remote MCP

내부에서 일어나는 일:

Connect를 클릭하면 Quickchat AI가 URL에서 전송 프로토콜을 자동 감지합니다. URL에 sse가 포함되어 있으면 SSE 전송이 사용되고, 그렇지 않으면 streamable_http가 기본값입니다. 인증 토큰을 제공하면 Authorization 헤더에 Bearer 토큰으로 전송됩니다.

도구 필터링은 3단계 시스템으로 작동합니다. MCP 서버의 각 도구는 두 집합과 비교됩니다. 명시적으로 활성화된 도구는 항상 포함되고, 명시적으로 비활성화된 도구는 항상 제외되며, 어느 집합에도 없는 도구는 선택한 “default tool is active” 설정을 따릅니다. 즉 MCP 서버가 새 도구를 추가할 때, 해당 도구를 에이전트가 자동으로 사용할 수 있게 할지, 명시적 활성화를 요구할지 제어할 수 있습니다.

도구 필터링

런타임에 대화가 시작되면 에이전트의 모든 활성 Remote MCP 연결이 로드됩니다. 도구는 각 연결의 구성에 따라 가져오고 필터링되며, 모든 소스에서 도구 이름의 고유성이 검증됩니다(중복이 발견되면 경고가 표시됩니다).

절충점: MCP가 노출하는 모든 것에 즉시 접근할 수 있지만, 도구 설명, 파라미터 정의, 또는 에이전트가 이를 사용하기로 결정하는 방식에 대한 제어는 제한적입니다. Shopify의 MCP로 AI Agent를 구축하면서 확인했듯이, 데모에서 프로덕션으로 넘어가려면 신중한 튜닝이 필요하며 MCP의 번들 접근 방식은 이를 어렵게 만들 수 있습니다.

AI Actions(HTTP Request): 하나의 엔드포인트, 완전한 제어

Quickchat AI의 AI Action은 AI Agent를 위해 개별적으로 구성하는 단일 HTTP API 엔드포인트입니다. MCP가 도구 번들을 한 번에 가져오는 반면, 각 AI Action은 하나의 특정 기능에 대한 완전한 제어를 제공합니다. 연락처를 만들고 보강하며, 거래를 기록하고, CRM에서 티켓을 여는 네 가지 액션을 다룬 완전한 예시는 HubSpot AI Actions 튜토리얼을 참고하세요.

AI Action 구성:

Name(최대 64자): LLM이 보는 도구 이름이 됩니다. 유효한 식별자로 정규화됩니다(예: “Check Order Status”는 Check_Order_Status가 됩니다)
Description(최대 1,000자): 가장 중요한 필드입니다. 설명은 LLM에 이 도구를 언제 사용할지 알려줍니다. 좋은 설명은 어떤 대화 상황에서 호출해야 하는지, 먼저 사용자에게 어떤 정보를 수집해야 하는지, 결과를 어떻게 다시 전달해야 하는지를 명시합니다
HTTP method: GET, POST, PATCH, DELETE 또는 PUT
URL(최대 10,000자): 동적 값을 위한 {{parameter_name}} 플레이스홀더를 포함할 수 있습니다
Headers: 인증 및 콘텐츠 유형을 위한 키-값 쌍
Body items / Body JSON: 파라미터 주입이 포함된 요청 본문
Query parameters: URL 쿼리 문자열 값
Parameters(최대 10개): 각각 이름, 설명(최대 500자), 타입(str, int, float, bool 또는 custom), 필수 여부 플래그, 선택적 기본값을 가집니다

{{parameter_name}} 플레이스홀더가 핵심 메커니즘입니다. LLM이 도구를 호출할 때, 대화 컨텍스트를 바탕으로 각 파라미터의 값을 제공합니다. Quickchat AI는 HTTP 요청을 보내기 전에 해당 값을 URL, 헤더, 본문, 쿼리 문자열 템플릿에 주입합니다. 이 방식으로 주입할 수 있는 네 가지 내장 변수도 있습니다: scenario_id, conversation_id, conversation_channel, conversation_url.

AI Action 예시 주문 상태 확인을 위해 구성된 AI Action입니다. 파라미터 플레이스홀더가 포함된 URL 템플릿, 헤더, 파라미터 정의를 보여줍니다.

내부 동작: Quickchat AI는 각 AI Action의 파라미터 정의에서 타입이 지정된 스키마를 동적으로 구축합니다. 지원되는 다섯 가지 타입(str, int, float, bool, custom)은 네이티브 동등 타입으로 매핑되며, 이 스키마는 HTTP 요청을 보내기 전에 LLM의 입력을 검증하는 데 사용됩니다.

주문 상태를 확인하는 AI Action 예시:

{
  "name": "check_order_status",
  "description": "사용자가 주문 상태에 대해 질문하고 주문 번호를 제공했을 때, 현재 상태를 조회하기 위해 이 엔드포인트를 호출합니다. 상태, 예상 배송일, 추적 번호(사용 가능한 경우)를 사용자에게 다시 알려줍니다.",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "사용자가 제공한 주문 ID(예: ORD-12345)",
      "type": "str",
      "is_required": true
    }
  ]
}

테스트: dashboard에는 배포 전에 샘플 파라미터 값을 제공하고 실제 HTTP 요청(생성된 curl 명령 포함)과 응답을 확인할 수 있는 “Test” 버튼이 있습니다.

효과적인 AI Action 설명 작성 팁:

에이전트가 언제 호출해야 하는지 구체적으로 작성하세요: “사용자가 주문 상태를 질문하고 주문 번호를 제공하면 이 엔드포인트를 호출합니다”
먼저 수집해야 할 정보를 언급하세요: “호출하기 전에 사용자의 이메일 주소와 주문 ID가 있는지 확인합니다”
응답 처리 방법을 설명하세요: “상태가 ‘shipped’이면 응답의 추적 번호를 사용자에게 알려줍니다”
다단계 워크플로의 경우 개별 액션 설명이 아니라 에이전트의 기본 시스템 프롬프트에 순서를 설명하고, 액션 간에 값을 전달하고 이를 기준으로 쓰기 작업을 게이트하려면 Save to memory와 실행 조건을 사용하세요

작동 예시: 리드, 답변되지 않은 질문, 데모 요청을 스프레드시트에 바로 기록하는 단계별 AI Action은 AI 에이전트를 Google Sheets에 연결하는 방법을 참고하세요.

Generate from Text: AI가 알아서 찾게 하기

세 번째 옵션은 에이전트가 무엇을 하기를 원하는지는 알지만 어떤 API 엔드포인트(또는 어떤 서비스)를 사용해야 하는지는 모르는 사용자를 위한 것입니다.

작동 방식:

원하는 내용을 자연어로 입력합니다. 예: “사용자가 요청하면 내 AI Agent가 사용자의 Tesla를 시동할 수 있게 하고 싶습니다”
Quickchat AI는 web_search 도구가 활성화된 LLM에 이를 보냅니다
모델은 웹을 조사해 올바른 API를 찾고, 공식 문서를 읽은 뒤, URL, 메서드, 헤더, 파라미터, 인증 요구사항을 포함한 완전한 AI Action 사양을 생성합니다
결과는 전체 액션 구성, 사용한 문서에 대한 인용, 가정과 누락 사항을 언급하는 설명 메시지와 함께 반환됩니다
검토하고, 자격 증명을 입력한 뒤, 활성화합니다

텍스트에서 생성한 AI Action 원하는 기능에 대한 자연어 설명을 입력합니다.

텍스트에서 생성한 AI Action 결과 사용된 API 문서에 대한 인용이 포함된 생성된 AI Action 구성입니다.

자동화된 AI Action 생성은 세 가지 우선순위를 중심으로 구성됩니다.

우선순위 1: 의도 이해. 개발자가 원하는 정확한 기능과 이를 제공하는 특정 API 엔드포인트를 식별합니다
우선순위 2: 문서에 근거하기. 추측이 아니라 웹 검색을 사용해 공식 공급업체 문서를 찾습니다
우선순위 3: 대화 우선 의미론 설계. 생성된 이름과 설명은 API가 기술적으로 무엇을 하는지가 아니라, 이 도구가 대화 중 언제 사용되는지를 설명해야 합니다

프롬프트는 두 가지 플레이스홀더 규칙을 사용합니다. {{param}}은 LLM이 대화 컨텍스트에서 채우는 런타임 파라미터를 표시합니다. [[secret_name]](이중 대괄호)은 활성화 전에 수동으로 구성해야 하는 API 키와 계정 ID 같은 개발자 상수를 표시합니다. 모든 파라미터 이름은 요청 정의 어딘가에 {{that_exact_name}} 플레이스홀더로 나타나야 하며, 고아 플레이스홀더는 허용되지 않습니다.

시스템은 fail-closed 정책을 사용합니다. 모델이 문서에서 중요한 정보(HTTP 메서드, URL, 인증 방식 또는 필수 페이로드 구조)를 확인할 수 없으면 액션이 생성되지 않습니다. 대신 추측하지 않고 무엇이 누락되었는지에 대한 간결한 설명을 반환합니다.

여기에서 AI 에이전트가 API를 발견한다는 철학적 지점이 구체적인 제품 기능과 연결됩니다. Generate from Text 기능은 말 그대로 AI 에이전트(웹 검색이 가능한 LLM)가 다른 AI 에이전트(대화에서 이를 사용할 Quickchat AI 에이전트)를 위한 도구 정의를 구축하는 것입니다.

작동 예시: 입력한 두 문장을 두 개의 실시간 테스트 완료 액션(키가 필요 없는 날씨 조회와 키가 필요한 NASA 액션, fail-closed 거부 포함)으로 바꾸는 전체 튜토리얼은 일반 영어로 AI 에이전트를 모든 API에 연결하는 방법을 참고하세요.

런타임에는 이 모든 도구 유형이 함께 조립됩니다. Quickchat AI는 HTTP request AI Action 도구, Shopify MCP 도구, knowledge base 도구, remote MCP 도구, Discord 도구, 기타 커스텀 도구를 LLM에 제시할 컬렉션으로 수집합니다. 모델은 이들 사이의 차이를 보지 않습니다. Remote MCP 도구와 수동으로 구성된 AI Action은 도구 목록에 들어가면 동일하게 보입니다.

새로운 SEO로서의 오픈 API

AI 에이전트가 API를 자율적으로 발견하고 사용하게 된다면, 잘 문서화되고 사용하기 쉬운 API를 보유하는 것은 배포 자산이 됩니다. Gartner는 2026년까지 API 수요 증가분의 30% 이상이 AI 에이전트에서 나올 것이라고 예측합니다.

최소한의 자격 증명 장벽을 가진 오픈 API를 보유한 기업은 자사 API가 최고의 획득 채널이 되는 것을 발견할 수 있습니다. Google 검색 노출 대신, “노출”은 AI 에이전트가 경쟁사 서비스가 아니라 여러분의 서비스를 사용하기로 선택하는 것입니다.

같은 논리는 한 단계 위에도 적용됩니다. 문서에서 답변하는 AI 에이전트 자체를 ChatGPT, Claude, Cursor가 도구로 호출하는 MCP 서버로 노출할 수 있으며, 이를 통해 API뿐 아니라 여러분의 지식도 에이전트형 웹에서 발견 가능해집니다.

API 문서의 품질은 AI 에이전트가 한 번의 시도로 여러분과 성공적으로 통합할 수 있는지를 결정합니다. 파라미터 설명, 오류 메시지, 예시 응답은 전통적인 SEO에서 메타 설명과 구조화된 데이터가 수행하는 것과 같은 기능을 합니다. 혼란스러운 오류 응답이나 문서화되지 않은 필수 필드는 에이전트의 실패로 이어지며, 반대편에는 이를 디버깅할 사람이 없습니다.

API가 문서화되어 있지 않거나 무거운 자격 증명 요구사항 뒤에 가려진 기업은 2000년대에 웹사이트가 없던 기업이 Google에서 보이지 않게 되었던 것처럼, 에이전트형 웹에서 보이지 않게 될 수 있습니다.

Computer Use와 API

AI 모델에 “computer use”(버튼 클릭, 양식 작성, UI 탐색)를 가르치는 데 상당한 투자가 이루어지고 있습니다. Anthropic, OpenAI(Operator), Browser Use 같은 오픈 소스 프로젝트가 모두 이에 대한 버전을 제공합니다.

하지만 브라우저 사용은 API가 없을 때의 우회 방법입니다. POST /orders 호출은 밀리초 단위로 실행되고 구조화된 데이터를 반환합니다. 체크아웃 흐름을 탐색하는 브라우저 에이전트는 몇 분이 걸리며, 버튼이 왼쪽으로 3픽셀만 이동해도 실패할 수 있습니다. API는 더 빠르고, 더 결정적이며, 실행 비용이 더 낮습니다.

Computer use와 API 비교

반론도 타당합니다. 모든 것에 API가 존재하지는 않습니다. 레거시 시스템, API 표면이 없는 엔터프라이즈 소프트웨어, GUI를 통해 제어되는 물리적 장치가 있습니다. Computer use는 이러한 경우 실제 공백을 메웁니다.

“이 작업을 위한 API가 없다”는 말에 대한 더 나은 장기적 대응은 아마 AI에게 GUI 사용법을 가르치는 것이 아니라 API를 구축하는 것입니다. 더 많은 소프트웨어가 AI 에이전트에 의해, AI 에이전트를 위해 작성될수록 API를 구축하고 유지하는 비용은 낮아집니다. UI를 스크래핑하는 것이 API를 만드는 것보다 저렴하게 만들었던 경제적 계산은 바뀌고 있습니다.

보안 측면도 있습니다. Simon Willison의 “치명적 삼중 조합”은 비공개 데이터 접근 + 신뢰할 수 없는 콘텐츠 노출 + 외부 통신의 위험한 조합을 설명합니다. 이는 두 접근 방식 모두에 적용되지만, API 기반 도구는 감사하고 제약하기가 더 쉽습니다. 모든 API 호출을 기록하고, 모든 파라미터를 검증하며, 모든 엔드포인트에 속도 제한을 걸 수 있습니다. 무엇이든 클릭할 수 있는 브라우저 에이전트에 대해 동일한 작업을 수행하는 것은 훨씬 더 어렵습니다.

물리적 세계를 위한 도구

지금까지 논의한 모든 것은 소프트웨어에 관한 것입니다. 같은 패턴은 물리적 세계에서도 나타납니다.

Google DeepMind의 RT-2와 Gemini Robotics는 같은 아키텍처를 사용하지만, 도구가 API 대신 액추에이터로 디스패치된다는 점이 다릅니다. SPCA(Sense-Plan-Code-Act) 프레임워크는 이를 로보틱스에 대해 정식화합니다. 환경을 스캔하고, 접근 방식을 계획하며, 실행 가능한 코드를 생성하고, 실행한 뒤, 결과를 관찰합니다.

“내 책상 위 화분을 오른쪽으로 옮겨라”라는 API는 없습니다. 하지만 카메라가 있는 로봇은 즉석에서 move_object(object_id="plant_01", direction="right", distance_cm=15)를 도구로 정의한 뒤 호출할 수 있습니다. 도구 정의는 추론 계층과 물리적 실행 계층 사이의 인터페이스 역할을 합니다. 이는 소프트웨어에서 API 엔드포인트가 하는 역할과 같습니다.

LLM + 도구 + 루프 아키텍처는 범용입니다. 오늘날에는 소프트웨어에서 구현하기 가장 쉽지만, 로보틱스도 따라잡고 있습니다.

물리적 세계를 위한 도구

AI가 AI를 위해 작성하는 API

대략 2년(2024년부터 2026년) 사이에 우리는 대부분의 코드가 인간에 의해 작성되던 시점에서 대부분의 코드가 AI에 의해 작성되는 시점으로 이동했습니다. 이는 API 엔드포인트가 무엇인지 다시 생각하기 좋은 순간입니다. 점점 더 엔드포인트는 인간 개발자가 문서를 읽고 수동으로 통합하기 위한 기술 인터페이스가 아니라, 기계가 발견하고 실행하도록 설계된 기능 선언이 되고 있습니다.

MCP는 유용한 표준화 계층이지만, 편향을 도입하는 선별 계층이기도 합니다. MCP 작성자는 어떤 도구를 노출할지, 그리고 이를 어떻게 프레이밍할지 결정합니다. 프로덕션 AI 에이전트에서는 그 프레이밍이 실제로 필요한 것과 맞지 않을 수 있습니다. (우리는 Shopify의 MCP 관련 과제를 분석하면서 이 점을 자세히 다뤘습니다.)

Quickchat AI Agents에서 살펴본 스펙트럼은 더 넓은 관점을 반영합니다. 적절한 제어 수준은 사용 사례에 따라 다릅니다. Remote MCP는 빠른 프로토타이핑에 적합합니다. 개별 AI Actions는 프로덕션 고객 대면 에이전트를 위한 세밀한 제어를 제공합니다. Generate from Text는 아직 탐색 중일 때 AI가 API를 조사하고 도구 정의를 구축하도록 합니다.

그리고 모든 수준에서 underlying 패턴은 동일합니다. LLM, 도구 세트, 루프입니다. 도구가 bash 명령이든, API 엔드포인트이든, MCP 서버이든, 로봇 액추에이터이든, 아래로 내려가도 계속 도구입니다.