source of truth

도입

source of truth의 핵심은 모든 데이터를 무조건 한곳에 몰아넣는 것이 아니라, 특정 도메인이나 사실에 대해 가장 권위 있고 기준이 되는 원천을 정해 다른 시스템이 그 기준을 따라가게 만드는 데 있다

실무에서 가장 답답한 순간 중 하나는 같은 고객, 같은 상품, 같은 설정을 가리키는데 시스템마다 값이 다를 때입니다. 대시보드는 1,204명을 말하고 CRM은 1,187명을 말하며, 운영 문서는 최신이 아니고, 배포 설정은 실제 클러스터 상태와 어긋나 있습니다.

이때 필요한 개념이 바로 source of truth입니다. 핵심은 “어느 값이 진짜인가”를 사후에 싸우는 것이 아니라, 애초에 무엇이 기준값인지를 설계 단계에서 정하는 것입니다. 그래서 source of truth를 이해한다는 것은 단순히 데이터 저장 위치를 정하는 일이 아니라, 권한, 변경 경로, 복제, 동기화, 신뢰 기준을 함께 정하는 일에 가깝습니다.

필요성

source of truth를 이해하면 숫자가 왜 다르게 보이는지, 설정 드리프트가 왜 생기는지, 어떤 시스템을 기준으로 데이터를 교정해야 하는지를 구조적으로 설명할 수 있다

조직이나 시스템이 커질수록 같은 정보가 여러 곳에 복제됩니다. 고객 정보는 CRM에도 있고, 마케팅 툴에도 있고, 데이터 웨어하우스에도 있고, API 캐시에도 있습니다. 문제는 복제 자체가 아니라, 어느 순간부터 무엇이 기준인지 불분명해진다는 점입니다.

source of truth가 없으면 각 팀은 자기 시스템을 진실이라고 믿게 되고, 결국 데이터 품질 문제는 기술 문제가 아니라 조직 신뢰 문제로 번집니다. 반대로 기준 원천이 분명하면, 파생본이 어긋났을 때 무엇을 기준으로 다시 맞춰야 하는지 즉시 판단할 수 있습니다.

source of truth가 특히 중요한 상황

• 같은 엔터티가 여러 시스템에 중복 저장되는 경우
• 운영 환경의 실제 상태와 선언적 설정이 자주 어긋나는 경우
• 지표 정의가 팀마다 달라 대시보드가 서로 다른 숫자를 보여 주는 경우
• 스키마 정의가 서비스마다 흩어져 데이터 교환이 불안정한 경우
• 수정 권한과 조회 권한이 뒤섞여 누가 기준을 책임지는지 모르는 경우

정의

source of truth는 특정 사실이나 도메인에 대해 다른 시스템과 프로세스가 기준으로 삼는 가장 신뢰되는 권위 원천이며, 기술 자체라기보다 시스템이 맡는 역할에 가깝다

source of truth는 특정 제품 이름이 아닙니다. 데이터베이스일 수도 있고, Git 저장소일 수도 있고, 스키마 레지스트리일 수도 있고, 메트릭 레이어나 문서 스펙일 수도 있습니다. 중요한 것은 “어디에 저장돼 있느냐”보다 무엇을 기준으로 삼느냐입니다.

즉, source of truth는 기술 카테고리보다 권위(authority)의 개념입니다. 이 필드의 값은 어디서 최종적으로 결정되는가, 이 설정의 의도된 상태는 어디에 선언되는가, 이 지표 정의는 어디를 보면 되는가를 정하는 역할입니다.

핵심 문장

source of truth는 “가장 많이 복제된 데이터”가 아니라, 어긋났을 때 되돌아가 확인해야 하는 기준 원천입니다.

핵심 원리

좋은 source of truth는 중앙에 하나 놓여 있기만 한 저장소가 아니라, 누가 수정할 수 있는지·누가 소비하는지·변경이 어떻게 전파되는지·기준이 어떻게 보존되는지까지 함께 설계된 구조다

많은 조직이 source of truth를 “중앙 DB 하나 만들기”로 오해합니다. 하지만 실제로 중요한 것은 중앙화 그 자체보다 기준값이 흐트러지지 않게 만드는 운영 규칙입니다.

예를 들어 source of truth가 제대로 작동하려면 최소한 네 가지가 필요합니다. 첫째, 특정 도메인에 대해 수정 권한이 한 방향으로 수렴해야 합니다. 둘째, 변경 사실이 다른 소비자에게 적절히 전파되어야 합니다. 셋째, 파생본과 원본을 구분할 수 있어야 합니다. 넷째, 누가 이 기준을 소유하고 있는지가 분명해야 합니다.

기본 구조

source of truth를 실무에서 설계하려면 도메인 경계, 소유자, 쓰기 경로, 읽기 소비자, 동기화 방식, 감사 추적을 각각 따로 봐야 한다

구성 요소	설명	실무 포인트
도메인 경계	무엇에 대한 truth 인지 범위를 정함	“고객 전체”가 아니라 “고객 연락처”, “청구 상태”, “배포 설정”처럼 쪼개는 편이 현실적
소유자	누가 기준 데이터의 품질과 변경을 책임지는지	기술 팀보다 업무 책임자가 명확해야 오래 버팀
쓰기 경로	어디에서 기준값을 변경할 수 있는지	쓰기 경로가 여러 군데면 source of truth가 흔들리기 쉬움
읽기 소비자	누가 이 기준값을 읽는지	캐시, API, 대시보드, 배치 등 소비 경로를 함께 봐야 함
동기화 방식	복제, CDC, 이벤트, 배치 동기화 등	파생본은 결국 동기화 지연과 드리프트 위험을 가짐
감사 추적	언제 누가 무엇을 바꿨는지	source of truth일수록 변경 이력과 승인 흐름이 중요함

기본 구현

source of truth는 설계 문서의 구호로 끝나면 아무 의미가 없고, 실제로는 “수정은 한곳에서만, 조회는 여러 곳에서”라는 흐름으로 구현되어야 한다

예시: 고객 이메일의 source of truth

[CRM]
  - customer.email 필드의 권위 원천
  - 수정 권한은 CRM만 가짐
  - 변경 시 이벤트 또는 CDC 발생
        ↓
[Data Warehouse]
[Marketing Tool]
[Search Index]
[Notification Service]

규칙
- 이메일 수정은 CRM에서만 수행
- 다른 시스템은 복사본만 가짐
- 값이 다르면 CRM 값을 기준으로 교정
- 복사본의 최신성은 동기화 지연을 감안해 해석

이 구조에서 핵심은 저장 위치가 하나라는 사실보다 기준 변경 경로가 하나라는 사실입니다. 읽는 곳은 많아도 상관없지만, 쓰는 기준점이 흔들리면 source of truth는 바로 무너집니다.

패턴 1. 권위 원천과 파생본

source of truth를 잘 잡으려면 원천 데이터와 파생본을 구분해야 하며, 특히 캐시·리포트·검색 인덱스·분석 저장소를 기준 원천으로 착각하지 않는 것이 중요하다

파생본은 많을수록 좋을 수도 있습니다. 읽기 성능을 위해 캐시가 필요하고, 검색을 위해 인덱스가 필요하고, 분석을 위해 데이터 웨어하우스가 필요할 수 있습니다. 문제는 그 파생본들이 어느 순간부터 원천처럼 행동하기 시작할 때입니다.

source of truth가 분명한 구조에서는 파생본이 틀어져도 “무엇을 기준으로 다시 맞출 것인가”가 명확합니다. 반대로 기준이 없으면 파생본끼리 서로를 참조하면서 잘못된 값이 증폭될 수 있습니다.

실전 감각

검색 인덱스가 빠르다고 해서 truth가 되는 것은 아닙니다. 대시보드가 많이 쓰인다고 해서 truth가 되는 것도 아닙니다. 원천을 정하는 기준은 사용 빈도가 아니라 권위와 수정 경로입니다.

패턴 2. System of Record, Source of Truth, SSOT

실무에서 가장 자주 헷갈리는 부분은 system of record와 source of truth와 single source of truth를 완전히 같은 말로 보는 것이며, 실제로는 문맥에 따라 구분이 필요하다

데이터 아키텍처 문맥에서는 System of Record가 특정 도메인의 원본 비즈니스 데이터를 기록하는 시스템을 뜻하는 경우가 많습니다. 예를 들어 CRM은 고객 상호작용의 system of record, ERP는 재무 도메인의 system of record일 수 있습니다.

반면 IBM이 설명하는 Source of Truth는 여러 system of record를 조화시키고 연결해 더 전체적인 뷰를 제공하는 역할에 가깝습니다. 즉, SOR는 도메인별 원본 기록 장치에 가깝고, SOT는 여러 원본을 통합해 조직이 신뢰할 기준 뷰를 만드는 쪽으로 이해할 수 있습니다.

다만 이 용어는 업계 전체에서 완전히 고정된 수학 공식처럼 쓰이지는 않습니다. Red Hat은 실무적으로 “도메인별 단일 source of truth”를 이야기하고, 때로는 이것을 system of record와 가깝게 표현하기도 합니다. 그래서 중요한 것은 단어 싸움보다 해당 조직에서 무엇을 기준 원천으로 정의했는가입니다.

개념	가까운 의미	실무 감각
System of Record	특정 도메인의 원본 기록 시스템	거래나 마스터 데이터를 최초 생성·보관하는 시스템
Source of Truth	기준으로 삼는 권위 원천	문맥에 따라 단일 도메인 원천일 수도, 통합 뷰일 수도 있음
Single Source of Truth	해당 범위 안에서 기준 원천을 하나로 정한 상태	조직 전체 하나일 수도 있지만, 보통은 범위/도메인을 먼저 정해야 현실적

매우 중요한 주의점

“single”이라는 단어 때문에 모든 데이터를 무조건 하나의 시스템에 넣어야 한다고 생각하기 쉽지만, 실제로는 도메인별 단일 기준 원천이 더 현실적이고 건강한 경우가 많습니다.

패턴 3. GitOps, Schema Registry, Metrics Layer

source of truth는 데이터베이스 개념에만 머무르지 않고, 운영 설정, 스키마 정의, 지표 정의처럼 “무엇을 기준으로 해석하고 실행할 것인가”가 중요한 모든 영역에 등장한다

대표 예시 1. GitOps

GitOps에서는 Git 저장소가 클러스터와 애플리케이션 구성의 source of truth가 됩니다. 중요한 것은 실제 런타임 상태보다 선언된 desired state가 기준이라는 점입니다. 즉, 운영자는 현재 클러스터가 어떻게 생겼는지를 직접 손으로 고치는 대신, Git에 있는 선언적 설정을 기준으로 시스템을 다시 맞춥니다.

대표 예시 2. Schema Registry

마이크로서비스와 이벤트 기반 아키텍처에서는 스키마 레지스트리가 스키마 정의의 source of truth가 됩니다. 서비스들이 각자 로컬 코드에 스키마를 하드코딩해 두면 금방 불일치가 생기지만, 레지스트리를 기준으로 삼으면 검증과 교환 규칙을 더 안정적으로 유지할 수 있습니다.

대표 예시 3. Metrics Layer / Semantic Layer

분석과 BI 문맥에서는 semantic layer나 metrics layer가 source of truth 역할을 합니다. 매출, 활성 사용자, 이탈률 같은 지표를 팀마다 제각각 계산하면 조직 전체가 서로 다른 숫자를 보게 됩니다. 이때 지표 정의를 한 곳에서 모델링하면 “숫자의 기준”이 생깁니다.

source of truth가 자주 등장하는 대표 문맥
- 고객/상품/계약 데이터의 기준 시스템
- GitOps의 선언적 설정 저장소
- 스키마 레지스트리
- 메트릭/세맨틱 레이어
- 네트워크 자동화의 intended state 저장소
- 정책/문서/사양(specification) 기준 문서

한계와 주의점

source of truth는 매우 유용하지만, 이를 “모든 데이터를 중앙 한곳에 몰아넣자”로 오해하면 오히려 복잡도와 운영 비용을 키우고 도메인 경계를 망가뜨릴 수 있다

가장 흔한 실패는 source of truth를 기술적으로만 이해하는 것입니다. “중앙 DB 하나 만들자”, “CMDB 하나면 다 해결된다”, “Git 한 저장소에 다 몰자” 같은 접근은 오히려 도메인별 책임을 흐리게 만들 수 있습니다.

또 다른 문제는 freshness입니다. source of truth가 아무리 잘 정의되어 있어도 파생본이 많으면 결국 복제 지연과 드리프트가 생깁니다. 그래서 source of truth는 중앙화만으로 완성되지 않고, 변경 전파와 관측 가능성까지 포함해 운영되어야 합니다.

특히 주의해야 할 지점

• 모든 데이터를 한 시스템에 몰아넣는 방식으로 오해하지 않기
• 기준 원천과 조회 최적화용 파생본을 구분하기
• 쓰기 경로가 여러 군데면 사실상 source of truth가 무너진다는 점 인식하기
• 변경 전파와 최신성 보장을 함께 설계하기
• 권한과 소유자가 없는 “명목상 SSOT”를 만들지 않기

자주 하는 실수

source of truth를 실패하게 만드는 가장 흔한 원인은 저장 위치만 정하고, 누가 언제 어떻게 바꾸고 다른 시스템이 언제 따라와야 하는지를 정하지 않는 데 있다

• source of truth = 중앙 저장소 하나라고만 생각함
• 도메인별 경계를 나누지 않고 조직 전체를 하나로 묶으려 함
• 쓰기 권한을 여러 시스템에 열어 둠
• 파생본과 원천을 같은 수준으로 취급함
• 변경 전파, 동기화 지연, 캐시 무효화를 무시함
• 소유자와 품질 책임자를 정하지 않음
• 문서나 지표 정의를 source of truth로 삼아 놓고 자동 반영 경로를 만들지 않음

실무 루틴

source of truth를 설계할 때는 먼저 “무엇에 대한 truth인가”를 좁히고, 그다음 수정 경로와 소비 경로와 동기화 방식을 정하는 순서가 맞다

1. 먼저 대상 도메인을 좁힌다. 예: 고객 이메일, 배포 설정, 주문 상태, 지표 정의
2. 누가 그 값을 소유하고 수정할 수 있는지 정한다.
3. 권위 원천이 무엇인지 명확히 선언한다.
4. 다른 시스템은 파생본인지 기준 원천인지 표기한다.
5. 변경 이벤트, CDC, 배치, 수동 승인 등 전파 방식을 정한다.
6. 불일치가 발생했을 때 무엇을 기준으로 복구할지 문서화한다.
7. 감사 로그, 버전 이력, 품질 검증 자동화를 붙인다.

디버깅

source of truth 관련 문제를 디버깅할 때는 값이 다르다는 사실만 보는 것이 아니라, 이 필드의 기준 원천이 어디인지와 그 값이 다른 시스템으로 어떻게 전파되는지를 먼저 나눠 보는 것이 가장 빠르다

1

먼저 이 값에 대한 source of truth가 어디인지 문서와 운영 기준을 확인한다.

2

기준 원천에서 실제 값이 무엇인지, 파생본에서 무엇이 보이는지 비교한다.

3

복제/CDC/이벤트/배치 중 어떤 동기화 단계에서 끊겼는지 본다.

4

파생본이 캐시인지, 리포트인지, 검색 인덱스인지, 분석 저장소인지 유형을 분리한다.

5

근본 원인이 다중 쓰기 경로인지, 소유자 부재인지, 자동 동기화 누락인지 확인한다.

source of truth 문제를 볼 때 먼저 나눌 질문
- 무엇에 대한 truth 인가?
- 기준 원천은 어디인가?
- 누가 수정 권한을 가지는가?
- 어떤 시스템이 파생본을 들고 있는가?
- 동기화는 어떤 방식으로 일어나는가?
- 불일치가 생기면 무엇을 기준으로 복구할 것인가?

요약

source of truth의 본질은 모든 데이터를 한곳에 모으는 것이 아니라, 특정 도메인에 대해 가장 권위 있는 기준 원천을 정하고 다른 시스템이 그 기준을 파생·복제·동기화하도록 만드는 데 있으며, 실제 설계의 핵심은 중앙화보다 도메인 경계, 쓰기 경로, 변경 전파, 소유권을 명확히 하는 데 있다

• ✅ source of truth는 기술 제품명이 아니라 기준 원천의 역할이다.
• ✅ 파생본이 틀어졌을 때 되돌아가 확인할 수 있는 권위 원천이어야 한다.
• ✅ source of truth는 보통 도메인 경계와 함께 설계하는 편이 현실적이다.
• ✅ system of record와 source of truth는 문맥에 따라 구분이 필요하다.
• ✅ GitOps에서는 Git, 스키마 관리에서는 schema registry, 분석에서는 semantic layer가 source of truth 역할을 할 수 있다.
• ✅ 핵심은 저장 위치보다 쓰기 경로와 소유권과 변경 전파다.
• ✅ “single”을 이유로 모든 데이터를 한곳에 몰아넣는 것은 오히려 안티패턴이 될 수 있다.
• ✅ 좋은 source of truth는 중앙화보다 권위와 일관성과 복구 기준을 제공한다.