PRD 와 FS

1. PRD (Product Requirements Document)

제품요구사항문서

정의

• 만들려는 제품이 무엇을 해야 하는지 를 정의한 문서
• “왜 만드는가"와 “무엇을 만드는가"에 답한다
• 기술 용어 없이, 업무를 아는 사람이면 읽고 판단할 수 있는 수준으로 쓴다

담기는 내용

역할

• 방향을 고정: 문서가 없으면 요청할 때마다 다른 앱이 나온다
• 판단 기준: “이 기능 넣을까?” → PRD의 목적에 맞는지로 결정
• 합의 도구: 현업/팀장과 만들기 전에 말을 맞춘다

2. FS (Functional Specification, 기능명세서)

정의

• PRD를 실제 개발 가능한 단위 로 구체화한 문서
• “어떻게 만드는가"에 답.
• 화면마다 어떤 버튼·입력창이 있고 무엇을 하는지까지 적는다

담기는 내용

역할

• 번역기 역할: 사람의 요구사항을 AI/개발자가 바로 옮길 수 있는 형태로
• 되묻기를 없앤다: 애매한 부분을 미리 결정해 두어 작업이 끊기지 않는다
• 누락을 막는다: 권한 매트릭스로 “관리자만 되는 기능"이 새는 사고 방지
• 자주 바뀐다: 화면·기능이 추가될 때마다 갱신

3. 둘의 관계

현업의 요구  →  [ PRD ]  →  [ FS ]  →  프롬프트  →  앱
                무엇을·왜    어떻게      제작 요청     결과

순서를 지켜야 하는 이유

1. PRD 없이 FS부터 쓰면 → 목적과 무관한 기능이 정교하게 만들어진다
2. FS 없이 PRD만 주면 → AI가 빈칸을 제멋대로 채운다
3. 그래서 항상 PRD 먼저, FS 나중

4. 예를 들어.

PRD = 신제품 기획서

20~30대 타깃, 도수 12도, 달지 않은 탄산 막걸리. 여름 성수기 출시, 편의점 유통, 500ml 페트. 기존 제품은 너무 달아서 젊은 층이 외면한다.

• 마케팅팀도, 영업팀도 읽고 “이 술 낼지 말지"를 판단할 수 있다
• 그러나 이것만 들고 양조장에 가면 아무도 술을 담글 수 없다

FS = 배합비 · 공정표

멥쌀 100kg, 누룩 8kg, 물 130L. 1차 발효 24℃ 3일 → 2차 발효 22℃ 4일. 여과: 규조토 여과 후 살균. 탄산 주입 2.2 vol, 최종 당도 8 Brix.

• 양조 담당자가 그대로 따라 하면 같은 술이 나온다
• 그러나 이것만 보면 “왜 이 술을 만드는지"는 알 수 없다

정리

기획서만 주고 “술 담가"라고 하면 아무도 못 만든다. 배합비만 주면 왜 이 술인지 아무도 모른다. 둘 다 있어야 같은 술이 매번 나온다.

1. LLM 과 PRD 작성 대화 하기

왜 대화부터 시작하는가

• 내게 꼭 맞고 정확한 PRD 문서를 위해서는 충분한 정보를 제공해야 합니다.
• 혼자 고민하면 놓치는 것이 많고, 전문 영역(보안, 권한 설계, 법적 요건)의 지식이 부족합니다.
• LLM은 “빠진 질문을 대신 던져주는 역할"을 할 때 가장 유용합니다. 답을 받아쓰는 도구가 아니라 *인터뷰어*로 쓰세요.

대화에서 반드시 다뤄야 할 항목

• 배경/문제: 지금 무엇이 불편한가? 현재는 어떻게 처리하고 있는가?
• 사용자(행위자): 관리자, 일반회원, 비로그인 방문자 등. 각자 무엇을 하려고 오는가?
• 핵심 기능 3가지: 이것이 없으면 앱이 성립하지 않는 기능. 나머지는 후순위로 미룹니다.
• 데이터: 무엇을 저장하는가? 누가 보고, 누가 수정하는가?
• 제약: 예산, 기한, 예상 사용자 수, 모바일/PC 우선순위
• 성공 기준: “무엇이 되면 성공인가"를 숫자나 문장으로 정의

대화 시작 프롬프트 예시

나는 [○○ 업무]를 하는 사람이고, [○○ 문제] 때문에 앱을 만들려고 한다. 바로 문서를 쓰지 말고, PRD 작성에 필요한 정보를 얻기 위해 나에게 한 번에 3개씩 질문해 줘. 내가 놓치고 있을 만한 부분도 지적해 줘.

PRD 문서 생성

• 대화가 끝나면 앱의 설계도인 PRD 문서를 생성합니다.
• 권장 목차:
  1. 개요 / 한 줄 소개
  2. 문제 정의와 배경
  3. 목표와 성공 지표
  4. 사용자 유형(행위자)과 각자의 시나리오
  5. 기능 목록 (우선순위 표기: 필수 / 권장 / 추후)
  6. 범위 밖(Out of Scope) — 이 항목이 매우 중요합니다
  7. 화면 구성 개요
  8. 제약 조건과 가정
• 파일 형식: Markdown (prd.md)

FS 문서 생성

• 대화내용 기반으로 LLM 에게 작성 요청합니다
• PRD를 첨부하고, 기술적 구현 방법을 정의하는 FS 문서를 작성합니다.
• 권장 목차:
  1. 기술 스택 (예: React + Firebase)
  2. 데이터 모델 — 컬렉션/필드/타입/관계
  3. 인증과 권한 규칙 (행위자별 CRUD 권한 표)
  4. 화면별 상세 명세 — 입력값, 검증 규칙, 에러 처리
  5. 화면 이동 흐름(라우팅)
  6. 외부 연동 (이메일, 결제, 파일 업로드 등)
  7. 예외 상황 처리 (네트워크 오류, 권한 없음, 빈 데이터 상태)
• 파일 형식: Markdown (fs.md)

문서 품질 점검

• 필요하면 작성된 문서를 다시 LLM에 넣고 검토를 요청합니다.

이 PRD와 FS에서 모순되는 부분, 정의가 빠진 부분, 구현 시 애매해질 문장을 찾아서 수정해줘

• 스스로 읽으며 확인: “제3자가 이 문서만 보고 같은 앱을 만들 수 있는가?”

2. PRD, FS 를 이용한 앱 제작

입력 자료 준비

• 첨부파일로 PRD, FS 문서를 제공합니다.
• 기타 추가 데이터로 사용할 수 있는 자료를 함께 제공합니다.
  • 샘플 데이터(CSV, 엑셀)
  • 로고, 색상 코드, 폰트
  • 참고 디자인 스크린샷
  • 기존에 쓰던 문서 양식

1차 제작 프롬프트 구성

• 제작 배경·의도, 사용 언어, 디자인 방향을 함께 명시해 1차 제작을 진행합니다.
• 프롬프트에 포함할 요소:
  • 배경과 의도 (왜 만드는지)
  • UI 표시 언어 (예: 한국어)
  • 디자인 톤 (예: 깔끔한 화이트 기반, 모바일 우선, 큰 글씨)
  • 기술 스택 지정
  • “PRD/FS에 없는 기능은 임의로 추가하지 말 것” 같은 제약

단계적 제작 요령

• 한 번에 전체를 만들려 하면 오류 추적이 어렵습니다. 순서를 나누세요.
  1. 데이터 구조와 기본 화면 골격
  2. 인증(로그인/회원가입)
  3. 핵심 기능 1개 완성 → 동작 확인
  4. 나머지 기능 순차 추가
• 각 단계마다 실제로 눌러보고 넘어갑니다. 동작 확인 없이 다음 기능을 쌓지 않습니다.

버전 보관

• 정상 동작하는 시점마다 코드를 내려받아 보관하거나 Git에 커밋합니다.
• 다음 수정에서 망가졌을 때 되돌아갈 지점이 있어야 합니다.

3. Firebase 설정

프로젝트 생성

• Firebase 콘솔에서 새 프로젝트 생성 → 앱(웹) 등록 → 설정 키(config) 복사
• 키를 코드에 붙여넣고 연결 확인

Authentication (인증)

• 사용할 로그인 방식 활성화: 이메일/비밀번호, Google 로그인 등
• 승인된 도메인(Authorized domains)에 배포 주소 추가

Firestore Database

• 데이터베이스 생성 (위치는 asia-northeast3 서울 권장)
• FS 문서의 데이터 모델대로 컬렉션 구조 생성
• 처음에는 테스트 모드로 시작하되, 반드시 배포 전에 보안 규칙을 잠급니다

Storage (파일 업로드가 있다면)

• 이미지·문서 업로드 경로 규칙 정의
• 파일 크기·확장자 제한 설정

보안 규칙 (Security Rules)

• 가장 자주 빠뜨리는 단계입니다. “화면에서 안 보이는 것"과 “접근이 막힌 것"은 다릅니다.
• 최소 원칙:
  • 로그인하지 않으면 읽기/쓰기 불가
  • 본인 데이터만 수정 가능
  • 관리자 전용 컬렉션은 관리자 계정만 접근
• 규칙 작성 프롬프트 예시:

FS 문서의 권한 표에 맞는 Firestore 보안 규칙을 작성해 줘. 각 규칙이 어떤 요구사항에 대응하는지 주석으로 설명해 줘.

연결 점검 체크리스트

• 회원가입 시 Authentication에 사용자 생성되는가
• 동시에 Firestore에 사용자 문서가 만들어지는가
• 데이터 저장/조회/수정/삭제가 모두 동작하는가
• 로그아웃 상태에서 데이터에 접근하면 차단되는가

4. 테스트용 ID 가입

목적

• 실제 사용자와 동일한 경로로 가입해 보며 흐름의 빈틈을 찾습니다.

준비할 계정

• 관리자 계정 1개
• 일반회원 계정 2개 이상 (A가 B의 데이터를 볼 수 있는지 확인하려면 최소 2개 필요)
• 가능하면 권한별로 1개씩 추가

확인 사항

• 가입 폼 검증 (빈 값, 잘못된 이메일, 짧은 비밀번호)
• 중복 이메일 가입 시 안내 메시지
• 가입 직후 자동 로그인 또는 로그인 화면 이동
• 로그아웃 후 재로그인
• 비밀번호 재설정 메일 수신

테스트 계정 관리

• 계정 정보를 별도 문서에 정리해 둡니다 (이메일, 비밀번호, 역할, 용도).
• 실제 개인 이메일 대신 별칭 주소(이름+test1@gmail.com)를 쓰면 관리가 편합니다.

5. 관리자 설정

관리자 지정 방식

• Firestore 사용자 문서에 role: "admin" 같은 필드를 두는 방식이 가장 단순합니다.
• 첫 관리자는 Firebase 콘솔에서 직접 필드를 수정해 지정합니다.
• 주의: 클라이언트에서 role을 바꿀 수 있으면 안 됩니다. 보안 규칙으로 role 필드 수정을 차단하세요.

관리자 화면 구성

• 접근 경로: 별도 /admin 라우트 또는 메뉴 노출 제어
• 기본 구성:
  • 회원 목록 / 검색 / 상태 변경
  • 콘텐츠·데이터 관리 (등록/수정/삭제)
  • 통계 요약 (가입자 수, 등록 건수 등)
  • 공지·설정 관리

확인 사항

• 일반회원이 /admin 주소를 직접 입력하면 차단되는가
• 관리자 메뉴가 일반회원 화면에 노출되지 않는가
• 관리자가 자기 자신의 관리자 권한을 실수로 해제할 수 없는가

6. 행위자별 기능테스트 (관리자)

테스트 방법

• FS 문서의 기능 목록을 그대로 체크리스트로 변환해 하나씩 눌러봅니다.
• 결과를 표로 기록: 기능 / 기대 동작 / 실제 동작 / 통과 여부 / 비고

점검 항목

• 회원 조회·검색·정렬·필터
• 회원 상태 변경 (승인, 정지, 삭제)
• 데이터 등록 / 수정 / 삭제
• 삭제 시 확인 창이 뜨는가 (실수 방지)
• 통계 수치가 실제 데이터와 일치하는가
• 잘못된 입력값을 넣었을 때 에러 처리
• 목록이 비었을 때의 화면 (빈 상태 안내)
• 데이터가 많을 때의 화면 (페이지네이션, 성능)

수정 요청 요령

• 문제를 발견하면 한 번에 하나씩, 구체적으로 요청합니다.

관리자 회원 목록에서 ‘정지’ 버튼을 누르면 상태는 바뀌지만 목록이 새로고침되지 않는다. 상태 변경 후 목록이 즉시 갱신되도록 수정해 줘.

7. 행위자별 기능테스트 (일반회원)

점검 항목

• 가입 → 로그인 → 주요 기능 사용까지 한 번에 이어지는가
• 본인 데이터 등록 / 조회 / 수정 / 삭제
• 다른 회원의 데이터에 접근할 수 없는가 (URL 직접 입력으로도 시도해 볼 것)
• 관리자 전용 기능이 보이지 않고 접근도 안 되는가
• 프로필 수정, 비밀번호 변경
• 회원 탈퇴 시 데이터 처리

환경 테스트

• 모바일 화면 (실제 휴대폰에서)
• PC 브라우저 (Chrome, Safari, Edge)
• 느린 네트워크에서의 로딩 표시
• 새로고침 후 로그인 상태 유지

사용성 점검

• 처음 보는 사람이 설명 없이 목적을 달성할 수 있는가
• 버튼 이름이 실제 동작과 일치하는가
• 작업 완료 후 “됐다"는 신호(토스트, 메시지)가 있는가

8. 세부 디자인 마무리

정리 대상

• 색상: 주색상 / 보조색 / 경고색을 정하고 전체에 일관 적용
• 폰트: 크기 단계(제목/본문/설명)를 3~4개로 통일
• 여백: 요소 간 간격 규칙 통일
• 버튼: 주요 동작(Primary)과 보조 동작(Secondary) 구분

놓치기 쉬운 화면

• 로딩 중 화면
• 데이터가 없을 때(빈 상태) 화면
• 에러 발생 화면
• 404 / 권한 없음 화면
• 로그인 전 첫 화면

마무리 항목

• 앱 아이콘, 파비콘
• 브라우저 탭 제목
• 모바일 반응형 최종 확인
• 오탈자 전수 점검

9. 더미데이터 삭제

목적

• 테스트용으로 추가했던 더미 데이터와 사용자 정보를 삭제합니다.
• 실제 사용자가 들어왔을 때 남의 테스트 데이터가 보이면 신뢰를 잃습니다.

진행 절차

1. 삭제 전 현재 상태를 백업 (Firestore 내보내기 또는 스크린샷)
2. Firestore 문서 삭제
3. Authentication 사용자 계정 삭제
4. Storage에 올린 테스트 파일 삭제
5. 코드 안에 하드코딩된 샘플 데이터 제거

프롬프트 예시

더 안전한 형태:

컬렉션 구조와 필드 정의, 보안 규칙은 그대로 두고 테스트용으로 넣은 문서 데이터와 사용자 계정만 삭제해

주의

• 관리자 계정 1개는 남겨두어야 합니다. 전부 지우면 다시 들어갈 수 없습니다.
• 삭제 후 앱이 정상 동작하는지 재확인 (빈 데이터 상태에서 오류가 나는 경우가 많습니다).

10. 베타 테스트

진행 방식

• 주변에 공유해서 일정 기간 테스트 사용 기간을 갖습니다.
• 권장 규모: 510명, 기간 12주
• 가능하면 실제 목표 사용자와 유사한 사람을 섭외합니다.

테스터에게 전달할 것

• 접속 주소
• 앱의 목적 한 줄 설명
• “이것만 해봐 주세요” 형태의 과제 2~3개
• 피드백 제출 방법 (구글 폼 권장)

피드백 수집 양식 예시

• 어떤 화면에서 / 무엇을 하려다 / 무슨 일이 일어났는가
• 기대했던 결과는 무엇이었는가
• 사용 기기와 브라우저
• 불편함 정도 (1~5점)

반영 원칙

• 피드백을 받아 해당 내용을 반영·수정합니다.
• 모든 의견을 다 반영하지 않습니다. 분류하세요.
  • 즉시 수정: 오류, 데이터 손실, 접근 차단 실패
  • 배포 전 수정: 사용성 문제, 문구 혼동
  • 다음 버전: 새 기능 제안
• 여러 명이 같은 지점에서 막혔다면 그것은 사용자 문제가 아니라 설계 문제입니다.

11. 최종 검토

기능

• PRD의 필수 기능이 모두 구현되었는가
• 베타 피드백 중 ‘즉시 수정’ 항목이 모두 처리되었는가
• 각 행위자 시나리오를 처음부터 끝까지 한 번씩 재실행

보안

• Firestore/Storage 보안 규칙이 테스트 모드가 아닌가
• API 키가 공개 저장소에 노출되지 않았는가
• 로그아웃 상태 / 타 계정에서 데이터 접근 시도 차단 확인
• 관리자 권한 상승이 불가능한가

데이터

• 더미 데이터 완전 삭제 확인
• 백업 방법 확보

운영 준비

• 개인정보 처리방침 / 이용약관 (회원가입을 받는다면 필요)
• 문의 연락처
• 오류 발생 시 확인할 수 있는 경로(콘솔, 로그)

12. 배포

배포 절차

1. 프로덕션 빌드 생성
2. 호스팅에 배포 (Firebase Hosting, Vercel 등)
3. Firebase 승인된 도메인 목록에 배포 주소 추가
4. 실제 배포 주소에서 전체 흐름 재테스트 (로컬에서 되던 것이 안 되는 경우가 흔합니다)

배포 직후 확인

• 회원가입 → 로그인 → 핵심 기능 1회 완주
• 모바일에서 접속 확인
• 링크 공유 시 미리보기 정상 표시

배포 후 운영

• 초기 며칠은 매일 데이터와 오류를 확인합니다.
• 사용자 문의 창구를 열어둡니다.
• 수정이 필요할 때는 코드부터 고치지 말고 *PRD/FS 문서를 먼저 갱신*합니다. 문서가 최신이어야 다음 수정도 LLM에게 맡길 수 있습니다.

부록

A. 자주 겪는 문제

B. 문서 버전 관리

• docs/prd-v1.md, docs/prd-v2.md 형태로 버전을 남깁니다.
• 변경 시 날짜와 변경 사유를 문서 상단에 기록합니다.
• 기능 추가 요청 시 최신 PRD/FS를 다시 첨부하면 LLM이 기존 맥락을 유지한 채 작업합니다.