온라인 분석 처리(Online Analytical Processing)

•

2026년 10월 09일 발행•2026년 10월 09일 수정

요약

대량의 데이터를 차원과 측정값으로 구성된 다차원 모델로 조직하여 여러 관점에서 빠르게 집계·분석할 수 있도록 하는 데이터 처리 방식

초급

관계형 데이터베이스와 SQL의 GROUP BY·조인에 대한 기초 지식이 있으면 이해할 수 있으며, 데이터 웨어하우스와 차원 모델링 개념을 알면 열 지향 저장과 시맨틱 레이어 부분을 더 깊이 이해할 수 있다.

태그

데이터 웨어하우스 비즈니스 인텔리전스 데이터베이스 ETL 빅데이터

#개념

온라인 분석 처리(Online Analytical Processing, OLAP)는 대량의 데이터를 여러 관점에서 집계·요약하여 빠르게 분석할 수 있도록 설계된 데이터 처리 방식과 그 시스템을 가리킨다. 매출을 지역별·월별·상품군별로 합산하고 전년 대비 증감을 비교하는 것처럼, 의사 결정에 필요한 질문을 대화하듯 던지고 수 초 안에 답을 얻는 것이 목표이며, 데이터 웨어하우스(Data Warehouse)와 비즈니스 인텔리전스(Business Intelligence)의 핵심 기반 기술이다.

OLAP라는 용어는 관계형 모델의 창시자 E. F. Codd가 1993년 백서에서 처음 제안했고, 1990년대 데이터 웨어하우스의 확산과 함께 자리 잡았다. Chaudhuri와 Dayal(1997)은 운영 데이터베이스(Database)에서 ETL로 데이터를 추출·정제하여 웨어하우스에 적재하고, 그 위에서 OLAP 서버가 다차원 질의를 처리하며, 최종 사용자가 보고서와 데이터 시각화(Data Visualization) 도구로 결과를 소비하는 구조를 정리했다.

OLAP를 이해하는 가장 쉬운 방법은 온라인 트랜잭션 처리(Online Transaction Processing, OLTP)와 비교하는 것이다. OLTP는 주문 생성, 결제 승인, 재고 차감처럼 서비스 운영 중 발생하는 개별 거래를 빠르고 정확하게 기록하는 시스템이고, OLAP는 그렇게 쌓인 거래를 분석하는 시스템이다. 두 방식은 다음과 같이 대비된다.

OLTP와 OLAP의 비교

목적: OLTP는 일상 업무의 거래 처리, OLAP는 과거 데이터의 분석과 의사 결정 지원이 목적이다.
질의 형태: OLTP는 소수의 행을 읽고 쓰는 짧은 질의가 초당 수천 건 발생하고, OLAP는 수백만 행을 훑어 집계하는 복잡한 읽기 질의가 상대적으로 드물게 발생한다.
데이터 모델: OLTP는 갱신 이상을 막기 위해 정규화된 스키마를 쓰고, OLAP는 조인을 줄이기 위해 의도적으로 비정규화된 다차원 스키마를 쓴다.
데이터 범위: OLTP는 현재 상태 중심의 비교적 작은 데이터를 다루고, OLAP는 수년치 이력을 포함한 대용량 데이터를 다룬다.
저장 방식: OLTP는 행 단위 접근에 유리한 행 지향 저장을, OLAP는 열 단위 집계에 유리한 열 지향 저장을 주로 사용한다.

운영 데이터베이스에서 무거운 분석 질의를 직접 실행하면 거래 처리가 느려지고 장애로 이어질 수 있으므로, 분석 부하를 별도의 OLAP 시스템으로 분리하는 것이 두 세계를 구분하는 실질적인 이유다. 최근에는 하나의 엔진에서 두 부하를 함께 처리하는 HTAP(Hybrid Transactional/Analytical Processing)도 시도되지만, 대규모 조직에서는 여전히 분리가 일반적이다.

OLAP의 데이터 모델은 큐브(Cube)로 표현된다. 큐브는 분석 대상 수치인 측정값(Measure)과, 그 수치를 바라보는 관점인 차원(Dimension)으로 구성되며, 예를 들어 매출액·주문 수·수량이 측정값이라면 시간·지역·상품·고객이 차원이다. 각 차원은 "일-월-분기-연"이나 "상품-소분류-대분류"처럼 계층(Hierarchy)을 가지며, 계층의 각 수준(level)과 구성원(member)이 집계의 단위가 된다. 차원이 넷 이상이면 기하학적 정육면체는 아니지만, 각 차원 값의 조합마다 측정값 셀이 하나씩 존재하는 다차원 배열이라는 뜻에서 큐브라 부른다. 사용자는 큐브 위에서 몇 가지 기본 연산을 조합하여 분석을 진행하며, 대표적인 연산은 다음과 같다.

OLAP의 기본 연산

롤업(Roll-up): 계층을 따라 상위 수준으로 올라가며 집계하는 연산으로, 일별 매출을 월별 매출로 합산하는 것이 그 예다.
드릴다운(Drill-down): 롤업의 반대로 상위 수준의 집계를 하위 수준으로 세분화하여 들여다보는 연산이며, 분기 매출이 급감했을 때 어느 달, 어느 주에서 문제가 생겼는지 추적할 때 쓴다.
슬라이스(Slice): 한 차원의 값을 하나로 고정하여 큐브의 단면을 떼어 내는 연산으로, "2026년 3월"만 선택하면 나머지 차원으로 이루어진 2차원 표가 남는다.
다이스(Dice): 둘 이상의 차원에 조건을 걸어 부분 큐브를 잘라 내는 연산으로, "서울 지역·아우터 카테고리·최근 3개월"처럼 여러 조건을 함께 적용한다.
피벗(Pivot): 행과 열의 차원을 서로 바꾸어 같은 데이터를 다른 배치로 보는 연산으로, 스프레드시트의 피벗 테이블이 이 개념을 대중화했다.

Gray 등(1997)은 이러한 다차원 집계를 SQL로 표현하기 위해 데이터 큐브 연산자(Data Cube Operator)를 제안했다. $n$개의 차원에 대해 가능한 모든 $2^n$가지 GROUP BY 조합을 한 번에 계산하는 이 연산자는 오늘날 대부분의 SQL 엔진이 지원하는 GROUP BY CUBE, ROLLUP, GROUPING SETS 구문의 기원이며, 큐브의 셀을 미리 계산해 두는 사전 집계(pre-aggregation)와 어떤 집계를 실체화할지 선택하는 뷰 선택 문제의 출발점이 되었다. OLAP 서버는 큐브를 어떤 형태로 저장하고 질의하느냐에 따라 세 가지로 나뉜다.

OLAP 서버의 구현 방식

MOLAP(Multidimensional OLAP): 큐브를 전용 다차원 배열 구조에 사전 집계된 형태로 저장하여 질의 응답이 매우 빠르지만, 차원이 늘어날수록 저장 공간이 폭발하고 적재 시간이 길며 데이터가 갱신되면 큐브를 다시 만들어야 한다.
ROLAP(Relational OLAP): 데이터를 관계형 테이블에 그대로 두고 다차원 질의를 SQL로 변환해 실행하는 방식으로, 대용량과 세부 데이터 접근에 유리하고 유연하지만 응답 속도는 데이터베이스 엔진의 성능에 좌우된다.
HOLAP(Hybrid OLAP): 자주 쓰는 상위 수준 집계는 MOLAP 방식으로 사전 계산하고 세부 데이터는 관계형 테이블에서 조회하여 두 방식의 장점을 절충한다.

ROLAP가 다차원 모델을 관계형 테이블로 표현하는 표준적인 설계가 Kimball이 체계화한 차원 모델링(Dimensional Modeling)이다. 그 중심인 스타 스키마(Star Schema)는 측정값과 차원 테이블의 외래 키를 담는 팩트 테이블(Fact Table) 하나를 가운데 두고, 각 차원의 속성을 담는 차원 테이블(Dimension Table)들이 별 모양으로 둘러싸는 구조이다. 차원 테이블은 조인 수를 줄이기 위해 비정규화되어 상품 테이블 하나에 소분류·대분류·브랜드가 모두 들어가며, 분석가가 이해하기 쉽고 질의가 단순하다는 장점이 있다.

스노우플레이크 스키마(Snowflake Schema)는 차원 테이블을 다시 정규화하여 상품-소분류-대분류를 별도 테이블로 분리한 구조로, 저장 공간이 줄고 차원 속성의 일관성을 유지하기 쉽지만 조인이 늘어 질의가 복잡해진다. 저장 비용이 저렴해진 오늘날에는 스타 스키마가 더 널리 권장되며, 고객의 주소 변경처럼 시간에 따라 바뀌는 차원 속성을 이력과 함께 관리하는 느리게 변하는 차원(Slowly Changing Dimension, SCD) 처리와, 팩트의 세부 수준인 입도(Grain)를 명확히 정하는 것이 차원 모델링의 핵심 실무다.

2000년대 이후 OLAP의 성능을 근본적으로 바꾼 것은 열 지향 저장(Columnar Storage)이다. 행 지향 저장은 한 행의 모든 열을 연속해서 기록하므로 "매출액 합계"를 구하려 해도 모든 열을 디스크에서 읽어야 하지만, 열 지향 저장은 열마다 값을 따로 모아 두어 질의에 필요한 열만 읽는다. 같은 열의 값은 자료형과 분포가 비슷해 사전 인코딩, 런 길이 인코딩, 비트 패킹 등으로 압축률이 매우 높고, 압축된 열을 CPU 캐시에 올려 SIMD 명령으로 한꺼번에 처리하는 벡터화 실행(vectorized execution)과 결합하면 집계 속도가 수십 배 이상 빨라진다.

Stonebraker 등의 C-Store와 MonetDB 같은 연구에서 출발한 이 설계는 Parquet·ORC 같은 열 지향 파일 형식과 Apache Arrow 같은 인메모리 형식으로 표준화되었다. 그 결과 사전 집계 큐브를 만들지 않고도 원본 수준의 테이블에서 즉석 집계를 수행하는 것이 가능해졌고, 전통적인 MOLAP 큐브의 역할은 크게 줄었다.

현대의 OLAP는 클라우드 데이터 웨어하우스와 데이터 레이크(Data Lake) 엔진으로 구현된다. Snowflake, Google BigQuery, Amazon Redshift, Databricks SQL은 저장과 계산을 분리하고 대규모 병렬 처리(MPP)로 페타바이트급 빅데이터(Big Data)를 SQL로 분석하며, 레이크 위에 Delta Lake·Apache Iceberg 같은 테이블 형식을 얹어 웨어하우스의 성능과 레이크의 유연성을 결합한 레이크하우스 구조가 확산되었다.

한편 ClickHouse, Apache Druid, Apache Pinot은 스트리밍으로 유입되는 이벤트를 초 단위로 적재하고 밀리초 안에 집계하는 실시간 OLAP(Real-time OLAP) 영역을 담당하고, DuckDB는 단일 머신에서 노트북이나 애플리케이션에 내장되어 동작하는 경량 분석 엔진으로 자리 잡았다. 이들 엔진은 모두 열 지향 저장과 분산·병렬 실행을 공통 기반으로 하며, 적재 지연·동시 질의 수·비용 구조에 따라 용도가 나뉜다.

엔진이 다양해지면서 새롭게 중요해진 것이 시맨틱 레이어(Semantic Layer)이다. 시맨틱 레이어는 물리적 테이블과 사용자 사이에서 "매출", "활성 사용자", "전환율" 같은 지표와 차원의 정의, 테이블 간 관계, 접근 권한을 한 곳에 선언해 두고, BI 도구·노트북·AI 도구가 모두 같은 정의로 질의하도록 하는 추상화 계층이다. 전통적 OLAP 큐브가 수행하던 "비즈니스 언어로 데이터를 정의한다"는 역할을 특정 엔진에 묶이지 않는 형태로 계승한 것으로, dbt Semantic Layer, Cube, LookML, Microsoft의 표 형식 모델이 대표적이며, 같은 지표가 도구마다 다른 값으로 나오는 문제를 줄인다.

데이터 과학과 머신러닝의 관점에서 OLAP 시스템은 단순한 보고 도구를 넘어 탐색적 데이터 분석(Exploratory Data Analysis)과 특징 생성의 기반이다. 사용자별 최근 30일 구매 횟수, 카테고리별 평균 객단가 같은 집계 특징은 OLAP 엔진의 윈도 함수와 GROUP BY로 계산되어 피처 스토어(Feature Store)에 적재되고, A/B 테스트(AB Testing)의 실험군별 지표 비교와 추천 모델의 성능 대시보드 역시 OLAP 질의 위에서 동작한다. 따라서 데이터 과학자에게 차원 모델의 구조와 OLAP 엔진의 성능 특성을 이해하는 것은 분석의 속도와 비용을 좌우하는 실무 역량이 된다.

전자상거래 조직을 예로 들면, 주문·클릭·결제 이벤트가 OLTP 데이터베이스와 스트리밍 로그에서 ETL을 거쳐 열 지향 웨어하우스의 스타 스키마로 적재되고, 분석가는 시맨틱 레이어에 정의된 지표를 BI 도구에서 드릴다운하며 카테고리별·캠페인별 성과를 파악한다. 운영 조직은 실시간 OLAP 엔진으로 프로모션 진행 중의 분당 주문 수를 모니터링하고, 데이터 과학 팀은 같은 웨어하우스에서 학습용 집계 특징을 생성한다.

결론적으로 OLAP는 큐브와 차원이라는 사고 모델, 롤업·드릴다운·슬라이스·다이스·피벗이라는 분석 연산, 스타 스키마라는 설계 패턴을 남겼고, 열 지향 저장과 클라우드 엔진은 그 구현 방식을 사전 집계 중심에서 즉석 집계 중심으로 바꾸었다. 기술은 바뀌었지만 "데이터를 여러 관점에서 빠르게 집계하여 의사 결정을 돕는다"는 OLAP의 목적은 오늘날의 데이터 플랫폼에서도 그대로 유효하다.

#관련 용어

온라인 트랜잭션 처리(OLTP)

서비스 운영 중 발생하는 개별 거래를 빠르고 정확하게 기록하는 데 최적화된 데이터 처리 방식

데이터 웨어하우스

여러 운영 시스템의 데이터를 분석 목적으로 통합·적재하여 OLAP 질의의 기반이 되는 중앙 저장소

스타 스키마

팩트 테이블 하나를 중심으로 비정규화된 차원 테이블들이 둘러싸는 차원 모델링의 대표적 설계 패턴

열 지향 저장

데이터를 열 단위로 모아 저장하여 필요한 열만 읽고 높은 압축률과 벡터화 집계를 가능하게 하는 저장 방식

ETL

운영 데이터베이스에서 데이터를 추출·변환하여 분석용 웨어하우스에 적재하는 과정

비즈니스 인텔리전스

OLAP 질의 결과를 대시보드와 보고서로 가공하여 의사 결정을 지원하는 도구와 활동

#직무 연관도

Data Analyst밀접

롤업·드릴다운·슬라이스·다이스 연산으로 지표를 다각도로 분석하고 BI 대시보드를 구성하는 일상 업무의 기반 기술이다

Data Scientist보통

탐색적 데이터 분석과 집계 특징 생성, 실험 결과 분석에 OLAP 엔진과 차원 모델을 직접 활용하며, 질의 성능 특성을 이해해야 분석 비용을 통제할 수 있다

Data Engineer밀접

데이터 웨어하우스와 실시간 OLAP 엔진의 설계·운영, 스타 스키마 모델링, ETL 파이프라인과 시맨틱 레이어 구축이 데이터 엔지니어의 핵심 업무다

#사용 사례

전자상거래금융유통제조통신인터넷 서비스미디어

개요

OLAP는 매출·재고·마케팅 성과 분석과 경영 보고, 금융 거래와 리스크 분석, 통신 트래픽과 이탈 분석, 제조 설비 가동률 분석, 서비스 이벤트 로그의 실시간 모니터링 등 대량의 이력 데이터를 다양한 관점에서 집계해야 하는 모든 분석 업무에 활용되며, 머신러닝용 집계 특징 생성과 실험 분석의 기반이기도 하다.

사례

패션 전자상거래 조직이 주문·클릭 이벤트를 열 지향 클라우드 웨어하우스의 스타 스키마로 적재하고, 시맨틱 레이어에 '순매출'과 '구매 전환율'을 정의해 BI 도구와 노트북이 같은 값을 보도록 통일했다. 분석가는 분기 매출 급감을 월·주·카테고리로 드릴다운해 특정 아우터 카테고리의 재고 문제를 찾아냈고, 데이터 과학 팀은 같은 웨어하우스에서 사용자별 최근 30일 집계 특징을 생성해 추천 모델 학습에 사용한다.