SSOT란 무엇인가: 헷갈릴 때 무엇을 믿을지 정하는 법

SSOT는 Single source of truth의 약자다.

쉽게 말하면 이거다.

같은 말이 여러 곳에 다르게 적혀 있을 때, 마지막에 무엇을 믿을지 정해둔 기준.

조직에서는 같은 사실이 여러 곳에 흩어진다.

Slack에는 “그렇게 하자”는 말이 있고, 회의록에는 배경이 있고, Asana에는 할 일이 있고, Google Sheet에는 숫자가 있고, 앱 DB에는 실제 상태가 있고, 핸드북에는 운영 규칙이 있다.

처음에는 괜찮다. 그런데 시간이 지나면 문제가 생긴다.

Slack에서는 A라고 했다.
Sheet에는 B라고 적혀 있다.
상담 스크립트에는 C가 남아 있다.
실제 앱에는 D 상태다.

이때 누군가 묻는다.

그래서 뭐가 맞아요?

이 질문에 바로 답하게 만드는 것이 SSOT다.

제일 쉬운 예시

프로모션 가격이 있다고 해보자.

어느 날 가격이 바뀌었다. 그런데 곳곳에 예전 정보가 남았다.

표면	남아 있는 내용
Slack	팀원이 “이번 달은 39만 원으로 가죠”라고 말함
상담 스크립트	예전 가격 49만 원이 남아 있음
Google Sheet	누군가 44만 원으로 수정해 둠
앱 admin	실제 고객에게 보이는 가격은 39만 원
프로모션 archive	최종 승인된 가격은 39만 원

이때 “Slack에서 봤는데요”, “Sheet에는 다른데요”라고 말하기 시작하면 일이 느려진다.

좋은 운영은 이렇게 닫는다.

현재 고객 안내 기준은 promotion archive다.
archive에는 39만 원으로 되어 있고, 앱 admin에서도 39만 원으로 확인했다.
상담 스크립트의 49만 원은 예전 정보라서 수정해야 한다.
Sheet의 44만 원은 근거가 없으니 정본이 아니다.

이게 SSOT다.

모든 정보를 한곳에 몰아넣는다는 뜻이 아니다. 충돌할 때 무엇이 이기는지 정해두는 것이다.

한 줄 정의

SSOT는 어떤 주제에 대해 지금은 이것이 맞다고 판정하는 기준이다.

더 실무적으로 말하면, 아래 네 가지를 답할 수 있어야 한다.

현재 정본은 어디인가?
방금 확인했는가?
다른 곳과 다르면 무엇이 이기는가?
바꾸려면 어디를 고쳐야 하는가?

이 네 가지를 답하지 못하면 아직 SSOT가 아니다. 그냥 메모, 대화, 참고자료, 초안이다.

단어를 쉽게 풀면

Single source of truth를 그대로 번역하면 “진실의 단일 출처”다. 말이 좀 크다.

실무에서는 이렇게 읽으면 된다.

단어	쉬운 뜻
single	충돌하면 하나만 이긴다
source	어디를 봐야 하는지 정해져 있다
truth	지금 업무에서 맞다고 보기로 한 값이다

여기서 truth는 철학 시간의 진리가 아니다. “현재 업무에서 믿고 움직일 기준”이다.

그래서 SSOT를 한국어로는 정본, 기준 표면, 최종 기준 정도로 부르면 된다.

원천과 정본은 다르다

여기서 하나만 구분하면 된다.

원천은 정보가 처음 생기는 곳이다.

정본은 충돌할 때 최종 기준으로 보기로 한 곳이다.

예를 들면 이렇다.

상황	원천	정본
실제 결제 상태	앱 DB	앱 admin 또는 DB read-back
월마감 숫자	정산 workbook	월마감 확정 Sheet
실행 업무	Asana task	해당 task의 상태와 완료 증거
운영 규칙	회의, Slack, 현장 메모	handbook에 승격된 규칙

작은 일에서는 원천과 정본이 같을 수도 있다. 예를 들어 앱 DB의 특정 row가 실제 상태이자 최종 기준일 수 있다.

하지만 매번 같지는 않다. 그래서 “어디서 처음 생겼는가”와 “무엇을 최종 기준으로 볼 것인가”를 나눠야 한다.

근거를 쉽게 말하면

자료들을 보면 어려운 말이 많이 나온다. 하지만 핵심은 단순하다.

IBM은 system of record와 source of truth를 나눠 설명한다. 쉽게 말하면, 어떤 시스템은 데이터를 처음 만들고 보관하는 역할을 하고, 어떤 시스템은 여러 데이터를 합쳐서 판단 기준을 만드는 역할을 한다는 뜻이다.

Bill Inmon 쪽 데이터웨어하우스 문맥에서는 single version of the truth라는 표현이 나온다. 이것도 쉽게 말하면 “여러 숫자가 싸울 때 마지막으로 믿을 숫자”다.

그래서 이 글에서는 SSOT를 이렇게 쓴다.

SSOT = 원천을 확인하고, 충돌을 끝내고, 고칠 위치를 알려주는 기준

왜 필요할까

SSOT가 없으면 조직은 같은 질문을 계속 반복한다.

이거 최신 맞아요?
누가 하기로 했어요?
가격이 이게 맞아요?
이 숫자는 어디서 나온 거예요?
이 문서 믿어도 돼요?

이 질문 자체가 나쁜 것은 아니다. 문제는 매번 처음부터 다시 확인한다는 점이다.

SSOT가 없으면 이런 일이 생긴다.

깨지는 지점	실제 증상
판단	회의가 “뭐가 맞냐” 확인으로 길어진다
실행	담당자, 마감, 다음 액션이 표면마다 다르다
신뢰	문서와 숫자를 봐도 아무도 바로 믿지 않는다
속도	매번 Slack, Sheet, DB, 회의록을 다시 뒤진다

SSOT는 문서를 예쁘게 정리하려는 말이 아니다.

같은 확인을 반복하지 않게 만드는 운영 장치다.

한 문서에 다 넣으라는 뜻이 아니다

SSOT를 들으면 “그럼 모든 걸 한 문서에 넣으면 되나?”라고 생각하기 쉽다.

아니다.

모든 것을 한 문서에 넣으면 그 문서는 금방 낡는다. 숫자는 Sheet나 DB보다 늦게 바뀌고, 업무 상태는 Asana보다 늦게 바뀌고, 실제 앱 상태는 문서보다 먼저 바뀐다.

좋은 SSOT는 큰 문서 하나가 아니다.

좋은 SSOT는 무엇은 어디가 이기는지 정해둔 지도다.

정보 종류	보통 이기는 곳
누가 언제 무엇을 할지	Asana 또는 issue
실제 시스템 상태	production DB 또는 앱 admin
반복 운영 규칙	handbook
정산 숫자	원본 Sheet 또는 월마감 workbook
논의 배경	Slack thread 또는 회의록

논의 배경도 중요하다. 하지만 배경은 배경이다. 고객에게 안내할 가격, 오늘 처리할 업무, 월마감 숫자는 최종 기준이 따로 있어야 한다.

Slack은 보통 SSOT가 아니다

Slack, 카톡, 회의 STT, 현장 메모는 아주 중요하다.

하지만 보통 SSOT는 아니다.

이유는 간단하다.

1. 중간 말과 최종 결정이 섞여 있다.
2. 누가 언제까지 할지가 빠질 때가 많다.
3. 나중에 보면 지금도 유효한지 알기 어렵다.

그래서 raw 대화는 버리면 안 된다. 대신 정본으로 옮겨야 한다.

Slack 논의
  -> 정리 노트
  -> Asana task 또는 handbook 규칙
  -> 실제 시스템 상태 확인

이 흐름이 없으면 조직은 계속 “분명 어디서 말했는데” 상태에 갇힌다.

실무에서는 이렇게 말하면 된다

좋은 SSOT 답변은 길 필요가 없다.

현재 정본은 <표면/파일/row>다.
<날짜/명령/링크>로 확인했다.
다른 곳에 있는 내용은 참고자료지만 현재 기준은 아니다.
바꾸려면 <어디>를 고쳐야 한다.
고친 뒤 <어디>에 전파한다.

예시는 이렇게 된다.

현재 프로모션 가격 정본은 promotion archive다.
2026-06-22에 앱 admin에서도 같은 가격으로 확인했다.
상담 스크립트의 예전 가격은 참고자료가 아니라 수정 대상이다.
가격이 바뀌면 archive를 먼저 고치고, 상담 스크립트와 Slack 공지에 전파한다.

이 정도면 충분하다.

메디빌더에서 바로 쓰는 기준

앞으로 운영 규칙, 정산 기준, 프로모션 조건, 시스템 상태, 반복 업무 기준을 만들 때는 아래 다섯 줄을 남긴다.

원천 표면:
정본 표면:
최신 확인:
변경 권한자:
전파 위치:

뜻은 이렇다.

항목	쉬운 뜻
원천 표면	정보가 처음 생기는 곳
정본 표면	충돌하면 최종 기준으로 볼 곳
최신 확인	언제, 어떻게 확인했는지
변경 권한자	누가 고칠 수 있는지
전파 위치	고친 뒤 어디까지 바꿔야 하는지

이 다섯 줄이 없으면 그 문서는 아직 정본이 아니다. 초안이다.

나쁜 신호

아래 말이 나오면 SSOT가 아직 안 잡힌 것이다.

• “일단 Slack에 적어뒀어요”
• “Sheet에는 다른데요”
• “캡처는 있는데 원본은 모르겠어요”
• “누가 하기로 했는지는 모르겠어요”
• “문서는 있는데 최신인지는 몰라요”
• “DB에는 다른 값이 있어요”
• “바꾸려면 어디를 고쳐야 하는지 모르겠어요”

이 문제는 문서를 더 많이 만든다고 해결되지 않는다.

무엇이 이기고, 어디를 고치고, 어디에 전파할지 정해야 해결된다.

결론

SSOT는 어려운 데이터 용어처럼 보이지만, 실제로는 단순하다.

헷갈릴 때 무엇을 믿을지 정해두는 것.

이 글에서 중요한 것은 “어딘가에 적었다”가 아니다.

중요한 것은 이 문장까지 말할 수 있는 상태다.

지금은 이게 맞고, 바꾸려면 여기를 고치면 된다.