🤖
2704 in / 1708 out / 4412 total tokens
모바일 화면 최상단에 출발지·도착지 입력란이랑 장소 검색란이 같이 있던 걸 분리했다. 검색 진입점은 하나만 남기고, 경로 편집은 별도 모드로 빼는 게 사용자에게 낫다고 판단해서다.
기존 MobileSearchEntry 컴포넌트는 startAddress, endAddress를 prop으로 받아서 강남역 → 서울역 같은 경로 라벨을 보여주고 있었다. 근데 모바일 화면에서 경유지 검색하려고 들어갔는데 출발지·도착지가 먼저 보이면, 유저는 이게 "경로를 입력하는 곳"인지 "장소를 찾는 곳"인지 헷갈린다. 카페 찾고 싶은데 왜 출발지부터 입력하라고 하지? 하는 느낌.
그래서 startAddress, endAddress prop을 MobileSearchEntry와 SearchOverlay에서 몽땅 뺐다. 대신 라벨을 어디를 경유할까요?로 바꿔서, 이 화면이 경유지/장소를 검색하는 곳이라는 걸 명확히 했다.
tsx
// Before
const routeLabel = startAddress && endAddress
? ${startAddress} → ${endAddress}
: '어디로 갈까요?';
// After
const searchLabel = hasResults
? ${category || '장소'} 추천 결과
: '어디를 경유할까요?';
SearchOverlay 쪽에서도 검색 결과로 출발지/도착지를 자동 세팅하던 로직을 제거했다. 장소 검색은 장소 검색대로, 경로 편집은 경로 편집대로 각자 역할을 명확히 하는 게 맞다.
테스트도 함께 고쳤다. 기존 테스트는 출발지를 입력하세요, 도착지를 입력하세요 placeholder가 있는지 검증하고 있었는데, 이걸 "경로 편집 입력이 숨겨져 있는지" 검증하는 방향으로 바꿨다. E2E 테스트도 어디로 갈까요? → 어디를 경유할까요?로 업데이트.
UX 결정 문서를 docs/design/에 남겼다. 왜 두 입력을 섞으면 안 되는지, 초기 화면은 어떤 역할만 가져야 하는지 적어뒀다. 나중에 다시 이 결정을 돌아볼 때 맥락을 알 수 있게.
삽질 포인트는 page.tsx에서 SavedRoute 타입 임포트가 더 이상 안 쓰이는데 남아있던 거. UI 변경하다 보니 이런 죽은 코드가 눈에 들어온다.
검색은 검색대로, 경로는 경로대로. 한 화면에 두 역할을 섞으면 둘 다 이상해진다.