> ## Content Index
> Fetch the complete content index at: https://zerodraftlab.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 에이전트보다 대시보드를 먼저 만들어라
- URL: https://zerodraftlab.com/dashboard-before-agent/
- Published: 2026-07-12T01:13:46.000Z
- Updated: 2026-09-15T08:36:07.000Z
- Author: JooMong

AI 에이전트를 만들겠다는 팀은 대개 행동부터 설계한다. 고객에게 메일을 보내고, 늦은 업무를 독촉하고, 보고서를 만들고, 다음 조치를 스스로 결정하게 하려 한다.

순서가 거꾸로다. 에이전트가 무엇을 해야 하는지 정하기 전에, 지금 무슨 일이 벌어지고 있는지 볼 수 있어야 한다. 고객이 어디에서 멈췄는지, 어떤 일이 늦었는지, 누가 마지막으로 행동했는지 모르는 상태에서 자동화를 붙이면 그럴듯한 메시지는 만들 수 있어도 믿을 만한 운영은 만들 수 없다.

**데이터 없는 에이전트는 영리한 데모다. 실제 제품은 대시보드에서 시작한다.**

## 20개 에이전트도 처음에는 대시보드였다

SaaStr는 프로덕션에서 20개가 넘는 에이전트를 운영한다고 말한다. 그런데 자체 개발한 에이전트들은 처음부터 에이전트가 아니었다. 먼저 사람이 쓰는 대시보드를 만들고, 데이터가 흐르게 한 뒤, 그 위에 자동화 계층을 얹었다.

대표 사례가 행사 스폰서를 관리하는 QBee다. 현재 QBee는 100개가 넘는 스폰서 계정과 13개 핵심 업무를 추적한다. 계정마다 개인화한 주간 메일을 보내고, 지연 작업을 찾아내며, 팀에 매일 상태를 보고하고, 마감 독촉과 수금까지 지원한다.

하지만 출발점은 평범한 스폰서 포털이었다. 기존 포털에서는 로그인을 했는지조차 제출이 발생하기 전까지 알기 어려웠다. 새 포털의 첫 요구사항도 단순했다. 업무를 배정하고, 로그인을 쉽게 만들고, 다음 할 일을 가볍게 알려주는 것이었다. 실제 고객 네 곳에서 먼저 운영하며 고장을 고쳤고, 그 과정에서 처음으로 쓸 만한 행동 데이터가 쌓였다.

SaaStr는 QBee가 고객 관리에 드는 사람의 시간을 70% 이상 줄이고, 고객 로그인과 정시 제출을 10배 이상 늘렸다고 주장한다. 인상적인 수치지만 독립적으로 검증된 연구 결과는 아니다. SaaStr가 자사 운영 사례를 바탕으로 공개한 자기보고 수치로 읽어야 한다.

## 대시보드는 화면이 아니라 관찰 장치다

대시보드의 가치는 차트를 예쁘게 보여주는 데 있지 않다. 운영 상태를 구조화하는 데 있다. 고객, 담당자, 해야 할 일, 완료 여부, 마감일, 마지막 로그인, 다음 행동이 같은 문법으로 기록되면 조직은 비로소 반복을 볼 수 있다.

예를 들어 “스폰서 대응을 자동화하자”는 요구는 너무 크고 모호하다. 반면 “마감 7일 전인데 로고를 제출하지 않은 스폰서에게 담당자 이름과 부스 번호를 포함한 안내를 보낸다”는 행동은 자동화할 수 있다. 필요한 상태, 조건, 메시지, 책임자가 모두 보이기 때문이다.

이 차이가 중요하다. 에이전트는 빈 공간에서 판단하지 않는다. 이미 관찰되고 있는 상태에 규칙과 언어를 더한다. 무엇을 개인화할지, 언제 개입할지, 누구에게 보고할지는 대시보드에 남은 데이터가 결정한다.

그래서 첫 질문은 “어떤 에이전트를 만들까?”가 아니다. **“사람이 지금 반복해서 확인하는 상태는 무엇인가?”**다. 그 상태를 한 화면에 모으면 두 번째 질문이 생긴다. “이 가운데 매번 같은 조건에서 반복되는 행동은 무엇인가?” 자동화는 그때부터 시작된다.

## 데이터를 한곳에 복사할 필요는 없다

SaaStr가 말하는 대시보드는 모든 데이터를 새 데이터베이스에 다시 넣는 시스템이 아니다. QBee는 계약과 계정 정보를 Salesforce에서, 인증 상태를 Clerk에서, 발송 결과를 Resend에서 읽는다. 다른 도구인 10K도 Salesforce와 등록 시스템, 마케팅 도구, 여러 공급자 API의 데이터를 연결해 하나의 운영 화면을 만든다.

원본 데이터는 그 데이터를 책임지는 시스템에 남는다. 대시보드는 여러 정본을 현재 시점의 한 장면으로 조립한다. 이 구조가 중요한 이유는 에이전트보다 사람에게 먼저 신뢰를 주기 때문이다. 영업팀 숫자와 마케팅팀 숫자가 다르고 기준일도 모호하다면, 그 위에 올라간 에이전트의 판단 역시 믿기 어렵다.

내부 도구를 만들 때도 같은 원칙을 적용할 수 있다. 계약은 계약 시스템, 결제는 결제 시스템, 업무 상태는 업무 관리 시스템이 책임진다. 새 대시보드는 원본의 소유권을 빼앗는 대신, 결정에 필요한 필드와 기준일을 읽어 하나의 업무 상태로 보여준다. 연결할 수 없는 데이터만 최소한으로 직접 보관한다.

## 자동화는 네 층으로 올린다

QBee가 확장된 순서는 에이전트의 기능 목록보다 유용하다.

1. **개인화:** 이미 수집된 업무 상태를 이용해 계정별 주간 메일을 작성한다.
2. **트리거:** 고객이 특정 업무를 했거나 하지 않았을 때 다음 행동을 실행한다.
3. **보고와 누락 탐지:** 팀이 매일 보는 상태 보고를 만들고, 사람이 놓친 빈칸을 표시한다.
4. **선제 행동:** 마감 독촉과 수금처럼 결과에 직접 영향을 주는 행동을 수행한다.

여기서 핵심은 자율성의 양이 아니라 실패 비용이다. 개인화 초안이 틀리면 사람이 고칠 수 있다. 내부 보고가 빠뜨린 항목도 다음 검토에서 잡을 수 있다. 하지만 잘못된 독촉이나 수금 메시지는 고객 관계와 돈을 건드린다. 뒤로 갈수록 데이터의 정확성, 승인 권한, 중복 실행 방지, 되돌리기 절차가 더 엄격해야 한다.

따라서 “완전 자율 에이전트”는 시작 요구사항이 될 수 없다. 처음에는 사람이 버튼을 누르고 결과를 확인한다. 반복 정확도가 쌓이면 내부 보고를 자동으로 보낸다. 그다음 낮은 위험의 외부 행동을 제한적으로 허용한다. 돈, 계약, 계정 정지처럼 되돌리기 어려운 행동은 마지막까지 승인 단계를 남긴다.

## 내부 도구는 이 다섯 질문에서 시작한다

에이전트 아이디어가 생겼다면 기능 명세를 쓰기 전에 다음 다섯 질문에 답하는 편이 낫다.

1. **매일 이 화면을 볼 실제 사용자는 누구인가?** 사용자가 없다면 데이터도 쌓이지 않는다.
2. **그 사람이 반복해서 확인하는 상태는 무엇인가?** 고객, 업무, 마감, 금액처럼 변화를 추적할 대상을 고른다.
3. **각 상태의 정본은 어디인가?** 대시보드 숫자와 원본 시스템의 숫자가 갈라지지 않게 한다.
4. **어떤 조건에서 같은 행동이 반복되는가?** 직감이 아니라 실제 운영 기록에서 자동화 후보를 찾는다.
5. **틀렸을 때 누가 멈추고 되돌릴 수 있는가?** 자동화의 권한은 실패 비용에 맞춘다.

이 질문에 답하면 첫 버전은 의외로 작아진다. 로그인, 핵심 상태표, 담당자, 마감일, 다음 행동 정도면 충분할 수 있다. 그 화면을 실제 사용자에게 주고 몇 주간 운영하면 예상하지 못했던 병목이 드러난다. 에이전트의 진짜 명세는 회의실의 상상이 아니라 그 병목에서 나온다.

## 에이전트는 제품이 아니라 축적된 운영의 결과다

대시보드부터 만든다는 말은 AI를 나중으로 미루자는 뜻이 아니다. AI가 행동할 수 있는 현실의 좌표를 먼저 만들자는 뜻이다. 무엇이 정상이고, 무엇이 늦었고, 누구에게 어떤 정보가 필요한지 기록되지 않으면 모델은 유창하게 추측할 수밖에 없다.

좋은 내부 도구는 처음부터 사람을 없애려 하지 않는다. 사람의 일을 보이게 만들고, 반복을 발견하고, 낮은 위험부터 자동화한다. 그러다 어느 순간 대시보드는 단순한 화면이 아니라 조직의 관찰 장치가 되고, 에이전트는 그 위에서 움직이는 실행 계층이 된다.

**대시보드가 먼저다. 데이터가 흐른 다음에야 에이전트가 무엇을 해야 하는지 알 수 있다.**

---

출처: SaaStr, [One Way to Build a Great AI Agent? Just Start With a Dashboard. Then Add the Agent.](https://www.saastr.com/one-way-to-build-a-great-ai-agent-just-start-with-a-dashboard-then-add-the-agent/?ref=zerodraftlab.com) 본문의 QBee 운영 규모와 성과 수치는 SaaStr의 자기보고 사례이며 독립 검증된 연구 결과로 취급하지 않았습니다.