6장. Source of Truth와 버전관리
이 장의 목적
문서가 여러 개인데 무엇이 기준인지 아무도 모르는 상태는 AI 시대에 더 위험하다. AI가 오래된 초안과 최신 승인본을 구분 없이 읽으면 혼선이 빠르게 확산되기 때문이다. 이 장은 정보 종류별 최종 기준 문서를 어떻게 정하고, 변경과 버전을 어떻게 관리하는지를 다룬다.
1. Source of Truth가 없는 조직에서 벌어지는 일
실무에서 더 흔한 문제는 문서가 없는 상태보다, 문서가 여러 개인데 무엇이 최종 기준인지 아무도 확신하지 못하는 상태다.
이 상태에서는 다음이 반복된다.
- 운영팀은 FAQ를 기준으로 답한다.
- 기획팀은 PRD를 기준으로 말한다.
- 개발팀은 코드를 기준으로 말한다.
- QA는 오래된 테스트 문서를 기준으로 본다.
각자 나름의 “정답”이 있지만 팀 전체의 정답은 없는 상태가 된다.
예를 들어 재가입 규칙 하나를 놓고도 PRD, 운영 문서, FAQ, 테스트케이스, 코드가 서로 다른 기준을 가질 수 있다. 문서 수는 충분하지만, 어느 문서가 최종 기준인지 정해져 있지 않기 때문에 충돌이 반복된다.
2. AI 시대에 왜 더 치명적인가
예전에도 이 문제는 있었지만, AI 시대에는 더 치명적이다.
AI는 여러 문서를 동시에 읽는다. 최신 승인본과 오래된 초안을 같은 비중으로 처리하며, 그 사이의 차이를 스스로 인지하고 판단하지 못한다. 예를 들어 재가입 규칙이 두 버전의 문서에 다르게 기술되어 있다면, AI는 어느 쪽이 현행 기준인지 판단하지 못한 채 둘 중 하나 혹은 조합을 그럴듯한 표현으로 초안에 담아낼 수 있다. 사람이 검토하기 전에 이 초안이 다음 문서의 기반으로 쓰이면, 기준 충돌이 아래 레이어로 빠르게 전파된다.
즉, Source of Truth가 약한 상태에서 AI 자동화를 올리면 오류가 자동화된다. AI는 정답을 더 빨리 만드는 것이 아니라, 기준이 섞인 오답을 더 빨리 만들고 더 빨리 퍼뜨릴 가능성도 함께 키운다. 초안 품질이 높아 보일수록 오류를 발견하기도 늦어진다.
3. Source of Truth는 파일 하나가 아니다
Source of Truth를 단일 파일로 오해하면 곤란하다. 실무에서는 정보 종류마다 기준 문서가 달라야 한다.
- 용어 기준: 용어집
- 정책 규칙: 정책서 (판단 기준은 DMN으로 분리)
- 제품 방향과 범위: PRD
- 구현 상세: 사양서
- 검증 기준: 테스트케이스 / RTM
핵심은 문서 수가 아니라 어떤 질문에 대해 어떤 문서가 최종 기준인지 합의되어 있는가다.
Source of Truth는 “문서 하나를 왕으로 두는 것”이 아니라, 정보 유형별 최종 기준을 명시적으로 지정하는 구조다.
4. Source of Truth를 정하는 기본 원칙
4-1. 정보 종류별로 기준을 정한다
문서 이름 기준이 아니라 정보 종류 기준으로 정해야 한다.
4-2. 최종 기준은 한 곳이어야 한다
같은 정보에 대해 두 문서가 동시에 최종 기준일 수는 없다. 참조 문서는 있을 수 있지만, 최종 기준은 하나여야 한다.
4-3. 상위 기준과 하위 기준을 나눈다
전사 공통 정책과 프로젝트 예외 규칙은 같은 수준이 아니다. 상위 기준과 하위 기준을 나누지 않으면 프로젝트 문서가 공통 정책을 암묵적으로 덮어쓰는 문제가 생긴다.
4-4. 변경 책임자를 명확히 한다
문서만 정리해서는 충분하지 않다. 누가 수정할 수 있는지, 누가 승인하는지, 누가 영향 범위를 검토하는지가 함께 정리되어야 한다.
4-5. 참조 경로가 보여야 한다
실행 문서가 어떤 기준 문서를 참조했는지 드러나야 한다. 그래야 나중에 정책 변경 시 영향 범위를 빠르게 추적할 수 있다.
5. 버전관리는 왜 문서 관리가 아니라 운영 원칙인가
버전관리를 파일명에 날짜를 붙이는 정도로 이해하면 부족하다. 이 책에서 말하는 버전관리는 무엇이 최신이고 무엇이 폐기되었는지를 조직적으로 보장하는 방식이다.
버전관리가 필요한 이유는 세 가지다.
첫째, 변경의 맥락을 남기기 위해서다. 무엇이 왜 바뀌었는지 모르면 같은 논쟁을 반복한다.
둘째, 영향 범위를 파악하기 위해서다. 정책 규칙 하나가 바뀌면 BPMN, DMN, 사양서, 테스트케이스, FAQ까지 영향을 받을 수 있다.
셋째, AI 입력 품질을 유지하기 위해서다. 버전이 섞인 문서는 사람보다 AI에게 더 위험하다.
버전관리는 문서 보관이 아니라 변경 통제와 기준 유지의 문제다.
6. 최소 버전관리 원칙
6-1. 문서 상태를 구분한다
| 상태 | 의미 |
|---|---|
| Draft | 작성 중, 검토 전 |
| Review | 검토 중, 미승인 |
| Approved | 승인 완료, 현재 기준 |
| Deprecated / Archived | 폐기 또는 보관 |
이 상태가 없으면 초안과 승인본이 같은 수준으로 취급된다.
6-2. 버전 번호 기준을 둔다
| 버전 | 의미 |
|---|---|
| v0.1 | 초안 |
| v0.9 | 리뷰 반영본 |
| v1.0 | 최초 승인본 |
| v1.1 | 경미 수정 |
| v2.0 | 주요 정책 변경 |
숫자 체계가 절대 중요한 것은 아니지만, 최신성과 변화 수준이 보여야 한다.
6-3. 변경 이유를 남긴다
무엇이 바뀌었는지만으로는 부족하다. 왜 바뀌었는지, 어떤 이슈나 의사결정에 의해 바뀌었는지를 같이 남겨야 한다.
6-4. 승인 주체를 남긴다
특히 기준 문서는 누가 최종 승인했는지가 중요하다. 승인 정보가 없으면 “누가 정한 기준인지”를 확인하기 어렵다.
6-5. 영향 문서를 연결한다
정책서가 바뀌면 어떤 DMN, 사양서, 테스트케이스가 영향을 받는지 연결 고리를 남겨야 한다. 이것이 나중에 RTM과 Decision Log로 이어진다.
7. 실무에서 어떻게 시작하면 되는가
7-1. 자주 충돌하는 정보부터 시작한다
모든 문서를 한 번에 정리하려 하면 시작이 안 된다. 실무에서는 가장 먼저 충돌하는 정보부터 기준을 정한다.
- 용어
- 정책 규칙
- 기능 범위
- 예외 처리
- 운영 문구
7-2. 정보별 기준표를 만든다
| 정보 종류 | 최종 기준 문서 | 승인 주체 | 영향 문서 |
|---|---|---|---|
| 회원 상태 용어 | 용어집 | PO / 도메인 오너 | PRD, 사양서, FAQ |
| 재가입 규칙 | 정책서 (판단 테이블은 DMN으로 분리) | PO + 운영 책임자 | BPMN, 테스트케이스 |
| 오류 메시지 | 사양서 (운영 문구는 운영 가이드로 분리) | PO + CX | 프로토타입, 테스트케이스 |
7-3. 초안과 승인본을 분리한다
Draft와 Approved가 섞여 있으면 Source of Truth가 바로 무너진다.
7-4. 폐기 문서를 명확히 처리한다
오래된 기준을 폐기했으면 보관은 하더라도 현재 기준과 분리해야 한다.
8. AI와 PM/PO의 역할 구분
Source of Truth 구조를 만들고 유지하는 과정에서 AI와 PM의 역할은 명확히 나뉜다.
| 작업 | AI 역할 | PM/PO 책임 |
|---|---|---|
| 기준 문서 후보 탐색 | 문서 목록에서 중복·충돌 항목 탐지 | 실제 기준 문서 최종 확정 |
| 기준표 초안 작성 | 정보 종류별 기준표 초안 생성 | 기준 문서 지정 적절성 검토 |
| 상태/버전 표기 초안 | 상태, 버전, 영향 문서 초안 생성 | 승인 여부와 최종 값 결정 |
| 영향 문서 후보 제시 | 변경 시 영향받을 문서 후보 목록 제시 | 실제 영향 범위 확정 |
| 변경 이력 초안 | changelog, decision log 초안 작성 | 변경 배경과 승인 맥락 기록 |
AI가 단독으로 처리해서는 안 되는 항목은 다음 세 가지다.
- 어떤 문서가 최종 기준인지 확정
- Approved 상태 승인
- 기존 기준 문서의 폐기 결정
이 세 항목은 조직의 의사결정이 반영된 판단이기 때문이다.
9. Source of Truth 운영 체크리스트
| 항목 | 확인 기준 |
|---|---|
| 기준 문서 지정 | 정보 종류별 최종 기준 문서가 명시돼 있는가 |
| 중복 기준 없음 | 같은 정보에 두 개 이상의 기준 문서가 있지 않은가 |
| 상위/하위 구분 | 전사 정책과 프로젝트 예외 규칙이 분리돼 있는가 |
| 변경 책임자 | 각 기준 문서의 수정·승인 주체가 정의돼 있는가 |
| 문서 상태 표시 | Draft / Review / Approved / Deprecated가 명시돼 있는가 |
| 변경 이유 기록 | 무엇이 왜 바뀌었는지가 남는가 |
| 폐기 문서 처리 | 오래된 초안·폐기 문서가 현재 기준과 분리돼 있는가 |
| 영향 문서 연결 | 기준 문서 변경 시 영향받는 하위 문서가 파악되는가 |
이 체크리스트를 처음부터 완벽하게 충족할 필요는 없다. 다만 “기준 문서 지정”과 “문서 상태 표시” 두 항목은 AI 협업을 시작하기 전에 최소한 갖춰야 한다.
10. 이 장의 핵심 메시지
Source of Truth는 문서 하나를 왕으로 두는 것이 아니라, 정보 유형별 최종 기준과 변경 권한을 명시하는 운영 구조다.
모든 문서가 중요할 수는 있지만, 모든 문서가 최종 기준일 수는 없다. Source of Truth와 버전관리 원칙이 없으면 문서는 많아질수록 더 충돌한다.
11. 다음 장으로의 연결
이 장에서는 어떤 문서가 최종 기준인지, 변경과 승인은 어떻게 다루는지를 정리했다.
이제 선택한 문서 세트를 실제 운영 구조 안에서 어떻게 유지할지 봐야 한다.
선택한 문서 세트를 실제 도구 환경과 AI 작업 흐름 안에서 어떻게 운용할 것인가?
다음 장에서는 기준 문서와 실행 문서가 실제 운영 환경에서 어떻게 관리되고 이어지는지, 그리고 한 문서가 어떻게 다음 문서의 입력이 되는 AI 산출물 파이프라인을 다룬다.