에이전트는 API를 대체하지 않습니다. 오히려 기존 API가 얼마나 취약한지를 드러낼 뿐입니다

AI 에이전트(AI agents)가 Model Context Protocol과 같은 기술과 결합하여 API를 대체할 것이라는 담론이 확산되고 있습니다.

왜 그런 생각이 자리 잡았는지 이해하기는 쉽습니다. 에이전트는 도구(tools)를 발견하고, 어떤 도구를 호출할지 추론하며, 런타임(runtime)에 워크플로우를 조립할 수 있습니다. 이는 하나의 시스템이 고정된 엔드포인트(endpoint), 고정된 페이로드(payload), 고정된 순서에 따라 다른 시스템을 호출하는, 우리가 수년간 경험해 온 정적 통합(static integrations)과는 매우 다르게 느껴집니다.

하지만 그 결론은 타당하지 않습니다.

에이전트는 API를 대체하지 않습니다. 에이전트는 API에 의존합니다. 에이전트가 실제로 하는 일은 많은 API가 이미 얼마나 취약한지를 드러내는 것입니다.

대체라는 환상

Model Context Protocol과 유사한 접근 방식은 제어 평면(control plane)을 변화시킵니다. 이들은 에이전트에게 사용 가능한 도구를 발견하고, 설명을 검토하며, 무엇이 관련이 있는지 결정하고, 추론된 의도에 따라 호출할 수 있는 방법을 제공합니다.

이는 유용합니다. 하지만 동시에 그 이상의 무언가로 오해하기 쉽습니다.

에이전트가 접하는 설명(description)의 이면에서는, 우리가 이미 이해하고 있는 것과 동일한 종류의 작업들이 여전히 수행되고 있습니다: HTTP 엔드포인트(HTTP endpoints), 구조화된 페이로드(structured payloads), 인증된 작업(authenticated operations), 서비스(services), 데이터 저장소(data stores), 그리고 이벤트 스트림(event streams)입니다. 에이전트가 무엇을 호출할지 동적으로 결정할 수는 있지만, 호출되는 대상은 여전히 결정론적(deterministically)으로 동작해야 합니다.

이것이 첫 번째 중요한 차이점입니다. MCP는 에이전트가 도구를 찾고 호출하는 방식을 표준화합니다. 그것이 도구 아래에 있는 실행 계층(execution layer)을 제거하는 것은 아닙니다. 오히려 호출자가 예측 불가능해졌기 때문에, 그 계층은 더욱 중요해졌다고 볼 수 있습니다.

대부분의 API는 개방형으로 설계된 적이 없습니다

불편한 진실은 많은 API가 실제로 범용 인터페이스(general-purpose interfaces)가 아니라는 점입니다. 그것들은 이미 알려진 애플리케이션을 위한 백엔드(backends)입니다.

그것은 비난이 아닙니다. 지극히 이해할 수 있는 이유들로 인해 대부분의 시스템이 구축되어 온 방식입니다. React 프론트엔드 (front end)는 특정 형태의 데이터가 필요합니다. 모바일 앱 (mobile app)은 정해진 여정 (journey)을 가지고 있습니다. 파트너 통합 (partner integration)은 협의된 흐름 (flow)을 따릅니다. API는 이러한 소비자 (consumers)들을 중심으로 진화하며, 시간이 흐름에 따라 계약 (contract)에는 관련된 모든 이들이 명시적으로 기록하지 않아도 이해하고 있는 가정 (assumptions)들이 흡수됩니다.

호출자 (caller)가 누구인지 알고, 순서 (sequence)를 알며, 컨텍스트 (context)를 공유하고 있습니다.

API가 실제로 더 큰 애플리케이션 경계 (application boundary)의 일부일 때는 이 방식이 충분히 잘 작동합니다. 하지만 소비자가 주변 컨텍스트를 상속받지 않은 에이전트 (agent)가 되면 상황은 훨씬 더 취약해집니다.

에이전트는 특정 화면만을 위해 구축된 엔드포인트 (endpoint)가 무엇인지 알지 못합니다. 특정 필드가 이전 호출을 통해 어떤 상태 (state)를 초기화한 후에만 유효하다는 사실도 알지 못합니다. 어떤 작업이 안전한 이유가 단지 프론트엔드 (front end)가 평소에 사용자가 잘못된 순서로 해당 작업에 도달하는 것을 방지해주기 때문이라는 점도 알지 못합니다. 에이전트는 도구 (tool), 이름 (name), 설명 (description), 그리고 스키마 (schema)를 봅니다. 그런 다음 노출된 정보로부터 추론합니다.

저는 제가 한때 작업했던 modifyCustomer API에서 이러한 패턴을 직접 목격했습니다. 그것은 원래 범용 백엔드 (universal back-end) 작업, 즉 하나 이상의 채널에서 사용할 수 있는 단일 고객 수정 인터페이스로 설계되었습니다. 하지만 실제로는 계약 (contract)이 특정 프론트엔드 (front end)의 가정 (assumptions)을 중심으로 점차 형성되었습니다. 입력 모델 (input model)에는 오직 그 프론트엔드만이 접근할 수 있는 필드들만 포함되었고, API 자체에 존재하는 컨텍스트 (context)보다는 화면 흐름 (screen flow)에 존재하는 컨텍스트에 의존했습니다.

그 결과, 외부에서 보기에는 여전히 범용적으로 보이는 API였지만, 다른 어디에서도 안전하게 호출할 수 없는 API가 되었습니다. 계약 (contract)이 첫 번째 소비자의 가정 (assumptions)을 흡수해 버린 것입니다.

바로 이 지점에서 깔끔해 보이던 API들이 갑자기 취약해집니다. 좁은 의미에서 설계가 잘못되었기 때문이 아니라, 공유된 가정 (shared assumptions)의 관계 안에서 설계되었기 때문입니다. 에이전트 (agents)는 그 관계를 약화시킵니다.

오픈 API (Open APIs)는 다른 영역의 전문 분야입니다

어떤 호출자라도 안전하게 사용할 수 있는 API를 설계하는 것은 애플리케이션 백엔드 (application backend)를 구축하는 것과는 다릅니다.

그 차이는 단순히 문서화 (documentation)의 문제가 아닙니다. 그것은 계약 (contract)의 명시성 (explicitness) 수준에 있습니다. 진정한 오픈 API (open API)는 스스로 더 많은 의미를 담고 있어야 합니다. 단순히 구현의 편의성이 아니라 비즈니스 의도 (business intent)를 반영하는 작업 이름 (operation names)이 필요합니다. 원래의 클라이언트 외부에서도 안정적이고 이해 가능한 페이로드 (payloads)가 필요합니다. 예측 가능한 동작 (predictable behaviour), 명확한 실패 모드 (failure modes), 좁은 권한 (narrow authority), 그리고 숨겨진 시퀀스 (hidden sequence)나 주변 UI 로직에 대한 최소한의 의존성이 필요합니다.

다시 말해, API는 스스로 독립적으로 존재할 수 있어야 합니다.

이는 애플리케이션의 내부 작동 방식을 노출하는 것보다 플랫폼 표면 (platform surface)을 구축하는 것에 훨씬 가깝습니다. 이는 더 어려운 작업이며, 진정으로 재사용 가능한 API가 대부분의 조직이 인정하고 싶어 하는 것보다 더 희귀한 이유 중 하나입니다.

우리는 종종

그런 일이 발생하면, 그 부담은 API 계약 (API contract)으로 옮겨갑니다. 계약은 오용을 방지하거나 안전하게 실패할 수 있을 만큼 충분히 예측 가능하고, 명시적이며, 범위가 좁아야 합니다.

이 지점에서 흔히 발생하는 약점들이 훨씬 더 눈에 띄게 됩니다. 모호한 이름이 더 중요해집니다. 과부하된 엔드포인트 (Overloaded endpoints)가 더 중요해집니다. 느슨한 스키마 (Loose schemas)가 더 중요해집니다. 광범위한 보안 모델이 더 중요해집니다. 이것들은 항상 아키텍처 (Architecture) 상의 문제였지만, 인간 개발자들은 종종 판단력, 로컬 지식, 그리고 테스트를 통해 이를 보완해 왔습니다. 에이전트 (Agents)는 그러한 안전망의 상당 부분을 제거합니다.

실제로 변하는 것

이 변화는 "API 대 에이전트"가 아닙니다. 그것은 잘못된 프레임워크 (Framing)입니다.

진정한 변화는 정적 통합 (Static integration)에서 동적 구성 (Dynamic composition)으로의 전환입니다. 알려진 서비스 세트를 알려진 순서로 호출하는 사전 정의된 워크플로우 (Workflow) 대신, 이제 우리는 도구의 선택이 런타임 (Runtime)에 이루어질 수 있는 시스템을 갖게 되었습니다. 오케스트레이션 계층 (Orchestration layer)은 더 유연해지지만, 실행 계층 (Execution layer)은 여전히 실제 작업을 수행해야 합니다.

그 실행 계층은 여전히 API, 서비스, 데이터 저장소 (Data stores), 큐 (Queues), 그리고 이벤트 스트림 (Event streams)입니다. 에이전트의 어떤 점도 이러한 책임들을 사라지게 만들지 않습니다. 오히려 에이전트는 이러한 인터페이스의 품질을 더 중요하게 만듭니다. 왜냐하면 시스템 동작의 더 많은 부분이 이제 이러한 인터페이스를 안전하게 이해하고 구성할 수 있는지 여부에 달려 있기 때문입니다.

이것이 바로 대체 서사가 오해를 불러일으키는 이유입니다. 그 서사는 에이전트 프레임워크 (Agent framework)에만 주의를 집중시키지만, 더 중요한 질문은 그 아래의 시스템들이 원래 애플리케이션의 가정을 따르지 않고 작동하는 무언가에 의해 호출되기에 적합한가 하는 점입니다.

불편한 결론

에이전트는 아키텍처를 우회하는 지름길이 아닙니다.

그들은 강제 함수 (Forcing function)입니다.

그들은 우리가 취약한 API 설계, 제대로 정의되지 않은 데이터 경계, 일관성 없는 계약, 그리고 잘 작동하는 호출자 (Caller)에 너무 과도하게 의존했던 보안 가정들에 직면하도록 강제합니다. 에이전트는 알려진 클라이언트에게 작동하는 API와, 일반적인 기능으로서 안전하게 사용될 수 있는 API 사이의 차이를 드러냅니다.

에이전트 중심의 시스템 (agentic systems)이 데모 단계를 넘어 실제 기업 환경 (enterprise environments)으로 이동함에 따라, 그 차이는 더욱 중요해질 것입니다.

만약 당신이 에이전트 중심의 세상을 위해 무언가를 구축하고 있다면, 우선순위는 에이전트 프레임워크 (agent framework)가 아닙니다. 그것의 배후에 있는 실행 계층 (execution layer)입니다.

에이전트는 API를 대체하지 않기 때문입니다. 에이전트는 해당 API들이 실제로 얼마나 좋은지, 혹은 나쁜지를 무시하는 것을 불가능하게 만듭니다.

하지만 API가 여전히 중심적인 역할을 유지하더라도, 우리가 그것들을 설계하는 방식은 무너지기 시작하고 있습니다. 우리는 이전에 그러한 패턴을 본 적이 있으며, 그 교훈은 현재의 에이전트 물결보다 더 오래되었습니다. 그것은 서비스 지향 아키텍처 (SOA)에서 시작됩니다.