검증은 끝났는데, 다음 단계가 막막합니다
아이디어를 정리하고, 시장에서 통하는지 확인까지 했습니다. 그런데 이제 개발을 시작하려고 보면 또 다른 벽이 나타납니다.
"내 머릿속에 있는 이걸, 어떤 형태로 정리해서 넘겨야 하지?"
기획서, 요구사항 정의서, PRD, 화면 설계서, 와이어프레임. 검색하면 비슷한 듯 다른 용어가 한꺼번에 쏟아집니다. 개발사에 문의하면 "기획서를 보내주세요"라는 답이 돌아오고, 바이브코딩을 하려고 하면 "PRD를 먼저 써야 한다"는 글이 나옵니다. 그런데 정작 그 문서를 어떻게 쓰는 건지, 어디까지 내가 해야 하는 건지는 알려주는 곳이 없습니다.
이 단계에서 멈추는 분이 꽤 많습니다. 아이디어도 있고 검증도 했는데, 개발로 넘기는 다리를 못 만들어서 시간이 지나가는 거죠.
PRD가 뭔데, 왜 요즘 자꾸 나오나요
PRD는 Product Requirements Document의 줄임말입니다. 한국어로는 "제품 요구사항 문서"라고 번역하는데, 이 번역이 오히려 어렵게 느껴질 수 있습니다.
쉽게 풀면 이렇습니다. "이 서비스는 이런 사람을 위해, 이런 문제를 풀고, 이런 기능이 있고, 이런 순서로 동작한다"를 한 문서에 담은 것이 PRD입니다. 예전에는 기획서, 요구사항 정의서, 화면 설계서가 각각 따로 만들어졌는데, 요즘은 PRD 하나에 핵심을 담고 거기서부터 대화를 시작하는 방식이 많아졌습니다.
특히 바이브코딩이나 AI 도구를 쓸 때 PRD의 역할이 더 커졌습니다. AI에게 "앱 하나 만들어줘"라고 말하면 뭔가 나오긴 나오지만, 방향이 엉뚱한 곳으로 갑니다. 그런데 PRD를 먼저 정리해서 넘기면, AI가 만드는 결과물의 정확도가 완전히 달라집니다. 13번 글에서 "설계 없이 개발하면 수정비가 3배"라고 했던 이야기가 여기서 이어집니다. PRD는 사람이든 AI든, 개발을 시작하기 전에 방향을 맞추는 설계도인 셈이죠.
비개발자가 PRD에 담아야 할 것, 안 담아도 되는 것
PRD라는 이름이 거창하지만, 비개발자가 쓰는 PRD는 사실 다섯 가지만 담으면 됩니다.
이 서비스를 쓰는 사람은 누구인가요. 16번 글에서 정리한 "누구의 문제인가"의 답을 여기에 옮기면 됩니다. "30대 직장인 중 이직을 준비하는 사람", "소규모 카페를 운영하면서 재고 관리가 어려운 사장님"처럼 한두 문장이면 충분합니다.
그 사용자가 지금 겪고 있는 불편은 무엇인가요. 이것도 16번 글에서 이미 정리한 내용입니다. 문제를 한 문장으로 쓸 수 있으면, PRD의 방향은 잡힌 겁니다.
문제를 풀기 위해 이 서비스가 꼭 해야 하는 일을 3~5개만 적으세요. 10개, 20개를 나열하고 싶은 마음이 들겠지만, 처음에는 3~5개로 충분합니다. 나머지는 서비스가 시장에 나간 후에 추가해도 늦지 않습니다.
16번 글에서 마지막으로 정리한 것, 사용자가 처음 앱을 열어서 가치를 느끼는 순간까지의 경로입니다. "가입 → 메인 화면 → 핵심 기능 사용 → 결과 확인" 정도의 흐름을 글로 써보세요. 완벽한 화면 설계가 아니어도 괜찴습니다.
17번 글에서 확인한 내용을 한두 줄로 정리합니다. "잠재 사용자 5명과 대화한 결과, 3명이 기존 서비스의 이런 부분에서 불편을 느끼고 있었다", "가짜 도어 테스트에서 일주일간 40명이 관심을 표시했다" 같은 형태입니다. 이 근거가 있으면 개발사와의 대화에서 "왜 이 기능이 필요한가"에 대한 답이 명확해집니다.
여기까지가 비개발자의 영역입니다. 기술 스택이나 데이터베이스 구조, API 명세 같은 것은 안 담아도 됩니다. 그건 개발사나 AI 도구가 채울 영역이니까요. PRD는 완벽한 설계도가 아니라, 대화의 출발점입니다.
PRD에서 화면 설계서로 넘어가는 순간
PRD까지 정리하면 다음 단계는 화면 설계서입니다. 와이어프레임이라고도 부르는데, PRD에 적힌 기능과 흐름을 실제 화면 단위로 옮기는 작업입니다.
이 전환이 비개발자에게 가장 어려운 구간입니다. 기능 목록을 화면 단위로 재배치해야 합니다. 화면과 화면 사이의 이동 경로도 설계해야 하고요. 한 화면 안에서 사용자가 보는 것과 하는 일을 구분하는 작업도 필요합니다. 이건 서비스 구조를 반복적으로 다뤄본 경험이 있어야 자연스럽게 나옵니다.
그래서 이 구간에서 "혼자 다 하겠다"고 버티면, PRD까지 잘 왔는데 화면 설계에서 몇 주가 멈추는 일이 생깁니다. 반대로 이 구간에서 경험 있는 파트너와 대화하면, PRD에 적힌 다섯 가지가 화면으로 바뀌는 속도가 확 빨라집니다.
PRD는 완벽하게 쓰는 게 아니라 같이 만드는 겁니다
비개발자가 PRD를 처음 쓰면, 대부분 두 가지 중 하나에 빠집니다. 너무 짧게 써서 핵심이 빠지거나, 너무 길게 써서 방향이 흐려지거나요. 두 경우 모두 자연스러운 일입니다. PRD를 처음부터 완벽하게 쓸 수 있는 사람은 거의 없으니까요.
흐름소프트의 초기 미팅은 이 지점에서 시작합니다. 의뢰인이 "완벽한 PRD"를 들고 와야 하는 게 아니라, 머릿속에 있는 아이디어와 검증 결과를 가지고 대화를 하면 됩니다. 그 대화 안에서 사용자 정의가 선명해지고, 핵심 기능의 우선순위가 잡히고, 첫 사용 흐름이 구체화됩니다. 그리고 그 결과가 자연스럽게 PRD가 됩니다.
530건의 프로젝트를 거치면서 "이 기능은 처음에 꼭 있어야 한다"와 "이건 출시 후에 붙여도 된다"를 구분하는 눈이 쌓여 있기 때문에, 대화 한 번으로 PRD가 실행 가능한 수준까지 올라갑니다. 그 다음에는 화면 설계로 바로 이어지고요.
AI가 코드를 만들어주는 시대에도, 그 AI에게 무엇을 만들라고 말할 수 있는 사람이 결국 서비스를 완성합니다. PRD는 그 "무엇"을 정리하는 첫 번째 도구이고, 혼자 쓰는 것보다 같이 만드는 게 훨씬 빠릅니다.
