요약
AI가 만든 HTML 대시보드를 S3에 올리는 사내 도구가 연 15만 달러짜리 Looker를 상당 부분 대체했습니다.
직원 500명 규모 회사에서 3명짜리 데이터 플랫폼 팀에 있는 엔지니어의 경험담입니다. 2026년 2월 동료가 Claude로 만든 HTML 대시보드를 SSO 뒤에 올려 사내 링크로 공유하는 서비스를 만들었고, 8개월 만에 주간 사용자 수가 Looker와 비슷해졌습니다.
왜 중요한가
- 대시보드를 만들고 보여 주는 일을 AI가 싸게 대신하면서 비싼 BI 라이선스의 근거가 약해졌다고 봤습니다.
- 데이터 관리 규칙은 dbt 모델과 Snowflake 권한에 두고, 대시보드 층은 느슨하게 두자는 설계 방향을 보여 줍니다.
- 저자는 이미 데이터 플랫폼과 그것을 잘 아는 팀이 있을 때 통하는 방식이라고 선을 그었습니다.
핵심 내용
- 8개월 동안 Claude 토큰 약 6,400달러와 AWS 약 1,900달러가 들었고, 같은 기간 Looker 비용은 약 10만 달러였습니다.
- 대시보드는 보는 사람의 Snowflake OAuth 토큰으로 실시간 질의하므로 Snowflake 역할이 곧 권한 체계가 됐습니다.
- 초기 버전은 대시보드 스크립트가 사용자 세션과 같은 출처에서 돌아 XSS(악성 스크립트 주입) 위험이 있었습니다.
- 다시 만든 버전은 MCP 커넥터 하나로 업로드를 받고, 사람이 승인해야 게시하며, 쿠키 없는 샌드박스 iframe에서 돌립니다.
- 엔지니어 인건비는 계산에서 뺐고, Looker 사용량은 3분의 1가량 줄었을 뿐 아직 쓰는 팀도 있습니다.
HN 반응
- BI의 핵심은 그림이 아니라 지표 정의와 시맨틱 레이어(지표 정의를 한곳에 모은 층), 접근 제어라는 반론이 많았습니다.
- 반면 Looker 구독을 Claude나 Codex로 만든 자체 도구로 바꿔 해지했다는 경험담도 여럿 나왔고, 인건비를 빼 절감액이 부풀었다는 지적도 있었습니다.
BI를 정말 지나치게 단순하게 보셨네요. 제 경험상 대부분의 회사는 무엇이 중요한지, 무엇을 측정해야 하는지, 그 측정값을 사업 개선에 어떻게 써야 하는지를 정하는 데서부터 애를 먹습니다.
기업들이 이런 세부 사항을 정리하려고 애쓰는 동안, 분석가들은 글쓴이의 표현대로라면 '근사한 그림을 뽑아내는' 일을 맡게 됩니다. 하지만 BI 도구는 사실 분석가들이 사내의 골치 아픈 상황을 헤쳐 나가기 쉽게 하려고 존재하는 것입니다.
그림이나 HTML을 더 쉽게 만들어 낸다고 해서 의사결정 문제가 풀리지는 않습니다. 오히려 더 나빠질 수도 있습니다.
결국 그림 한 장에 50센트보다 훨씬 많은 비용이 들 겁니다.
네, 저는 개인적으로 데이터 시각화와 BI를 구분해서 봅니다. AI가 앞의 것을 확실히 바꿔 놓았어요. claude design으로 시각 자료를 설계할 수 있다는 게 꽤 멋집니다. 라이브러리가 할 수 있는 범위에 매이지 않고, html + svg로 데이터를 원하는 방식 그대로 시각화할 수 있습니다(3D까지 화려하게 만들 수도 있지만, 실질적인 인사이트 없이 눈요기만 되는 함정이 있습니다). 저도 duckdb-wasm으로 그런 재미있는 것들을 만들어 봤습니다.
하지만 BI는 시각화 이상입니다. 탄탄한 데이터 모델과 시맨틱 레이어가 필요하고, 같은 지표가 12군데에서 제각각, 때로는 조금씩 다르게 다시 정의되는 일이 없도록 데이터 거버넌스를 강제하는 도구도 필요합니다. 그리고 (RLS/CLS를 갖춘) 제대로 된 접근 제어도 있어야 합니다. 물론 직접 쓸 BI 도구를 바이브 코딩으로 만들 수는 있겠지만, 시각화 부분만 만드는 것보다 훨씬 많은 작업이 듭니다.
지금은 그게 그냥 채팅 한 번이면 됩니다. https://reportr.com 을 보세요
그쪽 제품이에요? 요즘은 다른 모든 기업용 앱처럼 BI 도구도 전부 채팅이 있잖아요.
SAP는 아니죠. 거기는 대형 장애나 업그레이드를 두 번은 더 겪어야 합니다.
SAP 토큰 하나에 얼마나 받을지 상상이나 되세요?
물어봐야 알 정도면... 애스턴 마틴 한 대? 아니면 2 피오나(fiona)에 1 셰켈쯤 되려나요.
저는 10년 넘게 D3를 좋아해 왔지만, 유지보수에 필요한 학습 곡선이 너무 가팔라서 고객에게 추천한 적은 없습니다. 이제는 아닙니다. ${YourAIAgent} + D3는 정말 끝내줍니다.
10년도 더 전에 다닌 회사에 딱 이런 BI 도구가 있었습니다. 물론 AI는 빼고요. 엔지니어가 아닌 사람이 만든, SQL을 내장한 PHP 페이지가 전부였습니다. 누군가 다른 방식으로 자른 데이터가 필요하면, 그 사람이 기존 페이지를 복사해서 SQL과 컬럼 이름만 바꿨습니다. SQL 문의 여러 파라미터는 URL 쿼리 스트링으로 넘겼습니다. SQL 인젝션에 열려 있었는지는 기억나지 않지만, 어차피 사내 전용 도구였습니다. 나중에 BI 도구를 제대로 도입한 뒤에도 다들 여전히 그 PHP 페이지를 썼습니다. 원하는 데이터가 나오는 페이지를 북마크해 두는 쪽이 더 빠르고 편했거든요.
로우코드 도구처럼, 대부분의 사람은 셀프서비스 BI를 만지작거리고 싶어 하지 않습니다. AI가 그 부분을 도와줄 수는 있겠지만, 기사에 나온 도구는 같은 것의 미묘하게 다른 버전을 사람들이 계속 만들어 내는 문을 열어 줄 것 같습니다. 또 claude는 시각화를 정말 못합니다. 제가 본 것은 전부 비슷비슷하고, 형편없는 차트가 빽빽하게 들어차 있고, 글은 너무 많고, 색 선택은 어설프고, 스토리 측면에서는 실질적인 가치가 없습니다. 그래도 그 개념을 구현한 흥미로운 사례이긴 합니다.
와, 저희 회사도 지금 딱 이걸 하고 있어요! 좀 영리한 엔지니어 한 명이 10년 동안 써 온 연 30만 달러짜리 Looker 구독을 Claude의 힘을 빌린 자체 구현으로 갈아치우는 일을 맡았거든요.
그리고 성공하고 있는 것 같아요! 솔직히 저희는 Looker 기능을 제대로 활용하지도 않았으니 생각보다 문제가 쉬웠던 건 맞아요... 그래도 핵심 아이디어는 몇 주 만에 검증됐고, 한 사람이 몇 달간 파트타임으로 프로젝트를 맡았을 뿐인데, 어제 Looker(정확히는 구글)에 갱신하지 않겠다고 통보했어요.
일단은 1:1 변환으로 시작해서 고객들이 바뀐 걸 거의 눈치채지 못하게 하려고요. 그 뒤에는 iframe으로 서빙하지 않아도 되는 새로운 유연성을 살려서 대시보드를 새로 구상할 계획이에요.
정말 미친 시대예요!
저도 전 직장에서 비슷한 걸 만들었습니다. 끝내 해결하지 못한 부분은 모든 사람이 올바른 숫자를 보고 있다는 걸 어떻게 보장하느냐였습니다. 시맨틱 레이어를 빈틈없이 갖춰 놓아도, 지표를 대시보드에 올리는 과정에서 잘못될 수 있는 일이 아주 많습니다. 제 생각에는 이게 분석가가 여전히 필요한 이유입니다.
바로 그겁니다. 제가 BI에 붙이는 농담 같은 슬로건은 "자신 있게, 쉽게 동료들에게 거짓말하세요"입니다.
의도적일 필요도 없어요. 현실의 데이터가 충분히 복잡하고 엉망이기만 하면 됩니다.
https://xkcd.com/1138/
저희는 salesforce와 salesloft에 연 4만 달러를 내고 있었습니다. 둘 다 영업팀과 SDR팀이 쓰는 간단한 앱 하나로 만들었습니다. 새 앱은 Salesforce보다 훨씬 깔끔하고 빠릅니다. Salesforce와 그 리포트를 설정하고 관리해 달라고 컨설팅 업체까지 고용했었는데, 그 컨설팅 업체도 이제 없어졌습니다.
저는 몇 년째 "genBI" 분야에서 일하고 있는데, 흐름이 정확히 이랬습니다. 처음에는 번지르르한 시각화와 그걸 만들어 내는 AI 엔진을 파는 데 집중했습니다. 하지만 이제 근사한 차트 하나 만드는 데 0.50달러면 된다는 건 맞는 말이지만, 그건 잘못된 데이터로 만든 잘못된 차트일 테고, 한 번 읽히고 나면 잊힐 겁니다.
이 모든 것에서 어려운 부분은 시맨틱 레이어를 구축하고 유지하는 일입니다. 하지만 더 중요한 건, 사용자들이 이 번지르르한 HTML을 만들려고 던지는 프롬프트와 쿼리를 전부 수집하는 일입니다. 만드는 비용이 워낙 싸니까, 그 사용 내역을 수집해서 실제 BI 계층(시맨틱 정의, 스킬과 지식 베이스 파일, 심지어 차트 엔진 규칙까지)을 개선하는 데 반영해야 합니다. 그래야 회사 전체(또는 분석을 의존하는 모든 사람, 최종 사용자까지)에게 일관되고 정확한 단일 진실 공급원을 제공할 수 있습니다.
이 모든 차트 밑바탕에 깔린 데이터 모델, 특히 사용 데이터를 처리해 품질 평가와 파인튜닝 모델로 바꾸는 방식의 자기 개선형 데이터 모델이 이제 핵심입니다. 차트는 얼마든지 Claude가 만든 HTML로 대체될 수 있습니다.
(공개: 저는 Upsolve 창업자라서 이런 문제를 매일 고민합니다)
저희는 Looker를 Hex [1]로 바꿨는데, (저희 사용 사례에서는) 7배 쌌습니다. 그런데 얼마 지나지 않아 사내 데이터 에이전트 플랫폼 "Reef"를 직접 만들었고, 이게 영업과 고객 성공부터 상업 전략과 운영 전략 수립까지 회사 전체가 일하는 방식을 사실상 바꿔 놓았습니다. 저희 엔지니어 중 한 명인 Samuel이 이에 관한 짧은 글을 썼습니다 [2]. 요컨대 ETL을 잘 챙기고 데이터 모델링을 최우선 과제로 삼으면, 자체 BI(더 좋게는 에이전트형 BI)를 비교적 쉽게 만들 수 있습니다.
[1] https://hex.tech/
[2] https://www.samuelsvensson.com/blog/reef
토큰 비용만 따질 게 아니라, 이 도구를 다시 만들고 유지하는 데 들어간 엔지니어링 팀의 인건비까지 계산에 넣었다면 훨씬 더 철저한 분석이었을 겁니다.
결국에는 비용 절감이 50% 정도에 그칠 가능성이 큽니다. 그래도 좋은 결과지만, 기사가 말하는 것보다는 분명 비용이 더 듭니다.
만들 수 있는 대시보드의 유연성이 훨씬 커지고, 필요한 걸 말로 설명하기만 하면 누구나 쉽게 만들 수 있다는 점도 함께 따져 봐야 합니다.
Looker의 시맨틱 모델과 Git 워크플로가 마음에 들지만 이제 직접 AI-BI 플랫폼을 만들고 싶다면, 엔진으로 Credible Data를 한번 살펴보시길 권합니다.
https://www.credibledata.com/
(저는 이 회사와 아무 관계도 없고, 그냥 업계를 잘 알 뿐입니다.)
Credible은 시맨틱 모델 언어로 Malloy를 씁니다. Malloy는 Looker 창업자와 동료들이 만든 것으로, 말하자면 "지금 다시 한다면 뭘 다르게 할까"를 고민한 차세대 프로젝트입니다. PRQL, Cube 같은 것들과 비교하는 맥락에서 HN에서 몇 번 논의된 적도 있습니다.
Credible은 여기에 서빙 인프라와 RAG 같은 것들을 얹었습니다. 사용자 페르소나로 특히 소프트웨어 엔지니어를 겨냥하고 있습니다. 제가 보기에는 기술력이 매우 뛰어난 팀이고 업계의 미래를 보는 시각도 좋습니다.
저희는 codex로 대시보드를 html로 이전해서 Looker에서 막 빠져나왔습니다.
이제 그냥 git 저장소 하나입니다.
모든 사람이 같은 내용을 보는, 비교적 단순한 경우 같네요. 대시보드는 현재 사용자, 어떤 사용자 그룹, 혹은 현재 사용자 아래 조직도에 있는 사람들 기준으로 쿼리해야 하는 경우가 많습니다. 그러려면 HTML을 호스팅하는 데 그치지 않고, 쿼리를 동적으로 실행하고 실행 시점에 차트를 생성해야 합니다.
SaaS 이전에 저희가 하던 방식과 비슷합니다. 2014년에 우버에 입사했을 때는 사람마다 자기 사용자 이름으로 범위가 지정된 S3 버킷이 하나씩 있었고, 거기에 올린 html 파일은 사내 누구에게나 공유할 수 있는 고정 URL을 가졌습니다. 처음에는 분석을 공유하려고 jupyter 노트북을 덤프하는 것부터 시작했고, 시간이 지나면서 점점 더 복잡한 대시보드를 갱신하는 스케줄 작업이 늘어났습니다. 정말 재미있었습니다!
"당신 소프트웨어에 받을 수 있는 최대 가격은, 내가 그걸 다시 만드는 데 드는 비용이다."
벤더들이 더 높은 가격을 받으려고 어떤 다른 요소들을 동원하게 될지 흥미롭네요. 다양한 형태의 락인(lock-in)이나 법적 책임 같은 것들이겠죠.
일부 사용 사례에서, 그리고 모두가 모든 시스템에 접근할 수 있고 데이터 양 덕분에 성능이 적당히 나오는 경우라면 잘 돌아가리라고 봅니다.
고객에게 노출되는 분석 같은 경우에는, 지속적인 운영과 유지보수를 지원하는 AI 네이티브 산출물용 배포 계층이 필요합니다. 대화형 데이터 에이전트로 질문에 답하게 하고 맞춤 분석 요청을 줄이고 싶다면, 관리하고 유지해야 할 것이 더 늘어납니다.
Claude Dashboards 발표를 보셨다면 아시겠지만, 그쪽에서는 레거시 BI가 AI 산출물의 배포 계층이 될 거라고 했습니다. 저는 동의하지 않습니다. 레거시 BI는 애초에 배포에 형편없었습니다.
저희는 Ridge AI(ridgedata.ai)에서 AI 산출물을 배포하고 확장하기 위한, 성능 좋은 브라우저 네이티브 대안을 만들었습니다.
이 모든 것이 실시간으로 진화하는 걸 지켜보는 게 정말 흥미롭습니다.
첫 문장에 Looker 링크를 걸어 줬으면 좋았을 텐데요.
제가 읽기에는 첫 번째 버전(결과 html을 공유하는 방식)은 사실상 권한 계층을 건너뛴 것 같습니다. 누군가 매출 데이터 분석을 그 데이터를 볼 권한이 없는 사용자들에게 마음대로 공유할 수 있다면, 위험한 결정 아닌가요?
단연코 그렇습니다.
저희도 아주 비슷한 상황이 있었는데, Snowplow였던 걸로 기억합니다(몇 년 전 일이라서요). 매달 말도 안 되는 돈이 나가던 도구였습니다.
그 대부분을 GCP BQ 예약 쿼리로 대체했습니다.
몇 년 뒤 "데이터" 팀을 채용했는데, 그 팀이 들어오자마자 난장판의 원흉인 DBT를 들여왔습니다. 비용은 폭증했고 데이터는 엉망이 됐습니다. 저희가 직접 관리하던 얼마 안 되는 데이터는 울타리를 쳐서 따로 떼어 놓고, 계속 GCP BQ 예약 쿼리로 굴렸습니다.
KISS.
괜찮으시면 그 얘기를 좀 더 해 주세요. 저도 DBT 이전 프로젝트를 몇 번 해 봤는데, 모든 걸 수동으로 관리하는 게 시간이 꽤 많이 드는 건 맞다고 생각합니다. 저희는 작업 관리에 prefect를 썼지만, DBT가 완성도 있게 느껴진 적은 없었습니다(다른 기술들처럼 제가 쓰던 때 이후로는 어느 정도 성숙했겠죠).
관련된 사용 사례로, 저는 claude로 제가 쓰는 tensorboard 로그 리더에 기능을 추가하거나 바꾸고 있습니다. 보고 싶은 걸 볼 수 있도록 언제든 무엇이든 바꿀 수 있는 유연성이 정말 좋습니다.
저는 늘 로컬 모니터링 도구를 선호해 왔는데, tensorboard는 지금 사실상 연명 치료 중인 것 같습니다.
https://github.com/dleemiller/BlernsBoard
이 목록에 Tableau도 추가하세요. Claude 자연어로 만든 시각화가 더 낫습니다. 전통적인 BI 중에서 살아남을 불변의 요소는 프레젠테이션 계층이 아니라 데이터 웨어하우스입니다.