월요일 정기 회의가 끝나고 팀장님이 말합니다.
“아까 나온 얘기로 기획서 한번 써 보죠,
다음 주까지 초안 주시면, 개발팀이랑 같이 리뷰 해봅시다.”
자리로 돌아와 빈 문서를 열었다면, 첫 줄에 뭘 적으실 건가요?
빈 화면을 보자마자 기획서를 바로 적기 시작하는 분은 사실상 이제 거의 없을 겁니다.
AI한테 회의 때 적어 둔 메모나 회의록을 붙여넣고, 기획서 초안을 뽑아달라고 하겠죠.
요즘 이렇게 안 하는 사람을 찾는 게 더 어렵습니다.
그리고 AI를 활용해서 기획서 자동 생성을 하는 이 방법이, 실제로 꽤나 잘 통합니다.
뭐부터 써야 되냐 하던 막막함이 몇 분 만에 목차가 잡힌 문서로 바뀌니까요.
이 글에서 다루려는 건 그 다음입니다.
그렇게 받은 초안을 다음 주에 그대로 내도 되는지, 안 된다면 뭘 더 채워야 하는지.
초안과 개발에 넘길 수 있는 기획서 사이에는 분명한 간격이 있는데,
그 간격을 만드는 게 뭔지 예시 하나로 바로 보여드리겠습니다.
AI가 뽑아 준 초안, 그대로 제출해도 될까요?
가계부 앱을 기획한다고 가정하고, 그 앱에 영수증 스캔 기능을 넣는다고 해 보겠습니다.
같은 기능이 두 문서에는 이렇게 적힙니다.
- 초안: 영수증을 촬영하면 지출 내역이 자동으로 기록된다.
- 개발용 기획서: 영수증을 촬영하면 가게 이름, 날짜, 금액을 인식해 지출 내역에 추가한다.
인식에 실패하면 직접 입력 화면으로 안내하고, 같은 영수증을 다시 찍으면 중복 여부를 물어본다.
인식된 금액은 저장 전에 수정할 수 있다.
초안이 틀린 건 아닙니다.
방향만 보고하고 끝나는 자리였다면 첫 번째 문장으로 충분했을 겁니다.
그리고 방향을 합의하는 자리에서는 이 차이가 잘 걸리지 않습니다.
누구를 위한 기능인지, 왜 넣는지가 맞으면 넘어가니까요.
다만 그 자리를 통과했다고 개발에 넘길 수 있는 상태가 되는 건 아닙니다.
빠지는 건 대체로 비슷합니다
빠지는 조건들을 전부 셀 수는 없지만, 유난히 자주 비어 있는 자리들은 있습니다.
초안을 점검할 때는 이런 데부터 보면 됩니다.
- 실패했을 때: 핵심 동작이 실패하면 사용자에게 무엇이 보이는가.
Ex) 영수증 인식이 실패했을 때의 안내 같은 것.
- 동시에 일어나면: 두 사람이 같은 것을 동시에 하면 어떻게 되는가.
Ex) 공유 가계부에 부부가 같은 지출을 동시에 올리는 경우 같은 것.
- 권한이 없으면: 누가 할 수 있고 누가 못 하는가.
Ex) 상대방이 기록한 내역을 내가 지울 수 있는지 같은 것.
- 비어 있으면: 데이터가 하나도 없을 때 무엇을 보여주는가.
Ex) 설치 직후 지출 내역이 없는 첫 화면 같은 것.
초안을 쓸 때 이 조건들이 안 보이는 이유는 간단합니다.
쓰는 사람 머릿속에는 기능이 잘 돌아가는 장면만 있기 때문입니다.
잘 안 돌아가는 장면은 만들어 본 사람이 묻기 전에는 떠오르지 않습니다.
조건을 다 채워도, 아직 문서는 한 장입니다
그렇게 자주 비는 자리들을 찾아 다 채웠다고 해 보겠습니다.
그래도 개발 미팅에 들고 가기 전에 확인할 게 하나 남았습니다.
미팅에서 실제로 오가는 기획 문서는 원래 한 장짜리가 아니라는 점입니다.
보통은 이 네 가지가 한 세트로 움직입니다.
- 이걸 왜 만드는지, 누구를 위한 것인지 정리한 문서
- 무엇을 만드는지, 세부 조건까지 적힌 문서
- 사용자가 어떤 순서로 움직이는지 그린 그림
- 화면이 대략 어떻게 생겼는지 감을 잡는 그림
예를 들어, 개발자는 견적을 내려고 무엇을 만드는지 적힌 문서부터 찾고,
디자이너는 흐름과 화면 그림부터 찾습니다.
문서를 통째로 전달하면, 받는 사람마다 자기한테 필요한 부분을 찾아내는 일부터 시작하게 됩니다.
그럼 처음에 프롬프트를 입력할 때,
직무별로 전달할 기획 문서를 나눠서 써 달라고 요청할 수 있겠죠?
다만 따로 만든 문서들은 서로를 모릅니다.
이게 무슨 뜻이냐면, 조건 하나를 바꾸면 어느 문서까지 같이 고쳐야 하는지 모른다는 겁니다.
기획서 자동 생성의 진짜 목적은 문서 몇 장이 아니라 이 세트까지입니다.
조건이 채워져 있고, 받는 사람별로 필요한 정보가 나뉘어 있는 상태여야 하죠.
그럼 그 세트는 어떻게 만드는데요?
직접 손으로 하실 수도 있습니다.
초안을 읽으면서 왜 만드는지에 해당하는 내용과
무엇을 만드는지에 해당하는 내용을 따로 떼어내고,
기능마다 앞에서 본 조건들을 대 보고, 사용자 흐름은 별도로 그리는 겁니다.
안 될 건 없는데, 다음 주까지라면 시간이 좀 빠듯하겠죠?
저희 팀이 만드는 매니패스트는 이 나누는 일을 처음부터 대신하는 AI 기획 워크스페이스입니다.
아이디어나 회의록 한 문단을 입력하면, 앞에서 본 네 가지가 각각의 문서로 만들어집니다.
그 네 가지가 바로 PRD, 기능명세서, 유저플로우, 와이어프레임입니다.
만들어지는 순서에도 이유가 있습니다. 앞 문서가 다음 문서의 재료가 되기 때문입니다.
- PRD가 먼저입니다. 누구를 위해 왜 만드는지를 적어 두면,
뒤에서 기능을 넣을지 말지 고민될 때마다 돌아올 기준이 생깁니다.
- 그 기준을 받아서 기능명세서가 실제로 만들 기능 목록을 정합니다.
- 기능 목록이 있어야 유저플로우를 그릴 수 있습니다.
흐름을 그리면 문장에서는 안 보이던 갈림길, 실패하거나 이탈하는 경로가 드러납니다.
- 마지막으로 와이어프레임이 유저플로우의 각 단계를 화면으로 잡습니다.
여기까지 오면 개발자, 디자이너와 그림을 놓고 이야기할 수 있습니다.
조건이 비어 있는 기능에는 AI가 제안을 올려 줍니다.
언제 시작되는지, 실패하면 무엇을 보여주는지 같은 것들이 포함됩니다.
그중 혼자 정하기 애매한 건 질문으로 올라오고요.
적용할지 답할지는 쓰는 사람이 정하고, 정한 내용은 그대로 문서에 문장으로 적힙니다.
자주 묻는 질문
AI한테 더 자세히 시키면 개발용 기획서까지 한 번에 나오지 않나요?
어느 정도는 맞습니다. 자세히 시킬수록 초안 품질도 올라갑니다.
여기서 개발용 기획서란 개발자가 읽고 바로 만들기 시작할 수 있는 문서,
그러니까 기능마다 언제 무엇이 일어나는지와 예외 상황까지 적혀 있는 문서를 말합니다.
문제는 시키는 문장에 내가 아는 조건만 담긴다는 점입니다.
내가 생각하지 못한 예외는 요청에 들어가지 않고, 초안에도 없습니다.
누락된 예외를 검토해 달라고 요청할 수도 있지만,
그렇게 나온 제안이 이 프로젝트에 맞는지는 사람이 판단해야 합니다.
그래서 얼마나 잘 시켰든, 초안을 점검하고 빠진 조건을 채우는 단계는 따로 필요합니다.
화면 흐름이나 와이어프레임도 자동으로 만들 수 있나요?
가능한 도구들이 있습니다.
와이어프레임은 버튼과 안내 문구를 어디에 놓을지 그린 화면 설계도이고,
화면 흐름은 그 화면들이 어떤 순서로 이어지는지 그린 지도입니다.
고를 때 확인할 건 그 화면 그림이 기능 문서와 연결되어 있는지입니다.
예를 들어 "영수증 인식에 실패하면 직접 입력 화면으로 안내한다"는
조건을 고쳤을 때 화면도 같이 바뀌는지요.
문서 따로 그림 따로인 도구라면 조건이 하나 바뀔 때마다 두 군데를 고치게 됩니다.
기획서는 어떤 순서로 쓰는 게 맞나요?
왜 만드는지를 먼저 정하고, 무엇을 만드는지를 기능 목록으로 적고,
기능마다 예외 상황을 포함한 조건을 채우고, 마지막에 화면 흐름과 화면 모양을 그립니다.
문서 이름으로는 PRD, 기능명세서, 유저플로우, 와이어프레임 순서입니다.
앞 단계에서 정한 것이 다음 단계의 재료가 되기 때문에 순서가 이렇습니다.
다만 순서 자체보다 중요한 건 각 단계에서 정하지 않은 조건을 빈칸으로 남기지 않는 것입니다.
빈칸으로 남긴 조건은 개발팀 리뷰에서 질문으로 나옵니다.
제출 전에 꼭 확인해야 할 두 가지!
다음 주에 낼 초안으로 돌아가 보겠습니다.
AI가 뽑아 준 문서는 목차도 문장도 이미 그럴듯할 겁니다.
그런데 그 기획서는 팀장님 책상에서 멈추지 않습니다.
개발자, 디자이너들도 같이 볼 기획서입니다.
그래서 확인할 건 두 가지입니다.
1. 빠지기 쉬운 조건들을 기능마다 대 봤을 때 빈칸이 얼마나 남는지
2. 그 문서가 받는 사람(직무)별로 나뉠 수 있는 상태인지
채우는 일과 나누는 일을 도구에 맡기고 싶다면, 매니패스트에 초안을 그대로 붙여넣어 보세요.
한 장짜리 초안이 PRD, 기능명세서, 유저플로우, 와이어프레임으로 나뉘어 정리되고,
비어 있는 조건마다 질문이 올라옵니다. 나중에 받을 질문을 제출 전에 미리 확인할 수 있습니다.