지금까지 API를 AI 에이전트에 연결하려면 꽤 번거로운 절차가 필요했다. MCP 서버를 별도로 구축하고, API 스키마가 바뀔 때마다 싱크를 맞추고, 에이전트가 이해할 수 있는 tool definition을 손으로 작성해야 했다. 이 과정에서 발생하는 마찰은 생각보다 컸다. 결국 대부분의 API는 AI 에이전트에게 '보이지 않는 존재'로 남았다—인간은 알고 있지만 에이전트는 발견할 수도, 호출할 수도 없는 REST 엔드포인트로.
APIKumo는 이 구조적 마찰을 아예 없애버리는 접근을 택했다. 컬렉션을 publish하는 순간, 자동으로 MCP 엔드포인트가 생성된다. 별도 서버도, 별도 설정도, 유지보수할 코드도 없다. 문서 페이지·AI 채팅·MCP 엔드포인트가 모두 동일한 소스에서 파생되므로 스키마를 업데이트하면 MCP 엔드포인트도 즉시 반영된다. 날씨 API를 예로 들면, GET /forecast 같은 엔드포인트를 파라미터와 응답 스키마, 인증 방식까지 포함해 Claude나 Cursor 같은 MCP 호환 클라이언트가 즉시 discover하고 호출할 수 있다. 'AI-ready docs'의 진짜 의미가 여기 있다—보기 좋은 페이지가 아니라 에이전트가 읽고 행동할 수 있는 surface.
프론트엔드·풀스택 개발자 관점에서 이 변화는 단순한 편의 기능이 아니다. 지금까지 우리가 API를 'Claude에게 설명'하려면 시스템 프롬프트에 엔드포인트 목록을 붙여넣거나, function calling용 schema를 직접 작성해야 했다. MCP가 표준으로 자리잡으면 이 과정이 사라진다. 내가 만든 API 컬렉션 자체가 에이전트의 tool로 즉시 전환된다. 이것은 개발 워크플로우의 추상화 계층이 하나 올라가는 것이다—API를 설계하는 것이 곧 에이전트 capability를 설계하는 것과 같아지는 시대.
그런데 MCP가 해결하지 못하는 지점이 있다. dev.to에 게재된 Ingero의 분석이 이를 정확하게 짚는다. MCP는 '에이전트가 무엇을 했는가(what)'를 잘 답하지만, '왜 시스템이 그렇게 동작했는가(why)'는 답하지 못한다. 실제 사례를 보면 이 차이가 얼마나 결정적인지 드러난다. vLLM 추론 클러스터에서 TTFT(첫 토큰 응답 시간)가 200ms에서 11초로 치솟는 장애가 발생했을 때, Grafana MCP는 '그 시간대에 요청량 변화 없이 GPU 사용률 96%, TTFT 급등'이라는 what을 정확히 짚어냈다. 하지만 GPU가 '바쁜 척'하면서 실제로 처리량이 무너진 이유—vLLM 엔진 스레드가 토크나이저 워커와의 futex 경합으로 CPU에서 쫓겨나고 있었다는 사실—은 커널 레벨 데이터 없이는 절대 보이지 않는다.
여기서 eBPF가 등장한다. eBPF는 libcudart.so, libcuda.so에 uprobes를 외부에서 직접 붙여 모든 CUDA 호출을 프레임워크 무관하게 추적하고, sched_switch 같은 스케줄러 tracepoint로 어떤 프로세스가 CPU를 선점했는지까지 본다. Ingero의 eBPF 기반 MCP 서버를 Grafana MCP와 같은 Claude Code 세션에 동시에 연결했을 때, 에이전트는 두 MCP를 순차적으로 호출하며 스스로 원인을 종합했다. 결론: vLLM 엔진 스레드를 taskset이나 cgroup cpuset으로 격리하면 해결된다. 사람이 각 레이어를 따로 뒤지던 작업을 에이전트가 두 MCP를 오가며 단일 대화 안에서 완결한 것이다.
이 두 사례가 함께 가리키는 시사점은 명확하다. MCP는 단일 만능 프로토콜이 아니라 '레이어드 컨텍스트 아키텍처'의 인터페이스다. 애플리케이션 계층의 what-MCP와 커널 계층의 why-MCP를 조합하면, 에이전트는 단순 조회를 넘어 실제 문제 해결까지 수행할 수 있는 reasoning chain을 구성할 수 있다. 프론트엔드 개발자에게도 같은 원리가 적용된다—사용자 행동 데이터를 노출하는 analytics MCP와 렌더링 성능 트레이스를 노출하는 performance MCP를 조합하면, AI 에이전트가 Core Web Vitals 저하 원인을 스스로 추적하는 워크플로우가 가능해진다.
불과 열흘 사이에 Grafana, AWS Bedrock AgentCore, DBmaestro 등 8개 관찰성·보안 플랫폼이 MCP 서버를 출시했다는 사실은 프로토콜 수렴의 신호다. 지금은 what-layer MCP가 먼저 채워지고 있고, why-layer MCP가 그 뒤를 잇고 있다. 앞으로 우리가 설계할 API와 내부 도구는 '사람이 읽는 문서'와 '에이전트가 호출하는 MCP 엔드포인트'를 동시에 염두에 두어야 한다. API 설계가 곧 에이전트 capability 설계가 되는 시대에, 이 두 레이어를 어떻게 쌓아 올리느냐가 개발 워크플로우의 다음 경쟁 지점이 될 것이다.