관광 앱 검색·필터·거리순 정렬 설계 (로컬 DB vs 서버 API 분리하기)
제주에서 이런저런 관광 관련 앱이나 웹 서비스를 만들다 보면 가장 손이 많이 가고 복잡한 게 바로 '검색'과 '필터' 기능입니다. 사용자들은 단순히 "제주시 카페"만 찾는 게 아니라, "아이와 갈 만한 곳", "지금 내 위치에서 가까운 곳", "오늘 문 연 곳" 처럼 온갖 조건을 조합해서 장소를 찾기 때문입니다. 이걸 매번 화면 상태값으로만 대충 비벼서 처리하거나, 모든 필터를 서버 API 하나에 몰아넣으면 나중에 운영할 때 무조건 한계가 옵니다. 반대로 로컬 DB에 다 밀어 넣자니 실시간 영업 상태나 행사 정보 같은 데이터 동기화가 발목을 잡죠. 저도 매번 구현할 때마다 헷갈리는 부분이 있어서, 공공데이터 기반 관광 앱을 개발할 때 검색·필터·정렬의 역할을 어떻게 나누고 구조를 잡아야 하는지 실무 기준으로 정리해 둡니다. 이래저래 운영하다 보면 생기는 문제들 처음에 설계를 대충 하면 꼭 아래와 같은 버그나 운영상 난관에 부딪힙니다. 화면마다 지역, 카테고리 필터 처리하는 로직이 제각각이다. 앱 로컬에 저장된 정적 데이터랑 서버 API가 뱉는 필터 결과가 안 맞아서 목록이 튄다. 사용자가 위치 권한을 거부했는데, 앱이 거리순 정렬을 기본값으로 잡고 있어서 먹통이 된다. 필터 조건이 너무 많아져서 사용자가 지금 자기가 뭘 선택했는지도 모른다. 공공데이터 포털에서 준 카테고리 코드가 앱 UI 디자인이랑 1:1로 매핑이 안 된다. 디버깅 한답시고 실제 API URL이나 사용자 위치 좌표(위경도)를 로그나 공개 글에 그대로 남기는 보안 실수를 한다. 결국 검색 필터는 단순한 UI 옵션이 아니라 데이터 모델, API 계약, 로컬 캐시, 위치 권한 이 다 얽혀 있는 기능으로 보고 접근해야 합니다. 1. 필터 상태는 전용 데이터 모델(Model)로 묶기 필터 조건을 뷰(View)나 화면 상태 변수로만 들고 있으면 화면이 회전되거나 프로세스가 죽었다 살아날 때 다 날아갑니다....