들어가며
Amazon Redshift는 여러 Compute Node가 동시에 데이터를 처리하는 MPP(Massively Parallel Processing) 구조를 사용합니다. 하지만 데이터를 무작위로 저장하면 JOIN을 수행할 때 노드 간 데이터 이동(Network Shuffle)이 발생하여 성능이 크게 저하될 수 있습니다.
따라서 Redshift에서는 데이터를 각 Compute Node에 어떤 기준으로 저장할지 결정하는 Distribution Style을 제공합니다.
이번 글에서는 Distribution Style의 개념과 AUTO, EVEN, KEY, ALL 방식의 차이점을 살펴보겠습니다.
1. Distribution Style이란?

Distribution Style은 테이블의 데이터를 여러 Compute Node에 어떻게 분산하여 저장할 것인지 결정하는 방식입니다.
Redshift는 데이터를 여러 노드에서 동시에 처리하기 때문에 데이터를 어떻게 분산하느냐에 따라 SQL 성능이 크게 달라집니다.
예를 들어 하나의 테이블을 다음과 같이 저장할 수 있습니다.
Node 1 Node 2 Node 3
Order A Order B Order C
Order D Order E Order F
여러 노드가 동시에 데이터를 처리하므로 분석 속도가 향상됩니다.
2. Distribution Style이 필요한 이유
다음과 같은 JOIN을 수행한다고 가정해보겠습니다.
SELECT *
FROM orders o
JOIN customers c
ON o.customer_id = c.customer_id;
만약 Orders와 Customers의 데이터가 서로 다른 Node에 저장되어 있다면 JOIN을 수행하기 위해 데이터를 이동해야 합니다.
Node 1 (Orders)
│
▼
Network Transfer
│
▼
Node 3 (Customers)
│
▼
JOIN 수행
노드 간 데이터 이동(Network Shuffle) 이 발생할수록 성능이 저하됩니다.
Distribution Style은 이러한 데이터 이동을 최소화하기 위해 존재합니다.
3. Distribution Style 종류
| 방식 | 특징 |
| AUTO | Redshift가 자동으로 선택 |
| EVEN | 데이터를 균등하게 분산 |
| KEY | 같은 Key를 같은 Node에 저장 |
| ALL | 모든 Node에 전체 복사 |
3-1) AUTO
AUTO는 Redshift가 데이터 크기와 사용 패턴을 분석하여 가장 적절한 Distribution Style을 자동으로 선택하는 방식입니다.
최근에는 AUTO 사용이 권장되며, 데이터가 증가하면 Redshift가 Distribution Style을 자동으로 변경하기도 합니다.
3-1-1) 장단점
| 장점 | 단점 |
| 별도 설정이 필요 없다. | 세부적인 튜닝이 어렵다. |
| AWS가 자동으로 최적화한다. | 내부 동작을 직접 제어하기 어렵다. |
| 운영 부담이 적다. |
3-1-2) 적합한 경우
- 대부분의 일반적인 테이블
- Distribution Key를 결정하기 어려운 경우
3-2) EVEN
EVEN은 데이터를 모든 Compute Node에 가능한 한 균등하게 저장합니다.
예를 들어 데이터가 12건이라면
Node1 Node2 Node3
4건 4건 4건
처럼 분산됩니다.
하지만 JOIN 시에는
Node1 (Orders) ───▶ Network ───▶ Node3 (Customers) ───▶ JOIN
처럼 노드 간 데이터 이동이 발생할 수 있습니다.
3-2-1) 장단점
| 장점 | 단점 |
| 데이터가 균등하게 분산된다. | JOIN 시 데이터 이동이 발생할 수 있다. |
| 특정 Node에 데이터가 몰리지 않는다. | JOIN이 많은 환경에서는 비효율적이다. |
3-2-2) 적합한 경우
- JOIN이 거의 없는 로그 데이터
- 단독 조회가 많은 테이블
3-3) KEY

KEY는 지정한 Distribution Key(Hash Key)를 기준으로 같은 값을 가진 데이터를 항상 같은 Node에 저장합니다.
예를 들어 Distribution Key를 customer_id로 지정하면
customer_id = 100
↓
Node2
Orders와 Customers 모두 customer_id를 Distribution Key로 사용하면
Orders(Node2) ─────────▶ JOIN ◀──────── Customers(Node2)
처럼 같은 Node에서 JOIN이 수행됩니다. 따라서 Network Shuffle이 거의 발생하지 않습니다.
3-3-1) 장단점
| 장점 | 단점 |
| JOIN 성능이 매우 뛰어나다. | Distribution Key를 잘못 선택하면 Data Skew가 발생한다. |
| 노드 간 데이터 이동이 크게 감소한다. | 특정 값이 많은 경우 한 Node에 부하가 집중될 수 있다. |
3-3-2) 적합한 경우
- Fact Table
- JOIN이 자주 발생하는 대용량 테이블
3-4) ALL
ALL은 테이블 전체를 모든 Compute Node에 복사하는 방식입니다.
Customers 테이블을 저장하면
Customers
↓
Node1
Node2
Node3
모든 Node가 동일한 데이터를 가지고 있습니다.
따라서 JOIN 시
Orders(Node1) ─────────▶ JOIN ◀──────── Customers(Node1)
Orders(Node2) ─────────▶ JOIN ◀──────── Customers(Node2)
Orders(Node3) ─────────▶ JOIN ◀──────── Customers(Node3)
처럼 데이터 이동 없이 JOIN이 가능합니다.
3-4-1) 장단점
| 장점 | 단점 |
| JOIN 성능이 매우 우수하다. | 저장 공간을 많이 사용한다. |
| Network Shuffle이 발생하지 않는다. | INSERT, UPDATE 시 모든 Node를 수정해야 한다. |
3-4-2) 적합한 경우
- 작은 Dimension Table
- 국가 코드, 지역 코드 등 변경이 거의 없는 참조 데이터
4. Distribution Style 비교
| 방식 | 데이터 저장 방식 | JOIN 성능 | 저장 공간 | 추천 대상 |
| AUTO | Redshift가 자동 선택 | ★★★★☆ | ★★★★★ | 대부분의 테이블 |
| EVEN | 균등 분산 | ★★☆☆☆ | ★★★★★ | 로그 데이터 |
| KEY | 같은 Key를 같은 Node에 저장 | ★★★★★ | ★★★★★ | Fact Table |
| ALL | 모든 Node에 복사 | ★★★★★ | ★☆☆☆☆ | 작은 Dimension Table |
5. 마치며
이번 글를 정리하며 Distribution Style은 데이터를 단순히 여러 노드에 나누어 저장하는 기능이 아니라, 노드 간 데이터 이동(Network Shuffle)을 줄여 분석 성능을 높이는 핵심 요소라는 점을 이해할 수 있었습니다.
또한 AUTO는 운영 부담을 줄여주는 기본 선택지이며, EVEN은 균등한 데이터 분산, KEY는 JOIN 성능 향상, ALL은 작은 참조 테이블의 빠른 조회에 적합하다는 차이도 알게 되었습니다.
Redshift에서는 동일한 SQL이라도 Distribution Style에 따라 성능 차이가 크게 발생할 수 있으므로, 데이터의 크기와 JOIN 패턴을 함께 고려하여 적절한 방식을 선택하는 것이 효율적인 데이터 웨어하우스를 설계하는 중요한 요소라는 점을 배울 수 있었습니다.
'Data Engineering > AWS' 카테고리의 다른 글
| Amazon Redshift Serverless란 (0) | 2026.07.02 |
|---|---|
| Amazon Redshift - WLM, VACUUM, SQA (0) | 2026.07.02 |
| Amazon Redshift - Spectrum, Durability, Scaling (0) | 2026.07.02 |
| Amazon Redshift란? (0) | 2026.07.02 |
| Amazon DocumentDB란? (0) | 2026.07.01 |