대시보드는 끝났다: AI 에이전트가 소프트웨어를 쓰는 법

URL: https://www.youtube.com/watch?v=5bg469hWGGc 날짜: 2026-10-10 채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==대시보드는 인간이 기계의 제약을 번역해 주던 인터페이스였고, AI 에이전트가 목표와 도구만으로 답을 실행하는 시대에는 에이전트 전용 인터페이스로 대체된다.==

• 인간은 답을 원했지만 Datadog·Jira·Slack·Sentry·VS Code·GitHub의 UI와 각기 다른 쿼리 언어를 오가며 답을 얻어야 했다.
• AI 버튼은 기존 대시보드 안에서 자연어를 쿼리로 바꾸었지만, 복잡한 작업과 여러 앱을 가로지르는 업무를 해결하지 못했다.
• MCP(Model Context Protocol)는 에이전트에게 각 앱으로 들어가는 문을 열었지만, 학습·기억의 부재, 도구 과부하, 앱 간 고립이라는 구조적 문제가 남았다.
• 에이전트 전용 인터페이스는 흩어진 API와 도구를 검색·계획·실행 가능한 하나의 경험으로 바꾸고, 앱 사이의 복합 작업을 연결해야 한다.

대시보드의 종말은 화면이 물리적으로 사라진다는 뜻이 아니라, 사용자가 목표를 달성하기 위해 화면과 쿼리 언어를 직접 조작하는 방식이 중심에서 밀려난다는 뜻이다. 사람은 더 이상 다섯 개의 창을 열어 번역 작업을 반복하지 않고, 에이전트는 목표를 받아 필요한 도구와 실행 순서를 찾아 결과를 만든다. 따라서 앞으로 소프트웨어의 품질은 사람이 UI를 쉽게 배우는지뿐 아니라 눈이 없는 에이전트가 목표를 얼마나 안정적으로 끝내는지로 평가된다.

1. 대시보드가 필요했던 이유와 한계

대시보드는 사람이 데이터 저장소와 서비스의 서로 다른 언어를 해석해 주는 번역 장치였지만, 사용자가 원하는 것은 대시보드가 아니라 답이었다.

1.1. Datadog 대시보드에 한 번도 들어가지 않은 사용자

1. 매일 쓰지만 열어 보지 않은 도구

   1. 6개월간의 습관: Sarah는 지난 6개월 동안 매일 Datadog을 사용했지만 대시보드를 직접 연 적은 한 번도 없었다.
   2. 당황스러운 순간: 동료가 알림(alert)을 함께 보자고 하자 Sarah는 Datadog을 열었고, 로그아웃된 상태라 다시 로그인해야 했다. 동료가 화면을 지켜보는 상황에서 컴퓨터의 모든 행동을 의식하게 됐다.

2. 익숙함의 착시

   1. 대시보드 앞에서의 정지: Sarah가 Datadog 대시보드를 열자 어디에 무엇이 있는지 전혀 알 수 없어 그대로 얼어붙었다.
   2. Datadog 자체의 잘못이 아님: 문제는 Datadog의 품질을 비난할 일이 아니라, 실제 사용이 매일 필요한 데이터 조회와 알림 확인에 한정돼 대시보드라는 UI를 배울 기회가 없었다는 데 있었다.

1.2. 2022년의 다섯 창과 다섯 언어

1. 버그 제보가 번역 업무로 변하는 과정

   1. Slack에서 시작하는 요청: 누군가 Slack으로 “prod를 검색하려고 하면 이런 에러가 난다”고 알려 오면, 답을 찾기 위해 먼저 Slack의 맥락을 읽어야 했다.
   2. 도구 다섯 개의 연쇄: Slack에서 맥락을 읽고, Datadog에서 쿼리를 쓰고, Sentry에서 이슈를 확인하고, VS Code에서 버그를 고치고, GitHub에서 PR을 여는 다섯 단계가 필요했다.

2. UI와 쿼리 언어의 파편화

   1. 재학습의 반복: 다섯 개 UI는 제품이 새로 디자인될 때마다 다시 익혀야 하며, 화면 재설계는 가장 큰 문제도 아니었다.
   2. 서비스마다 다른 문법: Datadog은 자체 쿼리 문법을 쓰고, Jira는 JQL(Jira Query Language)을 사용하며, Slack 검색은 별도의 검색 수식(modifier)을 사용한다.
   3. SQL조차 통일되지 않음: 여러 도구가 같은 언어를 쓴다고 주장해도 SQL처럼 보이는 언어의 세부 동작과 해석은 서로 달랐다.

3. 대시보드의 본질

   1. 번역 장치: 지금까지 사용한 모든 대시보드와 난해한 쿼리 언어는 기계가 사용자의 진짜 의도를 이해하지 못했기 때문에 사람과 데이터 사이를 번역하는 장치였다.
   2. 사람이 원한 것: 사람은 대시보드나 저주받은 쿼리 언어를 원한 것이 아니라, 질문에 대한 답을 원했다.

2. AI 버튼에서 MCP까지

자연어를 쿼리로 바꾸는 AI 버튼은 기존 UI의 부담을 줄였지만, 에이전트가 업무 전체를 끝내는 문제까지 해결하지는 못했다.

2.1. 2023년의 반짝이 버튼

1. 자연어 쿼리의 등장

   1. 클릭 한 번의 변화: 2023년에 등장한 ‘반짝이 버튼(sparkle button)’을 누르면 LLM이 질문에 필요한 쿼리를 작성했다.
   2. 불완전한 정확성: LLM이 작성한 쿼리는 때때로 맞았고, 사용자는 생성된 쿼리를 통해 답을 얻었다.

2. 복잡도에 따른 한계

   1. 두 개 조인까지의 농담 섞인 경계: 질문이 두 개 이상의 데이터베이스 조인(database join)을 필요로 하지 않을 때에야 반짝이 버튼이 제대로 작동한다는 한계가 있었다.
   2. AI 네이티브 대시보드의 착시: 반짝이 버튼이 모든 곳에 퍼지면서 대시보드는 AI 네이티브가 됐지만, 대시보드가 답을 직접 실행하는 문제는 여전히 남았다.

2.2. 2024년 MCP의 약속

1. 앱과 AI를 잇는 공개 표준

   1. Anthropic의 발표: 2024년 11월 Anthropic은 AI 시스템과 데이터 소스를 연결하기 위한 오픈 표준인 MCP를 발표했다.
   2. 에이전트의 직접 실행: 사용자가 이미 매일 쓰는 Claude 같은 에이전트가 쿼리를 생성하고, 사용자를 대신해 실행하고, 결과를 직접 전달할 수 있게 됐다.

2. 프로토콜만으로 끝나지 않는 이유

   1. 통신 채널일 뿐인 MCP: MCP는 에이전트와 서비스가 통신하는 프로토콜이자 채널이지, 서비스가 에이전트와 어떤 방식으로 소통해야 하는지까지 결정하지 않는다.
   2. 서비스 제공자의 책임: 실제 경험의 품질은 각 서비스가 에이전트에게 어떤 도구, 설명, 입력 형식, 실행 흐름을 제공하는지에 따라 달라진다.

3. MCP 서버가 복잡해지는 세 가지 구조적 이유

MCP는 각 앱으로 들어가는 문을 열었지만, 에이전트를 수천 개의 방에 지도와 기억 없이 세워 두는 결과를 만들 수 있다.

3.1. 첫째 문제: 에이전트는 스스로 배우지 않는다

1. 대화가 매번 처음부터 시작됨

   1. 기억의 부재: 에이전트는 모든 대화를 처음부터 시작하며, 어제 어떤 방식으로 Slack 링크의 서식을 망쳤는지 기억하지 못한다.
   2. 실수의 반복: 어제의 실패가 오늘의 행동에 반영되지 않으므로 같은 링크 서식 실수가 다시 발생한다.

2. Skills의 한계

   1. 패치로서의 Skills: 반복되는 절차를 Skills에 적어 넣는 방식은 문제를 덮는 반창고일 뿐, 에이전트가 실제로 학습한 것은 아니다.
   2. 컨텍스트 비용: Skills를 추가하면 도구 설명과 함께 더 많은 컨텍스트를 주입해야 하므로, 해결책이 새로운 부담으로 되돌아온다.

3.2. 둘째 문제: 도구와 컨텍스트의 과부하

1. 도구가 많을수록 모델이 둔해짐

   1. 역설적인 컨텍스트 효과: 더 많은 컨텍스트를 제공할수록 에이전트가 똑똑해지는 것이 아니라 오히려 멍청해질 수 있다.
   2. 정의의 홍수: 여러 서버를 연결하면 수천 개의 도구 정의(tool definition)가 모델의 컨텍스트 윈도우에 그대로 들어간다.

2. GitHub 예시

   1. 200개가 넘는 도구: GitHub 툴킷 하나만 해도 200개가 넘는 도구를 가진다.
   2. 잘못된 선택: 모델은 도구 목록에 파묻혀 잘못된 도구를 선택하거나, 여러 도구 사이의 의존성을 해결하지 못하고 어떤 도구를 먼저 호출해야 하는지 판단하지 못한다.

3.3. 셋째 문제: 앱의 고립

1. 각 서버가 자기 앱만 앎

   1. 국소적 지식: 각 MCP 서버는 자신이 연결된 앱의 정보만 알고 다른 앱에 대해서는 아무것도 모른다.
   2. 복합 작업의 현실: 실제 업무는 거의 항상 두 앱 이상을 가로지르므로, 앱 사이의 관계와 순서를 사람이 직접 연결해야 한다.

2. 지도 없는 방의 비유

   1. 문은 많아졌지만 지도가 없음: MCP는 에이전트에게 모든 앱으로 들어갈 문을 줬다.
   2. 기억 없는 방문자: 에이전트는 수천 개의 분리된 방에 서 있지만, 그 방들을 잇는 지도도 없고 이전에 방문한 기억도 없다.

4. 에이전트 전용 인터페이스의 설계

에이전트가 목표를 달성하려면 단순한 연결보다 도구 검색, 실행 계획, 앱 간 맥락 유지가 먼저 제공돼야 한다.

4.1. Slack 버그 보고서에서 수정 PR까지

1. 목표를 한 문장으로 전달

   1. Claude와 Composio MCP: Claude를 Composio MCP에 연결한 환경에서 Slack 메시지 링크를 그대로 복사해 붙여 넣는다.
   2. 명확한 지시: “이 메시지를 사용해 Datadog에서 원인을 찾고, 초안 PR을 만들되 실수하지 말라”고 요청한다.

2. Composio Search의 작업 분해

   1. 필요한 세 가지 목표: Composio Search는 Slack 메시지 가져오기, Sentry 이슈 검색, Datadog 로그 검색이라는 세 가지 작업을 먼저 선언한다.
   2. 도구뿐 아니라 계획 반환: 각 목표에 맞는 올바른 도구만 반환하지 않고, 그 도구를 어떤 순서와 방식으로 사용할지에 대한 실행 계획도 함께 반환한다.
   3. Slack의 선행 조건: Slack 메시지를 검색하려면 먼저 Slack 채널 ID를 찾아야 하므로, 채널 ID 확인이 쿼리보다 앞선 단계로 계획된다.

3. 병렬 조사와 코드 수정

   1. 맥락 수집: 계획에 필요한 맥락을 갖춘 뒤 Slack에서 사용자 불만의 원문을 가져온다.
   2. 동시 데이터 조회: Datadog과 Sentry에서 병렬로 데이터를 가져오고, 동시에 코드베이스를 스캔한다.
   3. 5분 이내의 결과: 근본 원인을 확인한 뒤 수정 사항을 담은 PR이 5분도 안 돼 생성된다.

4. 워크플로와 Skills를 별도로 만들 필요가 없음

   1. 절차의 자동 구성: 이 작업을 위해 별도의 워크플로를 만들거나 에이전트에게 절차를 가르치는 Skills를 작성하지 않아도 된다.
   2. 도구 조합의 결과: Claude가 Composio MCP를 사용해 필요한 검색과 실행을 스스로 연결한 결과다.
   3. 사용 습관의 변화: 이런 방식이 쉬워지면서 Claude를 여는 일이 무엇이든 처리하기 위한 근육 기억(muscle memory)이 됐고, 매일 열던 대시보드는 점점 낯설어졌다.

4.2. Composio가 제공하는 통합 인터페이스

1. 네이티브 MCP와의 초기 비교

   1. 동일 조건 비교: 공개 전 초기 결과는 Composio와 Claude 마켓플레이스에 등록된 각 앱의 네이티브 MCP를 비교한다.
   2. 변수를 통제한 비교: 동일한 작업과 동일한 모델을 사용했으며, 결과에는 명확한 성능 차이가 나타났다.

2. 에이전트가 좋아하는 인터페이스

   1. 복잡한 API의 번역: Composio는 일상적으로 사용하는 앱들의 지저분하고 문서화가 드물며 계속 변하는 API를 에이전트가 사용하기 쉬운 형태로 바꾼다.
   2. 여러 실행 계층의 결합: MCP, CLI(Command-Line Interface), 네이티브 도구 위에 통합 계층을 만들어 일관되고 응집력 있는 경험을 제공한다.
   3. 앱 간 복합 작업: 통합된 인터페이스는 여러 앱에 걸친 복잡한 작업을 끊김 없이 수행할 수 있게 한다.

5. PostHog와 Metabase를 넘나드는 데이터 분석

앱 사이의 전체 결과를 컨텍스트에 부어 넣지 않고 필요한 식별자와 스키마만 단계적으로 활용하면, 에이전트는 교차 데이터 분석도 짧은 시간에 수행할 수 있다.

5.1. 온보딩에서 사용자 세그먼트 찾기

1. 첫 번째 질문

   1. 분석 목표: 온보딩 과정에서 사용자가 선택한 업종(vertical)의 분포를 확인한다.
   2. 자연어 요청: Claude에게 사용자 데이터를 깊이 파고들어 업종별 선택 분포를 보여 달라고 요청한다.

2. PostHog 실행

   1. 검색과 쿼리 생성: Claude는 Composio Search를 다시 실행하고 PostHog에 사용할 쿼리를 작성한다.
   2. 즉시 결과 확인: 쿼리를 실행하면 업종 분포 결과가 화면에 나타난다.

5.2. 이커머스 사용자의 툴킷 분석

1. 두 번째 질문의 확장

   1. 특정 세그먼트 선택: 업종 분포 중 e-commerce 영역을 골라 그 사용자들이 어떤 툴킷(toolkit, Composio에서 앱을 부르는 표현)을 좋아하는지 확인한다.
   2. 두 데이터 소스 연결: PostHog에서 얻은 사용자 ID를 사용해 Metabase의 데이터와 결합한다.

2. 식별자와 결과의 분리

   1. ID 추출: PostHog에서 e-commerce를 선택한 사용자들의 ID를 쿼리한다.
   2. 컨텍스트 절약: 전체 결과를 에이전트 컨텍스트에 적재하지 않고, 필요한 ID를 저장한 채 다음 단계로 넘어간다.

3. Metabase 구조 파악

   1. 스키마 확인: Metabase에서 데이터베이스 스키마를 조회한다.
   2. 샘플링: 일부 데이터를 샘플링해 테이블과 필드가 어떻게 구성돼 있는지 파악한다.
   3. 실행 준비: 데이터 구조에 확신이 생길 때까지 필요한 정보만 확인한다.

4. Remote Workbench의 동적 쿼리

   1. 쿼리의 동적 생성: Composio Remote Workbench라는 도구가 정규식 문자열(regex string)을 활용하는 SQL 쿼리를 동적으로 생성한다.
   2. 전체 ID를 적재하지 않음: 저장된 사용자 ID들을 다시 검색하지만, 수천 개일 수 있는 전체 목록을 컨텍스트 윈도우에 통째로 넣지 않는다.
   3. 분석 결과: 몇 분도 안 돼 해당 사용자 페르소나에서 가장 인기 있는 툴킷을 확인한다.
   4. 교차 소스의 가치: 결과는 PostHog와 Metabase 양쪽에서 가져온 데이터로 만들어진다.

5.3. 공개 데모와 사용 초대

1. 직접 체험
   1. 현장 초대: Composio 부스에서 라이브 버전을 직접 사용해 볼 수 있다.
   2. 데모의 목적: 교차 앱 검색과 컨텍스트 절약이 실제로 어떻게 작동하는지 사용자가 직접 체험하게 한다.

6. 에이전트를 새로운 사용자로 대하는 제품 전략

웹사이트를 AI 검색에 잘 노출되도록 만드는 것만으로는 부족하며, 실제 애플리케이션 자체가 에이전트의 목표와 도구 사용을 지원해야 한다.

6.1. Composio의 출발점과 수요 변화

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

   1. 초기 방향: Composio는 개발자를 돕는 도구로 시작했다.
   2. 앱의 변환: 사용자가 즐겨 쓰는 인기 앱들을 에이전트가 사용할 수 있는 도구로 바꾸는 일이 출발점이었다.

2. 고객 요구의 이동

   1. 사람의 피로: 사람들은 대시보드에 지쳤다.
   2. 에이전트의 피로: 에이전트들은 잘 설계되지 않은 MCP 서버에 지쳤다.
   3. 스타트업의 요청: 이제 스타트업들은 고객이 자신의 서비스를 에이전트를 통해 사용할 방법을 요구하고 있다고 전한다.

6.2. 눈이 없는 새로운 사용자

1. 제품 설계의 전환

   1. 새로운 종의 사용자: 지금 무언가를 만드는 사람은 새로운 종류의 사용자를 서비스하게 됐다.
   2. 시각적 UI의 부재: 이 사용자는 눈이 없으므로 화면을 보거나 반짝이 버튼을 클릭하지 않는다.

2. 에이전트의 평가 기준

   1. 목표와 도구로 등장: 에이전트는 목표와 도구 묶음을 가지고 서비스에 접근한다.
   2. 단 하나의 판단 기준: 에이전트는 일을 끝낼 수 있는지, 오직 그 한 가지로 서비스를 평가한다.
   3. 다음 시대의 승자: 지난 10년 동안 사람에게 사용하기 쉬운 제품을 만들었다면, 다음 시대는 에이전트에게 사용하기 쉬운 제품을 만드는 쪽이 차지한다.

주요 발언 모음

“The dashboard is dead. And I think that's great news for everyone in this room except probably for me because my team is responsible for the Composio dashboard.”

“You never wanted a dashboard or its cursed query language. You wanted the answer.”

“MCP gave agents a door into every app, but it left them standing in thousands of separate rooms with no map and no memory of ever being there.”

“Humans are tired of dashboards and their agents are tired of poorly designed MCP servers.”

“They don't have eyes. They are not going to click your sparkle button.”

“It shows up with a goal and a set of tools, and it judges you on exactly one thing: whether it can get the job done.”

“The next era belongs to those that are easy for agents to use.”

핵심 데이터 & 수치

• 6개월: Sarah는 Datadog을 매일 사용했지만 대시보드를 직접 연 적은 없었다.
• 2022년: Slack·Datadog·Sentry·VS Code·GitHub를 각각 오가며 버그를 해결해야 했던 시기의 기준점이다.
• 5개 도구와 5개 UI: 하나의 Slack 버그 보고를 처리하려면 맥락 확인, 로그 조회, 이슈 확인, 코드 수정, PR 생성에 다섯 도구가 필요했다.
• 2개 데이터베이스 조인: 2023년 반짝이 버튼이 제대로 처리할 수 있는 복잡도의 농담 섞인 경계로 제시됐다.
• 2024년 11월: Anthropic이 MCP 프로토콜을 발표했다.
• 200개 이상: GitHub 툴킷 하나에 포함된 도구 수로, 도구 과부하가 실제 문제가 되는 규모다.
• 5분 미만: Composio MCP를 사용한 Slack 버그 분석·근본 원인 파악·수정 PR 생성까지의 시연 결과다.
• 몇 분 이내: PostHog의 e-commerce 사용자 ID와 Metabase의 툴킷 데이터를 결합해 인기 툴킷을 확인한 시간이다.
• 비교 조건: Composio와 각 앱의 Claude 마켓플레이스 네이티브 MCP를 같은 모델과 같은 작업으로 비교한 초기 미공개 결과에서 분명한 차이가 관찰됐다. 구체적인 점수나 성공률은 공개되지 않았다.

결론 및 시사점

1. 대시보드는 데이터와 사용자의 의도를 번역하는 중간 단계였고, 에이전트가 직접 검색·계획·실행할수록 그 중간 단계의 필요성이 줄어든다.
2. AI 버튼을 기존 대시보드에 붙이는 방식은 단순 쿼리 생성에는 유용하지만, 복수 앱의 맥락과 의존성을 해결하는 에이전트 인터페이스가 되지는 못한다.
3. MCP를 도입할 때는 연결 자체보다 에이전트가 반복해서 배우고, 필요한 도구를 찾고, 호출 순서를 계획하고, 앱 간 작업을 이어 가는 경험을 설계해야 한다.
4. 도구 정의와 Skills를 무작정 늘리면 컨텍스트 윈도우가 포화돼 모델이 잘못된 도구를 고르므로, 검색과 계획을 통해 필요한 정보만 제공해야 한다.
5. PostHog에서 사용자 ID만 추출해 저장하고 Metabase에서 스키마와 샘플을 확인한 뒤 동적 SQL을 생성한 방식은, 결과 전체를 컨텍스트에 넣지 않고도 교차 데이터 분석을 가능하게 한다.
6. 소프트웨어 팀은 사람용 UI뿐 아니라 눈이 없고 목표와 도구로 접근하는 에이전트용 인터페이스를 제품의 핵심 표면으로 설계해야 한다.
7. 마지막에 Datadog 대시보드 앞에서 느꼈던 “뒤처지고 있다”는 감각은 실패의 순간이 아니라, 인간이 화면을 직접 조작하는 시대에서 에이전트가 일을 끝내는 시대로 넘어가는 예고편이 된다.