파티셔닝과 샤딩: 대용량 데이터를 나누는 두 전략

출처: https://m.youtube.com/watch?v=lVRJv4qVWFo&ra=m · 코딩하는기술사 · 7:45 · 2026-02-24

요지

• 파티셔닝은 하나의 데이터베이스 인스턴스 안에서 큰 테이블을 여러 저장 단위로 나누는 내부 최적화 전략이다.
• 샤딩은 데이터를 여러 데이터베이스 인스턴스에 분산해 단일 서버의 물리적 한계를 넘는 수평 확장 전략이다.
• 파티션 선택은 주로 DBMS가 처리하지만, 샤딩에서는 애플리케이션이나 미들웨어가 샤드 키를 바탕으로 요청을 라우팅해야 한다.
• 날짜 기반 로그와 오래된 데이터의 일괄 삭제에는 범위 파티셔닝이 특히 유용하다.
• 샤딩은 교차 샤드 조인과 트랜잭션, 재분배, 운영 복잡도를 동반하므로 단일 DB 최적화로 한계를 해결할 수 없을 때 검토해야 한다.

개요

데이터가 커지면 인덱스 탐색과 디스크 접근 비용이 늘고, 동시 트랜잭션의 경합과 잠금 대기도 길어진다. 백업·복구·배포 시간까지 증가하며 CPU, 메모리, 디스크를 증설하는 수직 확장만으로는 감당하기 어려운 시점이 온다. 이때 데이터를 논리적 또는 물리적으로 나누는 대표적인 방법이 파티셔닝과 샤딩이다.

두 기술은 모두 데이터를 분할하지만 경계가 다르다. 파티셔닝은 한 DB 인스턴스 내부의 저장 구조를 개선하고, 샤딩은 여러 DB 인스턴스로 시스템 자체를 확장한다. 따라서 선택 기준은 단순한 데이터 크기가 아니라 병목의 위치, 쿼리 패턴, 운영 역량과 확장 목표여야 한다.

배경 / 사전 지식

데이터베이스 인스턴스는 실행 중인 DBMS와 그 DBMS가 관리하는 메모리·스토리지 자원의 단위다. 하나의 인스턴스에 큰 테이블을 계속 쌓으면 다음 문제가 나타날 수 있다.

• 인덱스가 커져 캐시에 머무르기 어려워지고 디스크 I/O가 증가한다.
• 많은 트랜잭션이 같은 데이터나 인덱스 구간을 다루며 경합한다.
• 전체 테이블을 대상으로 하는 백업, 복구, 유지보수 작업이 오래 걸린다.
• 서버의 CPU·메모리·디스크 성능을 높이는 스케일 업에는 비용과 물리적 한계가 있다.

스케일 업은 한 서버의 사양을 높이는 방식이고, 스케일 아웃은 서버 수를 늘려 부하와 데이터를 분산하는 방식이다. 파티셔닝은 주로 단일 인스턴스의 효율을 높이는 데 쓰이며, 샤딩은 스케일 아웃을 구현하는 핵심 수단이다.

두 방식 모두 데이터를 어디에 배치할지 결정하는 키가 중요하다. 파티션 키는 인스턴스 내부의 저장 단위를 고르고, 샤드 키는 데이터를 보관할 DB 인스턴스를 고른다. 키의 분포와 실제 쿼리 조건이 좋지 않으면 분할한 뒤에도 특정 구간이나 서버에 부하가 몰릴 수 있다.

핵심 개념

파티셔닝

파티셔닝은 하나의 큰 테이블을 같은 DB 인스턴스 안의 여러 파티션으로 나누는 기법이다. 애플리케이션은 보통 기존 테이블을 그대로 조회하며, DB 옵티마이저가 조건에 맞지 않는 파티션을 제외하는 partition pruning을 수행한다. 즉 개발자에게는 하나의 테이블처럼 보이지만 내부 저장 단위는 분리되어 있다.

대표적인 분할 방식은 다음과 같다.

• 범위 파티셔닝: 날짜나 숫자의 연속 범위로 나눈다. 월별 로그나 연도별 주문 데이터에 적합하다.
• 리스트 파티셔닝: 서울·부산 같은 정해진 값의 목록으로 나눈다.
• 해시 파티셔닝: 키의 해시값으로 데이터를 비교적 균등하게 배치한다.
• 복합 파티셔닝: 범위와 해시처럼 둘 이상의 방식을 결합한다.

파티셔닝의 장점은 조건과 파티션 키가 잘 맞을 때 읽어야 할 데이터 범위를 줄일 수 있고, 오래된 데이터가 담긴 파티션을 통째로 제거하거나 교체하기 쉽다는 점이다. 그러나 모든 데이터와 연산은 여전히 한 인스턴스의 CPU, 메모리, 디스크 한계 안에 있다.

샤딩

샤딩은 데이터를 서로 다른 DB 인스턴스에 나눠 저장하는 기법이다. 각각의 데이터 조각과 그것을 담당하는 인스턴스를 샤드라고 한다. 예를 들어 고객 ID의 해시값이나 지역을 기준으로 한국 고객은 A 샤드, 미국 고객은 B 샤드에 배치할 수 있다.

샤딩에서는 요청을 어느 샤드로 보낼지 결정하는 라우팅 계층이 필요하다. 이 책임은 대개 애플리케이션, 데이터 접근 계층 또는 전용 미들웨어가 맡는다. 여러 서버가 저장 공간과 처리 부하를 나누므로 수평 확장이 가능하지만, 교차 샐드 조인·집계와 분산 트랜잭션은 복잡하고 비싸진다.

핵심 차이

작동 원리

파티셔닝의 처리 흐름

1. 데이터의 조회·보존 패턴에 맞는 파티션 키를 고른다. 월별 로그라면 생성 시각이 자연스러운 후보가 된다.
2. 범위, 리스트, 해시 또는 복합 전략으로 파티션 경계를 정의한다.
3. 데이터 삽입 시 DBMS가 키를 검사해 알맞은 파티션에 저장한다.
4. 조회 조건에 파티션 키가 포함되면 옵티마이저가 관계없는 파티션을 제외한다.
5. 보존 기간이 지난 데이터는 행별 DELETE 대신 해당 파티션을 분리하거나 삭제할 수 있다.

파티션이 있다는 사실만으로 모든 쿼리가 빨라지지는 않는다. 쿼리가 파티션 키로 범위를 좁히지 못하면 DBMS가 많은 파티션을 확인해야 하며, 파티션 수가 지나치게 많으면 계획 수립과 관리 비용도 커진다.

샤딩의 처리 흐름

1. 사용자 ID, 테넌트 ID, 지역처럼 요청에서 안정적으로 얻을 수 있는 샤드 키를 정한다.
2. 범위, 해시 또는 디렉터리 기반 매핑으로 키와 샤드의 관계를 정의한다.
3. 쓰기 요청이 오면 라우터가 샤드 키를 계산해 대상 DB를 선택한다.
4. 읽기도 같은 규칙으로 단일 샤드를 찾아간다. 샤드 키가 없는 전체 조회는 여러 샤드에 요청한 뒤 결과를 합치는 작업이 필요하다.
5. 용량이나 부하가 증가하면 샤드를 추가하고 일부 데이터를 재배치한다. 이때 라우팅 정보와 실제 데이터의 일관성을 함께 유지해야 한다.

좋은 샤드 키는 데이터와 트래픽을 고르게 분산하면서 주요 요청을 한 샤드 안에서 끝내게 한다. 특정 대형 고객이나 최신 시간대에 요청이 몰리는 키를 그대로 사용하면 핫 샤드가 생겨 전체 확장 효과가 줄어든다.

코드 예시

다음은 PostgreSQL에서 월별 범위 파티셔닝을 구성하고 파티션 프루닝을 확인하는 실행 가능한 예시다.

CREATE TABLE event_log (
    id          bigint GENERATED ALWAYS AS IDENTITY,
    occurred_at timestamptz NOT NULL,
    payload     jsonb NOT NULL,
    PRIMARY KEY (id, occurred_at)
) PARTITION BY RANGE (occurred_at);

CREATE TABLE event_log_2026_01
PARTITION OF event_log
FOR VALUES FROM ('2026-01-01 00:00:00+00')
         TO ('2026-02-01 00:00:00+00');

CREATE TABLE event_log_2026_02
PARTITION OF event_log
FOR VALUES FROM ('2026-02-01 00:00:00+00')
         TO ('2026-03-01 00:00:00+00');

INSERT INTO event_log (occurred_at, payload)
VALUES
    ('2026-01-15 12:00:00+00', '{"event":"login"}'),
    ('2026-02-24 09:30:00+00', '{"event":"purchase"}');

EXPLAIN
SELECT *
FROM event_log
WHERE occurred_at >= '2026-02-01 00:00:00+00'
  AND occurred_at <  '2026-03-01 00:00:00+00';

마지막 조회의 조건은 파티션 키인 occurred_at의 2월 범위와 일치한다. PostgreSQL은 실행 계획에서 1월 파티션을 제외하고 event_log_2026_02만 읽을 수 있다. 새 달이 시작되기 전에 다음 파티션을 생성해야 하며, 정의되지 않은 범위의 데이터가 들어올 가능성이 있다면 기본 파티션이나 사전 생성 자동화도 검토해야 한다.

샤딩에서는 이와 별도로 애플리케이션이 customer_id 같은 샤드 키를 받아 연결 대상을 선택해야 한다. 단순한 hash(key) % N은 샤드 수가 바뀔 때 대량의 키가 이동하므로, 운영 환경에서는 일관 해싱이나 별도의 샤드 매핑 테이블을 사용하는 편이 안전하다.

함정·실수

• 파티셔닝을 샤딩과 동일하게 보는 실수: 파티션을 여러 개 만들어도 같은 인스턴스에 있다면 서버의 물리적 한계는 그대로다.
• 파티션 키가 없는 조회가 많은 설계: 모든 파티션을 스캔할 수 있으므로 실제 쿼리 조건을 먼저 분석해야 한다.
• 파티션을 지나치게 세분화하는 설계: 파티션 수가 과도하면 메타데이터와 실행 계획, 유지보수 비용이 증가한다.
• 증가하는 시간값을 그대로 샤드 키로 사용하는 설계: 최신 데이터가 한 샤드에 몰려 쓰기 병목이 발생할 수 있다.
• 샤드 키를 변경 가능한 비즈니스 속성으로 선택하는 실수: 고객 지역 등이 바뀔 때 대규모 데이터 이동과 참조 갱신이 필요해진다.
• 교차 샤드 조인과 트랜잭션을 기존처럼 사용할 수 있다고 가정하는 실수: 네트워크 왕복, 부분 실패와 일관성 제어가 추가되므로 관련 데이터를 같은 샤드에 배치하는 모델링이 필요하다.
• 샤드 수를 해시의 나머지 연산에 직접 묶는 실수: 샤드를 추가할 때 대부분의 데이터 위치가 달라질 수 있다.

베스트 프랙티스

• 먼저 쿼리 실행 계획, I/O, 잠금 대기, 인덱스 크기와 데이터 보존 비용을 측정해 실제 병목을 확인한다.
• 날짜 조건으로 조회하고 기간 단위로 폐기하는 로그·이력 데이터에는 범위 파티셔닝을 우선 검토한다.
• 파티션 키를 자주 쓰는 필터 조건과 맞추고, 새 파티션 생성 및 오래된 파티션 제거를 자동화한다.
• 샤딩에 앞서 인덱스와 쿼리 개선, 캐시, 읽기 복제본, 데이터 보관 정책, 하드웨어 증설로 문제를 해결할 수 있는지 검토한다.
• 샤드 키는 분포가 균등하고 안정적이며 주요 쿼리에서 항상 알 수 있는 값을 선택한다. 멀티테넌트 시스템에서는 테넌트 ID가 흔한 후보지만 대형 테넌트의 쏠림을 별도로 평가해야 한다.
• 관련 데이터와 트랜잭션 경계를 같은 샤드에 배치하고, 전체 집계는 분석 저장소나 비동기 파이프라인으로 분리한다.
• 샤드별 스키마 버전, 백업·복구, 장애 전환, 용량과 핫스팟을 일관되게 관리할 자동화와 관측 체계를 마련한다.
• 샤딩이 필요하더라도 각 샤드 내부에서 파티셔닝을 함께 사용할 수 있다. 두 기술은 배타적 대안이 아니라 서로 다른 계층의 전략이다.

참고

(영상 내 명시 없음)