PostgreSQL · 2026-04-26

PostgreSQL 멀티테넌시: 스키마 vs 파티션 전략

PostgreSQL에서 스키마 기반과 파티션 기반 멀티테넌시의 개념과 구현 예시, 성능·보안·운영상의 차이를 비교하고 도입 시점별 설계 고려사항을 정리한 전략

작성일 : 2026-04-26 ㆍ 작성자 : 관리자
post
목차

개요

멀티테넌시 설계는 하나의 데이터베이스에서 여러 고객(테넌트)을 어떻게 분리하고 관리할지 결정하는 작업이다. PostgreSQL에서는 주로 스키마 기반과 파티션 기반 접근이 사용된다. 둘의 차이와 장단점을 이해하면 확장성과 운영성, 보안 요구를 균형 있게 맞출 수 있다.

멀티테넌시 기본 개념

스키마 기반 멀티테넌시

각 테넌트에 별도 스키마를 생성한다. 테이블 구조는 동일하지만 스키마가 분리되어 테넌트 데이터를 격리한다. 데이터베이스 수준의 테넌트 분리와 객체 네임스페이스를 제공한다.

파티션 기반 멀티테넌시

단일 테이블을 테넌트 식별자(예: tenant_id)로 파티셔닝한다. PostgreSQL의 선언적 파티션(Declarative Partitioning)을 사용하면 파티션별로 물리적 분리가 가능하다. 동일한 테이블 스키마를 유지하면서 데이터 분할과 쿼리 성능 최적화를 노릴 수 있다.

스키마 기반의 장단점

  • 장점
    • 테넌트별 완전한 네임스페이스 분리로 스키마 충돌 없음.
    • 권한 관리와 백업/복구가 개별 스키마 단위로 가능하여 보안·운영 유연성 확보.
    • 테넌트마다 다른 확장(컬럼 추가 등)이 필요한 경우 적용 용이.
  • 단점
    • 스키마 수가 많아지면 데이터베이스 메타데이터 부담 증가.
    • 공통 쿼리(여러 테넌트 집계) 구현이 번거롭고 성능 저하 소지.
    • 운영 자동화(스키마 생성, 마이그레이션)가 필요함.

파티션 기반의 장단점

  • 장점
    • 단일 테이블로 유지되므로 쿼리 최적화와 인덱스 관리가 일관됨.
    • 파티션 단위로 I/O, 백업, 보존 정책을 적용하면 대용량 데이터 처리에 유리.
    • 테넌트가 대량의 데이터를 보유할 때 파티션 프루닝으로 성능 향상.
  • 단점
    • 테넌트별 권한 분리가 어렵고, 논리적 격리 수준이 낮음.
    • 파티션 수가 급증하면 관리 복잡성이 증가함.
    • 테넌트별 스키마 차이가 있으면 적용이 복잡함.

성능·보안·운영 비교

성능

접근 패턴에 따라 달라진다. 읽기 중심이고 테넌트별 데이터가 큰 경우 파티션이 유리하다. 반대로 테넌트별 소규모 데이터와 많은 테넌트 수라면 스키마 기반에서 컨넥션과 메타데이터 비용을 확인해야 한다.

보안과 격리

강한 논리적 격리가 필요하면 스키마 기반이 우수하다. 파티션은 논리적 필터(tenant_id)로 접근 제어를 해야 하므로 실수로 인한 데이터 누수 위험이 있다. 이때는 행 수준 보안(RLS)을 병행하면 보완 가능하다.

운영성

스키마 기반은 테넌트 프로비저닝과 개별 마이그레이션이 쉬운 반면, 테넌트 수가 많아지면 자동화 도구가 필수다. 파티션 기반은 단일 테이블 관리로 일관성이 좋지만 파티션 관리(생성/병합/삭제) 정책을 명확히 해야 한다.

구현 예시

스키마 기반 예시

CREATE SCHEMA tenant_1;
SET search_path TO tenant_1, public;
CREATE TABLE users (
  id serial PRIMARY KEY,
  name text,
  email text
);
-- 애플리케이션 레벨에서 search_path를 테넌트에 맞춰 설정

파티션 기반 예시

CREATE TABLE events (
  tenant_id int NOT NULL,
  id bigint NOT NULL,
  created_at timestamptz,
  payload jsonb,
  PRIMARY KEY (tenant_id, id)
) PARTITION BY LIST (tenant_id);

CREATE TABLE events_t1 PARTITION OF events FOR VALUES IN (1);
CREATE TABLE events_t2 PARTITION OF events FOR VALUES IN (2);

설계 고려사항

  • 테넌트 수와 데이터 분포를 먼저 파악한다.
  • 테넌트별 격리 요구(규제, SLA)를 명확히 한다.
  • 쓸모없는 복잡성을 피하기 위해 초기에는 단순한 모델로 시작한다.
  • 모니터링과 자동화(프로비저닝, 마이그레이션)를 계획한다.
  • 백업·복구 전략을 테넌트 단위로 설계할지 전체 단위로 설계할지 결정한다.

결론

스키마 기반과 파티션 기반은 목적에 따라 적합성이 달라진다. 규제가 엄격하거나 테넌트별 격리가 중요하면 스키마 기반을 우선 고려한다. 반대로 대량의 데이터와 읽기 성능이 우선이면 파티션 기반이 유리하다. 현실적으로는 두 방식을 혼합하거나, 초기에는 단순 모델로 시작해 필요 시 파티션을 도입하는 단계적 접근이 합리적이다.

멀티테넌시 postgres 스키마 테넌시 파티션 postgres multitenant postgres 전략 PostgreSQL 멀티테넌시 스키마 기반 테넌시 파티션 기반 테넌시 데이터베이스 설계 테넌트 격리