- 검색 입력과 목록 조회가 하나의 페이지에 결합되어 있어, 입력 즉시 API 요청이 발생하는 구조였다.
- 한글 IME 입력 시 조합 중 상태에서도
input이벤트가 발생하여, 의도하지 않은 중간 문자열(예: ㄱ, 가, 갇) 로 검색 요청이 발생하는 문제가 있었다. - IME 조합을 존중하도록 정책을 변경하자, 이번에는 검색이 지연되는 것처럼 체감되는 UX 문제가 발생했다.
- 즉시성(Real-time Search)과 한글 조합 안정성(IME Safe Policy) 사이에서 트레이드오프가 발생했다.
현재 구조는 다음과 같다.
- 상단 검색 입력
- 동일 페이지에서 목록 즉시 갱신
- 검색어 변경 → API 재요청 → 리스트 교체
즉, "입력 이벤트 = 네트워크 요청 트리거"로 강하게 결합되어 있었다.
이 구조에서는 입력 정책이 곧 네트워크 정책이 된다.
한글 입력은 다음과 같은 특징을 가진다.
- 키 입력 ≠ 글자 완성
- 조합 중에도
input이벤트가 발생 - 최종 문자열은
compositionend시점에 확정
따라서 단순 debounce(input) 기반 실시간 검색은
- 영문 입력에서는 자연스럽지만
- 한글 입력에서는 중간 조합 문자열로 요청이 발생하거나
- 조합 종료까지 검색이 보류되어 UX가 느려지는 현상이 발생한다.
| 정책 | 장점 | 단점 |
|---|---|---|
| 조합 중 요청 차단 | 정확한 검색어 보장 | 검색이 늦게 체감됨 |
| 조합 중에도 debounce 허용 | 즉시성 확보 | 중간 문자열 요청 발생 |
이 문제는 단순 구현 이슈가 아니라, 정책 선택의 문제임을 인지하게 되었다.
compositionstart/compositionend이벤트 활용- 조합 중에는 서버 요청 보류
- 조합 종료 시 1회 flush
이를 통해 중간 자모 문자열로의 요청을 방지했다.
- 입력은 항상 즉시 반영 (
query) - debounce를 통해 네트워크 요청 빈도 제어
- debounce 만료 시점에 조합 중이면 요청 보류
compositionend시 즉시 요청 flush
이 정책은 다음을 동시에 만족한다.
- 영문 입력 → 자연스러운 실시간 검색
- 한글 입력 → 조합 확정 후 안정적 검색
검색과 조회가 하나의 페이지에 결합되어 있기 때문에, 입력 정책이 곧 네트워크 정책이 되는 구조적 제약이 있음을 인지했다.
대안으로 다음 구조를 고려했다.
- Enter 기반 검색 트리거
- 별도 검색 결과 페이지로 분리
- 로컬 캐시 기반 즉시 필터 + 서버 검색 분리
현재는 MVP 단계이므로 기존 구조를 유지하되 정책을 정교화하는 방향을 선택했다.
- 한글 조합 중 중간 문자열로의 API 요청 제거
- 영문 입력 시 debounce 기반 실시간 검색 유지
- IME 입력 UX와 실시간성 사이의 균형 확보
- 입력 정책과 네트워크 정책의 관계를 명확히 인식
이번 이슈를 통해 깨달은 점은 다음과 같다.
- 실시간 검색은 단순히 debounce의 문제가 아니다.
- IME 입력 모델을 이해하지 않으면 UX 문제를 반복하게 된다.
- 입력과 조회가 강하게 결합된 화면 구조에서는 정책 선택이 매우 중요하다.
- 기술적 문제처럼 보이지만 실제로는 "UX 정책과 아키텍처 선택"의 문제였다.
특히, 한글 입력은 브라우저 이벤트 모델을 깊이 이해해야만 올바르게 다룰 수 있다는 점을 체감했다.
즉시성과 정확성 사이의 균형을 어떻게 설계할 것인지에 대한 고민은 앞으로의 검색 UX 설계에서도 중요한 기준이 될 것이다.