CodeNib: 코드 저장소 컨텍스트를 재사용 가능한 데이터 시스템으로

도입

코딩 에이전트가 실제 저장소에서 일할 때 가장 큰 비용 중 하나는 코드를 고치는 일이 아니라 필요한 맥락을 다시 찾는 일이다. 에이전트는 grep으로 검색하고, 파일을 읽고, 언어 서버에 질의하고, 작업별 히스토리를 유지한다. 하지만 이런 정보는 서로 분리되어 있고, 저장소가 바뀌면 같은 발견 과정이 반복된다. CodeNib은 이 문제를 개별 검색 도구의 문제가 아니라 저장소 컨텍스트를 관리하는 데이터 시스템 문제로 본다.

핵심 내용

• 저장소의 다중 뷰 구성: CodeNib은 각 repository commit에 대해 어휘 뷰, 밀집 벡터 뷰, 구조 뷰를 만든다. 어휘 뷰는 키워드 검색에, 벡터 뷰는 의미 기반 검색에, 구조 뷰는 심볼 탐색과 코드 관계 파악에 적합하다.
• 일관된 소스 위치 매핑: 각 뷰에서 나온 결과는 저장소 상대 소스 범위로 매핑된다. 이를 통해 인덱스, 언어 서버, 에이전트 히스토리가 서로 다른 위치 체계를 쓰면서 생기는 혼선을 줄인다.
• 뷰별 증분 유지관리: 저장소가 변할 때 항상 전체를 다시 만들지 않고, 선택된 뷰를 각자에 맞는 방식으로 유지한다. 논문은 100개 스냅샷에서 품질과 비용의 경계를 분석했으며, 출력이 독립 재구축 결과와 일치하는 경우 그래프 업데이트와 벡터 업데이트의 중앙값 속도가 재구축보다 각각 8.7배, 25.4배 빠르다고 보고했다.
• 하나의 런타임에서 제공: CodeNib은 랭킹 검색, 심볼 내비게이션, 제한된 컨텍스트를 같은 런타임에서 제공한다. 정규화된 live-server 위치와 일치한 정적 탐색 하위 집합, 즉 1,000개 요청 중 63%에 대해 live/static의 요청별 중앙값 지연 비율은 4.7배로 제시됐다.
• 에이전트 토큰 절감: 다섯 개 모델에서 선택된 컨텍스트 정책은 위치 식별 품질을 유지하면서, grep/read 조합 대비 trajectory token을 50~87% 줄였다.

의미와 영향

CodeNib의 의미는 특정 검색 기법 하나보다, 코드 컨텍스트를 재사용 가능하고 유지 가능한 인프라로 다룬다는 점에 있다. 코딩 에이전트는 매 작업마다 저장소를 처음부터 탐색하는 대신, 갱신 가능한 여러 뷰를 통해 필요한 범위의 맥락을 받을 수 있다. 이는 모델의 예산을 반복 탐색보다 추론, 계획, 수정에 더 많이 쓰게 만들 수 있다.

다만 논문은 결과의 경계를 분명히 한다. 증분 업데이트의 속도 향상은 독립 재구축과 출력이 일치한 경우에 한해 계산됐고, 탐색 지연 비교도 호환 가능한 하위 집합에 적용된다. 저장소 컨텍스트 시스템은 작업 종류마다 유효성 조건이 다를 수 있기 때문에, 이런 제한은 실제 도입 시 중요한 평가 기준이 된다.

대규모이면서 빠르게 변하는 코드베이스에서 코딩 에이전트를 장기간 운영하려면, CodeNib 같은 다중 뷰 컨텍스트 서비스가 모델과 저장소 사이의 기본 계층으로 자리 잡을 가능성이 있다.

출처: Hugging Face Daily Papers