이번 행사 시리즈를 쓰면서 가장 자주 나온 말은 "맥락"이었습니다. Snowflake Horizon Context, Fabric IQ 온톨로지, Genie Ontology가 모두 결국 같은 걸 말합니다. 회사의 지표를 한곳에서 정의하자는 것, 즉 시맨틱 레이어입니다.
개념을 정리하려고 오래전부터 이 일을 해 온 dbt의 문서를 읽었습니다.
문제: 매출이 대시보드마다 다르다
지표 정의가 BI 도구 안에 있으면 도구마다, 대시보드마다 계산식이 따로 놉니다. 누군가는 환불을 빼고, 누군가는 빼지 않습니다. 둘 다 '매출'이라고 부릅니다.
해법: 정의를 한 단계 아래로
dbt 문서의 핵심 문장은 이것입니다. 지표 정의를 BI 계층에서 모델링 계층으로 옮기면, 어떤 도구를 쓰든 모든 부서가 같은 지표 정의로 일한다고 확신할 수 있다.
그리고 정의가 바뀌면 그 지표를 부르는 모든 곳에 반영됩니다. 한 번 고치면 끝입니다.
어떻게 동작하나
문서가 설명하는 흐름은 네 단계입니다.
- 정의: dbt 프로젝트 안에서
revenue같은 지표를 MetricFlow로 정의합니다. 기존 모델 위에 얹고, 조인은 자동으로 처리합니다. - 설정: 관리자가 자격 증명과 토큰을 설정합니다.
- 배포: dbt 작업으로 배포하고 지표를 구체화합니다. 자주 쓰는 쿼리는 내보내기와 캐시로 빠르게 합니다.
- 소비: BI 도구와 앱이 시맨틱 레이어 API로 지표를 조회합니다.
에이전트가 소비자가 됐다
4번에 눈에 띄는 문장이 있습니다. Claude나 ChatGPT 같은 AI 도구가 dbt MCP 서버로 연결해, 원시 테이블 대신 관리되는 지표로 답하게 할 수 있다는 내용입니다.
이것이 지금 모든 회사가 시맨틱 레이어를 다시 꺼내는 이유입니다. 사람은 숫자가 이상하면 물어봅니다. 에이전트는 테이블을 보고 계산식을 새로 만들어 버립니다. 정의된 지표를 쓰게 하면 그 추측을 막을 수 있습니다.
행사 발표와 비교하면
| 정의를 누가 만드나 | 어디에 두나 | |
|---|---|---|
| dbt Semantic Layer | 사람이 코드로 | dbt 프로젝트 |
| Fabric IQ 온톨로지 | 사람이, 시맨틱 모델에서 생성 가능 | Fabric |
| Horizon Context | 여러 원본에서 모으고 Autopilot이 갱신 | Snowflake |
| Genie Ontology | 업무 흔적에서 자동 추출 | Databricks |
위로 갈수록 정확하게 통제되고, 아래로 갈수록 유지 비용이 적습니다. 어느 쪽이 맞는지는 회사의 지표가 얼마나 자주 바뀌고, 틀렸을 때 얼마나 아픈지에 달려 있습니다.
참고로 dbt Semantic Layer는 Starter 또는 Enterprise 계정이 필요합니다.
