476. OLAP (Online Analytical Processing)와 비정규화

⚠️ 이 문서는 "올해 20대 남성이 가장 많이 산 물건이 뭐야?"라는 사장님의 질문에 대답하기 위해, **수억 건의 데이터를 뒤적거리는 무거운 쿼리가 진짜 서비스(결제 시스템)를 마비시키는 것을 막고자 별도로 분리해 낸 '분석 전용 읽기 깡패 시스템(OLAP)'**을 다룹니다.

핵심 인사이트 (3줄 요약)

본질: 현재 굴러가는 비즈니스가 아니라, 과거의 데이터(수억 건)를 긁어모아 엑셀의 피벗 테이블처럼 이리저리 돌려가며 다차원(Multi-dimensional)으로 분석하는 시스템이다.

주요 작업: 데이터 변경(INSERT, UPDATE)은 밤에 한 번만 몰아서 하고, 낮에는 오직 복잡한 통계용 조회(SELECT)만 엄청나게 발생하는 극단적인 읽기 전용 환경이다.

설계 철학: 조인(JOIN) 횟수를 줄여서 쿼리 속도를 높이기 위해, 쪼개놨던 테이블들을 다시 억지로 합쳐서 데이터를 중복시키는 **'비정규화(Denormalization)'**가 필수적인 설계 원칙이다.

Ⅰ. 개요: 1억 번의 조인(JOIN)을 피하는 법 (Context & Necessity)

정규화가 잘 된 OLTP(475번 문서) 시스템에서 통계를 내려면 이런 쿼리를 짜야 한다.

SELECT ... FROM 주문 JOIN 고객 JOIN 상품 JOIN 매장 JOIN 지역 ...
1억 건의 주문 데이터를 5번이나 조인하면 DB는 3시간 동안 멈춰버리고 아무도 결제를 할 수 없게 된다.

그래서 똑똑한 아키텍트들은 시스템을 두 개로 찢었다.

OLTP (결제용 서버): 고객들이 물건 사는 서버. 아주 빠름.
OLAP (분석용 서버): 매일 밤 12시에 OLTP 서버에서 그날 팔린 데이터를 복사해 온다. 이때 5개의 테이블을 미리 조인(JOIN)해서 **하나의 거대한 뚱뚱한 테이블(비정규화)**로 뭉쳐놓는다.

다음 날 아침 사장님이 OLAP 서버에 똑같은 통계 쿼리를 날리면? 조인할 필요 없이 뚱뚱한 테이블 하나만 풀 스캔(Full Scan)하면 되니까 3시간짜리 쿼리가 3분 만에 끝난다!

📢 섹션 요약 비유: OLTP가 **'정갈하게 분류된 도서관(정규화)'**이라면, OLAP는 **'도서관의 책들을 모조리 복사해서 내가 발표할 주제에 맞게 오려 붙인 뚱뚱한 스크랩북(비정규화)'**과 같습니다. 스크랩북을 만드는 데는 밤새 시간이 걸리지만, 다음 날 발표할 때(통계 낼 때)는 그 스크랩북 한 권만 훌훌 넘기면 되니까 엄청 빠르죠.

Ⅱ. OLAP의 핵심 설계 원칙: 비정규화 ★

"정규화가 무결성을 위한 신의 계시라면서요?" 맞다. 하지만 OLAP에서는 데이터 무결성을 걱정할 필요가 없다. 어차피 아무도 데이터를 고치지 않기(Read-only) 때문이다.

1. 비정규화 (Denormalization)의 강제

일부러 데이터의 중복을 허용한다.
주문 데이터 옆에 고객 이름과 상품 이름을 다 텍스트로 박아버린다.
장점: 조인(JOIN)이 없어져서 CPU와 메모리 소모가 극단적으로 줄어든다. 읽기 성능 최고.

2. 다차원 모델링 (Multi-dimensional Modeling)

OLAP은 데이터를 큐브(Cube) 모양으로 상상한다.
X축(시간), Y축(지역), Z축(상품). 이 큐브를 돌려가며 "서울에서, 4월에 팔린, 텀블러 매출"을 엑셀 피벗 테이블처럼 쑥쑥 뽑아낸다. (이를 롤업, 드릴다운 연산이라고 부름 - 479번 문서)

Ⅲ. OLTP vs OLAP 완벽 비교

정보처리기사와 백엔드 기술 면접의 단골 손님이다.

구분	OLTP (온라인 트랜잭션 처리)	OLAP (온라인 분석 처리)
목적	현재 비즈니스의 운영 (결제, 가입)	과거 데이터의 분석 (통계, 의사결정)
주요 연산	짧고 빠른 `INSERT`, `UPDATE`	길고 무거운 `SELECT` (집계, GROUP BY)
설계 철학	정규화 (중복 제거, 일관성 유지)	비정규화 (중복 허용, 조회 속도 올인)
인덱스	꼭 필요한 것만 최소한으로 (B-Tree)	온갖 조건에 다 걸어둠 (비트맵 인덱스 등)
사용자	불특정 다수의 고객 (수만 명)	내부 임원, 데이터 분석가 (소수)

┌──────────────────────────────────────────────────────────────┐
│           OLTP와 OLAP의 데이터 파이프라인 (ETL) 분리 시각화             │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 🏃‍♂️ 실시간 운영 환경 ]                 [ 📊 야간 분석 환경 ]       │
│                                                              │
│  사용자 ──▶ [ OLTP DB ] ────────▶ [ OLAP DB ] ◀── 사장님       │
│            (정규화됨)      (ETL 복사)  (비정규화됨)                │
│             A, B, C       (매일 밤)    ABC_통합테이블              │
│                                                              │
│ ★ 핵심: 사장님의 무거운 통계 쿼리가 사용자의 결제를 방해하지 않게 완벽히 격리함!│
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"정규화가 진리라는 고정관념을 버리는 것이 분석의 시작이다." 주니어 개발자들은 모든 테이블을 제3정규형(3NF)으로 완벽하게 쪼개야만 좋은 설계라고 착각한다. 하지만 테이블이 쪼개지면 쪼개질수록 조인 비용은 기하급수적으로 늘어난다. 현대의 데이터 아키텍처는 OLTP(MySQL, PostgreSQL)로 비즈니스의 무결성을 지키면서, 동시에 그 데이터를 Snowflake나 BigQuery 같은 OLAP 전용 데이터 웨어하우스로 퍼 날라서 비정규화하는 **'투 트랙(Two-track) 전략'**이 표준이 되었다. 데이터를 '쓰는 방법'과 '읽는 방법'은 물리적으로 달라야 한다는 것이 OLAP의 철학이다.

📌 관련 개념 맵

대척점 시스템: OLTP (온라인 트랜잭션 처리 - 475번 문서)
시스템 구현체: 데이터 웨어하우스(DW), 데이터 마트 (473, 474번 문서)
설계 방식: 스타 스키마 (Star Schema - 비정규화의 대표적인 형태)
분석 기법: Roll-up, Drill-down, Slicing, Dicing (479번 문서)

👶 어린이를 위한 3줄 비유 설명

OLTP는 도서관 사서 선생님이에요. 책이 들어오면 "소설은 1번 칸, 만화는 2번 칸"에 완벽하게 쪼개서 정리(정규화)하느라 바쁘죠.
하지만 교장 선생님이 "올해 우리 학교 학생들이 가장 많이 본 책 장르가 뭐야?"라고 물어보면 사서 선생님은 멘붕에 빠져요. 도서관 전체를 다 뒤져야 하니까요.
그래서 매일 밤, 사서 선생님은 책 대출 기록만 다 모아서 '한 장짜리 거대한 통계 포스터(비정규화)'를 따로 만들어놔요. 교장 선생님은 이 포스터(OLAP)만 쓱 보면 1초 만에 답을 알 수 있답니다!