오락실 이름 몇 글자를 검색하려고 전체 오락실 정보를 먼저 받아야 할까? 브라우저 안에서 검색하려면 비교할 목록이 필요하다. 작은 목록에서는 단순한 방법이지만, 오락실이 약 300곳에 가까워지면서 검색하지 않을 장소까지 내려받는 비용이 커졌다.

Gamma에서는 검색어를 서버로 보내 관련된 장소만 받는 방식으로 바꿨다. 특히 가까운 장소의 거리를 계산하는 목록과 검색용 목록이 서로 다른 API에서 비슷한 데이터를 내려주고 있었으므로, 검색 자료의 전송부터 줄일 필요가 있었다.

브라우저 검색의 준비 비용

브라우저 검색은 받은 목록을 입력한 문자열과 비교해 결과를 고르는 방식이다. 예를 들어 특정 점포 이름을 찾더라도, 그 이름이 목록 어디에 있을지 판단하려면 먼저 모든 후보를 가지고 있어야 한다. 입력 후 비교가 간단하다는 장점은 있지만, 검색을 시작하기 전의 준비량이 목록 전체 크기에 따라 늘어난다.

기존 화면은 검색을 위한 자료와 거리 계산용 자료를 별도로 받았다. 같은 장소가 큰 응답에 반복해서 포함되면 초기 화면을 여는 사람도 그 비용을 부담한다. 이용자가 필요한 결과에 비해 전송 범위가 넓어진 상황이다.

기존 Beta 검색 화면(2023-12-25 코드 재현 · 샘플 데이터). 당시에는 받은 목록에서 검색어를 비교했다.

flowchart TD
    accTitle: 이전 검색의 준비 비용
    accDescr: 브라우저가 전체 데이터를 받은 뒤 입력한 검색어로 결과를 골랐다.
    A["전체 오락실 목록 전송"] --> B
    B["브라우저에 목록 준비"] --> C
    C["검색어로 결과 필터"]

키워드 검색 API

API는 화면이 서버에 필요한 작업을 요청하는 통로다. 검색 API에는 현재 키워드를 보내고, 서버가 관련 오락실을 찾아 결과로 돌려주게 했다. 브라우저에서 전체 후보를 비교하던 작업을 서버의 조회로 옮기는 방식이다.

이렇게 하면 한 점포를 찾기 위해 모든 검색 자료를 미리 준비할 필요가 줄어든다. 반면 검색할 때마다 통신이 필요하므로, 전체 다운로드를 없앤 뒤에는 입력에 따른 요청 횟수도 고려해야 한다.

flowchart TD
    accTitle: 키워드 중심 요청
    accDescr: 입력이 유지되면 키워드를 보내고 관련 장소만 받는다.
    A["검색어 입력"] --> B
    B["입력 대기"] --> C
    C["서버에 키워드 요청"] --> D
    D["관련 결과 표시"]

입력 대기와 결과 조회

검색어는 한 번에 완성되지 않는다. 예를 들어 이름을 몇 글자 입력하는 동안 중간 문자열마다 요청하면, 이용자는 완성된 검색어의 결과를 기다리면서도 앞선 응답을 계속 받게 된다. 그래서 입력이 잠시 유지됐을 때 조회하는 대기를 둔다. 입력이 멈춘 뒤 요청하는 이 방식을 디바운스라고 부른다.

화면은 현재 검색어를 관리하고 서버의 결과를 표시한다. 이번 이전은 검색에 해당하며, 홈에서 거리를 계산하기 위한 목록까지 모두 서버로 옮긴 것은 아니다. 같은 오락실 데이터라도 두 기능의 요청을 별도로 개선해야 한다.

flowchart TD
    accTitle: 이번 변경과 남은 거리 계산
    accDescr: 검색의 전체 목록 의존성을 줄이고 홈 거리 계산의 부담은 별도로 남긴다.
    A["검색 전용 요청"] --> B
    B["검색용 전체 목록 전송 제거"] --> C
    C["홈 거리 계산은 별도 과제"]

초기 로딩의 개선과 통신 의존

이번 작업에서는 초기 로딩이 약 1초 줄어드는 것을 확인했다. 검색용 전체 목록을 먼저 받던 과정이 사라진 데 따른 관측값이다. 기기와 통신 환경이 달라지면 같은 시간이 줄어든다고 보기는 어렵다.

서버 검색은 연결 지연이나 응답 실패의 영향을 받는다. 검색어가 빠르게 바뀔 때 어떤 입력의 결과인지 맞춰 표시하는 일도 필요하다. 이름과 별칭이 부정확하거나 자료가 오래됐다면, 전송량을 줄여도 원하는 장소를 찾기 어려운 문제는 남는다.

참고: 뮤즈캣 엔지니어링 기록.

관련 업데이트

• 뮤즈캣 δ8 업데이트