지표 플랫폼: 시맨틱 기반에서 지능형 소비까지 실천 경로

一、서론: 지표 플랫폼의 다음 역은 "AI가 신뢰하고 활용하는 것"

지표 플랫폼의 진화사는 본질적으로 "의미"가 사람의 머릿속에서 기계로 이주해 온 역사다. 1세대는 지표를 OLAP 큐브의 물리 구조에 고정시켰고, 유연성이 극히 떨어졌다. 2세대는 시맨틱 레이어로 비즈니스 용어와 SQL 표현식을 분리하여 "명명 일관성"이라는 표면적 문제를 해결했다. 3세대는 지표를 구조화된 시맨틱 자산 객체로 격상시키고, NoETL로 광폭 테이블 사전 구체화의 부담을 우회함으로써 Chat BI와 NL2SQL이 처음으로 가능해졌다. 업계가 보편적으로 동의하는 다음 역은 지표를 "혈연이 있는 객체"에서 한 걸음 더 나아가 "시맨틱 관계를 지니고 추론 가능한 제약을 갖춘 온톨로지 네트워크"로 격상시키는 것이다. 이 방향은 옳다. 지표 간의 인과 경로, 차원 계층의 동적 확장은 데이터 인지 인프라가 머지않아 반드시 보완해야 할 한 과목임이 분명하다.

지난 반년 동안 우리는 회사 내부에서 실제로 "지표 사전"을 0에서 1로 정착시키는 일을 추진했고, 동시에 Text2SQL 시맨틱 레이어 역량 구축을 지원했다. 이 경로는 한 번의 아키텍처 설계로 다 깔 수 있는 것이 아니다. 비즈니스 측, 제품 측, 데이터 웨어하우스 측 세 라인이 동시에 힘을 내야 하며, 모든 단계는 "AI가 이 데이터를 가져다 쓸 때 올바르게 가져올 수 있는가"라는 검증을 견뎌야 한다.

이 글에서 하려는 것은 온톨로지화라는 거대한 서사 위에 이론을 한 겹 더 얹는 것이 아니라, 우리가 실제 정착 과정에서 검증한 경로를 명확히 이야기하는 것이다. 시맨틱 기반을 어떻게 무에서 세우는지, 품질이 통제 불능으로 흐르지 않게 어떻게 보장하는지, Text2SQL과 AI Coding이라는 두 소비 주선을 어떻게 지원하는지, 그리고 이 경로를 따라 앞으로 나아갈 때 다음 단계는 어느 방향으로 힘을 써야 하는지 말이다.

二、시맨틱 기반의 토대: 암묵지를 명시적 자산으로 바꾸기

어떤 지표 플랫폼의 지능화든 한 가지 전제 위에 세워진다. 시맨틱 레이어 안의 모든 설명은 진실되고, 유일하며, 신뢰할 수 있어야 한다는 것이다. 이 토대를 어떻게 다질 것인가에 대해 우리의 경험은 세 라인을 동시에 추진하는 것이다.

비즈니스 측: 기존 리포트에서 역으로 정리하기, 그리고 "암묵 지표" 공략

지표 사전에서 가장 만들기 쉬운 부분은 기존 리포트, 대시보드, SQL에서 이미 "주인이 있는" 지표를 역으로 정리하는 것이다. 이 부분은 상대적으로 관리가 쉽다. 집계 기준이 이미 사용되고 있기 때문이며, 다만 구조화되지 않았을 뿐이다. 정말 어려운 부분은 분석가가 일상적으로 분석 도구에서 높은 빈도로 사용하지만 한 번도 규범적 지표로 축적된 적 없는 그 무리다.

이런 지표에는 세 가지 공통 특징이 있다. 집계 기준이 개인 경험 속에 존재한다(예를 들어 "활성 사용자"는 분석가마다 다른 시간 창을 쓸 수 있고, 누구도 틀리지 않았지만 누구에게도 통용되지 않는다). 여러 기술 기반에 흩어져 서로를 인지하지 못한다. 사용 빈도는 높지만 관리 우선순위는 낮다. "쓸 수만 있으면 되니까"라는 이유에서다.

우리가 이런 문제에 내놓은 해법은 한 번에 전량 흡수하기를 기대하는 것이 아니라, "축적-관찰-정식 전환"이라는 지속 가능한 메커니즘을 세우는 것이다. 회사의 핵심 지표 체계(북극성→지지 지표→관련 지표)를 기점으로, 어떤 리포트가 핵심 지표를 커버하는지 역으로 대조하여 우선 정렬해 상장하고, 롱테일·맞춤형 지표는 우선 등록만 한다(이름, 집계 기준, 담당자 기록). 개발 리소스를 차지하지 않고, 재사용 횟수가 올라가고 비즈니스 가치가 부각되면 그때 "정식 전환"하여 사전 지표로 승격한다. 이는 "닥치는 대로 전부 수록"하는 것보다 훨씬 현실적이다. 초기에 우리는 정말로 정리해 낸 모든 지표를 한 번에 데이터 웨어하우스 개발로 밀어 넣으려 시도했지만, 곧 리소스가 전혀 감당하지 못한다는 것을 발견했고, 게다가 상당수는 리포트 아래의 이산적 맞춤 집계 기준이라 전부 받아들이는 것은 오히려 "핵심 지표 집계 기준 통일"이라는 당초 취지에서 벗어나는 일이었다.

이 메커니즘의 핵심 논리는 이것이다. 시맨틱 주석의 밀도가 이후 AI 데이터 조회 시나리오의 정확도 상한을 직접 결정한다. 따라서 비즈니스 측의 최우선 목표는 "지표를 몇 개나 커버했는가"가 아니라 "실제로 고빈도로 사용되는 지표를 몇 개나 커버했는가"이다.

데이터 웨어하우스 측: 소비를 도메인이 통제 가능한 광폭 테이블로 수렴시키기

비즈니스 측이 해결하는 것이 "지표가 어디서 오고 누가 정의하는가"라면, 데이터 웨어하우스 측이 해결할 것은 더 근본적인 문제다. 지표 뒤의 데이터가 충분히 깨끗한가, 집계 기준이 충분히 통일되었는가, 하류에서 안심하고 인용할 수 있는가.

과거에 분석가와 하류 작업이 완전한 사용자 프로필이나 경영 지표 한 부를 원할 때는 흔히 여러 장의 하위 상세 테이블, 귀인 테이블, 요약 테이블을 스스로 조인해야 했다. 각 테이블의 입자도와 기본 키를 이해해야 할 뿐만 아니라 테이블 간의 연관 관계와 집계 기준 차이까지 명확히 알아야 했다. 이런 이해 비용은 본질적으로 반복 노동이다. 하류 수요 열 개 중 여덟 개가 각자 똑같은 연관 로직을 다시 짜 맞출 수 있고, 조금만 어긋나도 집계 기준이 갈라진다.

해법은 이런 산발적 의존을 도메인 내에서 통제 가능한 몇 장의 정품 광폭 테이블로 수렴시키는 것이다. 수렴 이후 하류는 더 이상 상류의 가공 로직을 신경 쓸 필요가 없고, 데이터 조회가 "다중 테이블 조인+집계 기준 정렬"에서 "단일 테이블 조회"로 단순해진다. 집계 기준은 도메인 내에서 통일 관리되어, 비즈니스 집계 기준이 조정되면 광폭 테이블 가공 계층에서 한 번만 고치면 모든 하류에 자동 반영된다. 광폭 테이블 자체도 자연스럽게 대외 공유 능력을 갖추게 되어, 다른 도메인이 인용하든 지표 사전이나 Text2SQL 엔진이 색인하든 추가 설명 비용 없이 곧바로 도메인이 대외에 데이터 서비스를 제공하는 "계약"으로 삼을 수 있다.

이것은 "우리가 낡은 테이블을 관리하겠다"는 한마디로 추진되는 것이 아니다. 실무적으로 네 가지 구체적 단계를 밟아야 한다.

첫째, 명명과 계층 현황을 먼저 파악한 뒤 착수한다. 같은 핵심 테이블 묶음에서 기본 키 유형이 통일되지 않고, 비표준 접두사, 프로젝트 코드가 테이블명에 박혀 있는 등의 문제를 먼저 파악하지 않으면 어떤 재구성도 새로운 함정을 파내기 쉽다.

둘째, 문서 설명을 믿지 말고 혈연(리니지)을 검증한다. 가장 과소평가되지만 대가가 가장 큰 단계다. 문서에 기록된 의존 관계와 실제 혈연은 자주 맞지 않는다. 반드시 혈연을 검증한 뒤 재구성에 착수해야 하며, 이는 철칙이다.

셋째, 의존 관계에 따라 배치 단위로 추진한다. 내부 의존이 없고 병렬로 개조 가능한 테이블을 선두에 세우고, 고위험 초광폭 테이블은 맨 마지막에 둔다. 또한 필드를 삭감하기 전에 반드시 필드 참조율 통계를 먼저 해야 한다.

넷째, 도메인 경계 프로토콜을 명확히 한다. 본 도메인은 실제로 본 도메인에 귀속되는 필드만 산출하고, 크로스 도메인 지표는 JOIN으로만 인용할 수 있으며, 다른 도메인 필드를 본 도메인 광폭 테이블에 직접 복사해 기록하는 것은 금지한다. 이 규칙을 재구성 단계에서 명확히 해두지 않으면 광폭 테이블 경계는 이후 반복 과정에서 계속 깨질 것이다.

이 단계는 지표 사전이 버틸 수 있는가의 기반 공사다. 지표 뒤의 물리적 구현이 여전히 여기저기서 긁어모은 것이고 집계 기준이 분산되고 혈연이 끊긴 낡은 자산이라면, 지표 사전이 아무리 규범적이어도 더러운 데이터 한 무더기에 깨끗한 겉옷을 한 겹 입혀준 것에 불과하다.

제품 측: "상장"이라는 일 자체를 확장 가능하게 만들기

비즈니스 측이 암묵 지표를 공략하고, 데이터 웨어하우스 측이 물리 자산을 수렴시키며, 최종적으로는 모두 제품 측의 엔지니어링 역량을 통해 이 일련의 과정을 규모화·복제 가능한 생산 라인으로 축적해야 한다. 지난 반년 동안 제품 측이 한 일은 몇 가지로 정리할 수 있다.

프로세스 효율 측면에서, 지표 상장은 "수작업 집계 기준 대조—수작업 모델링—수작업 배포"의 직렬 링크에서 구조화된 폼 입력+자동화 검증+원클릭 배포로 전환하고 있다. 동시에 차원 관리 모듈을 추진하여 "채널별 GMV"와 "GMV" 같은 분해 관계가 자동으로 연관될 수 있게 하여, 모든 차원 조합마다 지표를 새로 만들어야 하는 상황을 없애고자 한다.

다중 기술 출처의 통일 공급은 간과되기 쉽지만 가치가 매우 큰 부분이다. 여기서 말하는 "다중 기술 출처"는 단순한 인터페이스 래핑이 아니라, 동일한 지표 정의 뒤에 여러 물리 구현을 장착하는 것을 허용한다는 뜻이다. 오프라인 테이블의 일 단위 집계 결과일 수도 있고, 실시간 링크가 산출한 분 단위 집계 결과일 수도 있으며, 심지어 서로 다른 엔진(Spark 오프라인 / Flink 실시간)으로 가공된 여러 장의 테이블일 수도 있다. 이런 출처는 각기 다르지만 대외적으로 제시되는 것은 반드시 동일한 집계 기준, 동일한 결과여야 한다. 하류가 실시간 대시보드의 분 단위 데이터를 필요로 하든 오프라인 심층 분석의 일 단위 데이터를 필요로 하든, 가져오는 것은 "동일한 지표"이며, 다만 뒤에서 시나리오에 따라 서로 다른 기술 출처를 매칭했을 뿐이다. 이는 본질적으로 지표 정의 계층에서 "일대다"의 물리 매핑 관리를 하는 것이다.

AI 자동 인식+YAML 기반 대량 생성은 효율 레버가 가장 큰 부분이다. YAML 파일 파싱 기반의 초판 기능을 이미 전달했으며, 데이터 모델과 원자 지표를 자동 생성할 수 있다. 다음 단계는 AI가 "자동 인식" 능력을 갖추게 하는 것이다. 분석가가 비즈니스 설명 한 단락이나 참조 테이블 한 장을 제공하면, AI가 추출 가능한 지표 정의를 자동 인식하고, 필드 집계 기준을 추천하며, 대응하는 YAML 시맨틱 설명을 생성하고, 사람은 최종 검토만 한다. 이 능력이 작동하려면, 팀이 이미 태그 테이블 개발에서 동일한 방법론을 검증한 전제가 있다. 요구사항 입력→목표 테이블명/비즈니스 배경/데이터 입자도/필드 집계 기준/데이터 소스 다섯 가지 핵심 정보 추출→기존 동종 테이블 코드 스타일 참조→테이블 생성문, 파라미터 설정, 가공 로직, 데이터 검증을 포함한 완전한 개발 패키지 자동 생성, 모든 산출물은 동일한 골격을 강제로 따른다(라이브러리명/시간 파라미터는 통일 변수로 하고 하드코딩하지 않으며, 모든 테이블은上线 전에 분포 검증+널값 검사+기본 키 유일성 검증을 반드시 자체적으로 갖춘다). 지표 사전의 AI 자동 인식은 이 경로의 연장선을 걷는다. 오늘은 AI에게 "어떤 테이블을 만들어야 하고 입자도는 무엇인가"를 추출하게 한다면, 내일은 AI에게 "이 설명에 어떤 재사용 가능한 지표가 포함되어 있고 YAML은 어떻게 써야 하는가"를 추출하게 하는 것이며, 산출물이 SQL에서 YAML로 바뀔 뿐 방법론은 변하지 않는다.

三、품질이 통제 불능으로 흐르지 않게 하는 핵심: 이의성(二義性)을 원천에서 차단하기

시맨틱 기반이 하류에서 안심하고 소비될 수 있는가의 가장 핵심 전제는 단 하나다. 모든 지표 이름과 집계 기준은 유일하고 모호함이 없어야 한다. 만약 "신규 고객"이라는 단어가 시스템 안에서 동시에 "최초 주문"과 "최초 가입"이라는 두 집계 기준에 대응한다면, AI가 데이터를 가져올 때 무작위로 함정을 밟게 되고, 사용자는 자신이 어느 버전을 받았는지 전혀 인지하지 못한다.

이 일의 올바른 해법은 지표를 잘못 쓴 뒤 되돌아가 점검하는 것이 아니라, 지표 제출 단계에서 시맨틱 유사도 검사와 집계 기준 충돌 경보를 하여 "두 사람이 각자 거의 동명이지만 집계 기준이 다른 지표를 정의한" 상황을 원천에서 차단하는 것이다. 우리는 이 능력을 시맨틱 기반의 "면역 체계"로 이해한다. 그것은 모든 시맨틱 복잡성을 제거하려 하지 않고, 하류에서 소비되는 모든 지표가 소비되는 그 순간 집계 기준이 확정적이고 유일하도록 보장한다.

이에 딸린 것은 커버리지에 명확하고 자기평가할 수 없는 판정 경계가 있어야 한다는 것이다. "정품 자산 지표 사전 상장 커버리지" 같은 지표는 머릿속으로 대충 정의할 수 있는 소프트 지표로 이해되기 쉽다. 그러나 진정으로 실행 가능한 방법은 분모를 정품 데이터 자산 카탈로그(이미 등급과 인증 메커니즘이 명확한 자산 목록) 안에서 "지표"로 표시되고 동시에 "비즈니스 인증 또는 플랫폼 추천"을 충족하는 그 부분 필드로 고정하는 것이지, 데이터 웨어하우스 측이 스스로 "이 지표가 자주 쓰이는지 안 쓰이는지"를 판단하는 것이 아니다. 이 경계는 한 가지 실제 문제를 해결했다. 과거에 자산盘点을 할 때 "우리 도메인에 사실 지표를 꽤 많이 상장했는데 왜 커버리지 숫자는 여전히 안 좋은가"라는 논쟁이 자주 생겼는데, 근원은 분자와 분모의 집계 기준이 정렬되지 않은 것이었다. 판정 기준을 이미 있는 인증 결과에 고정한 뒤에야 커버리지 숫자는 크로스 도메인 비교 가능성을 갖추게 되고, 비즈니스 측이 분석가에게 지표 상장을 추진할 때도 구체적으로 어느 카탈로그, 어느 필드에 정렬해야 하는지 알게 된다.

품질 보장의 마지막 고리는 모든 정품 자산上线 전의 강제 게이트다. 태그/지표 분포 검증, NULL 값 검사, 기본 키 유일성 검증, 이 세 가지 검증은 "권장 사항"이 아니라 "빠지면 완료로 치지 않는다"이다. 이 세트가 하부의 OneData 명명 규범, 계층별 책임의 지속적 구축과 맞물려 목표로 하는 것은 테이블명, 필드명이 "사람이 읽을 수 있는" 것을 넘어 "AI가 곧바로 이해할 수 있는" 것이 되어, 시맨틱 모호함이 낳는 데이터 조회 오류를 줄이는 것이다.

四、시맨틱 기반의 진짜 시험지: Text2SQL과 AI Coding 두 소비 주선

시맨틱 기반을 아무리 견실하게 세워도 실제 소비 시나리오로 검증하지 않으면 가치가 닫힐 수 없다. 현재 회사 차원에서 시맨틱 레이어에 대한 가장 무거운 두 소비 주선은 하나는 Text2SQL이고 하나는 AI Coding이며, 둘은 겉보기엔 독립적이지만 실제로는 동일한 시맨틱 인프라에 의존한다.

Text2SQL: 지표 사전은 그것의 "사실 출처"

회사 차원의 Text2SQL 능력은 본질적으로 두 계층으로 나뉜다. 이해 계층(NL2SQL 엔진이 자연어를 올바른 SQL 구조로 변환)과 사실 계층(엔진이 "활성 사용자"가 어느 테이블로 가서 어느 필드를 쓰고 어떤 집계 기준으로 계산해야 하는지 아는 것)이다. 업계의 많은 Text2SQL 프로젝트가 막히는 것은 흔히 모델 능력이 부족해서가 아니라 사실 계층이 결여되어 있기 때문이다. 엔진은 언어를 이해하지만 "진실"이 어디 있는지 모른다. 지표 사전은 바로 사실 계층에 권위 있는 데이터 소스를 제공하는 것이다.

우리는 Text2SQL 시맨틱 레이어 프로젝트에서 매우 명확한 규칙을 관찰했다. 필드의 전량 시맨틱 주석이 세밀할수록 NL2SQL이 열거, 집계, 파티션, 제약 같은 구조화 차원에서의 성능이 더 안정적이다. 반대로 어떤 필드에 "논리명과 물리명 불일치" 같은 시맨틱 모호함이 존재하면 곧바로 한 번의 잘못된 데이터 조회로 나타난다. 이는 지표 사전이 해결해야 할 핵심 문제를 정확히 뒷받침한다. 시맨틱 주석이 충분히 정밀하고 집계 기준이 충분히 유일하기만 하면 Text2SQL의 정확도 상한은 뚜렷하게 올라간다.

우리가 실측한 오류 귀인 구조에서 시맨틱 레이어 메타데이터 결여와 Text2SQL 정확도 사이의 직접적 인과관계를 더 구체적으로 볼 수 있다. 시스템 평가 SQL 정확도 85%+, 분석가人工 표본 조사 정확도 90+%, 격차는 크지 않지만 오류 귀인은 세 가지 문제에 고도로 집중된다.

이 데이터 묶음은 매우 중요한 한 가지를 말해준다. Text2SQL 정확도의 병목은 대다수 경우 모델 추론 능력이 아니라 시맨틱 레이어가 "이 필드는 어떻게 조회되어야 하는가" 같은 메타데이터를 명시적으로 선언할 수 있는지에 있다. 이의성 차단, 필드 값 취득 방식 선언, 시간 파싱 규칙 고정, 이렇게 "매력적이지 않은" 시맨틱 레이어 기초 작업이야말로 현재 Text2SQL 정확도를 높이는 가장 직접적인 레버다. 이것이 "이의성 차단"이 제품 측에서 높은 우선순위로 지정된 이유이기도 하다. 그것은 금상첨화의 경험 최적화가 아니라 Text2SQL이 규모화·신뢰를 갖출 수 있는가의 선결 조건이다.

만약 어느 한 시점의 정적 스냅샷만 본다면, 독자는 이 정확도 수준이 좋은지 나쁜지 판단하기 어렵다. 그것은 참조물이 필요하다. 관찰 창을 시맨틱 레이어 구축의 전체 추진 주기로 늘리면 더 직접적인 증거를 볼 수 있다. 시스템 평가 SQL 정확도는 시맨틱 주석 밀도와 커버리지 향상과 동시에 상승하며, 고정된 수준에 머무르지 않는다.

시맨틱 레이어 구축이 지속적으로 추진됨에 따라, 시스템 평가 정확도는 85%+에서 95%+로 향상되었고, 향상 리듬은 시맨틱 레이어 관리 동작(조건 결합 수정, 시간 파싱 규칙 고정, 이의성 검출上线)과 하나하나 대응하며, 자연적 변동이나 모델 능력 자체의 변화가 아니다. 이 추세 데이터 묶음은 앞선 오류 귀인 구조가 말하려 했으나 직접 증명하지 못한 그 문장을 보완한다. 시맨틱 레이어가 불완전에서 완전으로 가는 과정은 Text2SQL 정확도의 관측 가능한 향상으로 직접 실현되며, 이론상 "마땅히" 향상된다는 것에 그치지 않는다.

AI Coding: 시맨틱 레이어의 풍부함이 그 천장을 결정한다

또 하나의 소비 주선(主線)은 AI Coding이 데이터 웨어하우스 개발 체인에서 규모화되어 응용된 것이다. 팀 내부의 실천은 이미 AI 보조 개발이 표준화된 시나리오에서 수량급의 효율 향상을 가져올 수 있음을 검증했다. 특정 비즈니스 도메인의 OneData 구축 전 과정에서 효율이 40% 이상 향상되었고, 핵심 모델 개발 단계에서는 효율이 70% 이상 향상되었다(한 번의 대형 와이드 테이블 분할에 수반된 여러 배치의 하류 마이그레이션을 전 과정 AI 보조 개발로 진행하여 효율이 약 40% 향상).

하지만 이러한 효율 향상에는 공통된 전제가 있다. AI가 충분히 정확한 컨텍스트를 가져야 올바른 코드를 생성할 수 있다는 것이다. 지표 사전과 OneData 자산 체계는 바로 AI Coding에 컨텍스트를 제공하는 핵심 인프라이다. 새로운 라벨 테이블을 개발해야 할 때, AI가 '이 비즈니스 개념이 어느 기존 지표에 대응하는가', '이 와이드 테이블의 어떤 필드를 재사용할 수 있는가', '이 집계 기준의 역사적 정의는 무엇인가'를 직접 조회할 수 있는지가 AI가 생성한 코드의 일회 통과율을 직접 결정한다. 현재 AI 코드 통과율이 비교적 높은 수준에 도달할 수 있는 것은 상당 부분 구조화된 지식 자산(용어 사전, 개발 원칙, 안티패턴 목록, 컨텍스트 트리거 규칙)과 지표 사전의 공동 지원 덕분이며, 단지 모델 자체가 강해졌기 때문만은 아니다.

지표 사전, OneData 자산, 구조화된 지식 베이스는 본질적으로 같은 일의 세 가지 단면이다. 즉 데이터 웨어하우스의 암묵지를 명시화하고, 구조화하고, 검색 가능하게 만드는 것이다. Text2SQL이 소비하는 것도 이 의미론 계층이고, AI Coding이 소비하는 것도 이 의미론 계층이다. 겉으로 보기에 독립적인 두 기술 주선은 저변에서 동일한 의미론 인프라에 의존한다. 이것이 바로 데이터 웨어하우스 측의 정품 자산 수렴이 '기술 부채 정리' 같은 낮은 우선순위의 작업으로 취급될 수 없는 이유이며, 그것은 회사 전체 AI화 데이터 소비 체인의 지반이다.

五、한 걸음 더 나아가기: '소비할 수 있음'에서 '소비가 거버넌스를 주도하는' 폐루프로

의미론적 지반이 세워지고, 품질 차단 메커니즘이 효력을 발휘하고, Text2SQL과 AI Coding 두 주선이 규모화되어 소비되기 시작한 다음, 다음 단계는 어느 방향으로 나아가야 하는가? 우리는 올바른 경로가 더 복잡한 의미론적 추론 능력을 서둘러 덧쌓는 것이 아니라, 우선 '소비'라는 일 자체를 역으로 거버넌스의 입력으로 만들어 자기 강화형 폐루프를 형성하는 것이라고 본다.

첫째, 소비 열기는 자산 거버넌스 우선순위를 역으로 환류해야 한다. 하나의 지표가 Text2SQL, Agent에 의해 더 자주 호출될수록 그 거버넌스 우선순위도 더 높아야 한다. 이를 위해서는 지표 하류 소비 열기 순위와 변경 적시율 순위를 수립하여, '어떤 지표를 우선적으로 거버넌스해야 하는가'라는 일을 인공적 판단에서 데이터 기반으로 바꿔야 한다. 이는 적응형 구체화(materialization)의 사고와 일맥상통한다. 시스템 스스로가 거버넌스 자원을 어디에 써야 하는지를 학습하게 하고, 경험이나 직급의 발언권으로 우선순위를 배분하지 않게 하는 것이다.

둘째, 다중 기술 출처의 통합 딜리버리는 비즈니스 셀프서비스 분석과 더욱 연결되어야 한다. 동일한 지표가 오프라인, 실시간 등 서로 다른 입도의 물리적 구현을 안정적으로 탑재할 수 있게 된 다음 단계는, 이 능력과 BI 도구를 더 깊이 통합하여 비즈니스 셀프서비스 데이터 추출의 커버리지를 현저히 높이는 것이다. 목표는 분석가가 더 복잡한 SQL을 쓰도록 배우게 하는 것이 아니라, '무슨 데이터가 필요한가, 어느 정도 입도가 필요한가'라는 일 자체를 구성 가능하게 만드는 것이며, 지표 플랫폼은 뒤에서 집계 기준의 일관성을 보장하는 역할을 맡는 것이다.

셋째, 메타데이터의 입도는 계속 '소비 방식' 수준까지 하강해야 한다. 의미론 계층이 과거에 주로 담아온 것은 집계 기준 설명(이 지표가 무엇인지, 어떻게 계산하는지)이었다면, 다음 단계에서는 '이 필드는 어떻게 조회되어야 하는가'와 같은 소비 측 메타데이터를 명시적으로 담아야 한다. 특정 함수 처리가 필요한지, 시간 필드의 기본 파싱 규칙은 무엇인지, 강제 2차 확인이 필요한 비즈니스 경계 모호성이 존재하는지 등이다. 이런 종류의 메타데이터는 복잡한 기술 방안이 필요하지 않고 잘 구조화된 의미론 설명 필드 하나면 충분하지만, 반드시 Text2SQL, Agent가 SQL을 생성하기 전에 읽을 수 있어야 하며, SQL을 생성한 뒤에 다시 오류를 교정하는 방식이어서는 안 된다. 이것이 현재 오류 귀인의 '조건 결합', '경계 모호성' 두 가지 문제가 체계적으로 근절될 수 있는 관건이다.

넷째, OneData 구축은 '사람이 알아볼 수 있음'이 아니라 'AI가 직접 이해할 수 있음'을 종국적 표준으로 삼아야 한다. 명명 규범, 계층 책임, 필드 의미론의 지속적 거버넌스에서 측정 기준은 '규범 문서가 얼마나 명확하게 쓰였는가'에서 'Text2SQL 엔진이 테이블명과 필드명을 통해 데이터 경계를 직접 이해할 수 있는가'로 격상되고 있다. 이는 데이터 웨어하우스 측의 규범화 작업이 향후 'AI 데이터 추출 정확도'를 검수 기준 중 하나로 삼아야 하며, 코드 리뷰 시의 인공적 점검 항목에 그쳐서는 안 된다는 것을 의미한다.

六、맺음말: 지표의 의미는 인간의 뇌에서 기계로 이동하고 있다

지표 플랫폼의 가치는 '의미론'을 데이터 자체와 동등하게 중요하게 만드는 것이다. 지난 반년의 실천은 이 일에 지름길이 없다는 것을 점점 더 확신하게 해준다. 비즈니스 측이 암묵적 집계 기준을 명시적 자산으로 바꿔야 하고, 데이터 웨어하우스 측이 산발적 의존을 도메인 내에서 통제 가능한 정품 와이드 테이블로 수렴해야 하며, 제품 측이 상장(上架)이라는 일 자체를 규모 복제 가능한 생산 라인으로 엔지니어링화해야 하고, 동시에 이의성(二義性) 차단으로 의미론적 지반의 유일성과 신뢰도를 지켜내야 한다.

SQL을 잘 쓰는지 여부는 점점 덜 중요해지고 있다. 하지만 '활성 사용자란 무엇인가', '이 지표는 어느 테이블에서 추출해야 하는가', '이 집계 기준은 누가 결정하는가'라는 질문에 얼마나 정확하고 빠르게 답하는지가 Text2SQL이 진정으로 비즈니스 측의 신뢰를 받을 수 있는지, 나아가 AI Coding이 데이터 웨어하우스 개발 체인에서 효율을 지속적으로 증폭시킬 수 있는지를 직접 결정할 것이다. 이것이 또한 이 체계가 모델러에게 요구하는 새로운 능력이다. 더 이상 '코드를 작성하는 사람'이 아니라 '비즈니스 언어와 기계 언어 사이의 번역자이자 수호자'인 것이다.

지표 사전은 종착점이 아니라, 데이터 웨어하우스가 '인간을 향한 조회 시스템'에서 'AI를 향한 의미론적 지반'으로 진화하는 과정에서 가장 먼저 세워진 그 하중 지지 기둥이다. '지반이 견고함 → 품질 통제 가능 → 소비 검증 → 소비가 거버넌스를 주도함'이라는 이 경로를 따라 나아가야만, 더 높은 차원의 온톨로지화 능력과 지표 간 인과 추론이 진정으로 신뢰할 수 있는 기반 위에 세워질 수 있다. 이것이야말로 지표 플랫폼 4.0이 걸어야 할 길이다.

지난 회차 돌아보기

1. 기업급 MultiAgent 도입: Plan 모드와 주·부 Agent 협업｜더우물 기술

2. 더우물 소점 AI Native 진화 실록: Harness로 통제 가능한 AI 딜리버리 구축

3. 기업급 MultiAgent의 기억 시스템: 단기 컨텍스트와 4계층 기억 아키텍처 구현｜더우물 기술

4. EP-Harness: 개인 AI Coding에서 팀급 Agent 워크플로로｜더우물 기술

5. 더우물 지식 문답: 복합 검색 Agent의 시스템 설계 실천

글 / 沈卢

더우물 기술을 팔로우하세요, 매주 목요일 기술 실무 콘텐츠가 업데이트됩니다

글이 도움이 되셨다면 댓글, 공유, 좋아요 부탁드립니다~

더우물 기술의 허가 없이 무단 전재를 금지하며, 위반 시 법적 책임을 물을 것입니다.

더우물 기술

417

글

1.3m

조회

8.3k

팬