Graft로 AI 에이전트의 토큰 낭비와 느린 코드 탐색 해결하기

URL: https://www.youtube.com/watch?v=VCQPCvN4uiA 날짜: 2026-09-15 채널: Tech Bridge 원문 제목: [한영자막] GitHub 1위 트렌딩 도구가 해결한 AI 에이전트의 치명적인 문제입니다 관련 도구: Graft (Trail / NanoNets context-graph-engine) 관련 링크: https://trailhq.com/graft

---

📌 핵심 질문

==AI 코딩 에이전트가 코드를 수정하기 전에 반복하는 파일 탐색을 어떻게 줄여, 토큰 사용량·응답 시간·비용을 동시에 낮출 것인가?==

• Claude Code, Codex 같은 에이전트는 수정 대상 파일을 찾기 위해 여러 터미널 도구를 연속으로 호출한다.
• 각 호출마다 지금까지의 대화와 도구 결과가 모델에 다시 전달되어 컨텍스트가 커지고 사용량이 누적된다.
• 단순한 벡터 유사도 검색은 코드의 실제 의존 관계와 변경 영향 범위를 알지 못한다.
• Graft는 코드베이스를 노드와 엣지로 구성된 지식 그래프로 만들고, 에이전트가 파일을 검색하기 전에 관련 위치와 의존 관계를 파악하게 한다.
• 공개 벤치마크에서 162회 실행 기준 작업 시간 60% 단축, 도구 호출 46% 감소, 토큰 42% 감소, 비용 32% 절감이 보고됐다.

높은 성능의 모델은 좋은 결과를 내지만 많은 토큰을 소모하고, 고성능 모델일수록 사용량 한도에 더 빨리 도달하며 응답도 느려진다. Graft는 모델을 바꾸지 않고 프로젝트의 맥락을 미리 구조화해 이 병목을 줄인다. 별도 모델 API 키 없이 기존 모델 구독을 사용하고, 로컬 코드 관계를 지속해서 갱신한다는 점이 핵심이다.

전사 과정에서 자동 자막의 Graph, graft, clawed, Codeex, Calendarly, AIABS Pro 표기는 문맥과 제품명에 맞춰 각각 Graft, Claude Code, Codex, Calendly, AI Labs Pro로 보정했다.

1. 고성능 AI 모델이 코드 작업에서 치르는 비용

1.1. 모델 품질과 토큰·시간의 교환 관계

1. 좋은 모델일수록 결과와 비용이 함께 커진다

   1. Opus와 GPT 5.6 같은 좋은 모델은 대체로 좋은 출력을 제공한다.
   2. 좋은 출력의 대가로 많은 토큰을 소모한다.
   3. GPT Astra와 Fable 5.1 같은 고성능 모델은 다른 모델보다 사용량 한도에 훨씬 빨리 도달한다.
   4. 모델의 추론 속도도 느려 한 작업이 끝날 때까지 오래 기다리게 된다.

2. 문제의 초점은 모델 자체가 아니라 작업 방식이다

   1. 같은 모델을 계속 사용해도 프로젝트 안에서 필요한 코드를 찾는 방식이 비효율적이면 토큰이 탐색 과정에서 먼저 소진된다.
   2. 검색·읽기·수정의 왕복을 줄이지 않으면 더 좋은 모델을 선택할수록 비용과 대기 시간이 더 커진다.
   3. Graft는 모델의 품질을 낮추지 않고 에이전트가 프로젝트를 탐색하는 기본 방식을 바꾸는 접근을 취한다.

1.2. Graft가 해결하려는 약속

1. 저렴한 모델 사용이 아니라 불필요한 탐색 제거

   1. GitHub에서 트렌딩 중인 Graft는 코딩 에이전트가 프로젝트를 다루는 기본 방식을 바꾼다.
   2. 에이전트가 혼자 작업할 때보다 토큰을 적게 사용하고 더 빠르게 움직이는 것을 목표로 한다.
   3. 기존에도 비슷한 문제를 해결하려는 도구는 있었지만, 코드 의미의 유사성과 실제 연결 관계 사이에 큰 공백이 남아 있었다.

2. 설명의 범위

   1. AI Labs는 Graft가 왜 필요한지 설명한 뒤 설치, 프로젝트 초기화, 맵 생성, 에이전트 연동, 실제 앱 구축 결과까지 순서대로 보여준다.
   2. 핵심은 단순 검색 가속이 아니라 에이전트가 처음부터 프로젝트의 구조를 알고 시작하게 만드는 것이다.

2. 기본 코딩 에이전트의 치명적인 탐색 루프

2.1. 수정 전 파일을 찾는 과정

1. 변경 요청은 곧 탐색 요청이 된다

   1. 앱에 기능을 추가해 달라고 요청하면 에이전트는 먼저 변경을 작성해야 할 위치를 찾아야 한다.
   2. 에이전트는 원하는 기능과 관련된 단어를 검색하는 터미널 명령을 여러 번 사용한다.
   3. 모델은 첫 시도에 원하는 코드를 찾지 못하는 경우가 많다.
   4. 검색 범위를 좁히기 위해 여러 도구를 순서대로 사용해야 한다.

2. 도구 선택에도 모델 호출이 필요하다

   1. 다음에 어떤 도구를 쓸지 매번 모델이 결정한다.
   2. 에이전트는 지금까지의 전체 대화와 이미 실행한 도구의 응답을 모델에 다시 보낸다.
   3. 모델은 누적된 내용을 읽고 다음 검색이나 파일 읽기 단계를 결정한다.
   4. 필요한 파일에 도달하기까지 여러 턴이 발생하고, 각 턴이 사용량으로 계산된다.

2.2. 버튼 색상 변경으로 보는 왕복 구조

1. 검색에서 수정까지의 예시

   1. “버튼을 초록색으로 바꿔 달라”는 요청을 받아도 에이전트는 먼저 그 버튼의 코드가 어느 파일에 있는지 찾아야 한다.
   2. 첫 번째 도구 호출로 버튼을 포함한 파일을 검색한다.
   3. 검색 결과는 사용자의 메시지와 함께 모델에 전달된다.
   4. 에이전트는 두 번째 도구 호출로 해당 파일의 특정 코드 줄을 읽는다.
   5. 모델은 그제야 수정 작업을 수행한다.

2. 왕복이 만드는 누적 비용

   1. 사용자의 메시지와 도구 결과가 매번 다시 전송된다.
   2. 컨텍스트 윈도우는 검색 결과와 파일 내용을 포함하며 계속 커진다.
   3. 새로운 검색이 추가될 때마다 모델은 더 많은 내용을 읽고 다음 행동을 결정해야 한다.
   4. 필요한 파일을 좁히는 데 여러 턴을 쓰므로 실제 변경보다 탐색에 더 많은 시간이 걸린다.

2.3. 사용량 한도와 출력 품질의 악화

1. 한도 소진

   1. 한 세션에서 많은 작업을 수행하면 검색 왕복마다 누적된 토큰이 사용량 한도를 빠르게 소모한다.
   2. 고성능 모델을 사용할수록 각 턴의 비용이 커져 한도에 더 빨리 도달한다.

2. 집중력 저하

   1. 한도 소진은 유일한 문제가 아니다.
   2. 컨텍스트 윈도우에 검색 과정과 여러 도구 결과가 과도하게 쌓이면 에이전트가 한 가지 작업에 집중하기 어려워진다.
   3. 결과적으로 모델의 출력 품질도 낮아질 수 있다.
   4. 탐색 효율을 높이는 일은 비용 절감뿐 아니라 맥락 오염을 줄여 정확도를 지키는 일이기도 하다.

3. 벡터 검색이 남기는 구조적 공백

3.1. 일반적인 벡터 검색의 작동 방식

1. 코드를 숫자로 바꾸는 인덱싱

   1. 기존 도구의 흔한 접근법은 코드의 각 부분을 벡터라는 숫자 표현으로 변환하는 것이다.
   2. 사용자가 질문하면 검색 도구도 질문을 벡터로 변환한다.
   3. 검색 도구는 질문 벡터와 가장 가까운 코드 조각을 찾아 반환한다.
   4. 의미가 얼마나 비슷한지를 기준으로 정보를 찾는 방식이 벡터 검색이다.

2. 유사도와 기능적 관계는 다르다

   1. 의미가 비슷하다는 사실만으로 코드가 서로 어떻게 연결되는지는 알 수 없다.
   2. 계정 생성 코드와 계정 삭제 코드는 모두 “계정”이라는 질문과 잘 맞을 수 있다.
   3. 하지만 두 기능은 서로 반대되는 일을 수행한다.
   4. 잘못된 코드 조각을 선택하면 수정 결과가 크게 손상될 수 있다.

3.2. 코딩 에이전트가 벡터 검색을 기본으로 쓰지 않는 이유

1. 연결 관계와 변경 영향 범위가 빠진다

   1. 유사도 검색은 관련 있어 보이는 위치를 찾을 수 있지만, 한 부분을 바꿨을 때 어떤 다른 부분이 영향을 받는지 알려주지 못한다.
   2. 코드베이스의 참조 방향, 의존성, 호출 관계를 확인하려면 파일을 다시 읽고 추가 탐색을 해야 한다.

2. 검색 정확도와 비용의 균형 문제

   1. 유사도만으로는 코드 변경에 필요한 구조적 판단을 보장하기 어렵다.
   2. 그래서 대부분의 코딩 에이전트는 이 방법을 기본 탐색 방식으로 채택하지 않는다.
   3. Graft는 벡터 임베딩을 만들고 비슷한 문장을 고르는 대신, 실제 코드가 무엇을 사용하고 무엇에 의존하는지 기록한다.

4. Graft의 핵심: 코드베이스 지식 그래프

4.1. 노드와 엣지로 표현하는 프로젝트

1. 프로젝트 전체를 지도화한다

   1. Graft는 컴퓨터의 코드를 읽고 프로젝트 안에서 발견한 각 부분의 이름과 위치를 기록한다.
   2. 각 부분이 다른 부분과 어떻게 연결되는지도 기록한다.
   3. 이 지도에서 각 코드 구성 요소는 노드(node)다.
   4. 두 구성 요소 사이의 연결은 엣지(edge)다.

2. 관계 기반 검색

   1. 에이전트가 특정 부분을 사용하는 코드를 물으면 Graft는 엣지를 따라간다.
   2. 검색 대상과 연결된 코드를 함께 제공해 변경이 다른 부분에 영향을 주는지 판단하게 한다.
   3. 벡터 검색이 하지 못했던 영향 범위 확인이 구조적으로 가능해진다.
   4. 한 파일을 읽기 전에 관련 코드와 의존 관계를 알아 코드 변경의 위험 범위를 파악할 수 있다.

4.2. 로컬 JSON 맵과 브라우저 뷰어

1. JSON 저장

   1. Graft는 프로젝트 지도를 컴퓨터에 JSON 파일로 저장한다.
   2. JSON은 구조화된 정보와 그 정보에 붙은 세부 데이터를 함께 기록하기에 적합하다.
   3. 코드의 위치와 연결 관계를 구조적으로 보존하므로 매번 전체 코드를 처음부터 분석할 필요가 없다.

2. 시각적 탐색

   1. 브라우저에서 지도를 여는 뷰어도 제공된다.
   2. 사용자는 노드와 엣지를 직접 탐색하면서 프로젝트의 연결 구조를 확인할 수 있다.
   3. 빈 폴더로 시작하면 노드가 0개인 상태에서 출발하고 파일이 생길 때마다 노드가 추가된다.

4.3. 모델 API 키와 선택적 설명 페이지

1. 별도 모델 API 키 없이 동작

   1. Graft는 무료 오픈 소스 도구다.
   2. 핵심 기능은 별도의 모델 API 키를 사용하지 않는다.
   3. 따라서 사용자가 이미 이용 중인 모델 구독 환경에서 추가 API 비용 없이 작동한다.

2. 평문 설명 페이지는 선택 사항

   1. 선택적으로 모델을 이용해 앱의 각 부분이 무엇을 하고 서로 어떻게 맞물리는지 평문 페이지로 작성할 수 있다.
   2. 노드와 엣지로 연결 관계를 보여주는 기본 맵만으로도 에이전트는 구조를 파악할 수 있다.
   3. 설명 페이지는 코드의 연결뿐 아니라 코드가 무엇을 하는지까지 알려 주는 보충 정보다.
   4. 이 페이지가 있으면 에이전트가 각 파일을 일일이 열기 전에 구성 요소의 역할을 이해할 수 있다.

5. 벤치마크와 기대 효과

5.1. 공개 테스트 수치

1. 최상의 토큰 절감 사례

   1. Graft 팀은 에이전트의 토큰 사용량이 최대 4배 저렴해졌다고 보고한다.
   2. 4배 절감은 가장 좋은 조건에서 얻은 결과다.
   3. 절감의 근원은 모델을 더 싼 모델로 바꾸는 것이 아니라, 에이전트가 수행하던 파일 검색을 제거하는 데 있다.

2. 162회 실행 벤치마크

   1. 162회 실행에서 작업 시간은 평균 60% 줄었다.
   2. 에이전트의 도구 사용 횟수는 46% 감소했다.
   3. 토큰 사용량은 42% 감소했다.
   4. 전체 비용은 평균 32% 낮아졌다.
   5. 같은 에이전트와 같은 작업을 차가운 상태의 검색 방식과 그래프 우선 방식으로 비교한 결과다.

5.2. 프로젝트 규모에 따른 효과

1. 큰 프로젝트에서 절감 폭이 커진다

   1. 절감되는 양의 대부분은 에이전트가 더 이상 수행하지 않는 검색에서 나온다.
   2. 작은 프로젝트는 애초에 찾아야 할 코드가 많지 않아 줄일 검색도 적다.
   3. 프로젝트가 커질수록 관련 파일을 좁히기 위한 왕복이 늘어나므로 Graft의 사전 지도 효과가 커진다.

2. 지원 범위

   1. Claude Code와 Codex에서 작동한다.
   2. 터미널 명령이나 MCP(Model Context Protocol)를 사용하는 다른 코딩 에이전트에도 연결할 수 있다.
   3. 특정 모델이나 단일 에이전트에 종속된 최적화가 아니라, 파일 탐색이 필요한 에이전트의 공통 병목을 겨냥한다.

6. 최신 상태를 유지하는 증분 그래프

6.1. 벡터 맵과 다른 업데이트 방식

1. 실제 사용 관계를 기록한다

   1. Graft는 코드를 숫자로 바꾸고 의미 유사도로 매칭하지 않는다.
   2. 코드를 읽고 어느 부분이 어느 부분을 실제로 사용하는지 적는다.
   3. 한 부분을 바꿀 때 그 변경으로 무엇이 깨질 수 있는지 에이전트가 확인할 수 있다.

2. 변경된 부분만 갱신한다

   1. 코드가 바뀌면 Graft는 프로젝트 전체를 다시 만드는 대신 바뀐 부분을 업데이트한다.
   2. 맵이 프로젝트의 오래된 버전에 머물지 않도록 자동으로 최신 상태를 유지한다.
   3. 에이전트는 낡은 의존성 지도에 기반해 잘못된 파일을 고르는 위험을 줄인다.

6.2. 세션 시작과 프롬프트별 동작

1. 세션 시작 시 사용법을 주입한다

   1. Graft를 Claude Code에 연결하면 매 세션 시작 시 모델에 맵 사용법이 전달된다.
   2. 모델은 프로젝트를 처음 만났을 때부터 Graft 지도를 먼저 활용하는 방법을 안다.

2. 프롬프트에서 최대 세 위치를 붙인다

   1. 사용자가 프롬프트를 보낼 때마다 Graft는 메시지의 단어를 맵과 대조한다.
   2. 관련성이 높은 위치를 최대 3개까지 찾아 프롬프트에 첨부한다.
   3. 모델은 도구를 한 번도 호출하기 전에 어느 파일과 어느 줄을 읽어야 할지 단서를 얻는다.
   4. 실제 코드는 에이전트가 해당 줄을 읽을 때만 컨텍스트에 들어온다.
   5. 결과적으로 필요한 파일에 더 적은 턴으로 도달하고 컨텍스트에 추가되는 정보도 줄어든다.

6.3. CLI 방식과 MCP 방식

1. CLI의 프롬프트 선첨부 방식

   1. CLI 설정에서는 Graft가 프롬프트를 보고 관련 위치를 추정한다.
   2. 에이전트가 실제로 필요로 하는지와 무관하게 그 위치를 모든 메시지에 첨부한다.
   3. 선제적으로 맥락을 제공하기 때문에 더 빠르게 작동한다.

2. MCP의 필요 시 조회 방식

   1. MCP 설정에서는 프롬프트에 위치가 자동으로 붙지 않는다.
   2. 에이전트가 실제로 정보가 필요할 때만 Graft에 요청한다.
   3. Graft 자체 테스트에서는 MCP 방식이 CLI 방식보다 정답을 몇 개 더 맞혔다.
   4. 반대로 CLI 방식은 더 빨랐다.
   5. 설치하면 두 방식이 모두 제공되므로 속도와 필요 시 정밀 조회 사이에서 선택할 수 있다.

6.4. 모델을 쓰지 않는 자동 동기화

1. 질문 전 변경 여부 확인

   1. 에이전트가 질문에 답하기 전에 Graft는 맵 생성 이후 코드가 바뀌었는지 확인한다.
   2. 코드 변경이 감지되면 먼저 맵을 업데이트한다.
   3. 이 업데이트 과정에는 모델 호출이 필요하지 않다.

2. 파일 편집 후 훅 동작

   1. 에이전트가 파일을 편집한 뒤에도 Graft가 맵을 갱신한다.
   2. 사용자가 매번 별도 갱신 명령을 실행하지 않아도 다음 작업에 최신 관계가 반영된다.

7. 설치와 프로젝트 초기화

7.1. 설치 명령과 에이전트별 설정

1. 설치 경로

   1. Graft 공식 사이트에서 설치 명령을 복사할 수 있다.
   2. 사용하는 코딩 에이전트에 맞는 설정 프롬프트도 복사할 수 있다.
   3. 설정 프롬프트에는 Graft 설치와 프로젝트 연결에 필요한 명령이 들어 있다.
   4. 모든 과정을 직접 하려면 사이트의 설치 명령을 복사해 어느 폴더에서든 터미널로 실행하면 된다.
   5. 설치가 끝나면 CLI를 사용할 준비가 된다.

2. 기본 설치 예시

   npm install -g @nanonets/graft
   

7.2. 프로젝트 폴더에서 graft init 실행

1. 초기화 위치의 중요성

   1. 실제 프로젝트에서 사용하려면 작업 중인 프로젝트 폴더 안에서 init 명령을 실행해야 한다.
   2. 초기화 명령은 해당 폴더에 프로젝트 전용 지침을 추가한다.
   3. 다른 폴더에서 실행하면 그 프로젝트가 필요로 하는 지침을 작업 폴더에 남길 수 없다.

2. 에이전트 선택

   1. 초기화 과정에서 어떤 코딩 에이전트를 사용하는지 묻는다.
   2. 에이전트마다 필요한 설정이 다르므로 사용 중인 에이전트를 선택해야 한다.
   3. 예시에서는 Claude Code를 선택하고 설치를 진행했다.

7.3. 설치되는 스킬과 훅

1. 프로젝트 스킬

   1. 초기화가 끝나면 프로젝트 폴더에 Graft 스킬이 생긴다.
   2. 이 스킬은 에이전트에게 Graft 사용법과 사용할 수 있는 명령을 알려 준다.

2. 자동 실행 훅 세 가지

   1. 훅(hook)은 정해진 시점에 자동으로 실행되는 작은 스크립트다.
   2. 세션이 시작될 때 모델에 맵 사용 지침을 제공하는 훅이 설치된다.
   3. 사용자가 프롬프트를 보낼 때 일치하는 위치를 첨부하는 훅이 설치된다.
   4. Claude가 파일을 수정한 뒤 맵을 업데이트하는 훅도 설치된다.
   5. 훅들은 에이전트가 Graft 워크플로를 따르도록 강제한다.

7.4. 기존 프로젝트와 빈 폴더

1. 기존 프로젝트

   1. 이미 작업하던 프로젝트라면 같은 폴더에서 graft build 명령을 실행해야 한다.
   2. Graft가 기존 코드 전체를 훑고 현재 상태의 지도를 만든다.

2. 빈 폴더

   1. 빈 폴더에는 아직 지도화할 코드가 없다.
   2. 파일이 생긴 뒤 스킬이 Graft에 맵을 만들도록 한다.
   3. 초기 뷰어에는 노드가 0개로 표시된다.
   4. 파일이 생성될 때마다 노드와 연결이 추가된다.

8. 예약·스케줄링 앱 구축 실험

8.1. 실험 조건과 사전 준비

1. 앱과 모델

   1. Calendly와 비슷하지만 독립 사업자를 위한 예약·스케줄링 앱을 구축했다.
   2. 토큰을 매우 빠르게 소비하는 Fable 5.1을 사용했다.
   3. 모델이 잘못된 작업에 시간을 쓰지 않도록 실제 실행 전에 프로젝트 맥락을 준비했다.

2. PRD 작성

   1. 먼저 앱의 기능과 요구사항을 설명하는 PRD(Product Requirements Document)를 작성했다.
   2. PRD는 앱이 무엇을 해야 하는지, 어떤 기능이 필요한지 모델에 알려 주는 문서다.
   3. 에이전트가 구현 목표를 잃지 않도록 모든 기능 요구를 한 문서에 정리했다.

3. CLAUDE.md 작성

   1. 장시간 실행에서도 목표에서 벗어나지 않도록 모델 맞춤 지침을 담은 CLAUDE.md 파일을 추가했다.
   2. 사용한 파일은 AI Labs Pro 커뮤니티에 템플릿으로 업로드한 파일과 같은 템플릿이다.
   3. 처음에는 템플릿에 빈 부분이 있었으므로 PRD 내용을 이용해 에이전트가 CLAUDE.md의 빈 부분을 채우게 했다.
   4. PRD가 없다면 무엇을 만들고 있는지 프롬프트에 직접 설명해도 된다.

8.2. 자율 실행 프롬프트

1. 모델과 도구 지정

   1. CLAUDE.md를 업데이트한 뒤 Fable 5.1로 전환했다.
   2. 예약 앱을 만들라는 프롬프트와 함께 사용할 프레임워크·도구를 명시했다.

2. 중단·허가 요청 방지

   1. Fable 5.1이 스스로 작업 중이라는 사실을 명시적으로 알려야 한다.
   2. 작업을 멈추고 허가를 요청하지 말라고 지시했다.
   3. 장시간 실행 모델을 사용할 때 이 지시를 빼면 모델이 중간마다 확인을 요청해 자동화 이점이 줄어든다.

8.3. 첫 전체 빌드 결과

1. Graft 사용 시

   1. 빌드 시간은 39분이었다.
   2. 컨텍스트 윈도우 사용량은 약 31%였다.

2. Graft 미사용 시

   1. 같은 빌드는 47분이 걸렸다.
   2. 컨텍스트 윈도우 사용량은 약 35%였다.
   3. 두 앱의 기능은 실질적으로 거의 같았다.

3. 첫 빌드에서 차이가 제한적이었던 이유

   1. 첫 빌드 시점에는 Graft가 아직 프로젝트 전체의 맵을 완성하지 못했다.
   2. 따라서 기존 맵을 활용할 수 있는 변경 작업보다 첫 구축의 차이가 작았다.
   3. 프로젝트 구조가 축적된 이후 변경을 시작하면서 차이가 더 크게 벌어졌다.

8.4. 랜딩 페이지 전면 개편

1. 변경 속도

   1. Graft를 사용한 랜딩 페이지 전면 개편은 2분이 채 걸리지 않았다.
   2. Graft가 없었다면 같은 변경은 훨씬 더 오래 걸렸을 것으로 비교됐다.

2. 맵의 후속 갱신

   1. 변경 뒤 Graft는 새 파일을 반영해 맵을 업데이트했다.
   2. 해당 턴에서 절약한 토큰의 자체 추정치도 보여 줬다.
   3. 코드 변경과 맵 갱신이 이어지면서 이후 작업이 이미 최신 프로젝트 구조를 활용하게 된다.

9. 코드 외 프로젝트 맥락의 한계와 확장

9.1. Graft가 지도화하지 않는 파일

1. 실제 프로젝트는 코드만으로 구성되지 않는다

   1. 실제 프로젝트에는 무엇을 만들고 있는지 설명하는 여러 맥락 파일이 포함된다.
   2. PRD가 대표적인 예다.
   3. 영역별 지침 파일과 learnings.md 같은 학습·메모 파일도 에이전트의 작업 맥락을 구성한다.
   4. 그 밖에도 프로젝트 목표와 작업 방식을 설명하는 파일이 존재할 수 있다.

2. 현재 범위

   1. Graft의 기본 맵은 코드만 지도화한다.
   2. PRD와 메모 파일은 지도에 포함하지 않는다.
   3. 에이전트가 이런 파일을 읽어야 할 때는 기존의 기본 탐색 방식을 사용한다.
   4. 따라서 코드 탐색은 최적화되지만 비코드 맥락 파일을 읽는 비용까지 자동으로 없어지는 것은 아니다.

9.2. 비코딩 작업과 다중 계획 파일

1. 코딩 외 Claude Code 사용

   1. Claude Code는 코드 작성뿐 아니라 다양한 비코딩 작업에도 사용된다.
   2. 기본 Graft가 코드에만 맞춰져 있으면 실제 프로젝트의 모든 작업 흐름을 다루기 어렵다.

2. 확장 버전

   1. AI Labs 팀은 여러 계획 파일을 포함한 실제 프로젝트에서도 사용할 수 있도록 Graft를 일부 수정했다.
   2. 코드 이외의 작업 맥락과 여러 계획 파일을 다룰 수 있는 변형 버전을 AI Labs Pro에 추가했다.
   3. 이 확장은 코드 관계 지도만으로는 부족한 프로젝트 문서 맥락까지 작업 흐름에 포함하려는 시도다.

주요 발언 모음

“좋은 모델을 사용하면 보통 좋은 결과를 얻지만, 그 모델들은 많은 토큰도 소모한다.”

“에이전트가 혼자 작업할 때보다 토큰을 적게 사용하고 훨씬 빠르게 만든다.”

“유사도만으로는 앱의 각 부분이 어떻게 연결되는지 알 수 없다.”

“Graft는 코드를 숫자로 바꾸고 유사도로 매칭하지 않는다. 실제로 어느 부분이 어느 부분을 사용하는지 읽고 기록한다.”

“모델은 도구를 단 한 번 호출하기 전부터 어느 파일과 줄을 읽어야 하는지 알 수 있다.”

“MCP 버전은 CLI 버전보다 몇 개의 답을 더 맞혔고, CLI 버전은 더 빨랐다.”

“코드가 바뀌면 Graft는 전체를 다시 만드는 대신 바뀐 부분을 업데이트한다.”

“Graft를 사용한 빌드는 39분이 걸렸고 컨텍스트 윈도우의 약 31%를 사용했다. Graft가 없으면 47분과 약 35%였다.”

핵심 데이터 & 수치

• 162회 실행: 동일 에이전트·동일 작업을 차가운 탐색 방식과 그래프 우선 방식으로 비교한 자체 벤치마크 횟수다.
• 최대 4배 저렴: 토큰 사용량 기준으로 보고된 최상의 비용 절감 사례다.
• 작업 시간 60% 감소: 162회 실행에서 평균 작업 시간이 줄어든 폭이다.
• 도구 호출 46% 감소: 파일 검색을 위한 에이전트 도구 사용 횟수가 줄어든 폭이다.
• 토큰 42% 감소: 반복 검색과 누적 컨텍스트에 쓰이는 토큰의 평균 감소 폭이다.
• 비용 32% 감소: 벤치마크의 평균 전체 비용 절감 폭이다.
• 39분 대 47분: 예약·스케줄링 앱 전체 빌드에서 Graft 사용과 미사용에 걸린 시간이다.
• 컨텍스트 31% 대 35%: 같은 앱 빌드에서 Graft 사용과 미사용 시 컨텍스트 윈도우 사용량이다.
• 최대 3개 위치: CLI 방식이 각 프롬프트에 선제적으로 붙이는 관련 코드 위치의 상한이다.
• 2분 미만: Graft를 사용한 랜딩 페이지 전면 개편에 걸린 시간이다.
• 0개 노드: 빈 폴더에서 시작한 Graft 맵의 초기 상태이며, 파일이 생성되면 노드가 추가된다.

결론 및 시사점

1. 에이전트의 실제 병목을 먼저 줄여야 한다: 모델 성능을 높이는 것만으로는 반복적인 파일 탐색과 컨텍스트 누적을 해결할 수 없다.
2. 관계 지도가 유사도 검색보다 코드 변경에 적합하다: 기능 이름이 비슷한 코드를 고르는 데 그치지 않고 실제 의존 관계와 변경 영향 범위를 추적해야 한다.
3. Graft는 기존 구독을 보존한다: 핵심 맵 생성과 갱신에 별도 모델 API 키를 요구하지 않아 현재 사용 중인 에이전트 구독에 연결할 수 있다.
4. 초기 설정 뒤 자동으로 따라온다: npm install -g @nanonets/graft와 프로젝트 폴더에서의 graft init을 거치면 세션 시작·프롬프트·파일 편집 시 훅이 맵 사용과 갱신을 담당한다.
5. 기존 프로젝트는 먼저 빌드해야 한다: 이미 코드가 있는 저장소는 graft build로 현재 구조를 지도화해야 검색 절감 효과가 시작된다.
6. 작은 프로젝트보다 큰 코드베이스에 유리하다: 절감 효과의 원천이 검색 왕복 제거이므로 파일과 의존 관계가 많을수록 투자 대비 효과가 커진다.
7. CLI와 MCP는 속도·정확도의 선택지다: CLI는 모든 프롬프트에 빠르게 관련 위치를 붙이고, MCP는 필요한 순간에만 조회해 테스트 정확도가 조금 높았다.
8. 코드 맵과 문서 맥락을 구분해야 한다: 기본 Graft는 코드만 지도화하므로 PRD, CLAUDE.md, learnings.md, 계획 파일을 읽는 비용은 별도로 남는다.
9. 실무 적용 시 목표 문서를 함께 준비해야 한다: PRD와 에이전트 지침을 먼저 정리하면 고성능 모델이 잘못된 작업에 토큰을 쓰는 일을 줄일 수 있다.
10. 검증 수치와 한계를 함께 봐야 한다: 162회 자체 벤치마크와 예약 앱 사례는 유의미한 신호지만, 첫 전체 빌드의 차이는 작았고 맵이 충분히 쌓인 후 변경 작업에서 효과가 더 컸다.

핵심 요약 (20줄)

1. Opus와 GPT 5.6 같은 고성능 모델은 좋은 결과를 내지만 많은 토큰을 소모한다.
2. GPT Astra와 Fable 5.1처럼 고급 모델일수록 사용량 한도에 빨리 도달하고 응답도 느려진다.
3. Claude Code와 Codex는 코드를 고치기 전에 터미널 검색을 여러 번 수행한다.
4. 모델은 매 검색 턴마다 전체 대화와 기존 도구 결과를 다시 읽는다.
5. 버튼 색상 변경 같은 단순한 작업도 파일 검색과 코드 읽기를 거쳐야 수정된다.
6. 반복된 탐색은 컨텍스트 윈도우를 키우고 모델의 집중력과 출력 품질을 떨어뜨린다.
7. 벡터 검색은 의미가 비슷한 코드 조각을 찾지만 실제 의존 관계는 설명하지 못한다.
8. 계정 생성 코드와 계정 삭제 코드는 모두 계정과 관련되지만 기능은 정반대다.
9. Graft는 코드를 숫자 벡터가 아니라 노드와 엣지로 이루어진 지식 그래프로 지도화한다.
10. 각 노드는 코드 구성 요소이고 각 엣지는 실제 사용·참조·의존 관계를 나타낸다.
11. 에이전트는 그래프를 따라 변경 대상과 잠재적 영향 범위를 함께 파악한다.
12. 맵은 로컬 JSON으로 저장되고 브라우저 뷰어에서 연결 구조를 탐색할 수 있다.
13. 핵심 기능은 별도 모델 API 키 없이 기존 구독과 로컬 환경에서 작동한다.
14. 선택적 평문 설명 페이지는 코드 연결뿐 아니라 각 구성 요소의 역할까지 보충한다.
15. 162회 벤치마크에서 작업 시간은 60%, 도구 호출은 46% 줄었다.
16. 같은 벤치마크에서 토큰은 42%, 전체 비용은 평균 32% 감소했다.
17. CLI 방식은 프롬프트마다 최대 세 관련 위치를 미리 붙이고 MCP는 필요할 때만 조회한다.
18. 코드 변경 후에는 바뀐 부분만 자동 갱신해 오래된 프로젝트 맵을 피한다.
19. 예약 앱 실험에서 Graft 사용 빌드는 39분과 컨텍스트 31%로 끝났고 미사용 빌드는 47분과 35%를 사용했다.
20. 큰 코드베이스일수록 검색 왕복이 많으므로 Graft의 관계 지도와 자동 갱신 효과가 커진다.