함수 이름은 startAsyncSearchSync였다. 이름만 보면 인덱스 갱신을 뒤에서 시작하고 검색은 곧바로 진행할 것 같다. 실제 동작은 반대였다.
로컬 인덱스와 중앙 임베딩 서버를 함께 쓰는 AI 기억 검색 시스템에서 지연을 추적했다. 네 컴퓨터의 인덱스는 모두 FTS와 벡터 검색이 가능했고 식별 정보도 정상이었다. 그런데 WSL 검색 하나는 44.627초가 걸렸고 기존 15초 제한을 넘겼다. 인덱스가 없어서 문서 전체를 훑는 상황은 아니었다.
검색 경로는 dirty 상태이면 검색 전에 증분 동기화를 시작하도록 구현돼 있었다. 문제의 helper는 이름과 달리 동기화를 await해 실제 검색을 막았다. 새 문서를 임베딩하고 인덱스에 반영하는 일이 끝나야 FTS·벡터 검색·재정렬로 넘어갔다.
여기에 네 컴퓨터가 하나의 중앙 임베딩 모델을 공유하는 조건이 겹쳤다. 실행기의 처리 슬롯은 하나였다. 요청이 몰린 구간에는 개별 임베딩 호출이 약 2.5~6.5초 걸렸고, 다른 요청은 그 뒤에 줄을 섰다. 반면 동기화가 끝난 실제 검색은 2.236초였고, 별도 임베딩 검사는 cold 1.117초와 warm 0.220초였다.
15초를 60초로 늘린 수리는 검색이 끝날 시간을 벌어 줬다. 하지만 검색과 인덱스 갱신이 묶여 있고 중앙 처리 슬롯이 하나라는 구조는 그대로다. 제한 시간 확대는 증상을 흡수한 조치이지 병목 제거가 아니다.
이 증거로 인덱스를 강제로 다시 만들거나 검색 순위를 바꿀 이유도 없었다. 반복 지연이 다시 관측될 때 검토할 대상은 검색 시 동기화 분리와 임베딩 병렬성이다. 둘 다 실제 경쟁 상황에서 별도 검증해야 한다.
Async는 함수 이름일 수 있다. 지연 시간 보증은 아니다.