AI시대 DW: schema-aware reasoning은 결국 무엇을 잘하자는 이야기일까
이 글은 AI 시대의 DW 모델링은 어떻게 달라져야 할까 와 semantic layer를 왜 다시 보게 되는가 에서 이어지는 내용입니다.
앞선 글에서는 AI 시대에 왜 DW 모델이 더 읽히는 구조가 되어야 하는지, 그리고 왜 semantic layer가 다시 중요해지는지를 적었습니다. 그런데 그 글에서 조금 헷갈릴 수 있는 표현이 하나 있습니다. 바로 schema-aware reasoning 입니다.
저도 처음에는 이 표현이 조금 연구 용어처럼 느껴졌습니다. 그런데 Text-to-SQL 관련 자료를 보다 보니, 결국 실무에서 자주 마주치는 문제를 꽤 정확하게 가리키는 표현이라고 느끼게 됐습니다.
제가 이해한 schema-aware reasoning
제가 이해한 schema-aware reasoning은 거창한 새 개념이라기보다, 아래를 제대로 하자는 이야기입니다.
- 질문에서 말하는 대상이 어느 테이블과 컬럼인지 연결하고
- 그 테이블의 grain과 조인 관계를 이해한 뒤
- 그 문맥에 맞는 SQL을 선택하게 만드는 것
즉 단순히 “스키마를 본다”는 수준이 아니라, 질문을 스키마 문맥 안에서 해석하고 판단하는 능력 에 더 가깝습니다.
왜 이게 별도 주제로 보일까
Text-to-SQL에서는 비슷한 표현이 함께 나옵니다.
- schema linking
- schema-aware reasoning
- disambiguation
- schema pruning
- context selection
이 표현들은 조금씩 다르지만, 실무 감각으로 보면 결국 한 덩어리 문제를 다루고 있습니다.
질문이 들어왔을 때 아래를 잘해야 한다는 뜻입니다.
- 봐야 할 테이블을 너무 많이 보지 않을 것
- 같은 이름처럼 보이는 컬럼을 잘못 고르지 않을 것
- 조인 가능한 것과 조인해야 하는 것을 구분할 것
- 질문에 맞는 기준일과 집계 단위를 고를 것
저는 이걸 DW 입장에서는 결국 질문을 잘 받는 스키마를 만드는 문제 로 보게 됩니다.
schema linking과는 어떻게 다를까
연구 문헌에서는 schema linking 이 좀 더 좁은 표현으로 자주 등장합니다. 질문의 단어와 테이블/컬럼 이름을 연결하는 문제에 가깝습니다.
예를 들어 "공식 경기 수" 라는 질문이 들어왔을 때,
matches테이블을 볼지is_official같은 Boolean 성격 컬럼을 잡아낼지"official"이라는 단어가 단순 설명이 아니라 필터 조건이라는 점을 이해할지
같은 문제가 여기에 들어갑니다.
반면 제가 이해한 schema-aware reasoning 은 여기서 한 단계 더 갑니다.
- 단어를 테이블과 컬럼에 연결하는 것에서 끝나지 않고
- 어떤 조인이 의미상 맞는지
- 어떤 기준일을 골라야 하는지
- 어떤 serving model을 먼저 봐야 하는지
까지 포함하는 넓은 판단에 가깝습니다.
즉 아주 단순하게 줄이면:
- schema linking: “무엇을 봐야 하는가”
- schema-aware reasoning: “그걸 어떤 문맥으로 읽어야 하는가”
정도로 이해하면 꽤 실무적으로 와닿습니다.
실무에서는 이런 상황에서 바로 드러납니다
예를 들어 아래 질문을 생각해보겠습니다.
지난 30일 활성 구매 유저 수를 서비스별로 보여줘
겉으로는 단순하지만, 실제로는 아래를 다 알아야 합니다.
- “활성”이 앱 방문인지 구매 완료인지
- “서비스”가 어느 테이블의 어떤 컬럼인지
- 30일 기준일이
event_date인지order_date인지snapshot_date인지 - 취소 주문이나 테스트 계정을 제외해야 하는지
- 주문 fact를 기준으로 갈지, 이미 만들어둔 유저 상태 mart를 먼저 볼지
이건 문법 문제라기보다 해석 문제입니다.
사람은 경험상 “이 질문은 raw 주문 로그보다 serving mart가 낫겠다” 같은 판단을 할 수 있습니다. 하지만 AI는 그런 맥락이 없으면 눈에 띄는 테이블을 중심으로 그럴듯한 SQL을 빠르게 만들 가능성이 있습니다.
그래서 schema-aware reasoning을 잘하게 만든다는 것은, 결국 AI가 SQL을 예쁘게 쓰게 만드는 것보다 잘못된 기준을 덜 고르게 만드는 것 에 더 가깝습니다.
왜 AI 시대에 더 중요해졌을까
예전에도 분석가는 스키마를 잘 이해해야 했습니다. 그런데 지금은 AI가 SQL 초안을 빠르게 만들기 시작하면서 문제가 조금 달라졌습니다.
예전에는 아예 SQL이 안 나오는 경우가 더 큰 문제였다면, 지금은 문법은 맞는데 해석이 틀린 SQL 이 더 빨리 더 많이 나오는 쪽이 문제입니다.
예를 들어:
order_items기준으로 주문 수를 세는 문제- 현재값 dimension을 과거 사실값에 바로 붙이는 문제
event_date와snapshot_date를 혼용하는 문제- 이름이 비슷한 서비스 컬럼 중 하나를 임의로 고르는 문제
이런 SQL은 겉으로 보면 꽤 자연스럽습니다. 그래서 더 위험합니다.
그래서 결국 모델링 이야기로 돌아오게 됩니다
여기서 다시 처음 글로 돌아가게 됩니다. schema-aware reasoning이 중요하다는 말은, 결국 모델링이 더 중요하다는 말과 꽤 많이 겹칩니다.
왜냐하면 AI가 reasoning을 잘 하려면, reasoning할 재료가 좋아야 하기 때문입니다.
예를 들어 아래 요소는 그대로 영향을 줍니다.
- grain이 명확한가
- 기준일이 분리되어 있는가
- 질문 단위 serving model이 있는가
- 조인 경로가 문서나 메타데이터에 드러나는가
- 컬럼명이 비슷한데 의미가 다른 구조를 방치하고 있지 않은가
저는 그래서 schema-aware reasoning을 별도의 AI 기술 용어로만 보기보다, 좋은 DW 모델이 원래 제공해야 했던 힌트를 AI도 필요로 한다는 사실이 다시 드러난 것 에 가깝다고 봅니다.
semantic layer와는 어떤 차이가 있을까
이 글을 쓰다 보면 semantic layer와도 자꾸 겹쳐 보입니다. 둘은 분명 관련이 있습니다. 하지만 초점은 조금 다릅니다.
- semantic layer는 해석 기준을 고정하려는 계층에 가깝고
- schema-aware reasoning은 질문을 스키마 문맥 안에서 제대로 읽고 선택하게 만드는 능력에 가깝습니다
즉 semantic layer는 “무엇을 어떻게 계산할지”를 덜 흔들리게 만드는 쪽이고, schema-aware reasoning은 “지금 무엇을 보고 어떤 경로로 가야 하는지”를 덜 틀리게 만드는 쪽에 가깝습니다.
실무에서는 둘이 같이 필요합니다.
- semantic layer만 있고 아래 모델이 애매하면 여전히 잘못 읽을 수 있고
- 모델이 좋아도 metric 정의와 조인 규칙이 흩어져 있으면 해석이 흔들릴 수 있습니다
지금 당장 실무에서 해볼 수 있는 것들
거창한 AI 시스템을 붙이기 전에도 먼저 점검해볼 수 있는 것들이 있습니다.
- 자주 받는 질문 10개를 뽑고, 기준 테이블과 기준일이 바로 떠오르는지 보기
- 이름은 비슷하지만 의미가 다른 컬럼을 정리하기
- 질문별 권장 조인 경로를 문서나 메타데이터로 남기기
- raw 이벤트 대신 먼저 보게 할 serving model을 정리하기
- AI가 자주 틀릴 만한 질문을 골라 실제로 SQL을 생성해보고 오답 패턴을 모으기
이런 작업은 결국 schema-aware reasoning을 모델 밖에서만 기대하지 않고, 모델과 메타데이터 쪽에서도 같이 받쳐주겠다는 뜻입니다.
정리
제가 이해한 schema-aware reasoning은 “AI가 스키마를 안다”는 뜻이 아닙니다. 질문을 스키마 문맥 안에서 해석하고, 어떤 테이블과 컬럼과 조인과 기준일을 선택해야 하는지 더 덜 틀리게 판단하는 능력에 가깝습니다.
그래서 이 이야기는 결국 다시 DW 모델링 이야기로 돌아옵니다. AI가 SQL을 더 잘 쓰게 되는 시대일수록, 어떤 질문을 어떤 구조로 받게 할지, 어떤 오답을 원천적으로 어렵게 만들지에 대한 고민이 더 중요해진다고 생각합니다.
댓글 남기기
댓글 목록
관리자 보기