왜 검색 모듈을 교체 가능하게 만드는가
블로그에 들어오는 쿼리는 성격이 다양하다.
- "RAG가 뭐야?" → 의미 기반 검색이 맞다
- "LangGraph 태그 달린 글 목록" → 메타데이터 필터가 맞다
- "nuartz 프로젝트 전체 내용" → 파일 직접 접근이 맞다
- "Nuartz랑 연결된 개념들" → 그래프 탐색이 맞다
- "context engineering" → 키워드 검색이 맞다 (한국어로 쓴 글이 없을 수 있으니)
단일 검색 전략으로는 이 모든 케이스를 커버하기 어렵다. 그렇다고 처음부터 모든 전략을 한 파이프라인에 우겨넣으면 뭐가 잘 되고 뭐가 안 되는지 파악하기 힘들다.
그래서 방향을 이렇게 잡았다:
- 각 검색 전략을 독립적인 모듈로 구현한다
- 파이프라인에서 모듈을 조합할 수 있게 만든다
- 같은 질문으로 다른 조합을 테스트하고 비교한다
레포 재편 맥락
이 프로젝트의 위치와 레포 구조는 Nuartz - Headless 설계와 레포 생태계 재편에서 다뤘다.
블로그 데이터의 특성
실험 전에 데이터를 먼저 이해해야 한다.
| 특성 | 내용 |
|---|---|
| 포맷 | Obsidian 마크다운 (wikilink, callout, 코드 블록 포함) |
| 언어 | 한국어 + 영어 혼용 |
| 카테고리 | AI, Dev, Projects, Study, Tools, Events, Others |
| 구조 | 단순 파일 + 폴더, wikilink로 연결된 그래프 |
| 길이 | 짧은 메모부터 긴 기술 문서까지 다양 |
한국어 혼용은 특히 중요한 변수다. 시맨틱 검색의 임베딩 품질, 키워드 검색의 토크나이징, 쿼리 언어 불일치 모두 영향을 받는다. Nuartz에서 한국어 검색을 위해 CJK-aware 토크나이저를 따로 구현했던 것처럼, 여기서도 신경 써야 할 부분이다. → Nuartz - 한국어 검색 구현
답하고 싶은 질문들
조합 효과
- Semantic + Keyword Hybrid가 각각 단독보다 항상 나은가?
- 메타데이터 사전 필터링이 시맨틱 검색 품질을 높이는가?
- 그래프 탐색을 추가하면 연관 노트 발견에 실질적인 차이가 있는가?
모듈별 특성
- 키워드 검색은 어떤 쿼리 유형에서 시맨틱 검색을 이기는가?
- 파일 직접 접근은 언제 쓰는 게 맞는가?
평가
- 어떤 방식으로 조합 간 품질을 정량 비교할 수 있는가?