2장. 구조가 먼저다
이 장의 목적
AI 협업에서는 잘 쓴 문장보다 구조화된 입력이 더 중요하다. 이 장은 왜 그런지, 그리고 기획 산출물 안에서 어떤 역할 분리가 필요한지를 다룬다.
이 장을 읽고 나면 “설명을 위한 문서”와 “실행을 위한 문서”가 왜 다르게 써야 하는지, 그리고 프롬프트보다 입력 구조를 먼저 다듬어야 하는 이유를 설명할 수 있다.
1. 왜 좋은 문장만으로는 부족한가
기획 문서는 오랫동안 “잘 쓴 문장”의 영향을 크게 받아왔다. 문제가 명확해 보이고, 의도가 자연스럽고, 배경 설명이 풍부하면 좋은 문서처럼 보이기 쉽다.
하지만 AI 협업에서는 다른 질문이 더 중요해진다.
- 이 문장에서 정책 포인트를 분리할 수 있는가
- 이 문장에서 흐름을 추출할 수 있는가
- 이 문장에서 판단 규칙을 찾을 수 있는가
- 이 문장에서 테스트 기준을 만들 수 있는가
즉, 문장의 품질만이 아니라 구조적 해석 가능성이 중요해진다.
예를 들어 “휴면회원은 본인확인 후 로그인할 수 있다”는 문장은 문장 자체로는 분명해 보인다. 하지만 구조는 아직 약하다. 본인확인 성공 여부는 어떤 기준인가, 실패 시 결과는 무엇인가, 상태 전환은 언제 일어나는가, 로그인 허용 여부 판단은 별도 규칙으로 분리할 것인가가 드러나지 않는다.
좋은 구조는 이런 질문을 열어준다. 즉, 좋은 구조는 ‘문장이 그럴듯한 상태’가 아니라 정책, 흐름, 판단, 검증으로 내려갈 준비가 된 상태다.
2. 설명·합의 문서와 실행용 입력물의 역할 분리
구조가 왜 먼저인지 이해하려면, 기획 문서의 역할이 무엇으로 바뀌고 있는지를 같이 봐야 한다.
2-1. 설명·합의 중심 문서의 특징과 한계
기획 산출물은 예전에도 실행에 쓰였다. 다만 많은 조직에서는 설명, 합의, 승인, 실행 준비가 한 문서 안에 함께 들어 있었고, 그 과정에서 문서의 서술 방식은 사람 중심으로 짜이는 경우가 많았다.
사람 중심으로 읽히는 문서에는 공통된 특징이 있다. 맥락 설명이 길고, 설득 구조로 짜이며, 결론이 여러 구역에 분산되어 있고, 형식이 강조된다. 이런 특징은 사람 중심 검토에는 자연스럽지만, AI가 읽어 다음 산출물로 변환해야 하는 상황에서는 약점이 된다.
AI는 분산된 결론을 취합하지 못하고, 설득 구조에서 실제 명세를 안정적으로 추출하지 못한다. 설명과 합의에 최적화된 긴 문서를 그대로 입력하면 그 분위기를 흉내 낸 초안을 돌려줄 수는 있어도, 실행 가능한 결과물을 만들지는 못한다.
2-2. 실행용 입력물의 조건
실행용 입력물은 AI가, 또는 실행 팀이, 이것을 읽고 실제로 무언가를 만들 수 있도록 설계된 명세다. 핵심 조건은 세 가지다.
범위가 고정되어 있다. 무엇이 이번 범위이고 무엇이 아닌지가 문서 안에서 분명해야 한다.
정책이 분리되어 있다. 기능 설명과 운영 규칙, 예외 처리, 판단 기준이 한 문장 안에 뒤섞이지 않아야 한다.
완료 기준이 포함된다. 무엇이 구현 완료이고 무엇이 검증 완료인지 명시되어야 한다.
2-3. 두 유형의 비교
| 항목 | 설명·합의 중심 문서 | 실행용 입력물 |
|---|---|---|
| 주된 독자 | 의사결정자, 검토자, 이해관계자 | AI, 개발자, 실행 팀 |
| 문서의 목적 | 합의·승인 획득 | 실행 지시와 범위 고정 |
| 분량 구조 | 긴 서술, 배경 설명 포함 | 간결한 명세, 배경 최소화 |
| 결론 위치 | 분산 | 집중 |
| 범위 기술 | 포괄적·개략적 | 구체적·경계 명시 |
| 정책 위치 | 기능 설명에 혼재 | 별도 분리 |
| 완료 기준 | 없거나 암묵적 | 명시적 포함 |
“실행용 입력물을 강화한다”는 말은 설명과 합의를 위한 문서를 없앤다는 뜻이 아니다. 의사결정을 위한 문서는 의사결정을 위한 형식으로, 실행을 위한 문서는 실행을 위한 형식으로 나뉜다. 달라지는 것은 문서의 수가 아니라 역할의 분리다.
2-4. 어떤 산출물이 어떻게 달라지는가
PRD는 배경과 맥락 설명만으로 끝나는 문서가 아니라, 범위·정책·완료 기준이 구조화된 문서가 되어야 한다. 정책서는 기능 설명 안에 섞여 있던 규칙을 분리한다. 사양서는 UI 설명을 넘어서 입력값, 상태, 예외를 구현 가능한 수준으로 남긴다.
핵심은 문서가 사라지는 것이 아니라, 역할이 분리되고 연결 방식이 달라진다는 점이다.
3. 프롬프트보다 입력 구조가 중요한 이유
많은 팀이 AI 활용에서 먼저 프롬프트를 개선하려 한다. 물론 프롬프트는 중요하다. 하지만 입력 구조가 약하면 프롬프트를 아무리 정교하게 바꿔도 한계가 있다.
입력 구조가 약한 상태에서는 범위와 예외가 빠지고, 같은 용어가 다르게 쓰이고, 기준 문서가 연결되지 않고, 뒤 문서가 해석에 의존한다. 반대로 입력 구조가 좋으면 AI는 비교적 단순한 프롬프트로도 더 안정적인 결과를 낸다.
AI가 읽기 쉬운 문서는 문장이 짧은 문서만을 뜻하지 않는다. 범위가 분리돼 있는가, 핵심 시나리오가 보이는가, 정책 포인트가 분리돼 있는가, 판단 포인트가 드러나는가, 예외가 별도 항목으로 정리돼 있는가, 뒤 단계 문서 후보가 식별되는가가 더 중요하다.
그래서 이 책은 프롬프트보다 먼저 문서 구조와 입력 체계를 다룬다.
4. 기준 문서와 실행 문서
구조가 중요하다는 점이 분명해졌다면, 다음 질문이 따라온다. 그 구조는 무엇 위에 세워지는가.
이 책은 산출물을 먼저 두 종류로 나눈다.
- 기준 문서: 여러 프로젝트가 공통으로 참조하며 쉽게 흔들리면 안 되는 문서
- 실행 문서: 특정 프로젝트·기능·개선 과제 단위로 생성·수정되는 문서
이 구분을 여기서 먼저 세우는 이유가 있다. 앞서 설명한 “실행용 입력물”이 제대로 작동하려면, 그 문서가 무엇을 기준으로 쓰였는지가 분명해야 하기 때문이다. 실행 문서의 품질은 결국 기준 문서의 안정성과 연결 품질에 종속된다. 기준 문서가 흔들리면 그것을 참조한 모든 실행 문서도 흔들린다.
여기서 “실행 문서”는 기준 문서와 대비되는 포괄적 개념으로 사용한다. 3장에서는 이 실행 문서를 입력, 실행, 연결·운영 세 영역으로 더 세밀하게 나눈다.
5. 가상 적용 예시. 쇼핑몰 플랫폼을 “앱 만들어줘”로 시작하면 왜 흔들리는가
누군가 AI 코딩 도구 앞에 앉아 이렇게 말한다.
“쇼핑몰 플랫폼 만들어줘. 회원가입, 상품관리, 주문, 결제, 관리자 기능까지 넣어줘.”
겉으로 보면 충분해 보인다. 해야 할 기능도 들어 있고, 방향도 얼핏 보인다. 하지만 이 문장은 아이디어일 수는 있어도 구현 기준은 되기 어렵다.
이 요청만으로는 아직 아무것도 고정되지 않았다. 자사몰인지 입점형 마켓플레이스인지, 관리자 기능이 운영자용인지 판매자용인지, 회원가입이 이메일 기반인지 휴대폰 인증인지, 주문은 결제 완료 후 생성되는지 등 핵심 조건이 비어 있다.
사람끼리 일할 때는 이런 빈칸을 회의와 질문으로 조금씩 메울 수 있다. 하지만 AI는 그 빈칸을 대개 질문보다 추측으로 채운다. 결과는 빠르게 나오지만, 그 속도만큼 쉽게 빗나간다.
그래서 필요한 것이 실행용 입력물이다. 범위를 고정하고, 정책을 분리하고, 흐름과 상태를 설명하고, 구현 가능한 기준으로 바꾸는 문서 체계가 있어야 한다.
결국 “앱 만들어줘”는 출발점일 수는 있어도 기준점은 아니다. 그다음에 필요한 것은 더 긴 프롬프트가 아니라, 무엇을 왜 만들고 어디까지 만들며 어떤 규칙으로 동작할지를 먼저 고정하는 구조다.
6. 이 장의 핵심 메시지
AI 협업에서 중요한 것은 잘 쓴 문장이 아니라 다음 문서와 실행으로 이어질 수 있는 입력 구조다.
기획 산출물의 핵심 변화는 보고용 문서가 사라지는 데 있지 않다. 설명·합의 중심 문서와 실행용 입력물의 역할을 분리하고, 실행 쪽 문서를 더 명확하고 더 구조적으로 써야 한다는 데 있다.
7. 다음 장으로의 연결
이 장에서는 왜 구조가 먼저여야 하는지, 그리고 기획 산출물 안에서 설명·합의 중심 문서와 실행용 입력물의 역할을 왜 분리해야 하는지를 살펴봤다.
이제 다음 질문이 따라온다.
그렇다면 기획 산출물은 전체적으로 어떤 문서들로 이루어지며, 그 문서들은 어떤 역할군으로 나뉘는가?
다음 장에서는 기획 산출물 전체를 기준·입력·실행·연결·운영 네 영역으로 나눠 전체 지형도를 펼쳐 보인다.
다음 장: 3장. 산출물 지형도