BI를 쿼리를 그림으로 바꾸는 도구로 보고, 토큰 비용 0.50달러면 되니 15만 달러 라이선스를 정당화하기 어렵다는 건 지나친 단순화임. 내가 겪은 대부분의 기업은 무엇이 중요하고 무엇을 측정해야 하는지, 그리고 측정 결과를 사업 개선에 어떻게 활용할지 정하는 데 어려움을 겪음.
기업이 이런 세부 사항을 정하는 동안 분석가에게 보기 좋은 그림을 뽑아 달라고 하지만, BI 도구는 실제로 분석가가 복잡하게 얽힌 내부 사정을 헤쳐 나가도록 돕기 위해 존재함. 그림이나 HTML을 쉽게 만드는 것만으로는 의사결정 문제를 해결할 수 없고, 오히려 악화할 수도 있음. 결국 그림 한 장당 50센트보다 훨씬 많은 비용이 들게 됨.
개인적으로 데이터 시각화와 BI를 구분함. AI는 시각화를 확실히 바꿨고, Claude Design으로 라이브러리의 제약 없이 HTML과 SVG를 활용해 원하는 모습을 구현할 수 있다는 건 멋진 일임. 나도 duckdb-wasm 등을 써서 재미있는 것들을 만들었지만, 3D 효과까지 넣다 보면 통찰 없이 눈요기만 제공할 위험도 있음.
BI에는 시각화 외에도 탄탄한 데이터 모델과 시맨틱 계층, 같은 지표가 열두 군데에서 조금씩 다르게 정의되지 않도록 하는 데이터 거버넌스, 행·열 수준 보안(RLS/CLS)을 통한 접근 제어가 필요함. 바이브 코딩으로 BI 도구를 직접 만들 수는 있겠지만, 시각화만 구현하는 것보다 훨씬 많은 작업이 필요함.
무슨 뜻인지는 어렴풋이 알겠지만 핵심을 건너뛰고 있음. 복잡하게 얽힌 내부 사정이 구체적으로 무엇인지 정의해야 할 것 같음.
데이터 업계는 오랫동안 도구에 집착했지만, 가장 큰 효과는 조직과 사람에게서 나옴. 지표, 차원, 핵심 엔터티에 합의하는 것, 즉 거버넌스가 핵심이며 SaaS 제품처럼 돈을 주고 살 수는 없음.
D3를 10년 넘게 좋아했지만 유지보수를 위한 학습 부담 때문에 고객에게 추천하지는 않았음. 이제는 달라졌고, ${YourAIAgent}와 D3의 조합은 훌륭함.
10여 년 전 다녔던 회사에 AI만 없을 뿐 정확히 이런 BI 도구가 있었음. 비개발자가 만든 SQL 내장 PHP 페이지였고, 다른 관점의 데이터가 필요하면 기존 페이지를 복사해 SQL과 열 이름을 바꾸는 식이었음. SQL 매개변수는 URL 쿼리 문자열로 전달했으며, SQL 삽입에 취약했는지는 기억나지 않지만 내부 전용 도구였음. 정식 BI 도구를 도입한 뒤에도 원하는 데이터 페이지를 북마크하는 편이 더 빠르고 쉬워서 모두 PHP 페이지를 계속 사용함.
로우코드 도구와 마찬가지로 대부분은 셀프서비스 BI를 직접 만지려 하지 않음. AI가 도움은 되겠지만, 글 속 도구는 같은 것을 조금씩 다르게 만든 버전이 늘어날 여지도 줌. 게다가 내가 본 Claude 시각화는 나쁜 차트와 과도한 텍스트, 부적절한 색상으로 가득하고 전달하려는 이야기도 빈약해 전부 비슷해 보임. 그래도 이 개념을 구현한 방식은 흥미로움.
우리 회사에서 지금 바로 이 작업을 하고 있음. 유능한 엔지니어 한 명이 Claude의 도움으로, 10년간 지불해 온 연 30만 달러짜리 Looker 구독을 자체 구현으로 대체하는 중임.
상당히 잘 진행되고 있음. 원래 Looker 기능을 충분히 활용하지 않아 예상보다 쉬웠다는 점은 감안해야 하지만, 핵심 아이디어 검증에 몇 주, 이후 한 사람이 다른 업무와 병행해 몇 달을 썼고 어제 Looker, 정확히는 Google에 갱신하지 않겠다고 알림.
우선 고객이 변화를 거의 느끼지 못하도록 기존 기능을 그대로 이전하고 있음. 이후에는 iframe으로 제공하지 않아도 되는 자유를 활용해 대시보드를 새롭게 설계할 계획임.
이전 직장에서 비슷한 것을 만들었음. 끝내 해결하지 못한 부분은 모두가 올바른 숫자를 보고 있다는 보장이었음. 포괄적인 시맨틱 계층이 있어도 지표를 대시보드에 올리는 과정에서 잘못될 수 있는 부분은 여전히 많음. 그래서 분석가가 계속 필요하다고 봄.
BI의 농담 같은 홍보 문구로 “자신 있고 손쉽게 동료에게 거짓말하기”를 쓰곤 함. 고의일 필요도 없고, 현실의 데이터가 충분히 복잡하고 지저분하기만 하면 그렇게 됨.
몇 년간 생성형 BI 분야에서 일했는데 정확히 이런 경로를 거쳐 왔음. 처음에는 AI로 멋진 시각화를 만드는 데 집중했지만, 이제 화려한 차트는 정말 0.50달러면 만들 수 있음. 다만 잘못된 데이터로 만든 잘못된 차트를 한 번 보고 잊어버리기 쉬움.
어려운 부분은 시맨틱 계층을 구축하고 유지하는 것이며, 더 중요한 건 사용자가 HTML을 만들려고 입력하는 프롬프트와 쿼리를 모두 수집하는 일임. 제작 비용이 워낙 저렴하니, 그 사용 내역을 시맨틱 정의, 스킬과 지식 기반 파일, 차트 생성 규칙 등 실제 BI 계층의 개선으로 연결해야 함. 그래야 사내 구성원과 분석 결과에 의존하는 최종 사용자 모두에게 일관되고 정확한 기준 데이터를 제공할 수 있음.
이제 핵심은 차트 아래의 데이터 모델, 특히 사용 데이터를 품질 평가와 미세 조정 모델로 연결해 스스로 개선하는 모델임. 차트 자체는 Claude가 만든 HTML로 대체해도 됨. 참고로 나는 Upsolve 창업자이며 매일 이 문제를 고민하고 있음.
Salesforce와 Salesloft에 연 4만 달러를 쓰다가, 영업팀과 영업 개발 담당자(SDR)를 위한 간단한 앱으로 두 도구를 대체함. 새 앱은 Salesforce보다 훨씬 깔끔하고 빠름. Salesforce와 보고서를 설정·관리하려고 고용했던 컨설팅 업체도 더는 필요하지 않게 됨.
토큰 비용뿐 아니라 도구를 다시 만들고 유지보수하는 데 들어가는 엔지니어 인건비까지 계산했다면 더 충실한 분석이 됐을 것임. 실제로는 약 50% 비용 절감에 가까울 가능성이 큼. 그것도 좋지만, 글에서 주장하는 것보다는 훨씬 비싼 셈임.
만들 수 있는 대시보드의 유연성이 훨씬 커지고, 누구나 필요한 것을 설명하는 것만으로 쉽게 만들 수 있다는 점도 계산에 넣어야 함.
Looker를 Hex로 교체했더니 우리 용도에서는 비용이 7분의 1로 줄어듦. 얼마 뒤 자체 데이터 에이전트 플랫폼 Reef를 만들었고, 이제 영업과 고객 성공부터 사업·운영 전략 수립까지 회사 전체의 일하는 방식을 바꿔 놓았음. 우리 엔지니어 Samuel이 간단한 글도 작성함. ETL을 잘 관리하고 데이터 모델링을 핵심으로 다루면 자체 BI, 더 나아가 에이전트형 BI도 비교적 쉽게 만들 수 있음.
Hex: https://hex.tech/.
Reef 소개: https://www.samuelsvensson.com/blog/reef.
모두가 모든 시스템에 접근할 수 있고 데이터 규모도 적절한 성능을 허용한다면, 일부 용도에서는 잘 작동할 것 같음.
하지만 고객용 분석에는 AI로 만든 산출물을 지속적으로 운영·유지보수할 수 있는 배포 계층이 필요함. 대화형 데이터 에이전트로 질문에 답하고 맞춤 분석 요청을 줄이려면 관리할 대상도 더 늘어남.
Claude Dashboards 발표에서는 기존 BI가 AI 산출물의 배포 계층이 될 것이라고 했지만 동의하기 어려움. 기존 BI는 애초에 배포에 서툴렀음. 우리는 Ridge AI에서 AI 산출물을 배포하고 확장하기 위한 고성능 브라우저 기반 대안을 만들었음. 주소는 ridgedata.ai이며, 이 변화가 실시간으로 진행되는 모습이 흥미로움.
Codex로 대시보드를 HTML로 이전해 Looker에서 벗어남. 이제는 Git 저장소 하나로 관리함.