대시보드는 죽었다 — 에이전트 경험(AX)이 새로운 UX다

URL: https://www.youtube.com/watch?v=YiFqcu9YA38
날짜: 2026-10-04
채널: aiDotEngineer
발표자: Sarah Simionescu, Composio

---

📌 핵심 질문 / 대시보드 다음의 인터페이스

==사용자가 도구의 화면과 쿼리 언어를 직접 조작하는 시대는 끝나고, 목표를 받은 에이전트가 필요한 도구를 찾아 계획하고 실행하는 에이전트 경험(Agent Experience, AX)의 시대가 열린다.==

• 대시보드와 애플리케이션별 쿼리 언어는 사람이 데이터 시스템의 의도를 번역해 주던 중간 계층이었다.
• LLM의 자연어 쿼리 생성은 번역 작업을 줄였지만, 여러 데이터베이스와 여러 애플리케이션을 넘나드는 계획·기억·도구 선택 문제를 해결하지 못했다.
• MCP(Model Context Protocol)는 에이전트와 서비스 사이에 문을 열었지만, 서비스별 서버가 고립된 방이 되는 문제를 남겼고, Composio는 검색·계획·실행을 하나의 에이전트용 인터페이스로 묶으려 한다.

사람에게 쉬운 제품을 만드는 것만으로는 충분하지 않다. 앞으로의 제품은 눈이 없고 목표와 도구만 가진 에이전트가 실제 일을 끝낼 수 있도록 설계되어야 한다.

1. Datadog 대시보드에서 시작한 고백

Sarah Simionescu는 6개월 동안 매일 Datadog을 사용했지만, 정작 대시보드를 제대로 본 적은 없었다는 경험으로 논의를 시작한다.

1.1. 매일 쓴 도구를 열자 얼어붙은 이유

1. 동료의 알림 확인 요청

   1. 동료가 Sarah에게 Datadog 알림을 보여 달라고 부탁했고, Sarah는 괜찮다고 답했다.
   2. 다른 사람이 자신의 화면을 지켜보는 상황에서 조심스러웠던 Sarah는 Datadog을 열기 전에 로그아웃했다가 다시 들어가야 했다.

2. 대시보드의 낯섦

   1. Datadog 대시보드를 열자 화면이 멈춘 것처럼 느껴졌고, 어디에 무엇이 있는지 전혀 떠오르지 않았다.
   2. Datadog의 문제가 아니라, Sarah가 매일 Datadog을 사용하면서도 컨트롤 패널을 한 번도 직접 열어 보지 않았기 때문에 생긴 문제였다.

1.2. “컨트롤 패널은 죽었다”는 선언

1. 뜻밖의 결론

   1. Sarah는 다소 미친 소리처럼 들리지만 곧 명백해질 주장을 하겠다고 예고했다.
   2. 그 주장은 “컨트롤 패널은 죽었다(The control panel is dead)”라는 선언이다.

2. 선언의 아이러니

   1. 컨트롤 패널의 죽음은 방 안의 거의 모든 사람에게 좋은 소식이다.
   2. Sarah의 팀은 바로 그 대시보드를 만드는 일을 맡고 있으므로, 그 소식은 Sarah에게만은 그다지 반갑지 않다.

2. 2022년의 ‘도구를 직접 조작하는’ 개발 흐름

대시보드의 부검은 Slack 한 통으로 시작되는 2022년의 개발자 업무를 되짚는 방식으로 진행된다.

2.1. 프로덕션 오류 하나에 필요한 다섯 개의 화면

1. Slack에서 시작한 문제

   1. 동료가 Slack으로 “프로덕션(prod)을 찾으려는데 오류가 난다”고 핑을 보낸다.
   2. Sarah는 문제를 풀기 위해 단순한 답변 하나가 아니라 여러 시스템을 이어 붙여야 한다.

2. 다섯 도구의 연쇄 작업

   1. Slack에서 대화 맥락을 읽고, Datadog에서 쿼리를 작성한다.
   2. PostHog에서 세션을 확인하고, VS Code에서 버그를 수정한다.
   3. GitHub에서 풀 리퀘스트(Pull Request, PR)를 열어야 한다.
   4. 다섯 도구와 다섯 인터페이스를 각각 익혀야 하며, 각 서비스가 새 디자인을 출시할 때마다 사용법을 다시 배워야 한다.

2.2. 인터페이스보다 더 큰 장벽인 쿼리 언어

1. 서비스마다 다른 검색 문법

   1. Datadog에는 자체 쿼리 구문이 있다.
   2. Jira에는 JQL(Jira Query Language) 검색이 있고, Slack에는 고유한 검색 수정자(search modifiers)가 있다.

2. SQL조차 공유되지 않는 의미

   1. 여러 도구가 SQL처럼 같은 언어를 쓴다고 주장해도 SQL에 대한 의견과 동작 방식은 서로 다르다.
   2. 대시보드와 낯선 쿼리 언어는 모두 사용자와 데이터 사이의 번역 수단이었다. 데이터 반대편의 기계가 사용자가 진짜 원하는 것을 이해하지 못했기 때문이다.

3. 사용자가 원한 것

   1. 사용자는 툴바나 빌어먹을 쿼리 언어를 원한 것이 아니라 답을 원했다.
   2. 화면을 이동하고 문법을 기억하는 과정은 답에 도달하기 위한 비용일 뿐, 목적 자체가 아니었다.

3. 2023년의 반짝이 버튼과 2024년의 MCP

LLM과 MCP는 도구 조작 비용을 줄였지만, 자연어만으로 복잡한 업무를 안정적으로 완성하는 일은 별개의 문제로 남았다.

3.1. 2023년, 반짝이 버튼의 등장

1. 한 번의 클릭으로 쿼리 만들기

   1. 2023년에 ‘반짝이 버튼(shine button)’이 등장했고, 사용자는 마법 같은 버튼을 한 번 누를 수 있게 됐다.
   2. LLM은 사용자의 질문에 맞는 쿼리를 때때로 작성해 주었다.

2. 아직 좁은 범위의 자동화

   1. 질문이 두 개를 넘는 데이터베이스 연결을 요구하지 않을 때에야 원하는 답을 얻을 수 있었다.
   2. 반짝이는 버튼은 곧 곳곳에 퍼졌고, 툴바는 AI 제품의 기본 요소가 됐다.

3.2. 2024년 11월, MCP가 연 문

1. 개방형 연결 표준

   1. Anthropic은 2024년 11월 MCP(Model Context Protocol)를 발표했다.
   2. MCP는 AI 시스템을 데이터 소스에 연결하는 개방형 표준을 만들겠다는 약속이었다.

2. 에이전트가 대신 실행하는 흐름

   1. 사용자가 매일 쓰는 Claude 에이전트가 요청을 만들고, 사용자를 대신해 서비스에서 실행한 뒤, 답을 직접 제공할 수 있게 됐다.
   2. 반짝이 버튼을 사용자가 직접 누르는 대신 Claude가 요청·실행·응답의 흐름을 맡는 셈이다.

4. MCP만으로는 해결되지 않는 세 가지 문제

MCP는 에이전트와 서비스가 통신할 수 있는 채널이지, 에이전트가 여러 서비스에서 일을 완수하는 방법 자체는 아니다.

4.1. MCP의 본질과 서비스의 책임

1. 프로토콜은 통신 채널이다

   1. MCP는 에이전트와 서비스 사이의 통신을 위한 프로토콜이다.
   2. 에이전트에게 어떤 방식으로 말할지는 각 서비스가 결정해야 한다.

2. 서버를 여러 개 연결했을 때 드러나는 현실

   1. MCP 서버를 12개쯤 연결해 본 사람이라면, 연결 자체와 실제 업무 완수 사이에 큰 간극이 있음을 알게 된다.
   2. 그 간극은 에이전트의 학습 부재, 컨텍스트 과부하, 애플리케이션 고립이라는 세 가지 문제로 나타난다.

4.2. 첫 번째 문제: 에이전트는 학습하지 않는다

1. 매 대화가 백지에서 시작된다

   1. 모든 대화는 처음부터 시작되고, 에이전트는 이전에 배운 사용법을 기억하지 못한다.
   2. 전날 Slack 링크를 올바르게 포맷하는 방법을 알려 줬어도, 다음 날 같은 실수가 반복될 수 있다.

2. 스킬은 임시 처방이다

   1. 이 문제를 스킬(skills)로 고칠 수 있지만, 스킬은 근본 치료가 아니라 반창고에 가깝다.
   2. 더 많은 도구와 스킬을 넣을수록 컨텍스트가 커지고, 에이전트는 오히려 더 둔해진다.

4.3. 두 번째 문제: 도구 정의가 컨텍스트를 가라앉힌다

1. 도구가 많을수록 선택이 어려워진다

   1. 더 많은 도구와 스킬을 연결하면 수천 개의 도구 정의(tool definitions)가 컨텍스트 윈도우 안으로 들어온다.
   2. Composio의 GitHub와 비슷한 툴킷에는 200개가 넘는 도구가 있고, 모델은 그 앞에서 가라앉는다.

2. 잘못된 도구와 의존성 문제

   1. 모델은 잘못된 도구를 선택할 수 있다.
   2. 여러 도구 사이의 의존성을 해결하려다 무엇을 먼저 호출해야 하는지 결정하지 못할 수 있다.

4.4. 세 번째 문제: 애플리케이션이 고립된다

1. 각 MCP 서버의 좁은 시야

   1. 각 MCP 서버는 자기 애플리케이션만 알고 다른 애플리케이션은 알지 못한다.
   2. 실제 업무가 두 애플리케이션을 넘나들면, 둘을 이어 붙이는 책임은 다시 사용자에게 돌아온다.

2. 지도 없는 수천 개의 방

   1. MCP는 에이전트에게 모든 별관으로 통하는 문을 열어 줬다.
   2. 하지만 에이전트는 지도도 없고 그곳에 와 본 기억도 없는 채 수천 개의 분리된 방에 서 있게 됐다.

5. 2026년의 버그 리포트 처리: 목표에서 수정 PR까지

Composio MCP는 애플리케이션별 도구 목록을 나열하는 대신, 목표를 분석하고 필요한 도구와 사용 순서를 찾아 실행하는 흐름을 제시한다.

5.1. 자연어 목표와 Composio 검색

1. 문제의 출발점

   1. Claude가 Composio MCP에 연결된 화면을 가정한다.
   2. 사용자는 Slack 문제 메시지의 링크를 복사해 붙여 넣고 다음과 같이 지시한다: “Sentry와 Datadog을 사용해서 근본 원인을 찾고, 초안 PR을 만들어 줘. 실수하지 마.”

2. 첫 호출은 도구 실행이 아니라 검색이다

   1. Claude는 가장 먼저 Composio의 검색(search)을 호출해 수행해야 할 작업을 구체화한다.
   2. 요청의 작업은 Slack 메시지 가져오기, Sentry 이슈 살펴보기, Datadog 로그 확인하기라는 세 가지로 분해된다.

5.2. 도구와 실행 계획을 함께 받기

1. 필요한 도구 이상의 응답

   1. Composio는 세 작업 각각에 필요한 도구만 반환한다.
   2. 필요한 도구 목록과 함께 그 도구를 어떤 순서와 방식으로 써야 하는지에 대한 계획도 반환한다.

2. Slack의 숨은 선행 조건

   1. Slack 메시지를 요청하려면 먼저 Slack 채널 ID를 찾아야 한다.
   2. 이런 선행 조건까지 포함된 컨텍스트가 있어야 Claude가 처음부터 올바른 계획을 세울 수 있다.

5.3. 병렬 조사와 5분 이내의 수정

1. 계획에 따른 조사

   1. Claude는 Slack에서 사용자 불만의 맥락을 확인할 메시지를 가져온다.
   2. Datadog과 Sentry에서 데이터를 병렬로 가져오는 동시에 코드베이스를 스캔한다.

2. 업무 완결

   1. 근본 원인을 식별하면 5분 이내에 수정 사항을 발행한다.
   2. 사용자는 이 작업을 위해 별도의 워크플로를 만들거나 방법을 가르치는 스킬을 작성하지 않아도 된다.

3. 사용 습관의 변화

   1. Claude가 Composio MCP를 사용해 처리하는 방식은 점점 근육 기억처럼 익숙해진다.
   2. 반대로 매일 열던 툴바는 점점 낯설어진다.

6. 에이전트를 위해 설계된 인터페이스

Composio의 차이는 MCP 연결 여부가 아니라 에이전트가 복잡한 업무를 발견하고 조합하고 실행하기 쉬운 인터페이스를 제공하는 데 있다.

6.1. 네이티브 MCP와의 비교

1. 초기 비교 결과

   1. Composio와 Claude Marketplace에 등록된 각 애플리케이션의 네이티브 MCP를 비교한 초기 결과가 제시된다.
   2. 같은 작업과 같은 모델을 사용했는데도 두 방식 사이에 뚜렷한 차이가 나타났다.

2. 수치 공개의 한계

   1. 비교 결과는 당시 공개되지 않은 초기 결과(early unpublished results)로 소개된다.
   2. 구체적인 성공률·시간·점수는 제시되지 않았지만, 네이티브 MCP 대비 에이전트 작업 경험의 차이가 명확하다는 점이 핵심이다.

6.2. Composio가 만드는 통합 계층

1. 에이전트를 위한 새 인터페이스

   1. Composio는 에이전트를 위해 특별히 설계된 완전히 새로운 인터페이스를 개발한다.
   2. 매일 쓰는 애플리케이션의 지저분하고 문서화가 부족하며 계속 변하는 API를 에이전트가 실제로 사용하기 좋아하는 형태로 바꾼다.

2. 기반 기술의 결합

   1. MCP, CLI(Command-Line Interface), 네이티브 도구 위에 구축한다.
   2. 여러 애플리케이션에서 복잡한 작업을 매끄럽게 수행할 수 있도록 전체적이고 통합된 에이전트 경험을 제공한다.

7. 사용자 분석 사례: PostHog와 Metabase를 넘나드는 질문

대시보드에서 차트를 찾아 읽는 대신, 자연어 목표가 여러 데이터 소스를 연결한 분석과 결과 해석으로 이어진다.

7.1. 온보딩 업종 분포 조회

1. 질문으로 시작하기

   1. Sarah는 온보딩 과정에서 사용자가 선택한 업종(vertical)의 분포를 보고 싶다고 Claude에게 묻는다.
   2. 별도의 화면을 찾아 들어가거나 쿼리 문법을 직접 기억하지 않고 자연어로 분석 목표를 전달한다.

2. PostHog 쿼리 실행

   1. Claude는 다시 Composio 검색을 실행한다.
   2. PostHog에 쿼리를 작성하고, 이를 실행한 뒤 결과를 돌려준다.

7.2. 전자상거래 사용자와 선호 툴킷 분석

1. 질문의 확장

   1. 분석 범위를 전자상거래(e-commerce) 섹션으로 좁히고, 그 사용자들이 어떤 툴킷(toolkit)을 즐겨 사용하는지 확인한다.
   2. 화면의 용어로 툴킷은 애플리케이션을 뜻하며, Composio는 애플리케이션을 툴킷이라고 부른다.

2. 서로 다른 소스의 조인

   1. Claude는 PostHog의 사용자 ID를 바탕으로 Metabase에서 데이터를 가져오는 방법을 스스로 판단한다.
   2. Composio 검색을 다시 사용해 PostHog에서 전자상거래에 옵트인한 사용자의 ID를 요청한다.

3. 컨텍스트를 보존하는 데이터 처리

   1. 사용자 ID 전체 결과를 컨텍스트에 불러오지 않고 저장한다.
   2. Metabase에서 데이터베이스 스키마를 확인하고, 필요한 데이터를 선택하고, 구조를 파악하기 위해 몇 개의 쿼리를 실행한다.

4. Remote Workbench의 동적 쿼리 생성

   1. Claude가 충분한 확신을 얻으면 Composio Remote Workbench를 사용한다.
   2. Remote Workbench는 정규식 문자열(regular expression string)을 포함한 SQL 쿼리를 동적으로 생성해 앞서 얻은 사용자 ID를 다시 조회한다.
   3. 전체 사용자 ID 목록을 컨텍스트 윈도우에 넣지 않아도 되므로 컨텍스트를 작게 유지한다.

5. 몇 분 안에 얻는 결론

   1. PostHog와 Metabase 두 소스의 데이터를 결합해 해당 사용자 페르소나가 가장 많이 사용하는 툴킷을 확인한다.
   2. 결과를 얻는 데 걸리는 시간은 몇 분도 채 되지 않는다.
   3. 현장에서 직접 사용해 보고 싶다면 Composio 부스에 방문해 라이브 버전을 플레이해 볼 수 있다.

8. 대시보드 이후의 제품 설계

대시보드가 사라진다는 주장은 웹사이트의 문구를 AI 친화적으로 바꾸는 수준을 넘어, 실제 애플리케이션의 사용 계약을 에이전트 중심으로 다시 설계하라는 요구다.

8.1. GEO와 실제 에이전트 사용성의 차이

1. 랜딩 페이지의 변화

   1. 많은 스타트업이 GEO(Generative Engine Optimization) 목적을 위해 랜딩 페이지와 웹사이트를 AI 친화적으로 만들기 시작했다.
   2. 검색·생성 시스템이 페이지를 잘 읽도록 만드는 것과, 에이전트가 제품 안에서 실제 일을 처리하도록 만드는 것은 다른 문제다.

2. 애플리케이션 준비 부족

   1. 웹페이지를 AI가 읽을 수 있게 만든 회사는 많지만, 에이전트가 애플리케이션을 사용할 수 있게 준비한 회사는 아직 적다.
   2. 애플리케이션 내부 API, 권한, 도구 정의, 작업 순서까지 에이전트가 다룰 수 있어야 한다.

8.2. Composio가 발견한 새로운 수요

1. 개발자 도구에서 에이전트 도구로

   1. Composio는 개발자를 돕는 도구로 출발했다.
   2. 사용자가 사랑하는 인기 애플리케이션을 에이전트가 사용할 수 있는 도구로 바꾸는 일을 해 왔다.

2. 고객의 직접적인 요구

   1. 사람들은 대시보드에 지쳤고, 에이전트는 형편없이 설계된 MCP 서버에 지쳤다.
   2. 이제 고객이 자신의 서비스를 에이전트를 통해 사용하게 해 달라고 요청하는 스타트업이 Composio에 찾아온다.

8.3. 새로운 사용자: 눈이 없는 에이전트

1. 사용자 정의의 변화

   1. 지금 제품을 만드는 사람은 새로운 유형의 사용자를 섬기게 된다.
   2. 에이전트에게는 눈이 없으므로 반짝이 버튼을 누르지 않는다.

2. 에이전트의 평가 기준

   1. 에이전트는 목표와 도구 세트를 가지고 나타난다.
   2. 에이전트가 제품을 평가하는 기준은 오직 일을 끝낼 수 있는가 여부다.

3. 다음 시대의 경쟁력

   1. 지난 10년 동안 제품 팀은 사람이 쉽게 사용할 수 있는 제품을 만들어 왔다.
   2. 다음 시대는 에이전트가 쉽게 사용할 수 있는 제품을 만드는 팀의 몫이다.

주요 발언 모음

“컨트롤 패널은 죽었다. 그리고 그건 모두에게 좋은 소식이다. 아마 내 팀만 빼고.”

“사용자는 툴바나 빌어먹을 쿼리 언어를 원한 게 아니다. 답을 원했다.”

“MCP는 모든 별관으로 통하는 문을 열어 줬지만, 에이전트를 지도도 없고 그곳에 와 본 기억도 없는 수천 개의 방에 세워 두었다.”

“그녀는 목표와 도구 세트를 가지고 나타나며, 일을 끝낼 수 있는지라는 한 가지 기준으로만 당신을 평가한다.”

“지난 10년은 사람이 사용하기 쉬운 제품을 만드는 시대였다. 다음 시대는 에이전트가 사용하기 쉬운 제품을 만드는 사람들의 것이다.”

핵심 데이터 & 수치

• 6개월: Sarah가 Datadog을 매일 사용했지만 대시보드를 제대로 열어 보지 않았던 기간이다.
• 2022년: Slack·Datadog·PostHog·VS Code·GitHub를 오가며 프로덕션 오류를 처리하던 개발 흐름의 시점이다.
• 5개 도구·5개 인터페이스: 하나의 오류를 처리하기 위해 거쳐야 했던 도구와 화면의 수다.
• 2개 데이터베이스 연결: 2023년 반짝이 버튼이 원하는 쿼리를 만들 수 있었던 대략적인 한계다.
• 2024년 11월: Anthropic이 MCP를 발표한 시점이다.
• 12개 MCP 서버: 여러 서버를 연결했을 때 학습 부재·컨텍스트 과부하·애플리케이션 고립 문제가 현실화되는 예시다.
• 200개 이상 도구: Composio의 GitHub와 비슷한 툴킷이 가진 도구 규모로, 모델이 올바른 도구 선택에 어려움을 겪는 이유다.
• 5분 이내: Slack·Sentry·Datadog·코드베이스를 함께 조사한 뒤 근본 원인 수정 사항을 발행하는 목표 시간이다.
• 몇 분 이내: PostHog의 전자상거래 사용자 ID와 Metabase 데이터를 결합해 인기 툴킷을 확인하는 데 걸리는 시간이다.
• 공개되지 않은 초기 비교 결과: Composio와 애플리케이션별 네이티브 MCP를 같은 작업·같은 모델로 비교했으며, 구체적인 성공률이나 점수는 공개되지 않았다.

결론 및 시사점

1. 제품의 핵심 인터페이스를 다시 정의하라

   1. 대시보드와 툴바를 더 화려하게 만드는 것보다, 에이전트가 목표를 이해하고 필요한 도구를 발견하게 하는 일이 중요하다.
   2. 사용자가 직접 조작하던 화면은 에이전트가 대신 수행할 작업의 계약과 계획으로 대체된다.

2. MCP 연결만으로는 충분하지 않다

   1. 개방형 프로토콜은 연결을 제공할 뿐이며, 기억·도구 선택·다중 애플리케이션 조정은 별도로 해결해야 한다.
   2. 검색, 선행 조건 파악, 실행 계획, 병렬 호출, 컨텍스트 절약을 하나의 경험으로 설계해야 한다.

3. 에이전트용 API를 제품의 기본 산출물로 삼아라

   1. 불안정하고 문서화가 부족한 API를 에이전트가 호출하기 쉬운 도구와 계획으로 바꿔야 한다.
   2. 권한, 스키마 탐색, 결과 저장, 데이터 간 연결, 오류 복구까지 에이전트가 일을 끝내는 경로를 설계해야 한다.

4. 평가 지표를 ‘완료 여부’로 이동하라

   1. 에이전트 사용자는 버튼을 얼마나 쉽게 찾았는지가 아니라 목표한 작업을 실제로 끝냈는지를 평가한다.
   2. Composio와 네이티브 MCP 비교처럼 동일한 모델·동일한 작업에서 성공률, 계획의 정확성, 완료 시간, 컨텍스트 사용량을 측정해야 한다.

5. Datadog에서 얼어붙은 순간을 미래의 신호로 읽어라

   1. 사람이 매일 쓰던 대시보드 앞에서 길을 잃는 현상은 사용자가 화면을 사랑해서가 아니라 결과를 얻기 위해 화면을 참아 왔다는 증거다.
   2. Sarah는 그 순간을 뒤처지고 있다는 신호로 느꼈지만, 이제는 다가올 에이전트 중심 제품 시대의 예고편으로 해석한다.

청중 질문과 답변 없이 “Thank you”라는 인사로 마무리되며, 대시보드의 죽음은 화면의 즉각적인 삭제가 아니라 에이전트가 일을 완수하는 새로운 인터페이스로의 이동을 뜻한다.

핵심 요약 (20줄)

Sarah Simionescu는 6개월 동안 매일 Datadog을 썼지만 대시보드 앞에서 어디를 눌러야 할지 몰랐던 경험을 털어놓는다. Datadog 대시보드가 멈춘 것이 아니라 매일 쓰면서도 컨트롤 패널을 직접 익히지 않았던 사용 방식이 문제였다. 컨트롤 패널의 죽음은 대시보드를 만드는 팀을 제외한 모두에게 좋은 소식이라는 아이러니를 만든다. 2022년 프로덕션 오류 하나를 해결하려면 Slack, Datadog, PostHog, VS Code, GitHub를 오가야 했다. 다섯 도구는 각자의 인터페이스와 쿼리 언어를 요구해 개발자가 사용법을 계속 다시 배우게 만들었다. 대시보드와 쿼리 언어는 기계가 사용자의 의도를 이해하지 못해 생긴 번역 계층이었다. 사용자가 원한 것은 툴바나 쿼리 문법이 아니라 데이터에서 얻는 답이었다. 2023년의 반짝이 버튼은 LLM으로 쿼리를 만들었지만 두 개를 넘는 데이터베이스 연결에는 약했다. Anthropic은 2024년 11월 MCP를 AI와 데이터 소스를 연결하는 개방형 표준으로 발표했다. MCP는 에이전트와 서비스 사이의 통신 채널을 열었지만 복합 업무의 계획까지 자동으로 제공하지는 않았다. 에이전트는 대화를 기억하지 못하고 도구와 스킬이 늘수록 컨텍스트 과부하로 더 둔해진다. 각 MCP 서버가 자기 애플리케이션만 알기 때문에 여러 서비스가 필요한 업무는 여전히 사용자가 이어 붙여야 한다. Composio MCP는 Slack 링크에서 시작해 Sentry, Datadog, 코드베이스를 조사할 도구와 실행 계획을 찾는다. Claude는 Slack 채널 ID 같은 선행 조건을 파악하고 Datadog과 Sentry를 병렬로 조사한다. 근본 원인이 발견되면 별도 워크플로와 스킬 없이 5분 이내에 수정 PR을 만들 수 있다. Composio는 MCP, CLI, 네이티브 도구 위에 에이전트가 좋아하는 통합 인터페이스를 구축한다. PostHog의 사용자 ID와 Metabase 스키마를 결합하면 전자상거래 사용자의 인기 툴킷을 몇 분 안에 확인할 수 있다. Remote Workbench는 전체 사용자 ID를 컨텍스트에 넣지 않고 정규식이 포함된 SQL을 동적으로 생성한다. 제품 팀은 GEO용 웹사이트를 넘어 에이전트가 애플리케이션 안에서 실제 일을 끝내도록 설계해야 한다. 다음 시대의 경쟁력은 사람이 아니라 목표와 도구를 가진 에이전트가 쉽게 사용할 수 있는 제품을 만드는 데 있다.