에이전트가 코드를 '찾느라' 돈을 쓰고 있어요
Claude Code, Cursor, Codex 같은 AI 코딩 에이전트를 써보셨다면 이런 장면 익숙하실 거예요. '이 함수 어디서 호출돼?'라고 물었더니 에이전트가 grep을 돌리고, 파일을 열고, 다른 파일을 또 열고, 다시 검색하고… 답 한 줄 받으려고 툴 호출이 열 번 넘게 일어나는 거요.
이번에 소개된 Pensieve라는 프로젝트가 바로 이 문제를 겨냥해요. 아이디어는 단순해요. 에이전트가 매번 코드베이스를 처음부터 뒤지게 두지 말고, 로컬에 인덱스(색인)를 미리 만들어두고 그걸 조회하게 하자는 거예요. 해리포터에서 기억을 꺼내 담아두는 그릇 이름을 따온 것처럼, 코드베이스에 대한 '기억'을 미리 저장해두는 셈이죠.
툴 호출은 왜 비쌀까
이게 왜 문제인지부터 짚어볼게요. LLM 에이전트에서 툴 호출 한 번은 생각보다 비싸요. 에이전트가 grep을 호출하면 그 결과가 통째로 컨텍스트(모델이 한 번에 읽는 대화 내용)에 들어가요. 파일을 열면 파일 내용이 또 들어가고요. 다음 턴에서 모델은 이걸 전부 다시 읽어야 하고요.
비유하자면 도서관에서 책 한 권을 찾는데, 색인 카드 없이 서가를 하나하나 돌면서 책을 꺼내 펼쳐보는 거랑 비슷해요. 찾긴 찾는데 오래 걸리고, 꺼내본 책이 책상 위에 계속 쌓여요. 그 책상이 컨텍스트 윈도우이고, 쌓인 만큼 토큰 비용이 나가는 거죠.
컨텍스트가 길어지면 모델이 중요한 정보를 놓치거나 엉뚱한 파일에 매달리는 문제도 생겨요. 그러니까 비용만이 아니라 답의 품질에도 영향을 주는 거예요.
로컬 인덱싱은 어떻게 동작할까
로컬 인덱싱은 이 탐색을 '미리' 해두는 접근이에요. 보통 이런 흐름으로 돌아가요.
먼저 코드베이스를 파싱(코드를 읽어서 구조를 분석)해서 함수, 클래스, 변수 같은 심볼(이름이 붙은 코드 단위)과 그 위치, 그리고 '누가 누구를 호출하는지' 같은 관계를 뽑아내요. 이걸 로컬 데이터베이스나 파일에 저장해두고, 코드가 바뀌면 바뀐 부분만 갱신해요. 그러면 에이전트는 '이 함수의 정의와 호출처를 알려줘' 같은 질문을 툴 호출 한 번으로 해결할 수 있어요. grep 결과 수백 줄 대신 딱 필요한 정보만 압축해서 받는 거죠.
여기서 포인트는 '로컬'이라는 점이에요. 코드를 외부 서버로 보내서 임베딩하는 방식과 달리 인덱스가 내 컴퓨터 안에만 있으니까 보안 걱정이 덜하고 네트워크 지연도 없어요. 회사 코드를 밖으로 보내기 꺼려지는 환경에서는 꽤 큰 차이예요.
비슷한 접근들과 비교해보면
이 문제를 고민한 게 Pensieve만은 아니에요.
Aider는 일찍부터 'repo map'이라는 기능을 써왔어요. tree-sitter라는 파서로 저장소 전체의 함수·클래스 시그니처를 뽑아내고, 중요도를 매겨서 압축한 지도를 모델에게 넘겨주는 방식이에요. Cursor는 코드베이스를 임베딩(텍스트를 숫자 벡터로 바꾼 것)해서 의미 기반 검색을 제공하고요. Serena 같은 MCP 서버는 LSP(언어 서버 프로토콜), 그러니까 VS Code에서 '정의로 이동'을 가능하게 해주는 그 기술을 에이전트에게 열어줘서 심볼 단위로 코드를 탐색하게 해줘요.
반대 철학도 있어요. Claude Code는 별도 인덱스 없이 grep과 파일 읽기를 되풀이하는 '에이전틱 검색'을 기본으로 써요. 인덱스는 금방 낡고 관리 부담이 있는 데다, 모델이 똑똑하면 직접 찾는 편이 더 정확하다는 판단이에요.
결국 트레이드오프예요. 인덱스는 빠르고 저렴하지만 최신 상태를 유지하는 비용이 들고, 에이전틱 검색은 항상 최신이지만 토큰을 많이 먹어요. Pensieve 같은 도구는 그 사이에서 '자주 나오는 구조적 질문은 인덱스로, 나머지는 직접 탐색으로' 균형을 잡으려는 시도라고 보면 돼요.
실무에서 어떻게 써볼까
당장 적용해볼 만한 포인트를 정리해볼게요.
대형 레거시 코드베이스를 다루신다면 효과가 클 거예요. 수십만 줄짜리 자바·스프링 모노레포에서 에이전트가 grep으로 헤매는 비용은 생각보다 크거든요. 인덱스 기반 도구나 LSP 연동 MCP 서버를 붙여보면 토큰 사용량 차이가 꽤 느껴질 거예요.
API 비용을 직접 내는 팀이라면 도입 전후로 세션당 툴 호출 횟수와 입력 토큰을 꼭 재보세요. 숫자로 보면 도입할지 말지 판단하기가 훨씬 쉬워져요.
도구를 따로 안 쓰더라도 이 아이디어는 바로 써먹을 수 있어요. 프로젝트 루트에 아키텍처 개요나 주요 모듈 위치를 정리한 문서(CLAUDE.md나 AGENTS.md 같은)를 두는 것도 일종의 '수동 인덱스'거든요. 에이전트가 헤매는 시간이 확실히 줄어요.
마무리
한 줄 정리: AI 에이전트의 비용과 정확도는 '모델이 얼마나 똑똑한가'만큼이나 '필요한 정보를 얼마나 적은 토큰으로 건네주느냐'에 달려 있어요.
여러분은 코딩 에이전트에 인덱스를 붙이는 쪽인가요, 그냥 직접 탐색하게 두는 쪽인가요? 실제로 토큰 비용 차이를 재보신 분이 있다면 경험 공유 부탁드려요.
🔗 출처: Hacker News