검색이 훨씬 빨라졌습니다 — v1.0.2 & v1.0.3 업데이트
이번 주에 두 번의 빠른 패치를 배포했습니다. 둘 다 같은 목표에 집중했습니다: 검색이 정말로 즉각적으로 느껴지게 만드는 것.
무엇이 문제였는지
v1.0.1 출시 후 답답한 문제를 발견했습니다. 처음 검색은 잘 됐는데, 반복 검색이 느려지거나 결과가 안 나왔습니다. 더 심각한 건, 백그라운드에서 인덱싱이 돌아가면 검색이 5초 이상 멈출 수 있었습니다. 하루에 수십 번 쓰는 도구치고는 용납할 수 없는 수준이었습니다.
v1.0.2 — 검색 엔진 전면 재작성
전체 검색 파이프라인을 새로 작성했습니다.
근본 원인은 SQLite 쿼리 구조 문제였습니다. UNION ALL이 포함된 복합 SELECT 문에서 ORDER BY와 LIMIT이 제대로 적용되지 않았습니다. 이것만 고쳐도 폴더 검색 결과가 0개에서 정상으로 돌아왔습니다.
SQL 수정 외에도, 취소 로직을 분리해서 빠른 검색(파일명 매칭)과 전체 검색(내용 매칭)이 서로 간섭하지 않도록 했습니다. 이제 탭 전환이나 언어 변경 시에도 검색 결과가 사라지지 않습니다. 전용 읽기 전용 연결 풀 덕분에 검색 쿼리가 인덱싱 쓰기와 데이터베이스 접근을 놓고 경쟁하지 않습니다.
Data Setup 페이지도 눈에 띄게 빨라졌습니다 — 순차적으로 실행되던 상태 체크들이 이제 병렬로 실행됩니다.
v1.0.3 — 속도, 그리고 더 빠른 속도
v1.0.3은 하루 뒤 6개의 타겟팅된 수정과 함께 배포됐습니다.
가장 큰 개선은 push batch 시스템입니다. 대량 파일 스캔 중에 앱이 초당 수천 개의 개별 상태 업데이트로 UI를 폭격하고 있었습니다. 이제 그 업데이트들을 버퍼에 모아 200ms마다 한 번에 전송합니다. 활성 인덱싱 중 검색 응답이 3-4분에서 1초 미만으로 줄었습니다.
기타 변경사항: 파일명 검색이 LIKE 쿼리 대신 SQLite FTS5를 사용하고(6만 개 이상 파일에서 훨씬 빠름), 검색 단계가 순차가 아닌 병렬로 실행되며, 30초 내 반복 쿼리는 캐시된 결과를 즉시 반환합니다.
수치로 보면
| 시나리오 | 이전 | 이후 |
|---|---|---|
| 인덱싱 중 검색 | 5초 이상 | 1초 미만 |
| 동일 쿼리 반복 | 전체 재쿼리 | 즉시 (캐시) |
| 파일명 조회 | 순차 LIKE 스캔 | FTS5 인덱스 매칭 |
다음 단계
검색 품질은 모든 것의 기반입니다 — MCP 통합, 이메일 검색, 전부 다요. 이 두 패치로 검색 안정성 작업을 마무리합니다. 다음은 안정성을 유지하기 위한 테스트 인프라 구축입니다.
LocalSynapse 사용을 미루고 계셨다면, 지금이 좋은 타이밍입니다. GitHub Releases에서 최신 버전을 받아보세요.