매 세션마다 반복되는 '콜드 스타트' 비용
AI 코딩 에이전트를 팀에 붙이고 나서 가장 먼저 마주치는 문제는 모델 성능도, 프롬프트 품질도 아니다. 세션이 시작될 때마다 에이전트가 코드베이스를 처음부터 다시 읽는다는 것이다. 같은 파일, 같은 구조, 같은 토큰 비용—매번 반복된다. 팀 규모가 커지고 코드베이스가 늘어날수록 이 '콜드 스타트 세금'은 눈에 보이지 않는 형태로 쌓인다.
실측 비교가 드러낸 격차: 800k 토큰 vs 4k 토큰
dev.to에 공개된 실험은 이 문제를 숫자로 직접 드러낸다. FastAPI 레포지토리(108,075줄, 1,131개 파일)를 대상으로 네 가지 코드베이스 인덱싱 도구를 실측 비교한 결과, 툴 간 토큰 비용 격차는 상상 이상이었다.
가장 직관적인 접근인 Repomix는 레포 전체를 XML/Markdown으로 덤프한다. 결과는 약 800,000토큰—Claude나 GPT-4의 200k 컨텍스트 윈도우를 4~6번 초과한다. 코드 전체를 보여주지만, 에이전트는 여전히 아키텍처를 원시 소스에서 직접 추론해야 한다. Aider의 repo-map은 PageRank 방식으로 관련도 높은 코드를 압축해 8,000~15,000토큰 수준으로 줄이지만, Aider 외부에서는 쓸 수 없다는 치명적 제약이 있다. Codebase Memory MCP는 tree-sitter 기반 SQLite 지식 그래프를 구축해 쿼리당 스트리밍 방식으로 답하지만, 로컬 DB라 팀원이 머신을 바꾸거나 공유하면 처음부터 다시 빌드해야 한다. 반면 Stacklit이 동일 레포에서 생성한 JSON 인덱스는 4,142토큰—하나의 컨텍스트 윈도우에 완전히 들어간다.
비용 구조의 핵심: '얼마나 많이 보여주느냐'가 아니라 '무엇을 커밋하느냐'
이 실험이 진짜 가리키는 것은 토큰 수 자체가 아니다. 인덱스를 깃에 커밋할 수 있느냐는 팀 운영 관점에서 완전히 다른 문제를 푼다. Stacklit의 접근은 단순하다. 소스 코드 대신 구조—모듈 그래프, 익스포트, 타입, 최근 변경 이력—를 추출해 stacklit.json으로 레포에 커밋한다. 팀원이 클론하면 인덱스가 따라온다. Claude Code든 Cursor든 Copilot이든 별도 설정 없이 파일을 읽는다.
이건 단순한 최적화가 아니다. 에이전트가 항상 콜드 스타트를 워밍된 상태로 시작한다는 의미다. 멀티 에이전트 환경에서, 혹은 여러 팀원이 같은 레포에서 에이전트를 돌릴 때 이 차이는 선형이 아니라 누적적으로 커진다.
Claude Code Monitor Tool: 폴링을 버리고 이벤트로 깨워라
인덱스 비용 설계와 함께 눈여겨볼 신기능이 있다. GeekNews에 소개된 Claude Code의 Monitor Tool은 에이전트가 백그라운드 프로세스를 생성하고 stdout을 처리하는 방식으로 작동한다. 핵심은 폴링을 없앴다는 것이다.
기존 방식은 에이전트가 주기적으로 로그나 상태를 확인했다—토큰 낭비이고 불안정하다. Monitor Tool은 에이전트가 스레드를 차단하지 않고 대기하다가 특정 조건에서만 대화창으로 스트리밍한다. 실제 사용 패턴은 이렇다: kubectl logs -f | grep ..로 오류를 수신하고, 크래시가 발생하면 자동으로 PR을 제출한다. 로그를 계속 추적하되 필요할 때만 깨어나니, 토큰 효율은 높고 안정성은 올라간다.
이 둘을 연결하면 하나의 설계 원칙이 나온다. 에이전트는 필요한 것만 소비해야 한다—컨텍스트에서도, 루프에서도.
로컬 AI 어시스턴트가 보여준 '프로젝트 기억' 문제
dev.to의 LeanAI 구축 사례는 다른 각도에서 같은 문제를 건드린다. Hyderabad의 DevOps 엔지니어 Gowri Shankar가 Qwen2.5 Coder(7B/32B)를 로컬에서 돌려 만든 이 시스템은, 세션 간 대화를 ChromaDB에 저장하고 AST 기반 의존성 그래프(9,775개 엣지)로 코드베이스를 상시 인덱싱한다. 흥미로운 기능도 있다—AI 의심 점수를 붙여 커밋별 버그 원인을 추론하는 '시맨틱 git bisect', 엣지 케이스를 자동 생성하는 adversarial 퍼징, 그리고 실제 사용 패턴으로 QLoRA 파인튜닝을 돌리는 지속 학습 파이프라인.
솔직한 한계도 명확하다. CPU 환경에서 응답에 25~90초가 걸리고, 모델 성능은 GPT-4/Claude에 미치지 못한다. 하지만 이 사례가 시사하는 것은 로컬 AI의 성숙도가 아니다. '프로젝트 기억' 문제—에이전트가 매번 낯선 사람처럼 코드베이스를 대하는 구조적 결함—은 클라우드냐 로컬이냐를 막론하고 동일하게 존재한다는 사실이다.
팀 리드가 지금 당장 해야 할 설계 결정
세 사례를 종합하면 실전 팀이 도구를 고르기 전에 먼저 잡아야 할 설계 축이 보인다.
첫째, 인덱스 전략부터 결정하라. 소규모 원샷 쿼리면 Repomix로 충분하다. 하지만 팀원 여럿이 같은 레포에서 에이전트를 돌린다면, 커밋 가능한 구조 인덱스(Stacklit 방식)가 컨텍스트 비용을 통제하는 기준점이 된다. 여기에 Codebase Memory MCP를 시맨틱 쿼리 레이어로 얹는 조합이 현실적이다.
둘째, 에이전트가 '항상 깨어있어야 하는지' 설계하라. Claude Code Monitor Tool처럼 이벤트 기반으로 에이전트를 깨우는 패턴은 장기 실행 워크플로우에서 토큰 낭비를 구조적으로 막는다. CI/CD 파이프라인, 배포 모니터링, 로그 기반 자동 수정 같은 운영 자동화에 즉시 적용 가능하다.
셋째, 도구가 서로 배타적이지 않다는 점을 팀에 명확히 하라. Stacklit의 저자 스스로 말했듯, 커밋된 인덱스는 다른 모든 도구를 더 잘 작동하게 하는 베이스라인이다. 도구 선택은 'A냐 B냐'가 아니라 '각 도구가 워크플로우의 어느 레이어를 담당하느냐'의 문제다.
전망: 컨텍스트 비용은 곧 팀의 운영 비용이다
에이전트 도입 논의가 '어떤 도구를 쓸까'에서 '어떻게 운영할까'로 넘어가고 있다는 건 이미 여러 현장이 확인했다. 그런데 그 앞단—도구를 고르기 전에 컨텍스트 비용 구조를 어떻게 설계할 것인가—는 아직 많은 팀이 기본값에 맡겨두고 있다.
토큰은 추상적인 숫자가 아니다. 팀이 에이전트를 돌릴수록, 세션이 늘어날수록, 코드베이스가 커질수록 누적되는 실제 비용이다. 인덱스를 어떻게 커밋하고, 에이전트를 언제 깨우고, 어떤 도구가 어느 레이어를 맡는지—이 세 가지를 먼저 설계한 팀이 에이전트 ROI를 예측 가능한 범위 안에서 운영할 수 있다. 나머지는 그 다음 문제다.