CodeNib: A Multi-View Data System for Serving Repository Context to Coding Agents

Paper: Zhongming Yu; Hengjia Yu; Boqin Yuan; Shuting Zhao; Yizhao Chen; Aryan Dokania; Mihir Jagtap; Jiayu Chang; Yitong Ma; Yash Jayswal; Wentao Ni; Hejia Zhang; Zhaoling Chen; Gangda Deng; Jishen Zhao (2026). "CodeNib: A Multi-View Data System for Serving Repository Context to Coding Agents". https://arxiv.org/abs/2607.25431v1 · arXiv:2607.25431v1. 이 글은 2026년 7월 28일 공개된 23쪽의 v1을 기준으로 한다. PDF · 공식 코드. 코드 인용은 2026년 9월 12일 조회한 head commit 61a9ab2에 고정한다.

Abstract: 코딩 에이전트는 같은 저장소를 과제마다 다시 탐색한다. 색인, 언어 서버, 과제별 대화 기록이 서로 떨어져 있어 한 번 찾은 사실이 다음 과제로 넘어가지 않고, 그 과정의 비용도 한 덩어리로 뭉쳐 보이지 않는다. CodeNib은 이 문제를 데이터 시스템 문제로 다시 놓는다. 커밋은 변경 불가능한 기반 데이터이고, 청크·포스팅·임베딩·occurrence·관계는 그로부터 파생된 뷰이며, 에이전트의 요청은 특정 뷰에 대한 질의이고, 프롬프트에 들어가는 컨텍스트는 경계가 정해진 전달 결과다. 시스템은 커밋마다 lexical·dense·structural 뷰를 만들고, 각 결과를 저장소 상대 소스 범위로 되돌려 매핑하며, 뷰별로 다른 경로로 갱신하고, 하나의 런타임에서 랭킹 검색·심볼 내비게이션·경계가 정해진 컨텍스트를 제공한다. 평가는 하나의 종합 점수를 만들지 않는다. 다섯 개 질문이 각각 다른 출력 계약과 다른 통과 조건 위에서 측정되고, 보고된 속도 향상은 모두 그 조건을 통과한 부분집합에만 적용된다. 이 글은 뷰 정의와 갱신 경로, 다섯 실험의 설계와 결과를 따라가면서, 각 헤드라인 수치가 어느 부분집합에서 성립하고 어디까지 일반화되지 않는지를 검토한다. 논문 §§3–9

---

Executive Summary

항목	설명
연구 질문	저장소에서 파생된 상태를 과제 간에 재사용할 때, 품질·호환성·갱신 충실도·지연·토큰을 각각 어떤 경계 안에서 얻을 수 있는가?
시스템	커밋 단위 lexical·dense·structural 뷰와 이를 목록화하는 manifest, 뷰별 증분 갱신 경로, 뷰를 불러와 제공하는 에이전트 런타임.
검색 (Q1)	5개 임베더에서 file Recall@10 0.705–0.820, symbol Recall@10 0.422–0.638. 리랭커는 file 0.858까지 올리지만 질의당 초 단위 비용이 든다.
그래프 확장 (Q1)	42개 held-out 스냅샷에서 ΔFile Success@10 점추정 −4.8 ~ +7.1%p. 모든 구간이 0을 포함한다.
벡터 색인 (Q2)	HNSW(ef=16)는 평균 FAISS 검색을 0.910 ms에서 0.0268 ms로 줄이지만, 전체 dense 질의 중앙값은 45.1 ms다.
내비게이션 (Q3)	1,000개 요청 중 632개(63.2%)만 정규화 위치 집합이 일치한다. 그 부분집합의 중앙 live/static 비율은 4.72×, 중앙 절대 절감은 1.69 ms다.
증분 갱신 (Q4)	심볼 단위 그래프 복구는 33개 중 15개, 벡터 재사용은 31개 중 28개가 독립 재빌드와 일치한다. 일치한 전이의 중앙 속도 향상은 8.67×와 25.44×다.
컨텍스트 (Q5)	5개 모델에서 선택된 정책이 grep/read 토큰의 12.9–49.9%를 쓰고, ΔAnswerRecall@5는 −0.009 ~ +0.067이다.
핵심 한계	패치 생성과 이슈 해결은 평가 범위 밖이다. 뷰 사이의 원자적 갱신이 없고 BM25는 증분 경로가 없으며, 세 헤드라인 수치는 서로 다른 부분집합 위에서 성립한다.

수치와 평가 범위는 논문 §9 및 Appendix A–H에 따른다.

목차

1. 반복되는 탐색과 보이지 않는 수명주기 비용
2. 커밋 하나를 세 개의 뷰로 재료화한다
3. 네 연산은 서로 다른 값을 반환한다
4. 증분 유지: 무엇을 고치고 무엇을 검사하는가
5. 검색 계획의 품질–지연 지형
6. 벡터 색인의 물리 구조는 어디를 최적화하는가
7. 정적 색인은 언어 서버를 대체하지 못한다
8. 갱신 속도와 수명주기 회계
9. 컨텍스트 전달 정책과 토큰
10. 한계, 재현 조건과 결론

---

1. 반복되는 탐색과 보이지 않는 수명주기 비용

코딩 에이전트는 저장소를 읽는 동안 서로 다른 성격의 연산을 섞어 쓴다. 식별자를 문자열로 찾고, 자연어 설명으로 의미가 가까운 코드를 찾고, 정의와 참조를 따라가고, 파일을 읽고, 지금까지의 관측을 기억한다. 이 연산들은 같은 소스 상태를 공유하지만 서로 다른 종류의 증거를 돌려준다. 검색은 순위가 매겨진 후보를 주고, 내비게이션은 위치를 준다. 논문 §1

문제는 이 증거들이 과제 경계에서 사라진다는 것이다. 이슈 하나를 처리하면서 찾아낸 파일 목록과 호출 관계는 그 과제의 대화 기록 안에 남고, 다음 이슈는 같은 저장소를 다시 grep으로 훑는다. 색인을 붙이면 이번에는 색인·언어 서버·프롬프트 상태가 각각 다른 물리 구조와 다른 갱신 경로를 갖는다는 문제가 생긴다.

논문은 이를 세 개의 결합된 과제로 정리한다. C1은 이질적인 뷰다. 텍스트·벡터·그래프는 서로 다른 레코드와 다른 연산자를 쓰지만, 결과는 같은 커밋과 같은 저장소 상대 소스 범위로 되돌아와야 한다. C2는 증분 신선도다. 한 번의 편집이 각 뷰에 서로 다른 영향을 주므로 그래프 복구, 임베딩 재사용, 재빌드 경로를 따로 선택하고 따로 평가해야 한다. C3은 에이전트 전달이다. 미리 계산한 증거가 도구나 컨텍스트를 통해 모델에 닿아야 하고, 그 과정의 빌드·적재·질의·기록 비용이 보여야 한다.

원논문 Figure 2. 가운데가 커밋 단위 데이터 평면이고, 오른쪽 위는 질의를 소스에 연결된 랭킹 코드 블록으로 바꾸는 경로, 오른쪽 아래는 컨텍스트 정책과 도구를 에이전트 루프에 연결하는 런타임이다. 도판의 패널 제목은 컴파일러를 Agent Index Compiler로 표기하지만, 같은 도판의 원 캡션과 본문은 이를 repository view compiler로 부른다. 도판의 해시·lag·점수는 원 캡션이 밝히듯 예시이며 측정값이 아니다. Yu et al. (2026), PDF p. 3. 원본 도판 영역 직접 추출.

그림을 누르면 원본 해상도로 볼 수 있다. 아래 도판도 같은 방식으로 확대할 수 있다.

이 논문을 읽는 방식은 일반적인 방법 논문과 다르다. 하나의 점수를 올리는 것이 목표가 아니라, 다섯 개 연산의 품질–비용 지형을 각각 측정하고 각 수치가 유효한 범위를 명시하는 것이 목표다. 논문 스스로 "정확한 대체"와 "품질–비용 절충"을 구분해서 보고하겠다고 밝힌다. 따라서 검토의 축도 "얼마나 빨라졌는가"가 아니라 "그 수치가 어떤 부분집합에서 성립하는가"가 된다. 논문 §1

저자 구성도 이 설계를 이해하는 데 참고가 된다. 제1저자와 PI로 기재된 마지막 저자를 포함한 세 명은 이슈 위치 파악 에이전트 OrcaLoca의 저자이고, 공저자 두 명은 그래프 기반 위치 파악 에이전트 LocAgent의 저자다. 두 연구 모두 이 논문의 참고문헌에 들어 있다. 에이전트 쪽 프레임워크를 만든 그룹이 그 아래에 깔리는 데이터 계층을 다시 설계한 셈이다. 논문 References·Appendix I

2. 커밋 하나를 세 개의 뷰로 재료화한다

2.1 소스 단위와 세 뷰

커밋 c의 체크아웃에서 추출한 소스 단위 U_c의 원소는 다음과 같이 기록된다.

p는 저장소 상대 경로, [r_s,r_e]는 소스 범위, \ell\in{L_0,L_1,L_2}는 단위의 크기, \tau는 노드 타입, x는 소스 텍스트, s는 해결된 심볼이다. 파일이 L_0, 타입 같은 스코프가 L_1, 호출 가능한 정의가 L_2다. 논문 §4.1

이 위에 세 뷰가 만들어진다. Lexical 뷰는 식별자·경로·주석·소스 텍스트의 포스팅 또는 trigram 레코드이고, dense 뷰는 L_0 또는 L_2 단위의 임베딩과 소스 범위로 돌아가는 매핑이며, structural 뷰 G_c는 파일·스코프·정의 사이의 포함 및 관계 간선과, 백엔드가 제공하는 경우 저장된 occurrence 레코드다.

뷰	저장물	기본 백엔드	증분 경로	평가에서 확인하는 것
Lexical	청크 텍스트 포스팅, 선택적 파일 trigram	BM25, 선택적 Zoekt	없음, 전체 재빌드	Q1 비교 대상 아님
Dense	L_0/L_2 임베딩과 소스 side mapping	FAISS Flat 기본, IVF 설정 가능	내용 주소 기반 임베딩 재사용 + FAISS delta	Q1·Q2 품질과 지연, Q4 재사용 일치
Structural	타입이 붙은 정점·간선, occurrence 테이블	SCIP 4개 언어, C/C++는 clangd	Git diff + LSP 보조 복구	Q3 위치 일치, Q4 재빌드 일치

논문 §§5.1–5.3

여기서 BM25에 증분 경로가 없다는 점은 그냥 지나치기 쉽다. 논문은 벡터 갱신을 설명하는 문장 끝에 "BM25는 여전히 재빌드한다"고 적고, Q4 서술에서도 현재 BM25 경로에 통합된 delta 갱신이 없다고 다시 밝힌다. 세 뷰를 내세우는 시스템에서 증분 신선도 이야기는 두 뷰에만 해당한다. 논문 §6.4

2.2 manifest는 저장소가 아니라 조회 경계다

각 뷰는 프로필 \theta(언어, 백엔드, 스키마, 모델, 옵션)를 갖고, manifest가 이들을 묶는다.

K_c는 능력(capability)이다. manifest는 뷰의 내용물을 담는 컨테이너가 아니라 런타임이 무엇을 열 수 있는지 확인하는 조회 경계다. 빌더는 각자 독립적으로 쓰고 상태와 메타데이터를 돌려주며, 모든 빌더가 끝난 뒤에야 manifest가 타입·경로·타임스탬프·상태·설정·소요 시간을 기록하고 능력을 유도한다. 벡터 빌더가 실패해도 BM25는 계속 사용 가능하다. 논문 §5.4

이 실패 격리가 중요한 이유는 컴파일 언어에서 드러난다. C/C++는 비어 있지 않은 compile_commands.json을 요구하고, 없으면 CMake나 Bear로 생성을 시도한다. 의존성 복원이나 빌드가 실패하면 그래프 빌더는 더 약한 데이터를 같은 능력 이름으로 내놓는 대신 명시적으로 실패한다. 즉 "그래프가 있다"와 "구문 트리만 있다"가 같은 라벨을 쓰지 않는다. 논문 Appendix D

다만 manifest는 커밋을 기록할 뿐 워크트리를 잠그지는 않는다. 그리고 편집 이후의 저장소 간 트랜잭션을 제공하지 않는다. 논문은 이 두 가지를 §3.4에서 경계로 명시한다. 여기서 C1과 C2 사이에 구조적 긴장이 생긴다. C1은 모든 결과가 같은 커밋과 같은 주소 체계로 돌아오는 것을 요구하는데, C2의 갱신 경로는 뷰마다 따로 진행된다. 초기 빌드 시점에는 동일 커밋 불변식이 구성상 성립하지만, 그 뒤에는 성립하지 않을 수 있고 런타임은 이를 막는 대신 staleness 경고로 알린다. Figure 2의 manifest 예시가 in sync, patching, queued와 서로 다른 lag 값을 나란히 보여주는 것이 정확히 그 상태다. 논문 §§3.4, 5.4, 7.1

2.3 능력은 언어마다 다르다

레지스트리는 청킹, 콜드 그래프, 증분, 라이브 언어 서버 백엔드를 각각 독립적으로 고른다. 청킹은 14개 언어를 지원하고, 평가는 다섯 언어 그룹에서 이뤄진다. Python·Go·Rust·TS/JS는 SCIP로 콜드 그래프를 만들고 SCIP occurrence 색인을 먼저 조회한 뒤 그래프로 폴백한다. C/C++는 SCIP 경로가 아니라 clangd 배경 색인을 그래프·범위 표현으로 디코딩하며, SCIP occurrence 경로를 주장하지 않는다. Table 5는 C/C++의 정적 위치 경로를 그래프 위치·범위 색인으로 적는다. 논문 §5.1·Table 5

L_2 정의도 언어마다 다르다. 평가 설정은 l2_level_exclusive=true로, 최상위 leaf 선언과 중첩 멤버는 남기고 class·struct·trait·interface·impl 같은 컨테이너는 제외한다. 따라서 "심볼 단위 검색"이라고 할 때의 심볼은 클래스가 아니라 호출 가능한 정의에 가깝다. 심볼 단위 recall 수치를 읽을 때 이 정의를 먼저 확인해야 한다. 논문 Appendix C·Table 4

3. 네 연산은 서로 다른 값을 반환한다

논문은 네 연산을 반환값과 측정 비용으로 구분하고, 각 연산이 자기 출력 계약으로만 비교되도록 설계한다. 이 구분이 평가 전체의 뼈대다.

랭킹 검색. 텍스트 질의 q는 다음 튜플로 낮춰진다.

경로 r\in{A,B,C,D}는 lexical·semantic·hybrid·structural을 고르고, 오직 hybrid C만 RRF를 소유한다. 폭 k는 검색 fan-out k_{\mathrm{ret}}과 선택적 pre-rerank 절단 k'을 포함하며, 최종 k_{\mathrm{out}}은 호출자 제한으로 남는다. \rho는 선택적 리랭커이고, 그래프 확장 h는 D에서만 허용된다. 실행 결과는 [(u_1,\sigma_1),\dots,(u_{k_{\mathrm{out}}},\sigma_{k_{\mathrm{out}}})]이다. 논문 §4.2

심볼 내비게이션. LSP 형태의 요청 a에 대해 N(\cdot)이 제공자 결과를 결정론적인 경로/시작줄 쌍 집합으로 사영한다. 정적 제공자와 라이브 제공자는 다음이 성립할 때 일치한다.

이 정규화 집합은 문자 위치, 끝 범위, 제공자 메타데이터를 버린다. 논문은 이 기준이 의도적으로 약하다는 점과, 일치는 상호교환 가능성을 증명하지 않는다는 점을 함께 적는다. 그래서 일치율과 일치한 요청의 지연을 반드시 함께 보고한다. 논문 §4.2

구조 뷰 유지. 전이 c\to c'에서 증분 복구한 그래프 \widehat G_{c'}과 독립적으로 새로 만든 목표 그래프 G_{c'}에 대해, 선언된 그래프 사실 사영 \mathcal F(\cdot)의 동치와 재적재 후 서빙 재현을 각각 검사한다.

두 검사는 모두 타이밍이 끝난 뒤에 수행되고, 갱신 지연에 포함되지 않으며, 유지보수 경로 위에서 실행되지 않는다. 논문은 이를 "보고한 속도 향상을 한정하는 장치이지 온라인 정확성 오라클이 아니다"라고 표현한다. 논문 §4.2, Eqs. 1–2

컨텍스트 전달. 정책 \pi는 랭킹된 후보와 누적된 기록을 모델 프롬프트로 옮긴다. 비교 대상은 모델이 직접 grep/read하는 방식, 상위 L_2 블록을 미리 주입하는 eager, 같은 주입 뒤 기록을 한 번 다시 쓰는 compact다. 지표는 전체 궤적 토큰과 AnswerRecall@5다.

속도 향상 지표도 정의를 확인해야 한다. 그래프 갱신 비율은 서버 기동·워밍업 비용을 공유 횟수로 나눠 부담시킨다.

여기서 n_{\mathrm{share}}는 하나의 서버 설정을 공유하는 전이 수이고, 이 실험에서는 5다. 즉 보고된 그래프 속도 향상은 "서버를 다섯 번 연속 쓸 때의 분할 부담"을 전제로 한다. 고립된 단발 갱신이라면 n_{\mathrm{share}}=1이 되고 비율은 내려간다. 논문 §4.3, Eq. 3

마지막으로 Q5의 품질 게이트가 있다. 각 모델에서 grep/read 대비 짝지은 평균 변화 \Delta\mathrm{AR@5}(\pi)의 95% 구간 하한이 -\epsilon=-0.05 이상이면 품질을 보존한 것으로 보고, 그 조건을 통과한 정책 중 토큰이 적은 쪽을 고른다. 논문은 이것이 사전등록된 동등성 검정이 아니라 보고 기준이라고 명시한다. 이 규칙의 성격은 9절에서 다시 다룬다. 논문 §4.3

4. 증분 유지: 무엇을 고치고 무엇을 검사하는가

원논문 Figure 3. (a–b)는 diff (c) 전후의 그래프이고, (d)는 전체 재빌드, (e–f)는 변경 파일의 하위 그래프를 통째로 지우고 다시 연결하는 파일 단위 갱신, (g)는 안정적인 사실을 보존하고 편집으로 무효가 된 부분만 고치는 심볼 단위 갱신이다. 도판 (c)의 열 머리글은 c.py source지만 패널 제목과 코드 내용은 foo.py의 diff다. 원본 표기를 그대로 유지했다. Yu et al. (2026), PDF p. 7. 원본 도판 영역 직접 추출.

4.1 줄이 밀렸다고 의미가 바뀐 것은 아니다

파일 단위 기준선은 변경된 파일의 하위 그래프를 전부 버리고 다시 만든다. 이 방식은 안정적인 선언과 교차 파일 관계까지 버리고, 줄이 밀린 것을 의미 변화처럼 취급한다. 심볼 단위 경로는 컨텍스트 없는 hunk와 새로 받은 documentSymbol 트리를 결합해 심볼을 삭제·영향받음·이동·불변·추가로 분류한다. 논문 §6.4

도판 (g)의 예가 분류를 그대로 보여준다. 유지된 bar와 변하지 않은 run의 간선은 복사되고, 속성만 바뀐 fmt는 정체성을 유지한 채 줄·앵커 속성이 -2만큼 재조정된다. old와 run→print는 삭제되고, new와 run→fmt를 비롯한 인접 사실은 모든 정점이 만들어진 뒤에 추가된다. 하나의 영향받은 심볼이 여러 동작을 동시에 겪을 수 있다.

LSP 호출 수로 보면 파일 단위는 참조 4회와 정의 5회, 심볼 단위는 참조 1회와 정의 4회다. 9회에서 5회로 4회, 44.4%가 줄어든다. 다만 원 캡션이 밝히듯 이 수는 도판에 표시된 요청만 센 것이고 동기화·documentSymbol 등 다른 프로토콜 메시지는 포함하지 않으며, 전체 속도 향상을 뜻하지도 않는다.

패처의 실제 동작에는 잘못된 간선을 막는 장치도 들어 있다. 참조로 들어오는 간선을 찾을 때, 메서드 위치는 정의 질의가 그 구체적 메서드로 되돌아오는 경우에만 유지한다. 인터페이스 구현 관계가 거짓 호출 간선을 만드는 것을 막기 위해서다. 같은 (line, character)의 중복 semantic token은 제거하지만, 위치가 다른 동일 텍스트 토큰은 섀도잉과 import 때문에 다르게 해석될 수 있으므로 제거하지 않는다. 그래서 지연은 변경된 줄 수보다 영향받은 심볼과 참조 fan-out에 좌우된다. 논문 Appendix F

4.2 검사는 갱신 경로 밖에 있다

갱신이 옳았는지는 두 단계로 확인한다. 먼저 정점 정체성·타입·소스/선택 줄·앵커가 붙은 타입 간선의 multiset을 메모리에서 비교한다. 그다음 두 그래프를 모두 다시 적재해 결정론적인 정의·참조 요청을 재생하고 정규화 결과가 같은지 본다. 두 검사 중 하나라도 실패하면 그 전이는 조건부 속도 향상 집계에 들어가지 않는다. 지연이 아무리 낮아도 마찬가지다. 논문 §4.2

벡터 쪽은 더 엄격하다. 문서 정체성, 수치적으로 동일한 벡터, 그리고 정확히 순서까지 같은 Flat top-k 재생을 모두 요구한다. 9위와 10위가 뒤바뀌기만 해도 실패다.

이 설계의 장점은 분명하다. "빠르다"는 주장과 "같은 결과를 낸다"는 주장이 분리되고, 후자가 전자의 전제가 된다. 대신 대가도 있다. 검사가 오프라인이고 독립 재빌드를 기준으로 하므로, 그 기준 자체가 흔들리면 실패의 원인을 패처로 돌릴 수 없다. 8절에서 이 문제가 실제로 나타난다.

5. 검색 계획의 품질–지연 지형

5.1 평가 대상은 SWE-bench 자체가 아니다

Q1–Q3는 CodeNib Base를 쓴다. Base는 SWE-bench Verified에서 Python을, SWE-bench Multilingual에서 C/C++·Go·Rust·TS/JS 쌍을 다시 표집해 만든 100개 스냅샷이고, 25개 저장소에서 왔다. 질의는 이슈 본문이고, 정답은 개발자 패치가 건드린 패치 이전 파일과 L_2 블록이다. 상류 테스트는 실행하지 않는다. 즉 이 평가는 이슈 해결률이 아니라 위치 파악 대리 지표다. 논문 Appendix A

언어	행 수	저장소	LOC 중앙값	L_0/L_2 중앙값
C/C++	20	5	206,900	279 / 7,483
Go	21	5	147,434	383 / 4,790
Python	20	5	158,938	379 / 6,690
Rust	20	5	104,917	404 / 4,110
TS/JS	19	5	57,942	251 / 1,751

논문 Table 3

표집 방식도 모집단 표본이 아니라 의도적 층화다. 각 언어 그룹에서 파일 수 기준 최소·25·50·75·최대 백분위에 가까운 저장소 다섯 개를 고르고, 난이도는 기록된 Claude Opus alias가 이슈 본문과 패치 앞부분 6,000자로 분류한다. 최종 구성은 낮음 56, 중간 36, 높음 8이다. 목표 블록 151개 중 74개 행이 블록 하나만 갖는다. 이 분포는 결과를 읽을 때 함께 고려해야 한다.

5.2 임베더 선택이 recall과 지연을 동시에 움직인다

원논문 Figure 6. (a)는 검색에 쓰는 callable 색인의 평균 L_2 빌드 시간 대비 파일 Recall@10, (b)와 (c)는 평균 질의 시간 대비 파일·심볼 Recall@10이다. 연결된 리랭크 점들은 pre-rerank 절단 k'\in{30,50,100}을 훑은 것이고, 점선은 각 패널 안의 경험적 비지배 점이다. (a)의 세로 방향으로 쌓인 점들은 리랭킹이 빌드 시간을 바꾸지 않기 때문에 생긴다. Yu et al. (2026), PDF p. 11. 원본 도판 영역 직접 추출.

리랭킹과 그래프 확장을 빼고 순수 임베딩만 보면 다음과 같다.

임베더	파라미터	차원	파일 R@1	파일 R@10	파일 R@20	심볼 R@1	심볼 R@10	심볼 R@20
SweRank-Small	137M	768	0.39	0.70	0.79	0.20	0.42	0.49
Qwen3-Embed-0.6B	596M	1,024	0.38	0.71	0.78	0.13	0.50	0.61
Jina-Code-1.5B	1.54B	1,536	0.39	0.81	0.89	0.14	0.49	0.62
Qwen3-Embed-4B	4.02B	2,560	0.41	0.82	0.86	0.21	0.55	0.71
SweRank-Large	7.07B	3,584	0.50	0.82	0.87	0.30	0.64	0.73

논문 Figure 12·Table 6

k=10에서 파일 recall은 0.705에서 0.820까지 올라가고 심볼 recall은 0.422에서 0.638까지 움직인다. 파라미터가 약 50배 늘어나는 동안 파일 Recall@10은 0.12 오른다. 순서가 항상 크기를 따르지도 않는다. 파일 k=20에서는 1.5B의 Jina가 0.89로 7B의 SweRank-Large 0.87보다 높고, 심볼 k=1에서는 137M의 SweRank-Small이 0.20으로 0.6B·1.5B보다 높다. 모델을 키우는 것이 단조로운 개선이 아니라는 뜻이다. 논문 §9.2

리랭킹은 다른 축이다. Jina에 4B 리랭커를 k'=50으로 붙이면 파일 Recall@10이 0.858, 질의 시간 4.29초다. 같은 Jina의 dense 단독은 0.812에 92 ms다. 4.6%p를 얻는 대신 지연이 46.6배가 된다. 심볼 단위 최고값은 Qwen3-Embed-4B에 8B 리랭커를 k'=100으로 붙인 0.742이고 14.1초가 든다. 이 호스트에서 dense 질의 평균은 모든 임베더에서 300 ms 아래인데, 리랭킹은 초 단위다. 논문 §9.2

한 가지 보고 공백이 있다. Qwen 4B·8B 리랭커의 점수 평균은 k'=30/50에서 n=99/98을 쓰고 나머지는 100이다. 어떤 스냅샷이 왜 빠졌는지는 설명되지 않는다. 값 자체에 큰 영향을 줄 규모는 아니지만, 100개 스냅샷의 매크로 평균을 비교하는 표에서는 기록해 둘 사항이다. 논문 Figure 6 캡션

5.3 그래프 확장은 결론이 나지 않았다

원논문 Figure 7(a). 짝지은 그래프−dense ΔFile Success@10이다. 상위 10개 서로 다른 파일 안에 모든 목표 파일이 들어왔는지를 보는 전부-아니면-전무 지표이므로, Figure 6의 평균 Recall@10 경계가 이동한 것과는 다른 값이다. Yu et al. (2026), PDF p. 12. 원본 도판 영역 직접 추출.

그래프 연산자만 분리하기 위해 dense와 graph 두 조건은 같은 임베딩 색인과 같은 후보 예산을 공유한다. L_2 청크 300개를 가져와 앞의 10개 seed를 들어오고 나가는 참조 간선으로 한 홉 확장한 뒤, 가중 RRF로 의미 순위와 구조 순위를 합친다. 가중치 w_g는 58개 스냅샷·15개 저장소의 튜닝 분할에서 골라 0.5로 고정한 다음, 겹치지 않는 10개 저장소의 42개 스냅샷에서 효과를 보고한다. 가중치를 고른 라벨로 효과를 평가하지 않겠다는 설계다. 논문 §9.2

결과는 리랭커 없는 계열에서 −4.8%p(Qwen3-Embed-4B)부터 +7.1%p([−2.6, +19.5], Qwen3-Embed-0.6B)까지다. 두 계열 모두에서 모델별 구간이 0을 포함하고, 열 개의 교차 임베딩 familywise 구간도 마찬가지다. 논문은 "일반적 이득도, 임베딩별 라우팅 규칙도 확립하지 못했다"고 쓴다. 확장 자체의 지연은 리랭크 없는 조건에서 중앙값 기준 15–39 ms로 작다.

여기에 덧붙일 것은 해상도 문제다. held-out이 42개 스냅샷이고 지표가 짝지은 전부-아니면-전무 차이이므로, 점추정값은 정의상 약 2.38%p의 배수로만 나올 수 있다. −4.8 ~ +7.1은 스냅샷 −2개에서 +3개에 해당한다. "미해결"이라는 결론은 정확하지만, 이 설계는 작은 효과를 분해할 해상도를 갖고 있지 않다고 보는 편이 맞다.

6. 벡터 색인의 물리 구조는 어디를 최적화하는가

Q2는 dense 색인의 오프라인 구축과 온라인 검색, 근사 오차를 분리한다. 빌드 시간은 L_0에서 중앙값 3.8–56.7초, L_2에서 19.3–285.0초이고, 같은 모델 안에서 L_2/L_0 비율은 5.0–6.4배다. 질의 지연 중앙값은 20.9 ms에서 233.8 ms까지 올라간다. 타이머는 청킹 이후에 시작하며 체크아웃·SCIP·그래프 디코딩은 빠져 있다. 논문 §9.3

원논문 Figure 7(b–c). (b)는 평균 top-10 L_2-ID 중첩 대비 검색 지연이고, 테두리 표시는 평균 중첩 0.95 이상인 각 계열의 가장 빠른 설정이다. (c)의 옅은 표식은 스냅샷별 속도 향상이고, 굵은 표식은 곡선마다 여섯 개씩으로 로그 크기 구간의 중앙값을 잇는 안내선이다. 가로축의 색인 크기가 수백에서 수만 벡터 범위임을 함께 보아야 한다. Yu et al. (2026), PDF p. 12. 원본 도판 영역 직접 추출.

중첩 0.95를 기준으로 각 계열의 가장 빠른 설정을 고르면, HNSW(ef_{\mathrm{search}}=16)는 neighbor Recall@10 0.977에서 평균 FAISS 검색을 0.910 ms에서 0.0268 ms로 줄인다(33.9배). IVF는 25% probe에서 0.965와 0.223 ms다(4.1배). 두 설정 모두 모든 스냅샷에서 Flat의 패치 목표 파일 Recall@10을 그대로 유지한다(매크로 평균 0.620).

여기서 논문이 직접 적어 둔 비율이 중요하다. HNSW가 줄이는 값은 평균 0.883 ms인데, 전체 dense 질의의 중앙값은 45.1 ms다. 즉 ANN이 손대는 구간은 질의 전체의 약 2%다. 논문은 이 질의 시간을 질의 인코딩과 Flat 스캔, 고정 k 결과 재료화의 합이라고만 밝히고 각 항을 따로 재지 않으므로, 나머지 98%의 내역은 보고된 값에서 분해되지 않는다. 게다가 HNSW는 평균 색인 전용 빌드 시간을 6.4 ms에서 2.00초로, 직렬화 크기를 21.74 MiB에서 23.18 MiB로 올린다. IVF는 0.889초와 22.33 MiB다. 측정된 평균 기준으로 추가 구축 비용은 IVF가 약 1,300회, HNSW가 약 2,300회 검색 뒤에 상쇄된다. 논문 §9.3

Figure 7(c)의 가로축을 보면 이 저장소들의 색인이 수백에서 수만 벡터 규모다. Table 3의 L_2 중앙값이 언어별로 1,751–7,483개인 것과 일치한다. 로그 크기 구간의 중앙값 안내선으로 보면 IVF의 속도 향상은 색인 크기와 거의 무관하게 낮은 배수에 머무는 반면, HNSW는 수백 벡터 구간에서 IVF를 넘어선 뒤 단조롭게 올라가 위 중앙값 구간에서 이미 두 자릿수 배에 이른다. 그런데도 논문의 결론은 "이 규모에서는 Flat이 더 단순하다"이다. 검색 자체의 배수가 작아서가 아니라, 그 배수가 적용되는 구간이 전체 질의의 2% 남짓이고 추가 구축 비용이 수천 회 검색 뒤에야 상쇄되기 때문이다. 더 큰 색인과 더 높은 질의율은 측정하지 않았다고 밝힌다.

Q1과 Q2를 함께 보면 지연 예산의 주인이 드러난다. 리랭커는 초 단위, dense 질의 전체는 수십에서 수백 ms, 그중 FAISS 검색은 1 ms 미만이다. 색인의 물리 구조를 고르는 일은 이 스케일에서 시스템 성능을 좌우하는 결정이 아니다. 어떤 모델을 부르는가가 좌우한다.

7. 정적 색인은 언어 서버를 대체하지 못한다

원논문 Figure 9. 왼쪽 라벨은 경로/시작줄 일치율이고, 오른쪽 값은 일치한 요청의 중앙 live/static 비율이다. 옅은 쌍은 스냅샷별 중앙값, 굵은 점은 전체 요청 중앙값이다. 일치하지 않은 요청은 조건부 지연 요약에서 제외된다. Yu et al. (2026), PDF p. 13. 원본 도판 영역 직접 추출.

실험은 같은 에이전트 요청의 백엔드만 바꾼다. 스냅샷마다 소스에 매핑 가능한 참조 간선 앵커를 정렬해 다섯 위치를 균등 간격으로 고르고, 정의와 참조 두 능력을 모두 호출한다. 정의는 최대 8개, 참조는 최대 40개 위치를 돌려준다. 라이브 제공자는 clangd, gopls, basedpyright, rust-analyzer, typescript-language-server다. 위치가 정적 그래프에서 나왔으므로, 논문은 이 일치율이 임의의 편집기 요청에 대한 추정이 아니라고 못 박는다. 논문 §9.4

1,000개 요청 중 632개(63.2%)의 정규화 경로/시작줄 집합이 일치한다. 정의는 500개 중 437개(87.4%), 참조는 500개 중 195개(39.0%)다. 일치한 632개 중 630개는 양쪽 모두 비어 있지 않은 결과를 돌려준다. 이 부분집합에서 정적·라이브의 요청 중앙 지연은 0.62 ms와 2.26 ms이고, 짝지은 절감의 중앙값은 1.69 ms, 비율의 중앙값은 4.72배다.

언어	정의 일치율	정의 중앙 비율	참조 일치율	참조 중앙 비율
C/C++	87%	54.0×	22%	3.2×
Go	99%	3.0×	73%	10.6×
Python	80%	1.6×	36%	57.6×
Rust	85%	2.4×	33%	3.6×
TS/JS	85%	4.7×	28%	22.1×

논문 Figure 9

논문은 일치율을 제한 요인으로 규정하고, 정의조차 12.6%에서 어긋나므로 능력 타입만으로 안전하게 라우팅할 수 없으며 4.72배는 달성된 워크로드 속도 향상이 아니라 조건부 기회라고 적는다. 이 판단은 정확하다.

여기에 표를 세로로 읽으면 한 가지가 더 보인다. 지연 이득이 큰 능력과 호환성이 낮은 능력이 대체로 겹친다. 다섯 언어 모두에서 참조의 일치율이 정의보다 낮고, 다섯 중 넷에서 참조의 중앙 비율이 정의보다 높다. 정적 서빙이 극적으로 빠른 지점은 그것이 라이브 결과를 가장 적게 재현하는 지점이다. 전체 중앙값 4.72배는 두 성격이 다른 집단을 합친 값이고, 일치한 요청의 69%는 정의다.

절대 크기도 함께 보아야 한다. 중앙 절감은 1.69 ms다. 모델 호출이 초 단위인 에이전트 루프에서 요청당 1.69 ms는 종단 지연에서 거의 보이지 않는다. 동시에 이 측정은 그래프 적재, 서버 기동, 워밍업, 유휴 대기를 모두 제외한 준비 이후의 한계 비용이다. 라이브 경로의 실제 부담이 있는 구간이 측정에서 빠져 있으므로, 이 수치는 정적 서빙의 운영상 이점을 오히려 낮게 잡는다. 비율은 크게 보이고 절대값은 작으며 진짜 비용은 측정 밖에 있다는 세 가지를 함께 읽어야 한다. 논문 Appendix D

8. 갱신 속도와 수명주기 회계

원논문 Figure 10. (a)는 갱신 속도 향상이고 채워진 표식이 출력 일치, 빈 표식이 불일치다. 세로 점선 왼쪽은 갱신이 재빌드보다 느린 구간이다. (b)는 뷰 구축 요소와 완결적이되 서로 더할 수 없는 재료화–적재–서빙 단계이고, (c)는 측정된 세 항으로부터의 회계 투사다. Yu et al. (2026), PDF p. 14. 원본 도판 영역 직접 추출.

8.1 일치한 전이와 일치하지 않은 전이

워크로드는 여덟 저장소에서 각각 다섯 개의 first-parent 커밋 전이를 따르고, 언어당 두 저장소씩 Go·Python·Rust·TS/JS를 담는다. 소스가 바뀐 전이는 그래프 33개, 벡터 31개다. 논문 §9.1

뷰	언어	전이	일치	속도 향상 중앙값 [IQR]	보조 지표
Graph	Go	7	7	8.89 [6.99, 10.01]	간선 F1 / 서빙 일치 100 / 100%
Graph	Python	8	8	6.95 [6.22, 13.00]	100 / 100%
Graph	Rust	9	0	17.00 [8.97, 40.42]*	99.12 / 97.40%
Graph	TS/JS	9	0	1.97 [1.32, 7.59]*	97.61 / 99.53%
Vector	Go	7	7	27.61 [22.18, 31.77]	아티팩트 7 / 재생 7
Vector	Python	6	6	38.18 [37.42, 38.75]	6 / 6
Vector	Rust	9	6	19.43 [14.26, 24.79]	9 / 6
Vector	TS/JS	9	9	13.63 [8.92, 25.53]	9 / 9

별표는 통과한 행이 없어 조건부 집계에서 제외된 원시 비율이다. 논문 Table 8

심볼 단위 복구는 33개 중 15개(45.5%)에서 독립 재빌드와 일치하고, 그 전이의 속도 향상 중앙값은 8.67배, IQR은 5.95–10.99배다. 파일 단위 교체는 14개에서 일치하며 중앙값 1.95배다. 두 경로가 모두 일치한 14개 전이에서 심볼 복구는 중앙값 4.25배 빠르다. 벡터 재사용은 31개 중 28개(90.3%)에서 일치하고 중앙값 25.44배, IQR 15.24–35.15배다. 31개 아티팩트 모두 문서 정체성과 벡터를 재현하지만, Rust 3개 행이 순서까지 정확한 top-10 재생에서 실패한다.

여기서 두 가지를 지적할 수 있다.

첫째, 집계에서 빠진 18개 전이가 한쪽으로 치우쳐 있지 않다. Rust 그래프의 원시 중앙 비율은 17.00배로 통과한 Go의 8.89배·Python의 6.95배보다 높은 반면, TS/JS는 1.97배로 네 행 중 가장 낮다. 제외된 값들이 위아래로 모두 걸쳐 있으므로 보고된 8.67배를 보수적이라거나 낙관적이라고 단정할 근거는 없다. 분명한 것은 네 언어 중 둘에 대해서는 "빠르면서 같은 결과를 낸다"는 주장의 근거가 아예 없다는 점이다.

둘째, 실패의 원인이 분해되지 않는다. Rust와 TS/JS의 간선 F1 중앙값은 99.12%와 97.61%, 서빙 일치는 97.40%와 99.53%로 재빌드와 거의 같다. 그런데 같은 커밋을 두 번 독립적으로 재빌드한 감사에서도 fresh/fresh 간선 F1 중앙값이 99.75%, 서빙 일치가 99.35%이고, 변경 범위에서 정확히 일치한 것은 네 건 중 세 건이다. 논문은 이를 두고 "콜드 라이브 LSP 재빌드는 모든 Rust/TS 그래프에 대해 결정론적 오라클이 아니다"라고 쓴다. 그렇다면 Rust·TS/JS의 0/9는 패처의 결함일 수도 있고 언어 서버의 비결정성일 수도 있으며, 이 설계로는 둘을 나눌 수 없다. 논문이 사후 허용 오차를 만들어 통과시키지 않고 원시 지표와 정확 일치 수를 나란히 보고한 선택은 적절하지만, 그 결과로 남는 것은 "두 언어에 대해서는 증분 갱신의 정확성에 관해 판단을 보류한다"는 상태다. 논문 §9.5, Appendix F

Figure 10(a)에는 세로 점선 왼쪽, 즉 갱신 경로가 재빌드보다 느린 전이도 있다. 다만 도판에서 그 표식은 모두 파일 단위 교체이고, 심볼 복구와 벡터 재사용에는 1배 아래로 내려간 전이가 없다. 평균이나 중앙값만 보면 보이지 않는 부분이다.

8.2 수명주기 비용은 더해지지 않는다

수명주기 회계는 준비된 체크아웃에서 시작한다. BM25·구조 그래프·벡터 구축의 중앙값은 각각 0.81초, 37.97초, 59.48초이고, 이들은 완전 재료화 단계에 기여하지만 질의 지연이 아니다. 아래 단계의 값은 재료화 B=116.7초(95% CI 65.6–153.9), 새 프로세스의 런타임 뷰 적재 L=7.40초(6.99–8.07), warm 서비스 추적 S=0.727초(0.593–1.079)다. 중앙 아티팩트 크기는 160.3 MiB다. 두 묶음은 서로 더할 수 없다. 예를 들어 평가된 벡터 빌더는 추적이 L_2만 질의하는데도 L_0와 L_2를 모두 재료화하고, 그 비용이 수명주기에 포함된다. 논문 §9.6, Appendix G

추적은 스냅샷당 20개 세션을 고정한다. 각 질의를 dense와 BM25로 한 번씩 실행하고 두 개의 정의 probe를 더해 20(1+1)+2=42개 요청이 된다. 이 수는 선택한 워크로드 규모가 아니라 구성에서 유도된 값이다. 참조는 보정 과정에서 정규화 집합이 흔들려 제외했다.

세션당 비용 투사는 B/q+L+S/N(프로세스 격리)과 (B+L)/q+S/N(상주 런타임)이다. q=20에서 13.20초와 6.24초, q=100에서 8.53초와 1.27초다. 논문은 여섯 개의 q 값이 실행된 여섯 규모가 아니라 같은 측정값으로부터의 투사이며, 1/q 항이 향하는 곳은 측정된 서빙 전용 비용이지 하드웨어 하한이 아니라고 명시한다.

이 절에서 눈에 띄는 것은 무엇이 계산되지 않았는가다. 구축은 116.7초와 160.3 MiB이고, 9절에서 볼 토큰 절감은 질의당 수만 토큰 규모다. 논문은 두 축을 끝까지 합치지 않는다. 각 연산의 비용을 분리해 보이겠다는 방침에는 일관되지만, 그 결과 "언제 이 시스템을 도입할 만한가"라는 질문은 답이 없는 채로 남는다. 도입을 검토하는 쪽에서는 자기 워크로드의 재사용 배수 q와 토큰 단가를 넣어 직접 계산해야 한다.

9. 컨텍스트 전달 정책과 토큰

9.1 세 팔은 전달과 보존을 함께 바꾼다

Q5는 전달과 보존을 나눈다. grep/read는 주입된 후보가 없고, eager는 고정된 상위 10개 L_2 블록 C^{\mathrm{ctx}}_{10}을 받으며, compact는 같은 후보를 받되 첫 성공한 read 이후 기록을 한 번 다시 쓴다. 세 팔은 이슈, 도구, 예산, 턴 상한, 모델 파라미터, 저장소 커밋, 답변 형식을 공유한다. 논문 §7.4

다만 세 팔이 보존 방식만 다른 것은 아니다. Eager와 Compact는 같은 후보를 받으므로 둘의 직접 대조만이 보존 효과를 분리하고, grep/read와의 비교는 후보 전달 방식까지 함께 바꾼다고 논문이 밝힌다. 헤드라인 토큰 절감이 바로 그 grep/read 대비 수치이므로, 그 값에는 후보 주입의 효과와 기록 보존의 효과가 섞여 있다. 논문 §4.2

재작성은 다음과 같다.

s는 시스템 프롬프트, q는 원래 이슈, e_{1:j}는 버려지는 탐색 기록이고 d_j는 방향 seed다. Seed에는 중복 제거한 read 경로, 마지막 성공한 read 결과 전체, 그리고 마지막 비어 있지 않은 어시스턴트 메시지의 앞 600자가 들어간다. 요약 모델을 부르지 않는 결정론적 재작성이고, 검색이 아니라 보존을 바꾼다. 재작성 이전에 이미 기록된 사용량은 그대로 집계에 남는다.

에이전트 실험은 CodeNib Synthesis를 쓴다. Base의 25개 저장소에서 스냅샷 하나씩을 골라 각 20개 질의를 붙인 500개 행이고, 질의 유형은 behavioral 175, file hint 76, module hint 75, reasoning 50, symbol hint 50, traversal 74다. 질의 500개·모델 5개·정책 3개로 7,500개 궤적이 나온다. 질의를 만든 모델과 판정한 모델은 같은 opus alias이고, 그 alias의 불변 리비전은 복구되지 않는다. 논문은 이를 스스로 기록한다. Base와 Synthesis가 저장소를 공유한다는 점도 함께 밝힌다. 논문 Appendix A

9.2 토큰은 줄지만 선택 규칙이 무엇을 고르는지 보아야 한다

원논문 Figure 11. (a–b)는 짝지은 grep/read 대비 모델별 토큰과 AnswerRecall@5 효과이고 후보는 공유된다. (c)는 워크로드 조각별 효과이며 라벨의 수는 다섯 모델·세 정책에 걸친 질의 수다. 수염은 스냅샷 군집 95% 구간이다. Yu et al. (2026), PDF p. 15. 원본 도판 영역 직접 추출.

grep/read 기준선의 절대량은 질의당 25.9–159.7천 토큰으로 크게 달라서, 비교는 짝지은 비율로 정규화한다. §4.3의 규칙을 적용하면 Haiku는 Eager가, 나머지 네 모델은 Compact가 선택된다. 모델 순서대로 선택된 팔은 짝지은 grep/read 토큰의 49.9%, 45.1%, 44.8%, 12.9%, 35.8%를 쓰고, ΔAnswerRecall@5는 −0.009에서 +0.067 사이이며 모든 하한이 −0.05 위에 있다. 초록의 "50–87% 적은 토큰"은 이 범위를 뒤집은 값이다. 논문 §9.7

압축이 항상 유리하지도 않다. Compact/Eager 토큰 비율은 Haiku의 123.3%부터 Gemma의 27.9%까지 벌어진다. Haiku에서는 한 번의 기록 재작성이 오히려 전체 토큰을 늘린다.

여기서 선택 규칙의 성격을 분명히 해야 한다. 규칙은 grep/read 대비 −0.05 게이트를 통과한 정책 중에서 토큰이 적은 쪽을 고른다. Gemma와 Gemini는 Eager의 ΔAnswerRecall@5가 각각 +0.11 수준으로 Compact보다 높지만, Compact가 게이트를 통과하면서 토큰이 더 적기 때문에 선택된다. 논문도 두 모델이 Eager 대비 0.070과 0.044를 내주면서 기준선 게이트를 통과한다고 적는다. 따라서 "87% 적은 토큰으로 위치 파악을 보존했다"는 문장은 grep/read를 기준으로 한 것이고, 해당 모델에서 품질이 가장 높았던 팔을 기준으로 한 것이 아니다. 부록의 절단 민감도 표에서 Qwen-27B의 Eager만 유일하게 게이트를 놓친다는 기록도 함께 보면, 게이트는 팔을 거르는 장치이고 순위를 정하는 것은 토큰이다. 논문 Appendix H, Table 9

워크로드 조각도 효과가 고르지 않다. Figure 11(c)에서 품질 상승은 behavioral 질의에 몰려 있고, 파일·모듈·심볼 힌트가 들어간 질의에서는 0 부근이다. 질의가 이미 파일이나 심볼 이름을 알려 주면 grep/read도 충분히 찾아간다고 읽을 수 있다. 논문은 여러 구간이 마진을 가로지르므로 하위 그룹 라우팅 주장을 하지 않는다고 명시한다. 이 신중함은 타당하지만, 반대로 말하면 "어떤 질의에 미리 주입을 켤 것인가"라는 실무적 질문에도 아직 답이 없다.

토큰 회계의 범위도 확인해야 한다. 집계는 제공자가 보고한 프롬프트·완성 토큰의 단순 합이고 답변 형식 호출까지 포함한다. 프리픽스 캐시 적중, prefill 작업, KV 메모리, 지연, 과금은 추정하지 않는다. Compact가 만드는 새 프리픽스는 이후 호출에서 재사용될 수 있지만, 이 실험은 그 효과를 측정하지 않는다. 토큰 절반이 곧 비용 절반이라고 옮겨 적을 수 없다. 논문 Appendix B

10. 한계, 재현 조건과 결론

10.1 논문이 밝힌 한계

• 패치 생성과 이슈 해결은 평가 범위 밖이다. 측정 대상은 저장소 상호작용과 위치 파악이다. 논문 §9
• manifest는 저장소 간 트랜잭션이 아니고, 컴파일은 커밋을 기록할 뿐 워크트리를 잠그지 않는다. 논문 §3.4
• 정적 내비게이션이 모든 라이브 응답을 재현하지 못하므로, 워크스페이스 의미가 필요한 호출자는 라이브 LSP 경로를 유지해야 한다.
• 증분 갱신의 동치 검사는 타이밍 이후 오프라인에서만 수행되며 온라인 정확성 오라클이 아니다. 논문 §4.2
• BM25에는 통합된 delta 갱신 경로가 없다. 논문 §6.4
• 엄격한 일치 검사는 유지보수 품질과 라이브 제공자의 재현성을 함께 드러내며, 콜드 라이브 LSP 재빌드는 모든 Rust/TS 그래프에 대해 결정론적 오라클이 아니다. 논문 §9.5, Appendix F
• 델타 경로는 모든 뷰를 트랜잭션으로 함께 진전시키지 않는다. 런타임은 이를 막는 대신 staleness 경고로 알리며, 뷰별 버전의 원자적 게시는 다음 시스템 경계로 제시된다. 논문 §§6.4, 7.1, 10
• ANN 비율은 구성요소 국소값이며 종단 속도 향상이 아니다. 더 큰 색인과 높은 질의율은 측정하지 않았다. 논문 §9.3
• 수명주기 투사는 측정된 세 항의 회계 투사이며 실행된 여섯 규모나 손익분기 주장이 아니다. 논문 §9.6
• Base와 Synthesis는 같은 저장소를 공유하므로 저장소 간 독립 증거가 아니다. 질의 생성과 판정에 쓴 opus alias는 불변 리비전을 복구할 수 없다. 논문 Appendix A
• Q1은 계획을 직접 호출하므로 라우팅 휴리스틱의 경로 선택 품질을 평가하지 않는다. MCP도 실험 요인이 아니다. 논문 §7.2

10.2 해설자 관점

세 헤드라인 수치는 서로 다른 부분집합 위에 있다. 8.67배는 그래프 전이의 45.5%, 4.72배는 내비게이션 요청의 63.2%, 토큰 절감은 모델별로 다르게 선택된 정책에서 성립한다. 각 조건은 논문에 명시되어 있고 이는 이 논문의 미덕이다. 다만 세 조건이 동시에 성립하는 운영 상태에서 시스템이 어떻게 동작하는지는 어느 실험도 보여 주지 않는다.

Q3에서 이득이 큰 곳과 호환이 낮은 곳이 겹친다. 다섯 언어 모두에서 참조의 일치율이 정의보다 낮고, 다섯 중 넷에서 참조의 중앙 비율이 정의보다 높다. 즉 정적 서빙이 가장 빛나는 능력이 가장 자주 어긋나는 능력이다. 게다가 절대 절감은 1.69 ms이고, 라이브 경로의 기동·워밍업은 측정에서 제외되어 있다.

초록의 87%는 최저 토큰 팔의 수치다. 선택 규칙 자체는 논문이 §4.3에 명시한 대로 게이트를 통과한 정책 중 토큰이 적은 쪽을 고른다. 그 규칙을 적용한 결과, Gemma와 Gemini에서는 같은 실험 안에서 품질이 가장 높은 팔인 Eager가 아니라 Compact가 보고된다. 따라서 초록의 "50–87% 적은 토큰으로 위치 파악을 보존"은 grep/read 대비 문장이며, 최고 품질 팔 대비 문장이 아니다.

그래프 확장의 "미해결"은 설계 해상도의 문제이기도 하다. held-out 42개 스냅샷에서 짝지은 전부-아니면-전무 지표를 쓰면 점추정값은 정의상 약 2.38%p의 배수로만 나올 수 있고, 보고된 전체 범위는 스냅샷 −2개에서 +3개에 해당한다. 구조 신호가 쓸모없다는 증거가 아니라, 이 규모에서는 판정할 수 없다는 뜻으로 읽어야 한다.

채택 손익 계산은 독자에게 남는다. 재료화 116.7초와 160.3 MiB, 그리고 질의당 수만 토큰의 절감은 단위가 다르고 논문은 이를 합치지 않는다. 스테이지를 하나의 점수로 뭉개지 않는 것은 논문이 기여로 선언한 설계이므로 이는 누락이 아니다. 다만 그 방침의 결과로, 자기 워크로드의 재사용 배수와 토큰 단가를 넣어 손익을 맞춰 보는 일은 읽는 쪽 몫이 된다.

뷰별 독립 갱신의 귀결은 여러 뷰를 동시에 읽는 호출자에게 돌아간다. 비트랜잭션 manifest, 뷰별 독립 갱신, staleness 경고, 다음 경계로서의 원자적 게시는 모두 논문이 명시한 사실이다. 여기에 덧붙일 것은 그 조합의 결과다. 같은 커밋·같은 주소로 결과가 돌아온다는 C1의 약속은 초기 빌드에서 구성상 성립하고, 그 뒤에는 호출자가 경고를 읽고 판단해야 한다. 랭킹 검색과 심볼 내비게이션을 한 과제 안에서 섞어 쓰는 에이전트에게 이는 설계 시 고려할 사항이다.

10.3 공개된 것과 확인하지 못한 것

공식 저장소는 공개되어 있고 Apache-2.0이며, 평가 하네스와 실험 코드를 포함한다. 데이터셋 두 개도 공개되어 있다. Base 데이터셋의 현재 리비전은 논문이 고정한 해시 4eb84e2와 일치한다. Synthesis 데이터셋은 논문이 고정한 리비전 5ac36c3이 조회되지만 현재 head는 다른 리비전이다. 저장소 head commit은 2026년 9월 5일자로 v1 공개 이후에도 계속 갱신되었으므로, 현재 코드가 논문이 측정한 아티팩트와 1:1로 대응한다고 가정할 수 없다. 각 그림에 대응하는 원시 측정 결과 파일의 공개 위치는 이 검토에서 확인하지 못했다. (2026년 9월 12일 조회 기준)

재현을 시도한다면 다음이 필요하다. 다섯 언어 서버의 버전, 여덟 저장소의 전이 커밋 해시 목록, 리랭크 셀에서 빠진 스냅샷의 사유, 그리고 Haiku 실행의 하드웨어와 불변 모델 리비전이다. 나머지는 이미 부록에 기록되어 있다. 언어별 프로젝트 준비 절차와 n_{\mathrm{share}}=5를 포함한 갱신 스케줄 규칙은 Appendix D와 F에 있다. 질의 집합은 Synthesis 데이터셋 리비전과 parquet 해시로 고정되어 있고, Q3의 앵커는 정렬 후 균등 간격 선택이라 시드가 필요하지 않으며, 답변 형식 호출 비율은 다섯 모델 모두 보고되어 있다. 논문은 남은 제공자 시점 드리프트도 스스로 미해결이라고 밝힌다. 논문 §9.1, Appendix A·H

10.4 적용을 검토할 때 확인할 것

설계 질문	확인할 대상
같은 커밋을 몇 번이나 다시 질의하는가?	재사용 배수 q, 상주 런타임 여부, 116.7초 재료화의 상각
어떤 언어를 다루는가?	SCIP 경로인지 clangd 경로인지, 증분 갱신 일치가 확인된 언어인지
어떤 능력을 자주 호출하는가?	정의 위주인지 참조 위주인지, 참조라면 라이브 경로 유지 필요
지연 예산의 주인은 무엇인가?	리랭커 초 단위, dense 질의 전체 수십~수백 ms, 그중 FAISS 검색 1 ms 미만
질의가 어떤 형태로 들어오는가?	힌트가 포함된 질의인지 행동 설명 질의인지
토큰 절감을 어떻게 환산하는가?	프리픽스 캐시·prefill·과금은 측정 밖, 제공자 보고 합계만 존재
뷰가 어긋났을 때 무엇이 일어나는가?	staleness 경고의 처리 방식, 원자적 게시 부재의 영향

10.5 결론

CodeNib의 기여는 저장소 컨텍스트를 여러 뷰로 미리 만들었다는 사실 하나에 있지 않다. 커밋과 소스 주소를 공통 기준으로 삼아 서로 다른 물리 구조의 결과를 연결하고, 뷰마다 다른 갱신 경로를 따로 평가하며, 랭킹 후보와 소스 위치와 프롬프트 기록을 하나의 추상으로 뭉개지 않은 채 에이전트에 전달하는 연결 방식에 있다. 다섯 실험은 각각의 출력 계약 위에서 측정되고, 보고된 속도 향상은 모두 그 계약을 통과한 부분집합에 한정된다.

이 절제가 이 논문의 성격을 결정한다. 여기서 얻는 것은 "에이전트가 더 잘 고친다"는 결론이 아니라, 어떤 연산이 정확히 대체 가능하고 어떤 연산이 조건부 절충이며 어떤 연산은 아직 판정할 수 없는지에 대한 지도다. 증분 갱신은 두 언어에서 검증되었고 두 언어에서는 보류 상태다. 정적 내비게이션은 정의에서 대체로 일치하고 참조에서 그렇지 않다. 컨텍스트 정책은 토큰을 절반 이하로 줄이지만 그 선택은 모델마다 다르다. 남은 질문은 이 조건들이 동시에 성립하는 운영 환경에서, 그리고 동시 갱신과 다중 테넌시가 들어온 뒤에도 같은 경계가 유지되는지다.

원논문 Figures 2, 3, 6, 7, 9, 10, 11을 도판 영역만 추출해 인용하고 한국어 해설을 덧붙였다. Figure 7은 (a)와 (b–c) 패널 영역으로 나누어 배치했으며 원본 그래프·축·범례·수치는 유지했다. 이 글은 v1의 원문 검토이며, 시스템이나 모델 실험을 새로 실행한 것은 아니다.

References

Chen, Z., Tang, R., Deng, G., Wu, F., Wu, J., Jiang, Z., Prasanna, V., Cohan, A., & Wang, X. (2025). LocAgent: Graph-guided LLM agents for code localization. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 8697–8727). Association for Computational Linguistics. ACL Anthology

Cormack, G. V., Clarke, C. L. A., & Büttcher, S. (2009). Reciprocal rank fusion outperforms condorcet and individual rank learning methods. In Proceedings of the 32nd International ACM SIGIR Conference on Research and Development in Information Retrieval (pp. 758–759). Association for Computing Machinery. ACM DL

Gupta, A., Mumick, I. S., & Subrahmanian, V. S. (1993). Maintaining views incrementally. In Proceedings of the 1993 ACM SIGMOD International Conference on Management of Data (pp. 157–166). Association for Computing Machinery. ACM DL

Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., & Narasimhan, K. (2024). SWE-bench: Can language models resolve real-world GitHub issues? In International Conference on Learning Representations. OpenReview

Johnson, J., Douze, M., & Jégou, H. (2021). Billion-scale similarity search with GPUs. IEEE Transactions on Big Data, 7(3), 535–547. IEEE Xplore

Malkov, Y. A., & Yashunin, D. A. (2020). Efficient and robust approximate nearest neighbor search using hierarchical navigable small world graphs. IEEE Transactions on Pattern Analysis and Machine Intelligence, 42(4), 824–836. IEEE Xplore

Reddy, R. G., Suresh, T., Doo, J., Liu, Y., Nguyen, X. P., Zhou, Y., Yavuz, S., Xiong, C., Ji, H., & Joty, S. (2026). SweRank: Software issue localization with code ranking. In International Conference on Learning Representations. arXiv 논문

Robertson, S., & Zaragoza, H. (2009). The probabilistic relevance framework: BM25 and beyond. Foundations and Trends in Information Retrieval, 3(4), 333–389. 출판사 페이지

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K. R., & Cao, Y. (2023). ReAct: Synergizing reasoning and acting in language models. In International Conference on Learning Representations. OpenReview

Yu, Z., Yu, H., Yuan, B., Zhao, S., Chen, Y., Dokania, A., Jagtap, M., Chang, J., Ma, Y., Jayswal, Y., Ni, W., Zhang, H., Chen, Z., Deng, G., & Zhao, J. (2026). CodeNib: A multi-view data system for serving repository context to coding agents (arXiv:2607.25431v1). arXiv. arXiv 논문

Yu, Z., Zhang, H., Zhao, Y., Huang, H., Yao, M., Ding, K., & Zhao, J. (2025). OrcaLoca: An LLM agent framework for software issue localization. In Proceedings of the 42nd International Conference on Machine Learning (Vol. 267, pp. 73416–73436). PMLR. PMLR proceedings

Zhang, Y., Li, M., Long, D., Zhang, X., Lin, H., Yang, B., Xie, P., Yang, A., Liu, D., Lin, J., Huang, F., & Zhou, J. (2025). Qwen3 embedding: Advancing text embedding and reranking through foundation models (arXiv:2506.05176). arXiv. arXiv 논문