SSOT(Single Source of Truth) 뜻과 AI 시대에 문서를 한곳에서만 고쳐야 하는 이유

SSOT(Single Source of Truth), 즉 단일 진실 공급원은 하나의 정보를 한곳에서만 고치고 나머지 곳은 전부 그곳을 참조하게 만드는 원칙입니다. 백과사전은 이 말을 모든 데이터 요소를 한곳에서만 고치도록 데이터 구조를 짜는 관례라고 정의합니다. 쉽게 말해 원본은 한 장만 두고, 원본이 필요한 모든 곳에는 복사본 대신 원본의 주소를 적어 두는 방식입니다.

주간 보고에 적힌 전환 수와 광고 대시보드의 전환 수가 다르고, 두 부서가 각자 관리하는 고객 목록의 연락처가 어긋나는 일은 누구나 한 번쯤 겪습니다. 그때마다 어느 쪽이 맞는지 확인하는 회의가 열리는데, 이 문제가 사람의 실수가 아니라 정보를 두는 구조에서 온다는 점은 잘 알려져 있지 않습니다. 같은 정보가 두 곳 이상에 따로 저장되어 있으면 언젠가는 어긋나기 마련입니다.

AI에게 일을 맡기기 시작하면 이 문제가 더 커집니다. 사람은 두 문서가 다르면 최신 것을 찾아보지만, AI는 낡은 사본과 원본을 구분할 근거가 없어 읽은 그대로 따릅니다. 이 글에서는 SSOT가 어디서 나온 말인지, 흔히 쓰는 백업이나 동기화와 무엇이 다른지, 왜 AI 시대에 더 중요해졌는지, 그리고 작은 팀이 실제로 만드는 순서를 정리하겠습니다.

위 화면은 노션 공식 도움말에 실린 동기화 블록(synced block) 예시입니다. 회사 소개 문단 하나가 다른 페이지 두 곳에서도 쓰이고 있는데, 세 곳 가운데 어디서 고치든 나머지가 함께 바뀝니다. 문단을 세 번 복사해 붙여 넣은 것과 겉보기는 같지만 고치는 곳이 하나라는 점이 다르고, 이 글에서 말하는 SSOT가 문서 도구 안에서는 이런 모습으로 나타납니다.

SSOT의 기원과 한 줄 정의

이 말은 데이터베이스 설계에서 나왔습니다. 고객의 주소를 주문 테이블과 배송 테이블과 청구 테이블에 각각 적어 두면 이사 한 번에 세 곳을 고쳐야 하고, 하나라도 놓치면 택배는 옛 주소로 갑니다. 그래서 주소는 고객 테이블 한곳에만 두고 나머지 테이블은 고객 번호로 그 위치를 가리키게 만드는데, 이 정리 방식을 정규화라고 부르고 그 결과로 생기는 상태가 단일 진실 공급원입니다.

같은 원칙이 데이터 창고와 문서와 코드로 차례로 옮겨 갔습니다. 마이크로소프트의 애저 데이터브릭스 문서는 여러 시스템에 데이터 사본을 만들고 맞추는 일을 없애는 것을 SSOT의 뜻으로 설명하면서, 데이터를 복제하면 팀마다 품질과 신선도가 다른 버전을 쓰게 되는 사일로, 즉 서로 통하지 않는 데이터 더미가 생긴다고 적고 있습니다. 구글 클라우드의 데이터 거버넌스 문서는 지표와 용어의 뜻을 한곳에 모은 비즈니스 용어집이 조직 전체의 단일 진실 공급원이 된다고 설명합니다. 데이터베이스에서 시작한 말이 이제는 정의와 규칙까지 가리키는 말이 된 셈입니다.

정리하면 SSOT는 원본을 정하는 일이 아니라 고치는 곳을 하나로 줄이는 일입니다. 원본이 어디인지 모두가 알아도 사본을 따로 고치고 있으면 SSOT가 아니고, 반대로 정보가 여러 화면에 보이더라도 고치는 곳이 하나면 SSOT입니다.

SSOT는 백업이나 동기화와 무엇이 다를까요?

SSOT라는 이름은 백업이나 동기화보다 상대적으로 낯설 수 있습니다. 쉽게 말하면 백업과 동기화는 사본을 여러 개 두고 서로 맞추는 방식이고, SSOT는 사본 대신 원본을 가리키는 참조를 두는 방식입니다. 셋 다 같은 정보를 여러 곳에서 보게 해 준다는 점은 같은데, 고치는 곳이 몇 개인지와 어긋났을 때 무엇이 남는지가 다릅니다. 고객 주소 하나를 네 가지 방식으로 관리한다고 놓고 비교하면 차이가 보입니다.

백업은 SSOT와 충돌하지 않습니다. 원본이 하나이고 백업은 읽기 전용 사본이라는 역할이 분명하기 때문입니다. 문제는 복사와 양방향 동기화입니다. 복사는 고치는 곳을 사본 수만큼 늘리고, 양방향 동기화는 어느 쪽에서 고쳐도 되게 만들어서 두 사람이 같은 항목을 다르게 고쳤을 때 나중 것이 앞 것을 덮습니다. 두 방식 모두 원본이 어디인지가 흐려집니다.

팀에서 진실이 둘이 되는 세 가지 장면

원칙은 단순한데 실제 팀에서는 진실이 두 개가 되는 곳이 늘 비슷합니다. 세 장면으로 나눠 보겠습니다.

첫째는 지표 정의입니다. 광고 대시보드의 전환과 분석 도구의 전환은 이름이 같아도 세는 방법이 다릅니다. 한쪽은 클릭 뒤 며칠 안의 구매를 세고 다른 쪽은 방문 세션 안의 구매만 셉니다. 두 숫자가 보고서 한 장에 나란히 놓이면 어느 쪽이 맞는지 다투게 되는데, 사실은 둘 다 맞고 정의가 다를 뿐입니다. 이때 필요한 것은 전환이라는 말이 이 팀에서 무엇을 뜻하는지 적어 둔 지표 정의서 한 장이고, 보고서는 그 정의를 가져다 써야 합니다.

둘째는 문서 사본입니다. 온보딩 안내 페이지를 부서마다 복제해 조금씩 고쳐 쓰다 보면 반년 뒤에는 서로 다른 안내가 네 개 생기기 쉽습니다. 슬랙에 붙여 넣은 문단, 메일에 첨부한 PDF도 전부 사본입니다. 원본 페이지를 고쳐도 사본은 그대로 남아서, 새로 온 사람은 어느 것이 최신인지 알 길이 없습니다.

셋째는 AI에게 주는 작업 규칙입니다. 프로젝트 규칙을 CLAUDE.md에 적고, 같은 내용을 다른 도구용 파일에 또 적고, 대화창에서 또 한 번 말하는 경우입니다. 세 곳의 내용이 조금씩 달라지면 AI는 그때그때 다른 규칙을 따릅니다. 이 장면은 앞의 둘과 달리 어긋난 결과를 사람이 아니라 AI가 만들어 내기 때문에 눈에 늦게 띕니다.

세 장면의 공통점은 정보가 필요한 곳마다 정보 자체를 갖다 놓았다는 것입니다. 이사할 때마다 명함을 전부 다시 찍는 대신 명함에는 사무실 주소 하나만 적어 두듯, 필요한 곳에는 정보가 아니라 정보가 있는 곳의 주소를 두어야 합니다.

AI 에이전트 시대에 SSOT가 더 중요해진 이유

사람이 읽는 문서라면 사본이 조금 낡아도 읽는 사람이 눈치채고 최신 것을 찾습니다. AI는 그렇지 않습니다. 세션마다 새로 시작해서 읽으라고 준 파일을 그대로 믿고, 낡은 사본과 원본을 구분할 근거가 없습니다.

클로드 코드 공식 문서가 이 점을 직접 말합니다. CLAUDE.md 작성 안내에는 두 규칙이 서로 어긋나면 클로드가 어느 하나를 임의로 고를 수 있으니, 프로젝트 안의 CLAUDE.md 파일과 하위 폴더의 파일과 규칙 폴더를 주기적으로 검토해 낡거나 충돌하는 지시를 지우라고 적혀 있습니다. 규칙이 두 곳에서 다르게 적혀 있을 때 어느 쪽이 원본인지 AI에게는 알 방법이 없다는 뜻입니다.

같은 문서가 SSOT를 만드는 방법도 함께 안내합니다. 위 표처럼 프로젝트 규칙은 저장소 안의 CLAUDE.md 한 파일에 두고 팀원과는 버전 관리로 공유합니다. 다른 코딩 도구가 이미 AGENTS.md 같은 파일을 쓰고 있다면 그 내용을 CLAUDE.md에 복사하는 대신 @AGENTS.md 한 줄로 가져오라고 안내하는데, 공식 문서의 표현을 옮기면 두 도구가 같은 지시를 중복 없이 읽게 하기 위해서입니다. 규칙의 원본은 한 파일이고 나머지는 그 파일을 가리키는 참조라는 점에서 이것이 바로 SSOT입니다. CLAUDE.md 자체를 어떻게 쓰는지는 CLAUDE.md 세팅 정리 글과 클로드 코드 메모리 클래스에 있습니다.

문서 쪽도 마찬가지입니다. 앤트로픽의 AI 네이티브 개발 플레이북이 intent.md와 spec.md를 위키가 아니라 코드와 같은 저장소에 두라고 하는 이유도 같습니다. 코드가 바뀌면 같은 커밋에서 문서도 바뀌어야 다음 단계의 AI가 낡은 문서를 읽지 않습니다. AI에게 맡기는 일이 늘수록 AI가 읽는 문서의 원본이 어디인지가 결과의 품질을 정합니다.

작은 팀에서 SSOT를 만드는 순서

데이터베이스나 전사 플랫폼이 없어도 됩니다. 노션 페이지와 스프레드시트, 마크다운 파일로도 충분하고, 순서는 넷입니다.

1. 진실이 필요한 항목을 고릅니다. 모든 정보를 SSOT로 만들 필요는 없습니다. 여러 사람이 여러 곳에서 되풀이해 쓰는 것만 고릅니다. 지표 정의, 고객과 거래처 목록, 가격표, AI에게 주는 작업 규칙 정도가 대개 여기 들어갑니다.
2. 원본 한곳을 정하고 주소를 붙입니다. 노션이면 페이지 하나, 스프레드시트면 시트 하나, 코드 저장소면 파일 하나입니다. 이 위치에 고정된 URL이나 파일 경로가 있어야 다른 곳에서 가리킬 수 있습니다.
3. 나머지 곳에는 복사 대신 참조를 둡니다. 노션은 동기화 블록이나 링크, 스프레드시트는 다른 시트를 불러오는 함수, CLAUDE.md는 @파일경로 가져오기가 그 참조입니다. 슬랙이나 메일에는 내용을 붙여 넣지 않고 원본 링크를 보냅니다.
4. 고치는 사람과 고친 날짜를 정합니다. 원본을 누가 고치는지와 마지막으로 언제 고쳤는지가 원본 안에 적혀 있어야 합니다. 이것이 없으면 원본 자체가 낡아도 아무도 모릅니다.

지표 정의서를 예로 들면 아래 정도의 표 하나가 원본이 됩니다. 값은 가상입니다.

주간 보고서는 이 표를 다시 적지 않고 링크로 가리킵니다. 전환의 정의가 바뀌면 이 표 한 줄을 고치고, 보고서를 읽는 사람도 AI도 같은 줄을 봅니다.

SSOT를 만들 때 자주 하는 실수

• 도구 하나로 모든 것을 옮기려 합니다. SSOT는 도구가 아니라 원칙입니다. 노션과 스프레드시트와 코드 저장소에 각각 원본이 있어도 항목마다 원본이 하나이고 나머지가 참조라면 SSOT입니다. 반대로 한 도구 안에 같은 표가 두 개 있으면 SSOT가 아닙니다.
• 원본을 정해 두고 사본도 계속 고칩니다. 원본이 어디인지 모두가 아는 것과 원본만 고치는 것은 다릅니다. 사본을 고치는 습관이 남아 있으면 얼마 지나지 않아 사본이 더 최신이 됩니다.
• 참조 대신 복사가 편해서 복사합니다. 링크는 열어야 보이고 복사본은 바로 보이니 복사가 편합니다. 다만 그 편함의 대가는 몇 달 뒤에 어느 것이 맞는지 확인하는 회의로 돌아옵니다.
• 원본 문서를 너무 크게 만듭니다. 모든 것을 한 페이지에 넣으면 아무도 끝까지 읽지 않고 AI도 마찬가지입니다. 클로드 코드 문서도 CLAUDE.md 한 파일을 200줄 아래로 두고, 특정 폴더에서만 필요한 지시는 경로별 규칙 파일로 나누라고 권합니다. 원본은 항목별로 작게, 대신 주소는 분명하게 두는 편이 낫습니다.

SSOT를 만들려면 데이터베이스가 있어야 하나요?

아닙니다. SSOT는 데이터베이스 설계에서 나온 말이지만 원칙은 도구와 무관합니다. 노션 페이지 하나, 스프레드시트 시트 하나, 마크다운 파일 하나도 그 항목을 고치는 유일한 곳이고 다른 곳이 그것을 참조한다면 SSOT입니다. 데이터베이스가 필요해지는 시점은 항목 수와 고치는 사람이 많아져서 권한과 이력을 도구가 관리해 줘야 할 때입니다.

노션 페이지 하나에 다 모아 두면 SSOT인가요?

모아 두는 것만으로는 아닙니다. 같은 내용이 다른 페이지에도 복사되어 있으면 원본을 모아 둔 페이지와 상관없이 진실은 둘입니다. 노션 안에서 SSOT를 만들려면 다른 페이지에는 동기화 블록이나 페이지 링크를 두고 본문을 복사하지 않아야 합니다. 페이지 복제 기능을 쓰는 순간 사본이 생긴다는 점을 팀이 같이 알고 있는 편이 낫습니다.

SSOT와 데이터 거버넌스는 어떻게 다른가요?

데이터 거버넌스는 데이터를 신뢰할 수 있게 만드는 규칙과 역할과 절차 전체를 가리키는 넓은 말이고, SSOT는 그 안에서 원본을 하나로 두는 구조 하나를 가리킵니다. 구글 클라우드 문서가 비즈니스 용어집을 데이터 거버넌스의 기초 단계로 놓고 그것이 정의의 단일 진실 공급원이 된다고 설명하는 것처럼, SSOT는 거버넌스의 결과물 가운데 하나입니다. 작은 팀이라면 거버넌스라는 말을 쓰기 전에 지표 정의서 하나를 SSOT로 만드는 것에서 시작하면 됩니다.

3줄 요약

1. SSOT(Single Source of Truth)는 하나의 정보를 한곳에서만 고치고 나머지 곳은 전부 그곳을 참조하게 만드는 원칙입니다. 원본을 정하는 것이 아니라 고치는 곳을 하나로 줄이는 것이 핵심이고, 데이터베이스 설계에서 나와 문서와 AI 작업 규칙까지 이어졌습니다.
2. 복사와 양방향 동기화는 고치는 곳을 늘려서 언젠가 두 진실을 만듭니다. 사본이 있던 곳에 링크, 가져오기, 동기화 블록 같은 참조를 두면 원본을 한 번 고치는 것으로 모든 곳이 함께 바뀝니다.
3. AI는 낡은 사본과 원본을 구분하지 못하고, 클로드 코드 공식 문서도 규칙이 어긋나면 임의로 고를 수 있다고 밝힙니다. 지표 정의서와 작업 규칙의 원본 한곳을 정하고 주소를 붙이는 것이 AI에게 일을 맡기기 전에 할 일입니다.

Sources

• Microsoft Learn: What does it mean to build a single source of truth? (Azure Databricks)
• Google Cloud 문서: Build foundational data governance
• Claude Code 공식 문서: How Claude remembers your project
• Notion 도움말: Synced blocks