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". arXiv:2607.25431v1, 2026년 7월 28일 공개된 v1 기준. PDF · 공식 코드

한 줄 요약: CodeNib은 코딩 에이전트가 과제마다 저장소를 처음부터 뒤지는 대신, 같은 커밋의 코드를 여러 관점으로 미리 정리해 두고 필요한 관점만 꺼내 쓰게 하려는 시스템이다. 다만 논문은 이것이 이슈 해결률을 올린다고 보여 주지 않는다. 검색·위치 찾기·갱신·컨텍스트 토큰을 서로 다른 품질 기준으로 나눠 측정한다.

1. 왜 에이전트는 같은 저장소를 계속 다시 읽을까

코딩 에이전트에게 “이 API의 timeout은 어디에서 결정되나?”라고 물었다고 해 보자. 에이전트는 timeout이라는 글자를 찾고, 이름이 달라도 역할이 비슷한 코드를 찾고, 정의와 호출 위치를 따라가며 파일을 읽는다. 다음 이슈가 들어오면 상당 부분을 다시 한다. 한 과제에서 얻은 관찰은 대화 기록에 남지만, 저장소 전체가 공유하는 지식이 되지는 않기 때문이다.

CodeNib은 이 반복을 데이터 관리 문제로 본다. 특정 Git commit을 하나의 스냅샷으로 고정하고, 그 스냅샷에서 만든 검색 자료를 다음 과제에도 재사용한다. CodeNib이 다루는 범위는 “코드를 한 번 요약해 둔다”보다 넓다. 어떤 자료가 어느 commit의 어느 파일·줄 범위에서 왔는지 끝까지 추적하고 저장소가 바뀌면 어떤 자료를 다시 만들어야 하는지도 구분한다. 논문은 이를 세 과제로 정리한다. 서로 다른 종류의 자료를 연결하는 일, 편집 뒤에 최신성을 유지하는 일, 그리고 그 자료를 에이전트의 도구와 프롬프트에 전달하는 일이다. 논문 §1, pp. 1–2

코드를 여러 관점으로 정리하는 부분과, 필요한 코드 조각을 에이전트에 건네는 부분을 따라가면 전체 흐름이 보인다. 도판의 해시·점수·갱신 지연 값은 예시이며 모든 색인이 동시에 최신이라는 보장을 뜻하지 않는다. 원논문 Figure 2, p. 3을 그대로 인용했다(arXiv:2607.25431v1).

2. 같은 코드를 세 가지 방식으로 정리한다

사람도 코드베이스를 찾는 방식이 하나가 아니다. 함수 이름을 기억하면 문자열 검색이 빠르고, “결제 실패를 재시도하는 로직”처럼 설명만 있으면 의미가 가까운 코드를 찾는 편이 낫다. “이 함수가 어디에서 쓰이나?”라는 질문은 호출 관계를 봐야 답할 수 있다. CodeNib은 이 셋을 하나로 섞지 않고 따로 만든다.

관점	쉽게 말하면	질문 예시
문자열(lexical) 색인	코드에 적힌 단어·경로를 찾는 색인	timeout, RetryPolicy는 어디에 있나?
의미(dense) 색인	설명과 역할이 가까운 코드 조각을 찾는 색인	결제 실패를 다시 시도하는 곳은?
구조(structural) 색인	정의·참조·의존 관계를 따라가는 지도	이 메서드는 누가 호출하나?

이 구분에는 구현 취향 이상의 이유가 있다. 문자열·의미 검색은 보통 “후보를 좋은 순서대로” 돌려주고, 구조 탐색은 “어느 위치인가”를 돌려준다. 둘은 답의 모양도, 틀렸을 때의 위험도 다르다. 그래서 논문은 모두를 하나의 정확도나 속도 점수로 합치지 않는다. 논문 §§4.2–4.3, pp. 4–5

3. 실제로는 이렇게 움직인다

예를 들어 “주문 취소 뒤 재고를 되돌리는 코드는 어디인가?”라는 이슈가 들어왔다고 하자. 에이전트는 먼저 현재 commit에 사용할 수 있는 뷰의 상태를 확인한다. 이름을 알고 있으면 문자열 색인부터, 설명만 있으면 의미 색인부터 쓴다. 의미 검색은 후보 코드 조각을 순위대로 내놓고, 필요하면 구조 색인이 그 함수의 정의나 참조 위치를 이어 준다. 마지막으로 에이전트는 상위 후보를 읽고 답을 만든다.

commit 스냅샷은 이 과정에서 안전장치 역할을 한다. 검색 결과가 지난주 코드에서 왔는데, 지금 읽는 파일은 오늘 코드라면 줄 번호와 관계가 어긋날 수 있다. CodeNib의 자료 목록인 manifest는 각 자료가 어떤 commit과 설정으로 만들어졌는지, 준비됐는지 갱신 중인지 기록한다. 하지만 이 manifest가 모든 자료를 동시에 바꿔 주는 것은 아니다. 뷰들은 독립적으로 만들어지고 갱신된다. 논문도 편집 뒤 여러 저장물을 가로지르는 트랜잭션은 제공하지 않는다고 밝힌다. 즉 동시 변경이 잦은 저장소에서는 “현재 어떤 뷰가 늦었는가”를 읽는 운영 규칙이 필요하다. 논문 §5.4, p. 6; §10, p. 15

4. 저장소가 바뀌면 전부 다시 만들지 않아도 될까

이 질문이 논문의 실용적인 중심이다. 작은 수정마다 전체 그래프와 모든 임베딩을 다시 만들면, 재사용의 이점이 줄어든다. CodeNib은 코드 구조 쪽에서는 Git의 변경 내역과 코드의 정의·참조를 찾아주는 언어 서버를 함께 써서 영향받은 부분을 고치고, 벡터 쪽에서는 내용이 같은 코드 조각의 임베딩, 즉 의미 검색에 쓰는 숫자 표현을 재사용한다.

전체를 다시 만드는 방식, 바뀐 파일을 다시 연결하는 방식, 영향받은 심볼만 고치는 방식이 어떻게 다른지 비교한다. 적게 고친다는 설계만으로 결과가 항상 같아지는 것은 아니므로, 뒤의 재빌드 일치율과 함께 읽어야 한다. 원논문 Figure 3, p. 7을 그대로 인용했다(arXiv:2607.25431v1).

하지만 “빨리 갱신했다”만으로는 충분하지 않다. 논문은 갱신 시간을 잰 뒤, 새 commit을 처음부터 다시 만든 결과와 같은지 별도로 확인한다. 여러 갱신 경로 중 그래프의 함수·클래스 같은 심볼을 고치는 경로는 33개 소스 변경 전이 중 15개가 독립 재빌드와 일치했다. 이 15개에서 속도 향상의 중앙값은 8.67배였다. 벡터 재사용 경로는 31개 중 28개가 일치했고, 이 28개에서 중앙값이 25.44배였다. 그래프의 파일 단위 교체 경로는 별도로 평가하므로 이 수치에 포함되지 않는다. 논문 §9.5, p. 14

숫자는 계산 조건과 함께 읽어야 한다. 8.67배는 33번의 모든 변경에서 보장된 값이 아니라, 일치한 15번의 조건부 중앙값이다. 또 이 검사는 갱신 경로에서 실시간으로 돌아가는 안전망이 아니라, 시간을 잰 뒤 따로 수행한 평가다. CodeNib이 빠른 갱신 경로를 제시했다는 점은 분명하지만, 운영 중 어떤 변경에서도 같은 결과를 보장한다는 뜻은 아니다.

5. 빠른 위치 찾기와 적은 토큰은 어떤 조건에서 나왔나

정적 구조 색인이 언어 서버를 대신할 수 있는지도 따로 시험했다. 정적 색인과 라이브 언어 서버가 정규화한 파일 경로·시작 줄 집합에서 같은 답을 낸 요청은 1,000개 중 632개였다. 그 일치한 요청만 놓고 보면 라이브/정적 지연의 중앙 비율은 4.72배이고, 중앙 절감은 1.69ms다. 나머지 요청도 같은 답을 냈다는 뜻은 아니며, 서버 기동과 워밍업 같은 비용도 이 비교에는 들어가지 않는다. 이 결과는 정적 색인이 조건에 맞는 위치 찾기에서 쓸 수 있는 선택지임을 보여 주지만, 라이브 언어 서버의 일반적인 대체를 증명하지는 않는다. 논문 §9.4, p. 13

컨텍스트 실험도 비슷한 방식으로 읽어야 한다. 논문은 에이전트가 직접 grep과 파일 읽기를 하는 방식, 상위 후보를 미리 넣는 Eager, 그 뒤 대화 기록을 한 번 압축하는 Compact를 비교했다. 다섯 모델에서 코드 위치를 찾는 성능이 기준선보다 정해진 허용 폭 이상 나빠지지 않는다는 조건을 통과한 정책은 이 실험의 grep/read 기준선이 쓴 토큰의 12.9–49.9%를 사용했고, 이에 따라 논문은 50–87% 적은 궤적 토큰이라고 요약한다. 논문 §9.7, p. 15

토큰을 얼마나 줄였는지와 찾아야 할 코드를 얼마나 찾았는지를 함께 비교한 그림이다. 본문의 절감 수치는 품질 조건을 통과한 모델별 정책에서 나온 값이며, 실제 과금·응답 시간·패치 성공률을 측정한 결과는 아니다. 원논문 Figure 11, p. 15을 그대로 인용했다(arXiv:2607.25431v1).

여기에도 두 겹의 조건이 있다. 먼저 모델마다 선택된 정책이 다르고, Compact가 언제나 Eager보다 낫지도 않다. 다음으로 이 토큰 수는 제공자가 보고한 프롬프트·완성 토큰의 합이다. 캐시 적중, 답 생성 전 입력 처리, 응답 지연, 실제 과금은 측정하지 않았다. 정해진 품질 기준을 통과한 모델별 정책이 이 실험의 토큰 회계에서 더 적게 썼다는 뜻이며 “모든 에이전트 비용이 87% 줄었다”고 일반화할 수는 없다.

6. 이 논문을 어디까지 가져갈 수 있나

같은 commit을 여러 과제에서 반복해 읽는가? 이름 검색, 의미 검색, 심볼 탐색 중 무엇이 자주 필요한가? 변경 뒤 일부 뷰가 늦어도 업무가 안전한가? 이 질문에 “그렇다”고 답할수록 CodeNib의 설계가 잘 맞을 가능성이 크다. 반대로 실시간 편집 상태, 동시 업데이트, 패치 생성 성공률이 중요한 환경이라면 이 논문만으로 결론을 내리기 어렵다. 저자들도 평가는 저장소 상호작용과 위치 파악에 한정하며, 패치 생성·이슈 해결·동시 운영 업데이트는 아직 범위 밖이라고 명시한다. 논문 §9, p. 10; §10, p. 15

CodeNib은 같은 commit의 저장소 정보를 재사용하면서 검색·위치 찾기·갱신·토큰 사용을 각각 검증하는 시스템 설계를 제시한다. 도입할 때도 어떤 정보가 어느 버전의 코드에서 왔는지, 갱신 뒤 결과가 맞는지, 실제로 자주 쓰는 요청에서 비용이 줄었는지를 나눠 확인해야 한다.

상세한 실험 설계, 수치별 조건, 그림과 비판적 검토는 상세 읽기에서 이어집니다.

References

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. https://arxiv.org/abs/2607.25431