AI시대 DW: semantic layer를 왜 다시 보게 되는가

5 분 소요

지난 글에서 AI 시대의 DW 모델링 이야기를 하면서 semantic layer 이야기를 잠깐 꺼냈습니다. 그런데 이 주제는 짧게 한 문단으로 끝내기에는 아쉬움이 있었습니다.

왜냐하면 semantic layer는 단순히 “지표를 예쁘게 정의해두는 도구” 정도로 보기에는, 앞으로의 분석 환경에서 맡게 될 역할이 꽤 커 보이기 때문입니다.

이 글은 semantic layer를 설명하려는 글은 아닙니다. 오히려 왜 이 개념을 다시 보게 되는지, 그리고 왜 AI 시대에는 더 자주 이야기될 수밖에 없는지를 제 관점에서 정리한 글에 가깝습니다.

semantic layer를 한 문장으로 말하면

저는 semantic layer를 이렇게 이해합니다.

질문할 때마다 SQL 안에서 의미를 다시 만들지 않도록, 지표 정의와 조인 규칙, 기준일을 공통 규칙으로 고정해두는 계층

즉 핵심은 계산 자체보다 해석의 기준을 반복 가능하게 만드는 것 에 있습니다.

조금 더 실무적으로 말하면, “같은 질문을 누가 하든 비슷한 SQL과 비슷한 숫자로 수렴하게 만드는 장치”에 가깝습니다.

예를 들어 아래 같은 것들입니다.

매출은 어떤 테이블을 기준으로 계산하는가
active user는 어떤 행동을 기준으로 정의하는가
신규 유저는 first_seen 기준인가 first_purchase 기준인가
날짜 기준은 event_date 인가 snapshot_date 인가
여러 fact를 함께 볼 때 어떤 조인 규칙을 따라야 하는가

이런 것이 매번 쿼리 안에서 다시 결정되면, SQL은 돌아가도 해석은 흔들리기 쉽습니다.

semantic layer가 실제로 고정하려는 것은 이런 것들입니다

조금 더 감각적으로 보면, semantic layer는 아래 같은 것을 중앙에서 고정하려는 시도에 가깝습니다.

항목	예시
metric 정의	`active_users = 지난 30일 내 핵심 행동을 1회 이상 한 유저 수`
기준 엔터티	`user_id`, `service_id`
기준일	`event_date` 기준인지 `snapshot_date` 기준인지
조인 규칙	매출은 `orders` 기준, 상품 속성은 `products` 와 연결
제외 규칙	테스트 계정, 내부 트래픽, 취소 주문 제외 여부

즉 semantic layer가 하는 일은 대단히 새로운 계산을 발명하는 것보다, 이미 조직 안에 흩어져 있던 해석 규칙을 덜 흔들리게 고정하는 쪽에 더 가깝습니다.

예전 프로젝트를 돌아보면 완전히 새로운 이야기는 아니었습니다

예전에 제가 공공기관처럼 합의와 문서화가 특히 중요했던 프로젝트를 할 때는, DW 설계에서 테이블 정의서나 컬럼 정의서를 굉장히 꼼꼼하게 관리했었습니다.

그 문서 안에는 단순한 컬럼 설명만 있는 것이 아니었습니다. 어떤 지표를 어떤 기준일로 계산하는지, 어떤 코드값을 어떤 의미로 해석하는지, 어떤 테이블을 어떤 조건으로 조인해야 하는지, 집계 시 어떤 제외 규칙을 따라야 하는지 같은 내용이 함께 들어 있었습니다.

ㅇ그때 하던 일이 완성된 제품 형태의 semantic layer는 아니었습니다. 다만 적어도 “질문할 때마다 의미를 다시 만들지 않게 한다”는 점에서는 꽤 비슷한 역할을 했다고 생각합니다.

차이가 있다면 예전에는 이걸 문서와 사람의 숙련도에 더 많이 기대어 유지했다면, 지금은 그 의미를 모델과 메타데이터 계층 안으로 더 직접 넣으려는 흐름이 강해졌다는 점입니다. 저는 semantic layer를 볼 때 이 차이를 가장 크게 느낍니다.

semantic layer가 특히 필요해지는 질문들

저는 아래 같은 질문이 많아질수록 semantic layer 필요성이 커진다고 봅니다.

지난 30일 활성 유저 수를 서비스별로 보여달라는 질문
매출을 채널별로 분해해달라는 질문
신규 유저와 복귀 유저를 같은 기준으로 계속 보고 싶은 질문
여러 팀이 같은 지표를 각자 다른 SQL로 보고 있는 질문

이런 질문은 한 번만 답하면 끝나는 것이 아니라 계속 반복됩니다. 그래서 쿼리 실력보다 해석 기준의 재사용성이 더 중요해집니다.

왜 지금 더 중요해 보일까

예전에도 semantic layer는 중요했습니다. 다만 지금은 AI가 들어오면서 중요도가 더 커진다고 느낍니다.

이유는 단순합니다. AI는 SQL을 빨리 만들어줄 수 있지만, 의미를 합의해주지는 못하기 때문입니다.

예를 들어 AI가 아래 질문을 받았다고 해보겠습니다.

지난 30일 활성 유저 수를 서비스별로 보여줘

겉으로는 단순합니다. 그런데 실제로는 아래를 모두 알아야 합니다.

“활성”의 기준 행동이 무엇인지
서비스 구분은 어느 컬럼이 진실인지
30일 기준일이 event_date 인지 snapshot_date 인지
제외해야 할 내부 트래픽이나 테스트 유저가 있는지

이건 SQL 실력이 아니라 의미 체계의 문제입니다. semantic layer가 필요한 이유가 여기 있습니다.

semantic layer가 없으면 어떤 일이 생기나

semantic layer가 없다고 해서 바로 큰 사고가 나는 것은 아닙니다. 오히려 더 흔한 문제는 “다들 그럴듯한 SQL을 만들지만 결과가 조금씩 다르다”는 쪽입니다.

예를 들면 이런 상황입니다.

팀 A는 active user를 앱 방문 기준으로 계산
팀 B는 핵심 기능 실행 기준으로 계산
팀 C는 내부 계정을 제외하지 않음
AI는 가장 그럴듯한 조인을 골라서 SQL 생성

그러면 숫자는 전부 “그럴듯하게” 나옵니다. 그래서 더 위험합니다.

semantic layer는 이 문제를 줄이는 장치입니다. 질문이 바뀌어도 해석 기준이 흔들리지 않게 해주기 때문입니다.

예를 들어 active user 하나만 봐도, 기준 행동을 앱 방문으로 볼지 핵심 기능 실행으로 볼지부터 다를 수 있습니다. semantic layer는 이런 차이를 쿼리 안에서 그때그때 결정하지 않도록 막아주는 역할을 합니다.

그렇다고 semantic layer가 모든 문제를 해결해주지는 않습니다

이 점도 중요합니다. semantic layer가 있다고 해서 모델링이 덜 중요해지는 것은 아닙니다.

오히려 저는 이렇게 봅니다.

semantic layer는 의미를 정리해주는 계층
DW 모델링은 그 의미가 안정적으로 서 있을 수 있게 받쳐주는 구조

즉 semantic layer는 좋은 모델 위에서 더 강해집니다. 아래 모델이 애매하면 semantic layer도 애매해질 수밖에 없습니다.

예를 들어 아래 같은 구조가 여전히 중요합니다.

명확한 grain
기준일 분리
상태 테이블과 이벤트 테이블의 역할 분리
잘못 조인하기 어려운 서빙 구조

semantic layer는 모델링의 대체재라기보다, 모델링 위에 올라가는 해석 계층에 더 가깝습니다.

그래서 저는 semantic layer를 도입한다고 해서 모델링 복잡도가 자동으로 사라진다고 보지 않습니다. 아래 테이블이 흔들리면 위 해석 계층도 같이 흔들립니다.

semantic layer가 있어도 바로 해결되지 않는 것들

이 부분도 같이 봐야 합니다.

raw 이벤트 정의 자체가 흔들리는 문제
grain이 서로 다른 fact를 무리하게 함께 보려는 문제
상태 계산을 매번 뒤늦게 복원해야 하는 문제
조직 내 지표 정의 합의가 끝나지 않은 문제

semantic layer는 이런 문제를 마술처럼 없애주기보다, 드러나게 하고 반복 가능하게 관리하는 쪽에 더 가깝습니다.

또 한 가지는, semantic layer라는 말이 제품마다 조금씩 다르게 쓰인다는 점입니다. 어떤 곳은 metric 정의 계층에 더 가깝고, 어떤 곳은 BI semantic model에 더 가깝고, 어떤 곳은 partner ecosystem 차원에서 다루기도 합니다. 그래서 개념을 볼 때는 이름보다 실제로 무엇을 중앙에서 고정해주는지부터 보는 편이 더 중요하다고 생각합니다.

결국 중요한 것은 질문과 모델 사이의 거리를 줄이는 일 같습니다

제가 semantic layer를 좋게 보는 이유는, 결국 질문과 모델 사이의 거리를 줄이는 시도이기 때문입니다.

예전에는 이 거리를 분석가나 엔지니어가 SQL 실력으로 메웠습니다. 앞으로는 그 거리를 semantic layer, 서빙 모델, 문서화, 그리고 AI 보조가 함께 메우게 될 가능성이 큽니다.

저는 그래서 semantic layer를 “새로운 유행어” 보다는, AI 시대에 다시 강조될 수밖에 없는 오래된 문제의 재등장처럼 보고 있습니다.

결국 “지표 정의는 중요한데, 매번 SQL에서 다시 만들고 싶지는 않다”는 오래된 고민이 다시 전면으로 나온 셈입니다.

정리

semantic layer는 AI 때문에 갑자기 생긴 개념은 아닙니다. 다만 AI가 SQL을 빨리 만들어주는 시대가 되면서, 오히려 무엇을 어떻게 계산해야 하는가 를 공통 규칙으로 두는 일이 더 중요해졌다고 생각합니다.

결국 SQL 자동화가 늘어날수록, 해석의 기준은 더 엄격하게 관리되어야 합니다. semantic layer는 그 기준을 붙잡아두는 한 가지 방식입니다.

참조 링크

댓글 목록

관리자 보기

관리자 키

YourFiesta Blog