CatchPro는 오더를 직접 선택하는 운송 기사가 더 짧은 시간 안에 핵심정보를 확인하고, 목적지 이동까지 자연스럽게 이어가도록 만든 현장형 도구입니다. 이 글은 아이디어만 정리한 문서가 아니라 문제 → 가설 → 개발 → 운행 테스트 → 기능 제거·개선 → 성과의 과정을 가치제안으로 연결한 기록입니다.
1. CatchPro를 만들게 된 현장 문제
오더 기반 운송 현장에서는 좋은 오더가 오래 남아 있지 않습니다. 기사는 짧은 시간 안에 수익성, 목적지, 이동 동선을 판단해야 하지만 상세정보 확인과 반복적인 화면 전환 때문에 수락 기회를 놓칠 수 있습니다. 운행 중 복잡한 조작은 피로와 안전 부담도 키웁니다.
2. 초기 고객과 가치 가설
- 고객: 플랫폼에서 오더를 직접 선택하는 운송 기사
- 핵심 문제: 좋은 오더를 찾고 판단하는 시간이 짧고, 상세 확인과 길 안내 연결에 조작이 많이 필요함
- 초기 가치 가설: 오더 핵심정보 확인과 상세 진입, 목적지 길 안내를 빠르게 연결하면 판단 시간을 줄이고 시간당 매출을 높일 가능성이 있음
3. 첫 MVP와 핵심 기능
- 오더 화면에서 필요한 핵심정보 인식
- 오더 상세화면 자동 진입
- 빠른 확인을 위한 반응속도 최적화
- 목적지 확인과 TMAP 연결
- 운행 중 조작을 줄인 단순한 사용 흐름
- 오류와 실패 원인을 남기는 현장검증 로그
OCR은 개발 과정에서 실제 구현과 동작이 확인된 핵심정보 인식 범위만 가치제안에 포함했습니다. 검증되지 않은 기능을 완성 기능처럼 확대해 적지 않았습니다.
4. 실제 운행 테스트 방법
현장 운행에서 오더 발견부터 상세정보 확인, 수락 판단, 목적지 확인, TMAP 실행까지의 흐름을 반복했습니다. 단순히 기능이 실행되는지만 보지 않고, 화면 전환 수와 반응 지연, 놓친 오더, 불필요한 조작, 오류 로그를 함께 확인했습니다.
5. 첫 결과와 발견한 문제
첫 MVP는 기능 범위가 넓어 실제 운행에서 중요한 판단 속도를 흐릴 수 있었습니다. 상세 진입이 늦거나 여러 화면을 거치면 좋은 오더를 확인하는 이점이 줄었고, 기능이 많아도 현장 수익에 직접 기여하지 않는 경우가 있었습니다.
6. 효과가 낮았던 오더 추적 기능 제거
현장검증 결과 오더 추적 기능은 복잡도를 높이는 데 비해 핵심 목표인 빠른 판단에 주는 효과가 낮았습니다. 기능 수를 유지하는 대신 과감히 제거하고, 오더 확인과 상세 진입, 길 안내 연결에 개발 우선순위를 집중했습니다.
7. 자동 상세 진입·반응속도·TMAP 흐름 개선
- 상세화면 자동 진입 지연 최소화
- 오더 확인 과정의 반응속도 개선
- 반복 터치와 화면 전환 감소
- 목적지 확인 후 TMAP으로 이어지는 단계 단순화
- 오류와 실패 원인을 로그로 남겨 재발 방지
8. 개선 전후 사용자 흐름 비교
| 구분 | 개선 전 | 개선 후 |
|---|---|---|
| 오더 확인 | 여러 정보와 기능을 함께 탐색 | 수락 판단에 필요한 핵심정보에 집중 |
| 상세 진입 | 반복 터치와 전환 지연 | 자동 진입과 반응속도 최적화 |
| 목적지 이동 | 주소 확인 후 별도 내비 조작 | 목적지 확인에서 TMAP 연결까지 단순화 |
| 기능 범위 | 효과가 낮은 추적 기능 포함 | 추적 기능 제거, 핵심 흐름에 집중 |
| 개선 방식 | 기능 구현 중심 | 현장 로그와 실제 운행 결과 중심 |
9. 실제 성과와 좋은 오더의 기준
CatchPro의 성과는 단순히 “빠르게 눌렀다”가 아니라, 이동거리 대비 운임이 높고 다음 오더까지 이어질 가능성이 높은 오더를 더 빠르게 판단한 결과로 봅니다.
매출 전후 비교
실제 운행에서 반복 관찰한 대표 수준이며 통제 실험 결과가 아닙니다.
3만원 달성일 비율
원시 일별 로그가 정리되기 전의 개발자 현장 관찰치입니다.
좋은 오더를 판단하는 4가지 요소
총 운행거리에 비해 운임이 높은가
현재 위치에서 픽업지까지 가까운가
정체·우회·통행 제약이 적은가
도착 후 다음 오더를 받기 좋은가
총 운행거리 = 현재 위치→픽업지 거리 + 픽업지→목적지 거리
거리당 운임 = 운임 ÷ 총 운행거리(km)
시간당 실현 매출 = 실제 운임 ÷ 실제 총 소요시간 × 60
거리당 운임은 오더 선택 기준이고, 시간당 매출은 선택 결과를 확인하는 사후 성과지표입니다. 통행료·주차비·연료비가 확인되면 비용을 뺀 거리당 예상 순수익을 보조지표로 사용합니다.
후보 오더 비교 방식
| 오더 | 총 거리 | 거리당 운임 | 픽업 접근 | 교통 | 목적지 수요 | 등급 |
|---|---|---|---|---|---|---|
| A | 실제 입력 | 자동 계산 | 좋음 | 원활 | 높음 | 자동 계산 |
| B | 실제 입력 | 자동 계산 | 보통 | 보통 | 높음 | 자동 계산 |
| C | 실제 입력 | 자동 계산 | 좋음 | 혼잡 | 낮음 | 자동 계산 |
표의 숫자는 실제 운행 입력란입니다. 예시 숫자를 넣을 때는 반드시 “평가 방식 설명을 위한 예시 가정”으로 표시합니다.
근거 수준
핵심정보 인식·자동 상세 진입·TMAP 연결
개발자 사용일 약 80%에서 3만원 관찰
외부 기사 5명·2주 교차 테스트
10. 최종 가치제안 캔버스
CatchPro 신사업 아이디어와 린 캔버스
현장 문제를 시장·고객·제품·사업모델로 압축하고, 확인된 사실과 다음 검증 가설을 분리했습니다.
한 문장 사업 정의
시장 → 고객 → 해결책
오더 선택형 운송·배달 플랫폼
짧은 시간 안에 좋은 오더 판단
정보 인식·자동 상세·TMAP 연결
1만원→3만원, 사용일 약 80%
TAM · SAM · SOM
플랫폼에서 오더를 선택하는 운송·배달 종사자 전체
공식 종사자·플랫폼 자료 필요Android 기반 오더 앱과 TMAP을 사용하며 오더를 직접 비교하는 기사
기기·앱 사용 비율 필요개발일지·동료 추천으로 모집 가능한 소규모 기사 체험단
첫 목표 5명근거 없는 시장규모 숫자는 생성하지 않고 출처가 확보될 때만 계산합니다.
자료 입력 필요린 캔버스 9개 블록
오더를 직접 비교·선택하는 운송 기사
초기 사용자: 빠른 판단과 TMAP 연결이 필요한 Android 사용자
좋은 오더의 수익성을 빠르게 판단하기 어렵고, 상세 확인·내비 연결에 반복 조작이 필요함
거리당 수익성과 다음 오더 가능성을 빠르게 판단하고 길 안내까지 한 흐름으로 연결
핵심정보 인식, 자동 상세 진입, 반응속도 최적화, 목적지 확인, TMAP 연결
동료 기사 추천, 소규모 기사 커뮤니티, CatchPro 개발일지 비공개 체험단
검증 필요무료 체험 후 월 구독 또는 기능형 유료 플랜
지불의향 검증 필요앱 개발·유지보수, 기기·현장 테스트, 고객지원, 서버·로그 운영
원가 산정 필요판단시간, A등급 적중률, 거리당 운임, 시간당 매출, 다음 오더 대기시간
실제 운행과 기능 개선을 연결해 축적하는 판단·오류·성과 데이터
외부 사용자 데이터 축적 필요AARRR 검증 퍼널
체험단 유입
첫 오더 판단 성공
2주 반복 사용
지불의향
동료 추천
현재 린 캔버스 원본
CatchPro 가설 검증 계획
개발자 본인의 반복 성과를 다른 기사에게도 재현할 수 있는지 기능형 MVP로 검증합니다.
1. 사업성을 결정하는 최우선 검증 가설
CatchPro의 사업성이 성립하려면 개인의 운행 경험을 넘어 외부 기사에게도 효과가 재현되어야 합니다. 외부 기사가 좋은 오더 기준을 사용했을 때 오더 판단시간, 거리당 운임, 시간당 매출이 개선되는지를 가장 먼저 검증합니다.
현재 확인된 1만원→3만원·사용일 약 80% 성과는 개발자의 반복 운행 관찰입니다. 외부 기사 재현성은 아직 검증 전입니다.
2. MVP와 실험 설계
핵심정보 인식
자동 상세 진입·반응속도 최적화
목적지 확인·TMAP 연결
자동 수락
제거된 오더 추적
검증되지 않은 자동 수익 예측
3. 기록할 데이터
| 구분 | 수집 항목 | 계산·사용 목적 |
|---|---|---|
| 조건 | 사용 여부, 날짜, 시간대, 권역 | 비슷한 조건끼리 비교 |
| 거리 | 현재→픽업, 픽업→목적지 | 총 운행거리·거리당 운임 |
| 성과 | 운임, 판단시간, 총 소요시간 | 시간당 매출·판단시간 개선 |
| 연속성 | 다음 오더 대기시간 | 목적지 수요 검증 |
| 정확성 | 예상 등급과 실제 결과 | A등급 적중률 |
| 안정성 | 상세 진입·TMAP 성공, 안전 문제 | 제품 신뢰성·중단 판단 |
총 운행거리 = 픽업 접근 거리 + 픽업지→목적지 거리
거리당 운임 = 운임 ÷ 총 운행거리
시간당 매출 = 실제 운임 ÷ 실제 총 소요시간 × 60
4. 성공 기준
| 지표 | 성공 기준 |
|---|---|
| 오더 판단시간 | 미사용 대비 30% 이상 단축 |
| 거리당 운임 | 미사용 대비 개선 |
| 시간당 매출 | 미사용 대비 개선 |
| 시간당 3만원 달성 | 사용 운행의 50% 이상 |
| A등급 오더 적중률 | 70% 이상 |
| 자동 상세·TMAP 성공률 | 각 95% 이상 |
| 계속 사용 의향 | 5명 중 4명 이상 |
| 중대한 안전 문제 | 0건 |
5. 모집·실행 퍼널
모집 페이지 방문
참여 의향
기초 설문
최종 테스트
위 숫자는 모집 계획입니다. 실행 후 실제 방문·신청·완료 수치로 교체합니다.
6. 2주 일정
모집·설치·안전 안내
교차 운행 1차
오류만 수정
교차 운행 2차
인터뷰·판정
7. 의사결정
수익성·사용성·안전 기준 충족
판단은 빨라졌으나 수익성 미달
표본·로그 부족으로 판단 보류
수익 개선 없음 또는 안전 문제
Mission 3 · CatchPro 고객 문제 심층분석과 타깃 페르소나
CatchPro 개발과 현장검증 과정에서 관찰된 문제를 Chapter 07의 JTBD·Pain·Gain과 Chapter 08의 Persona 방식으로 다시 분석했습니다. 기능을 먼저 설명하지 않고, 운송 기사가 어떤 상황에서 어떤 진전을 얻기 위해 CatchPro를 사용하는지부터 정의합니다.
개발·현장 기록 실제 구현, 제거 결정, 사용자 확인 성과 프로토 페르소나 인터뷰 전 행동 기반 가정 추가 검증 Mission 2의 5명·2주 테스트로 확인할 항목
1. 개발 기록에서 고객 문제를 추출한 과정
오더가 빨리 사라지고 상세 진입이 늦거나 실패함
자동상세진입 최우선, 클릭 대체 경로, 불필요 기능 제거
조작을 줄이고 더 빠르고 확신 있게 오더 판단
| 현장·개발 근거 | 고객 문제 해석 | 제품 결정 | 근거 상태 |
|---|---|---|---|
| 좋은 오더는 다른 기사가 먼저 잡으면 사라짐 | 판단 가능한 시간이 매우 짧음 | 리스트 감지 후 상세 진입을 최우선 루프로 분리 | 개발일지 |
| ACTION_CLICK이 항상 성공하지 않음 | 한 번의 클릭 실패가 기회 손실로 연결 | 실패 시 좌표 탭 보조 경로로 즉시 전환 | 구현 결정 |
| 오더추적 자동확정 성공 사례가 없었음 | 복잡한 기능이 핵심 반응속도를 방해할 수 있음 | 오더추적 화면과 실행 경로 제거 | 현장검증 |
| 2폰 운영에서 주소칸을 맞출 필요 | 주소를 다시 입력하는 조작·오류 부담 | TMAP과 AWS 주소 동기화를 독립 선택 기능으로 유지 | 개발일지 |
| 시간당 매출 3만원 달성 | 속도 개선이 수익 기회에 기여할 가능성 | 개발자의 반복 운행 관찰로 기록하고 외부 기사 재현성 검증 | 개발자 반복 운행 관찰 |
2. CatchPro 핵심 JTBD
“가까운 수익성 높은 오더가 잠깐 나타났을 때, 운행 중 조작을 최소화하면서 목적지와 요금을 빠르게 판단하고 상세 진입·확정·길 안내까지 이어서 공차와 대기시간을 줄이고 싶다.”
| Job 유형 | 고객이 하려는 일 | 성공의 모습 |
|---|---|---|
| 기능적 | 새 오더 발견, 목적지·요금 확인, 수락 판단, TMAP 연결 | 짧은 시간 안에 필요한 정보만 확인하고 이동 시작 |
| 감정적 | 좋은 오더를 놓칠 불안과 반복 조작 피로 감소 | 앱이 핵심 순간에 반응한다는 통제감과 확신 |
| 사회적 | 무리한 조작 없이 효율적으로 운행 | 안전하고 생산적으로 일하는 숙련 기사라는 자기인식 |
3. Pain·Gain 심층 분석
핵심 Pains
- 기회 손실: 상세 진입 전에 오더가 사라짐
- 클릭 불확실성: 접근성 클릭 실패와 화면 갱신
- 인지 부담: 목적지·요금·제외 조건을 짧은 시간에 판단
- 반복 조작: 상세 확인부터 내비 실행까지 화면 전환
- 기능 복잡도: 효과 없는 기능과 과도한 로그가 핵심 흐름을 방해
- 안전 부담: 운행 중 복잡한 화면 확인과 조작
기대 Gains
- 빠른 반응: 새 오더에서 상세 화면까지 지연 감소
- 판단 집중: 현재 도착지·요금 등 필요한 조건만 확인
- 조작 감소: 자동 진입과 TMAP 연결로 반복 터치 감소
- 실패 복원: 클릭 실패 시 대체 경로와 운행 후 로그 분석
- 단순한 도구: 효과가 확인된 기능만 남김
- 수익 가능성: 시간당 매출 개선 관찰 – 외부 기사에게 추가 검증
4. 프로토 페르소나 A – 빠른 판단형 숙련기사
김현우 · 수익 기회 최적화형
합성 가정 플랫폼 오더를 직접 고르는 숙련 기사 · 익숙한 지역에서 반복 운행 · 오더 조건을 빠르게 비교 · 기능 수보다 반응속도를 중시
“좋은 오더는 생각하는 사이에 없어집니다. 필요한 정보만 보고 바로 판단할 수 있어야 해요.”
| 핵심 목표 | 가까운 수익성 높은 오더 확보, 공차·대기시간 감소, 시간당 매출 향상 |
|---|---|
| 핵심 고충 | 짧은 노출시간, 상세 진입 지연, 클릭 실패, 불필요한 조건·팝업 |
| 중요 기능 | 자동상세진입, 후보 검색 최적화, 현재 목적지·요금 판단, 빠른 확정 |
| 검증 질문 | 몇 초의 지연부터 오더 손실로 느끼는가? 자동 진입이 판단시간과 수락률을 실제로 얼마나 바꾸는가? |
5. 프로토 페르소나 B – 2폰 안전운영형 기사
박민수 · 조작 최소화형
합성 가정 오더폰과 내비폰을 분리해 사용 · 주소 재입력과 기기 전환에 부담 · 최고 속도뿐 아니라 연결 안정성과 운행 중 안전을 중시
“오더폰에서 본 주소가 내비폰으로 자연스럽게 이어지면 화면을 덜 만져도 됩니다.”
| 핵심 목표 | 주소 확인부터 길 안내까지 단순 연결, 운행 중 조작 감소, 오류 시 사후 원인 확인 |
|---|---|
| 핵심 고충 | 주소 재입력, 두 기기 전환, 동기화 실패, 복잡한 설정, 운행 중 주의 분산 |
| 중요 기능 | TMAP 바로 실행, 선택형 AWS 주소 동기화, 6자리 방 코드, 핵심 로그 |
| 검증 질문 | 2폰 사용 비율은 얼마나 되는가? 주소 동기화가 터치 수와 오류를 실제로 얼마나 줄이는가? |
6. 두 페르소나 비교와 우선순위 그래프
공통 가치
빠르면서도 안전하고 예측 가능한 오더 처리
- 핵심정보에 집중
- 반복 조작 감소
- 실패 시 복원 가능한 흐름
- 수익에 직접 기여하는 기능 우선
상충 가능성
- A는 최고 반응속도, B는 연결 안정성을 더 중시
- 자동화 수준이 높을수록 속도는 오르지만 안전·통제 요구가 커짐
- 해결 원칙: 자동 수락은 제외하고 자동 진입·정보 제시까지만 보조
- 동기화는 기본 강제가 아닌 선택 기능으로 유지
팀 우선순위 점수이며 사용자 설문 결과가 아닙니다. Mission 2 테스트 후 수정합니다.
7. 분석 결과가 개발 결정으로 이어진 과정
| 고객 진전 | 유지·강화 | 제거·후순위 | 판정 근거 |
|---|---|---|---|
| 좋은 오더를 더 빨리 판단 | 자동상세진입, 후보 검색, 확정 우선순위 | 부가 UI·과도한 로그 | 상세 진입이 첫 관문 |
| 클릭 실패로 기회 손실 방지 | ACTION_CLICK 실패 시 좌표 탭 | 같은 실패 경로 반복 | 복원 속도가 중요 |
| 현재 조건에만 집중 | 선택한 목적지·요금 판단 | 이전 확정 오더와 행정구역 비교 | 현장 운영 의도와 불일치 |
| 주소·내비 조작 감소 | TMAP, 선택형 AWS 동기화 | 오더추적과 섞인 복잡한 흐름 | 2폰 주소 연결은 별도 가치 |
| 수익에 직접 기여 | 효과가 확인된 핵심 루프 | 성공 사례 없는 오더추적 | 현장 성공 사례 0건으로 제거 |
8. AI 분석 프롬프트와 검증 계획
CatchPro 개발일지와 현장검증일지만 근거로 사용한다.
1. 기능 설명이 아니라 고객이 이루려는 진전을 JTBD로 작성한다.
2. 개발 기록에서 Pain과 Gain의 근거 문장을 연결한다.
3. 행동이 다른 고객군을 프로토 페르소나로 나누고, 인구통계 가정은 표시한다.
4. 유지·제거된 기능이 어떤 고객 문제와 연결되는지 표로 설명한다.
5. 시간당 매출 3만원은 개발자의 반복 운행 관찰 성과로 표현하고 외부 검증 전임을 표시한다.
6. 인터뷰로 확인되지 않은 내용은 추가 검증으로 남긴다.| 검증 항목 | Mission 2 측정 | Persona 수정 기준 |
|---|---|---|
| 판단시간 | 미사용 대비 중앙값 30% 단축 | 속도 가치의 중요도 확정·조정 |
| 상세 진입·TMAP | 각 95% 이상 성공 | A·B의 기능 우선순위 조정 |
| 매출 재현성 | 3만원 이상 운행 50% 이상 | 수익 Gain의 표현 강화 또는 축소 |
| 계속 사용 의향 | 5명 중 4명 이상 | 주 고객 유형과 메시지 확정 |
| 안전 문제 | 중대한 문제 0건 | 1건이라도 발생하면 즉시 자동화 범위 축소 |
9. Mission 3 결론
CatchPro의 고객은 단순히 ‘운송 기사’가 아닙니다. 짧은 기회 창 안에서 수익성 있는 오더를 직접 선택하고, 운행 중 조작을 줄이면서 확실하게 길 안내까지 연결해야 하는 기사입니다. 따라서 제품의 핵심 가치는 기능 수가 아니라 빠른 판단, 성공 가능한 실행, 안전한 연결입니다.
현재 두 Persona는 실제 개발·현장 기록을 바탕으로 한 프로토타입입니다. Mission 2의 5명·2주 현장 테스트와 인터뷰가 끝나면 실제 행동 차이에 따라 통합하거나 세분화합니다.
CatchPro SWOT·TOWS 분석과 2주 Action Plan
개발·현장기록을 전략으로 바꾸고, 결론이 다음 개발 작업과 측정·의사결정으로 이어지도록 구성했습니다.
검증된 기록아직 가설다음 측정
1. 분석 근거와 한계
자동 상세 진입, 조건 판단, TMAP·AWS 동기화
반응속도 병목과 실패 원인
오더 추적 제거, 핵심 루프 집중
시간당 매출 3만원 반복 달성
5명·2주 반복성 확인
시간당 매출 3만원은 개발자의 반복적인 실제 운행 관찰 결과입니다. 전체 기사 평균·보장수익 또는 통제 실험 결과로 해석하지 않습니다.
2. CatchPro SWOT
- 실제 운행 문제에서 시작한 기능형 MVP
- 자동 상세 진입·조건 판단·확정의 짧은 핵심 루프
- TMAP 연결과 2폰 AWS 주소 동기화
- 실패 로그를 바탕으로 반복 개선하는 개발 방식
- 효과가 없었던 오더 추적 기능을 제거한 집중력
- 시간당 매출 3만원 달성 사례 보유
- 성과가 개발자 본인의 반복 관찰 중심
- 판단시간·성공률·매출 비교 데이터가 표준화되지 않음
- 외부 앱 UI·접근성 구조 변화에 의존
- ACTION_CLICK 실패 시 좌표 탭 보조의 취약성
- 배포·결제·고객지원 모델이 아직 검증되지 않음
- 안전성과 운영정책 적합성 검토 필요
- 짧은 시간 안에 오더를 판단해야 하는 현장 문제
- 운행 중 반복 조작을 줄이는 안전·편의 수요
- 2폰 운영과 내비게이션 연결의 명확한 사용 상황
- 소규모 기사 체험단으로 빠르게 검증 가능
- 운행 로그 기반 생산성 도구로 확장 가능
- 원본 앱 UI·접근성 이벤트 변경으로 인한 기능 중단
- 플랫폼 운영정책·자동화 허용범위 변화
- 운행 중 조작 또는 오작동에 따른 안전 위험
- 지역·시간대·기사 숙련도에 따른 성과 편차
- 플랫폼 자체 기능이나 유사 도구의 등장
3. TOWS 실행전략
| 전략 | 요인 조합 | CatchPro 실행안 | 확인 지표 |
|---|---|---|---|
| SO · 강점으로 기회 확대 | 현장형 MVP·핵심 루프 × 빠른 판단·조작 감소 수요 | 기능 추가보다 판단시간과 상세 진입 성공률을 증명하고 기사 체험단에 확장 | 판단시간, 성공률, 계속 사용 의향 |
| ST · 강점으로 위협 방어 | 로그·빠른 개선 × 외부 UI 변화·안전 위험 | 선택자·접근성·좌표 보조를 단계화하고 실패 시 자동 중단하는 안전장치 적용 | 오탭률, 중단률, 중대한 안전 문제 |
| WO · 약점을 보완해 기회 활용 | 데이터 부족 × 소규모 검증 가능성 | 5명·2주 교차 운행으로 미사용·사용 데이터를 동일 조건에서 수집 | 30회·60시간, 로그 완전성 95% |
| WT · 약점과 위협 동시 축소 | 외부 앱 의존·안전 검증 부족 × 정책·오작동 위험 | 자동화 범위를 최소화하고 개인정보·정확한 위치를 저장하지 않으며 중단 기준을 선행 확정 | 정책 검토, 개인정보 경고 0건, 안전사고 0건 |
4. 이번 분석으로 결정한 것
5. 다음 2주 Action Plan
| 기간 | Action | 산출물 | 완료 기준 |
|---|---|---|---|
| 1~2일 | 리스트 감지·상세 진입·조건 판정·확정·TMAP 연결 시간 이벤트 표준화 | 측정 이벤트 정의서와 로그 스키마 | 핵심 이벤트 기록률 95% 이상 |
| 3일 | 개인정보·오더번호·정확한 위치를 제외한 테스트 양식 확정 | 안전·개인정보 체크리스트 | 민감정보 수집 항목 0개 |
| 4~7일 | 기사 5명 미사용 기준 운행과 설치·교육 | 참여자별 기준선과 설치 결과 | 각 3회, 회당 최소 2시간 기준 확보 |
| 8~12일 | CatchPro 사용 운행, 실패 구간만 부분 개선 | 사용 운행 로그·오류 분류 | 각 3회, 전체 기능 성공률 집계 |
| 13일 | 계속 사용 의향·불안·불편 인터뷰 | 5명 인터뷰 요약 | 응답 누락 0명 |
| 14일 | 미사용·사용 비교와 Go/Improve/Stop 판정 | Mission 4 검증 결과표 | 결정과 다음 버전 범위 확정 |
6. 성공 지표와 우선순위
위 수치는 향후 검증의 성공 기준이며 현재 달성 결과가 아닙니다. 시간당 매출은 동일 시간대·지역 조건의 미사용 운행과 함께 비교합니다.
7. Go / Improve / Stop 판단 기준
| 판정 | 조건 | 다음 행동 |
|---|---|---|
| GO | 판단시간 30% 단축, 상세·TMAP 95%, 사용 의향 4/5 이상, 중대한 안전 문제 0건 | 기능 범위를 유지하고 제한된 체험단을 확대 |
| IMPROVE | 판단시간은 개선되지만 성공률 85~94%이거나 매출 효과가 불분명 | 실패 모듈만 수정하고 동일 조건으로 2주 재검증 |
| STOP | 중대한 안전 문제 1건 이상, 판단시간 개선 없음, 외부 앱 변화로 안정적 동작 불가 | 자동화 범위를 축소·중단하고 보조 정보 도구로 재설계 |
8. Action Plan 관점의 결론
CatchPro는 현장 문제를 해결하는 기능형 MVP와 실제 달성 사례를 보유했지만, 지금 필요한 것은 더 많은 기능이 아니라 반복성 증명입니다. 앞으로의 결론은 무엇을 알았는가에서 끝내지 않고 무엇을 언제 실행하고 어떤 수치로 다음 개발 여부를 결정할 것인가까지 기록합니다.
근거: CatchPro 개발일지, 핵심 속도 개선 기록, 현장검증 기록과 사용자 확인 성과. 시장성·다수 사용자 효과는 Mission 4 실행 후 확정합니다.
11. 검증된 내용과 추가 검증이 필요한 가설
| 구분 | 내용 |
|---|---|
| 구현·현장 확인 | 핵심정보 인식, 자동 상세 진입, 반응속도 개선, 목적지 확인과 TMAP 연결, 로그 기반 반복 개선 |
| 기능 제거로 확인 | 오더 추적은 현장 효과가 낮아 제거하고 핵심 흐름에 집중 |
| 사용자 확인 성과 | CatchPro 사용 운행일 중 약 80%에서 시간당 매출 3만원 달성 관찰 |
| 추가 검증 필요 | 운행 지역·시간대·기사별 반복 재현성, 장기간 평균 매출, 안전성과 조작 감소 효과의 정량 측정 |
12. 다음 개발 계획과 회고
다음 단계에서는 매출 사례를 운행 조건과 함께 익명 기록하고, 오더 확인 시간·화면 전환 수·TMAP 연결 성공률을 정량화할 계획입니다. CatchPro 개발에서 가장 큰 배움은 기능을 많이 넣는 것보다 현장에서 실제로 쓰이는 흐름을 빠르게 검증하고, 효과가 낮은 기능을 제거하는 일이 가치 제안을 더 선명하게 만든다는 점입니다.