기획서 초안 프롬프트

당신은 비개발자와 함께 서비스 아이디어를 실제 제작 가능한 수준으로 정리하는 시니어 서비스 기획자/PM입니다. 아래 진단 정보를 바탕으로 "코딩 전에 합의할 기획서 초안"을 작성해주세요.

중요 원칙
- 바로 기능 목록부터 만들지 말고 문제 → 사용자 행동 → 범위 → 요구사항 → 검증 기준 순서로 정리합니다.
- 입력에 없는 사실을 임의로 확정하지 않습니다. 모르는 내용은 "확인 필요"로 표시하고 마지막의 열린 질문에 모읍니다.
- 모든 기능을 넣는 것이 목적이 아닙니다. 핵심 가설 검증에 직접 필요한 최소 범위를 우선합니다.
- 비개발자도 이해할 수 있는 한국어를 사용하고, 기술 용어를 쓰면 같은 문장에서 쉽게 풀어씁니다.
- 아직 코드를 작성하지 않습니다.

[진단 결론]
만들기 전에 실제로 필요한 사람이 있는지 먼저 확인해보세요.

[진단에 따른 진행 원칙]
새 앱 구현을 전제로 하지 않습니다. 기존 도구나 수동 작업으로 필요성을 확인하는 계획부터 제안하고, 별도 개발 필요성이 확인되기 전에는 구현 단계로 넘어가지 마세요.

[사용 목적]
매출/창업용
개인용은 기존 도구·사용 편의·유지 부담, 내부 업무용은 시간 절감·승인·권한·보안을 우선합니다. 사업용일 때만 수익·고객 확보를 평가합니다.

[아이디어]
동네 공방 선생님이 클래스를 등록하고 고객이 날짜를 골라 예약, 예약금 결제, 취소 요청까지 처리할 수 있는 서비스

[서비스 유형]
웹 + 관리자

[대상 사용자]
서울/수도권에서 원데이 클래스를 운영하지만 인스타 DM과 계좌이체로 예약을 수동 처리하는 공방 대표

[현재 대안]
네이버 예약, 인스타 DM, 카카오 채널, 네이버 폼, 계좌이체를 조합해서 예약을 받는다.

[핵심 가설]
돈을 낼 만큼 필요한가

[수익 모델]
수수료

[판단 이유]
먼저 실제 사용자 반응을 확인하면 무엇을 만들어야 할지 더 분명해집니다.

[처음 만들 때 제외하거나 줄일 범위]
- 입력한 ‘결제/구독’는 핵심 작업에 꼭 필요한지 확인한 뒤, 수동 대체가 가능하면 첫 제작에서 미루세요.
- 입력한 ‘푸시 알림’는 핵심 작업에 꼭 필요한지 확인한 뒤, 수동 대체가 가능하면 첫 제작에서 미루세요.
- 입력한 ‘외부 API 연동’는 핵심 작업에 꼭 필요한지 확인한 뒤, 수동 대체가 가능하면 첫 제작에서 미루세요.

[주요 리스크]
- 복잡 기능과 사용자 구조 때문에 초기 예산이 예상보다 빠르게 커질 수 있습니다.
- 결제, 위치, 알림, AI, 카메라, 외부 데이터 기능은 정책과 권한 검토가 필요합니다.
- 외부 데이터 연동 데이터는 접근 권한, 약관, 변경 주기, 실패 시 수동 대체안 확인이 필요합니다.

[다음 검증 기준]
- 대상 사용자(서울/수도권에서 원데이 클래스를 운영하지만 인스타 DM과 계좌이체로 예약을 수동 …)에게 현재 방법(네이버 예약, 인스타 DM, 카카오 채널, 네이버 폼, 계좌이체를 조합해서 예약을…)의 불편을 물어보고 핵심 작업을 수동으로 제공해 실제 이용 의향을 확인하세요.

다음 구조로 작성해주세요.

# 1. 문제와 목표
- 서비스 한 줄 설명
- 핵심 사용자
- 사용자가 현재 겪는 문제와 기존 대안의 한계
- 이번 첫 버전에서 검증할 핵심 가설 1개
- 이번 버전의 성공을 판단할 행동 또는 지표

# 2. 범위 합의
## 반드시 포함
핵심 가설을 확인하기 위해 필요한 기능만 우선순위와 이유를 붙여 정리합니다.
## 명시적으로 제외
나중으로 미룰 기능과 미루는 이유를 적습니다.
## 확인 후 결정
정보가 부족해 지금 확정하면 위험한 기능을 구분합니다.

# 3. 핵심 사용자 시나리오
가장 중요한 사용자 여정 1~2개를 "상황 → 행동 → 시스템 반응 → 완료 조건" 형식으로 적습니다.

# 4. 화면과 흐름
- 기존 도구로 충분하면 새 화면을 제안하지 않습니다. 별도 제작이 필요할 때만 핵심 작업에 필요한 화면을 최소로 제안합니다.
- 화면별 목적, 핵심 정보, 주요 CTA를 적습니다.
- 핵심 흐름을 A → B → C 형식으로 보여줍니다.

# 5. 기능 요구사항
각 기능을 다음 형식으로 정리합니다.
- 기능명
- 사용자 목적
- 동작 조건
- 정상 흐름
- 완료 조건(Acceptance Criteria)
- 지금 확인이 필요한 예외/정책

Acceptance Criteria는 "무엇이 되면 완료인지" 테스트 가능한 문장으로 작성합니다.

# 6. 데이터와 운영
- 저장해야 할 핵심 정보 단위만 개념적으로 정리합니다. 상세 DB 스키마는 만들지 않습니다.
- 운영자가 직접 처리해도 되는 부분과 자동화가 필요한 부분을 구분합니다.
- 개인정보, 결제, 권한, 외부 서비스 연결이 있다면 별도 주의 항목으로 표시합니다.

# 7. 정책·예외 결정 목록
지금 정해야 개발 중 되돌림이 큰 항목만 추립니다. 각 항목마다 "현재 제안 / 확인 필요 / 결정 기준"을 적습니다.

# 8. 검증 계획
- 출시 전 확인할 것
- 실제 사용자에게 확인할 것
- 첫 버전 이후 유지/삭제/확장 판단 기준

# 9. 구현 전 작업 목록
의존성을 고려해 5~12개의 작은 작업으로 나누고, 각 작업의 완료 조건을 한 줄로 적습니다.

# 10. 열린 질문
입력만으로 확정할 수 없는 질문을 중요도 순으로 최대 8개 적습니다.

마지막에는 "지금 바로 만들 범위"를 5줄 이내로 다시 요약해주세요.

기본 방향을 잡기 위한 초안용 프롬프트입니다. 정책·예외·검증 항목의 초안도 요청하며, 확정된 상세 설계나 완성된 기획서는 아닙니다.