심사자용 3분 데모
구성 시작 화면, 핵심 조작 1개, 성공/실패, 결과 화면
목표 아이디어가 실제 플레이로 작동한다는 증거 확보
프로토타입은 싼 완성품이 아닙니다. 제안서, IR, 내부 승인, 기술 확인에 필요한 핵심 플레이 장면만 먼저 만드는 일입니다. 사용자가 실제로 눌러보는 URL을 만들되, 상용 운영에 필요한 서버·관리자·전체 콘텐츠는 따로 판단합니다.
프로토타입은 회의실에서 말로 설명하는 시간을 줄이는 산출물입니다. 아이디어의 재미, 조작 흐름, 기술 가능성을 짧은 URL로 보여주고, 본 개발 전에 무엇을 더 만들지 판단합니다. 제안서나 IR에서는 “이게 실제로 눌립니다”라는 증거가 되고, 내부 검토에서는 화면 수와 기능 우선순위를 정하는 기준이 됩니다.
PDF에 화면 이미지를 붙이는 것과 다릅니다. 브라우저에서 열리는 테스트 URL을 만들고, 사용자가 버튼을 누르거나 캐릭터를 움직이거나 퀴즈를 풀어 결과까지 확인합니다. 이 URL은 내부 회의와 제안 검토에 쓰기 좋지만, 공개 서비스처럼 트래픽·보안·관리자까지 보장한다는 뜻은 아닙니다.
| 구분 | 목적 | 포함 범위 |
|---|---|---|
| PoC | 기술 가능성 검증 | API, WebGL, 저장, 센서, 외부 연동 일부 |
| 프로토타입 | 플레이 흐름 검증 | 핵심 조작, 성공/실패, 결과 화면 |
| MVP | 제한된 사용자 테스트 | 기본 서버, 데이터 저장, 최소 관리자 가능 |
데모 단계에서 모든 것을 넣으면 프로토타입이 아니라 본 개발이 됩니다. 이 단계에서는 핵심 조작과 결과 확인에 집중하고, 상용 그래픽·서버 운영·관리자는 후속 판단으로 남겨두는 편이 낫습니다.
구성 시작 화면, 핵심 조작 1개, 성공/실패, 결과 화면
목표 아이디어가 실제 플레이로 작동한다는 증거 확보
구성 핵심 루프, 테스트 URL, 만든 것과 뺀 것 정리
목표 과제 산출물과 후속 개발 판단 자료 확보
구성 앱 웹뷰·LMS·웹페이지 삽입 가능성 확인
목표 본개발 전 기술 리스크 제거
| 확인 항목 | 전환 판단 | 후속 작업 |
|---|---|---|
| 핵심 루프 반응 | 플레이가 이해되고 반복 의향이 있음 | 화면 확장, 레벨/문항 추가 |
| 운영 데이터 | 저장할 결과와 운영자가 볼 컬럼이 명확함 | API/DB/관리자 설계 |
| 배포 환경 | 웹, LMS, 앱 웹뷰 중 실행 경로가 확인됨 | 호스팅, 삽입, 권한 정리 |
화면 흐름, 조작감, 핵심 UX를 회의에서 확인합니다.
규칙, 성공/실패 조건, 점수 계산을 검증합니다.
WebGL, 서버 저장, 외부 API 연동 가능성을 확인합니다.
제안서와 내부 회의에서 바로 보여줄 핵심 조작 화면입니다.
프로토타입은 핵심 조작과 흐름 확인에 가깝습니다. MVP는 제한된 사용자에게 실제 테스트를 할 수 있어야 해서 서버와 저장 범위가 붙는 경우가 많습니다. 내부 발표용이면 프로토타입, 사용자 테스트와 데이터 수집까지 가면 MVP에 가깝습니다.
이어갈 수 있습니다. 다만 데모 코드를 그대로 키울지, 확인 후 구조를 다시 잡을지는 따로 판단합니다. 처음부터 상용 구조로 가면 비용은 올라가지만 후속 개발 때 버릴 코드가 줄어듭니다.
의뢰할 수 있습니다. 보여줄 핵심 장면과 빼도 되는 일을 먼저 정하면 일정이 짧아집니다. 심사자나 내부 의사결정자가 이해해야 할 1~2분 흐름을 기준으로 화면을 잡습니다.
관련 기준