어디에나 SSOT
어디에나 SSOT
SSOT (Single Source of Truth) 는 데이터 거버넌스 용어에서 시작해 코드 · 문서 · 스키마 운영의 원칙으로 확장. 이 글은 출처 · 적용 영역 · 트레이드오프.
1. SSOT 에 대한 이야기
Wikipedia "Single Source of Truth" 항목의 정의:
"the practice of structuring information models and associated data schemas such that every data element is mastered (or edited) in only one place."
각 데이터 요소가 한 곳에서만 권위 있게 편집되도록 구성하라는 원칙. 같은 항목을 SPOT (Single Point of Truth) 로도 부름.
기업 데이터 관리 맥락에서 출발한 개념이며 구현 전략은 보통:
- Master Data Management (MDM) — 권위 있는 허브가 여러 출처에서 갱신을 받아 결정한 뒤 전파.
- Event Sourcing — 시스템 상태를 이벤트의 정렬된 시퀀스로 저장. 이벤트 스토어 자체가 진실.
- Data Warehouse — 보고 / 분석용 단일 버전. 운영계 데이터는 별도.
2. 코드 SSOT
같은 상수 · 타입 · 비즈니스 규칙을 여러 파일에 중복 선언하지 않음. 한 곳을 SSOT 로 정해 import. DRY 원칙 (01-kiss-dry-yagni) 의 "지식의 단일 표현" 과 같은 맥락.
3. 문서 SSOT
같은 사실 (예: 포트 매핑 · 환경변수 목록 · API 엔드포인트) 을 여러 README 에 적으면, 한쪽이 갱신되지 않을 때 사실이 갈라짐. 한 파일을 SSOT 로 지정하고 다른 곳에서는 링크로만 참조.
4. 스키마 SSOT
DB 스키마는 두 모델 중 하나로 운영:
- 단일 SQL SSOT —
schema.sql같은 파일이 현재 스키마의 정답. 모든 변경은 이 파일을 직접 수정.CREATE TABLE IF NOT EXISTS류로 멱등성을 유지하는 경우가 많음. - 마이그레이션 도구 — Flyway (Redgate, 2010) · Liquibase (2006) · Alembic (SQLAlchemy) 등이 변경의 순서 있는 시퀀스를 SSOT 로. 각 마이그레이션 파일이 한 시점의 변경을 담고, 누적 적용으로 현재 스키마가 만들어짐.
두 모델의 트레이드오프:
| 축 | 단일 SQL SSOT | 마이그레이션 도구 |
|---|---|---|
| 현재 상태 파악 | 파일 한 개로 즉시 | 모든 마이그레이션을 누적 추적 |
| 운영 DB 변경 | 별도 절차 필요 | 자동 적용 표준 |
| 히스토리 | git 히스토리에 의존 | 도구가 명시적으로 보관 |
| 적합한 환경 | 스키마 변경이 적고, 환경 재구축이 잦음 | 운영 DB 가 장수하고 변경이 잦음 |
작은 팀이나 신규 프로젝트, 또는 환경마다 매번 새로 만들 수 있는 스키마라면 단일 SQL 모델이 가벼움. 운영 DB 가 길게 살아 있고 데이터가 마이그레이션돼야 한다면 마이그레이션 도구가 안전.
5. 다른 길
SSOT 가 항상 가능한 것은 아님. Wikipedia 항목도 "다수의 정보시스템이 공통 데이터를 각자 필요로 하는 기업에서는 이상적 구현이 드물다" 고 명시.
대안 또는 보완:
- Eventual Consistency 기반 분산 SSOT — 권위 있는 출처 하나를 두되 복제본을 두며, 갱신 지연을 허용.
- Federated Truth — 도메인별로 권위 있는 출처를 두고 도메인 간에는 명시적 계약 (API · 이벤트) 으로 동기화.
분산 시스템에서는 진정한 의미의 단일 진실이 비용을 부르는 경우가 많아, 도메인 단위 SSOT 가 현실적이라는 평이 흔합니다 (04-tradeoff-not-bestpractice 의 CAP 참조).
6. 자주 쓰는 모양
문서 SSOT 의 한 형태:
# port-mapping.md (SSOT)
| 서비스 | 포트 |
|---|---|
| api | 8080 |
| web | 3000 |
# 다른 README 들
포트 매핑은 [port-mapping.md](docs/port-mapping.md) 참조.
스키마 SSOT (단일 SQL):
-- schema.sql
CREATE TABLE IF NOT EXISTS users (
id BIGSERIAL PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
스키마 SSOT (Flyway):
db/migration/
V1__create_users.sql
V2__add_user_status.sql
7. 자주 걸리는 자리
"한 곳에 적었다" 와 "한 곳이 권위다" 는 다름 — 권위 있는 출처가 어느 것인지 합의되지 않으면 사람들은 자기에게 가까운 사본을 봄.
SSOT 를 잘게 쪼개지 않으면 한 파일이 비대해져 변경 충돌이 잦아짐 — 도메인 단위로 SSOT 분할.
마이그레이션 도구 도입 후에도 운영 DB 에 사람이 직접 ALTER 를 치면 도구의 SSOT 가치가 무너짐 — 운영 변경 경로를 한 줄기로 좁히는 운영 규약.
문서 SSOT 와 코드의 사실 (예: 환경변수 이름) 이 갈라짐 — 가능하면 코드에서 자동 추출 (린트 · 코드 생성) 하거나, 사실 변경 PR 에 문서 변경을 의무화.
하고픈 말
SSOT 는 "한 곳에서만 권위 있게 편집" 의 단순한 원칙. 코드 · 문서 · DB 스키마 셋 모두에 적용 가능합니다. 운영 DB 의 변경 경로를 한 줄기로 좁히고, 같은 사실은 한 자리에 두고 다른 곳은 링크로만 참조 — 이 둘이 SSOT 의 실용적 핵심.
Next
- folder-as-contract
- tradeoff-not-bestpractice
Wikipedia Single Source of Truth · Flyway 공식 문서 · Liquibase 공식 문서 · Alembic 공식 문서 · Martin Fowler Evolutionary Database Design · Event Sourcing (Martin Fowler) · Pat Helland — Data on the Outside vs. Data on the Inside 를 참고합니다.