DB Migration 시 Table Schema 분리 250314

q1: DB Migration 시 Table Schema 분리

a1:

DB Migration 시 Table Schema 분리란?

DB 마이그레이션(Database Migration) 과정에서 **테이블 스키마 분리(Table Schema Separation)**란, 기존 데이터베이스에서 테이블을 논리적으로 또는 물리적으로 구분하여 별도의 스키마(schema)로 나누는 작업을 의미합니다.

즉, 기존에 한 데이터베이스 안에서 모든 테이블이 한 공간에 존재했다면, 이를 다른 스키마(예: public, app_data, audit_log 등)로 분리하여 관리하는 방식입니다.

⸻

왜 하는가? (목적 및 필요성)
1. 성능 최적화
• 대량의 데이터를 저장하고 처리할 때, 한 개의 스키마에 모든 테이블이 몰려 있으면 쿼리 성능이 저하될 수 있습니다.
• 스키마를 분리하면 관련 테이블들끼리만 그룹화되어 인덱스 효율이 증가하고, 조회 성능이 향상될 수 있습니다.
2. 보안 및 접근 권한 관리
• 민감한 데이터(예: 사용자 개인정보, 금융 데이터)와 일반 데이터를 분리하여 각 스키마마다 접근 권한을 다르게 설정할 수 있습니다.
• 예를 들어, audit_log 스키마에는 관리자만 접근 가능하도록 설정할 수 있습니다.
3. 데이터 유지보수 용이
• 스키마별로 역할을 나누면 특정 기능(예: 로그 저장, 사용자 데이터, 결제 데이터)만 따로 백업하거나 유지보수하기 쉬워집니다.
• 일부 테이블만 변경할 경우, 다른 기능에 영향을 덜 줍니다.
4. 마이크로서비스 아키텍처 지원
• 각 마이크로서비스가 별도의 데이터 스키마를 사용하면, 서로 다른 서비스 간의 데이터 충돌을 방지할 수 있습니다.

⸻

언제 하는가? (적용 시점)
1. DB 성능 문제 발생 시
• 테이블이 너무 많아지고 쿼리 성능이 저하되었을 때
• 특정 테이블이 너무 커져서 조회 및 업데이트 속도가 느려질 때
2. 보안 규정 강화가 필요할 때
• GDPR, ISO 27001 등의 보안 요구 사항을 충족해야 할 때
• 민감한 정보를 별도 보호해야 할 때
3. 애플리케이션이 확장될 때
• 단일 애플리케이션에서 마이크로서비스 구조로 변경할 때
• 새로운 기능 추가로 인해 기존 데이터 구조를 변경해야 할 때

⸻

예제 (Schema 분리 방식)

1) 기존 구조 (모든 테이블이 public 스키마에 있음)

CREATE TABLE public.users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

CREATE TABLE public.audit_logs (
    id SERIAL PRIMARY KEY,
    action TEXT,
    created_at TIMESTAMP DEFAULT NOW()
);

2) 테이블을 기능별 스키마로 분리

CREATE SCHEMA app_data;
CREATE SCHEMA audit_log;

CREATE TABLE app_data.users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

CREATE TABLE audit_log.logs (
    id SERIAL PRIMARY KEY,
    action TEXT,
    created_at TIMESTAMP DEFAULT NOW()
);

이제 app_data.users와 audit_log.logs처럼 분리하여 관리할 수 있습니다.

⸻

결론

DB 마이그레이션 시 Table Schema 분리는 성능 최적화, 보안 강화, 유지보수 편의성을 높이기 위한 중요한 전략입니다.
특히 대규모 시스템, 보안 요구가 높은 서비스, 마이크로서비스 구조에서 필수적으로 고려됩니다.