Cube

이것이 나머지 모든 것이 올라가는 토대다. 왜 중요할까. 지표, 차원, 조인을 코드로, YAML이든 JavaScript든 정의하면 Cube가 그것을 웨어하우스용 질의로 컴파일하기 때문이다. 효과는 시간이 지나며 드러난다. 정의를 한 번 바꾸면 모든 리포트, 대시보드, 임베디드 화면이 함께 갱신된다. 다섯 개의 서로 다른 스프레드시트에서 낡은 지표를 뒤져 본 사람이라면 그 차이를 느낄 것이다.

Analytics Chat은 사람들이 평범한 문장으로 질문하면 원시 테이블이 아니라 시맨틱 모델에 맞춰 답을 만들어 준다. 질의가 거버넌스 정의를 통해 해석되므로, 같은 질문은 누가 하든 같은 답을 돌려준다. 이 일관성이 핵심이다. AI 에이전트가 스키마를 추측하는 것은 자신감 넘치는 잘못된 숫자를 얻는 방법이다.

워크북은 SQL, 시각적 편집기, AI 어시스턴트를 한 화면에 합친다. Workbook Agent는 질의를 초안하고 당신과 함께 다듬는다. 모두 거버넌스 모델에 맞춰서다. SQL을 손으로 쓴다. 드래그 앤 드롭 화면을 쓴다. 여기서 하나를 고를 필요는 없다.

Dashboard Agent는 대화로 대시보드를 만든다. 보고 싶은 것을 설명하면 차트를 조립한다. 사전 집계와 캐싱이 결과를 빠르게 유지하며, 팀이 가장 자주 확인하는 숫자에서는 1초 미만의 성능을 낸다. 속도는 중요하다. 차트는 여전히 내 정의에 맞춰 해석되므로, 빠름이 일관성을 대가로 치르지 않는다.

iframe과 Analytics Chat API를 포함한 Cube의 임베디드 화면을 쓰면 BI 스택을 다시 만들지 않고 자사 제품 안에 분석을 넣을 수 있다. 구조적으로 멀티 테넌트라서 거버넌스가 내 모델에서 각 고객의 권한까지 흐른다. 내 브랜드도 그대로 유지되는데, 분석이 파는 것의 일부일 때 이 점이 중요하다.

질의 속도는 사람들이 쓰는 대시보드와 버리는 대시보드를 가르는 차이인 경우가 많다. Cube는 집계를 미리 계산해 전용 캐싱 계층인 Cube Store에 캐시하므로, 반복 질의가 매번 웨어하우스를 때리지 않는다. 느린 대시보드는 도입에 대한 실질적인 세금이다.

사용자 정의 역할, 싱글 사인온, 감사 로깅은 상위 요금제에서 쓸 수 있다. 이것이 Cube를 규제받는 팀에 신뢰할 만하게 만든다. 지표를 정의하는 바로 그 모델이 누가 그것을 볼 수 있는지도 정의할 수 있다. 거버넌스는 모델에서 차트를 보는 사람까지 처음부터 끝까지 흐른다.

Cube는 모델을 REST, GraphQL, SQL로 노출하고 MCP를 지원해, 에이전트가 거버넌스 데이터를 직접 질의할 수 있게 한다. 맞춤 에이전트는 테이블 이름을 환각하지 않고 내 업무 컨텍스트를 읽는다. 분석 스택과, 대부분의 팀이 아직 파악 중인 에이전트 계층을 잇는 다리다.