AI시대 DW: 모델링은 어떻게 달라져야 할까

8 분 소요

요즘은 AI에게 SQL 초안을 맡기는 일이 꽤 자연스러워졌습니다. 예전에는 쿼리를 직접 짜는 시간이 더 길었다면, 지금은 질문을 다듬고 결과를 검증하는 시간이 더 길어지는 경우도 많습니다. 저도 실제로 SQL 작성 속도 자체는 예전보다 빨라졌다고 느낍니다.

그런데 최근에는 다른 생각도 자주 하게 됩니다. AI가 SQL을 잘 써주는 시대라면, 데이터 엔지니어는 DW 모델링을 어떻게 바꿔야 할까 하는 질문입니다.

이 글은 “앞으로는 무조건 이렇게 해야 합니다” 같은 정답을 말하려는 글은 아닙니다. 아직 저도 정리 중인 생각에 가깝습니다. 다만 요즘 여러 Text-to-SQL 사례, semantic layer 논의, schema-aware reasoning 관련 자료를 보면서 점점 더 분명해지는 방향이 있어서, 그 생각을 제 경험과 함께 적어보려고 합니다.

semantic layer 쪽 이야기는 따로 떼어서 정리하는 편이 더 낫겠다고 판단했습니다. 이 부분은 semantic layer를 왜 다시 보게 되는가 글에서 조금 더 자세히 다뤄보겠습니다.

제가 요즘 느끼는 핵심

AI 시대에 DW 모델링이 덜 중요해지는 것이 아니라, 오히려 더 읽기 쉽고, 더 질문 친화적이고, 더 의미가 드러나는 방향으로 바뀌어야 한다고 생각합니다.

조금 더 직접적으로 풀면 이렇습니다.

SQL 작성 비용은 낮아지고 있습니다
대신 의미가 애매한 모델의 비용은 더 커지고 있습니다
앞으로는 사람이 읽기 쉬운 모델이면서 동시에 AI도 덜 헷갈리는 모델이 더 중요해질 가능성이 큽니다

즉 저는 AI 시대의 모델링을 “덜 해도 되는 일”이 아니라, 더 분명하게 해야 하는 일 로 보고 있습니다.

제가 생각하는 문제를 한 줄로 줄이면 이렇습니다

예전에는 애매한 모델이 있어도 숙련된 사람이 운영 감각으로 메우는 경우가 많았습니다. 그런데 이제는 AI가 그 애매함까지 빠르게 증폭시키는 쪽으로 바뀌고 있다고 느낍니다.

즉 예전에는 “어렵지만 사람 한 명이 풀 수 있는 문제”였다면, 지금은 “그럴듯한 SQL이 더 빨리 많이 만들어지는 문제”가 되고 있습니다.

왜 이런 생각을 하게 되었나

최근 Text-to-SQL 관련 자료를 보면 공통적으로 반복되는 키워드가 있습니다.

schema linking
semantic reasoning
disambiguation
multi-schema complexity
hallucination reduction

표현은 조금씩 달라도 결국 문제는 비슷합니다. AI가 SQL 문법을 몰라서 틀리는 경우도 있지만, 실제 실무에서는 그보다 어떤 테이블을 봐야 하는지, 어떤 컬럼이 기준인지, 어떤 조인이 의미상 맞는지 를 헷갈려서 틀리는 경우가 더 많습니다.

이 지점이 저에게는 꽤 중요하게 느껴졌습니다. 왜냐하면 이 문제는 모델이 더 큰 원인이기 때문입니다. AI가 똑똑해질수록 SQL 문법 문제는 줄어들 수 있습니다. 하지만 의미가 흐린 스키마, grain이 불분명한 테이블, 기준일이 섞인 모델, 조인 의미가 통제되지 않은 구조는 여전히 사람과 AI 모두를 힘들게 만듭니다.

예를 들어 orders 와 order_items 와 payments 가 있을 때, 사람은 경험상 “주문수는 orders 기준으로 봐야지”라고 판단할 수 있습니다. 하지만 AI는 질문과 스키마 설명만 보고 order_items 를 기준으로 집계를 시작한 뒤 그럴듯한 SQL을 만들어낼 수 있습니다. 문법은 맞는데 숫자는 틀리는 상황이 더 자주 생길 수 있다는 뜻입니다.

병목이 사라진 것이 아니라 위로 올라갔다고 봅니다

예전에는 “SQL을 잘 짜는 사람”이 병목인 경우가 많았습니다. 지금은 SQL 초안 자체는 꽤 빨리 나옵니다. 그래서 병목이 사라진 것처럼 보일 때도 있습니다.

그런데 제 느낌에는 병목이 없어진 것이 아니라 더 위로 올라간 것 에 가깝습니다.

예전 병목이 이런 것이었다면:

복잡한 SQL 직접 작성
윈도우 함수, 조인, 집계 구문 작성
반복 쿼리 구현

이제 더 자주 병목이 되는 것은 이런 것입니다.

어떤 모델이 질문을 가장 안정적으로 받는가
어떤 지표를 모델 단계에서 고정해야 하는가
어떤 상태를 이벤트 로그에서 직접 복원하지 말아야 하는가
어떤 테이블 구조가 AI에게도 덜 헷갈리는가
조인 가능한 것과 조인해야 하는 것을 어떻게 구분할 것인가

저는 이 변화가 꽤 크다고 느낍니다. SQL을 쓰는 능력의 가치가 사라지는 것은 아니지만, 모델을 설계하는 능력의 상대적 중요도는 오히려 올라가는 쪽에 가깝다고 봅니다.

그래서 요즘은 “어떻게 SQL을 짜게 할까”보다 “애초에 어떤 질문을 틀리지 않고 받게 할까”를 더 자주 생각하게 됩니다.

앞으로 DW 모델은 더 읽히는 구조가 되어야 한다고 생각합니다

여기서 말하는 “읽히는 구조”는 단순히 컬럼명이 예쁘다는 뜻은 아닙니다. 사람이든 AI든, 테이블을 봤을 때 아래가 더 빨리 드러나는 구조를 말합니다.

이 테이블은 한 행이 무엇을 의미하는가
이 테이블은 어떤 질문에 답하려고 만들어졌는가
이 날짜 컬럼은 어떤 기준일인가
이 상태 값은 언제 기준인가
이 테이블은 다른 어떤 테이블과 어떤 의미로 연결되는가

예전에도 중요했던 요소들이지만, AI를 붙이기 시작하면 이 중요도가 더 커진다고 느낍니다. 사람은 운영 경험이나 맥락으로 애매한 부분을 메울 수 있지만, AI는 그런 맥락을 추론하는 과정에서 그럴듯한 오류도 함께 만들 수 있기 때문입니다.

저는 그래서 요즘 모델을 볼 때 “정답을 만들기 쉬운가”보다 “오답을 만들기 어렵게 되어 있는가”를 더 자주 봅니다. AI 시대에는 이 기준이 더 현실적이라고 느낍니다.

그래서 저는 세 가지 방향이 더 중요해진다고 봅니다

1. 질문을 받아주는 서빙 모델이 더 중요해집니다

예전에는 “필요하면 분석가가 SQL로 풀면 되지”라는 말이 어느 정도 통했습니다. 그런데 AI 시대에는 오히려 이 태도가 한계를 더 빨리 드러낼 수 있다고 생각합니다.

AI는 이벤트 로그를 조합해서 그럴듯한 SQL을 만들어낼 수 있습니다. 하지만 반복적으로 많이 나오는 질문까지 매번 로그에서 복원하게 두는 것은 여전히 비효율적입니다. 저는 이런 질문일수록 더 적극적으로 서빙 모델로 올려야 한다고 봅니다.

예를 들어 이런 질문들입니다.

특정 날짜 기준 활성 유저 수
복귀 유저 수
휴면 전환 유저 수
특정 시점 상태 기준 세그먼트 규모
리텐션 계산의 기준 집합

이런 질문을 매번 raw 이벤트에서 새로 풀게 하면, 사람도 흔들리고 AI도 흔들립니다. 그래서 저는 AI 시대일수록 반복 질문은 더 과감하게 mart나 상태 테이블로 승격해야 한다고 생각합니다.

이건 단순히 쿼리 성능 이야기만은 아닙니다. 같은 질문에 대해 팀원마다, 또는 AI 세션마다 조금씩 다른 SQL이 나오지 않게 만드는 장치이기도 합니다.

2. 애매한 조인 구조는 더 비싸질 수 있습니다

AI가 SQL을 잘 만든다는 말은, 반대로 잘못된 조인도 더 빠르게 만들 수 있다는 뜻이기도 합니다. 특히 여러 fact-like 테이블이 느슨하게 연결되어 있거나, 시간축이 다른 dimension을 조인해야 하거나, SCD와 현재값 테이블이 함께 섞여 있으면 이 문제는 더 커집니다.

아래처럼 정리할 수 있습니다.

항목	AI 이전에도 문제	AI 시대에 더 커지는 문제
다의적인 키	숙련자 의존	그럴듯한 오조인 자동 생성
grain 불일치	중복 집계 위험	잘못된 결과 대량 재생산
시점 컬럼 혼재	해석 혼선	질문마다 다른 기준 선택
과도한 테이블 분산	탐색 난이도 증가	schema linking 실패 가능성 증가

저는 그래서 앞으로는 “정규화가 얼마나 예쁜가”보다, 잘못 읽힐 여지가 얼마나 적은가 를 더 자주 보게 될 것 같습니다.

이 기준으로 보면 모델링의 평가는 조금 달라집니다. 테이블 수를 줄였는가보다 중요한 것은, 질문을 받았을 때 기준 테이블과 기준 날짜와 기준 grain이 바로 드러나는가입니다.

3. semantic layer가 없더라도 semantic한 모델은 필요합니다

최근에는 semantic layer가 다시 많이 이야기됩니다. 여기서 말하는 semantic layer는 지표 정의, 기준일, 조인 규칙 같은 비즈니스 의미를 공통 규칙으로 관리하는 해석 계층 정도로 이해하면 됩니다. 쉽게 말해, 각자 SQL에서 의미를 다시 만들지 않도록 질문의 기준을 고정해두는 장치에 가깝습니다.

저도 그 흐름 자체에는 공감하는 편입니다. 다만 모든 팀이 완성도 높은 semantic layer를 곧바로 갖추기는 어렵습니다. 그래서 저는 현실적으로는 이렇게 생각합니다.

semantic layer가 아직 없더라도, 최소한 semantic한 모델은 있어야 합니다.

즉 모델 자체에서 아래 요소가 드러나야 합니다.

명확한 grain
기준일 분리
상태 정의
질문 단위의 서빙 구조
재처리 규칙

이런 요소 없이 AI에게 SQL만 잘 시키는 방향은 오래가기 어렵다고 생각합니다.

여기서 말하는 semantic한 모델은 꼭 특정 제품이나 semantic layer 도입을 뜻하지는 않습니다. 저는 우선 모델 이름, 컬럼 설명, 기준일 분리, 상태 정의, 질문 단위 mart 같은 기본기부터 더 중요해진다고 봅니다.

사람을 위한 모델과 AI를 위한 모델은 완전히 다르지 않다고 생각합니다

이 부분은 제가 요즘 가장 흥미롭게 보는 지점입니다. 처음에는 “AI 친화적인 모델”이라는 말이 사람 친화적인 모델과 별개일 수도 있다고 생각했습니다. 그런데 실제로는 완전히 반대는 아니었습니다.

오히려 제가 느끼기에는, 사람이 읽기 쉬운 모델과 AI가 읽기 쉬운 모델은 꽤 많이 겹칩니다.

결국 둘 다 싫어하는 것이 비슷합니다.

이름은 비슷한데 의미는 다른 컬럼
연결은 되지만 의미는 불명확한 조인
한 테이블 안에 섞여 있는 여러 기준일
한 행의 의미가 불분명한 구조
질문이 아니라 적재 편의만 반영된 서빙 계층

그래서 저는 AI 친화적 모델을 새로 발명해야 한다기보다, 결국 좋은 모델의 기준이 더 엄격하게 드러나는 것에 가깝다고 보고 있습니다.

결국 사람도 AI도 비슷한 지점에서 헷갈립니다. 다만 사람은 이상함을 느끼고 멈출 수 있고, AI는 이상한데도 계속 그럴듯하게 써내려가는 편이라서 더 조심해야 합니다.

그렇다면 앞으로 어떤 모델링 습관이 더 중요해질까

제가 요즘 더 중요하게 보게 되는 습관은 아래와 같습니다.

1. 질문을 먼저 적고 모델을 설계하기

테이블을 만들기 전에 “이 모델은 어떤 질문에 답할 것인가”를 먼저 적어두는 편이 더 중요해질 것 같습니다. AI 시대에는 질문이 곧 쿼리 입력이 되기 쉬우므로, 모델이 받아야 할 질문의 범위를 더 명확히 하는 것이 필요합니다.

2. grain을 더 노골적으로 드러내기

예전에도 중요했지만 앞으로는 더 중요해질 것 같습니다. 테이블 설명, 컬럼명, 문서, 모델 이름 어디에서든 grain이 드러나는 편이 낫다고 생각합니다.

3. 기준일 컬럼을 더 엄격하게 분리하기

event_date, snapshot_date, effective_date, loaded_at 가 섞인 구조는 예전에도 위험했습니다. AI가 여기에 들어오면 이 위험이 더 커집니다. 이름이 비슷할수록 그럴듯한 잘못이 더 자주 생깁니다.

4. 반복 질문은 raw에서 직접 풀지 않기

로그에서 매번 다시 계산해도 되는 질문과, 아예 서빙 모델로 승격해야 하는 질문을 구분해야 한다고 생각합니다. 저는 후자의 범위가 앞으로 더 넓어질 수 있다고 봅니다.

5. 모델 문서화를 선택이 아니라 인터페이스로 보기

AI에게 스키마를 읽히게 할 때도, 결국 좋은 문서가 있으면 훨씬 유리합니다. 그래서 모델 설명은 단순 참고문서보다 인터페이스에 더 가깝게 취급해야 한다고 생각합니다.

지금 당장 바꿔볼 만한 것들

거창한 리모델링 전에도 먼저 해볼 수 있는 것들이 있습니다.

반복 질문 다섯 개를 뽑고, 지금 raw에서 푸는지 serving model에서 받는지 점검하기
테이블 설명에 grain과 기준일을 한 줄로 적기
event_date, snapshot_date, effective_date 를 같은 의미처럼 쓰는 곳 정리하기
조인 가능한 키와 실제 권장 조인 경로를 문서나 모델 설명에 남기기
상태 기반 질문은 이벤트 로그 복원 대신 상태 테이블이나 mart 승격 검토하기

이 정도만 해도 AI가 생성하는 SQL의 흔들림은 꽤 줄어들 수 있다고 봅니다.

아직 저도 확신하지 않는 부분

물론 저도 아직 확신하지 않는 부분이 많습니다.

예를 들어 아래 질문은 계속 의문으로 남아있습니다.

semantic layer가 실제로 어느 정도까지 모델 복잡성을 흡수할 수 있을까
AI가 더 좋아지면 현재의 모델링 원칙 중 무엇은 덜 중요해질까
wide table과 semantic layer의 역할 분담은 어떻게 바뀔까
모델은 더 단순해지고 의미 계층은 더 두꺼워질까, 아니면 반대일까

정리

제가 요즘 내리는 잠정 결론은 이렇습니다.

AI가 SQL을 잘 써준다고 해서 DW 모델링의 중요성이 줄어드는 것은 아닌 것 같습니다. 오히려 SQL 작성 비용이 낮아질수록, 결국 모델이 얼마나 질문을 잘 받아주는지가 더 크게 드러납니다.

저는 그래서 앞으로의 DW 모델링은 더 질문 중심적이어야 하고, 더 읽기 쉬워야 하고, 더 의미가 잘 드러나야 한다고 생각합니다.

아직 이것이 정답이라고 말하고 싶지는 않습니다. 다만 적어도 제가 운영하거나 설계하는 DW에서는, 사람과 AI가 함께 읽는 구조를 더 자주 상상하게 됩니다. 그리고 그 상상은 생각보다 새로운 이야기가 아니라, 결국 좋은 모델이 원래 가져야 했던 성질을 다시 더 또렷하게 보는 일에 가깝다고 느끼고 있습니다.

참조 링크

댓글 목록

관리자 보기

관리자 키

YourFiesta Blog