Analytics Engineering & Data Modeling

1. Overview

애널리틱스 엔지니어링 및 데이터 모델링(Analytics Engineering & Data Modeling, AEM)은 데이터 레이크에 무질서하게 쏟아진 수백 기가바이트의 원시 데이터(Raw data) 늪에서, 경영진과 분석가가 1초 만에 비즈니스 통찰을 얻어낼 수 있는 정갈하고 완벽한 형태의 '별(Star)'자리 지도를 깎아내는 소프트웨어 공학과 데이터 모델링의 결합체입니다.

과거에는 수백 줄의 엉킨 SQL 스파게티 코드가 데이터베이스 어딘가에 숨어 돌아갔지만, 현대의 애널리틱스 엔지니어는 데이터 변환(Transformation) 과정을 하나의 '소프트웨어 제품'으로 취급합니다. 학습자는 킴볼(Kimball)의 차원 모델링(Dimensional Modeling)을 통해 복잡한 비즈니스 프로세스를 사실(Fact)과 차원(Dimension)이라는 명확한 구조로 분해합니다. 나아가 dbt(data build tool)와 같은 최신 프레임워크를 무기로 SQL을 모듈화(Jinja 템플릿)하고, 데이터가 변환될 때마다 null 값이나 중복 여부를 자동 검증(Data Testing)하여, 전사적으로 '모두가 동일한 숫자를 바라보는' 진실의 단일 공급원(Single Source of Truth)을 구축하는 역량을 갖춥니다.

2. Scope & Boundaries

In-Scope

• 차원 모델링 아키텍처 (Dimensional Modeling): 킴볼(Kimball) 방식의 스타 스키마(Star Schema), 눈송이 스키마(Snowflake Schema), 대리 키(Surrogate Key) 발급 물리.
• 사실과 차원 설계 (Facts & Dimensions): 트랜잭션 사실, 누적 스냅샷(Accumulating Snapshot), 서서히 변화하는 차원(SCD Type 1, 2, 3)의 물리적 이력 추적.
• 애널리틱스 옵스 워크플로우 (Analytics Ops): dbt 기반의 SQL 모듈화(CTE 활용), Jinja 템플릿 제어, 개발/운영(Dev/Prod) 환경 격리와 CI/CD 자동화 배포.
• 품질 보증과 의미 계층 (QA & Semantic Layer): 데이터 어설션(Data Assertion) 테스트, 데이터 계보(Lineage) 추적, 전사 지표 표준화를 위한 시맨틱 레이어(Metric Store).

Out-of-Scope

• 최종 시각화 대시보드의 렌더링 물리: Tableau나 Superset에서 차트를 그릴 때의 브라우저 렌더링이나 UI 디자인 → 12-01. HCI & Graphics 영역으로 위임.
• 머신러닝 피처 스토어 설계: AI 모델 학습을 위해 실시간 서빙 지연(Latency)을 마이크로초로 낮춘 극단적 피처 저장소 → 11-04. ML Engineering 영역으로 위임.

Boundaries

• AEM vs. Relational Systems (06-01): 06-01(RS)의 모델링이 '중복 데이터를 없애고(정규화) INSERT를 빨리 하기 위한 애플리케이션용 뼈대'라면, AEM의 모델링은 **'디스크 공간을 낭비하더라도(비정규화) 수십 억 건의 데이터를 JOIN 없이 단 1초 만에 GROUP BY 하기 위한 분석용 뼈대'**라는 상반된 목적 함수를 가집니다.

3. Counterexample

• 분석 시스템에서의 과도한 3정규화 강박 (Modeling Fallacy): 애플리케이션 개발 출신 엔지니어가 데이터 웨어하우스를 설계하면서, 저장 공간을 아끼겠다고 상품 카테고리를 대-중-소 분류 테이블 3개로 쪼개고(3NF) 팩트 테이블에 조인(Join)을 걸어버리는 행위. 10억 건의 구매 이력을 분석할 때마다 이 3개의 테이블을 런타임에 엮어내느라 쿼리가 30분씩 도는 참사가 발생합니다. 데이터 웨어하우스에서는 카테고리 대-중-소 컬럼을 하나의 차원(Dimension) 테이블에 때려 박는(비정규화, 스타 스키마) 공간 대비 연산(Compute) 최적화 트레이드오프 원칙을 무시한 치명적 안티패턴입니다.
• 스파게티 SQL과 지표의 난 (Analytics Ops Fallacy): 매출을 구하는 똑같은 로직의 SQL 문이 마케팅팀의 태블로(Tableau), 재무팀의 엑셀, 영업팀의 크론(Cron) 스크립트에 제각각 하드코딩되어 파편화된 상황. 세금 정책이 바뀌어 로직을 하나 수정해야 할 때, 어디에 쿼리가 숨어있는지 몰라 전사 대시보드 매출액이 수백억 원씩 오차를 내며 붕괴합니다. dbt와 같은 도구를 통해 SQL을 중앙에서 **버전 관리(Git)되는 모듈화된 뷰(View)**로 만들고, 의존성 트리(DAG)를 태우지 않은 분석 환경은 모래성입니다.

4. Prerequisites

• 관계형 시스템 (Basic): 고급 SQL (CTE, 윈도우 함수)과 테이블 간의 조인(Inner/Left/Full) 비용에 대한 메커니즘을 숙지해야 거대한 집계 모델을 짤 수 있습니다. (06-01. RS)
• 버전 관리와 CI/CD (Recommended): 데이터 파이프라인도 소프트웨어처럼 Git으로 커밋하고 Pull Request로 리뷰를 받아야 하므로 기초적인 형상 관리 지식이 권장됩니다. (09-02. Version Control)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 데이터 모델링 패러다임과 비정규화 역학 (Modeling Paradigms)

• Why to Learn: 백엔드 개발자의 머릿속에 박힌 "중복은 악이다"라는 정규화 강박을 깨부수고, 분석 환경의 물리 법칙에 맞는 뇌구조로 세팅하기 위함입니다.
• What to Learn:
  • Concepts: OLTP(트랜잭션) vs OLAP(분석), 정규화(Normalization) vs 비정규화(Denormalization).
  • Skills: 인몬(Inmon)의 전사적 통합 DW 접근법 vs 킴볼(Kimball)의 버스 아키텍처(Bus Architecture) 및 데이터 마트(Mart) 접근법 비교, 조인(Join) 폭발로 인한 메모리 OOM(Out of Memory) 분석.
  • Tools: ERD 다이어그램 도구 (dbdiagram.io).
  • Trade-offs: 정규화를 통해 업데이트(Update) 정합성을 맞추고 디스크 용량을 절약하는 것 vs 비정규화를 통해 중복을 허용하더라도 조인 연산을 0으로 만들어 10배 빠른 읽기 속도를 챙기는 빅데이터 철학.
• How to Learn:
  • 1단계: 주문-회원-주소-결제수단 4개 테이블로 쪼개진 3정규화(3NF) DB 모델에서 "서울에 사는 20대 여성의 신용카드 구매액"을 뽑기 위한 4단 조인 쿼리 비용(Explain Plan)을 도출합니다.
  • 2단계: 이를 1개의 '주문 팩트' 테이블과 컬럼 20개짜리 뚱뚱한 '고객 차원' 테이블 1개로 합쳐버린 비정규화 구조(Star Schema)에서, 조인 1번만으로 동일한 답을 훨씬 빠르게 도출하는 물리적 메모리 액세스 패러다임을 증명합니다.
• Implement: 특정 도메인(예: 배달 앱)의 복잡한 RDBMS 스키마를 입력받아, 분석가들이 쿼리하기 가장 좋은 형태의 평탄화된(Flattened) 와이드 테이블(Wide Table) 형태로 DDL을 재작성하는 모델링 명세서.

Recommended

Core Topic 02: 킴볼 차원 모델링과 이력 추적 (Dimensional Modeling & SCD)

• Why to Learn: 어제는 서울 지점 매출로 잡혔던 건이, 오늘 고객이 부산으로 이사 갔다고 해서 과거의 서울 지점 매출까지 부산으로 업데이트되어 버리는 통계 왜곡의 재앙을 막기 위해서입니다.
• What to Learn:
  • Concepts: 스타 스키마(Star Schema), 사실(Fact Table), 차원(Dimension Table), 대리 키(Surrogate Key).
  • Skills: 트랜잭션 사실(주문 1건), 주기적 스냅샷 사실(매월 잔고), 누적 스냅샷 사실(주문-배송-완료 생애주기)의 설계 분기, 서서히 변화하는 차원(SCD: Slowly Changing Dimension) Type 1, 2, 3 제어 물리.
  • Tools: DDL / DML SQL 스크립팅.
  • Trade-offs: 고객 주소가 바뀔 때 덮어씌워 버리는 SCD Type 1(과거 통계 왜곡 리스크, 구현 극히 간단) vs 기존 로우를 만료시키고 새 주소를 가진 새 로우를 만들어 대리 키(Surrogate Key)를 새로 따는 SCD Type 2(완벽한 과거 이력 보존, 테이블 크기 팽창 및 복잡도 증가).
• How to Learn:
  • 1단계: 고객 테이블의 기본키(주민번호)를 그대로 분석 DW의 기본키로 가져왔을 때, 해당 고객이 부서를 이동하면 과거 실적과 현재 실적을 테이블 구조적으로 분리해 낼 방법이 없음을 증명하는 안티패턴을 분석합니다.
  • 2단계: 시스템이 1, 2, 3... 자동 증가 번호를 부여하는 무의미한 '대리 키(Surrogate Key)'를 차원 테이블의 PK로 삼고, start_date와 end_date 컬럼을 활용해 한 명의 고객을 시간대별(서울 거주 시절, 부산 거주 시절)로 두 개의 로우(SCD Type 2)로 쪼개어 사실 테이블과 결합시키는 타임머신 모델링을 구현합니다.
• Implement: 고객의 프로필 변경 이력(JSON 로그)을 쭉 입력받으면, 변경된 시점의 유효 날짜 구간을 계산하여 SCD Type 2 구조의 차원 테이블 INSERT / UPDATE 문을 동적으로 생성하는 모델링 스크립트.

Practical

Core Topic 03: 애널리틱스 옵스 워크플로우 (Analytics Ops & dbt)

• Why to Learn: 누더기처럼 기워진 1,000줄짜리 프로시저(Stored Procedure)의 늪에서 탈출해, SQL 쿼리도 파이썬 함수처럼 변수화하고 재사용 가능한 소프트웨어 모듈로 조립하는 모던 워크플로우를 장착하기 위해서입니다.
• What to Learn:
  • Concepts: CTE(Common Table Expression) 체인, 매크로(Macro)와 Jinja 템플릿 렌더링, 증분 모델(Incremental Model).
  • Skills: dbt(data build tool)를 활용한 의존성(Ref) 그래프 선언, 소스(Source) 시스템과 모델의 물리적 분리, 개발/스테이지/운영(Dev/Stg/Prod) 환경 분리를 위한 DWH 스키마 타겟팅 물리.
  • Tools: dbt Core, Jinja2, Git.
  • Trade-offs: 매일 수십 기가의 테이블을 드롭(Drop)하고 CREATE TABLE AS SELECT로 바닥부터 새로 깔아 1시간씩 걸리지만 논리가 가장 깔끔한 테이블 재생성(Full Refresh) vs 새로 들어온 100건만 쏙 빼서 기존 테이블에 MERGE 시켜 10초 만에 끝나지만, 삭제(Delete) 로직을 잡기 더러운 증분 적재(Incremental) 모델.
• How to Learn:
  • 1단계: 날짜별로 쪼개진 raw_202401, raw_202402 테이블을 UNION ALL 하느라 쿼리가 지저분해지는 상황에서, Jinja 템플릿의 for loop를 사용해 단 5줄의 코드로 수백 개 테이블을 동적 유니온하는 매크로 컴파일(Compile) 역학을 스케치합니다.
  • 2단계: A 모델을 만들고, A를 참조({{ ref('A') }})하는 B 모델과 C 모델을 선언했을 때, 시스템이 스스로 DAG(의존성 그래프)를 그려 A를 돌린 직후 B와 C를 백그라운드 스레드로 동시 병렬(Parallel) 실행하는 오케스트레이션 실행 플랜을 분석합니다.
• Implement: 3단계(Staging → Intermediate → Mart)로 이루어진 SQL 변환 로직에 Jinja 변수({{ ref(...) }})를 삽입하여, 단일 명령(dbt run)으로 타겟 DB에 뷰(View)와 테이블(Table)이 올바른 순서대로 물리적(DDL) 생성되는 로컬 컴파일러 프로젝트.

Advanced

Core Topic 04: 품질 자동화와 시맨틱 레이어 (Quality QA & Semantic Layer)

• Why to Learn: "어제 대시보드에서는 매출이 10억이었는데, 오늘은 왜 9억이 나오나요?"라는 비즈니스 부서의 불신 폭주를 사전에 차단하고, 100% 무결점 지표를 선언하는 '진실의 단일 출처(SSOT)'를 구축하기 위해서입니다.
• What to Learn:
  • Concepts: 데이터 품질 보증(Data QA), 시맨틱 레이어(Semantic Layer, 의미 계층), 데이터 계약(Data Contracts), 이상치 탐지(Anomaly Detection).
  • Skills: dbt Test (Unique, Not Null, Accepted Values)를 활용한 자동 어설션(Assertion) 방어벽 구축, 중앙 집중식 Metric Store (LookML, Cube.js) 논리 구조 설계.
  • Tools: dbt Tests, Datafold (데이터 회귀 테스트), Cube.
  • Trade-offs: BI 도구(Tableau) 안에 "결제 완료 건수 = A+B"라는 수식을 하드코딩해 시각화 전문가가 빠르게 작업하는 유연성 vs BI 도구를 바꿀 때마다 로직을 다 다시 짜야 하는 참사를 막기 위해, DB와 BI 사이에 중앙 지표 정의서(Semantic Layer) 서버를 강제로 두어 거버넌스는 잡지만 초기 인프라 복잡도가 폭증하는 중앙 집중화.
• How to Learn:
  • 1단계: 개발자가 주문 로직을 살짝 바꾼 코드를 PR(Pull Request)로 올렸을 때, CI 파이프라인이 백그라운드에서 가상 DB를 띄우고 테스트 데이터를 부어 "기본키 중복(Not Unique) 발생!"이라는 에러를 토해내며 배포를 자동 차단하는 품질 게이트 역학을 설계합니다.
  • 2단계: '활성 사용자(Active User)'라는 지표를 마케팅팀은 '로그인한 자', 영업팀은 '장바구니에 넣은 자'로 다르게 정의하는 대혼돈을 막기 위해, YAML 파일 1개에 metric: active_user, sql: count(distinct case when ...)라고 법전처럼 박아두고, 모든 엑셀과 대시보드가 이 중앙 서버 API를 찌르도록 강제하는 시맨틱 통제 물리망을 스케치합니다.
• Implement: 특정 마트 테이블의 메타데이터(YAML)를 읽어, 설정된 테스트 조건(예: column: id, tests: [unique, not_null])에 부합하는 SELECT COUNT(*) 검증 SQL을 동적으로 생성하고, 실행 결과가 0이 아니면 시스템 콘솔에 치명적 알람(Alert)을 띄우는 QA 봇 뼈대.

7. Terminology

8. References

Primary References

• [P4] DS-BoK - Data Modeling & Warehousing — Analytical structures.
• [P5] SFIA - Business Intelligence / Data Analytics — Industry data modeling skills.

Secondary References

• [The Data Warehouse Toolkit] Ralph Kimball — The "Bible" of dimensional modeling.
• [Fundamentals of Analytics Engineering] online series — New paradigm guide.

Industry References

• [dbt Documentation - Best Practices] — Modern execution standard.
• [Modern Data Stack Whitepapers] — Integration of modular analytics tools.

9. Final Checklist

Primary Checklist

• 특정 비즈니스 질문(예: 지난달 지역별 매출 추이)을 해결하기 위해 어떤 Fact와 Dimension이 물리적으로 필요한지 식별 가능한가? (P4, P5)
• 스타 스키마가 눈송이 스키마(Snowflake) 대비 분석 쿼리 성능(Join 횟수 관점)에서 왜 유리한지 설명할 수 있는가? (P4)

Secondary Checklist

• 소스 데이터의 중복 행(Row) 발생 시 이를 최종 마트 단계에서 어떻게 물리적으로 유일성을 보장(Deduplication)할지 제안 가능한가?
• dbt의 'incremental' 모델이 전체 테이블을 다시 빌드하는 것 대비 가지는 리소스 및 시간적 이득을 인지하고 있는가?

Industry Checklist

• 전사 대시보드의 숫자가 틀렸을 때, 데이터 계보(Lineage)를 보고 어느 가공 단계에서 수식이 오류가 났는지 3분 내에 추적 가능한가? (SFIA)
• 데이터 분석가와 데이터 엔지니어 사이에서 '변환 완료된 데이터'의 품질 기준(Data Contract)을 정의하고 합의를 이끌어낼 수 있는가?