실제 파일 후보 수를 유지하는 검색 경로

수집 중 읽을 수 있던 264개 목록 중 102개가 기존 4,096개 후보 한도를 넘었다. 가장 큰 목록은 6,924개 파일이었다. 이는 중간 관측이며 전체 2,400개 결과가 아니다. 작은 저장소만 골라 평가하거나 파일을 잘라내지 않도록 확장 계획을 먼저 고정했다.

선택적 Go API

hintsearch.NewPathIndex(paths)는 고유한 상대 파일 경로 최대 100,000개, 경로당 4,096바이트, 합계 16MiB를 받는다. 수집기의 상한을 그대로 사용하며, 빈 경로·중복·잘못된 UTF-8·경로 정규화 문제는 오류로 돌려준다. 입력 순서를 유지하고 파일이나 심볼릭 링크를 열지 않는다. 접근 권한과 원천 목록의 완전성은 호출자가 보장해야 한다.

idx, err := hintsearch.NewPathIndex(paths)
if err != nil { return err }
ranking, err := idx.RankLongInto(completeRequest, hintsearch.Ranking{})
if err != nil { return err }
order, err := hintsearch.InterleavePathBaselineFirst(ranking.Order, hintIDs)
if err != nil { return err }
// order는 원래 paths의 위치이며 모든 후보를 포함한다.

전체 목록에서 공통 BM25 통계를 만든다. 조각별로 서로 다른 점수를 계산해 억지로 합치지 않는다. 인덱스는 불변이며 어휘·posting·점수·순서는 배열로 다룬다. 결과 버퍼를 재사용하고 동시 호출에서는 각각 소유한다. 큰 후보용 병합도 기존과 같은 baseline-first 순서이며, 힌트가 틀려도 후보를 없애지 않는다. 정확하고 비용이 같은 확인을 가정할 때 기존 순위 r의 후보는 min(n, 2r−1)번 안에 나온다. 시간·토큰·복수 증거 완성의 보장은 아니다.

기존 New와 병합 API의 작은 한도는 유지한다. 모델·특징·CLI·세션·지연 힌트의 계약은 바꾸지 않았다. 이 API는 실제 파일 경로 기준선과 후보 순서 제안을 위한 것이며 코드 본문 의미나 작업 해결 능력을 입증하지 않는다.

검증과 프로파일

6,000개 후보의 끝에 있는 검색어를 찾고 전체 목록 기준 IDF를 독립 계산해 비교했다. 최대 100,000개 입력에서도 마지막 후보 검색을 확인한다. 작은 목록은 기존 점수·순서에 정확히 일치한다. 역순 힌트로도 모든 후보와 baseline 순위 상한이 유지되는지, 잘못된 경로·중복·크기 초과를 거부하는지 검사한다.

M4 Pro CPU, 자체 합성 파일 경로 10,000개, 단어 하나를 반복 검색하는 benchmark를 각 3회 실행했다. CPU/할당 프로파일은 로컬에만 보관했다. 프로파일에서 정렬 비교·교환 비용을 확인하고 결과 순서 정렬을 sort.Slice에서 slices.SortFunc로 바꿨다. 점수 계산은 그대로다.

측정	변경 전	변경 후
재사용 검색 ns/op 범위	43,054–43,559	35,039–35,084
재사용 검색 할당 B/op	72	16
재사용 검색 할당 횟수	3	1

이 조건에서 검색 시간이 약 19% 줄었다. 두 측정 모두 동일한 profiling 옵션을 사용했지만 전체 시스템 부하와 실행 순서 효과를 배제한 인과 실험은 아니다. 합성 단어 한 개 검색을 실제 장문·저장소·LLM 성능으로 확대하지 않는다.

인덱스 생성은 변경 전 약 5.33–5.84ms, 변경 후 약 5.01–5.08ms였으며 약 9.47MB 누적 할당과 10,113회 할당이 유지됐다. 생성 알고리즘은 정렬 변경의 대상이 아니므로 생성 시간 차이를 개선 효과라고 주장하지 않는다. 누적 할당은 상주 메모리와 다르다. SIMD나 GPU 가속 주장은 없다. 전체 자료 수집은 완료했으며 실제 파일 정답 비교는 후속 평가에서 수행한다.