AI가 만든 대시보드로 Looker를 대체할 수 있을까?

대시보드 밖에 지표와 권한이 갖춰져 있는가

AI로 만든 화면이 기존 보고서를 대체할 수는 있다. 하지만 기업용 Looker 전체를 걷어내려면 그 보고서가 의존하던 지표 정의와 접근 통제, 운영 기능까지 어디에서 맡을지 정해야 한다. 여기서 비교하는 대상은 기업용 Looker이며 Looker Studio 보고서가 아니다.

Looker의 LookML 모델에는 비즈니스 지표와 데이터 관계를 정의할 수 있다. 회사가 매출 계산과 부서별 데이터 범위를 이곳에 모아 관리했다면, 비슷한 차트를 HTML로 그렸다는 이유만으로 그 역할까지 옮겨진 것은 아니다.

반대로 지표와 권한을 다른 데이터 기반에서 이미 관리한다면, 화면을 별도 서비스로 바꾸는 범위가 작아진다. 자체 구축을 판단할 출발점은 “AI가 이 차트를 만들 수 있나”보다 “차트 아래에서 누가 어떤 숫자를 책임지고 있나”에 가깝다.

사용자는 옮겨 갔지만 모든 보고서가 이전된 것은 아니다

데이터 플랫폼 엔지니어 David Lequin은 10월 14일 공개한 사례에서 약 500명 규모 회사의 자체 HTML 대시보드 서비스가 약 8개월 만에 Looker와 비슷한 주간 사용자 규모에 도달했다고 밝혔다. 이 회사에는 이미 dbt 모델과 Snowflake 권한 체계가 있었다.

그는 일부 대시보드는 아직 대체하지 못했고, 공개한 비용표에는 엔지니어 인건비가 빠졌다고 명시했다. 따라서 이 사례의 성과를 “BI를 완전히 없애고 구독료만큼 순절감했다”로 읽을 수는 없다.

도입을 검토하는 팀에는 다른 계산이 필요하다. 기존 보고서 중 실제로 이전한 업무, 여전히 유지하는 계약, 새 서비스를 고치는 시간과 인프라 비용을 같은 기간으로 놓아야 한다. 새 화면의 인기가 높다는 사실은 이전 후보를 보여 주지만, 계약을 줄여도 된다는 결론까지 대신하지는 않는다.

데이터 권한과 HTML 실행 권한은 다른 문제다

사용자가 어떤 데이터를 조회할 수 있는지와 업로드된 코드가 브라우저에서 무엇을 할 수 있는지는 따로 설계해야 한다. Snowflake OAuth는 보안 통합을 통해 토큰 기반 인증·인가를 제공한다. 이 기능으로 데이터 접근을 연결했다고 해서 AI가 만든 JavaScript의 실행 범위까지 정해지지는 않는다.

MDN의 iframe 문서는 같은 출처의 콘텐츠에 allow-scripts와 allow-same-origin을 함께 허용하는 구성을 경계한다. 해당 콘텐츠가 샌드박스 속성을 제거할 수 있기 때문이다. “사내 로그인 뒤에 둔다”거나 “iframe으로 감싼다”는 말만으로 설계를 마칠 수 없는 이유다.

직접 구축한다면 데이터 계정과 토큰을 누가 보관하는지, 보고 코드에 어떤 실행 권한을 주는지, 수정본을 누가 배포하고 되돌리는지 담당을 정해야 한다. 보고서를 만드는 속도가 빨라질수록 이 운영 기능을 반복해서 쓸 수 있어야 한다.

기존 Looker를 유지하고 화면만 바꾸는 선택도 있다

Google은 10월 12일 Looker Data Apps를 프리뷰로 발표했다. AI가 생성한 앱을 Looker 안에 호스팅하고, 기존 의미 모델과 행 수준 보안·접근 통제를 이용하는 방식이다. 이 경로는 Looker 계약을 없애는 대체재가 아니라 기존 기반을 활용하는 선택이다.

첫 시험 대상은 중요한 보고서 한 개로 좁힐 수 있다. 같은 기간과 필터를 넣고 기존 결과와 숫자를 대조한 뒤, 권한이 다른 계정으로 공유·조회·예약 전달까지 확인한다. 그 업무가 옮겨졌을 때 없앨 수 있는 비용과 새로 맡아야 할 운영을 적으면, 보기 좋은 화면을 만든 성과가 실제 구매 판단으로 이어진다.