YouTubeTech Bridge·2026년 10월 9일·0

[한영자막] 대시보드는 끝났습니다: AI 에이전트가 소프트웨어를 쓰는 법

Quick Summary

AI 에이전트가 소프트웨어를 대신 사용하는 시대에는 대시보드보다 에이전트가 작업을 완수할 수 있는 인터페이스가 중요해진다는 것이 발표의 핵심이다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

[한영자막] 대시보드는 끝났습니다: AI 에이전트가 소프트웨어를 쓰는 법 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

[한영자막] 대시보드는 끝났습니다: AI 에이전트가 소프트웨어를 쓰는 법의 핵심 내용을 4단계로 요약한 인포그래픽
[한영자막] 대시보드는 끝났습니다: AI 에이전트가 소프트웨어를 쓰는 법 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

AI 에이전트가 소프트웨어를 대신 사용하는 시대에는 대시보드보다 에이전트가 작업을 완수할 수 있는 인터페이스가 중요해진다는 것이 발표의 핵심이다.

📌 핵심 요점

  1. 발표자는 Datadog을 매일 사용하면서도 대시보드를 열지 않았던 경험으로 변화의 방향을 설명한다. 사용자가 원하는 것은 화면이나 쿼리 문법 자체가 아니라 문제의 답과 해결이다.
  2. 대시보드의 AI 버튼은 쿼리 작성을 돕지만, MCP는 익숙한 에이전트가 외부 서비스에 연결해 쿼리를 실행하고 답을 전달하도록 사용 경로를 바꾼다.
  3. MCP 연결만으로 작업이 완성되지는 않는다. 발표자는 대화 간 경험 단절, 도구 정의와 스킬로 인한 컨텍스트 부담, 앱 사이의 단절을 주요 문제로 지적한다.
  4. Composio는 목표에 맞는 도구와 사용 순서를 제공하고 여러 앱의 작업을 연결하는 방식을 제시한다. 버그 수정 목업과 PostHog·Metabase 분석 사례가 이를 보여준다.
  5. 발표자가 제안하는 제품 경쟁력의 기준은 에이전트의 작업 완수다. 사람이 보기 편한 화면에 더해, 에이전트가 필요한 도구를 찾고 올바르게 실행할 수 있는 설계가 중요해진다.

🧩 배경과 문제 정의

발표자 Sarah는 자신의 팀이 Composio 대시보드를 담당한다고 밝히면서, Datadog을 매일 사용해도 화면 위치를 모를 만큼 대시보드에서 멀어진 경험을 소개한다. 이를 출발점으로 소프트웨어의 사용 주체가 사람에서 에이전트로 이동할 때 필요한 제품 설계를 설명한다.

기존 업무에서는 Slack의 오류 제보를 읽고 로그와 세션을 확인한 뒤 코드를 수정하고 GitHub에 PR을 여는 과정마다 다른 화면과 검색 문법을 익혀야 했다. LLM과 MCP는 이러한 부담을 줄이는 경로를 열었지만, 도구 선택과 실행 순서, 앱 간 연계, 컨텍스트 관리라는 문제가 남았다는 것이 발표의 문제 정의다.

🕒 시간순 섹션별 상세정리

1. 매일 사용하는 도구에서 대시보드가 사라진 경험

  • Sarah는 6개월 동안 Datadog을 매일 사용했지만 동료에게 알림을 보여주려고 대시보드를 열었을 때 어디에 무엇이 있는지 몰랐다고 드러낸다. 화면을 보지 않고도 서비스를 사용해 왔다는 경험으로 ‘대시보드는 끝났다’는 주장을 시작한다. [01:02]
  • 2022년의 버그 대응은 Slack 확인, Datadog 조회, 세션 확인, VS Code 수정, GitHub PR 생성 등 다섯 도구의 화면을 오가는 일이었다. 도구별 검색 문법과 SQL 차이도 부담이었다. [01:58]
  • 발표자는 대시보드와 쿼리 언어를 사람의 의도를 데이터 시스템에 전달하는 번역 장치로 보여준다. 사용자가 원한 것은 화면 자체가 아니라 답이었다는 문제의식을 제시한다. [02:20]

2. AI 버튼과 MCP 이후에도 남은 실행 문제

  • 2023년 등장한 AI 버튼은 LLM이 쿼리를 작성하도록 했지만 정확성과 복잡한 조인에 한계가 있었다고 보여준다. 이어 2024년 11월 발표된 MCP를 통해 Claude 같은 에이전트가 직접 조회하고 답을 전달하는 경로를 보여준다. [03:10]
  • MCP는 통신 프로토콜이므로 서비스가 에이전트와 어떻게 소통할지는 별도 설계 문제다. 발표자는 대화마다 경험이 이어지지 않는 문제와 도구·스킬 정의가 컨텍스트를 채워 잘못된 도구 선택이나 호출 순서 혼란을 일으키는 문제를 지적한다. [04:13]
  • 각 MCP 서버가 자기 앱만 알기 때문에 여러 앱에 걸친 작업을 연결하는 부담도 남는다. 이를 지도와 기억 없이 수많은 방에 들어갈 수만 있게 된 상황에 비유한다. [04:39]

3. 목표에 맞는 도구와 계획을 제공하는 버그 수정 목업

  • 2026년의 업무 방식을 가정한 목업에서 Slack 메시지 링크와 함께 Sentry·Datadog으로 원인을 찾고 초안 PR을 만들도록 요청한다. Composio 검색은 Slack 메시지, Sentry 이슈, Datadog 로그 조회에 필요한 도구와 계획을 제공하며 Slack 채널 ID 같은 선행 조건도 안내한다. [05:31]
  • 에이전트는 제보를 읽고 데이터 소스를 병렬 조회하며 코드베이스를 살핀다. 발표자는 5분 이내 수정 PR 생성 흐름을 설명하고, 별도 워크플로 또는 스킬을 작성하지 않았다고 강조한다. [06:00]
  • 발표자는 Claude를 여는 일이 습관이 됐다고 드러낸다. 같은 과제와 모델로 Composio와 네이티브 MCP를 비교한 초기 미공개 결과도 소개하지만, 전사에는 구체적인 성능 수치가 담겨 있지 않다. [06:28]

4. 에이전트용 인터페이스와 두 데이터 소스의 연결

  • Composio는 변화가 잦고 문서가 부족한 API를 에이전트가 사용하기 쉬운 인터페이스로 바꾼다고 보여준다. MCP, CLI, 네이티브 도구 위에서 여러 앱의 복잡한 작업을 통합하는 접근이다. [07:05]
  • 온보딩에서 사용자가 선택한 업종 분포를 Claude에 요청하면 PostHog 쿼리를 작성하고 실행한다. 이어 전자상거래 사용자의 앱 이용을 알아보기 위해 PostHog의 사용자 ID를 Metabase 데이터와 연결하는 사례를 제시한다. [07:47]
  • 사용자 ID 전체를 컨텍스트에 넣지 않고 저장한 뒤 Metabase의 스키마와 샘플을 확인한다. Composio remote workbench에서 SQL을 생성해 두 소스의 데이터를 분석하고, 발표자는 몇 분 안에 인기 앱을 확인하는 흐름을 보여준 뒤 현장 체험을 안내한다. [08:43]

5. 새로운 사용자인 에이전트를 위한 제품 설계

  • 발표자는 많은 스타트업이 GEO를 위해 웹사이트를 AI 친화적으로 만들지만, 애플리케이션을 에이전트가 사용하도록 준비한 곳은 적다고 드러낸다. 고객이 에이전트를 통해 서비스를 사용하고 싶어 한다는 요청도 보여준다. [09:25]
  • 에이전트는 화면이나 AI 버튼 대신 목표와 도구를 갖고 서비스를 이용하며, 작업을 끝낼 수 있는지로 제품을 판단한다는 메시지를 전해진다. 다음 시대의 경쟁력은 에이전트가 쓰기 쉬운 제품에 있다는 주장이다. [09:56]
  • 처음의 Datadog 대시보드 경험으로 돌아와, 화면에 익숙하지 않은 자신을 뒤처진 사람이라고 생각했지만 이제는 앞으로 올 변화의 예고로 본다고 마무리한다. [10:07]

🧾 결론

  • ‘대시보드의 종말’은 발표자가 자신의 사용 경험과 제품 사례를 통해 제시하는 방향성이다. 영상만으로 모든 대시보드의 소멸을 입증하는 것은 아니다.
  • MCP는 서비스 연결의 기반이며, 도구 선택·호출 순서·앱 간 연계까지 해결하는 인터페이스 설계가 별도로 필요하다는 주장이다.
  • Composio 사례는 도구와 실행 계획을 함께 제공하고 대량 데이터를 컨텍스트 밖에서 다루는 접근을 보여준다. 실제 효과는 공개된 평가 조건과 재현 가능한 결과로 확인해야 한다.

📈 투자·시사 포인트

  • 소프트웨어 기업을 평가할 때 화면의 완성도와 함께 에이전트가 해당 서비스를 통해 작업을 끝낼 수 있는지 살펴볼 필요가 있다.
  • 도구 탐색, 호출 의존성 안내, 앱 간 작업 연결은 발표에서 제시한 인프라의 가치다. 투자 판단에서는 이러한 기능이 실제 성공률과 고객 사용으로 이어지는지 확인해야 한다.
  • 웹사이트를 AI 검색에 맞추는 GEO와 애플리케이션을 에이전트가 사용하도록 준비하는 일은 서로 다른 과제다. 발표자는 후자의 준비가 부족하다고 지적한다.
  • 고객이 에이전트를 통해 서비스를 사용하고 싶어 한다는 요청은 새로운 수요의 신호로 제시된다. 다만 영상에는 수요 규모나 매출 기여를 판단할 수치가 없다.

⚠️ 불확실하거나 확인이 필요한 부분

  • 버그 원인 분석과 초안 PR 생성 사례는 발표자가 명시한 목업 데모다. ‘5분 이내 수정’ 설명을 실제 운영 환경에서 검증된 성능으로 받아들이기 어렵다.
  • Composio와 각 앱의 네이티브 MCP 비교는 초기 미공개 결과로 소개된다. 제공된 전사에는 성공률, 표본 수, 과제 구성, 비용 등 구체적인 평가 자료가 없다.
  • ‘에이전트는 학습하지 않는다’거나 컨텍스트가 늘면 성능이 떨어진다는 설명은 발표자의 문제 진단이다. 적용되는 모델·메모리 설정·작업 조건의 범위는 확인되지 않는다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 실제 반복 업무 하나를 골라 필요한 앱, 도구, 호출 순서를 정리하고 에이전트가 어디에서 막히는지 확인한다.
  • 같은 모델과 같은 과제로 네이티브 MCP와 통합 인터페이스를 비교하고 작업 성공률, 소요 시간, 잘못된 도구 선택을 기록한다.
  • 여러 앱을 잇는 작업에서 선행 조건이 명확한지 점검한다. 영상의 Slack 채널 ID 확인처럼 먼저 필요한 호출을 안내할 수 있는지 살펴본다.
  • 대량의 사용자 ID나 조회 결과를 모델 컨텍스트에 모두 넣지 않고 저장·처리할 수 있는지 검토한다.

❓ 열린 질문

  • 에이전트 중심 사용이 확대될 때 사람용 대시보드는 어떤 작업에서 계속 필요할까?
  • 네이티브 MCP와 Composio의 성능 차이는 도구 탐색, 실행 계획, 데이터 처리 중 어느 요소에서 주로 발생할까?
  • 여러 앱을 연결하는 작업이 실패했을 때 원인을 어떻게 추적하고 안전하게 재시도할 수 있을까?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.