안녕하세요, 팀 매니패스트입니다!

창업을 꿈꾸는 분들, 혹은 한 번이라도 도전해 보신 분들이라면 공감하실 수도 있을 것 같은데요. 
아이디어라는 건 의자에 앉아서 계속 고민할 때보다 길을 걷다가, 
혹은 샤워를 하다가 갑자기 생각나더라고요.

그리고 그 좋은 아이디어가 떠오른 날은 잠도 잘 안 오죠.
누워서도 생각이 계속 이어지고, 결국 일어나서 그 생각을 마냥 적어 보기도 하고, 
AI를 켜고 새벽까지 대화를 주고받게 되기도 합니다. 

타깃은 누구인지, 비슷한 서비스는 무엇이 있는지, 수익은 어디서 나는지. 
그렇게 며칠을 보내면 사업계획서 항목이 하나씩 채워지고, 
지원사업 신청서와 발표 자료까지 만들어집니다. 
여기까지는 창업을 준비해 본 분이라면 익숙한 과정일 거예요.

이렇게 아이디어를 고도화하다 보면 세부 상황도 꽤 많이 생각하게 되죠. 
예를 들어 추천할 곳이 없으면 어떻게 할지, 뒤로 가면 골랐던 건 남길지, 
공유받은 사람은 어디까지 볼 수 있게 할지 같은 것들이요. 
문제는 그 생각들이 AI 대화창과 메모 여기저기에 흩어져 있다는 겁니다. 
개발자에게 넘기려면, 혹은 코딩 AI에게 시키려면 이걸 어떤 문서에 어떤 순서로 적어야 하는지, 
어디까지 정해야 개발이 시작되는지는 한 번도 배운 적이 없을겁니다. 🥲

사업계획서는 이 서비스를 왜 만드는지 설득하는 문서입니다.  
그러나 제품을 실제로 만들려면 제대로 된 기획서가 필요하겠죠?

제대로 된 기획서라는 말을 하면 거창하게 들릴 수 있습니다.
일단 기획서 안에는 필수적으로 네 가지의 문서가 필요하고 
그 문서의 내용은 바로 네 가지 질문에 답들입니다. 
이 글에서는 그 네 장을 순서대로 만듭니다. 

먼저, 매니패스트는 사업계획서를 대신 써 주는 도구는 아닙니다. 
그 다음 문서, 그러니까 개발자나 코딩 AI에게 넘길 앱 기획서를 만드는 기획 협업 워크스페이스입니다. 
그래서 이번에는 사업계획서 다음 단계를 저희 팀이 직접 해봤습니다. 
가상의 창업 아이템으로 데이트 코스 추천 앱, 이름하여 '오늘의 동선'을 한 번 기획해보겠습니다. 

순서는 아까 말씀드렸듯이 네 단계입니다. 
자, 그럼 이제 시작해볼까요?

PRD: 서비스 개요 한 문단이 기획서 첫 장이 됐습니다

PRD부터 만들어보겠습니다. 그게 뭐냐고요? 
바로 아까 말씀드렸던 첫 번째 질문, 왜 누구를 위해 만드는가에 답하는 문서입니다.

저희가 오늘 만들어 볼 앱 '오늘의 동선'은 
가까운 전시와 카페를 묶어 데이트 코스를 추천하는 앱입니다. 
사업계획서에 서비스 개요를 이미 써 뒀다면 빈 기획서 양식을 새로 여는 것보다 
그 문단에서 시작하는 편이 빠릅니다. 
매니패스트의 AI 에이전트 '매니'에게 서비스 개요 문단을 그대로 붙여 넣었습니다.
 

'오늘의 동선'은 주말 데이트나 나들이를 준비하는 
20~30대 두 사람을 위한 코스 추천 서비스다. 
사용자가 지역과 하고 싶은 활동을 고르면 
가까운 전시와 카페를 묶어 하루 코스를 제안하고, 
마음에 드는 코스는 저장해서 동행인에게 공유할 수 있다.

그리고 위 문단 아래에 두 문장을 더 적었습니다.
 

이번에는 예약, 결제, 실시간 위치 기능은 빼고 만든다. 
장소 정보를 어디서 가져올지, 공유받은 사람이 무엇까지 할 수 있는지는 아직 정하지 않았다.

처음부터 다 만들 생각은 없었기 때문입니다. 
사람들이 추천받은 코스를 보고 정말 가고 싶어 하는지부터 확인하고 싶었고, 
정하지 못한 것은 정하지 못했다고 그대로 적었습니다.
 

저렇게 작성했더니 PRD 초안이 나왔습니다. 
PRD는 어떤 제품을 누구를 위해 왜 만드는지 정리한 문서로, 앱 기획서의 첫 장에 해당합니다. 
뒤에 만드는 문서들이 전부 이 첫 장을 기준으로 삼습니다. 아래가 그 초안 전체입니다.






초안을 훑어보면 신청서에 적었던 문제와 해결 방안이 앞쪽에 그대로 들어가 있고, 
그 뒤로 타겟 사용자와 사용 시나리오, 시제품에서 확인할 지표, 리스크까지 차례로 정리돼 있습니다.

눈에 띈 건 두 군데였습니다. 
핵심 지표에 "코스를 저장하거나 동행인에게 공유하는 비율"을 보자고 적혀 있었는데, 
나중에 사용자 반응을 볼 때 기준으로 쓰기 좋아서 그대로 두었어요. 
그리고 우리가 아직 못 정했다고 적은 장소 정보와 
공유 권한은 초안에 일단 한 가지 안으로 적혀 있었습니다. 
이건 우리가 정해야 하는 부분이라, 다음 단계에서 매니가 하나씩 물어 왔습니다.

기능명세서: 장소가 없으면 다른 동네를 추천해도 될까요

이제 기능명세서로 넘어가보겠습니다.
이 서비스가 왜 필요하며 누가 쓸 것인지에 대해서 답했으니까, 
이제 두 번째 질문, 버튼을 누르면 무슨 일이 생기는가를 정하는 차례입니다.

못 정했다고 적었던 두 가지에 매니패스트의 AI 에이전트 매니가 질문을 붙여 왔습니다. 
그리고 우리가 적지 않았던 것까지 하나 더 물었습니다. 
선택 조건에 맞는 장소가 부족할 때 어떻게 할지였습니다. 
사용자는 오늘 전시를 보러 가고 싶은데 추천할 만한 마땅한 장소가 없다면 어쩌지? 
사업계획서를 쓸 때는 생각하기 쉽지 않은 질문입니다. 
그러나 이런 질문들은 개발자를 만났다면 첫 미팅에서 나왔을 질문이기도 합니다.

장소가 부족할 때의 선택지는 세 가지였습니다. 
부족하다고 안내하고 다시 고르게 하기, 비슷한 조건을 대신 제안하기, 
찾은 장소만이라도 먼저 보여주기. 두 번째 안을 놓고 팀에서 잠깐 이야기가 오갔습니다.
"성수를 가려고 켰는데 갑자기 홍대를 추천하면 좀 이상하지 않아요?" 이 한마디로 정리됐어요. 

사용자가 처음 고른 지역이 의미 없어지면 안 되니까요. 
그래서 첫 번째 안, 부족하다고 안내하고 다시 고르게 하는 쪽을 골랐습니다.

나머지 두 질문도 답했습니다. 
장소 정보는 외부 지도 서비스를 연동하는 대신 우리가 직접 고른 곳만 쓰기로 했습니다. 
그래서 첫 시제품에는 성수의 전시와 카페 몇 곳만 샘플로 들어갑니다. 
공유받은 사람은 코스를 보기만 할 수 있게 했습니다.

이렇게 정한 답은 기능명세서에 문장으로 들어갑니다. 
기능명세서는 버튼을 눌렀을 때 무슨 일이 일어나야 하는지 적어 둔 문서입니다. 
개발자는 이걸 보고 만들고, 다 만든 뒤에도 이 항목대로 되는지 확인합니다.

문장을 읽어 보니 질문이 하나 더 생겼습니다. 
부족하다는 안내를 보고 돌아갔을 때, 지역과 활동을 처음부터 다시 고르게 할 것인지. 
"그건 귀찮으니까 남겨 두자"로 정했고, 이 조건은 매니에게 추가로 요청했습니다.

못 정했던 조건 세 개가 이렇게 문장이 됐습니다. 조건을 글로 정했으니, 이제 그림으로 옮겨 볼까요?

유저플로우와 와이어프레임: 추천이 안 되는 경우까지 화면으로 그렸습니다

이제 유저플로우와 와이어프레임을 만들어보았습니다. 
이제 세 번째와 네 번째 질문, 화면이 어떤 순서로 이어지고 어떻게 생겼는가를 알아볼 차례입니다.
사용자가 어느 화면에서 시작해서 어디로 이동하는지 그린 지도라고 보면 됩니다. 
개발자에게 "이 화면 다음에 저 화면"이라고 말로 설명하는 대신 이 지도를 건네면 됩니다.

'코스 추천 요청하기' 다음에 '추천 코스 존재?'라는 갈림길이 생겼습니다. 
코스가 있으면 결과 화면으로 가고, 없으면 장소 부족 안내로 갑니다. 
부족 안내에서 '조건 다시 선택하기'를 누르면 선택 화면으로 돌아옵니다. 
아까 정한 조건이 그대로 갈림길이 된 것이지요.

흐름에는 저장 목록과 공유 화면도 있었지만, 
이번에 화면으로 옮길 것은 조건 선택, 추천 결과, 장소 부족 안내 세 개로 좁혔습니다. 
추천을 요청하고 결과를 확인하는 구간부터 보고 싶었기 때문입니다.

세 화면의 와이어프레임을 생성했습니다. 와이어프레임을 쉽게 말하자면 
디자인적인 요소 없이 만들어진 UI/UX 초안이라고 보시면 됩니다.

즉, 버튼과 안내 문구를 어디에 놓을지 보여주는 화면 설계입니다. 
디자이너와 개발자가 같은 화면을 놓고 이야기할 수 있게 해 줍니다. 

'장소가 부족하면 안내한다'고 적었던 문장이 '추천할 코스가 없어요'라는 
제목과 돌아가기 버튼으로 보이기 시작했어요. 흐름도 하나와 화면 세 장이 생겼습니다.

자, 이제 이 화면에 동작을 붙여 볼 차례입니다.

코딩 AI: 이번에 만들 부분만 좁혀서 넘겼습니다

여기서부터는 두 갈래입니다.
함께할 개발자나 아는 개발자가 있다면 
지금까지 만든 문서 네 장과 아래 요청문을 그대로 넘기면 됩니다.
직접 해볼 수도 있는데, 우리는 직접 해봤습니다.

코딩 AI는 글로 요청하면 코드를 대신 써 주는 도구입니다. 
이번에는 Claude Code를 썼습니다. 
매니패스트와 연결해 두면 파일을 내려받아 붙일 필요 없이 기획서를 직접 읽습니다. 

문서에는 저장과 공유도 들어 있지만, 
첫 구현은 추천 결과와 부족 안내를 확인하는 데까지만 잡았습니다. 
요청은 이렇게 적었습니다.

매니패스트에서 기획 중인 '오늘의 동선' 기획서와 화면 설계를 읽고, 
조건 선택에서 추천 결과까지 눌러볼 수 있게 만들어 주세요. 
가상 장소를 쓰고, 장소가 부족하면 안내 화면을 보여주세요. 
돌아갔을 때 이전 선택은 유지해 주세요. 로그인, 저장, 공유는 이번에 만들지 않습니다. 
장소가 충분한 경우와 부족한 경우를 각각 시험할 수 있게 해 주세요.

처음이라면 요청 끝에 
"제가 브라우저에서 열어 확인할 수 있게 실행 방법도 알려주세요" 
한 줄을 붙여 두면 편합니다. 

이번에는 회원가입이나 데이터베이스 연결 없이 
내 컴퓨터 브라우저에서 바로 열리는 형태로 만들었습니다.

열어 보니 '추천 코스 보기'를 누르면 샘플 코스가 나왔습니다. 
성수의 전시와 카페가 걸어서 이어지는 순서로 묶여 있고, 장소 사이 도보 시간까지 붙어 있었습니다.

시험 삼아 카페 데이터를 비우니 장소 부족 안내가 떴고, 
'조건 다시 선택하기'를 누른 뒤에도 성수, 전시, 카페 선택이 그대로 남아 있었습니다. 
휴대전화 크기로 봐도 같은 동작이었어요. 
"귀찮으니까 남겨 두자"고 정한 조건이 그대로 눌러지는 순간이었습니다. 😎

함께 만들 사람에게 보여줄 화면이 생겼습니다

처음에는 신청서에 적은 서비스 개요 한 문단이 있었습니다. 
지금은 추천할 곳이 없을 때 뭐라고 안내할지, 
사용자가 돌아가면 무엇을 남겨 둘지까지 눌러서 확인할 수 있습니다.

개발자나 디자이너를 만나면 이 화면을 놓고 이야기하면 됩니다. 
이번에 만들 범위가 어디까지인지, 어떤 조건을 왜 그렇게 정했는지가 
화면에 다 있으니 설명이 훨씬 짧아집니다. 
AI 대화창에 흩어져 있던 생각이 눌러 볼 수 있는 화면 하나가 된 셈이죠.

데이트를 계획하는 친구에게 보여줄 수도 있습니다. 
이 코스로 가고 싶은지, 장소가 없다는 안내를 받으면 다음에 무엇을 하고 싶은지. 
그 반응이 장소 데이터를 더 모을지 저장 기능부터 만들지 정할 때 참고가 됩니다. 
이번 제작에서는 아직 거기까지 가지 않았습니다.

신청서에 서비스 개요를 써 뒀다면 앱 기획서는 빈 종이에서 시작하지 않아도 됩니다.

그 문단을 매니패스트에 붙여 넣고, 사용자가 가장 먼저 해볼 행동 하나를 골라 보세요. 
'버튼을 누른 다음에 어떤 화면이 나와야 할까'를 정하는 데서 첫 앱 기획서가 시작됩니다. 
잠 못 들게 하던 그 아이디어, 이번 주말에 첫 화면까지 가 보세요.