기획서를 AI가 마음대로 고치지 못하게, 바뀌는 부분만 보고 승인하는 기획 방법

혹시 기획서를 전부 워드나 노션으로 쓰고 계신가요? 그럼 그 문서를 AI한테 넘겨보는 건 몇 번이나 미뤄 보셨나요?

기획 오래 하신 분들을 만나면 AI 얘기를 슬쩍 꺼내 보는데, 돌아오는 답이 거의 똑같습니다.

“써 보긴 했지. 근데 스무 장짜리 문서를 통째로 다시 써 왔더라고. 뭐가 바뀌었는지 알 수가 있어야지. 그냥 원본 다시 열었고 직접 수정했어.”

이해가 가긴 갑니다. 기획서 문장 하나하나에는 의도와 사정이 있으니까요. 환불 규정 한 줄에도 클라이언트와 실랑이하며 정한 이유가 들어 있죠.
그래서 새 문서가 아무리 매끈해도, 바뀐 곳을 모르면 전체를 다시 읽는 수밖에 없습니다.

이번 편에서는 순서를 바꿔 봤습니다.
쓰던 기획서를 그대로 살린 채로 옮기고, AI가 바꾸고 싶은 내용은 원본과 구분되는 제안으로만 받았습니다.
뭐가 바뀌는지 한눈에 보이고, 반영할지는 본인이 직접 정합니다.

물론 안 바뀌기만 할 거면 옮길 이유가 없죠.
옮기고 나면 이 기획서는 쓰다 놓친 조건까지 채워져서, 개발자한테든 AI한테든 그대로 넘길 수 있는 문서가 됩니다. 두 가지 다 실제 문서로 확인해 보겠습니다.

이번 편의 핵심 장면은 두 개입니다.
Step 2에서 원본은 그대로인 채 바뀔 곳만 파란 표시로 뜨는 화면을, Step 3에서 원문에 없던 조건이 질문으로 올라오는 화면을 보시게 됩니다.

이번 사례집은 상황별로 총 네 편입니다. 지금 상황에 맞는 편부터 읽으시면 됩니다.

이번 사례에서 옮기는 문서

직접 해 보려고 실제 문서를 하나 가져왔습니다.
예약 서비스 ‘우리동네 예약’의 리뉴얼 기획서인데, 예약 접수부터 노쇼 방지금(예약 때 미리 받는 보증금), 리마인드 알림까지 담긴 네 장짜리 워드 초안이에요.

내부 검토 전 초안이라, 쓰다 보면 놓치기 쉬운 조건도 몇 개 비어 있는 상태입니다.
권한이 없는 직원이 설정을 바꾸려 하면 어떻게 되는지 같은 것들이요.

Step 1. 기획서를 통째로 붙여넣기

매니패스트에 새 프로젝트를 만들고, 워드 기획서 내용을 채팅에 그대로 붙여넣었습니다. 부탁은 딱 하나만 더 추가했습니다.

“아래는 워드로 작성해 온 기존 기획서입니다. 바로 반영하거나 확정하지 말고, 정리한 변경안을 먼저 보여준 뒤 제 확인을 기다려 주세요.”

붙여넣은 원문은 채팅에 그대로 남습니다.
매니는 이 내용을 읽고 PRD와 기능명세서 초안을 정리하는데, 전부 변경안 상태로만 만들어 둡니다.

Step 2. 바뀔 곳이 한눈에 보입니다

PRD 문서를 열면 진행률이 0%입니다. 정리된 내용마다 파란 표시가 붙어 있고, 묶음마다 거절과 승인 버튼이 달려 있어요.

변경안은 다섯 묶음입니다. 훑어보다 마음에 안 드는 묶음만 거절하면 되고, 다 괜찮다 싶으면 하단의 일괄처리로 한 번에 넘길 수도 있어요.
어느 쪽이든 원본은 제가 정하기 전까지 그대로입니다.

덕분에 검토할 게 확 줄었습니다.
제 문장과 그 뒤의 사정은 그대로니까, 스무 장을 처음부터 다시 읽는 대신 파란 표시가 붙은 부분만 읽으면 되거든요.

Step 3. 내 문서의 빈틈이 질문으로 올라옵니다

기능 목록을 열면 기능마다 숫자가 붙어 있습니다.
매니패스트가 기능 하나를 개발에 넘기기 전에 정해둬야 할 항목 아홉 개를 세어 주는 ‘개발 준비 슬롯’인데,
지금은 여섯 칸이 비어 있어요. 전부 원문 기획서에 없던 조건입니다.

비어 있는 칸에는 질문이 걸려 있습니다. 운영 권한 기능을 열어 보니 이렇게 물어보더라고요.

“권한이 없는 사용자가 설정 변경을 시도하면 어떻게 처리할까요?”

원문에는 이 조건 자체가 없었습니다. 문서를 다 읽고 나서, 비어 있는 곳만 골라 묻는 거예요.
AI 추천 답변 적용 버튼이 있긴 한데, 이것도 누르기 전까지는 아무것도 바뀌지 않습니다.

기획서를 개발자에게 넘겨 본 분이라면 이 질문들이 낯익으실 겁니다.
원래는 개발이 시작되고 나서 개발자 입에서 나오던 질문이거든요.
여기서 미리 답해 두면, 그만큼 개발 중에 불려 갈 일이 줄어듭니다.

Step 4. 골라서 승인하기

다섯 묶음 중 개요 하나만 승인해 봤습니다. 진행률이 0%에서 23%로 오르고, 개요에 붙어 있던 파란 표시와 버튼이 사라졌어요.

화면 아래 남은 변경안 개수도 다섯에서 넷으로 줄었습니다.
손대지 않은 네 묶음은 여전히 원문 그대로예요. 급한 부분부터 승인하고 나머지는 나중에 검토해도 됩니다.

Step 5. 누가 언제 손댔는지 기록으로 남습니다

기획서를 오래 지켜 온 분들이 꼭 물어보는 게 있습니다. “그래서 이거 누가 고친 거예요?”

워드로 주고받을 때는 파일 이름 뒤에 v2, v3, 최종을 붙여 가며 답하던 질문이죠. 여기서는 프로젝트 오른쪽의 작업 로그가 대신 답합니다.

Step 4에서 개요를 승인한 건 ‘PRD 개요 섹션을 수정’으로 남았습니다. 매니가 정리한 내용이라 AI 배지가 붙어 있고, 1분 뒤에 버전 3이 자동으로 저장됐어요.

승인 전 문서는 버전 2로 그대로 남아 있습니다. 그래서 승인 버튼을 누르기가 덜 조심스러워져요.

팀원과 같이 볼 때는 코멘트를 씁니다.
Step 3에서 본 운영 권한 기능을 열고 그 자리에 “운영 권한 및 변경 이력 관리는 2차로 인증하는 시스템으로 갑시다.”
라고 남겼더니, 개발을 맡을 팀원이 바로 밑에 답을 달았어요.

결정이 그 기능 옆에 붙어 있으니, 왜 그렇게 정했는지가 문서 안에 같이 남습니다.
메신저에서 오간 얘기를 기획서로 다시 옮겨 적을 일이 없어지는 거예요.

그래서 옮기고 나면 뭐가 달라지나요?

문서 내용은 워드에 있던 그대로입니다. 달라진 건 그 문서가 할 수 있는 일이에요.
내가 지켜온 기획서인 채로, 이대로 개발에 들어가도 되는 문서가 됩니다.

바뀐 곳만 보게 해 준 게 변경안 승인이었고, 빈 조건을 채워 준 게 개발 준비 슬롯의 질문들이었어요.
조건이 채워져 있으니 개발자와의 첫 미팅에서 받을 질문도 그만큼 줄어 있고요.

정리하며

처음의 걱정으로 돌아가 볼게요.
AI한테 기획서를 넘기면 통째로 다시 써 와서, 뭐가 바뀌었는지 못 찾게 되는 것.
이번에 직접 해 보니 그 장면 자체가 나오질 않았습니다.

매니가 한 일을 돌아보면 이렇습니다.
붙여넣은 기획서는 전부 변경안으로만 정리해 뒀고, 원문에 없던 조건 여섯 개는 질문으로 걸어 뒀고,
승인 버튼은 묶음마다 따로 달아 뒀어요. 누가 언제 승인했는지는 작업 로그에 남겼고요.

셋 다 결정을 제 몫으로 남겨 두는 장치예요.
덕분에 끝나고 보니 기획서는 제가 쓴 그대로인데, 개발자나 AI한테 바로 넘겨도 되는 상태까지 와 있었습니다.

승인하지 않은 변경은 문서에 들어오지 않습니다.
이 한 줄을 화면에서 직접 확인하고 나면, 기획서를 AI한테 넘기는 결심이 꽤 가벼워집니다.

오늘 해볼 수 있는 것

1. 지금 쓰고 있는 기획서를 그대로 붙여넣어 보세요. 워드든 노션이든 텍스트면 됩니다.

2. 변경안을 훑어보고, 확실한 묶음 하나만 승인해 보세요.

3. 질문으로 올라온 빈틈 중에 정말 안 정했던 조건이 몇 개인지 세어 보세요.
   

원문은 계속 남아 있으니까, 승인을 두어 번만 해 보고 계속 쓸지 정하셔도 됩니다.