9장. 만들 기능과 화면 정리하기 (PRD 기초)

지난 장에서 우리는 누구를 위한 서비스인지 정했습니다. 이제 서비스의 얼굴이 조금 보이기 시작합니다. 하지만 아직 손을 바로 움직이기에는 부족합니다. 왜냐하면 초보자가 가장 자주 빠지는 함정이 바로 여기 있기 때문입니다.

"일단 만들면서 생각해보면 되지 않을까?"

물론 어느 정도는 맞는 말입니다. 실제 개발은 만들면서 배우는 과정이기도 합니다. 다만 아무 기준 없이 시작하면 금방 길을 잃습니다. 로그인부터 만들지, 글 작성부터 만들지, 검색은 지금 붙일지 나중에 붙일지, 목록 화면은 어떤 정보를 보여줘야 할지 계속 흔들리게 됩니다.

그래서 이 단계에서 필요한 것이 PRD입니다. 어렵게 들리지만 겁먹을 필요는 없습니다. 이 책에서 말하는 PRD는 거대한 회사 문서가 아닙니다. 초보자가 첫 서비스를 만들기 위해 적는 작고 실용적인 요구사항 정리 메모에 가깝습니다.

쉽게 말해 PRD는 이런 질문에 답하는 문서입니다.

"우리는 지금 정확히 무엇을 만들고, 무엇은 아직 만들지 않을 것인가?"

이 장에서는 그 답을 정리하는 방법을 배웁니다. 특히 필수 기능, 제외 기능, 필요한 화면을 구분해 작은 규모의 PRD 초안을 만드는 데 집중할 것입니다. 이 작업은 사람에게도 중요하지만, AI에게 일을 맡길 때는 더 중요합니다. AI는 똑똑하지만 텔레파시는 못 합니다. 요구사항이 흐리면 결과도 흐려집니다.

PRD는 거창한 문서가 아니라 작업 기준이다

PRD는 Product Requirements Document의 줄임말입니다. 한국어로는 보통 제품 요구사항 문서라고 부릅니다. 이름만 들으면 왠지 회의실, 큰 모니터, 진지한 표정이 떠오를 수 있습니다. 하지만 첫 서비스를 만드는 우리에게 PRD는 그렇게 무거운 것이 아닙니다.

지금 단계에서 PRD는 "개발 전에 정리해두는 약속장" 정도로 생각하면 됩니다.

어떤 문제를 해결하려는지, 누가 쓰는지, 어떤 기능이 꼭 필요한지, 어떤 화면이 있어야 하는지, 이번 버전에서는 무엇을 하지 않을지를 적어두는 문서입니다. 이것이 있어야 개발 중간에 흔들릴 때 다시 돌아올 수 있습니다.

예를 들어 여행을 간다고 생각해봅시다. 목적지도 없이 짐부터 싸면 수영복을 챙겨야 할지, 패딩을 챙겨야 할지 모릅니다. 하지만 "2박 3일 가을 부산 여행"이라고 정해지면 챙길 것이 확 줄어듭니다. PRD도 비슷합니다. 만드는 서비스의 목적과 범위를 먼저 정해두면, 필요한 기능과 필요 없는 기능이 보이기 시작합니다.

왜 초보자일수록 PRD가 더 필요할까

개발 경험이 많은 사람은 머릿속에서 어느 정도 구조를 그릴 수 있습니다. 하지만 처음 만드는 사람은 화면 하나를 떠올리기도 벅찰 수 있습니다. 이때 PRD 없이 시작하면 작업이 자꾸 옆길로 샙니다.

예를 들어 우리는 개인 기록 서비스를 만든다고 해봅시다. 처음에는 글 작성과 검색 정도만 생각했습니다. 그런데 화면을 만들다 보면 이런 생각이 계속 올라옵니다.

"태그도 넣을까?" "댓글도 있으면 좋지 않을까?" "공개 글과 비공개 글도 나누면 멋있지 않을까?" "좋아요 기능도 있으면 서비스 같지 않을까?"

이런 생각 자체는 나쁘지 않습니다. 문제는 지금 해야 할 일과 나중에 해도 될 일을 구분하지 못하면, 결국 아무것도 끝내지 못한다는 점입니다.

초보자의 첫 서비스에서 가장 중요한 것은 화려함이 아니라 완성입니다. PRD는 그 완성을 도와주는 브레이크이자 핸들입니다. 욕심을 멈추게 하고, 방향을 잡아줍니다.

그리고 이 점은 AI와 협업할 때 더 중요해집니다. PRD가 없는 상태에서 AI에게 "메모 서비스 하나 만들어줘"라고 하면 결과는 그럴듯해 보여도, 내가 원하는 것과 어긋날 가능성이 큽니다. 반대로 "로그인한 사용자가 자신의 글을 작성, 수정, 삭제하고 제목이나 본문으로 검색할 수 있는 개인 기록 서비스"처럼 분명하게 말하면 훨씬 좋은 결과가 나옵니다.

좋은 PRD는 길지 않아도 선명하다

초보자는 종종 두 가지 극단으로 갑니다. 하나는 아무 문서도 안 쓰는 경우고, 다른 하나는 시작도 전에 너무 완벽한 문서를 쓰려는 경우입니다.

둘 다 피하는 편이 좋습니다.

첫 서비스의 PRD는 길게 쓸 필요가 없습니다. 대신 선명해야 합니다. 문장을 읽었을 때 다음 세 가지가 바로 보여야 합니다.

• 누가 이 서비스를 쓰는가

• 이 서비스가 해결하는 핵심 문제는 무엇인가

• 첫 버전에서 반드시 되는 것은 무엇인가

여기에 하나를 더 붙이면 더 좋습니다.

• 이번 버전에서 하지 않을 것은 무엇인가

이 마지막 항목이 생각보다 아주 중요합니다. 서비스는 무엇을 넣느냐만으로 만들어지지 않습니다. 무엇을 빼느냐에 따라서도 완성도가 달라집니다.

기능은 소원 목록이 아니라 우선순위 목록이어야 한다

기획을 처음 하면 기능을 떠올리는 일은 꽤 즐겁습니다. 머릿속에서 서비스가 점점 풍성해지는 느낌이 들기 때문입니다. 문제는 풍성함과 완성 가능성이 비례하지는 않는다는 점입니다.

그래서 기능을 적을 때는 한꺼번에 늘어놓기보다, 우선 세 덩어리로 나누는 것이 좋습니다.

• 필수 기능: 첫 버전이 서비스로 성립하려면 반드시 필요한 기능

• 있으면 좋은 기능: 당장 없어도 되지만 나중에 확장할 수 있는 기능

• 이번 버전 제외 기능: 아이디어는 좋지만 지금 만들지 않을 기능

이렇게 나누면 머릿속이 훨씬 맑아집니다. 특히 초보자에게는 "하고 싶은 기능"보다 "이번에 반드시 끝낼 기능"을 중심에 두는 습관이 중요합니다.

예를 들어 우리의 실습 서비스가 "개인 기록을 저장하고 다시 찾는 웹 서비스"라면, 필수 기능은 비교적 분명합니다. 회원가입과 로그인, 글 작성, 목록 보기, 상세 보기, 수정, 삭제, 검색이 핵심입니다. 반면 댓글, 좋아요, 공유, 팔로우, 알림, AI 자동 요약은 지금 당장 없어도 서비스의 기본 가치를 전달할 수 있습니다.

이 구분이 있어야 개발도 쉬워지고, AI에게 작업을 나눠 맡기기도 쉬워집니다.

필수 기능을 고르는 가장 쉬운 질문

필수 기능을 고르는 기준이 애매하다면, 스스로에게 이렇게 물어보면 됩니다.

"이 기능이 없으면, 사용자가 핵심 문제를 해결할 수 없는가?"

이 질문은 꽤 강력합니다.

예를 들어 개인 기록 서비스에서 검색 기능은 어떤가요? 만약 사용자의 핵심 문제가 "나중에 다시 찾기 어렵다"라면 검색은 꽤 중요한 기능입니다. 반면 프로필 사진 변경 기능은 어떤가요? 있으면 좋지만, 없어도 사용자는 글을 저장하고 다시 찾을 수 있습니다. 그렇다면 필수 기능은 아닐 가능성이 큽니다.

또 다른 질문도 도움이 됩니다.

"이 기능이 없으면, 첫 사용자에게 이 서비스를 써볼 이유가 사라지는가?"

이 기준으로 보면 많은 기능이 자동으로 뒤로 밀립니다. 초보자에게는 이것이 아주 반가운 일입니다. 할 일이 줄어든다는 뜻이기 때문입니다.

화면은 기능의 그림이다

기능을 정리했다면 이제 화면을 정리할 차례입니다. 많은 초보자가 기능과 화면을 섞어 생각합니다. 하지만 둘은 다릅니다.

기능은 "무엇을 할 수 있는가"이고, 화면은 "그것을 어디서 하게 할 것인가"입니다.

예를 들어 "로그인"은 기능입니다. 그리고 그것을 수행하는 장소는 "로그인 화면"입니다. "글 수정"은 기능이고, 그것을 수행하는 장소는 "글 수정 화면"일 수도 있고 "글 작성 화면을 재사용한 편집 화면"일 수도 있습니다.

이 구분이 중요한 이유는, 화면을 정리하면 사용자 경험이 보이기 시작하기 때문입니다. 사용자가 어디로 들어와서, 무엇을 누르고, 어떤 순서로 이동하는지가 그려집니다. 그리고 이 흐름은 다음 장에서 다룰 사용자 흐름 설계와 자연스럽게 이어집니다.

지금 단계에서는 복잡한 화면 설계까지 갈 필요는 없습니다. 우선 "이 서비스가 굴러가려면 어떤 화면이 최소한 필요할까?"를 정리하면 충분합니다.

우리 서비스에 필요한 화면은 무엇일까

이 책의 실습 서비스는 작은 풀스택 웹 서비스입니다. 회원가입과 로그인, 글 작성·수정·삭제, 목록·상세 화면, 검색까지 포함됩니다. 그렇다면 필요한 화면도 자연스럽게 따라 나옵니다.

가장 기본적으로는 아래와 같은 화면이 필요합니다.

• 시작 또는 홈 화면

• 회원가입 화면

• 로그인 화면

• 글 목록 화면

• 글 상세 화면

• 글 작성 화면

• 글 수정 화면

• 검색 결과를 확인할 수 있는 화면 또는 목록 내 검색 상태

여기서 중요한 것은 "화면 수를 늘리는 것"이 아니라 "핵심 기능이 끊기지 않게 연결되는가"입니다. 예를 들어 검색 결과를 굳이 별도 페이지로 만들지 않고, 글 목록 화면 안에서 검색창과 결과를 함께 보여줄 수도 있습니다. 그러면 구현은 더 단순해집니다.

초보자에게는 이런 단순화가 아주 중요합니다. 화면이 하나 줄면 그만큼 상태 관리도 줄고, 예외 처리도 줄고, AI에게 요청할 범위도 선명해집니다.

PRD 초안은 이렇게 쓰면 된다

이제 실제로 작은 PRD 초안의 형태를 만들어봅시다. 아래 형식은 초보자가 쓰기 좋은 아주 실용적인 틀입니다. 너무 멋지게 쓰지 않아도 됩니다. 중요한 것은 내가 읽어도 이해되고, AI에게 보여줘도 방향이 전달되는 것입니다.

1. 서비스 한 줄 설명

먼저 서비스의 정체를 한 줄로 적습니다.

자주 떠오르는 생각과 메모를 저장하고, 나중에 검색으로 다시 찾을 수 있게 돕는 개인 기록 웹 서비스.

이 한 줄은 이전 장에서 만든 문장을 가져와 조금 다듬으면 됩니다. 여기서는 광고 문구보다 작업 기준에 더 가깝게 쓰는 편이 좋습니다.

2. 핵심 사용자

누가 쓰는지도 적어둡니다.

업무나 공부 중 떠오른 내용을 자주 기록하지만, 메모가 여러 곳에 흩어져 나중에 다시 찾기 어려운 사람.

이 문장이 있어야 기능 우선순위를 정할 때 흔들리지 않습니다. 예를 들어 이 사용자에게 중요한 것은 귀여운 배지 시스템보다 빠른 저장과 쉬운 검색입니다.

3. 사용자의 핵심 문제

이제 사용자가 무엇 때문에 불편한지 적습니다.

메모를 남겨도 노트 앱, 메신저, 문서 파일 등에 흩어져 저장되어 다시 찾기 어렵다. 그래서 기록은 하지만 회수가 잘 되지 않는다.

이 문장은 서비스가 해결해야 할 중심 문제입니다. 기능은 모두 이 문제를 향해 모여야 합니다.

4. 첫 버전의 목표

여기서는 "이번 버전에서 어디까지 되면 성공인가"를 적습니다.

사용자가 회원가입 후 로그인하고, 자신의 글을 작성·수정·삭제할 수 있으며, 목록과 상세 화면에서 글을 확인하고, 키워드로 검색해 원하는 글을 다시 찾을 수 있게 한다.

보면 아주 구체적이지만 과하지는 않습니다. 첫 버전의 성공 기준으로 딱 좋습니다.

5. 필수 기능

이제 핵심 기능을 적습니다.

• 회원가입

• 로그인과 로그아웃

• 내 글 작성

• 내 글 목록 보기

• 글 상세 보기

• 글 수정

• 글 삭제

• 제목 또는 본문 기준 검색

이 목록을 적을 때는 "한 문장으로 설명 가능한 기능" 단위로 쓰는 것이 좋습니다. 너무 잘게 쪼개면 복잡해지고, 너무 크게 뭉치면 구현할 때 애매해집니다.

6. 이번 버전에서 제외할 기능

이 부분이 아주 중요합니다. 넣지 않을 기능도 적어야 합니다.

• 댓글

• 좋아요

• 다른 사용자 팔로우

• 공개 프로필 페이지 꾸미기

• 실시간 알림

• 파일 첨부

• AI 자동 요약

• 관리자 대시보드

이렇게 적어두면 개발 중간에 마음이 흔들릴 때 도움이 됩니다. "좋은 아이디어지만 지금은 안 한다"라고 말할 근거가 생깁니다.

7. 필요한 화면

이제 화면을 적습니다.

• 홈 화면

• 회원가입 화면

• 로그인 화면

• 글 목록 화면

• 글 상세 화면

• 글 작성 화면

• 글 수정 화면

여기서 검색은 별도 화면이 아니라 글 목록 화면 안에서 처리할 수도 있습니다. 이런 결정도 PRD에 간단히 적어두면 좋습니다.

예를 들면 이렇게 쓸 수 있습니다.

"검색은 글 목록 화면 상단 검색창에서 처리하며, 검색 결과는 같은 화면의 목록에 반영한다."

한 줄이지만 아주 실용적인 결정입니다.

8. 기능별 간단한 완료 기준

AI와 협업할 생각이라면 이 부분이 특히 유용합니다. 각 기능이 "어느 상태면 끝난 것인지"를 짧게 적어두는 것입니다.

예를 들어 이렇게 적을 수 있습니다.

• 회원가입: 이메일과 비밀번호로 계정을 만들 수 있다.

• 로그인: 등록된 계정으로 로그인할 수 있다.

• 글 작성: 로그인한 사용자가 제목과 본문을 저장할 수 있다.

• 글 목록: 로그인한 사용자는 자신의 글 목록을 볼 수 있다.

• 글 상세: 목록에서 글을 눌러 상세 내용을 볼 수 있다.

• 글 수정: 작성한 글의 제목과 본문을 바꿔 저장할 수 있다.

• 글 삭제: 작성한 글을 삭제할 수 있다.

• 검색: 입력한 키워드로 제목 또는 본문에 포함된 글을 찾을 수 있다.

이 정도만 정리해도 개발이 훨씬 쉬워집니다. AI에게도 "이 기준을 만족하도록 구현해줘"라고 말할 수 있기 때문입니다.

PRD가 있으면 AI에게 어떻게 더 잘 시킬 수 있을까

이 장의 핵심 중 하나는 이것입니다. AI는 요구사항이 선명할수록 더 좋은 결과를 낸다.

예를 들어 두 요청을 비교해봅시다.

첫 번째 요청은 이렇습니다.

"메모 서비스 만들어줘."

이 말은 너무 넓습니다. 메모 서비스라고 해도 공개형인지 개인용인지, 로그인 있는지 없는지, 검색이 중요한지, 디자인이 단순한지 화려한지 알 수 없습니다.

두 번째 요청은 이렇습니다.

"개인 기록 웹 서비스의 첫 버전을 만들고 싶어. 핵심 사용자는 메모가 흩어져 다시 찾기 어려운 사람이고, 이번 버전의 필수 기능은 회원가입, 로그인, 글 작성, 목록, 상세, 수정, 삭제, 검색이야. 댓글, 좋아요, 파일 업로드는 이번 버전에서 제외해. 먼저 필요한 화면과 라우트 구조를 제안해줘."

둘 중 어떤 요청이 더 좋은 결과를 낼지는 너무 분명합니다.

PRD는 단지 기획 문서가 아닙니다. AI와 대화할 때 쓰는 기준 문서이기도 합니다. 나중에 Claude Code나 Codex에게 일을 맡길 때, 이 문서가 있으면 요청이 훨씬 또렷해집니다.

초보자가 자주 하는 PRD 실수

처음 PRD를 만들 때 흔히 하는 실수도 미리 알아두면 좋습니다.

첫 번째 실수는 기능을 너무 많이 넣는 것입니다. "어차피 언젠가 넣을 건데 미리 써두자"라는 마음으로 이것저것 넣다 보면, PRD가 아니라 거대한 희망 목록이 됩니다.

두 번째 실수는 너무 추상적으로 쓰는 것입니다. 예를 들어 "사용자 경험을 향상시킨다", "생산성을 높인다" 같은 말은 그럴듯하지만, 실제 구현으로 이어지기 어렵습니다. 대신 "글을 저장하고 다시 찾을 수 있게 한다"처럼 행동이 보이게 써야 합니다.

세 번째 실수는 제외 기능을 안 적는 것입니다. 이것은 생각보다 흔합니다. 하지만 "안 할 일"을 안 적어두면, 개발은 계속 옆으로 퍼집니다.

네 번째 실수는 화면 없이 기능만 적는 것입니다. 기능만 있으면 머릿속에서 둥둥 떠다닙니다. 화면까지 적어야 비로소 사용 장면이 보입니다.

다섯 번째 실수는 완료 기준이 없는 것입니다. "글 관리 기능"이라고만 쓰면 어디까지가 끝인지 모릅니다. 작성, 수정, 삭제, 목록, 상세처럼 쪼개고, 각 기능이 어느 상태면 완료인지 적어두는 편이 좋습니다.

이 책의 실습 서비스용 PRD 초안 예시

이제 앞에서 설명한 내용을 하나로 모아, 실제로 쓸 수 있는 작은 PRD 초안 예시를 만들어보겠습니다.

서비스 이름

개인 기록 웹 서비스

한 줄 설명

자주 떠오르는 생각과 메모를 저장하고, 나중에 검색으로 다시 찾을 수 있게 돕는 웹 서비스.

핵심 사용자

업무나 공부 중 떠오른 내용을 자주 기록하지만, 메모가 여러 곳에 흩어져 다시 찾기 어려운 사람.

핵심 문제

기록은 하지만 정리와 회수가 어려워 필요한 내용을 제때 찾지 못한다.

첫 버전 목표

사용자가 계정을 만들고 로그인한 뒤, 자신의 글을 작성·수정·삭제하고 목록과 상세로 확인하며 검색할 수 있게 한다.

필수 기능

• 회원가입

• 로그인/로그아웃

• 글 작성

• 글 목록 조회

• 글 상세 조회

• 글 수정

• 글 삭제

• 제목 또는 본문 검색

제외 기능

• 댓글

• 좋아요

• 팔로우

• 공개 프로필

• 실시간 알림

• 파일 업로드

• AI 요약

• 관리자 기능

필요한 화면

• 홈 화면

• 회원가입 화면

• 로그인 화면

• 글 목록 화면

• 글 상세 화면

• 글 작성 화면

• 글 수정 화면

간단한 완료 기준

• 사용자는 이메일과 비밀번호로 가입할 수 있다.

• 가입한 사용자는 로그인할 수 있다.

• 로그인한 사용자는 글을 작성할 수 있다.

• 로그인한 사용자는 자신의 글 목록을 볼 수 있다.

• 목록에서 특정 글을 눌러 상세 내용을 볼 수 있다.

• 작성한 글은 수정할 수 있다.

• 작성한 글은 삭제할 수 있다.

• 검색창에서 키워드를 입력해 관련 글을 찾을 수 있다.

이 정도면 이미 아주 훌륭한 초안입니다. 페이지 수로는 길지 않지만, 실제 구현을 시작하기에는 충분히 강합니다.

PRD는 완벽해야 하는 것이 아니라 업데이트 가능해야 한다

여기서 안심해도 되는 점이 하나 있습니다. PRD는 처음 쓴 그대로 영원히 고정되는 문서가 아닙니다. 실제로 만들다 보면 조금씩 바뀔 수 있습니다.

예를 들어 처음에는 검색을 제목만 대상으로 하려 했는데, 써보니 본문 검색도 꼭 필요하다고 느낄 수 있습니다. 혹은 글 수정 화면을 별도 페이지로 만들려 했지만, 구현 단순화를 위해 작성 화면을 재사용하는 쪽이 더 낫다고 판단할 수도 있습니다.

괜찮습니다. 오히려 그런 수정은 건강한 일입니다.

중요한 것은 아무 기준 없이 흔들리는 것이 아니라, 기준이 있는 상태에서 더 나은 방향으로 조정하는 것입니다. PRD가 있으면 수정도 훨씬 덜 혼란스럽습니다.

지금 단계에서 꼭 정리해두면 좋은 한 문장

PRD를 다 쓴 뒤에는 마지막으로 이 문장을 적어두면 좋습니다.

"우리는 첫 버전에서 작은 완성을 목표로 하며, 핵심 사용자 문제를 해결하는 기능만 우선 구현한다."

이 문장은 생각보다 강력합니다. 기능 욕심이 올라올 때, 새 아이디어가 계속 튀어나올 때, AI가 너무 많은 것을 한 번에 제안할 때도 다시 중심을 잡아줍니다.

첫 서비스는 거대한 성이 아니라, 비를 막아주는 작은 집을 짓는 일에 가깝습니다. 작아도 문이 열리고, 창문이 있고, 사람이 들어가 쉴 수 있으면 이미 훌륭합니다. 그리고 그 작은 집이 있어야 다음 확장도 가능합니다.

이 장에서 꼭 기억할 것

서비스를 만들기 전에 기능과 화면을 정리하는 일은 귀찮은 준비 작업이 아닙니다. 오히려 개발을 쉽게 만드는 가장 현실적인 준비입니다.

PRD는 거창한 문서가 아니라, 무엇을 만들고 무엇은 아직 만들지 않을지 정리하는 작업 기준입니다. 특히 초보자에게는 필수 기능, 제외 기능, 필요한 화면을 구분하는 것만으로도 개발 난도가 크게 내려갑니다.

그리고 AI와 협업할수록 이 작업의 가치는 더 커집니다. AI는 막연한 요청보다 선명한 요구사항에 훨씬 잘 반응합니다. 결국 좋은 결과는 좋은 지시에서 나오고, 좋은 지시는 좋은 정리에서 나옵니다.

이제 우리는 아이디어와 사용자에 이어, 첫 버전의 기능과 화면까지 정리했습니다. 다음 장에서는 이 내용을 바탕으로, 사용자가 실제로 어떤 순서로 서비스를 이용하는지 사용자 흐름을 그려보겠습니다.