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

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

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

결론: 사내용은 시장 크기보다 반복 업무, 사용자 수, 권한, 관리자, 시간 절감 효과를 기준으로 제작 범위를 정해야 합니다.

좁힌 웹앱/MVP 제작

사내용은 외부 수요보다 반복 업무, 사용자 수, 권한, 보안, 관리자 기능, 시간 절감 효과가 제작 방식의 기준입니다.

회사 내부 업무용
개발 전에 핵심 화면 흐름, 기능 범위, 비용 리스크를 AI 테스트 버전으로 먼저 확인하는 방식입니다.

필요 제작 범위

웹앱+관리자

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

회사 내부 업무용
예상 작업량은 시장성 점수가 아니라, 실제로 만들어야 할 화면·데이터·관리자·연동·정책 범위의 크기입니다. 현재 입력 기준으로 웹 + 관리자 / 내부 직원 + 관리자 / 선택 복잡 기능: 외부 API 연동 / 의료/헬스케어 도메인 리스크 있음 / 외부 데이터 연동 데이터 확보/최신성 유지 리스크 있음 요소를 반영해 L 등급으로 추정했습니다. L은 결제, 알림, 관리자, 예외 정책, 외부 연동이 함께 들어가는 본격 첫 개발 범위입니다. 입력하지 않은 결제, 관리자, 외부 연동은 포함했다고 단정하지 않습니다.

비용 경계

관리자/권한이 비용 핵심

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

가장 먼저 확인할 질문에 직접 필요 없는 추천/리뷰/커뮤니티 기능은 1차 범위에서 제외합니다.
복잡 기능과 사용자 구조 때문에 초기 예산이 예상보다 빠르게 커질 수 있습니다.

증거/견적 기준

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

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

증거 기준 v0.1

충분

반복 사용/반복 결제

반복 사용/반복 결제 단계의 행동 증거가 있어 첫 버전 판단 근거로 쓸 수 있습니다.

현재 증거

수동 운영/컨시어지
고객 인터뷰
운영 자동화 필요가 큼
회원/고객 DB 있음

더 필요한 증거

큰 누락 증거는 적습니다.

다음 확보 기준

핵심 CTA 또는 문의 전환율 5% 이상
유료 예약, 예약금, 구매 의향 5건 이상
타깃 고객 인터뷰 10명 이상에서 같은 현재 대안/불편 반복 확인
반복 사용 고객의 재방문 이유와 이탈 이유 기록

외주 견적 기준 v0.1

L 첫 버전 외주 기준

병원 내부 승인 흐름, 직원/관리자 권한, 재고 상태 변경, 외부 연동 가능성을 포함한 첫 업무 자동화 버전 기준입니다. 단순 랜딩이나 화면 샘플 비용이 아닙니다.

예상 구간

1,500만-3,500만원

DB/백엔드

큼

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

관리자

큼

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

기획/범위

보통+

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

연동/QA

보통

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

화면/프론트

보통

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

직접 먼저

핵심 화면 1개: 핵심 CTA 또는 문의 전환율 5% 이상
범위/제외 기능 문서: 가장 먼저 확인할 질문에 직접 필요 없는 추천/리뷰/커뮤니티 기능은 1차 범위에서 제외합니다.

포함

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

제외

고급 통계/추천
정산 자동화
앱스토어 심사 대응
운영 대행

견적서 확인

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

개발 경계

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

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

엔진 추천 후보

기존 추천과 일치

기존 추천과 같은 방향

기존 scoring과 새 엔진이 같은 추천 방향을 보고 있습니다.

현재 추천은 유지하고, 매칭 기능과 조합 룰만 보조 근거로 확인합니다.

현재 /result 추천

좁힌 웹앱/MVP 제작

기존 scoring 기준

엔진 후보

좁힌 웹앱/MVP 제작

룰·매트릭스 기준

전환 실험

문구 실험 가능

상단 추천 미반영

운영·권한·예산 리스크가 커서 기술 PoC보다 범위와 수요 검증을 먼저 정리해야 합니다.

매칭된 기능

관리자 승인 워크플로외부 API 조회

다중 사용자 역할 + 민감 데이터 가능성

역할이 나뉘고 민감한 데이터가 섞이면 권한 설계와 정보 노출 방지가 핵심 리스크가 됩니다.

상단 CTA는 기존 결과를 따릅니다.
매칭 기능: 관리자 승인 워크플로, 외부 API 조회
조합 룰: 다중 사용자 역할 + 민감 데이터 가능성
추천 경로: mvp_build

점수 시각화

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

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

점수 균형

점수 레이더

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

리스크 지도

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

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

차트 설명

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

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

리스크 항목

외부 API 연동

기기, 플랫폼 권한, 외부 데이터 접근은 실제 환경에서 막힐 수 있어 본개발 전에 작게 확인해야 합니다.

예상 비용 영향

높음

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

예상 기간 영향

높음

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

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

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

2단계추천 단계

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

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

기획서 초안 보기

상세 분석

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

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

반복 업무가 줄어들까?

사내용은 시장 크기보다 같은 업무가 얼마나 자주 반복되고, 누가 처리하며, 어디서 누락되는지가 먼저입니다.

목적: 회사 내부 업무용

운영 자동화 필요가 큼

회원/고객 DB 있음

판단 기준: 반복 빈도, 사용자 수, 권한, 관리자, 처리 시간

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

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

현재 사용 중인 대안

엑셀 파일, 카카오톡, 전화, 수기 장부를 조합해 재고 요청과 발주를 처리한다.

쓰는 이유지금 당장 문제를 해결하기 위해 이미 쓰는 방식입니다.

강점학습 비용이 낮고 고객이 익숙합니다.

빈틈정보가 흩어지거나 반복 업무가 수동으로 남을 가능성이 큽니다.

우리의 기회새 서비스는 익숙함을 해치지 않으면서 시간 절감이나 실수 감소를 보여줘야 합니다.

확인 질문: 고객이 이 방식을 버릴 만큼 자주 불편을 겪고 있나요?

다음 단계 시작

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

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

업무 흐름/권한 정리

반복 업무, 사용자 수, 권한, 관리자 범위를 개발 의뢰 전에 정리합니다.

기술/금액 산정표

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

ManyFast용 기획 입력 프롬프트

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

PoC 체크리스트 만들기

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

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

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

처음엔 여기까지만

가장 먼저 확인할 질문에 직접 필요 없는 추천/리뷰/커뮤니티 기능은 1차 범위에서 제외합니다.
관리자 기능은 승인, 상태 변경, 기본 조회처럼 운영에 꼭 필요한 기능만 남깁니다.
자동화가 필요한 업무는 시장·대체재 조사 또는 기술 확인 이후로 범위를 확정합니다.

개발자에게 물어볼 것

관리자/권한: 관리자 기능이 3개 이상이면 견적서에 화면 수와 권한 범위를 따로 적습니다.
외부 연동/알림: 실제 운영 데이터가 필요한 순간부터 개발자 검토 범위로 넘깁니다.
1차 버전에서 외부 API 연동을 제외할 수 있나요?
관리자 기능은 조회/승인/상태 변경 중 어디까지 필요한가요?

내가 만든다면

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

외주 맡긴다면

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

AI 분석 입력문

사내용 업무 절감 분석 프롬프트

ROI 금액 계산이 아니라, 반복 업무가 줄어드는지와 웹앱·관리자 필요 여부를 AI에게 먼저 분석시키는 입력문입니다.

사내용 전용

너는 사내 업무 자동화 PM이다. 아래 정보를 바탕으로 이 아이디어가 시장 크기보다 반복 업무 절감 관점에서 만들 가치가 있는지 판단해줘.

아이디어: 소규모 병원에서 직원이 반복 입력하는 재고 요청, 승인, 발주 확인 업무를 웹으로 자동화하는 내부 운영 도구
현재 대안: 엑셀 파일, 카카오톡, 전화, 수기 장부를 조합해 재고 요청과 발주를 처리한다.
사용자/역할: 내부 직원 + 관리자
필요 범위: 웹 + 관리자
주의 리스크: 복잡 기능과 사용자 구조 때문에 초기 예산이 예상보다 빠르게 커질 수 있습니다.

추가로 아래 값을 질문 형태로 받아서 분석해줘.
- 반복 업무명:
- 주간 처리 건수:
- 1건 처리 시간:
- 참여 역할과 승인 단계:
- 실수/누락/중복이 생기는 지점:
- 권한, 보안, 관리자 필요 여부:
- GPT/노션/시트/자동화툴로 먼저 가능한 범위:

출력은 다음 형식으로 작성해줘.
1. 지금은 GPT/노션/시트/자동화툴로 충분한가
2. 간단 웹앱 또는 관리자 화면이 필요한 조건
3. 개발비가 커지는 지점
4. 자동화 전 1주일 동안 기록할 지표
5. 첫 버전에서 빼야 할 기능

주의: ROI 금액을 단정 계산하지 말고, 시간 절감 예시와 확인 질문 중심으로 답해줘.

유료 리포트 후보

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

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

바로 후보

외주 견적 검토표

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

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

리포트 만들기

바로 후보

개발사 전달용 요약서

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

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

바로 후보

Codex 구현 패키지

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

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