SSOT(Single Source of Truth, 단일 진실 공급원) — 조직의 데이터나 시스템 상태를 오직 하나의 신뢰할 수 있는 원본(Source)에서만 생성하고 수정하도록 관리하는 정보 관리 원칙

요즘 이 용어가 정말 자주 언급됩니다. 왜일까요?

일하는 방식이 바뀌었기 때문입니다.

기획자는 노션에 있는 PRD를 ChatGPT에 붙여 넣고 정책을 다듬고,
디자이너는 메신저를 보고 피그마 화면을 고칩니다.
개발자는 이슈를 Claude Code에 넘겨 계획을 세우게 하고,
코드 수정과 테스트까지 맡긴 뒤 결과만 검토합니다.

각자 쓰는 AI도 다르고, AI에게 건네는 문서도 다릅니다.

이렇게 서로 다른 AI 에이전트들이
같은 기준으로 협업하기 위해서는 뭐가 필요할까요?

위와 같은 팀이 서비스 무료 체험 기간을
14일에서 7일로 줄이기로 했다고 해 볼게요.
기획자는 PRD를 고치고 슬랙에 공지도 올렸습니다.

그런데 2주 뒤 출시된 화면을 보니
랜딩 페이지는 7일인데 결제 화면은 14일,
AI로 자동화한 CS 답변 템플릿도 여전히 14일이었습니다.

누군가가 일을 못해서가 아닙니다.
다들 각자 보던 문서대로 성실하게 일했을 뿐이에요.
무엇을 최종 기준으로 볼지 정해 두지 않으면, 공지를 어디에 올려도 이런 일이 생깁니다.

이걸 막는 원칙이 바로 SSOT입니다.
오늘은 SSOT가 무엇인지, SSOT 없이 일하면 어디서 문제가 생기는지,
그리고 제품 기획 문서에 SSOT를 적용하면 무엇이 달라지는지 정리해 볼게요.

SSOT란 무엇인가요?

처음에 말씀드린 정의를 조금 더 풀어 볼게요.
SSOT는 원래 데이터베이스를 설계할 때 쓰던 말이에요.

예를 들어서, 고객의 전화번호를 회원 테이블,
주문 테이블, 배송 테이블에 각각 저장해 두면
회원 테이블의 전화번호만 바뀌었을 때
나머지 두 곳은 틀린 번호를 들고 있게 됩니다.
그래서 전화번호는 한 곳에만 저장하고, 나머지는 그곳을 따라가게 만들죠.

이 원칙은 시간이 지나면서 코드와 문서 관리로 넓어졌고,
요즘은 AI 코딩 도구가 읽는 기획서를 기준으로 삼자는 흐름까지 이어졌습니다.

분야마다 표현은 조금씩 다르지만, SSOT의 조건은 보통 다섯 가지로 정리됩니다.

1. 원본 지정: 정보는 한 곳에서만 만들고 고치며, 나머지는 그 원본을 참조합니다.

2. 기준의 정의: 무엇을 진짜 기준으로 볼지(승인된 가격표, 배포된 코드 등) 정해 둡니다.

3. 갱신 경로: 원본이 바뀌면 나머지가 어떻게 따라 바뀌는지 정해져 있습니다.

4. 근거와 이력: 누가, 언제, 왜 바꿨는지가 함께 남습니다.

5. 중복 최소화와 역할 분리: 같은 정보를 여러 곳에 따로 저장하지 않고, 백업이나 과거 기록은 원본과 구분해 관리합니다.

이 원칙은 기획 문서에도 똑같이 적용됩니다.
‘무료 체험 기간은 7일'이라는 정보를 아까 예시로 들었죠?
14일에서 7일로 바꿨다고 해서 숫자만 바뀌는 게 절대 아닙니다.

PRD, 디자인 파일(피그마 등), 이슈 트래커, CS 매뉴얼에
각각 14일이라는 숫자가 적혀 있을 텐데
그 말은 즉슨, 이미 14일이라는 데이터에 대해서 원본이 4개인 상태입니다.

디자이너 한 명만 확정된 모든 결정을 제대로 기억하고
랜딩페이지의 표기를 바꿨다 하더라도, 나머지 둘은 그대로 남아요.

여기서 많은 사람들이 자주 하는 오해가 하나 있습니다.

"그럼 모든 문서를 한 곳에 다 모아두거나 네이밍을 잘하면 되는 거 아닌가요?"
"그럼 모든 팀원이 다른 툴 쓰지말고 노션 하나만 쓰면 되는 거 아닌가요?"

결론부터 말씀드리자면, SSOT는 모든 문서를 한 폴더에 모으는 게 아닙니다.
노션 한 곳에 다 모아도 같은 정보가 페이지마다 따로 적혀 있으면,
한 곳에 모였을 뿐 원본은 여전히 여러 개거든요.

문서가 있는 것과 기준이 있는 건 다릅니다.
핵심은 장소가 아니라 "이 정보는 여기가 기준이다"라는 약속이에요.

SSOT 없이 일하면 생기는 일

기준이 없는 팀에서 문서는 생각보다 여러 곳에 흩어져 있습니다.
무료 체험 기간 변경 하나를 들고, 문서가 흩어지는 세 군데를 차례로 따라가 볼게요.

1. 조직 안에서: “최신본이 어떤 거예요?”

PRD는 노션에, 화면은 피그마에, 코드 작업 내용은 깃허브에 있습니다.
도구마다 문서가 따로 있으니, 한 곳을 고치면 나머지는 사람이 기억해서 고쳐야 하죠.
그래서 새로 합류한 사람이 가장 먼저 배우는 건 문서가 아니라 “누구한테 물어보면 되는지”입니다.

2. 회사와 클라이언트 사이에서: “그렇게 말한 적 없는데요?”

조직 안에서 흩어지는 문서가 있다면, 외주 프로젝트에서는 회사와 클라이언트 사이에 흩어집니다.
결정은 회의에서, 메일에서, 카톡에서 바뀌는데 공유한 기획서는 그 자리에 멈춰 있어요.
문서는 3주 전 것이고, 결정은 어제 바뀌었습니다.
이때 근거를 바로 꺼내지 못하면, 일정과 비용을 두고 기억 싸움이 시작됩니다.

3. 사람과 AI 사이에서: “그거 지난주 기획서잖아”

요즘은 AI 코딩 도구에 기획서를 붙여 넣고 작업을 맡기는 팀이 많습니다.
그러다 보니 사람이 보는 문서와 AI에게 주는 프롬프트를 따로 관리하게 되죠.
사람은 회의를 기억하지만, AI는 문서에 적힌 것만 압니다.
지난주에 붙여 넣은 기획서가 대화 안에 남아 있으면, 그게 AI에게는 정답이에요.

그래서 이게 왜 문제가 될까요?

이런 일이 한 번이면 해프닝이지만, 반복되면 팀의 일하는 방식이 됩니다.

첫째, 찾는 데 시간이 듭니다.

Atlassian이 지식 근로자 12,000명과 경영진 200명을 조사한 「2025 State of Teams」에서
리더와 팀은 일하는 시간의 25%를 답을 찾는 데 쓰고 있었습니다.
어느 문서가 최신인지 모르면, 결국 사람에게 물어보는 게 가장 빠른 방법이 되거든요.
물어볼 생각조차 못 하면, 오래된 문서를 보고 있다는 걸 모른 채 일하게 되고요.

둘째, AI를 쓸수록 더 커집니다.

2026년 하반기 AX 트렌드 리포트(응답 2,078명)에서 대기업이 꼽은 AI 도입 장애물 2위는
'데이터 분산'(39%)이었습니다.
출처: 조코딩AX파트너스의 「2026년 하반기 AX 트렌드 리포트」 · 조사 결과 보도

사람은 이상하다 싶으면 한 번 더 물어보지만, AI는 받은 문서를 그대로 믿고 빠르게 만듭니다.
기준이 흩어진 채로 속도만 빨라지면, 틀린 결과물도 그만큼 빨리 쌓입니다.

반대로 SSOT가 있다면 어떻게 일할까?

같은 무료 체험 기간 변경 안건을,
이번에는 SSOT가 있는 팀에선 어떻게 일하는지 설명드릴게요.

잠깐! 그 전에 하나만 짚고 갈게요.
버전 관리라고 하면 보통 파일명부터 떠올리죠.
‘결제정책_v1’, ’결제정책_v2’처럼요.
솔직히 상식적으로 v2가 최신이겠죠.

그런데 v2가 팀이 합의한 버전인지는 별개의 문제예요.

그래서 기준 문서를 정하는 것과 함께,
어떤 상태를 확정본으로 볼지도 정해야 합니다.
회의에서 바뀐 결정은 문서에 반영하고,
개발에 전달하거나 클라이언트가 확인한 버전은 따로 남기는 식이죠.

그럼 이 팀은 실제로 어떻게 일할까요?
같은 회의, 같은 결정에서 출발해 순서대로 따라가 볼게요.

이 팀은 미리 약속을 하나 해 둡니다.
“요금이나 체험 기간 같은 정책은 기능명세서의 ‘결제 정책’ 항목에서만 정한다.”

다른 문서에는 숫자를 옮겨 적지 않고 이 항목의 링크를 걸고,
이 항목을 고치는 사람은 기획자 한 명으로 정해 뒀어요.

회의가 끝난 직후, 기획자

기획자는 슬랙보다 기능명세서를 먼저 엽니다.
‘결제 정책’ 항목의 14일을 7일로 고치고, 그 아래에 한 줄을 덧붙여요.

“10월 2일 회의, 체험 기간 14일 → 7일. 결제 전환 테스트 결과를 보고 결정.”

그다음에야 슬랙이든 사내 메신저에 노티를 걸고 공지를 올립니다.

“결제 정책이 바뀌었어요. 확인은 여기서: (기능명세서 링크) 하시면 됩니다.”

공지에 숫자를 직접 적지 않으니, 슬랙 공지가 또 하나의 원본이 되지 않습니다.

공지를 본 디자이너

링크를 눌러 7일을 확인합니다.
피그마에는 체험 기간 숫자가 들어간 화면마다 ’기준: 결제 정책’이라는 메모가 달려 있어요.
이 메모로 찾아보면 랜딩 페이지와 결제 화면이 함께 나옵니다.
처음 예시의 팀은 랜딩 페이지만 고쳤지만, 이 팀은 두 화면을 모두 고칩니다.

개발자

깃허브 이슈에도 숫자 대신 같은 링크가 걸려 있습니다.
코드에서 체험 기간은 설정값 한 곳에서만 읽도록 만들어 뒀기 때문에,
그 한 줄만 고치면 결제 화면 문구와 실제 결제 로직이 함께 바뀝니다.

고객센터 AI와 AI 코딩 도구

고객센터 AI에는 답변 템플릿을 복사해 넣지 않고, ‘결제 정책’ 항목을 읽도록 연결해 뒀습니다.
그래서 기획자가 항목을 고친 다음부터 AI도 “무료 체험은 7일입니다”라고 답해요.
개발자가 쓰는 AI 코딩 도구도 지난주 대화가 아니라 같은 문서를 기준으로 코드를 고칩니다.

2주 뒤

누군가 “7일로 하자고 한 적 없는데요?”라고 물어도,
기획자는 메일함을 뒤지지 않고 변경 기록 한 줄을 보여 줍니다.
새로 합류한 팀원이 “최신본이 어떤 거예요?”라고 물으면, 답은 링크 하나로 끝나고요.

정리하면 이 팀이 지킨 건 세 가지입니다.

1. 하나의 기준: 정보마다 기준이 되는 자리를 하나 정하고, 다른 곳은 숫자 대신 그 자리를 가리켰습니다.

2. 변경이 흘러든다: 결정은 기준 문서에 먼저 쓰고 공지는 그다음에 했고, 바뀐 이유는 문서 안에 한 줄로 남겼습니다.

3. 사람과 AI가 같이 읽는다: AI에게 사본을 붙여 넣지 않고, 사람이 보는 그 문서를 그대로 읽게 했습니다.

1번과 2번은 앞에서 본 원론적인 조건을 실제 업무로 옮긴 것이고,
3번은 AI가 함께 일하면서 새로 중요해진 조건입니다.

SSOT는 데이터, 가격표, 고객 정보처럼 분야마다 모습이 다릅니다.
그중 개발 기획 분야의 SSOT에서 가장 중요한 걸 하나 꼽으라면, 코드와의 동기화입니다.
기획서에는 7일인데 코드에는 14일이 남아 있다면,
그 기획서는 기준이 아니라 지난 기록이 되니까요.

AI로 개발하는 팀들 사이에서도 이 차이를 구분하기 시작했습니다.
작업 하나를 위해 쓰고 끝나는 기획서와,
작업이 끝난 뒤에도 남아 기능이 바뀔 때마다 계속 고쳐 쓰는 기획서죠.
좋은 개발 기획서는 후자입니다.
결정이 바뀌면 함께 바뀌고 코드와도 맞춰지는, 살아 있는 기획서입니다.

우리 팀의 SSOT, 제대로 작동하고 있을까?

지금 진행 중인 기능 하나를 떠올리고 답해 보세요.

1. 이 기능의 최신 기준을 묻는다면, 답이 한 곳으로 정해져 있나요?

2. 어제 회의에서 바뀐 결정이 오늘 기준 문서에 들어가 있나요?

3. AI 코딩 도구가 팀이 합의한 그 문서를 읽고 있나요?

하나라도 “아니요”가 있다면, 문서는 있어도 기준은 아직 여러 개인 상태입니다.

매니패스트로 기획 문서를 SSOT로 운영하기

지금까지 말씀드렸던 방법은 웬만한 문서툴로도 할 수 있습니다.
다만 링크를 걸고, 문서를 먼저 고치고, 기록을 남기는 일을 매번 사람이 기억해야 하죠.
그리고 바쁜 기간에는 이 규칙이 가장 먼저 무너집니다.

매니패스트는 소프트웨어를 만들 때 필요한 결정과 조건을 구조화하는 기획 워크스페이스로,
이 규칙 중 사람이 놓치기 쉬운 부분을 기획 흐름 안에 넣어 두었습니다.

하나의 기준: PRD에서 요구사항, 기능, 상세 명세까지 하나의 계층형 문서로 이어지고,
유저플로우와 와이어프레임도 같은 프로젝트 안에서 이어서 만듭니다.
체험 기간이 어느 항목에 있고, 그 항목과 이어지는 화면이 무엇인지 한 프로젝트 안에서 보여요.

변경이 흘러든다: 회의록을 올리면 AI가 확정, 미정, 기각된 결정을 가려내고,
사용자가 검토한 뒤 확정된 결정을 기획서에 반영할 수 있습니다.

결정마다 회의록 원문이 근거로 붙고, 무엇이 바뀌었는지는 작업 로그에 전후 비교로 남아요.
외주 프로젝트라면 '그렇게 말한 적 없는데요?'라는 말에
회의록 원문을 바로 꺼내 보여 줄 수 있다는 뜻이기도 합니다.

사람과 AI가 같이 읽는다: MCP로 Cursor나 Claude Code 같은 AI 코딩 도구를 연결하면,
AI가 붙여 넣은 사본이 아니라 팀이 합의한 매니패스트의 기획서를 읽고 구현합니다.

팀에서 정한 내용과 그 이유가 한 곳에 남고,
팀과 클라이언트와 AI가 같은 기준을 보게 됩니다.

자주 묻는 질문

Q. 문서툴이고 뭐고 결국 코드가 진짜 기준 아닌가요?

코드에 기능이 어떻게 구현되는지는 가장 정확하게 보여주죠.
예를 들어, 비밀번호 5회 잘못 입력시 계정이 잠긴다와 같은 사실을 알 수 있습니다.

그러나 왜 ‘5번’인지 혹은 보안 점검 때문에 정한건지
고객 문의가 많아서 그런건지는 코드에 남지 않습니다.
그렇기 때문에, 코드와 기획 문서는 서로 맞춰져 있어야 하는 관계입니다.

Q. 작은 팀에도 필요한가요?

세 명이 일해도 PRD, 디자인 파일, 이슈 트래커는 따로 생깁니다.
사람이 적을수록 “말로 하면 되지”가 통하지만,
AI 코딩 도구까지 함께 일하기 시작하면 말로 전한 변경은 AI에게 닿지 않습니다.

Q. AI가 긴 문서를 다 읽을 수 있으면 SSOT는 필요 없지 않나요?

AI가 문서를 많이 읽을 순 있어도,
그 중 어느 것이 기준인지 스스로 정하지는 못합니다.
물론 “이 파일이 가장 최신 버전이야” 라던지
“내가 첨부한 것들 중에 이 파일이 가장 중요한거야”라고 프롬프트에 덧붙일 수는 있죠.

다만 그러려면 알려주는 사람이 어떤 문서든간에
최신본이 무엇인지 전부 다 인지하고 있어야되고
그 파일에 당장 어제 회의에서 바뀐 결정들이 전부 들어가있어야 합니다.
게다가 그 말은 그 대화창 안에서만 존재합니다.

다른 팀원이 쓰는 AI라던지 컨텍스트가 꽉 차서 새로 연 대화창에는
md파일을 붙여넣는다 하더라도 한계가 있습니다.
결국 기준을 정하는 건 AI가 아니라 팀이고,
SSOT는 그 기준을 한 번 정해 두는 방법입니다.

마무리하며

SSOT는 거창한 시스템 이름처럼 들리지만, 결국 한 문장입니다.
“이 정보는 여기가 기준이다.”
그리고 그 기준은 혼자 보는 문서가 아니라,
사람과 AI가 함께 보는 문서여야 합니다.

기능이나 정책에 대해서 다시 묻는 일이 잦다면,
문서가 부족한 게 아니라 기준이 여러 개인 상태일 가능성이 큽니다.

기획 문서의 기준을 한 곳에 두고
팀과 클라이언트와 AI가 같은 문서를 보게 하고 싶다면, 매니패스트에서 시작해 보세요.