레이크하우스에서의 데이터 모델링 재구상: Vibe Data Modeling을 소개합니다

데이터 모델링의 과제

모든 분석 스택에서 실버(Silver) 레이어는 성패를 가르는 핵심입니다. BI와 대시보드는 골드(Gold) 레이어에서 데이터를 읽고, 골드는 실버를 기반으로 구축됩니다. 실버 레이어 모델은 모든 분석가, 데이터 과학자, BI 도구가 의존하는 기반입니다. 실버 레이어가 무질서하고, 거버넌스가 없거나, 중복 데이터로 가득 차 있다면 그 위의 모든 작업은 더 어려워지고 느려지며 비용도 많이 들게 됩니다.

하지만 실버 레이어를 제대로 구축하는 것은 늘 어려운 과제였습니다. 대부분의 기업은 실버 모델을 처음부터 직접 구축하는 데 6개월에서 3년의 시간을 허비하거나, 범용 산업 템플릿(보험의 ACORD, 헬스케어의 FHIR, 리테일의 ARTS, 통신의 TM Forum SID 등)을 구매한 후 이를 다듬고 이름을 바꾸고 다시 연결하는 데 9~12개월을 소비합니다. 템플릿은 업계 전체의 평균일 뿐이어서 보통 20~40%만 비즈니스에 유용하며, 특정 비즈니스를 위해 맞춤 설계된 것도 아닙니다. 두 가지 방식 모두 현대적인 데이터 제품이 출시되어야 하는 빠른 속도를 따라잡지 못합니다.

오늘, Vibe Data Modeling을 발표합니다

Vibe Data Modeling은 쉬운 영어로 작성된 비즈니스 설명을 완전하고 거버넌스가 적용되어 배포 가능한 실버 레이어 데이터 모델로 변환하는 멀티 모델 LLM 에이전트입니다. 이 기능은 단일 노트북으로 제공됩니다. 4개의 위젯, 단 한 번의 실행으로 Unity Catalog에 모델을 완전히 배포할 수 있습니다. 결과물이 마음에 들지 않으면 마음에 들 때까지 쉬운 영어로 "바이브(vibe)"를 조절하며 수정할 수 있습니다.

• 몇 달이 아닌 단 몇 시간: 2시간 이내에 배포 가능한 최소 기능 모델(Minimum Viable Model)을 구축하고, 단 하루 오후 만에 확장 범위 모델(Expanded Coverage Model)을 완성합니다.
• 나에게 100% 부합하는 모델: 업계 평균이 아닌 귀사만의 용어, 부서, 도메인을 사용합니다.
• 구조적으로 신뢰할 수 있는 설계: 강제 적용 가능한 251개의 규칙, 두 번의 아키텍트 검토, 배포 전에 모델을 검증하는 에이전트 루프(agentic loop)를 거칩니다.
• 네이티브 Unity Catalog 배포: 스키마, 테이블, 외래 키, 분류 태그, 메트릭 뷰, RDFS 온톨로지, DBML 다이어그램, 샘플 데이터가 함께 생성되고 버전이 관리됩니다.

사용자의 바이브가 최우선입니다

전체 에이전트를 지배하는 단 하나의 원칙은 바로 사용자의 지시가 최우선이라는 점입니다. 위젯, model_vibes 또는 비즈니스 설명에 명시된 지침은 파이프라인의 모든 휴리스틱, 점수 공식, 게이트 및 LLM의 의견보다 우선합니다. 사용자가 "정확히 10개의 도메인"이라고 지정하면 어떤 티어 분류기도 11번째 도메인을 추가할 수 없습니다.

바이브가 데이터 모델이 되는 과정

4개의 위젯 이면에서 에이전트는 4단계 파이프라인을 실행합니다. 입력을 이해하고, 모델을 하향식(top-down)으로 설계하고, 관계 및 메트릭과 연결한 다음 배포합니다. 각 단계는 다음 단계가 시작되기 전에 검증을 거치므로 오류가 없는 깨끗한 상태에서만 다음 단계로 진행됩니다. 내부적으로는 멀티 모델 앙상블로 작동합니다. 대형 사색가(thinker) 모델이 추론과 검토를 처리하고, 대형 작업자(worker) 모델이 대량의 제품과 속성을 생성하며, 소형 모델들이 도메인, 태깅, 샘플 데이터를 처리하고, 판정(judge) 모델이 하나의 루브릭을 기준으로 경쟁 제안들의 점수를 매깁니다. 이 모델 명단은 자가 치유 능력이 있어 실패한 모델은 강등하고 정상 상태로 회복되면 다시 복구합니다.

모델의 구성 방식

모든 모델은 상단부터 하단까지 조직(organization), 부서(divisions), 도메인(domains), 서브도메인(subdomains), 제품(products), 속성(attributes)의 동일한 구조를 따릅니다. 최상위에는 거의 모든 조직이 공유하는 세 가지 부서인 Operations(수행하는 업무), Business(서비스 대상), Corporate(일하는 방식)가 위치합니다. Operations와 Business가 핵심이며, Corporate는 이를 지원하는 소수 영역입니다. 도메인은 고유한 개념 집합을 소유하는 바운디드 컨텍스트(bounded context)입니다. 제품은 도메인 전문가가 인식할 수 있는 실제 비즈니스 개념(송장, 주문 등)을 의미하며, 단순한 배관이나 분석용 데이터가 아닙니다. 그리고 모든 속성은 그 존재 가치를 증명해야 모델에 포함될 수 있습니다.

단일 진실 공급원(Single Source of Truth)과 깨끗한 그래프

모델의 일관성을 유지하기 위해 두 가지 구조적 보장 조치가 강제 적용됩니다. 단일 진실 공급원(Single source of truth)은 하나의 개념이 정확히 하나의 소유 제품을 가짐을 의미합니다. 예를 들어 고객은 customer.customer에 한 번 정의되며 다른 모든 곳에서는 외래 키로 이를 참조합니다. 또한 관계는 방향성 비순환 그래프(DAG)를 형성합니다. 외래 키는 자식에서 부모를 가리키며 순환하지 않고, 어떤 제품도 고립되지 않으며, 키가 배치될 때 중복 열은 정규화를 통해 제거됩니다.

신뢰성을 보장하는 규칙

에이전트는 20개 그룹에 걸쳐 251개의 규칙을 강제 적용합니다. 구조적 규칙은 실제 모델 사전을 읽는 결정론적 게이트이므로 판정 결과를 번복할 수 없으며, 모델이 빌드될 때 실행되고 설치 게이트에서 배포된 모델을 대상으로 다시 한 번 실행됩니다. 실행 시 보고되는 품질 점수는 LLM의 자체 평가가 아니라 모델 자체에서 계산됩니다.

에이전트 루프: 생성, 검증, 다른 방식으로 재시도

단 한 번의 LLM 패스 결과는 결코 최종 결과로 신뢰받지 못합니다. 루프는 하나의 구체적인 시도를 생성하고, 이를 결정론적 게이트 및 정적 분석과 비교하여 검증하며, 실패할 경우 동일한 방식을 반복하는 대신 전략을 변경합니다. 충족되지 않은 요구사항과 구조적 잔재(비정규화된 키, 교차 도메인 중복, 연결되지 않거나 순환하는 외래 키)는 샌드박스 처리된 복구 단계로 라우팅된 후 다시 검증을 거칩니다. 단조 가드(monotonic guard)는 모델을 더 악화시키는 패스를 되돌리므로 모델은 개선되거나 최소한 현 상태를 유지하게 됩니다.

바이브 검증 방법

반복 작업을 수행할 때 사용자의 요청은 각각 개별적이고 확인 가능한 지시사항인 구조화된 검증 요구사항(VREQs)으로 파싱됩니다. 각 요구사항은 샌드박스 처리된 뮤테이터(mutator)에 의해 적용되고 독립적으로 검증되며, 가능한 경우 결정론적으로 처리됩니다. 즉, 게이트는 LLM에 변경 여부를 묻는 대신 실제 모델과 물리적 Unity Catalog를 직접 읽습니다. 실행 시 준수 점수가 보고되며, 검증되지 않은 항목은 조용히 누락되지 않고 다시 대기열에 추가됩니다.

두 개의 아키텍트 게이트

규칙이 기계적인 오류를 잡아낸다면, 아키텍트 게이트는 구조적으로 불합리한 부분을 잡아냅니다. 도메인 아키텍트는 각 도메인을 개별적으로 검토하고, 글로벌 아키텍트는 전체 모델을 검토하여 교차 도메인 중복, 단일 진실 공급원 위반, 구조적 무결성을 확인합니다. 발견된 사항은 자동으로 적용되고 반영(landed), 회귀(regressed) 또는 차단(blocked) 상태로 추적되며, 검토 작업은 오류가 없을 때까지 최대 8번까지 반복 실행됩니다.

한 번의 실행으로 얻을 수 있는 결과물

• 논리적 모델(model.json): 모든 도메인, 제품, 속성, 외래 키 및 분류 태그를 포함합니다.
• Unity Catalog의 물리적 배포: 스키마, 테이블, 외래 키(정보용) 및 분류 태그를 포함합니다.
• Unity Catalog 메트릭 뷰: 제품에 대한 재사용 가능한 KPI 정의로, AI/BI 대시보드 및 Genie에서 바로 사용할 수 있습니다.
• 시맨틱 도구 및 AI 에이전트를 위한 RDFS 온톨로지와 dbdiagram.io용 DBML 파일입니다.
• 동일한 모델을 기반으로 생성된 합성 샘플 데이터와 전체 파이프라인 로그 및 권장 개선 사항이 담긴 next_vibes 파일입니다.

model.json: 단일 진실 공급원

에이전트가 생성하는 모든 것은 단 하나의 아티팩트인 model.json에서 파생됩니다. 물리적 배포, 온톨로지, DBML 다이어그램, 메트릭 뷰, 샘플 데이터, 문서, 그리고 next_vibes 제안 사항이 모두 이 아티팩트로부터 생성됩니다. 어떤 것도 두 번 작성되지 않으므로 논리적 모델과 모든 다운스트림 아티팩트가 서로 달라질 일이 없습니다.

Unity Catalog에 배포되는 요소

배포 카탈로그를 설정하면 도메인은 스키마가 되고, 제품은 Delta 테이블이 되며, 속성은 열이 됩니다. 외래 키는 정보 제약 조건으로 적용되고, 분류 태그(PII, 용어집, 출처)는 빌드 시 적용되며, 메트릭 뷰가 그 위에 얹어집니다.

두 가지 범위: MVM 및 ECM

대부분의 팀은 첫날부터 모든 도메인이 필요하지 않으므로, 에이전트는 동일한 엔진에서 두 가지 범위를 생성합니다. Minimum Viable Model은 먼저 구축되는 핵심 코어이며, Expanded Coverage Model은 비즈니스 전체를 아우르는 전체 범위입니다. 둘 중 하나를 구축하거나, ECM을 MVM으로 축소하거나, MVM을 ECM으로 확장할 수 있으며, 축소 작업은 LLM의 안내에 따라 진행되므로 핵심 제품을 보호할 수 있습니다.

원하는 형태가 될 때까지 조정하기

정교화 과정은 Vibe Data Modeling이라는 이름이 왜 붙었는지 보여주는 단계입니다. v1은 기본 모델이며 옆이 아닌 앞으로만 진화합니다. 어떤 버전도 덮어쓰이지 않으며, 모든 반복 작업은 감사 및 되돌리기가 가능합니다. 변경 사항은 세 가지 의도 모드로 제공됩니다. 특정 부분만 수정하는 surgical(정밀 수정), 전체에 적용하는 holistic(전체 적용), 새로운 것을 만드는 generative(생성) 모드가 있으며, 모두 동일한 규칙과 검토 과정을 거칩니다.

하나의 에이전트, 여섯 가지 작업

동일한 노트북으로 첫 번째 모델을 구축하는 것 이상의 작업을 수행할 수 있습니다. 작업 위젯에서 여섯 가지 작업 중 하나를 선택할 수 있으며, 모든 작업은 동일한 규칙, 아키텍트 게이트, 에이전트 루프를 공유합니다.

버전 조정 방법 (VOV)

기존 버전을 조정하려면 “vibe modeling of version” 작업을 선택하고, 기반이 될 버전을 지정한 다음, 변경 사항을 일반 영어로 작성하거나 next_vibes.txt의 제안 사항을 붙여넣으세요. 에이전트는 이를 VREQs로 파싱하고 해당 버전을 기반으로 파이프라인을 다시 실행한 후 번호가 매겨진 새 버전을 작성합니다. 시작점이었던 기존 버전은 그대로 유지됩니다.

하나의 논리적 모델, 다양한 물리적 레이아웃

논리적 모델은 하나의 아티팩트이며, 물리적 레이아웃은 단일 위젯으로 제어되는 별도의 결정 사항입니다. 동일한 모델을 하나의 카탈로그, 부서별 카탈로그 또는 도메인별 카탈로그로 렌더링할 수 있습니다. 거버넌스 환경이 변경되면 다른 컨벤션으로 다시 배포하면 되며, 논리적 모델은 변경되지 않습니다.

산업 템플릿만으로는 부족합니다

범용 템플릿을 옹호하는 논거는 항상 '빠른 시작'이었습니다. 하지만 뼈아픈 경험을 통해 알게 된 현실은, 그 빠른 시작의 대가로 맞춤 조정과 이름 변경에 9~12개월이 소요된다는 점입니다. 템플릿은 특정 분야의 평균적인 모델일 뿐이며, 구조상 그 어떤 실제 비즈니스와도 정확히 일치하지 않습니다. Vibe Data Modeling은 귀사의 용어와 부서, 도메인을 반영한 모델을 단 몇 시간 만에 생성하며, 다른 모든 모델과 동일한 규칙으로 검증합니다.

에이전트로 구축된 모델 예시

산업에 구애받지 않는 이 동일한 에이전트는 매우 다양한 분야에서 비즈니스 전체를 아우르는 Expanded Coverage Models를 생성했으며, 각 분야에서 인정받는 표준을 참조했습니다. 아래 수치는 오픈 소스 리포지토리에 게시된 참조 모델의 수입니다.

지금 바로 사용 가능

참조 구현은 agent/dbx_vibe_modelling_agent.ipynb에 있는 단일 Databricks 노트북입니다. 네 개의 핵심 위젯을 채우고 실행하기만 하면 되며, 나머지는 해당 산업에 맞는 적절한 기본값으로 설정됩니다.

구체적인 시작 단계로, 제조업 모델을 생성하는 데 사용한 프롬프트와 이를 정교화하기 위해 보낸 첫 번째 일반 영어 조정(vibe) 내용을 소개합니다.

• 참조 리포지토리 (github.com/databricks-industry-solutions/lakehouse-industry-data-models): 에이전트 노트북, 오케스트레이터, 테스트 하네스, 40개 이상의 오픈 소스 참조 모델, 그리고 설계, 통합, 품질 게이트 및 규칙 카탈로그를 다루는 가이드.
• Vibe Data Modeling 백서: 모든 파이프라인 단계에 대한 전체 기술 설명, 전체 규칙 카탈로그, 아키텍트 검토 방법론 및 앙상블 아키텍처.

팀에서 Silver 레이어 프로젝트를 출시하지 못한 채 몇 달 동안 끌고 있었다면, 이것이 실제로 제품을 출시할 수 있는 가장 빠른 지름길입니다. 비즈니스를 일반 영어로 설명하고, 모델을 얻고, 원하는 형태가 될 때까지 반복 조정한 다음 프로덕션에 배포하세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)