RDS에서 분석 쿼리가 10분 걸린다면, Redshift에서는 3초면 끝난다. OLTP와 OLAP의 차이부터, 컬럼나 스토리지의 마법, Redshift Serverless, 그리고 Snowflake·BigQuery와의 경쟁까지 — 데이터 웨어하우스를 실전 관점에서 풀어본다.
RDS 글에서 Aurora PostgreSQL로 서비스를 운영하고 있다고 하자. 어느 날, CEO가 요청한다:
"지난 1년간, 카테고리별 월별 매출 추이를 보고 싶어요."
SELECT
category,
DATE_TRUNC('month', order_date) AS month,
SUM(total_amount) AS revenue,
COUNT(DISTINCT customer_id) AS unique_customers
FROM orders
JOIN products ON orders.product_id = products.id
WHERE order_date >= '2025-03-01'
GROUP BY category, month
ORDER BY category, month;
주문 테이블에 5억 건, 상품 테이블에 100만 건. 이 쿼리를 RDS에서 실행하면 — 10분. 그 사이 같은 DB에서 고객들이 주문을 하고 있고, 분석 쿼리가 DB 자원을 잡아먹어 서비스 응답이 느려진다.
문제는 명확하다: 트랜잭션 처리(OLTP)와 분석(OLAP)은 근본적으로 다른 워크로드인데, 하나의 DB에서 둘 다 하려고 한다.
이 OLAP 워크로드를 위해 만들어진 것이 데이터 웨어하우스(Data Warehouse) 이고, AWS의 데이터 웨어하우스가 Redshift다.
데이터 웨어하우스 개념은 1990년대에 Bill Inmon("데이터 웨어하우스의 아버지")과 Ralph Kimball(차원 모델링)이 정립했다.
전통적 DW의 대표 제품은 Teradata, Oracle Exadata, IBM Netezza. 이들의 공통점: 전용 하드웨어에 수억~수십억 원, 도입에 수 개월, 전문 DBA/DW 엔지니어 필요.
2012년 11월 AWS re:Invent에서 Amazon Redshift가 발표됐다. 핵심 메시지: "전통 DW의 1/10 비용으로, 수 분 만에, 페타바이트 규모의 분석이 가능하다."
이름의 유래: Red Shift — 천문학에서 먼 은하가 빠르게 멀어질 때 빛이 붉은색으로 이동하는 현상. Oracle(Red)에서 벗어나(Shift) 가자는 의미. AWS가 Oracle과의 경쟁을 공개적으로 선언한 이름이었다.
RDS/Aurora 같은 OLTP DB는 데이터를 행(Row) 단위로 저장한다. Redshift는 열(Column) 단위로 저장한다. 이 차이가 분석 속도를 10~100배 바꾼다.
행 기반 저장 (RDS):
행1: [주문ID: 1, 고객: Kim, 카테고리: 전자, 금액: 50000, 날짜: 2026-01]
행2: [주문ID: 2, 고객: Lee, 카테고리: 의류, 금액: 30000, 날짜: 2026-01]
행3: [주문ID: 3, 고객: Park, 카테고리: 전자, 금액: 80000, 날짜: 2026-02]
디스크에는 행 단위로 연속 저장된다. "주문ID 1의 모든 정보"를 읽을 때 빠르다 (OLTP). 하지만 "모든 주문의 금액 합계"를 구하려면? 모든 행의 모든 열을 다 읽어야 한다. 5억 행 × 20열 = 100억 개의 값을 읽지만, 실제 필요한 것은 금액 열 1개뿐.
열 기반 저장 (Redshift):
주문ID 열: [1, 2, 3, 4, 5, ...]
고객 열: [Kim, Lee, Park, Choi, ...]
카테고리 열: [전자, 의류, 전자, 식품, ...]
금액 열: [50000, 30000, 80000, 15000, ...]
날짜 열: [2026-01, 2026-01, 2026-02, ...]
"모든 주문의 금액 합계"를 구하려면? 금액 열만 읽으면 된다. 5억 개의 값만 읽으면 끝. 나머지 열은 디스크에서 아예 안 읽는다.
1. 압축 (Compression): 같은 열의 데이터는 유사한 값이 많다 (카테고리 열에 "전자"가 수백만 번). 열 단위 압축으로 디스크 사용량 60~80% 감소 → I/O 대폭 감소.
2. Zone Maps:
각 데이터 블록의 최소값/최대값을 메타데이터로 저장. WHERE date > '2026-01-01'이면 2025년 데이터 블록은 아예 읽지 않는다. 블록 스캔 건너뛰기.
3. MPP (Massively Parallel Processing): 여러 노드가 쿼리를 병렬로 처리. 10억 행을 10개 노드가 나눠서 1억 행씩 처리하면 10배 빠르다.
리더 노드: 클라이언트와 통신. SQL을 받아 실행 계획을 만들고, 컴퓨트 노드에 작업을 분배. 결과를 모아 클라이언트에 반환. 비용 없음 (리더 노드는 무료).
컴퓨트 노드: 실제 데이터를 저장하고 쿼리를 실행하는 워커. 노드를 늘리면 성능이 비례하여 향상.
2022년 출시된 Redshift Serverless는 클러스터(노드 수, 타입)를 직접 관리하지 않아도 된다:
DynamoDB의 온디맨드 모드, Aurora Serverless와 같은 패턴이다.
| Redshift | Snowflake | BigQuery | |
|---|---|---|---|
| 클라우드 | AWS | 멀티클라우드 | GCP |
| 스토리지/컴퓨트 분리 | RA3에서 지원 | 처음부터 분리 | 처음부터 분리 |
| 서버리스 | Serverless 모드 | 기본이 서버리스 | 완전 서버리스 |
| 과금 | 시간 또는 RPU | 크레딧 (시간 기반) | 스캔 데이터량 |
| AWS 통합 | 네이티브 (IAM, VPC, S3, Glue) | 제한적 | 없음 |
| 동시성 | WLM으로 관리 | 자동 스케일링 | 자동 |
| 강점 | AWS 생태계, 비용 효율 | 멀티클라우드, UX | 서버리스, 쉬움 |
| ML 통합 | Redshift ML (SageMaker) | Snowpark | BigQuery ML |
가장 대표적인 용도. 비즈니스 인텔리전스 도구(QuickSight, Tableau, Looker)가 Redshift에 연결하여 대시보드를 생성.
-- 일별 매출, 주문 수, 평균 주문 금액
SELECT
order_date,
COUNT(*) AS orders,
SUM(amount) AS revenue,
AVG(amount) AS avg_order_value
FROM fact_orders
WHERE order_date >= DATEADD(day, -90, CURRENT_DATE)
GROUP BY order_date
ORDER BY order_date;
RDS에서 이 쿼리가 수 분 걸렸다면, Redshift에서는 수 초.
Redshift Spectrum은 Redshift 클러스터에 데이터를 적재하지 않고, S3에 있는 데이터를 직접 SQL로 쿼리한다.
-- S3에 있는 로그 파일을 직접 쿼리 (Spectrum)
CREATE EXTERNAL SCHEMA logs
FROM DATA CATALOG
DATABASE 'logs_db'
IAM_ROLE 'arn:aws:iam::123:role/redshift-spectrum';
SELECT
DATE_TRUNC('hour', timestamp) AS hour,
status_code,
COUNT(*) AS count
FROM logs.access_logs
WHERE timestamp >= '2026-03-01'
GROUP BY hour, status_code
ORDER BY hour;
데이터를 S3에 그대로 두고, 필요할 때만 쿼리. 콜드 데이터를 Redshift에 적재하지 않으므로 스토리지 비용 절감.
2026년의 트렌드는 레이크하우스(Lakehouse) — 데이터 레이크(S3)와 데이터 웨어하우스(Redshift)의 경계를 허물고, 하나의 SQL로 모든 데이터에 접근:
DW에는 기업의 모든 데이터가 모여 있다 — 매출, 고객 정보, 거래 내역, 행동 로그. 해커의 최우선 표적이다.
| 모델 | 과금 방식 | 적합한 경우 |
|---|---|---|
| 프로비저닝 | 노드 시간당 과금 | 항상 실행, 예측 가능한 워크로드 |
| Serverless | RPU-시간 과금 | 간헐적 분석, 예측 어려운 워크로드 |
| Spectrum | 스캔 데이터 TB당 $5 | S3 데이터 임시 분석 |
프로비저닝 클러스터 비용 예시 (서울):
| 노드 타입 | 노드당 시간 비용 | 스토리지 | 용도 |
|---|---|---|---|
| dc2.large | 226/월) | 160GB SSD | 소규모, 빠른 시작 |
| ra3.xlplus | 338/월) | S3 관리형 (무제한) | 범용, 스토리지/컴퓨트 분리 |
| ra3.4xlarge | 1,138/월) | S3 관리형 (무제한) | 대규모 분석 |
Netflix는 Redshift로 일 수 PB 규모의 시청 데이터를 분석한다. "어떤 콘텐츠가 어떤 지역에서 인기 있는가", "추천 알고리즘의 클릭률은 어떤가" — 이런 질문에 대한 답을 Redshift가 수 초 만에 제공한다.
McDonald's는 전 세계 매장의 주문 데이터를 Redshift로 분석하여, 시간대별·지역별 메뉴 인기도, 프로모션 효과, 재고 최적화를 수행한다.
Lyft는 Redshift에 준실시간으로 데이터를 적재하여, 수요 예측, 가격 최적화, 드라이버 배치에 활용한다.
| 상황 | 추천 | 이유 |
|---|---|---|
| 수억 행 이상의 분석 쿼리 | Redshift | OLAP에 최적화된 컬럼나 스토리지 |
| BI 대시보드 백엔드 | Redshift | 복잡한 집계 쿼리를 수 초에 |
| S3 데이터 SQL 분석 | Redshift Spectrum 또는 Athena | 데이터 이동 없이 분석 |
| 간단한 S3 임시 쿼리 | Athena | 서버리스, Redshift보다 단순 |
| OLTP (주문 처리, 사용자 인증) | RDS/Aurora | Redshift는 트랜잭션에 부적합 |
| 키-값 고속 조회 | DynamoDB | Redshift는 단건 조회에 비효율 |
| 텍스트 검색 | OpenSearch | Redshift는 풀텍스트 검색에 약함 |
이 시리즈에서 다룬 데이터 관련 서비스를 정리하면:
| 서비스 | 용도 | 질문 유형 |
|---|---|---|
| RDS/Aurora | OLTP | "이 주문의 상태는?" (단건, 빠르게) |
| DynamoDB | 키-값 조회 | "이 사용자의 세션은?" (초고속) |
| OpenSearch | 텍스트 검색 | "이 키워드가 포함된 문서는?" |
| S3 | 파일 저장 | "이 파일을 저장/가져와" |
| Redshift | OLAP | "지난 1년간 카테고리별 매출 추이는?" (대규모 집계) |
각 서비스가 다른 유형의 질문에 최적화되어 있다. RDS로 분석을 하거나, Redshift로 트랜잭션을 처리하는 것은 잘못된 도구를 쓰는 것이다.
Redshift의 가치는 **"데이터에 빠르게 질문하고 답을 얻는 것"**이다. 10분 걸리던 쿼리가 3초면 끝나면, 분석가는 하루에 10개의 질문 대신 100개의 질문을 할 수 있다. 더 많은 질문 = 더 깊은 인사이트 = 더 좋은 비즈니스 결정.
코어닷투데이에서도 Redshift는 데이터 분석의 핵심이다. AI 서비스의 사용 패턴, 모델 성능 추이, 비즈니스 메트릭 — 이런 데이터를 S3 데이터 레이크에 모으고, Redshift로 분석하여, 서비스 개선의 근거로 활용한다. 데이터에 질문을 던지고, 3초 만에 답을 얻는 것 — 그것이 데이터 웨어하우스의 가치다.