가까운 오락실 몇 곳을 보고 싶은 이용자가 전국의 오락실 정보를 먼저 내려받아야 할 필요가 있을까? 초기에는 전체 목록이 크지 않아 브라우저에서 거리를 계산하는 방식도 가능했다. 그러나 한국에서 시작한 뮤즈캣이 올해 하반기 해외로 확장하면서, 목록을 모두 받은 뒤 가까운 곳을 고르는 방법을 계속 유지하기 어려워졌다.
홈 화면은 전체 오락실을 받아 이용자와 각 장소 사이의 거리를 계산했다. 장소가 200곳을 넘으면서 부담이 커졌고, 300곳에 가까워지자 첫 화면에 쓰지 않는 자료도 함께 전송됐다. 검색용 목록과 거리 계산용 목록이 별도 API에 있어 비슷한 자료를 두 번 받는 경우도 있었다.
기존 홈 화면(2025-07-01 코드 재현 · 합성 예시 데이터). 서버로 거리 계산을 옮기기 전 탐색 화면.
지난해 키워드 검색을 서버로 옮겼지만, 홈의 거리 계산은 여전히 전체 목록을 사용했다. 올해는 첫 로딩이 3초를 넘고 약 5초까지 걸리는 문제가 나타났다. 예를 들어 서울 주변을 찾는 요청에도 멀리 떨어진 장소의 정보가 필요했던 것이다. 해외 장소를 추가할수록 이 요청의 준비 과정부터 길어지는 구조였다.
주변 탐색에서는 어느 위치에서 어떤 조건으로 찾는지가 먼저 정해진다. 그래서 브라우저가 그 위치와 조건을 보내면, 서버가 거리를 계산하고 필터링과 정렬을 마친 결과를 돌려주도록 바꿨다. 이용자의 화면에는 선택한 조건에 맞는 장소만 전달한다.
데이터베이스를 바꾸는 방법도 별도의 검토 대상이지만, 전체 목록을 내려받는 방식은 저장소만 바꿔도 남는다. 이번에는 그 의존부터 줄이기로 했다. 키워드 검색이 검색어를 보내 결과를 받는 것처럼, 주변 탐색도 위치와 조건을 기준으로 요청하도록 맞춘 것이다.
서버는 탐색 좌표와 각 장소 사이의 거리를 계산하고, 조건에 맞는 후보를 가까운 순서로 정리한다. 브라우저는 이 결과를 표시한다. 전체 자료를 내려받은 다음 같은 계산을 시작하던 과정이 없어져, 화면이 필요한 결과를 직접 받을 수 있다.
탐색 위치는 검색의 기준점이다. 현재 위치를 사용할 수도 있고 방문할 지역을 정할 수도 있다. 예를 들어 여행할 도시를 기준으로 찾은 거리는 현재 내 위치에서의 거리가 아니다. 이 기준을 분명하게 두어야 결과를 해석할 수 있으며, 검색 위치를 보냈다고 실제 방문을 인증한 것으로 처리하지도 않는다.
이제 가까운 몇 곳을 보여 주기 위해 전체 데이터베이스를 전송할 필요가 없어졌다. 장소가 늘어나도 화면이 받는 자료를 관련 결과로 좁힐 수 있고, 거리 계산과 필터 및 정렬도 서버에서 함께 처리한다. 글로벌 확장을 위해 목록 전체를 계속 크게 보내는 방식을 피할 수 있게 됐다.
다만 계산을 서버로 옮겼으므로 요청이 늘면 후보를 찾고 거리를 계산하는 비용도 서버에 모인다. 장소 수정이 검색 결과에 언제 반영되는지도 관리해야 한다. 우선 전체 목록을 받아야만 화면을 만들 수 있던 구조를 바꿨으며, 남은 비용은 실제 요청과 사용량을 보며 확인할 계획이다.
참고: 뮤즈캣 엔지니어링 기록.