오늘 개발 키워드
- CatchPro 고도화
- 자동상세진입 반응속도
- 핵심 기능 집중
- 오더추적 제거
- TMAP 연결 단순화
- 현장검증 로그
- research.md 업데이트
오늘 CatchPro 개발 방향은 분명했다. 기능을 계속 늘리는 것이 아니라, 실제 운행에서 오더를 잡는 데 직접 도움이 되는 기본 기능을 강화하고, 현장에서 효과가 없었던 기능은 과감히 덜어내는 쪽으로 정리했다.
가장 중요한 목표는 오더 리스트에 새 오더가 보였을 때 최대한 빠르게 상세 화면으로 들어가는 것이다. 자동확정 조건이 아무리 정교해도, 상세 진입이 늦거나 실패하면 실제 현장에서는 오더를 놓칠 수 있다. 그래서 오늘은 CatchPro의 중심을 다시 자동상세진입 속도와 안정성으로 맞췄다.
개발일지
| 개발 항목 | 오늘의 결정 | 이유 |
|---|---|---|
| 자동상세진입 | 오더 리스트 감지 후 최우선 루프로 분리 | 오더를 잡는 첫 관문이 상세 진입이기 때문이다. |
| ACTION_CLICK 실패 대응 | 접근성 클릭 실패 시 좌표 탭 보조로 즉시 전환 | 접근성 클릭이 실패해도 화면상 행을 누를 수 있으면 상세 진입 가능성을 높일 수 있다. |
| 상세 미진입 대기 | 불필요한 대기 시간을 줄이는 방향으로 정리 | 현장에서는 몇 초의 지연도 오더를 놓치는 원인이 될 수 있다. |
| 반경 필터 확인 | 매번 확인하지 않고 캐시하는 방향으로 정리 | 리스트가 자주 갱신되는 상황에서 반복 확인 비용을 줄이기 위해서다. |
| 핫패스 로그 | 상세진입 핵심 루프에서는 로그를 줄이는 방향으로 정리 | 운행 중 핵심 루프는 판단보다 반응속도가 우선이다. |
| 오더추적 | 화면과 실행 경로에서 제거 | 지금까지 실제 운행에서 오더추적으로 자동확정된 사례가 없었기 때문이다. |
| TMAP 연결 | 주소 저장, TMAP 실행, AWS 주소 동기화용으로 유지 | 오더추적과는 분리하되, 2폰 운영에서 주소칸을 맞추는 선택 기능은 필요할 수 있기 때문이다. |
| 문서화 | research.md에 현재 구조와 제거 범위를 업데이트 | 나중에 다시 개발할 때 왜 이런 판단을 했는지 추적하기 위해서다. |
오늘 구현 방향을 내 언어로 정리하기
오늘의 핵심은 기능 정리였다. 그동안 CatchPro에는 자동확정, 오더추적, TMAP 연결, 상세주소 저장, AWS 동기화, 로그 분석 등 여러 기능이 붙어 있었다. 각각의 기능은 이유가 있었지만, 실제 운행에서 가장 중요한 순간은 하나였다. 오더가 뜨는 순간, 빠르게 상세로 들어가고, 조건이 맞으면 확정하는 것이다.
오더추적은 아이디어 자체는 좋았다. 기준 오더를 수행하는 동안 추가 오더까지 잡을 수 있다면 수익성이 좋아질 수 있기 때문이다. 하지만 실제 운행 로그를 보면 오더추적으로 자동확정된 사례가 없었다. 현장 검증에서 한 번도 성공하지 못한 기능이라면, 계속 붙잡고 있기보다 핵심 기능의 속도를 방해하지 않도록 정리하는 것이 맞다고 봤다.
TMAP 연결은 남겼다. 다만 역할을 바꿨다. 이제 TMAP 연결은 오더추적용 복잡한 흐름이 아니라, 인성앱에서 확인한 상세주소를 저장하고, TMAP으로 바로 실행하며, 운행 후 주소와 로그를 분석하기 위한 보조 기능으로 본다. 이후 2폰 운영에서 주소칸을 맞춰야 하는 상황을 고려해, AWS 실시간 주소 동기화는 TMAP 연결탭의 선택 기능으로 다시 복구했다.
현장검증일지
실제 운행에서 확인한 가장 큰 문제는 자동확정 조건 자체보다 오더 리스트에서 상세 화면으로 들어가는 반응속도였다. 자동확정모드를 켜고 운행할 때, 리스트에 오더가 보였는데도 상세로 들어가지 못하거나 늦게 들어가는 경우가 있었다. 이 문제는 조건 판단 이전의 문제다.
오더를 잡는 현장에서는 오더가 리스트에 보이는 시간 자체가 짧을 수 있다. 다른 기사가 먼저 잡으면 사라지고, 리스트가 갱신되면 클릭 대상도 바뀐다. 그래서 오더가 보이는 순간 상세로 들어가는 루프는 다른 작업보다 앞에 있어야 한다. 오늘 개발에서는 이 부분을 최우선 흐름으로 분리하는 방향을 정리했다.
오더추적은 실제 검증 결과가 좋지 않았다. 지금까지 추적으로 자동확정된 사례가 없었고, 설정과 판단 흐름이 복잡해지는 것에 비해 실익이 적었다. 그래서 현장 기준으로는 삭제하는 것이 맞다고 판단했다. 좋은 기능을 상상하는 것보다, 실제로 한 번이라도 잡혔는지가 더 중요하다.
문제점과 해결
| 현장 문제 | 원인 판단 | 개선 방향 |
|---|---|---|
| 오더가 보였는데 상세 진입이 늦음 | 상세진입보다 다른 파싱과 보조 판단이 먼저 끼어들 수 있음 | 오더 리스트 감지 후 최우선 자동상세진입 루프 실행 |
| 접근성 클릭이 실패하면 상세로 못 들어감 | ACTION_CLICK이 항상 성공하지 않음 | 실패 시 바로 좌표 탭 보조 실행 |
| 상단/하단 영역을 무작정 반복 클릭할 수 있음 | 실패 원인 구분 없이 반복 시도하는 흐름이 남아 있음 | 실패 시 같은 반복보다 즉시 보조 경로로 전환 |
| 반경 필터 확인이 반복됨 | 리스트 갱신마다 같은 상태를 계속 읽을 수 있음 | 필터 상태를 캐시해 핵심 루프 부담 감소 |
| 오더추적 성공 사례 없음 | 실제 운행에서 추가오더 자동확정으로 이어지지 않음 | 오더추적 화면과 실행 경로 제거 |
| TMAP 연결 흐름이 복잡함 | AWS 동기화와 오더추적 용도가 섞여 있었음 | 오더추적은 제거하고, AWS 주소 동기화는 TMAP 연결탭의 독립 선택 기능으로 복구 |
오늘 남긴 개발 기록
- 오더추적 기능은 실제 성공 사례가 없어 제거 대상으로 정리했다.
- TMAP 연결은 계속 유지하되, 오더추적과 분리했다.
- TMAP 연결의 역할을 인성 상세주소 저장, TMAP 바로 실행, 운행 후 분석용 기록으로 단순화했다.
- AWS 실시간 주소 동기화는 TMAP 연결탭의 선택 기능으로 다시 복구했다.
- 두 휴대폰에 같은 6자리 방 코드를 입력하면 주소 4칸이 WebSocket으로 자동 동기화되도록 다시 연결했다.
- 자동상세진입은 오더 리스트 감지 직후 최우선 루프로 실행하는 방향으로 정리했다.
- 접근성 클릭 실패 시 좌표 탭 보조를 빠르게 시도하는 방향으로 개선했다.
- 기준오더 자동확정에서 첫 번째 확정 오더와 두 번째 확정 오더의 도착지 행정구역을 비교하던 잔여 로직을 제거했다.
- research.md에 현재 구조, 제거된 기능, 남긴 기능의 이유를 업데이트했다.
추가 개선: 도착지 선택 조건만 보도록 정리
이후 검토 과정에서 예전 1차 오더 2개 묶기 로직이 아직 남아 있다는 점을 확인했다. 이 로직은 첫 번째로 확정된 오더와 두 번째로 확정하려는 오더의 도착지 구·군·동·읍·면 중 하나가 일치해야 두 번째 확정을 허용했다.
하지만 현재 운영 의도는 다르다. 예를 들어 전국 지역 도착지 선택에서 경기도 용인시 처인구를 선택했다면, CatchPro는 이전에 잡은 A오더와 비교하는 것이 아니라 현재 상세화면의 도착지가 처인구 조건에 맞는지만 봐야 한다. 인성앱에서 반경 2km로 리스트를 좁혀두고, CatchPro는 선택한 도착지 조건과 요금·거리·제외 키워드 조건만 판단하는 구조가 더 단순하고 현장 의도에 맞다.
그래서 기준오더 자동확정에서 첫 번째 확정 오더와 두 번째 확정 오더의 행정구역 일치 비교 로직을 제거했다. 이제 기준오더 자동확정은 이전 확정 오더가 아니라, 오더조건 탭에 설정된 현재 도착지 조건을 기준으로 판단한다.
추가 개선: AWS 주소 동기화 복구
TMAP 연결탭에는 AWS 실시간 주소 동기화 기능을 다시 살렸다. 오더추적 기능은 제거했지만, 2폰 운영에서 오더폰과 네비폰의 주소칸을 맞추는 기능은 별도 가치가 있기 때문이다. 이제 AWS 동기화는 오더추적과 섞이지 않고, TMAP 연결탭에서 필요할 때 켜는 독립 기능으로 동작한다.
구현은 단순하게 정리했다. 앱 시작 시 RouteAddressCloudSyncManager.start()를 다시 호출하고, TMAP 연결 화면에 AWS 실시간 주소 동기화 스위치와 6자리 방 코드 입력칸을 복구했다. 두 휴대폰에 같은 방 코드를 입력하고 스위치를 켜면 기준오더 A 상차지, 기준오더 A 하차지, 추가오더 B 상차지, 추가오더 B 하차지 주소칸이 같은 방 안에서 동기화된다.
동기화 과정도 운행 후 분석할 수 있게 유지했다. 연결, 조인, 주소 전송, 수신, 실패, 재연결 대기는 ROUTE_ADDRESS_CLOUD_SYNC 정밀 로그로 남는다. 그래서 실제 운행 중 주소가 동기화되지 않으면, 사용자가 운전 중 화면을 보지 않아도 운행 종료 후 원인을 다시 추적할 수 있다.
다음 현장검증 체크리스트
- 오더 리스트에 새 오더가 보인 뒤 상세 화면으로 들어가는 속도를 확인한다.
- ACTION_CLICK이 실패한 상황에서 좌표 탭 보조가 실제로 상세 진입을 돕는지 확인한다.
- 전체 필터 상태에서는 자동상세진입이 막히고, 10km 이하 반경 설정에서만 작동하는지 확인한다.
- 전국 지역 도착지를 선택했을 때 이전 확정 오더와 비교하지 않고 현재 선택한 도착지 조건만으로 판단하는지 확인한다.
- TMAP 연결 탭에서 인성 상세주소 저장과 TMAP 실행이 단순하게 작동하는지 확인한다.
- 두 휴대폰에서 같은 AWS 방 코드를 켰을 때 TMAP 주소 4칸이 자동 동기화되는지 확인한다.
- 운행 후 로그에서 상세진입 실패 원인을 다시 분석한다.
오늘의 결론
오늘 느낀 것은 명확하다. CatchPro는 기능이 많은 앱보다, 오더를 잡는 순간에 빠르게 반응하는 앱이어야 한다. 현장에서 한 번도 성공하지 못한 기능은 과감히 덜어내고, 실제로 돈과 시간에 영향을 주는 기본 기능을 더 단단하게 만드는 것이 맞다.
오늘의 다짐은 이것이다. 기능을 많이 붙이는 것보다, 현장에서 되는 기능을 빠르고 안정적으로 만드는 데 집중하겠다. CatchPro 고도화는 결국 실제 운행 로그와 현장 경험을 기준으로 계속 다듬어가는 과정이다.