벡터 검색을 지금 붙이지 않는 이유 — FTS와 source discipline 이후의 순서

memory 이야기를 하면 거의 바로 vector search가 나온다. embedding을 만들고, query와 비슷한 chunk를 찾고, RAG로 context를 넣으면 될 것처럼 보인다. 말만 보면 자연스럽다. 오케이징처럼 과거 대화, repo 파일, ticket, cron output이 계속 쌓이는 시스템에서는 더더욱 그렇다.

그런데 지금 단계에서 vector search를 먼저 붙이면 문제를 숨길 수 있다. 검색이 안 되는 이유가 embedding 품질 때문인지, source catalog가 엉망이라서인지, path boost가 없어서인지, 오래된 문서가 섞여서인지 구분하기 어려워진다. 그래서 순서를 일부러 늦췄다.

local-first Hermes memory의 현재 기준은 deterministic retrieval first다. SQLite catalog, FTS, path boost, source quality가 먼저다. 이 구조는 화려하지 않지만, 실패했을 때 이유를 추적하기 쉽다.

예를 들어 SEOJing 작업을 시작할 때 package.json, turbo.json, pnpm-workspace.yaml 같은 파일은 lockfile보다 우선되어야 한다. 이건 semantic similarity 문제가 아니라 작업 맥락의 문제다. embedding이 알아서 이 우선순위를 잡아주길 기대하면 안 된다.

그렇다고 vector search가 필요 없다는 뜻은 아니다. FTS는 단어가 맞아야 강하다. 사용자가 "아침마다 상황 정리해주는 거"라고 말했을 때, 실제 파일 제목이 briefing-automation-report-skill이면 FTS만으로는 놓칠 수 있다. 이런 경우 semantic retrieval이 도움이 된다.

다만 이때도 vector search는 첫 번째 권위가 아니라 recall 보조로 붙는 편이 낫다. 후보를 넓히고, 그 후보를 source quality와 freshness로 다시 거르는 구조가 더 안전하다.

이 흐름이면 vector search가 틀린 후보를 가져와도 마지막 단계에서 걸러질 수 있다. 반대로 vector result를 곧바로 context로 넣으면, 모델이 그럴듯한데 엉뚱한 근거를 붙들고 작업할 수 있다.

vector search를 붙이는 조건은 기능 구현보다 먼저 정해야 한다. 지금 기준에서는 최소한 아래 조건이 필요하다.

이 조건을 통과하지 못하면 vector search는 검색 개선이 아니라 opaque layer가 된다. 오케이징 memory의 원칙은 local-first와 source-linked인데, opaque retrieval은 그 원칙과 잘 맞지 않는다.

벡터 검색은 나중에 붙일 수 있다. 하지만 지금 당장 붙이지 않는 것도 설계다. 먼저 source discipline을 세우고, FTS와 path boost로 재현 가능한 baseline을 만든 뒤, 그 위에 semantic recall을 얹는 순서가 맞다.

오케이징에게 필요한 것은 검색이 똑똑해 보이는 것이 아니라, 틀렸을 때 왜 틀렸는지 추적할 수 있는 기억이다. vector search는 그 추적 가능성을 해치지 않는 범위에서 들어와야 한다.