4장. 문서 레이어와 책임 분리
이 장의 목적
각 문서가 어디까지 책임져야 하고 어디부터는 다음 문서로 넘겨야 하는지를 다룬다. PRD, 정책서, BPMN, DMN, 사양서, 프로토타입, 테스트케이스가 서로 섞이지 않으려면 각자의 질문 범위가 분명해야 한다. 이 장은 그 경계를 문서별로 정리한다.
1. 왜 문서 레이어와 책임을 분리해야 하는가
많은 조직에서 문서는 쌓이지만, 실제로는 같은 정보를 다른 표현으로 반복하는 경우가 많다. 표면적으로는 여러 문서가 있는 것처럼 보이지만, 자세히 보면 어떤 문서는 방향을 말하고, 어떤 문서는 규칙을 말하고, 어떤 문서는 구현 조건을 말해야 하는데 그 경계가 흐려져 있다.
이 문제가 생기면 다음 현상이 반복된다.
- PRD가 구현 상세까지 포함하려 한다.
- 정책서가 예외 규칙과 운영 메모와 UI 설명을 한 문서에 섞어 담는다.
- BPMN이 흐름을 설명하는 대신 정책 설명 텍스트로 길어진다.
- DMN이 따로 없어 판단 기준이 회의록과 사양서 문장 속에 숨어 있다.
- 프로토타입이 경험 검토용인지 상세 설계 대체물인지 불분명해진다.
- 테스트케이스가 뒤늦게 붙어 추적성이 끊긴다.
문서가 역할을 분담하지 못하면 가장 큰 문제는 같은 질문에 서로 다른 문서가 서로 다른 답을 주기 시작한다는 것이다. AI 시대에는 이 문제가 더 치명적이다. AI는 여러 문서를 동시에 읽을 수 있지만, 그 문서들 사이에서 무엇이 방향이고 무엇이 규칙이며 무엇이 구현 기준인지 스스로 안정적으로 보장하지 못한다.
품질 불일치는 대개 두 곳에서 생긴다.
- 정보 부재: 범위, 정책, 흐름, 판단, 구현 기준, 검증 기준이 애초에 문서화되지 않았다.
- 프로세스 부재: 문서는 있는데 최신성이 유지되지 않고, 승인과 변경 통제가 없다.
이 장은 먼저 정보 부재를 막기 위한 문서 경계를 다룬다. 프로세스와 변경 통제는 6장에서 다룬다.
2. 이 책이 제안하는 문서 레이어
이 책은 문서를 아래와 같이 일곱 개 레이어로 본다.
| 레이어 | 핵심 질문 | 대표 문서 | 산출 목적 |
|---|---|---|---|
| 비즈니스 레이어 | 왜 이 일을 해야 하는가 | BRD, 사업 요구, 문제 정의 문서 | 비즈니스 목적과 범위 정렬 |
| 제품/서비스 레이어 | 무엇을 만들고 어떤 가치를 줄 것인가 | PRD | 사용자 가치, 범위, 우선순위 정의 |
| 정책/판단 레이어 | 어떤 규칙과 조건으로 동작해야 하는가 | 정책서, DMN | 정책, 예외, 분기 규칙 명확화 |
| 흐름 레이어 | 어떤 순서와 상태 변화로 처리되는가 | BPMN, 프로세스 설계서 | 업무/시스템 흐름 구조화 |
| 상세 설계 레이어 | 구현 가능한 수준으로 무엇을 남길 것인가 | 사양서, 기능명세서 | 상태, 조건, 메시지, 인터페이스 정의 |
| 경험 레이어 | 사용자는 무엇을 보고 어떻게 행동하는가 | 프로토타입, 화면 설계 | 경험 검토와 협업 정렬 |
| 검증 레이어 | 요구사항이 실제로 충족됐는가 | 테스트케이스, RTM | 검증, 추적성, 변경관리 |
이 구조의 핵심은 문서를 이름으로 나누는 것이 아니라, 질문과 책임으로 나눈다는 데 있다.
도식: 문서 레이어 7단계 구조
3. BRD와 PRD의 경계
3-1. BRD는 목적을 정렬하는 문서다
BRD는 왜 이 일을 해야 하는지를 설명한다. 여기에는 비즈니스 목표, 범위, 제약, 기대 효과, 상위 배경이 들어간다.
BRD가 답해야 하는 질문은 다음과 같다.
- 왜 지금 이 과제를 해야 하는가
- 기대하는 비즈니스 효과는 무엇인가
- 범위와 제약은 무엇인가
- 이 과제의 우선순위는 왜 높은가
BRD에 과하게 들어가면 안 되는 것은 화면 전환 흐름, 상세 정책 예외, 구현 조건, 테스트 입력값 같은 내용이다.
3-2. PRD는 방향을 정의하는 문서다
PRD는 무엇을 만들 것인가를 정의한다. 여기에는 사용자 문제, 목표, 범위, 핵심 시나리오, 성공 기준, 우선순위가 들어간다.
PRD가 답해야 하는 질문은 다음과 같다.
- 어떤 사용자 문제를 해결하는가
- 어떤 범위를 이번 릴리즈에 포함하는가
- 핵심 시나리오는 무엇인가
- 성공은 무엇으로 판단하는가
반대로 PRD가 구현과 정책, 흐름, 판단까지 모두 떠안기 시작하면 문서는 길어지지만 뒤 레이어를 대체하지는 못한다.
정리하면, BRD는 목적과 범위에서 멈추고, PRD는 방향과 핵심 시나리오에서 멈춰야 한다. 상세 규칙과 구현은 다음 레이어로 넘긴다.
많은 팀이 BRD를 별도 문서로 만들지 않는다. 이 경우에도 원칙은 동일하게 적용된다. PRD 안에 비즈니스 배경과 목적을 담더라도, 그 내용이 상세 기능 명세와 명확히 구분된 섹션으로 분리되어 있어야 한다. BRD가 없는 것 자체가 문제가 아니라, BRD가 다뤄야 할 질문(“왜 지금 이 과제를 해야 하는가”)이 어떤 문서에도 없는 것이 문제다.
4. 정책서, BPMN, DMN의 경계
실무에서 가장 자주 섞이는 부분이 이 세 문서다.
4-1. 정책서는 규칙의 서술형 기준이다
정책서는 조직이나 프로젝트가 따라야 할 규칙, 원칙, 예외를 설명한다. 예를 들어 휴면 전환 기준, 재가입 제한 조건, 로그인 실패 누적 처리 원칙, 본인인증 실패 시 제한 기준 같은 내용이 여기에 들어간다.
정책서는 사람이 읽고 이해할 수 있도록 배경과 예외를 설명할 수 있다. 하지만 흐름이나 구현까지 모두 담으려 하면 과도하게 무거워진다.
4-2. BPMN은 흐름의 언어다
BPMN은 누가, 언제, 어떤 단계와 이벤트를 거쳐 처리하는지를 보여준다. 핵심은 순서와 상태 변화다.
BPMN이 답해야 하는 질문은 다음과 같다.
- 어떤 이벤트가 프로세스를 시작시키는가
- 어떤 역할이 어느 단계에서 개입하는가
- 어떤 순서와 상태 변화로 처리되는가
BPMN 안에 정책 설명 문장을 길게 넣기 시작하면 흐름이 흐려진다.
4-3. DMN은 판단의 언어다
DMN은 특정 조건 조합에서 어떤 판단 결과가 나오는지를 구조화한다. 핵심은 분기와 판정 기준이다.
DMN이 답해야 하는 질문은 다음과 같다.
- 어떤 조건 조합에서 허용/차단/예외가 결정되는가
- 분기 기준은 무엇인가
- 동일한 판단을 반복 적용할 수 있는가
4-4. 셋을 섞으면 왜 위험한가
정책서는 규칙을 설명하고, BPMN은 흐름을 설명하고, DMN은 판단을 설명한다. 셋을 한 문서에 섞으면 규칙은 길어지고, 흐름은 불명확해지고, 판단은 사람의 해석에 남는다.
정리하면 다음과 같다.
- 정책서는 “무슨 원칙인가”
- BPMN은 “어떤 순서인가”
- DMN은 “어떤 조건에서 무엇을 결정하는가”
5. 사양서는 무엇을 남기는 문서인가
사양서는 구현 가능한 수준으로 무엇을 남길 것인가를 다룬다. 상태값, 입력 조건, 오류 메시지, 인터페이스, API 응답, 예외 처리 조건처럼 개발과 QA가 직접 참조할 수 있는 상세 기준이 여기에 들어간다.
사양서가 답해야 하는 질문은 다음과 같다.
- 어떤 필드와 상태값을 저장하는가
- 어떤 입력과 출력이 오가는가
- 어떤 메시지를 어떤 조건에서 보여주는가
- 어떤 오류 코드와 예외 처리를 적용하는가
반대로 사양서에 비즈니스 목적이나 제품 전략의 장황한 설명이 반복되면 경계가 무너진다. 사양서는 구현을 위한 상세 조건 문서여야 한다.
6. 프로토타입은 무엇을 대신할 수 없나
프로토타입은 매우 강력한 협업 도구다. 특히 AI 시대에는 화면 초안과 인터랙션 아이디어를 빠르게 시각화하는 데 큰 도움을 준다.
프로토타입은 사용자 경험 흐름을 보여주고, 화면 구조와 주요 인터랙션을 빠르게 검토하게 해주며, 텍스트만으로는 모호했던 경험 요소를 이해관계자 간에 정렬하는 데 탁월하다. AI 시대에는 화면 초안을 빠르게 생성할 수 있어 이 장점이 더 강해졌다.
하지만 프로토타입이 대신하기 어려운 것도 분명하다. 정책 규칙 전체를 설명하거나, 복잡한 예외 조건을 구조화하거나, 시스템 상태 모델과 판단 기준을 명시하거나, 검증 가능한 테스트 조건을 완전히 담는 것은 프로토타입의 역할이 아니다.
프로토타입은 경험 레이어의 문서다. AI가 프로토타입을 빠르게 만들수록 “이게 있으면 됐다”는 착각도 빠르게 퍼진다. 프로토타입 하나로 정책서, DMN, 사양서까지 대체하려 하면 보이지 않는 빈틈이 더 빨리 쌓인다.
7. 테스트케이스는 왜 마지막 문서가 아닌가
많은 팀이 테스트케이스를 개발 이후 문서라고 생각한다. 하지만 이 책에서는 테스트케이스를 검증 레이어의 핵심 문서로 본다.
테스트케이스가 답해야 하는 질문은 명확하다.
- 어떤 입력과 전제가 있을 때
- 어떤 결과가 나와야 하는가
- 무엇을 성공으로 볼 것인가
- 어떤 예외 상황을 검증해야 하는가
이 질문은 개발 이후가 아니라 요구사항 설계 단계에서부터 존재한다. 테스트케이스는 구현 완료 후 붙는 부가 문서가 아니라, 요구사항·정책·흐름·판단 기준이 실제로 검증 가능한지를 확인하는 문서다.
테스트케이스를 늦게 만들면 다음 문제가 생긴다.
- 요구사항이 검증 불가능한 상태로 통과된다.
- 예외 규칙이 빠져도 뒤늦게 발견된다.
- 정책 변경이 테스트에 반영되지 않는다.
- PRD와 QA가 서로 다른 전제를 갖게 된다.
그래서 테스트케이스는 가능한 한 앞단에서 설계되어야 한다.
8. 실무에서 경계를 유지하는 원칙
8-1. 한 문서에 한 질문군을 우선 배정한다
문서마다 “이 문서는 주로 어떤 질문에 답하는가”를 먼저 정한다. 그 질문과 직접 관계없는 내용은 가능한 한 다른 레이어로 넘긴다.
8-2. 중복 서술보다 참조 구조를 택한다
같은 정책 문장을 PRD, BPMN, 사양서에 모두 복사하지 않는다. 기준 문서는 기준 문서대로 유지하고, 다른 문서는 그것을 참조하도록 설계한다.
8-3. BPMN과 DMN은 텍스트 설명을 대체하는 장식이 아니다
둘은 시각적 장식이 아니라 흐름과 판단을 분리하는 구조화 도구다. 도식이 있다는 사실보다, 무엇을 어디에 분리했는지가 더 중요하다.
8-4. 프로토타입은 결정 근거가 아니라 표현 결과다
프로토타입은 경험을 보여주지만, 정책과 판단 기준의 최종 근거가 되어서는 안 된다.
8-5. 테스트케이스를 뒤로 미루지 않는다
검증 문서를 앞당겨야 앞단 문서의 경계도 함께 선명해진다.
9. 레이어 경계 자가 진단 체크리스트
| 항목 | 확인 기준 |
|---|---|
| PRD 과부하 | PRD에 구현 상세가 섞여 있지 않은가 |
| 정책·흐름 혼재 | BPMN 안에 정책 설명 텍스트가 길게 들어가 있지 않은가 |
| 판단 기준 누락 | 조건 분기가 있는데 DMN 없이 텍스트 설명만 있지 않은가 |
| 사양서 부재 | 구현 기준을 개발자가 암묵적으로 보완하고 있지 않은가 |
| 프로토타입 과의존 | 프로토타입이 정책서·DMN·사양서를 사실상 대체하고 있지 않은가 |
| 테스트케이스 후치 | 테스트케이스가 개발 완료 후에만 작성되고 있지 않은가 |
| 중복 서술 | 같은 정책 문장이 여러 문서에 복사돼 있지 않은가 |
이 체크리스트는 어느 레이어가 가장 먼저 정리되어야 하는지 우선순위를 잡는 데 사용한다.
10. 이 장의 핵심 메시지
문서는 많이 만드는 것이 아니라, 서로 다른 질문을 서로 다른 책임으로 분리해 두는 것이 중요하다.
BRD는 목적을, PRD는 방향을, 정책서는 규칙을, BPMN과 DMN은 흐름과 판단을, 사양서는 구현 조건을, 프로토타입은 경험을, 테스트케이스는 검증을 맡아야 한다.
문서가 분리되어야 산출물 체인도 제대로 이어진다. 이 구조가 서야 문서는 서로를 보완한다. 이 구조가 무너지면 문서는 서로를 방해한다.
11. 다음 장으로의 연결
이 장에서는 각 문서가 어떤 질문에 답해야 하는지, 그리고 어디까지 책임져야 하는지를 정리했다.
이제 다음 질문이 남는다.
이 문서들을 프로젝트마다 어느 정도 크기의 세트로 가져가야 하는가?
다음 장에서는 프로젝트 규모와 복잡도에 따라 최소 세트와 확장 세트를 어떻게 선택할지 다룬다. 문서 경계를 나눴다면, 그다음에는 실제 과제에서 어디까지 가져가야 하는지를 판단해야 한다.
다음 장: 5장. 최소 세트와 확장 세트