콘텐츠로 바로가기
HY_TECH_BASE

Analytics Engineering & Data Modeling

원천 데이터를 비즈니스 통찰로 연결하는 차원 모델링 기법과 소프트웨어 개발 방법론을 데이터 가공에 입힌 데이터 분석 엔지니어링을 다루는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

애널리틱스 엔지니어링 및 데이터 모델링(Analytics Engineering & Data Modeling, AEM)은 원시 데이터(Raw data)를 정제하여 최종 분석자가 즉시 활용 가능한 신뢰 기반의 데이터 자산(Mart)으로 가공하는 전문 설계 영역을 다룹니다.

데이터 엔지니어가 물리적 이동(Ingestion)을 책임진다면, 애널리틱스 엔지니어는 데이터의 의미적 정제와 모델링을 책임집니다. 학습자는 킴볼(Kimball) 식의 스타 스키마(Star Schema) 차원 모델링 기법, 소프트웨어 엔지니어링의 모듈화/테스트 원칙을 데이터 변환에 적용한 dbt 등의 도구 운영, 그리고 비즈니스 로직의 코드로의 형상 관리를 심도 있게 학습합니다. 이를 통해 '보는 사람마다 숫자가 다른' 데이터 불일치 문제를 물리적으로 해결합니다.

2. Scope & Boundaries

In-Scope

  • Dimensional Modeling: 스타 스키마, 눈송이 스키마(Snowflake), 사실(Fact) 및 차원(Dimension) 정의
  • Analytics Development: 모듈화된 SQL 관리, Jinja 템플릿 기반 데이터 동적 생성
  • Data Testing & Quality: 데이터 테스트 자동화, 스키마 엔포싱 및 도메인 유효성 검증
  • Semantic Layer: 메트릭(Metric) 정의 표준화 및 BI 도구와의 물리적 접점 설계

Out-of-Scope

  • 데이터 파이프라인의 물리적 수송 자체 (06-05 Data Ingestion 영역으로 위임)
  • 시각적 대시보드 디자인 및 UI/UX (12. HCI & Graphics 영역으로 위임)

Boundaries

  • AEM vs. Relational Systems: 06-01(RS)이 '애플리케이션 구동을 위한 정규화 데이터'에 집중한다면, AEM은 '분석 효율을 위한 비정규화 역학 및 집계 기반 모델링'에 집중합니다.

3. Counterexample

  • 단순히 복잡한 쿼리를 작성하여 리포트를 뽑는 것은 AEM 학습이 아닙니다. 중복되는 집계 로직을 어떻게 **중간 모델(Intermediate Model)**로 모듈화하여 관리할지 설계하고, 소스 데이터의 변경이 최종 지표에 미치는 영향을 데이터 계보(Lineage) 관점에서 테스트 코드로 사전에 잡아낼 수 있어야 합니다.

4. Prerequisites

  • 관계형 시스템 기초 (Basic): 고급 SQL(CTE, Window Function)과 조인 성능에 대한 이해가 필수입니다. (06. RS)
  • 데이터 거버넌스 기초 (Recommended): 메타데이터 정의와 품질 지표(DQ) 개념 선행이 권장됩니다. (06. GPE)

5. Learning Map

  1. Analytical Architecture: 분석에 최적화된 데이터가 일반 DB와 어떻게 물리적/논리적으로 다른지 익힙니다.
  2. Structuring Dimensions: 현실의 복잡한 비즈니스 프로세스를 사실(Fact)과 차원(Dimension)으로 분해합니다.
  3. Engineering Workflow: V-모델이나 애자일 방식을 데이터 가공(dbt 등)에 이식하여 관리 체계를 구축합니다.
  4. The Metric Standard: 전사적으로 동일한 숫자를 보장하는 단일 지표 정의 계층(Semantic Layer)을 설계합니다.

6. Learning Topics

Basic

Core: 데이터 모델링 패러다임 (Modeling Paradigms)

  • Why to Learn: 분석 성능을 높이고 사용자가 이해하기 쉬운 데이터 지도를 그리기 위함입니다.
  • What to Learn:
    • 데이터 웨어하우스 설계의 양대 산맥: Inmon(정규화 기반) vs Kimball(차원 기반)
    • OLTP(트랜잭션 최적화)와 OLAP(분석 최적화)의 물리적 데이터 저장 차이
    • 대용량 데이터 환경에서의 비정규화(Denormalization) 전략과 트레이드오프
  • How to Learn:
    • 간단한 쇼핑몰 DB를 거래(Fact)와 기준 정보(Dimension)로 재분리하여 스타 스키마 그려보기
    • 정규화된 테이블 10개를 조인할 때와 스타 스키마에서 쿼리할 때의 물리적 비용 비교 관측
  • Implement: 특정 도메인의 비즈니스 프로세스를 반영한 논리적 차원 모델 설계도

Core: 스타 스키마 및 차원 모델링 실무 (Dimensional Modeling)

  • Why to Learn: 시계열 분석이나 다차원 분석 시의 쿼리 복잡도를 획기적으로 줄이기 위해서입니다.
  • What to Learn:
    • 사실 테이블(Fact Table): 트랜잭션, 누적, 스냅샷 유형 구분
    • 차원 테이블(Dimension Table): 서서히 변화하는 차원(SCD) 처리 기법 (Type 1, 2, 3)
    • 대리 키(Surrogate Key) 사용의 물리적 이유와 비즈니스 키 분리 전략
  • How to Learn:
    • 과거 이력이 변할 때(예: 고객의 주소 변경) 기존 데이터와의 연결성을 유지하는 SCD Type 2 로직 실습
    • 정크 차원(Junk Dimension) 등을 활용하여 테이블 파편화를 막는 물리 배치 연구
  • Implement: 데이터의 역사적 변천(SCD)을 추적할 수 있는 상세 데이터 모델링 명세서

Practical

Core: 애널리틱스 코드 개발 및 워크플로우 (Analytics Development)

  • Why to Learn: SQL 산란(SQL Sprawl)을 막고 데이터 가공 과정을 소프트웨어처럼 관리하기 위함입니다.
  • What to Learn:
    • dbt(data build tool)의 핵심: Select 문 하나로 모델-테스트-문서화 자동화
    • CTE(Common Table Expressions)를 이용한 복잡한 가공 로직의 가독성 및 모듈화
    • 환경 분리: 개발(Dev) → 검증(Stage) → 운영(Prod) 환경의 물리적 격리 및 배포
  • How to Learn:
    • dbt를 이용해 원시 데이터(Staging)부터 최종 마트(Mart)까지 흐르는 파이프라인 구축 실습
    • 특정 모델의 부모/자식 관계를 계보도(Lineage Graph)로 확인하며 의존성 이슈 디버깅
  • Implement: 재사용 가능한 매크로와 테스트 라이브러리가 포함된 dbt 프로젝트 구조 설계

Advanced

Core: 품질 자동화 및 지표 표준화 (Semantic Layer & QA)

  • Why to Learn: 대규모 조직에서 데이터 신뢰성을 100% 확보하고 '지표의 난'을 해결하기 위해서입니다.
  • What to Learn:
    • 의미 계층 (Semantic Layer): BI 도구 전 단계에서 지표 정의를 코드로 관리하는 기술
    • 데이터 계약(Data Contracts): 상류 소스 변경 시 분석 파이프라인의 안전 보장 물리
    • CI/CD 통합: PR 시 데이터 정합성 자동 검증 및 영향도 리포트 생성
  • How to Learn:
    • '매출' 정의가 팀마다 다른 사례를 분석하고, 전사 공통 지표 코드로 단일화하는 과정 연구
    • 샘플 데이터를 생성하여 데이터 테스트(null 체크, unique 체크 등)의 실패 상황 유도 및 대응 실습
  • Implement: 데이터 원천 변경에 따른 하류 영향도를 자동으로 통보하는 모니터링 대시보드 구성

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core/misused/legacy)
Star Schema 분석의 핵심인 사실(Fact) 테이블을 중심으로 설명용인 차원(Dimension) 테이블이 둘러싼 형태의 모델입니다. 기본 모델링 표준 Fact / Dimension Snowflake 단순히 '별 모양'으로만 오해 P4:DS-BoK Modeling core
Analytics Engineering 데이터 엔지니어링과 분석 사이에서, 소프트웨어 엔지니어링 기법을 이용해 깨끗한 데이터를 만드는 직관입니다. 실무 업무 패러다임 dbt / Modeling Data Analysis 단순히 'SQL 작성'으로 오해 Industry Labs Definition core
SCD 시간에 따라 천천히 변화하는 차원 속성을 관리하는 기술적 방법론입니다. 추천 이력 관리 Versioning History 실시간 변경과 혼동함 P4:DS-BoK Warehousing core
Semantic Layer 서로 다른 도구에서 동일한 지표를 볼 수 있도록 데이터 정의를 한곳에서 관리하는 중앙 집중식 추상화 계층입니다. 심화 지표 표준화 Metrics LookML / MetricFlow 단순 '뷰(View)'로 오해 Industry Data Stack core

8. References

Primary References

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)을 정의하고 합의를 이끌어낼 수 있는가?

Concepts & Tags

#analytics-engineering#data-modeling#dimension-modeling#dbt