단일 진실 원천

단일 진실 원천은 한 가지 정보를 두고 어느 값이 맞는지 가려 줍니다. 그 정보를 고치는 곳을 한 군데로 정합니다. 다른 시스템은 거기서 값을 받아 갑니다. 값이 어긋나면 언제나 그 한 곳을 따릅니다. 그래서 부서마다 같은 숫자가 다르게 나오는 일을 막습니다.

쉽고 빠른 이해

단일 진실 원천은 한 정보의 정답을 한 곳에만 두는 원칙입니다. 쇼핑몰이라면 회원 주소의 정답은 회원 데이터베이스 하나에만 있습니다. 배송 시스템과 메일 발송 시스템은 거기서 주소를 읽어 갑니다.

같은 정보를 여러 곳에서 따로 고치면 값이 갈립니다. 어느 쪽이 맞는지 아무도 가려 주지 못합니다. 마케팅 팀과 재무 팀이 같은 달 매출을 다르게 보고하는 일이 이렇게 생깁니다.

어떻게 도나:

1. 정보마다 정답을 가질 곳을 하나 정합니다
2. 값을 고칠 때는 그곳에서만 고칩니다
3. 다른 곳은 그곳에서 값을 받아 갑니다. 값이 어긋나면 그곳을 따릅니다

대가도 있습니다. 모두가 한 곳에 기대므로 그곳이 멈추면 여럿이 함께 멈춥니다. 받아 간 값은 조금 늦게 따라와서 잠깐 옛 값이 보이기도 합니다. 어느 부서의 값을 정답으로 삼을지 먼저 합의해야 합니다.

상세

가족 모임 일정을 부엌 벽의 달력 한 장에 적기로 정한 집이 있습니다. 식구들은 그 일정을 각자 수첩에 옮겨 적어 다닙니다. 수첩과 달력이 다르면 모두 달력을 믿습니다. 일정을 바꿀 때도 달력에 적습니다.

단일 진실 원천(Single Source of Truth, SSOT)은 정보마다 정답을 가진 곳을 하나만 정해 두는 원칙입니다. 그렇게 정해진 한 곳을 가리킬 때도 같은 이름을 씁니다. 쇼핑몰이라면 회원 주소의 정답은 회원 데이터베이스가 가집니다. 배송 시스템과 메일 발송 시스템은 주소가 필요할 때 거기서 읽어 갑니다.

「진실」은 모두가 맞다고 인정하는 값입니다. 「원천」은 모두가 그 값의 정답으로 삼기로 한 곳입니다. 대개는 그 값이 처음 생기고 고쳐지는 곳이 원천이 됩니다. 이 이름을 「단일 진실 공급원」으로 옮기기도 합니다.

단일 진실 원천이 사본을 금지하는 것은 아닙니다. 같은 값을 여러 곳에 복사해 두어도 됩니다. 정하는 것은 어느 쪽이 정답이냐입니다. 사본과 원천이 다르면 사본이 틀린 것으로 칩니다.

같은 정보가 여러 곳에 있을 때 무엇이 곤란한지부터 쇼핑몰 예로 봅니다. 그다음 원천과 사본이 역할을 어떻게 나누는지 봅니다. 이어서 분석과 개발에서 원천을 어디에 두는지 봅니다. 마지막으로 한 곳에 기대는 대가와 원천을 하나로 못 정할 때를 봅니다.

같은 정보가 여러 곳에 있을 때

쇼핑몰의 회원 주소가 두 곳에 있다고 해 봅시다. 회원 데이터베이스에 한 벌, 배송 시스템의 주소록에 또 한 벌이 있습니다. 회원이 주소를 바꾸면 회원 데이터베이스만 바뀝니다. 배송 시스템은 옛 주소로 상자를 보냅니다.

두 곳 모두에서 고칠 수 있으면 더 곤란합니다. 상담원이 배송 시스템에서 주소를 고치면 이번에는 회원 데이터베이스가 옛 값을 가집니다. 두 값이 다를 때 어느 쪽이 맞는지 가려 줄 규칙이 없습니다.

숫자에서도 같은 일이 생깁니다. 마케팅 팀과 재무 팀이 주문 데이터를 각자 제 저장소에 복사해 두었다고 해 봅시다. 복사한 날과 걸러 낸 주문이 저마다 달라서 같은 달 매출이 두 보고서에서 다르게 나옵니다. 회의는 어느 숫자가 맞는지 따지는 데 시간을 씁니다.

이렇게 부서마다 따로 쌓여 서로 맞춰지지 않는 데이터가 데이터 사일로입니다. 단일 진실 원천은 사일로가 만든 어긋남을 막으려고 세우는 약속입니다.

원천과 사본의 역할

단일 진실 원천을 세우면 정보를 가진 곳이 두 역할로 갈립니다. 원천은 정답을 가집니다. 사본은 원천의 값을 받아 씁니다.

사본을 두는 까닭은 빨리 읽기 위해서입니다. 필요할 때마다 원천에 물으면 원천이 붐빕니다. 원천이 멀리 있으면 읽는 데도 오래 걸립니다. 그래서 자주 읽는 쪽은 값을 가까이 받아 둡니다.

두 역할을 가르는 규칙은 아래와 같습니다. 핵심은 값을 고치는 일이 원천에서만 일어난다는 것입니다.

회원 주소로 그리면 이렇습니다. 주소를 바꾸는 요청은 회원 데이터베이스로만 들어갑니다. 배송 시스템, 메일 발송 시스템, 분석용 저장소는 거기서 흘러나온 값을 받습니다.

flowchart TD
    U["주소를 바꾸는 요청"] --> S["원천 · 회원 데이터베이스"]
    S --> C1["사본 · 배송 시스템"]
    S --> C2["사본 · 메일 발송 시스템"]
    S --> C3["사본 · 분석용 저장소"]

사본으로 값을 흘려보내는 방법은 여럿입니다.

• 복제 — 원천의 데이터를 다른 서버에 계속 옮겨 둡니다
• 캐시 — 자주 읽는 값을 가까이 잠시 보관합니다
• 배치 처리 — 정해진 때마다 한꺼번에 복사해 옵니다

어느 방법이든 값이 흐르는 방향은 원천에서 사본 쪽 하나입니다.

정보마다 따로 정하는 원천

단일 진실 원천은 회사에 시스템을 하나만 두라는 말이 아닙니다. 원천은 정보 하나하나마다 정합니다. 회원 정보와 주문과 재고의 원천이 서로 다른 시스템이어도 됩니다.

원천을 고르는 기준은 대개 그 값을 누가 만들고 고치느냐입니다. 주소는 회원이 고치므로 회원 데이터베이스가 원천입니다. 재고는 창고에서 물건이 드나들 때 바뀌므로 재고 시스템이 원천입니다.

표에서 한 정보의 원천은 언제나 하나입니다. 한 시스템이 어떤 정보에서는 원천이고 다른 정보에서는 사본일 수 있습니다. 주문을 받는 시스템은 주문 내역의 원천입니다. 같은 시스템이 재고 수량은 재고 시스템에서 받아 씁니다.

데이터 분석의 단일 진실 원천

분석에서는 데이터 웨어하우스가 흔히 이 역할을 맡습니다. 웨어하우스는 여러 시스템에 흩어진 데이터를 한곳에 모아 분석하기 좋게 정리해 둔 저장소입니다. 부서들이 주문 데이터를 각자 복사하는 대신 모두 웨어하우스에서 읽습니다.

앞 그림의 분석용 저장소가 바로 웨어하우스입니다. 운영 시스템 쪽에서 보면 웨어하우스는 주문 데이터베이스와 회원 데이터베이스의 사본입니다. 주문과 주소를 고치는 일은 여전히 그 데이터베이스들에서 일어납니다.

분석하는 쪽에서 보면 사정이 다릅니다. 부서들은 운영 데이터베이스를 직접 읽지 않고 웨어하우스만 읽기로 합의합니다. 복사를 한 번만, 한 가지 방법으로 해 두었기 때문입니다. 그래서 분석에서는 모두가 정답으로 삼는 웨어하우스가 원천입니다.

한 부서가 쓸 데이터만 떼어 둔 데이터 마트도 웨어하우스에서 받아 옵니다. 그러면 부서마다 마트를 따로 두어도 같은 원천을 나눠 씁니다.

같은 데이터를 읽어도 세는 법이 다르면 숫자는 또 갈립니다. 매출을 결제한 금액으로 셀 수도 있습니다. 결제 금액에서 환불을 뺀 금액으로 셀 수도 있습니다. 그래서 분석에서는 데이터뿐 아니라 계산법에도 원천을 둡니다.

매출이나 주문 수처럼 사업을 재는 숫자가 지표입니다. 분석에서는 지표마다 세는 법을 한 곳에 적어 둡니다. 「매출은 결제 금액에서 환불을 뺀 값」처럼 적는 식입니다. 보고서와 대시보드(지표 여러 개를 한눈에 보여 주는 화면)는 저마다 계산식을 두지 않고 이 정의를 가져다 씁니다.

이렇게 적은 지표 정의는 웨어하우스 위에 한 벌 얹힙니다. 여러 도구에 같은 지표 정의를 나눠 주는 이 계층이 시맨틱 레이어입니다.

두 계층을 쌓으면 아래 그림이 됩니다. 아래 계층의 웨어하우스는 어느 데이터를 읽을지를 하나로 정합니다. 위 계층의 지표 정의는 그 데이터를 어떻게 셀지를 하나로 정합니다.

flowchart TD
    A["주문 데이터베이스"] --> W["데이터 웨어하우스 · 데이터의 원천"]
    B["회원 데이터베이스"] --> W
    W --> M["지표 정의 · 계산법의 원천"]
    M --> R1["마케팅 보고서"]
    M --> R2["재무 보고서"]

개발에서 만나는 단일 진실 원천

단일 진실 원천은 데이터에만 쓰는 말이 아닙니다. 코드와 설정을 다룰 때도 같은 뜻으로 씁니다. 같은 내용을 두 파일에 손으로 적으면 한쪽만 고쳐지는 일이 똑같이 생기기 때문입니다.

개발에서는 사람이 고치는 파일 하나가 원천이 됩니다. 나머지는 그 파일에서 만들어지거나 그 파일을 읽어 갑니다. 흔한 예 셋은 테이블 구조, 프로그램끼리 주고받는 약속, 설정값입니다.

스키마는 테이블과 열이 어떻게 생겼는지를 적은 것입니다. 개발용 데이터베이스와 운영용 데이터베이스는 같은 스키마를 가져야 합니다. 두 곳에서 손으로 테이블을 고치면 둘이 금세 달라집니다.

마이그레이션 파일은 스키마를 바꾸는 단계를 차례로 적어 둔 파일입니다. 이 파일을 차례로 실행하면 어느 데이터베이스에서든 같은 스키마가 나옵니다. 그래서 테이블 구조의 원천은 마이그레이션 파일입니다.

API(Application Programming Interface)는 프로그램끼리 요청과 응답을 주고받는 약속입니다. 요청과 응답의 모양을 정의 파일 하나에 적어 두면 그 파일이 API 약속의 원천이 됩니다.

코드 생성은 정의 파일에서 코드를 만들어 내는 일입니다. API 정의 파일에서 서버 코드의 뼈대와 클라이언트 코드를 뽑아냅니다. 양쪽이 약속을 손으로 따로 옮겨 적지 않으므로 둘이 갈릴 일이 없습니다.

설정값은 설정 파일 한 곳에 둡니다. 여러 서비스가 그 파일을 읽어 가므로 값을 바꿀 때 한 곳만 고칩니다. 세 예를 표로 모으면 이렇습니다.

표의 셋은 같은 모양입니다. 사람은 원천만 고칩니다. 나머지는 원천에서 다시 만들거나 다시 읽으므로 따로 고칠 일이 없습니다.

단일 진실 원천은 코드 중복을 줄이자는 DRY(Don't Repeat Yourself, 같은 것을 되풀이해 적지 말라) 원칙과 뿌리가 같습니다. 둘 다 한 가지 지식을 한 곳에만 적으라고 합니다.

한 곳에 기대는 대가

모두가 한 곳에서 값을 받으므로 그곳이 멈추면 여럿이 함께 멈춥니다. 단일 장애점은 이렇게 하나가 멈추면 전체가 멈추는 곳입니다. 그래서 원천에는 보통 예비 서버를 붙여 둡니다.

사본은 원천보다 늦게 바뀝니다. 그 사이에 사본을 읽으면 옛 값이 보입니다. 이런 값을 낡은 데이터라고 부릅니다. 방금 바꾼 값을 바로 봐야 하는 일이라면 사본 대신 원천을 읽습니다.

원천을 정하는 일은 기술보다 합의에 가깝습니다. 매출을 어떻게 셀지, 고객 정보를 어느 팀이 고칠지를 부서들이 먼저 정해야 합니다. 이런 결정과 책임을 정해 두는 일을 데이터 거버넌스라고 부릅니다.

원천을 하나로 못 정할 때

한 회사가 다른 회사를 합치면 고객 목록이 두 벌 생깁니다. 두 시스템 모두 제 고객 정보를 오래 고쳐 왔으므로 어느 쪽도 버리기 어렵습니다.

이럴 때는 두 목록에서 같은 고객을 찾아 묶습니다. 값이 다르면 어느 쪽을 믿을지 규칙으로 정합니다. 그렇게 기준이 되는 기록 하나를 따로 만들면 그 기록이 새 원천이 됩니다. 이 일을 마스터 데이터 관리라고 부릅니다.

관련 항목

단일 진실 원천이 속하는 분야

데이터 엔지니어링 · 데이터 관리 · 정보 시스템 · 소프트웨어 설계

단일 진실 원천이 없을 때 생기는 문제

데이터 사일로 · 데이터 불일치 · 중복 데이터 · 이중 쓰기

단일 진실 원천을 맡는 저장소

데이터베이스 · 데이터 웨어하우스 · 데이터 레이크 · 레이크하우스 · 설정 파일

원천의 값을 사본으로 흘려보내는 방법

복제 · 캐싱 · 배치 처리 · 변경 데이터 캡처 · ETL · 데이터 파이프라인

원천의 데이터를 받아 쓰는 분석 계층

데이터 마트 · 비즈니스 인텔리전스 · 대시보드 · 시맨틱 레이어 · 지표

단일 진실 원천을 정하고 지키는 관리 활동

데이터 거버넌스 · 마스터 데이터 관리 · 데이터 품질 · 데이터 계보 · 데이터 계약 · 데이터 카탈로그 · 메타데이터

개발에서 단일 진실 원천을 두는 대상

스키마 · 마이그레이션 · API · 코드 생성 · 코드형 인프라 · 상태 관리

원천에 기댈 때 치르는 대가

단일 장애점 · 낡은 데이터 · 복제 지연 · 최종 일관성

단일 진실 원천과 뿌리가 같은 원칙·용어

DRY · 정규화 · 기록 시스템 · 골든 레코드