레포 전체 vs 필요한 파일만: 직접 돌릴 수 있는 재현 가능한 비용 실험

주위에 물어보면 양쪽 다 자신만만한 답이 돌아옵니다. "에이전트한테 레포 전체를 줘 — 큰 그림이 필요하니까." "절대 그러지 마 — 매 요청마다 같은 파일을 다시 읽는 비용을 치르는 거야." 둘 다 그럴듯하고, 둘 다 대개 측정이 아니라 기억에서 암송된 겁니다. 정직한 답은 "태스크와 도구와 코드베이스에 따라 다르다"이고, 여러분의 경우 그 답을 알아내는 방법은 하나뿐입니다: 직접 실험하기.

이 글은 결과가 아니라 프로토콜입니다. 우리는 여러분의 레포에서 이걸 돌리지 않았고, 돌린 것처럼 꾸미지도 않겠습니다. 이하에는 공정하게 돌리는 법 — 대부분의 자작 벤치마크를 조용히 무효로 만드는 함정까지 — 을 담았습니다.

질문을 정확하게

비교는 추상적인 "큰 컨텍스트 vs 작은 컨텍스트"가 아닙니다. 같은 커밋, 같은 모델, 같은 설정, 같은 작업 문구에서, 에이전트가 레포 전체에서 컨텍스트를 스스로 찾게 하는 쪽이 관련 파일만 골라 건네는 쪽보다 총비용(토큰 + 재시도 + 재작업)이 더 드는가? 이겁니다.

총이라는 단어에 주목하세요. 한 번에 성공하는 전체-레포 실행이, 의존성을 놓쳐 작업을 다시 해야 하는 타깃 실행보다 쌀 수 있습니다. 첫 시도의 토큰만 세면 잘못된 것을 측정합니다.

두 팔의 실험에서 실제로 다른 것

실험의 두 팔은 정확히 한 가지만 달라야 합니다:

• 팔 A(레포 전체 탐색): 에이전트가 레포 루트에서 출발해 필요한 걸 스스로 찾습니다 — 자체 grep, 자체 파일 읽기, 자체 코드베이스 지도.
• 팔 B(타깃 컨텍스트): 여러분(또는 미리 작성된 고정 목록)이 작업에 필요한 파일을 지정합니다. 에이전트는 그 목록에서 출발하고 배회하지 않습니다.

나머지는 전부 같아야 합니다: 같은 커밋, 같은 모델, 같은 시스템 프롬프트와 설정, 같은 작업 표현. 팔 사이에서 모델이나 프롬프트까지 바꾸면, 측정한 건 컨텍스트 전략이 아니라 여러분의 프롬프트 실력입니다.

세팅

git 워크트리를 써서 두 팔이 서로를 건드리지 않으면서 동일한 커밋 위에서 돌게 하세요:

git worktree add ../repo-armA <commit>
git worktree add ../repo-armB <commit>

(각 팔은 깨끗한 사본에서 — 절대 같은 디렉토리에서 돌리지 마세요. 첫 에이전트의 파일 변경이 두 번째 팔의 시작 상태를 오염시킵니다.)

최소 반복 횟수: 한 번 이상이 아니라 여러 번. 단일 실행 비교는 일화입니다. 팔당 3회가 반복할 만한 결과의 최소선이고, 그래도 방향성 지표로만 취급하세요. 모델 API는 비결정적이라 같은 프롬프트도 다른 도구 호출 체인을 낼 수 있으므로, 한 쌍의 실행은 여러분을 오도할 수 있습니다.

통제하거나 기록할 교란 변수:

• 프롬프트 캐시 상태. 따뜻한 캐시는 두 번째 동일-컨텍스트 호출을 더 싸게 만듭니다. 팔을 별도 세션에서 돌려 어느 팔의 캐시도 다른 팔을 데우지 않게 하고, 도구가 노출하면 캐시 히트율을 기록하세요.
• 순서. 두 번째로 도는 팔이 여러분이 과제를 더 잘 이해한 이득을 봅니다. A만 다 돌리고 B를 돌리지 말고 교차(A-B-A-B 또는 무작위)로 돌리세요.
• 과제 선택. 답이 두 개의 알려진 파일에 있는 과제는 팔 B에 유리하게 고정되어 있고, 횡단적 탐색이 필요한 과제는 팔 A에 유리합니다. 실제로 하는 과제를 고르고, 각 과제가 어느 쪽으로 기우는지 기록하세요.
• 숨은 재시도. 에이전트가 조용히 재시도한 실패한 도구 호출도 토큰을 씁니다. 세어야 합니다.
• 사람의 시간. 팔 B를 위해 파일 목록을 엄선하는 데 20분이 든다면 그 비용은 토큰 청구서에 안 보여도 실재합니다.

기록표 (일부러 비워 둠)

우리는 숫자가 아니라 표를 공개합니다. 특정 레포에서 돌려 보기 전까지 "여러분의" 경우에 대한 정직한 숫자는 존재하지 않습니다 — 프로토콜 없이 그 숫자를 인용하는 사람은 추측하는 겁니다.

정직하게 채점하는 법:

• 총비용 = 토큰 입력 + 출력(여러분 플랜의 계량 기준 — 프롬프트의 실제 비용 참조), + 재시도와 재실행, + 팔 B의 컨텍스트를 엄선한 여러분의 시간.
• 정확성이 먼저. 테스트를 통과 못 한 싼 실행은 싼 게 아니라 — 더 비싼 2회 실행 이야기의 전반부입니다. 각 팔의 출력을 고정 루브릭으로 채점하세요: 테스트 통과, 동작 일치, 회귀 없음.
• 텔레메트리 부재 = N/A, 0이 아님. 도구가 요청별 토큰 수를 안 알려주면 만들어내지 마세요. N/A라고 쓰세요. 정직하게 비어 있는 열이 허구로 가득 찬 열보다 낫습니다.
• 점이 아니라 범위를 보고하세요. "팔 B는 A의 0.7배 비용(실행 1–3)" — "43,210 토큰"이 아니라. 측정을 넘어선 정밀함은 데이터로 치장한 노이즈입니다.

적게 쓰면서 돌리는 법

• 프로토콜 자체를 디버깅할 땐 가장 싼 capable 모델로 드라이런 먼저. 첫 시도에서 깨지는 건 보통 모델이 아니라 하네스입니다.
• 각 실행의 지출 상한을 걸어라(대부분의 도구에 예산 플래그나 max-tokens 설정이 있음) — 폭주 루프가 벤치마크를 청구서로 바꿔놓지 못하게.
• 어차피 할 과제로 한 쌍의 실행부터. 팔 간 차이가 반복 간 잡음보다 명백히 작다면, 그것도 싼 값에 배운 겁니다.
• 기억이 아니라 진행 중에 기록해라. 세션 트랜스크립트와 도구 디버그 로그가 존재합니다. 세부가 생생할 때 실행마다 grep 하세요.

이 실험이 말해주는 것과 못 하는 것

말해줍니다: 여러분의 도구, 레포, 과제가 어떻게 상호작용하는지 — 예산 관점에서 중요한 질문의 유일한 버전. 의외의 비효율도 드러냅니다(벤더 의존성으로 배회하는 전체-레포 팔, 설정 파일을 놓쳐 루프 도는 타깃 팔).

못 해줍니다: 어디에나 적용되는 보편 상수. 하루치 실행은 커지는 레포나 모델 업데이트를 못 넘깁니다. 둘 중 하나가 실질적으로 변하면 다시 돌리세요. 그리고 일부러 하지 않은 주장도 적습니다: 이 글 어디에도 "X% 절감" 숫자가 없습니다 — 여러분의 코드에서 돌리지 않았기 때문이고, 여러분이 얻을 숫자야말로 직접 돌리는 요점입니다.

측정하는 동안의 실용적 기본값

아무것도 안 할 거라도: 뜨거운 과제는 작고 명확하게, 차가운 탐색 과제는 배회하게 두고, 기계적 작업은 싼 계량기로 라우팅하세요. 위의 프로토콜은 여러분의 레포에서 "작게"와 "싸게"가 무엇을 뜻하는지 알아내는 방법이고 — 그 답은 보통 두어 번의 실행 값을 합니다. 컨텍스트 전략은 여러분이 완전히 통제하는 몇 안 되는 비용 레버 중 하나니까요.

meshcode는 에이전트를 병렬 창으로 돌려 이 실험을 실용적으로 만듭니다: 팔 A는 한 창, 팔 B는 다른 창, 같은 레포, 같은 순간 — 그리고 기계적 실행용 선불 싼 모델이 곁에 있어 비교가 일일 쿼터를 먹어치우지 않습니다.

관련 글: 프롬프트 하나에 요청이 여러 번 드는 이유 · AI 코딩 에이전트 토큰 비용 비교 · 토큰당 생산성 늘리기.

👉 meshcode 다운로드