다시 진단하기진단 결과 · 입력 기준으로 산출

제작 방식 진단좁힌 웹앱/MVP 제작

제작 방식 진단: 좁힌 웹앱/MVP 제작

결론: 서울/수도권에서 원데이 클래스를 운영하지만 ... 기준으로 전체 구축보다 첫 MVP와 운영 범위를 고정하는 것이 핵심입니다.

좁힌 웹앱/MVP 제작

창업/매출 목적이라도 전체 구축보다 첫 수익 행동과 운영 범위를 줄인 제작 방식이 우선입니다.

매출/창업용
핵심 화면 흐름을 빠르게 검토하는 데 적합하지만 실제 예약 운영 검증에는 한계가 있습니다.

필요 제작 범위

웹앱+관리자

관리자는 고객 화면보다 비용이 늦게 드러나는 영역입니다. 조회, 승인, 상태 변경까지만 1차 범위로 좁힙니다.

매출/창업용
M 범위로 추정

비용 경계

연동/데이터가 비용 핵심

300만-800만원는 확정 견적이 아니라 M 범위의 판단용 기준입니다. 견적 전 포함/제외 범위를 먼저 고정해야 합니다.

추천 알고리즘과 리뷰 커뮤니티는 1차 범위에서 제외합니다.
공급자인 강사 확보가 늦어지면 고객용 앱을 만들어도 거래가 발생하지 않을 수 있습니다.

증거/견적 기준

부족한 근거는 개발비를 쓰기 전 판단 기준입니다.

확정 견적이나 성공 보장이 아니라, 어떤 행동 증거와 제작 범위가 정리되면 다음 단계로 넘어갈 수 있는지 분리해서 봅니다.

증거 기준 v0.1

보강 필요

예약금/유료 파일럿

예약금/유료 파일럿 단계까지는 확인됐지만, 개발 판단에는 문의, 결제, 반복 사용 같은 더 강한 행동 증거가 필요합니다.

현재 증거

고객 인터뷰
경쟁/대체재 분석
테스트 매출 있음
전환율 데이터 있음

더 필요한 증거

첫 예약 결제 수
문의 전환율
재예약률
강사 공급 확보 가능성

다음 확보 기준

2주 내 유료 예약 5건
문의 전환율 5% 이상
강사 등록 완료 5명
예약 취소율과 재예약률 기록

외주 견적 기준 v0.1

M 첫 버전 외주 기준

전체 플랫폼을 완성하는 외주 견적이 아니라, 예약/결제/관리자 승인만 좁힌 첫 버전 기준입니다. 상세 정산, 리뷰, 추천, 고도화된 알림은 제외한 범위입니다.

예상 구간

300만-800만원

DB/백엔드

보통+

데이터 저장, 상태 변경, 권한과 서버 로직 범위입니다.

연동/QA

보통+

결제, 알림, 외부 API, 정책/예외 테스트 부담입니다.

기획/범위

보통+

요구사항, 화면 흐름, 제외 기능, 성공 기준을 고정합니다.

화면/프론트

보통+

사용자 화면과 기본 반응형 UI를 포함합니다.

관리자

보통+

승인, 조회, 상태 변경, 운영자 처리 화면입니다.

직접 먼저

핵심 화면 1개: 2주 내 유료 예약 5건
범위/제외 기능 문서: 추천 알고리즘과 리뷰 커뮤니티는 1차 범위에서 제외합니다.

포함

핵심 사용자 흐름
기본 화면 구현
기본 QA
배포 준비

제외

복잡한 환불/정산 정책 자동화
확정되지 않은 외부 API/데이터 연동
고급 통계/추천
정산 자동화

견적서 확인

화면 수 기준인지 기능 기준인지 산정 방식
결제, 알림, 외부 API, QA가 포함/제외로 명시되어 있는가
QA 범위와 무상 하자보수 기간
소스코드 소유권 이전 여부

개발 경계

AI로 시작할 범위와 검토할 경계를 분리합니다.

새 진단 엔진은 기존 판정을 대체하지 않고, 기능·조합 룰·설명 근거를 보조 판단으로 함께 보여줍니다.

엔진 추천 후보

기존 추천과 차이

새 진단 엔진이 현재 /result 추천과 다른 개발 경계를 제안합니다.

현재 /result는 좁힌 웹앱/MVP 제작, 엔진 후보는 먼저 검증입니다.

현재 /result 추천

좁힌 웹앱/MVP 제작

기존 scoring 기준

엔진 후보

먼저 검증

룰·매트릭스 기준

전환 실험

문구 실험 가능

상단 추천 미반영

아직 바로 개발로 가기에는 확인되지 않은 부분이 있어, 가장 작은 방식으로 반응을 먼저 봐야 합니다.

매칭된 기능

권한별 대시보드단순 결제구독/정기결제푸시 알림외부 API 조회

초기 MVP 기능 과다

초기 기능이 많으면 가장 중요한 가설이 흐려지고 개발 범위가 빠르게 커집니다.

상단 CTA는 기존 결과를 유지하되, 엔진 후보를 보조 검토 기준으로 봅니다.
매칭 기능: 권한별 대시보드, 단순 결제, 구독/정기결제, 푸시 알림, 외부 API 조회
조합 룰: 초기 MVP 기능 과다
추천 경로: validate_first

점수 시각화

판단에 영향을 준 축을 한눈에 봅니다.

문제 강도, 사업성, 제작 범위, 비용 리스크가 어느 쪽으로 기울어져 있는지 확인합니다.

점수 균형

점수 레이더

높은 점수와 낮은 점수의 차이를 보면, 지금 아이디어가 강한 부분과 보완할 부분이 드러납니다.

리스크 지도

비용과 검증 부담이 큰 지점을 찾습니다.

오른쪽으로 갈수록 비용 영향이 크고, 아래로 갈수록 먼저 확인해야 할 가능성이 큽니다.

차트 설명

비용 영향과 검증 부담을 좌표로 봅니다.

비용 영향 낮음비용 영향 높음먼저 확인 필요검증 부담

리스크 항목

결제/구독

결제는 취소, 환불, 상태 불일치, CS 기준까지 함께 생겨 처음부터 넣으면 비용과 QA 범위가 커질 수 있습니다.

예상 비용 영향

높음

초기 범위에 포함하면 비용 추정이 커질 수 있는 정도입니다.

예상 기간 영향

보통+

기획, 구현, QA와 예외 처리까지 포함한 영향입니다.

지금 아이디어에 맞는 제작 순서를 봅니다.

AI로 직접 시작할지, 범위를 정리할지, 기술 확인이나 외주 준비가 먼저인지 판단합니다.

2단계추천 단계

기획서 초안으로 기능 범위 정리

1차 기능, 제외 기능, 사용자 흐름, 운영 정책을 문서로 고정합니다.

기획서 초안 보기

상세 분석

판단에 영향을 준 근거를 나눠 봅니다.

목적별 판단 기준, 대체재, 개발비 증가 요인, 기술 리스크를 분리해 왜 이런 판정이 나왔는지 확인합니다.

수익이 생길 지점이 있을까?

반응과 지불 의향을 더 확인해야 합니다.

사업성 점수 68점

고객 인터뷰 진행 중

테스트 매출 있음

반복 예약률과 재구매율은 아직 확인되지 않았습니다.

차별성을 높일 단서를 찾습니다.

비슷한 서비스와 사용자가 이미 쓰는 대안을 비교해, 우리 서비스가 더 명확하게 보여줘야 할 강점과 보완점을 찾습니다.

직접 경쟁 서비스

클래스 예약 앱, 취미/원데이 클래스 플랫폼

쓰는 이유고객이 클래스를 찾고 강사가 예약과 결제를 받는 전체 흐름을 해결합니다.

강점이미 탐색, 예약, 결제 경험이 갖춰져 있어 고객 신뢰를 얻기 쉽습니다.

빈틈지역/카테고리별 작은 공방의 운영 방식까지 세밀하게 맞추기는 어렵습니다.

우리의 기회특정 지역과 공방 유형에 좁게 들어가 강사 운영 편의를 더 잘 해결할 수 있습니다.

확인 질문: 강사가 기존 플랫폼 수수료나 운영 방식 때문에 다른 도구를 쓸 의향이 있나요?

다음 단계 시작

기능 범위와 실행 문서로 이어갑니다.

진단 결과를 바탕으로 시장·대체재 조사, 기획서 초안, 기술/금액 산정표, ManyFast/Codex용 시작 프롬프트까지 바로 이어갈 수 있습니다.

MVP 기능 범위 만들기

처음 만들 기능과 나중에 만들 기능을 나눠 개발 의뢰 가능한 범위로 정리합니다.

기술/금액 산정표

GPT, 노션, 웹앱, 앱, 관리자, 결제 중 무엇이 필요하고 어디서 비용이 커지는지 정리합니다.

ManyFast용 기획 입력 프롬프트

기획 초안으로 이어질 핵심 입력값을 압축합니다.

PoC 체크리스트 만들기

기술과 데이터가 막힐 수 있는 지점을 먼저 확인합니다.

시장·대체재 조사 결과 보기

개발 필요성, 대체재, 확인 질문을 먼저 정리합니다.

처음엔 여기까지만

추천 알고리즘과 리뷰 커뮤니티는 1차 범위에서 제외합니다.
정산 자동화는 수동 운영 후 반복 업무가 확인되면 추가합니다.
관리자 기능은 승인, 예약 상태 변경, 기본 조회만 남깁니다.

개발자에게 물어볼 것

결제/환불/정산: 실제 결제를 넣기 전 개발자와 QA/CS 책임 범위를 문서화합니다.
관리자/권한: 관리자 기능이 3개 이상이면 견적서에 화면 수와 권한 범위를 따로 적습니다.
외부 연동/알림: 실제 운영 데이터가 필요한 순간부터 개발자 검토 범위로 넘깁니다.
1차 버전에서 결제/구독, 푸시 알림을 제외할 수 있나요?

내가 만든다면

핵심 화면 1개: 랜딩, 신청, 예약, 문의 중 돈/시간을 아끼는 핵심 흐름 1개만 Mock이나 AI 테스트 버전으로 만듭니다.
범위/제외 기능 문서: 처음 만들 기능, 나중에 만들 기능, 절대 넣지 않을 기능을 한 장으로 나눕니다.
Codex용 프롬프트에 타깃, 현재 대안, 첫 CTA, 제외 기능을 함께 적습니다.
2주 내 유료 예약 5건

외주 맡긴다면

화면 수 기준인지 기능 기준인지 산정 방식
결제, 알림, 외부 API, QA가 포함/제외로 명시되어 있는가
QA 범위와 무상 하자보수 기간
소스코드 소유권 이전 여부
추천 알고리즘과 리뷰 커뮤니티는 1차 범위에서 제외합니다.

유료 리포트 후보

사용자가 돈을 낼 만한 다음 산출물

결제 기능이 아니라 상품 후보 검토 기준입니다.

바로 후보

외주 견적 검토표

견적서의 화면 수, 관리자, 결제, 외부 API, QA 포함 여부를 항목별로 점검합니다.

전환 기준: 개발사 상담 또는 견적서를 받은 직후

리포트 만들기

바로 후보

개발사 전달용 요약서

타깃, 현재 대안, 1차 기능, 제외 기능, 정책 리스크를 개발사가 이해하는 형식으로 압축합니다.

전환 기준: 기획서 초안이나 PoC 범위를 정할 때

바로 후보

Codex 구현 패키지

AI 테스트 버전, PoC, MVP 뼈대를 만들기 위한 프롬프트와 체크리스트를 묶습니다.

전환 기준: 직접 만들 화면 흐름 1개가 정해졌을 때