https://github.com/dbt-labs/dbt-charts는 채팅과 에이전트 코딩 경험이 훌륭함. “dbt Charts로 차트를 만들어 줘. uv tool install dbt-charts && dct skills intro부터 시작해”라고 한 뒤, “채용 메일함 대시보드를 만들어 줘. 지원자 이름·이메일·지역, 지원서 품질, 응답 경과 시간을 보여 줘”라고 요청함. 한 번의 요청으로 만든 대시보드가 놀라울 만큼 괜찮음.

데이터를 왜 시각화해야 할까? 그래프와 차트는 늘 수학 시간에 풀이 과정을 쓰라는 요구처럼 느껴짐. 일종의 강요된 공감각임.
로켓은 예상대로 안전하게 착륙하거나 그렇지 않을 뿐이며, 초록불과 빨간불도 추상화된 데이터 표시임. 맥락에 집중해야 함. “로켓은 0.2m/s 미만으로 착륙해야 함”이라는 조건에 데이터를 넣고, 초과하면 감속하고 미만이면 초록불을 켜면 됨.

오랫동안 BI 팀을 이끌어 온 입장에서 좋아 보이지만, 시각화는 BI 도구 가치의 일부에 불과함. 거버넌스, 접근 제어, 상호작용, 시맨틱 계층 연결도 필요함. 예제에서는 SQL을 직접 쓰지만, 실제로는 차원과 측정값의 이름 등을 활용하는 더 추상화된 형태를 원하게 됨.
이런 기능도 dbtTran Cloud에 들어갈 예정인가?

그럴 예정임! 시맨틱 계층과의 긴밀한 연동을 위한 큰 계획이 있음.

Chartio(YC'10, 현재 Atlassian Analytics) 창업자 Dave임. 오늘 대시보드를 선언하고 렌더링하는 오픈 소스 YAML 방언이자 도구인 dbt Charts를 공개함.
Claude나 다른 에이전트로 대시보드를 만들면 자유 형식의 결과물이 많이 생겨 검토와 확장이 어려워짐. dbt Charts는 대시보드용 Markdown처럼, 간단한 YAML로 차트를 선언하고 렌더링함. dbt와 마찬가지로 Apache 2.0 라이선스로 출시함.
이 언어와 AI를 통해 대시보드를 간결하고 검토 가능한 코드로 만들고, BI 생태계를 더 개방적으로 바꾸고 싶음. 생각과 피드백을 환영함.

가장 먼저 떠오른 용도는 MCP App의 렌더링 수단으로 dbt Charts를 쓰는 것임. Observable Framework처럼 LLM 클라이언트에 코드 실행 환경을 주고 싶지는 않음. dbt Charts는 데이터 소스로 보내는 SQL을 포함해 YAML 입력 전체를 검증하는 것으로 보임.
즉, JS 런타임 샌드박스를 구성하는 번거로움 없이 LLM/MCP 클라이언트가 동적으로 정의하고 렌더링할 수 있는 데이터 시각화 계층으로 이해함.

괜찮지만 실제보다 더 혁신적인 것처럼 포장함. BI는 이미 다른 구성 요소와 분리되어 있고, AI로 Excel이나 Power BI 보고서를 만드는 사람도 있음. YAML/XML/JSON 중 무엇인지는 중요하지 않으며, AI는 지시한 형식으로 생성할 수 있음.
dbt의 자연스럽고 좋은 발전이지만, 블로그 글에서 느껴지는 만큼 혁신적이지는 않음. 그래도 특정 사용자층에서 인기를 얻을 만한 좋은 아이디어라고 봄. 전문 데이터 디자이너를 고용하는 것도 좋은 선택임. 데이터 시각화는 잘못 만들기 매우 쉬움.

대체로 동의하지만, Dave가 어디서 데이터 시각화의 패러다임 전환이라고 했는지는 모르겠음. 핵심은 오히려 BI 도구가 대중화되기 전부터 있던 검증된 시각화 패턴을 기반으로 일관되게 좋은 차트를 만들고, 단순하며 유지보수가 쉽다는 것임.
이미 알려진 설계 범위 안에서도 잘 구현한 도구는 충분히 유용할 수 있음. AI로 이미 할 수 있는 일이더라도 결과물의 완성도와 유지보수성은 조금 떨어질 수 있음. 참고로 나는 dbt/Fivetran에서 일함.

AI가 지시한 것을 생성할 수는 있지만, 생성한 결과물을 이후에 어떻게 활용할지가 중요함. 재사용하려면 잘 정의된 구조화된 프로토콜이나 언어가 필요함.
차트를 설명하는 YAML을 다시 에이전트에 넘겨 “이걸 읽고 차트를 만들어 줘”라고 하는 것밖에 할 수 없다면 무슨 소용인가? 처음 만든 차트와 결과가 크게 달라질 것임.

거의 40년 동안 프로그래밍했지만 완전히 다른 분야에서 일해서, “대시보드”라는 개념이 거의 와닿지 않음. 이 프로젝트가 정확히 무엇인지, BI가 무엇이며 왜 필요한지 설명해 줄 수 있을까? PowerBI가 구현하는 무언가가 BI일 거라고 짐작할 뿐, 그 이상은 전혀 모르겠음.

전문가는 아니지만, BI 도구는 데이터에 질문을 던지고 답을 찾게 해 줌. 조직의 거의 모든 부서에서 무수히 많은 용도로 쓸 수 있음. 예를 들어 영업 책임자라면 다음 분기에 팀이 집중할 곳을 정하기 위해 회사의 영업·마케팅 데이터를 분석할 수 있음.
유용한 결과를 주는 질문을 찾았다면, 이를 모아 대시보드로 만들 수 있음. 그러면 최신 또는 최신에 가까운 데이터로 같은 질문과 결과를 쉽게 다시 확인하고 팀과 공유할 수 있음.

BI는 비즈니스 인텔리전스로 알고 있음. 군사 정보 활동과 비슷하게, 사업 담당자가 합리적인 의사결정을 내릴 수 있도록 데이터를 제시하는 관행과 도구의 집합임.
대시보드는 사용할 기능과 상호작용 요소를 한데 모아, 개별 도구나 데이터 화면으로 이동하게 해 주는 곳임. 상단에는 구매를 시작한 사람 수 대비 구매 건수 같은 의미 있는 지표가 있을 수 있음. 여기서 더 들어가 구매 소요 시간, 재구매 고객, 구매 과정 중 이탈 시점 등을 살펴볼 수 있음.
즉, 비즈니스 데이터를 탐색하는 출발점임.

나도 시각화를 외부 서비스가 렌더링할 수 있는 재사용 가능한 결과물로 만드는 비슷한 것을 개발하고 있었음. Slack, Teams 등 어떤 에이전트 실행 환경에서 요청하든, 에이전트가 dbt Charts 같은 서비스에서 명세를 받아 오는 구조임.
합의된 통합 명세가 있으면 타사 앱과 에이전트 실행 환경 모두 같은 차트 언어를 쓸 수 있어 멋질 것 같음. 아직 자세히 읽지는 않았는데, Vega-Lite 같은 도구와는 어떻게 다른가? https://github.com/vega/vega-lite.

실제로 내부에서 Vega-Lite를 사용함. Vega-Lite는 정적 데이터로 차트를 만드는 방대한 도구 모음이고, dbt Charts는 그 위에 반복 실행 가능한 SQL 쿼리를 갖춘 대시보드 계층을 추가함. 차트 스타일에도 여러 기본 원칙을 정해 놓았음. 즉, Vega-Lite라는 차트 조립 도구로 대시보드를 만드는 셈임.
모든 에이전트가 동일한 명세를 생성하고 여러 렌더러가 이를 그리는 표준 차트 언어는 꿈꾸는 목표임. 다만 단순하면서도 매우 다재다능해야 하므로 달성하기 어려움. 그런 조합이 아직 존재하는지도 확신하기 어려움. 우리 언어는 단순하고 꽤 유연하지만 Vega-Lite 자체나 JavaScript만큼 표현력이 높지는 않으며, 앞으로 그 방향으로 발전할 여지는 있음.