Brain💡 핵심 인사이트 스키마 온 라이트(Schema-on-Write)는 "데이터를 데이터베이스나 데이터 웨어하우스에 적재(Load)하는 시점에 데이터의 구조(스키마)를 사전 정의하고 검증하는" 접근 방식입니다. 데이터가 저장되기 전에 스키마가 적용되므로, **잘못된 데이터는 저장 시점에 차단**됩니다. 이는 데이터 무결성을 보장하지만, **데이터 소스와 분석 방식이 사전에 완전히 정의**되어야 하며, **유연성이 제한**되는 단점이 있습니다.
Ⅰ. 스키마 온 라이트의 기본 개념: 사전 검증 구조
스키마 온 라이트는 관계형 데이터베이스와 데이터 웨어하우스에서 전통적으로 사용되어온 방식입니다.
[스키마 온 라이트의 처리 흐름]
데이터 소스 (CRM, ERP, 외부 API...)
│
│ 원시 데이터 추출
▼
┌─────────────────────────────────────┐
│ ETL / ELT 파이프라인 │
│ (Extract - Transform - Load) │
│ │
│ 1. 데이터 추출 (Extract) │
│ 2. 스키마 매핑 (Transform) │
│ - 소스 데이터 → 대상 스키마 변환 │
│ - 데이터 타입 검증 │
│ - 필수 필드 확인 │
│ - 제약조건 검증 │
│ 3. 데이터 적재 (Load) │
│ - 검증 통과 → 저장소 저장 │
│ - 검증 실패 → 예외 처리/거부 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 사전 정의된 스키마 (저장소) │
│ ┌───────────────────────────────┐ │
│ │ CREATE TABLE customers ( │ │
│ │ cust_id INT PRIMARY KEY, │ │
│ │ name VARCHAR(100) │ │
│ │ email VARCHAR(255) │ │
│ │ created_dt DATE │ │
│ │ ); │ │
│ └───────────────────────────────┘ │
└─────────────────────────────────────┘
│
▼
분석/활용
핵심 원리: 데이터가 저장되기 전에 해당 데이터가 정의된 스키마에 맞는지 严格하게 검증됩니다. 만약 "email 필드에 전화번호가 들어온다"거나 "created_dt에 문자열이 들어온다"면, 해당 데이터는 저장 단계에서 거절됩니다.
Ⅱ. 스키마 온 라이트의 검증 메커니즘
스키마 온 라이트에서는 다양한 데이터 무결성 검증 메커니즘이 적용됩니다.
1. 데이터 타입 검증 (Type Checking) 각 컬럼에 허용되는 데이터 타입(정수, 문자열, 날짜 등)을 사전 정의합니다.
-- 스키마 정의 예시
CREATE TABLE sales (
sale_id BIGINT PRIMARY KEY, -- 64비트 정수
sale_date TIMESTAMP NOT NULL, -- 날짜/시간
amount DECIMAL(15,2) NOT NULL, -- 소수점 2자리 숫자
customer_id INT NOT NULL, -- 정수
status VARCHAR(20) -- 최대 20자 문자열
);
2. 필수 필드 검증 (NOT NULL Constraints) 비즈니스적으로 반드시 필요한 필드가 누락되지 않도록 합니다.
ALTER TABLE sales
MODIFY COLUMN sale_date DATE NOT NULL; -- 판매 날짜는 필수
3. 고유성 제약조건 (UNIQUE Constraints) 중복 데이터 발생을 방지합니다.
ALTER TABLE customers
ADD CONSTRAINT uq_email UNIQUE (email); -- 이메일 중복 불가
4. 참조 무결성 (REFERENTIAL Integrity) 외래 키를 통해 참조 관계의 유효성을 검증합니다.
ALTER TABLE sales
ADD FOREIGN KEY (customer_id) REFERENCES customers(customer_id);
-- 존재하지 않는 고객 ID로 판매 기록 생성 불가
5. 도메인 제약조건 (CHECK Constraints) 허용 가능한 값의 범위나 패턴을 정의합니다.
ALTER TABLE sales
ADD CONSTRAINT chk_status
CHECK (status IN ('COMPLETED', 'PENDING', 'CANCELLED'));
ALTER TABLE customers
ADD CONSTRAINT chk_age
CHECK (age >= 0 AND age <= 150);
Ⅲ. 스키마 온 라이트 vs 스키마 온 리드: 본질적 대비
스키마 온 라이트와 스키마 온 리드(Schema-on-Read)는 데이터 처리 시점에서 근본적으로 다릅니다.
[두 접근법의 핵심적 차이]
┌──────────────────────────────────────────────────────────────────────┐
│ 스키마 온 라이트 (Schema-on-Write) │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 데이터 처리 시점: 저장할 때 │
│ │
│ [데이터 소스] ──추출──> [변환/검증] ──적재──> [저장소] │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 스키마 정의/검증 │ │
│ │ - 타입 체크 │ │
│ │ - 필수 필드 │ │
│ │ - 범위 체크 │ │
│ │ - 참조 무결성 │ │
│ └─────────────────┘ │
│ │ │
│ ▼ │
│ [검증 실패 시 거부] │
│ │
│ 특징: │
│ - Bad 데이터는 저장 시 차단 │
│ - 저장된 데이터의 품질이 보장됨 │
│ - 사전 설계 필요 (유연성 낮음) │
│ - 적재 시 오버헤드 (변환/검증 비용) │
└────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────┐
│ 스키마 온 리드 (Schema-on-Read) │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 데이터 처리 시점: 읽을 때 │
│ │
│ [데이터 소스] ──그대로──> [저장소] ──읽을 때──> [적용] │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 원시 데이터 Pool │ │ 스키마 적용 │ │
│ │ (형태 그대로) │ │ (쿼리/분석 시) │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ 특징: │
│ - 데이터 먼저 저장, 스키마는 나중에 적용 │
│ - 다양한 스키마로 동일 데이터 해석 가능 │
│ - 저장 시 overhead 없음 │
│ - Bad 데이터도 저장됨 (나중에 정제) │
│ - 데이터沼泽 위험 │
└────────────────────────────────────────────────────────────────────┘
실무적 선택 기준:
- 데이터 소스와 분석 방식이 안정적 → 스키마 온 라이트 (데이터 웨어하우스)
- 데이터 소스가 다양하고 분석 방식이 빈번히 변화 → 스키마 온 리드 (데이터 레이크)
Ⅳ. 스키마 온 라이트의 장점과 단점
장점:
1. 데이터 품질 사전 보장 잘못된 데이터는 저장 시점에서 차단되므로, 저장된 데이터의 품질이 보장됩니다. 분석가와 개발자는 저장된 데이터를 신뢰할 수 있습니다.
2. 저장소 효율성 스키마가 사전 정의되어 있으므로, 적절한 데이터 타입과 압축을 적용할 수 있습니다. 이는 저장 공간을 절약하고 성능을 향상시킵니다.
3. 빠른 분석 데이터가 이미 정제되고 구조화되어 있으므로, 분석 SQL 작성이 비교적 간단합니다. 조인, 필터링, 집계가 정의된 스키마를 기반으로 효율적으로 수행됩니다.
4. 명확한 데이터 계약 스키마가 문서화되어 있으므로, 데이터 공급자(Producer)와 소비자(Consumer) 간의 계약이 명확합니다.
단점:
1. 유연성 부족 **새로운 데이터 소스**나 **예상치 못한 데이터 형식**이 등장하면, 기존 스키마를 변경하거나 ETL 파이프라인을 수정해야 합니다. 이 과정에서 시간과 비용이 발생합니다.
2. 데이터 소스 분석 부담 저장 전에 원본 데이터를 분석하여 스키마를 설계해야 합니다. **반정형/비정형 데이터**의 경우 스키마 설계가 매우 어렵습니다.
3. 적재 시 오버헤드 ETL/ELT 과정에서 데이터 변환과 검증이 필요하므로, 데이터 적재 시간이 길어질 수 있습니다. 특히 대용량 데이터에서는 이 부담이 가중됩니다.
4.スキーマ 변경의 어려움 운영 중인 시스템에서 스키마를 변경하려면 애플리케이션 호환성, 데이터 Migration 등 고려할 사항이 많습니다.
Ⅴ. 스키마 온 라이트의 실제 적용과 📢 비유
주요 적용 영역:
- 전통적 데이터 웨어하우스: Oracle Exadata, Teradata, Snowflake 등
- 관계형 데이터베이스: PostgreSQL, MySQL, Oracle 등 모든 RDBMS
- 엔터프라이즈 애플리케이션: ERP, CRM, 회계 시스템 등
하이브리드 접근: 많은 기업에서는 **스키마 온 라이트 + 스키마 온 리드**의 하이브리드를 채택합니다.
- 핵심 비즈니스 데이터(고객, 주문, 재고 등) → 스키마 온 라이트로 무결성 보장
- 로그, 센서 데이터, SNS 데이터 → 스키마 온 리드로 유연하게 수집
이는 "은행的金庫는 엄격한 검증을 거치지만(스키마 온 라이트),_ 창구의Various 서류는 일단 받고 나중에 분류하는_" 것과 같습니다.
📢 섹션 요약 비유: 스키마 온 라이트는 **"호텔 체크인 절차에 비유"**할 수 있습니다. 호텔에 체크인할 때 본인 인증, 카드 사전 승인, 예약 정보 확인 등을 체크인 시점에 모두 처리합니다. 문제가 있으면 (예약이 없거나, 신용카드가 거절되거나) 입실이 거부됩니다. 방에 들어간 모든 게스트는 (청결하고, 결제 수단이 확보된, 적법한) 것이 보장됩니다. 그러나 유연성은 제한됩니다 — "_예약 없이 찾아온 VIP_에게 (당연히) 빈 방이 없을 수 있습니다". 이는 데이터 저장에서도 마찬가지로, 사전 정의되지 않은 데이터는 저장할 수 없습니다.