SSOT라는 말 자체는 오래됐습니다. 데이터 웨어하우스도, 사내 위키도 스스로를 SSOT라고 불렀습니다. 그런데 어느 것도 진실이 되지 못했습니다. 왜일까요. 조건을 못 채웠기 때문입니다.
조건 1. 진실의 기준이 있어야 한다
문서 열 개가 서로 다른 말을 하면, 무엇이 맞는지 정하는 기준이 필요합니다. 저희의 답은 배포되어 돌아가는 코드입니다. 문서는 의도를 적고, 코드는 현실을 적습니다. 회사가 실제로 어떻게 동작하는지 아는 것은 코드뿐입니다. 정산이 언제 도는지, 포인트가 언제 사라지는지. 사람의 기억과 코드가 다르면, 맞는 쪽은 언제나 코드입니다.
조건 2. 스스로 갱신되어야 한다
사람이 관리하는 진실은 만든 날부터 낡기 시작합니다. 위키가 실패한 이유입니다. SSOT는 코드에서 기계적으로 뽑아내야 합니다. 그래야 코드가 바뀔 때 진실도 따라 바뀝니다.
조건 3. 모든 서술에 근거가 붙어야 한다
"이 규칙은 어디서 왔는가"에 답 못 하는 문장은 진실이 아니라 주장입니다. SSOT의 모든 문장에는 근거 코드 위치가 붙어야 하고, 근거가 없으면 없다고 적어야 합니다.
코드만으로는 완성되지 않는다. 네 개의 층
코드가 진실의 기준이라고 해서, 코드만 있으면 되는 게 아닙니다. 코드가 답하는 것은 무엇을(what), 어떻게(how)까지입니다. 회사의 진실에는 두 층이 더 있습니다.
- 왜(why)는 기획 문서에 있습니다. 왜 이 규칙을 만들었는지, 어떤 의도로 이 기능이 태어났는지는 코드에 없습니다. 기획 문서에 있습니다. 코드에 대조해 검증한 기획 문서가 코드 위에 얹혀야, "어떻게 동작하나"만이 아니라 "왜 이렇게 만들었나"에도 답할 수 있습니다.
- 결과는 데이터에 있습니다. 그렇게 만든 것이 실제로 어떤 결과를 냈는지는 데이터에 있습니다. 데이터 레이크·웨어하우스를 연결하고 테이블의 의미를 코드로 보증하면, 의도(why)와 구현(what·how)과 결과가 하나의 체계 안에서 이어집니다.
코드 위에 why가, 그 결과로 데이터가. 이 세 층이 하나로 묶여야 진정한 SSOT입니다.
마지막 층. 어디에도 없는 암묵지
그런데 회사의 지식 중에는 코드에도, 문서에도, 데이터에도 없는 것이 있습니다. 왜 이 예외를 뒀는지, 어떤 함정을 조심해야 하는지. 이것은 사람들의 머릿속에만 있는 암묵지입니다. 구성원이 일하면서 확인해준 이 지식이 메모리로 계속 쌓여야, SSOT는 시스템의 기록을 넘어 회사 전체의 진실(컴퍼니 레벨 SSOT)이 됩니다. 코드는 하루면 분석하지만, 이 층은 쓸수록 쌓입니다. 그래서 SSOT는 완성품이 아니라 살아 있는 자산입니다.
기존 도구와 무엇이 다른가
| 진실의 기준 | 갱신 | 근거 | |
|---|---|---|---|
| 사내 위키 | 작성자의 기억 | 사람 손 | 없음 |
| 사내 검색·RAG | 없음 (유사한 조각) | 문서가 낡는 만큼 낡음 | 출처는 있으나 참·거짓 검증 없음 |
| 지식그래프 | 사람이 정의한 관계 | 사람 손 | 구축자에 의존 |
| Enterprise SSOT | 배포된 코드 | 커밋 감지 자동 갱신 | 문장마다 코드 근거 |
이 세 조건을 채우면 처음으로 가능해지는 일이 있습니다. AI가 회사에 관한 질문에 검증된 답을 하는 것. 기획자가 물어도, 개발자가 물어도, AI 에이전트가 물어도 같은 진실이 나옵니다. 소통이 조회로 바뀝니다.