🤖
2055 in / 1657 out / 3712 total tokens
MidWayDer 모바일 경로 탐색 UX를 네이버지도 흐름에 맞추기 위해, 구현 전 기준 문서부터 잡았다. 스크린샷 4장(검색 홈, 장소 상세, 경로 설정, 경로 결과)을 분석해서 상태 모델 4단계(idle → placeSelected → routeEditing → results)로 정리했다. 색상이나 스타일이 아니라 화면 구조, 상태 전환, 정보 밀도, 조작 흐름을 맞추는 게 목적이다.
이걸 왜 하냐면, 기존에 UX 흐름이 애매했다. 검색에서 바로 경로 결과로 넘어가는 건지, 중간에 편집 단계가 있는 건지 명확하지 않았다. 네이버지도는 검색 → 장소 상세 → 경로 설정 → 경로 결과가 분리되어 있으면서도, 상단 입력 카드와 교통수단 탭을 계속 유지해서 사용자가 언제든 돌아갈 수 있게 해놨다. 이걸 MidWayDer에 어떻게 녹일지 계약을 정해둔 거다.
MobileHomeShell에서 결과 시트의 transition을 제거했다. transition-[max-height] duration-300 ease-out → transition-none. max-height 트랜지션이 60fps를 안 나와서 뺐다. 모바일에서 특히 더 끊기는데, will-change를 줘봐도 레이어 생성 비용이 더 크다. 그냥 토글 방식으로 바로 보여주는 게 낫다.
SearchOverlay에 Home, Building2, Bookmark 아이콘을 추가했다. 집, 회사, 즐겨찾기를 빠른 접근으로 넣으려는 거다. 69줄 추가, 35줄 삭제한 걸 보면 구조 정리도 같이 했다. 아이콘 임포트만 추가한 게 아니라, 검색 홈 화면에서 즐겨찾기/빠른 접근 섹션을 새로 구성한 거다. 아마 장소 상태 선택 후 경로 편집으로 넘어가는 플로우에서 출발지/도착지 빠른 입력용일 거다.
설계 문서만 250줄이다. 구현 전에 상태 전환과 컴포넌트별 계약을 문서화해두면, 나중에 상태 꼬이는 걸 사전에 방지할 수 있다. UE5에서도 Gameplay Ability System 적용 전에 어빌리티 스펙 문서부터 쓰는 거랑 같은 이유다.
다음 할 일은 이 문서 기준으로 실제 상태 관리 로직을 구현하는 거다. 상태 머신은 간단하게 useEffect 기반으로 갈지, useReducer로 갈지 고민 중이다.
기준 없이 구현하면 나중에 다시 짠다. 문서 250줄이 리팩터링 2500줄을 아껴준다.