아이디어 실증 이후 PRD와 설계서 작성

아이디어를 정리하고 시장 검증까지 완료한 단계입니다. 그러나 개발 착수 시점에 새로운 과제가 발생합니다.

구상한 내용을 어떤 형식으로 정리하고
개발사에 어떻게 전달하는가

검증 완료 후 다음 단계의 불명확성

기획서, 요구사항 정의서, PRD, 화면 설계서, 와이어프레임 등입니다. 검색하면 유사하지만 상이한 용어가 다수 제시됩니다. 개발사에 문의하면 기획서 제출을 요청받고, 인공지능으로 직접 개발하려 하면 PRD를 우선 작성해야 한다는 안내를 확인합니다. 그러나 문서를 어떻게 작성하고 발주처가 어디까지 작성하는지 안내하는 곳은 없습니다.

이 단계에서 진행이 중단되는 경우가 많습니다. 아이디어와 검증 결과가 있으나, 개발 단계로 전환하는 문서를 작성하지 못해 기간이 소요됩니다.

PRD의 정의와 활용 증가 배경

영문 약어이므로 생소하지만, 정의는 다음과 같습니다.

기존에는 기획서, 요구사항 정의서, 화면 설계서를 각각 작성했으나, 최근에는 1개 문서에 핵심을 정리하고 이를 기준으로 협의를 시작하는 방식이 증가했습니다.

특히 인공지능 도구 활용 시 이 문서의 비중이 증가했습니다. 단순 개발 요청만 입력하면 결과물은 생성되지만 의도와 다른 방향으로 개발됩니다. 반면 사전 정리한 문서를 전달하면 결과물이 크게 달라집니다. 화면 설계와 수정 비용에서 설명한 내용과 같은 이유입니다. 개발 주체가 사람이든 인공지능이든, 개발 착수 전에 방향을 확정하는 설계 문서입니다.

PRD의 필수 항목과 제외 항목

명칭과 달리 발주처가 작성할 항목은 다섯 가지입니다.

이상이 발주처가 작성할 범위입니다. 개발 기술, 데이터 저장 방식, 시스템 간 연동 방식은 기재하지 않아도 됩니다. 해당 항목은 개발사 또는 개발 도구가 작성할 영역입니다.

완성된 설계 문서가 아니라
협의의 기준 문서입니다.

화면 설계서 작성 단계로의 전환

위 항목을 정리하면 다음 단계는 화면 설계서입니다. 기재한 기능과 흐름을 실제 화면 단위로 전환하는 작업입니다.

이 전환 단계가 가장 어려운 구간입니다. 기능 목록을 화면 단위로 재구성하고, 화면 간 이동 경로를 설계하고, 화면별로 표출 정보와 이용자 행동을 구분해야 합니다. 이 작업은 서비스 구조 설계 경험이 있어야 수월합니다.

단독 완성이 아닌 공동 작성

최초 작성 시에는 대부분 두 가지 중 하나에 해당합니다. 분량이 지나치게 짧아 핵심이 누락되거나, 지나치게 길어 방향이 불명확해집니다. 두 경우 모두 일반적입니다. 최초 작성에서 완성도를 확보하는 경우는 드물기 때문입니다.

흐름소프트의 첫 상담은 이 지점에서 시작합니다. 완성된 문서가 없어도 구상 내용과 검증 결과로 협의를 진행합니다. 협의 과정에서 대상 이용자가 명확해지고, 기능의 우선순위가 정리되고, 최초 이용 흐름이 구체화됩니다. 그 결과가 문서가 됩니다.

첫 버전 필수 기능과 출시 후 적용 기능을 구분하는 판단 기준은 다수의 프로젝트 경험으로 축적됩니다. 따라서 1회 협의로 개발 착수가 가능한 수준까지 정리되고, 이후 화면 설계로 이어집니다.

인공지능이 코드를 생성하는 환경에서도 인공지능에 개발 대상을 지시할 수 있는 사람이 서비스를 완성합니다. PRD는 개발 대상을 정리하는 첫 문서이며, 단독 작성보다 공동 작성이 빠릅니다.

포함할 항목과 제외할 항목을 나누는 방법은 요구사항 정의 방법에서 설명합니다. 문서별로 실제 작성하는 항목은 기획서와 설계서의 차이에서 설명합니다.