SSOT(단일 진실 공급원)란 무엇인가: 데이터 원칙에서 LLM 시대의 사실 근거까지

들어가며: 같은 지표인데 화면마다 숫자가 다르다

회사에서 이런 경험을 한 번쯤 해봤을 겁니다. 이번 달 매출이 마케팅팀 대시보드에서는 12억인데, 재무팀 리포트에서는 11억 8천이고, 영업팀이 보는 CRM 화면에서는 또 다릅니다. 셋 다 "우리 회사 매출"을 보여 준다고 하는데 숫자가 어긋납니다. 회의는 "그 숫자 어디서 나온 거냐"로 시작해서 데이터의 출처를 따지다 끝납니다.

이것은 계산 실수가 아니라 설계의 실패입니다. 같은 사실이 여러 곳에 따로 저장되고 각자 조금씩 다르게 갱신되면, 시스템에는 "복수의 진실"이 생깁니다. 그리고 이 문제를 구조적으로 예방하는 원칙에는 이름이 있습니다. SSOT(Single Source of Truth), 단일 진실 공급원입니다.

이 글은 SSOT가 정확히 무엇인지, 개발·운영·데이터 관리에서 실제로 어떻게 구현하는지, 그리고 왜 하필 LLM 시대에 이 오래된 원칙이 오히려 더 중요해졌는지를 정리합니다. 마지막 질문이 이 글의 핵심입니다. RAG니 grounding이니 하는 최근의 개념들이 사실은 "LLM에게 SSOT를 붙여 주는 일"이라는 것을 보면, 낡아 보이던 데이터 원칙이 AI 애플리케이션의 한복판에 다시 서 있음을 알게 됩니다.

한 줄 정의

SSOT를 한 문장으로 줄이면 이렇습니다. 어떤 정보든 정답이 되는 곳을 딱 하나 정해 두고(정본, canonical), 나머지는 전부 그것을 참조하게 만드는 설계 원칙. 수정은 한 곳에서만 하고(write once), 읽기는 여러 곳에서 한다(read many).

여기서 오해를 하나 미리 풀어야 합니다. SSOT는 "모든 데이터를 물리적으로 한 저장소에 몰아넣는 것"이 아닙니다. 실제로 그렇게 하는 것은 멀티클라우드 환경이나 규제 때문에 비현실적이고, SSOT의 본질도 아닙니다. 핵심은 물리적 단일 저장소가 아니라 각 정보의 논리적 단일 권위입니다. 매출이라는 사실의 정답이 어디인지, 고객 주소의 정답이 어디인지를 각각 하나씩 정해 두는 것이지, 세상 모든 데이터를 한 곳에 쌓는 게 아닙니다.

이 원칙이 노리는 것은 세 가지입니다. 중복 최소화, 무결성, 일관성. 각 정보에 권위 있는 출처를 하나씩 지정하면 모두가 같은 데이터를 보게 되고, 사일로와 불일치와 오류가 예방됩니다. IBM은 이 개념을 "기록 시스템(system of record)"과 나란히 설명하는데, 여러 시스템이 같은 사실을 다룰 때 그중 무엇을 권위 있는 것으로 볼지를 정하는 일이 곧 SSOT를 세우는 일입니다.

SSOT가 없으면 무슨 일이 벌어지나

도입부의 "숫자가 다른" 상황은 우연이 아니라 예측 가능한 연쇄의 끝입니다. 세 단계로 무너집니다.

첫째는 데이터 사일로입니다. 부서별로, 시스템별로 데이터가 고립됩니다. 마케팅은 마케팅 도구에, 영업은 CRM에, 재무는 ERP에 각자의 사본을 들고 있습니다. 시간이 지나면 이 사본들은 서로 다른 속도로 낡아 갑니다.

둘째는 데이터 단편화입니다. 같은 정보가 여러 곳에 흩어지면서 "이 중 무엇이 진짜냐"를 판단할 수 없게 됩니다. 고객의 전화번호가 세 시스템에 세 가지 버전으로 존재하면, 어느 것도 확실히 옳다고 말할 수 없습니다. 복수의 진실이 생긴 것입니다.

셋째는 불신과 잘못된 결정입니다. 이것이 가장 비싼 대가입니다. 숫자가 화면마다 다르다는 것을 팀이 알게 되면, 아무도 중앙 보고서를 믿지 않게 됩니다. 각자 자기가 신뢰하는 데이터로 판단하기 시작하고, 조직 전체의 의사결정이 미묘하게 어긋납니다. 데이터가 틀린 것보다 데이터를 믿지 못하는 것이 더 큰 문제입니다.

SSOT는 이 세 단계를 구조적으로 끊는 장치입니다. 정답의 위치를 하나로 못 박으면, 애초에 복수의 진실이 생길 자리가 없어집니다.

실제로 어디에 두나: "정본의 위치"를 정하는 일

SSOT는 사서 설치하는 제품이 아니라 설계 원칙입니다. 그래서 구현은 언제나 "이 영역에서 정본을 어디에 둘 것인가"를 정하는 형태로 나타납니다. 소프트웨어의 각 층에는 이미 이 원칙의 표준적인 답이 있습니다.

이 표를 관통하는 공통 규칙이 하나 있습니다. 파생본은 얼마든지 둬도 됩니다. 캐시, 읽기 복제본, 조인 뷰, 대시보드 — 이런 것들은 성능과 편의를 위해 필요하고, SSOT 원칙은 이것들을 금지하지 않습니다. "복제와 캐시를 하지 말라"는 흔한 오해도 사실이 아닙니다. 다만 조건이 있습니다. 파생본은 정본에서 만들고, 정본에서 동기화하며, 직접 수정하지 않는다. 복제본의 정합성은 변경 데이터 캡처(CDC) 같은 이벤트 기반 동기화와 최종적 일관성으로 관리합니다.

몇 가지는 조금 더 볼 만합니다. 프론트엔드에서 Redux가 내세우는 세 원칙 중 첫 번째가 문자 그대로 "single source of truth"입니다. 애플리케이션의 전체 상태를 하나의 store에 두고, 화면에 보이는 모든 것은 그 store에서 파생된 값으로 그린다는 것입니다. 컴포넌트마다 자기 상태를 따로 들고 있으면 화면 간 불일치가 생기는데, 그것이 바로 UI 층의 "복수의 진실"입니다.

인프라 쪽의 GitOps는 이 원칙의 가장 선명한 사례입니다. GitOps에서는 인프라의 정본이 Git 저장소이고, 실행 중인 쿠버네티스 클러스터는 그 정본의 파생본일 뿐입니다. Argo CD 같은 도구가 클러스터의 실제 상태를 Git에 선언된 상태와 계속 비교해서, 어긋나면(드리프트) Git 쪽으로 되돌립니다. "실행 중인 시스템이 아니라 Git이 진실이고, 시스템은 Git을 따라와야 한다"는 발상입니다. 이 덕분에 이력·롤백·감사가 공짜로 따라옵니다.

이렇게 보면 SSOT는 운영의 세 층에서 각각 다른 얼굴로 나타납니다. 개발 단계에서는 값을 복사하지 말고 정본을 참조하라는 원칙(코드에서는 DRY, 즉 Don't Repeat Yourself)이 되고, 운영 단계에서는 정본을 버전관리해서 이력과 롤백을 확보하라는 원칙(GitOps)이 되며, 관리 단계에서는 소유자·정의·계보를 붙여 "누가 책임지는 정답인가"를 명확히 하라는 원칙(데이터 거버넌스)이 됩니다.

LLM 시대의 SSOT: 모델은 추론, SSOT는 근거

여기까지는 오래된 이야기입니다. 데이터베이스 정규화도, DRY도 수십 년 된 원칙입니다. 그런데 흥미로운 일이 벌어졌습니다. LLM이 등장하면서 이 낡은 원칙이 오히려 더 중요해졌습니다. 이유를 이해하려면 LLM이 무엇인지부터 정확히 봐야 합니다.

LLM은 진실의 원천이 아니다

LLM은 학습한 지식을 파라미터에 압축해 넣은 추론 엔진입니다. 진실을 저장하는 장치가 아닙니다. 두 가지 한계가 이 점을 분명히 합니다.

하나는 지식 컷오프입니다. 모델은 학습 데이터 바깥의 정보를 모릅니다. 어제 바뀐 사내 정책도, 방금 배포된 API 스펙도 모델의 파라미터에는 없습니다. 다른 하나는 환각(hallucination)입니다. Google Cloud의 문서 표현을 빌리면, 파운데이션 모델은 "그럴듯하지만 사실과 다른 내용을 만들어 내는 경향"을 가집니다. 모델은 모른다고 말하는 대신 자신 있게 지어냅니다.

그래서 등장한 것이 RAG와 grounding입니다. Google Cloud는 이 관계를 명확히 설명합니다. RAG는 "질문에 대한 사실을 먼저 검색하고, 답을 생성하기 전에 그 사실을 모델에 제공하는 것"이며, 바로 이것이 grounding, 즉 근거 부여의 의미라는 것입니다. Vertex AI 문서는 grounding을 "모델의 출력을 검증 가능한 소스에 연결(tether)하여, 내용을 지어낼 가능성을 줄이는 것"으로 정의합니다.

즉 RAG와 grounding이 하는 일은 외부의 지식 베이스를 모델의 source of truth로 삼는 것입니다. 답의 근거를 파라미터에 든 흐릿한 기억이 아니라, 검증 가능한 외부 데이터로 옮기는 것입니다.

RAG의 실제 구조: 사내 위키가 LLM의 SSOT가 된다

AWS의 안내 문서는 RAG의 동작을 네 단계로 정리합니다. 먼저 사내 문서를 임베딩해서 벡터 DB에 적재합니다. 사용자가 자연어로 질문하면, 오케스트레이터가 벡터 DB에서 유사도 검색으로 관련 내용을 꺼내 프롬프트에 붙입니다. 그 질문과 근거를 함께 LLM에 전달하면, LLM은 파라미터 지식이 아니라 그 근거를 바탕으로 답을 만듭니다.

이 구조의 함의가 중요합니다. 사내 위키와 문서를 담은 벡터 스토어가 곧 LLM의 SSOT가 됩니다. 모델은 그때그때 갈아 끼울 수 있지만, 답의 근거가 되는 사실은 그 외부 저장소에 있고, 그 저장소는 검증하고 감사할 수 있습니다.

다만 여기서 정직하게 짚어야 할 한계가 있습니다. RAG와 grounding은 환각을 줄이는 것이지 없애는 것이 아닙니다. IBM의 표현대로 "RAG가 환각의 위험을 줄일 수는 있어도 모델을 오류로부터 자유롭게 만들지는 못합니다." 실제로 근거를 붙인 일부 법률 AI 도구조차 상당한 비율의 환각이 남는다는 보고가 있습니다. 그래서 "LLM 출력을 검증 없이 그대로 정답으로 취급하는 것"은 명백한 안티패턴입니다. grounding은 신뢰할 만한 AI의 필요조건이지 충분조건이 아닙니다.

LLM 애플리케이션의 여러 SSOT 계층

실제 LLM 앱을 뜯어 보면 SSOT는 지식 계층 하나에만 있지 않습니다. 여러 층에 각각의 정본이 있습니다.

프롬프트 계층을 보면 SSOT 발상이 그대로 재현됩니다. LangSmith의 프롬프트 관리는 프롬프트에 커밋 태그를 붙여 두고, 코드에서는 커밋 ID가 아니라 태그를 참조하게 합니다. 그러면 코드를 수정하지 않고도 어느 버전의 프롬프트가 쓰일지를 바꿀 수 있습니다. 프롬프트 업데이트가 앱 배포와 분리되는 것입니다. 프롬프트라는 자산의 정본을 코드 바깥의 버전관리 저장소에 둔 셈입니다.

지표 계층은 앞서 본 "화면마다 숫자가 다른" 문제의 직접적인 해법입니다. dbt의 Semantic Layer는 "지표와 로직을 하나의 거버넌스된 소스에서 정의하고, 모든 리포트·임베디드 앱·AI 워크플로에서 그 정의를 쓰게" 합니다. Databricks의 metric view도 "지표를 한 번 정의하고 런타임에 계산"하는 방식으로, 생성 시점에 집계가 고정돼 드리프트가 생기는 일반 뷰와 대비됩니다. 특히 자연어를 SQL로 바꾸는 text-to-SQL 에이전트가 이 정의를 근거로 삼기 때문에, AI가 "매출"을 물었을 때 사람이 리포트에서 보는 것과 같은 정의로 답하게 됩니다.

여기서도 과장을 하나 걷어내야 합니다. "지표를 한 번 정의하면 모든 도구에서 항상 같은 답이 보장된다"는 식의 절대적 주장은 검증에서 반박됐습니다. 일관성은 자동으로 보장되는 것이 아니라, 다운스트림 도구들이 그 정의를 실제로 가져다 쓰도록 통합하는 설계 역량에 달려 있습니다. 정본을 세우는 것과 모두가 그 정본을 참조하게 만드는 것은 다른 일입니다.

연결 계층의 MCP(Model Context Protocol)는 조금 다른 위치에 있습니다. MCP 자체가 SSOT는 아닙니다. MCP는 LLM 애플리케이션을 외부의 권위 있는 소스에 붙이는 표준화된 배관입니다. 스펙의 표현으로는 "LLM 애플리케이션과 외부 데이터 소스·도구를 매끄럽게 통합하는 개방형 프로토콜"입니다. SSOT로 가는 통로이지 SSOT 그 자체는 아니라는 구분이 중요합니다.

거버넌스: 신뢰할 수 있는 AI의 토대

이 모든 계층을 떠받치는 것이 데이터 거버넌스입니다. Databricks의 가이드에 이 관계를 정확히 찌르는 문장이 있습니다.

품질 데이터 없이는 AI가 없고, 데이터 거버넌스 없이는 품질 데이터가 없다.

메타데이터를 중앙에서 관리하는 이점은 데이터의 SSOT를 유지하는 이점과 정확히 같습니다. 중복이 줄고, 무결성이 올라가며, 서로 다른 정의에서 오는 오해가 사라집니다. 이것이 바로 드리프트 안티패턴의 정반대입니다. 정의가 하나로 관리되면 지표가 조용히 어긋날 자리가 없어집니다. (다만 "거버넌스가 AI 성능을 개선한다"는 식의 서술은 이런 기능을 파는 벤더의 공식 입장이라는 점을 감안해서 읽는 편이 좋습니다.)

이 절 전체를 한 문장으로 줄이면 이렇습니다. LLM 시대의 SSOT는 "모델이 답을 길어 올릴, 외부의 권위 있는 사실 근거"입니다. 모델은 바뀌고 환각하지만 정본은 검증하고 감사할 수 있습니다. 모델은 추론을 맡고, SSOT는 근거를 맡습니다.

헷갈리는 용어와 안티패턴 정리

SSOT 주변에는 비슷해 보이는 용어가 몇 개 있어서 정리해 둘 필요가 있습니다.

SPOT(Single Point of Truth)는 SSOT와 같은 뜻의 동의어입니다. SVoT(Single Version of Truth)는 구별해야 합니다. SVoT는 조직 전체의 데이터를 일관되고 비중복적으로 담는 데이터 웨어하우징의 이상을 가리키는데, SSOT가 "각 데이터의 저장 원칙"이라면 SVoT는 "전체의 일관성"에 가깝습니다. DRY(Don't Repeat Yourself)는 SSOT의 코드·지식 판본입니다. 『실용주의 프로그래머』의 정의로는 "모든 지식은 시스템 안에서 단 하나의 권위 있는 표현을 가져야 한다"는 것으로, 값을 복사하지 말고 참조하라는 발상이 SSOT와 정확히 겹칩니다.

한 가지 주의할 것은 SSOD(Single Source of Data)라는 표현입니다. 겨냥해서 조사해도 권위 있는 정의를 찾을 수 없는, 표준 용어가 아닙니다. 이 말을 마주치면 SSOT의 오기이거나 SVoT를 염두에 둔 것으로 이해하는 편이 낫습니다.

안티패턴은 앞에서 나온 것들을 모으면 세 가지입니다. 첫째, "SSOT는 모든 데이터를 한 DB에 몰아넣는 것"이라는 오해 — 아닙니다. 논리적 단일 권위이지 물리적 단일 저장소가 아닙니다. 둘째, "복제와 캐시는 금지"라는 오해 — 아닙니다. 읽기 전용 파생본은 정상이고, 동기화 규칙만 지키면 됩니다. 셋째, "LLM 출력을 그대로 정답으로" — 환각 때문에 위험합니다.

도입 체크리스트

좋은 SSOT가 갖춰야 할 조건을 정리하면 이렇습니다. 권위 있는 유일 원본이 있을 것, 쓰기 경로가 하나로 일원화될 것, 값을 복사하는 대신 참조할 것, 소유자와 거버넌스가 명확할 것, 파생본의 동기화 규칙이 있을 것, 그리고 버전과 감사가 가능할 것(GitOps처럼).

실제로 도입하는 순서는 단순합니다. 먼저 정본 후보를 식별하고, 그중 하나를 정본으로 선정합니다(나머지는 전부 파생본이 됩니다). 쓰기 경로를 그 정본으로 일원화하고, 파생본은 정본에서 재생성하거나 동기화하게 만듭니다. 마지막으로 소유자를 지정하고 "복사하지 말고 링크하라"는 문화를 정착시킵니다.

마무리

SSOT는 화려한 기술이 아닙니다. 데이터베이스 정규화만큼이나 오래되고 지루한 원칙입니다. 그런데 이 원칙이 다루는 문제 — 무엇을 진실로 믿을 것인가 — 는 조금도 낡지 않았습니다. 오히려 시스템이 복잡해지고 데이터가 여러 곳으로 흩어질수록 더 날카로워집니다.

LLM 시대에 이 점이 특히 분명해집니다. 모델은 강력하지만 그 자체를 진실로 믿을 수는 없습니다. 모델이 잘하는 것은 추론이지 사실의 보관이 아니기 때문입니다. 그래서 우리는 모델 바깥에 검증 가능한 정본을 세우고, 모델이 그 근거를 길어 올려 답하게 만듭니다. RAG도, 버전관리되는 프롬프트도, semantic layer도, MCP도, golden dataset도 결국 같은 일을 합니다. LLM에게 믿을 만한 SSOT를 붙여 주는 것입니다.

무결성, 신뢰성, 일관성. SSOT가 지키려는 이 세 가지는 데이터가 사람을 위한 것이든 모델을 위한 것이든 변하지 않습니다. 모델은 추론하고, SSOT는 근거가 됩니다.

참고문헌

이 글은 세 차례의 교차검증 리서치를 바탕으로 하며, 주요 1차 소스는 다음과 같습니다.

• IBM — System of record vs source of truth: https://www.ibm.com/think/topics/system-of-record-vs-source-of-truth
• Wikipedia — Single source of truth: https://en.wikipedia.org/wiki/Single_source_of_truth
• IBM — Data silos / Data fragmentation: https://www.ibm.com/think/topics/data-silos
• Redux — Three Principles: https://redux.js.org/understanding/thinking-in-redux/three-principles
• GitLab — What is GitOps?: https://about.gitlab.com/topics/gitops/
• Argo CD 공식 문서: https://argo-cd.readthedocs.io/en/stable/
• The Pragmatic Programmer — DRY: https://media.pragprog.com/titles/tpp20/dry.pdf
• IBM — Data governance: https://www.ibm.com/think/topics/data-governance
• Google Cloud — RAG and grounding on Vertex AI: https://cloud.google.com/blog/products/ai-machine-learning/rag-and-grounding-on-vertex-ai
• Google Cloud Vertex AI — Grounding overview: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/grounding/overview
• IBM — Retrieval-augmented generation (RAG): https://www.ibm.com/think/topics/retrieval-augmented-generation
• AWS Prescriptive Guidance — What is RAG: https://docs.aws.amazon.com/prescriptive-guidance/latest/retrieval-augmented-generation-options/what-is-rag.html
• LangSmith — Manage prompts: https://docs.langchain.com/langsmith/manage-prompts
• dbt — Semantic Layer: https://www.getdbt.com/product/semantic-layer
• Databricks — Unity Catalog metric views: https://docs.databricks.com/aws/en/business-semantics/metric-views/
• Model Context Protocol — Spec (2025-11-25): https://modelcontextprotocol.io/specification/2025-11-25
• DeepEval — Evaluation datasets: https://deepeval.com/docs/evaluation-datasets
• Databricks — Data governance best practices: https://docs.databricks.com/gcp/en/lakehouse-architecture/data-governance/best-practices

LLM 파트의 소스 다수는 해당 기능을 제공하는 벤더의 1차 문서입니다. 기능의 정의와 메커니즘은 정확하지만, "보장한다"류의 규범적 서술은 해당 벤더의 설계 목표이자 공식 입장으로 이해하는 것이 안전합니다. RAG는 grounding의 한 기법이며(검색을 쓰지 않는 grounding도 있습니다), MCP 스펙을 비롯한 여러 기능이 2025~2026년의 신기능이라 빠르게 진화하고 있습니다.