이 글의 순서
- 01프로토타입 검수는 개발 시작 기준을 확인하는 과정입니다
- 02핵심 사용자가 한 가지 목적을 끝낼 수 있나요?
- 03이전·취소·다시 시도할 수 있나요?
- 04입력값과 선택 조건이 화면에서 이해되나요?
- 05빈 화면·로딩·오류·권한 상태가 있나요?
- 06고객 화면 뒤의 관리자 업무와 데이터가 연결되나요?
- 07첫 출시와 다음 버전의 경계가 보이나요?
- 08수정 내용과 승인 결과가 개발 기준으로 남았나요?
- 09검수 회의는 이 순서로 진행하세요
- 10한 장으로 남기는 프로토타입 승인표
- 11프로토타입만으로 확인할 수 없는 것도 있습니다
- 12개발을 시작하기 전 마지막으로 확인하세요
- 13데브크래프트는 실제 화면으로 범위를 함께 확인합니다
- 14자주 묻는 질문
프로토타입 검수는 개발 시작 기준을 확인하는 과정입니다
앱 화면이 보기 좋게 정리됐다고 바로 개발을 시작해도 되는 것은 아닙니다. 홈 화면은 완성됐지만 신청을 취소할 방법이 없거나, 고객이 요청을 보낸 뒤 운영자가 어디에서 확인하는지 정해지지 않았을 수 있습니다. 이런 내용은 실제 개발이 시작된 뒤 발견할수록 화면뿐 아니라 데이터와 서버 처리까지 다시 바꿔야 합니다.
프로토타입 검수의 목적은 디자인을 평가하는 데 있지 않습니다. 사용자가 목적을 끝낼 수 있는지, 화면 뒤의 운영과 상태가 연결되는지, 첫 버전에서 어디까지 개발할지가 합의됐는지 확인하는 데 있습니다.
프로토타입의 역할과 완성 앱과의 차이가 먼저 궁금하다면 프로토타입 용어 안내를 확인해보세요.
아래 일곱 가지를 실제 사용 상황처럼 직접 눌러보고 결과를 기록하면 ‘화면을 봤다’가 아니라 ‘개발을 시작할 기준을 확인했다’고 말할 수 있습니다.
핵심 사용자가 한 가지 목적을 끝낼 수 있나요?
프로토타입을 열기 전에 먼저 사용자를 한 명 정합니다. 모든 사용자를 한 번에 확인하면 화면은 많아지지만 무엇이 중요한지 판단하기 어렵습니다.
예약 앱이라면 ‘처음 방문한 고객이 가능한 시간을 확인하고 상담을 신청한다’처럼 시작 조건과 완료 결과를 한 문장으로 정합니다. 그다음 홈에서 시작해 예약 완료 화면까지 설명 없이 직접 이동해봅니다.
통과 기준
시작 화면, 선택·입력 화면과 완료 화면이 연결되고 사용자가 다음 행동을 추측하지 않아도 목적을 끝낼 수 있어야 합니다. 완료 화면에는 접수·확정처럼 현재 상태와 이후 확인 방법이 함께 보여야 합니다.
확인해보세요
- 이 화면의 핵심 사용자는 누구인가요?
- 사용자가 가장 먼저 끝내야 하는 한 가지 일은 무엇인가요?
- 완료됐다는 사실을 어떤 화면과 상태로 확인하나요?
이전·취소·다시 시도할 수 있나요?
정상적으로 다음 버튼만 누르는 흐름은 대부분 자연스럽게 보입니다. 실제 사용에서는 잘못 선택한 날짜를 바꾸고, 입력을 중단하고, 앱을 다시 열고, 실패한 요청을 다시 시도합니다.
통과 기준
뒤로 가기, 취소, 닫기, 다시 시도의 결과가 화면마다 정해져 있어야 합니다. 단순히 버튼이 존재하는 것이 아니라 입력값을 유지할지 지울지, 이미 저장된 요청을 취소할지까지 기록합니다.
확인해보세요
- 잘못 선택한 값을 이전 화면에서 바꿀 수 있나요?
- 취소하면 입력한 내용과 예약 가능 시간이 어떻게 되나요?
- 완료 후 홈·내역·상세 중 어디로 이동하나요?
입력값과 선택 조건이 화면에서 이해되나요?
프로토타입에서는 입력창과 버튼을 배치하는 데 그치기 쉽습니다. 실제 개발에서는 어떤 값이 필수인지, 잘못된 값은 언제 알려줄지, 선택할 수 없는 값은 왜 막혔는지가 필요합니다.
아직 사용자·문제·운영 흐름이 정리되지 않았다면 앱 서비스 기획 가이드에서 앞 단계를 먼저 확인하는 편이 좋습니다.
통과 기준
정상값, 잘못된 값, 비어 있는 값, 선택할 수 없는 값의 표시가 구분돼야 합니다. 예약 앱에서는 마감된 시간을 숨길지 비활성화할지, 고객이 새로고침했을 때 가능 시간을 다시 확인할지도 함께 정합니다.
확인해보세요
- 필수 정보와 선택 정보가 구분되나요?
- 입력 형식과 오류 이유를 해당 항목 가까이에서 알 수 있나요?
- 마감 시간·재고·권한처럼 선택할 수 없는 조건을 이해할 수 있나요?
빈 화면·로딩·오류·권한 상태가 있나요?
데이터가 잘 들어온 화면만 있으면 프로토타입은 완성돼 보입니다. 하지만 첫 가입이라 내역이 없거나, 네트워크가 느리거나, 요청이 실패하거나, 권한이 없는 상황도 실제 제품의 일부입니다.
통과 기준
최소한 빈 상태, 처리 중, 실패, 완료, 접근 불가를 구분합니다. 모든 화면을 완성할 필요는 없지만 핵심 흐름에서 상태가 바뀌는 지점은 프로토타입 또는 상태 표로 확인해야 합니다.
확인해보세요
- 처음 사용할 때 보여줄 빈 화면과 다음 행동이 있나요?
- 처리 중 중복 터치를 막고 진행 상태를 알리나요?
- 실패했을 때 입력 내용을 잃지 않고 다시 시도할 수 있나요?
- 권한이 없을 때 이유와 해결 방법을 안내하나요?
고객 화면 뒤의 관리자 업무와 데이터가 연결되나요?
고객이 신청 버튼을 누르는 순간 서비스 운영자의 일이 시작됩니다. 신청이 어디에 저장되는지, 누가 언제 확인하는지, 처리 결과가 고객에게 어떻게 돌아가는지를 함께 보지 않으면 출시 후 엑셀과 메신저로 업무를 보완하게 됩니다.
예약 앱 흐름을 직접 확인하려면 예약 신청이 관리자 승인과 앱 알림으로 이어지는 과정을 살펴보세요.
통과 기준
고객의 한 행동을 기준으로 고객 화면 → 저장 상태 → 관리자 업무 → 처리 결과 → 고객 확인이 연결돼야 합니다. 프로토타입에서 실제 서버가 동작하지 않더라도 필요한 데이터와 상태 이름, 담당자 행동은 기록할 수 있어야 합니다.
확인해보세요
- 고객 요청이 어떤 번호와 상태로 저장되나요?
- 관리자는 어디에서 확인하고 누가 담당하나요?
- 승인·보완·마감 결과가 고객 앱과 알림에 같은 내용으로 반영되나요?
- 알림이 도착하지 않아도 앱에서 최신 결과를 다시 확인할 수 있나요?
첫 출시와 다음 버전의 경계가 보이나요?
검수 과정에서는 새로운 아이디어가 계속 생깁니다. 좋은 아이디어라도 모두 첫 버전에 넣으면 프로토타입 검수가 범위 확정이 아니라 기능 추가 회의로 바뀝니다.
기능 후보가 많다면 MVP 기능 우선순위 진단으로 첫 버전과 다음 버전을 나눌 수 있습니다.
통과 기준
각 기능을 첫 출시, 다음 버전, 이번 제외, 추가 확인 중 하나로 분류하고 이유를 남깁니다. 첫 출시 범위는 화면 수가 아니라 핵심 흐름과 운영이 끊기지 않는지를 기준으로 정합니다.
확인해보세요
- 핵심 목적을 끝내기 위해 반드시 필요한 화면은 무엇인가요?
- 실제 이용 데이터가 있어야 결정할 기능은 무엇인가요?
- 첫 출시에서 제외해도 운영 가능한 기능은 무엇인가요?
- 제외 기능이 현재 화면에 들어갈 자리만 차지하고 있지는 않나요?
수정 내용과 승인 결과가 개발 기준으로 남았나요?
회의에서 모두 이해했다고 느껴도 기록이 없으면 같은 화면을 서로 다르게 기억합니다. 검수 결과는 화면별 의견 모음이 아니라 실제 개발과 테스트에서 확인할 기준으로 바뀌어야 합니다.
요구사항 문서가 필요하다면 앱 개발 RFP·요구사항 작성 도구로 화면 밖의 조건까지 정리할 수 있습니다.
통과 기준
화면마다 사용자 목적, 입력·데이터, 정상 결과, 오류·예외, 관리자 처리, 첫 출시 여부, 결정 상태가 남아 있어야 합니다. 확정된 내용은 RFP·기능 정의서·개발 일정과 검수 항목으로 이어집니다.
확인해보세요
- 누가 언제 어떤 시나리오로 검수했나요?
- 수정·보류·확정 항목과 담당자가 구분됐나요?
- 화면에 보이지 않는 데이터·권한·예외 조건도 기록했나요?
- 수정본을 다시 확인할 사람과 최종 승인자가 정해졌나요?
검수 회의는 이 순서로 진행하세요
회의 전·중·후에 남길 결과를 미리 정해두면 화면 감상이 아닌 개발 범위 확정 회의로 진행할 수 있습니다.
회의 전
검수할 사용자와 목적, 시작 조건과 완료 결과를 먼저 준비합니다.
회의 중
막힌 지점과 예상한 결과를 기록하고 새 제안은 첫 출시, 다음 버전, 제외로 분류합니다.
회의 후
수정 담당자와 일정, 재확인 대상을 정한 뒤 개발과 테스트 기준으로 전달합니다.
확인해보세요
- 이번에 확인할 사용자 한 명과 핵심 목적 하나를 정합니다.
- 시작 조건과 완료 결과가 다른 시나리오를 최대 세 개 준비합니다.
- 검수자가 설명을 듣지 않고 먼저 직접 눌러보게 합니다.
- 화면별 감상보다 사용자가 막힌 지점과 예상한 결과를 기록합니다.
- 새 기능 제안은 즉시 추가하지 않고 첫 출시·다음 버전·제외로 분류합니다.
- 고객 화면의 각 행동이 어떤 데이터와 관리자 업무를 만드는지 연결합니다.
- 수정 담당자와 완료일을 정합니다.
- 수정본에서 다시 확인할 항목만 별도 표시합니다.
- 모든 항목이 확정되면 개발 범위·일정·테스트 기준에 반영합니다.
한 장으로 남기는 프로토타입 승인표
각 항목에 확인 결과, 확정·수정·보류 중 하나의 결정, 담당자와 기한을 함께 남깁니다.
사용자와 핵심 목적
시작·완료 조건이 정해졌는지 확인합니다.
화면 이동과 복구
뒤로 가기, 취소, 재시도의 결과를 확인합니다.
입력과 선택 조건
필수·선택 입력, 오류, 비활성 조건을 확인합니다.
화면 상태
빈 상태, 로딩, 실패, 접근 권한을 확인합니다.
운영 연결
저장, 관리자 업무, 알림이 연결되는지 확인합니다.
버전 범위
첫 출시, 다음 버전, 제외 기능의 경계를 확인합니다.
개발 기준
데이터, 예외, 완료 조건이 개발과 테스트 기준으로 남았는지 확인합니다.
프로토타입만으로 확인할 수 없는 것도 있습니다
프로토타입이 실제 앱처럼 보여도 서버 저장, 보안, 권한 검사, 결제 승인, 대량 데이터 처리와 알림 전달이 구현된 것은 아닙니다. 화면 검수에서 확인한 내용은 실제 개발 범위와 테스트 계획으로 다시 연결해야 합니다.
프로토타입은 개발을 대신하는 결과물이 아니라, 잘못 이해한 부분을 개발 전에 발견하고 개발할 범위를 명확하게 만드는 도구입니다.
화면 시안과 관리자 도구, 실제 개발 결과물의 차이를 나란히 보고 싶다면 프로토타입·관리자·완성품 비교 화면을 확인해보세요.
확인해보세요
- 실제 데이터 저장과 동시 요청 처리
- 로그인·권한·개인정보 보호
- 결제·지도·본인 인증 같은 외부 서비스 연동
- 기기·네트워크별 성능과 오류 복구
- 관리자 변경 이력과 운영 로그
- 앱스토어 심사·배포·업데이트 과정
개발을 시작하기 전 마지막으로 확인하세요
아래 항목은 홈페이지의 확인 목록으로 표시됩니다. 아직 정하지 못한 항목은 개발 전에 담당자와 기한을 기록합니다.
하나라도 답하기 어렵다면 화면을 더 예쁘게 만드는 것보다 해당 조건을 먼저 정하는 것이 좋습니다.
확인해보세요
- 핵심 사용자가 시작부터 완료까지 직접 이동할 수 있다.
- 이전·취소·재시도의 결과가 정해져 있다.
- 필수 입력과 오류·비활성 조건이 구분돼 있다.
- 빈·로딩·실패·권한 상태가 정의돼 있다.
- 고객 행동과 저장·관리자·알림 흐름이 연결돼 있다.
- 첫 출시·다음 버전·이번 제외 범위가 구분돼 있다.
- 수정·확정 결과가 개발과 테스트 기준으로 기록돼 있다.
데브크래프트는 실제 화면으로 범위를 함께 확인합니다
데브크래프트는 기능 목록만 전달받아 바로 개발을 시작하지 않습니다. 사용자가 완료해야 하는 과정과 운영자가 처리할 업무를 실제 앱처럼 눌러볼 수 있는 화면으로 먼저 확인하고, 그 결과를 첫 출시 범위·개발 일정·검수 기준으로 연결합니다.
아이디어를 실제 서비스로 만드는 과정 영상을 보거나, 프로젝트 상담 신청에서 현재 준비된 화면과 확인이 필요한 흐름을 알려주세요.
자주 묻는 질문
프로토타입 검수를 시작하기 전에 자주 묻는 내용을 정리했습니다.
와이어프레임과 프로토타입은 무엇이 다른가요?
와이어프레임은 화면에 어떤 정보와 기능을 배치할지 구조를 정하는 데 가깝습니다. 프로토타입은 주요 화면을 연결해 사용자가 실제 순서로 이동하며 흐름과 빠진 조건을 확인할 수 있게 합니다.
모든 화면을 프로토타입으로 만들어야 하나요?
아닙니다. 핵심 사용자 목적, 위험한 운영 규칙, 구현 비용이 큰 흐름부터 확인하는 편이 좋습니다. 단순 반복 화면은 대표 유형만 만들고 공통 규칙으로 정리할 수 있습니다.
프로토타입에서 동작하면 개발도 거의 끝난 것인가요?
아닙니다. 화면 이동은 실제처럼 보여도 데이터 저장, 서버 처리, 권한, 보안, 외부 연동과 운영 로그는 별도 개발이 필요합니다.
관리자 화면도 프로토타입에 포함해야 하나요?
고객 요청을 운영자가 확인·승인·배정·정산해야 하는 서비스라면 핵심 관리자 흐름도 함께 확인해야 합니다. 고객 화면만 검수하면 출시 후 수작업과 누락이 생길 수 있습니다.
프로토타입은 언제 확정해야 하나요?
핵심 흐름, 상태, 운영 연결과 첫 출시 범위가 합의된 뒤 실제 개발을 시작하는 것이 좋습니다. 개발 중 새 근거가 생기면 바꿀 수 있지만 변경 이유와 일정·비용 영향을 함께 기록해야 합니다.
