좋은 데이터 모델은 저장이 아니라 질문을 위해 존재합니다

6 분 소요

데이터 모델링 이야기를 하다 보면 대화가 쉽게 구조 쪽으로 흘러갑니다. 정규화가 맞는가, 스타 스키마가 맞는가, 와이드 테이블이 맞는가, 레이크하우스가 좋은가 같은 질문들이 먼저 나옵니다. 물론 이런 논의는 중요합니다. 다만 실무에서는 모델이 실패하는 이유가 구조가 덜 예뻐서인 경우보다, 질문에 안정적으로 답하지 못해서인 경우가 더 많았습니다.

저는 좋은 데이터 모델을 저장을 잘하는 구조라기보다, 질문에 반복 가능하게 답할 수 있는 구조라고 생각합니다. 데이터를 잘 쌓는 것과 질문에 잘 답하는 것은 비슷해 보이지만 실제로는 꽤 다릅니다. 적재는 성공했는데 해석은 흔들리는 모델, 로그는 풍부한데 지표는 매번 달라지는 모델, 컬럼은 많은데 정작 중요한 질문에는 답하기 어려운 모델은 생각보다 흔합니다.

이 글에서는 데이터 웨어하우스 모델링을 볼 때 왜 저장 구조보다 질문 가능성을 먼저 봐야 하는지 정리해보겠습니다.

한눈에 보는 핵심

좋은 데이터 모델은 데이터를 예쁘게 저장하는 구조가 아니라, 비즈니스 질문에 반복 가능하게 답할 수 있도록 만드는 구조입니다.

질문 중심으로 다시 정리하면 좋은 모델은 보통 아래 조건을 만족합니다.

같은 질문을 여러 사람이 반복해도 결과가 크게 흔들리지 않습니다.
특정 시점 상태를 설명할 수 있습니다.
늦게 들어온 데이터나 재처리 이후에도 결과를 해석할 수 있습니다.
쿼리 복잡도를 모델 쪽에서 흡수합니다.

데이터 모델링 논의가 자꾸 저장 구조로만 흐르는 이유

데이터 엔지니어는 본능적으로 저장 구조를 먼저 보게 됩니다. 어떤 키를 쓸지, 어떤 테이블로 나눌지, 중복을 얼마나 허용할지, 증분 적재를 어떻게 할지 같은 문제는 실제 운영과 직결되기 때문입니다. 특히 데이터가 커지고 파이프라인이 복잡해질수록 저장 구조는 비용과 안정성을 크게 좌우합니다.

문제는 이 관점이 너무 앞에 오면 모델의 목적이 흐려진다는 점입니다. 웨어하우스는 원본 로그를 잘 보존하는 창고인 동시에, 반복되는 질문에 일관되게 답하는 해석 계층이기도 합니다. 그런데 저장 구조만 앞세우면 이런 질문이 뒤로 밀립니다.

이 모델은 어떤 대표 질문에 답해야 하는가
이 테이블의 grain은 무엇인가
특정 시점 상태를 복원할 수 있는가
지표 정의가 팀 안에서 일관되게 유지되는가
늦게 들어온 데이터나 백필에도 결과를 설명할 수 있는가

실무에서 모델의 품질은 결국 이런 질문 앞에서 드러납니다.

저장 중심 모델과 질문 중심 모델은 무엇이 다른가

구분	저장 중심 모델	질문 중심 모델
우선순위	원본 보존, 적재 안정성, 중복 최소화	해석 일관성, 질문 재현성, 소비 편의성
주요 관심사	저장 구조	질문 대응 구조
장점	적재 안정성	해석 안정성
흔한 문제	로그는 풍부하지만 질문이 어려움	모델 구축 비용 증가 가능성

저장 중심 모델이 나쁘다는 뜻은 아닙니다. 오히려 원본을 잃지 않고, 증분 적재가 가능하고, 운영이 안정적이어야 그 다음 단계도 존재할 수 있습니다. 다만 웨어하우스의 소비 계층으로 갈수록, 즉 지표와 분석과 의사결정에 가까워질수록 질문 중심 사고가 더 중요해집니다. 저는 이 지점에서 데이터 엔지니어의 역할이 단순 적재를 넘어서기 시작한다고 봅니다.

적재 성공만으로는 충분하지 않습니다

적재 성공은 필요조건입니다. 하지만 그것만으로는 충분하지 않습니다. 원본 이벤트가 빠짐없이 적재되었다고 해서 분석이 쉬워지는 것은 아닙니다. 오히려 이벤트 로그만 가득한 상태에서는 같은 질문도 사람마다 다르게 풀게 됩니다.

예를 들어 “지난 7일 활성 유저 수”를 계산한다고 해보겠습니다. 저장 중심 관점에서는 로그인, 클릭, 구매, 세션 시작 같은 이벤트가 잘 쌓여 있으면 준비가 된 것처럼 보입니다. 하지만 질문 중심 관점에서는 그 다음 질문이 더 중요합니다.

활성의 기준 이벤트는 무엇인가
기준일은 이벤트 발생일인가 적재일인가
중복 이벤트는 어떻게 제거하는가
시차가 있는 데이터는 어느 시점까지 허용하는가
백필 이후 과거 수치를 어떻게 다룰 것인가

이 질문들이 정리되지 않으면 데이터는 쌓여 있어도 답은 흔들립니다. 저는 이 차이가 저장 중심 모델과 질문 중심 모델의 핵심 차이라고 생각합니다.

이벤트 로그만으로는 왜 답이 흔들릴까

아래 흐름은 실무에서 자주 보는 패턴입니다.

flowchart TD
    A[원본 이벤트 로그는 잘 쌓입니다] --> B[질문이 들어옵니다]
    B --> C{질문에 바로 답할 수 있습니까?}
    C -- 아니오 --> D[각자 다른 SQL로 복원합니다]
    D --> E[정의가 조금씩 달라집니다]
    E --> F[같은 지표인데 결과가 달라집니다]
    F --> G[모델을 다시 설계해야 합니다]
    C -- 예 --> H[일관된 모델에서 반복 조회합니다]

이 흐름의 핵심은 단순합니다. 로그는 풍부할 수 있지만, 풍부한 로그가 곧 질문 가능성을 보장하지는 않습니다. 반복해서 나오는 질문이라면 결국 질문을 받아줄 모델이 따로 필요합니다.

질문 중심 모델이 특히 필요한 순간들

1. 이벤트 로그만으로는 상태 질문이 풀리지 않을 때

“이 유저는 3월 1일 기준 활성 상태였는가” 같은 질문은 이벤트 로그만으로도 이론상 계산할 수 있습니다. 하지만 매번 복원 로직을 새로 짜야 한다면 실용적이지 않습니다. 이런 질문이 반복된다면 snapshot, transition, interval 같은 상태 모델이 필요합니다.

2. 같은 지표가 팀마다 다르게 계산될 때

활성 유저, 복귀 유저, 휴면 유저, 전환 유저 같은 지표는 단어는 같아도 구현이 달라지기 쉽습니다. 저장은 잘 되어 있어도 정의가 분산되어 있으면 조직 안에서는 다른 숫자가 동시에 살아남습니다. 질문 중심 모델은 이런 해석 분산을 줄이는 데 목적이 있습니다.

3. 분석가가 매번 복잡한 SQL을 새로 짜야 할 때

모델이 질문을 받아주지 못하면 사람의 SQL이 그 공백을 메웁니다. 이때 생기는 문제는 단순히 불편함이 아닙니다. 같은 질문이 매번 다른 쿼리로 구현되고, 작은 조인 차이나 날짜 조건 차이로 결과가 흔들리기 시작합니다. 질문 중심 모델은 SQL을 없애는 것이 아니라, 반복되는 복잡성을 모델 쪽으로 옮겨오는 일에 가깝습니다.

4. 백필 이후 과거 수치를 설명하기 어려울 때

늦게 도착한 데이터, 재처리, 기준 변경은 운영 환경에서 피하기 어렵습니다. 이때 중요한 것은 숫자가 바뀌지 않는 것이 아니라, 왜 바뀌었는지 설명할 수 있는 구조를 갖고 있는가입니다. 질문 중심 모델은 결과값뿐 아니라 결과를 재현하는 규칙까지 함께 관리해야 합니다.

예시로 보면 더 분명합니다

예시 1. 활성 유저 수

저장 중심 관점에서는 이벤트만 잘 쌓이면 준비가 끝난 것처럼 보입니다. 하지만 실제 질문은 그 뒤부터 시작됩니다.

어떤 이벤트를 활성로 볼 것인가
집계 기준일은 무엇인가
이벤트 지연은 어디까지 허용할 것인가

이런 기준이 모델에 반영되지 않으면 활성 유저 수는 매번 다른 SQL로 다시 정의됩니다.

예시 2. 특정 시점 상태 복원

“3월 1일 기준 이 유저는 활성/휴면/이탈 중 무엇이었는가” 같은 질문은 이벤트 로그만으로도 계산 가능하지만, 운영 환경에서는 매우 비쌉니다. 이런 질문이 자주 나온다면 snapshot, transition, interval 같은 상태 모델을 두는 편이 낫습니다.

예시 3. 백필 이후 수치 변화

늦게 들어온 이벤트 때문에 지난달 활성 유저 수가 바뀌는 상황은 흔합니다. 이때 중요한 것은 숫자가 바뀌지 않는 것이 아니라, 바뀐 이유와 재계산 규칙을 설명할 수 있는가입니다. 질문 중심 모델은 결과를 저장하는 것에서 끝나지 않고, 결과를 재현하는 기준까지 같이 관리해야 합니다.

그래서 데이터 엔지니어는 무엇을 먼저 정의해야 하는가

저는 새 모델을 설계할 때 구조보다 먼저 아래 항목을 명확히 하는 편이 낫다고 생각합니다.

1. 이 모델의 대표 질문

테이블이 어떤 질문을 받아야 하는지 먼저 정해야 합니다. 예를 들어 유저 상태 테이블이라면 다음 같은 질문이 명확해야 합니다.

특정 날짜 기준 유저 상태는 무엇인가
상태 변화는 언제 일어났는가
활성/휴면/복귀 전환을 어떻게 집계하는가

이 질문이 먼저 정리되면 어떤 모델이 필요한지도 더 명확해집니다.

2. Grain

질문 중심 모델에서 grain은 매우 중요합니다. 유저-일 단위인지, 유저-상태변화 시점 단위인지, 유저-활동일 단위인지에 따라 해석 범위가 완전히 달라집니다. grain이 불분명하면 질문이 흔들리고, 질문이 흔들리면 쿼리도 흔들립니다.

3. 기준일과 시점 정의

event_date, effective_date, snapshot_date를 구분하지 않으면 상태 모델은 쉽게 틀어집니다. 특히 늦게 들어온 데이터가 있는 환경에서는 기준일을 명시적으로 관리해야 과거 수치를 설명할 수 있습니다.

4. 재처리 전략

질문에 답하는 모델은 결국 다시 계산될 수 있어야 합니다. 부분 재처리인지 전체 재빌드인지, 과거 구간 수정이 가능한지, 결과 변경을 어떻게 전달할지까지 생각해야 모델이 운영을 버팁니다.

질문 중심으로 설계할 때 최소 체크리스트

이 모델의 대표 질문이 한 문장으로 정의되어 있습니까?
grain이 명확합니까?
기준일과 시점 정의가 분리되어 있습니까?
반복 질의 시 결과가 일관됩니까?
재처리 이후 숫자 변경을 설명할 수 있습니까?
SQL 복잡도를 모델이 흡수하고 있습니까?

이 체크리스트를 통과하지 못한다면, 저장은 잘 되어 있어도 아직 질문을 잘 받는 모델이라고 말하기는 어렵습니다.

모델링은 예쁜 구조를 고르는 일이 아니라 질문을 고정하는 일입니다

데이터 모델링을 오래 할수록 구조의 아름다움보다 해석의 안정성이 더 중요하다는 생각을 하게 됩니다. 사용자가 쉽게 읽을 수 있고, 같은 질문에 같은 방식으로 답할 수 있고, 시간이 지나도 결과를 설명할 수 있는 모델이 결국 오래 갑니다.

저는 좋은 데이터 모델이란 데이터를 보기 좋게 저장하는 구조가 아니라, 비즈니스 질문을 반복 가능하게 만드는 구조라고 생각합니다. 저장은 출발점이지만 목적지는 아닙니다. 웨어하우스는 데이터를 쌓기 위한 장소이면서 동시에 질문을 고정하기 위한 장치여야 합니다.

결국 데이터 엔지니어가 만드는 것은 테이블만이 아닙니다. 조직이 같은 숫자를 같은 의미로 말할 수 있게 만드는 해석의 기반에 더 가깝습니다. 그래서 저는 모델을 설계할 때마다 저장보다 질문을 먼저 떠올리려고 합니다. 그 순서가 바뀌면 구조는 그럴듯해 보여도, 정작 가장 중요한 답변 가능성이 빠지기 쉽기 때문입니다.

댓글 목록

관리자 보기

관리자 키

YourFiesta Blog