같은 PR에 12.5배 청구서, 코딩 에이전트 비용의 민낯

AI 요약

• 무슨 일: Joule Index가 실제 오픈소스 버그 수정에서 코딩 에이전트의 비용, 에너지, merge-readiness를 함께 공개했습니다.
  • V0.1은 8개 agent tier, 3개 May 2026 bug-fix task, 공개 observational trace를 기준으로 한 preview입니다.
• 핵심 숫자: 같은 merged PR과 일치한 5개 tier 사이에서도 작업당 비용은 $0.082에서 $1.025까지 12.5배 벌어졌습니다.
• 의미: 코딩 에이전트 조달 기준은 SWE-bench 점수만이 아니라 prompt cache, token budget, 공개 trace, 실패 비용으로 이동합니다.
• 주의점: 표본은 아직 작습니다. Joule Index 자신도 V0.1 숫자를 indicative로 두고, V1에서 n>=30과 direct power measurement를 예고했습니다.

코딩 에이전트 시장은 지금까지 꽤 단순한 질문으로 움직였습니다. 어떤 모델이 더 많은 GitHub issue를 고칩니까. 어떤 도구가 SWE-bench Verified에서 더 높은 점수를 냅니까. 어떤 에이전트가 terminal task를 더 오래 버팁니까. 이 질문은 여전히 중요합니다. 하지만 실제 개발팀이 에이전트를 쓰기 시작하면 곧 다른 질문이 따라옵니다. 같은 결과를 내는 데 얼마가 들었습니까. 그 비용은 prompt cache로 줄어든 것입니까, 아니면 더 싼 모델을 쓴 것입니까. 실패한 run의 비용은 누가 봅니까. vendor가 공개한 benchmark score를 다시 계산할 수 있습니까.

2026년 5월 공개된 Joule Index는 이 두 번째 질문을 전면에 놓은 새 코딩 에이전트 벤치마크입니다. Blankline Research는 이를 "AI cost, energy and merge-readiness"를 함께 보는 auditable benchmark로 설명합니다. 핵심은 성능 표 하나를 더 만든 것이 아닙니다. 코딩 에이전트가 실제 오픈소스 버그 수정에서 human maintainer가 merge한 PR과 같은 diff를 만들었을 때, 그 결과를 달러 비용, joule 추정치, file attention, 접근성, 공개 trace와 함께 읽게 만든 점입니다.

이번 V0.1의 가장 강한 숫자는 12.5배입니다. leaderboard에 따르면 8개 agent tier가 같은 3개 May 2026 오픈소스 bug-fix task를 수행했고, 그중 5개 tier가 Attention F1 1.000을 기록했습니다. 즉 human maintainer가 실제로 merge한 PR의 파일 집합과 일치하는 결과를 만들었습니다. 그런데 그 5개 tier 사이에서도 평균 작업당 비용은 Dropstone Fast의 0.082달러에서 Claude Opus 4.7의 1.025달러까지 벌어졌습니다. diff가 같고 merge-readiness가 같다면, 그 차이는 개발팀의 청구서와 에너지 예산에 남습니다.

정확도 표에 빠져 있던 열

AI 벤치마크는 대체로 capability를 중심으로 설계됩니다. 정답률, pass@k, Elo, solved rate, benchmark score가 표의 주인공입니다. 코딩 에이전트도 마찬가지였습니다. SWE-bench Verified는 실제 GitHub issue를 풀게 한다는 점에서 큰 진전이었고, Terminal-Bench나 Aider Polyglot 같은 지표는 더 다양한 개발 작업을 측정하게 만들었습니다. 하지만 대부분의 표는 "풀었는가"를 먼저 묻고, "얼마에 풀었는가"는 보조 정보로 밀어둡니다.

Joule Index가 흥미로운 이유는 이 순서를 흔든다는 점입니다. 벤치마크의 질문은 "실제 사용자가 최근에 제기한 버그를 코딩 에이전트가 human maintainer가 merge할 만한 PR로 고칠 수 있는가, 그리고 그 비용은 달러와 joule로 얼마인가"입니다. 이 질문은 모델 리더보드라기보다 조달 문서에 가깝습니다. 개발자에게도 더 실용적입니다. 조직이 코딩 에이전트를 수십 명, 수백 명 개발자에게 배포하면 한 번의 benchmark score보다 작업당 비용 분포, tail cost, 실패 run의 반복 비용이 더 큰 운영 변수가 됩니다.

Blankline이 공개한 V0.1은 아직 작습니다. 3개 task, 8개 verified tier, 한 개 retired task입니다. 이 숫자만으로 "어떤 모델이 시장에서 가장 경제적이다"라고 결론내리면 과장입니다. 그러나 preview임에도 이 자료가 뉴스가 되는 이유는 방향 때문입니다. 이제 코딩 에이전트 벤치마크는 정확도 하나로 충분하지 않습니다. agent loop의 token budget, cache hit, wall time, energy estimate, 공개 trace가 함께 붙어야 실제 도입 판단에 가까워집니다.

같은 diff인데 왜 12.5배가 벌어졌나

Joule Index paper의 가장 실무적인 대목은 prompt cache입니다. 코딩 에이전트는 보통 한 번의 모델 호출로 끝나지 않습니다. 저장소를 읽고, 파일을 열고, 계획을 쓰고, 수정하고, 테스트를 돌리고, 오류를 해석하고, 다시 수정합니다. 이 과정에서 시스템 프롬프트, 도구 설명, 저장소 맥락, 이전 대화가 반복 입력됩니다. provider가 이 반복 입력을 prompt cache로 처리하면 비용과 에너지 추정치가 내려갑니다. cache support가 없거나 cacheable prefix를 잘 만들지 못하면 같은 일을 하면서도 매번 전체 문맥을 다시 계산하게 됩니다.

Blankline은 V0.1 데이터에서 Dropstone Fast의 input token cache-read rate가 66%, Dropstone Pro가 79%, Claude Haiku 4.5가 95%, Dropstone Heavy가 0%였다고 설명합니다. 여기서 중요한 것은 "Heavy가 멍청하다"가 아닙니다. Heavy도 Attention F1 1.000을 냈습니다. 문제는 같은 output을 내는 동안 cache를 활용하지 못해 비용과 joule 축에서 크게 밀렸다는 점입니다. paper는 이를 capability gap보다 inference architecture gap으로 읽습니다.

이 해석은 최근 에이전트 비용 논의와 잘 맞습니다. 단일 prompt 가격표는 에이전트 비용을 설명하지 못합니다. 에이전트는 같은 context를 반복해서 읽고, 파일 시스템과 shell을 오가며, 때로는 실패한 test output을 다시 모델에 넣습니다. 따라서 실제 비용은 모델 단가, output length, prompt cache, tool loop 횟수, repository 크기, harness 설계가 합쳐진 함수입니다. "저 모델이 싸다"보다 "우리 agent harness가 cacheable prefix를 안정적으로 유지하나"가 더 큰 질문이 될 수 있습니다.

Joule이라는 이름이 말하는 것

달러 비용은 비교적 익숙합니다. API 과금표와 billing record가 있으니 팀도 볼 수 있습니다. 더 낯선 축은 joule입니다. Joule Index는 closed API의 실제 GPU 전력 사용량을 직접 측정한 것이 아니라, billed token count와 공개된 per-token energy rate를 바탕으로 cache-aware adjustment를 적용합니다. cache read token은 fresh input energy의 15%로 계산하고, output decode는 fresh input보다 높은 비용으로 봅니다. 방법론은 이 값을 보수적 추정으로 설명하고, V1에서 open-weight run에 대한 direct GPU power measurement를 계획한다고 밝힙니다.

이 축은 완벽하지 않습니다. closed provider의 실제 hardware, batching, region, utilization, cooling, power mix를 외부에서 정확히 알기는 어렵습니다. 따라서 joule 수치를 절대적 탄소 회계처럼 읽으면 안 됩니다. 그러나 비교 지표로는 의미가 있습니다. 같은 작업을 수행하는 agent tier 사이에서 반복 입력을 얼마나 줄였는지, decode와 context 재사용이 어떤 차이를 만드는지 보여주기 때문입니다. 특히 long-horizon coding task에서는 energy estimate가 단순 ESG 장식이 아니라 비용 구조의 다른 표현이 됩니다.

leaderboard에서 Dropstone Heavy는 평균 1,693J로 가장 높습니다. Claude Opus 4.7은 511J, Dropstone Fast는 224J, Claude Haiku 4.5는 146J입니다. 이 숫자는 "작은 모델이 항상 낫다"거나 "비싼 모델은 쓰면 안 된다"는 말이 아닙니다. 어려운 작업에서는 강한 모델이 실패 반복을 줄여 총비용을 낮출 수도 있습니다. 하지만 routine bug fix에서 같은 diff를 냈다면, 더 큰 모델과 더 무거운 inference path를 기본값으로 쓰는 것이 합리적인지 다시 물어야 합니다.

Verified disclosure가 조달 언어가 되는 순간

Joule Index의 두 번째 축은 공개 방식입니다. Verified entry는 full observational trace를 공개해야 합니다. 여기에는 agent가 만든 tool call, 읽은 파일, billed token, final git diff 같은 audit에 필요한 정보가 들어갑니다. 반대로 source code, system prompt, internal reasoning은 요구하지 않습니다. 이 선은 중요합니다. vendor 입장에서는 영업비밀을 모두 공개하지 않아도 되고, 사용자는 score를 다시 계산할 최소 증거를 얻습니다.

이는 MLPerf Power에서 가져온 사고방식에 가깝습니다. hardware benchmark가 단순히 "우리가 빠르다"는 주장으로 권위를 얻지 못하듯, agent benchmark도 "우리가 이겼다"는 slide만으로는 부족합니다. 어떤 task였고, 어떤 file을 읽었고, 얼마나 많은 token을 썼고, 비용과 joule을 어떻게 계산했으며, 최종 diff가 무엇인지가 있어야 합니다. 특히 코딩 에이전트는 모델 하나가 아니라 모델, harness, tool policy, sandbox, cache, retry loop가 결합된 시스템입니다. system-level trace 없이 model score만 보면 어디서 비용이 생겼는지 알 수 없습니다.

개발팀이 이 관점을 받아들이면 vendor 평가 질문도 바뀝니다. "SWE-bench 점수가 몇 점입니까" 옆에 "우리와 비슷한 repository 크기에서 task당 token budget은 얼마입니까", "prompt cache hit rate를 보여줄 수 있습니까", "실패 run과 retry run도 비용 report에 포함됩니까", "tool call trace를 export할 수 있습니까", "model routing이 바뀌면 같은 task의 비용이 어떻게 변합니까"가 붙습니다. 이것이 실제 agent 운영에 더 가까운 질문입니다.

표본이 작다는 사실도 뉴스입니다

이 글에서 가장 조심해야 할 부분은 V0.1의 표본 크기입니다. Joule Index methodology는 definitive claim을 위해 model과 category당 n>=30을 요구한다고 밝힙니다. 그런데 현재 preview는 n=3 per cell입니다. 따라서 "Dropstone Fast가 Claude Opus 4.7보다 좋다" 같은 결론은 부적절합니다. 특히 task가 작고 routine한 bug fix에 가까울수록 작은 모델이나 저렴한 tier가 유리하게 보일 수 있고, 어려운 architecture change나 security patch에서는 결과가 달라질 수 있습니다.

하지만 표본이 작다는 사실이 이 release의 의미를 없애지는 않습니다. 오히려 좋은 benchmark가 해야 할 일을 보여줍니다. Joule Index는 한 후보 task를 reviewer disagreement 때문에 retired 처리했고, 그 이유를 공개했습니다. methodology는 contamination defense, Verified disclosure, pricing preview row의 한계, energy estimate의 한계를 문서화합니다. 이 태도는 agent benchmark 시장에 필요합니다. 코딩 에이전트는 빠르게 좋아지고 있지만, benchmark도 그만큼 빠르게 marketing artifact가 될 수 있습니다. 작은 표본을 작은 표본이라고 말하는 것은 약점이 아니라 신뢰의 시작입니다.

개발자 입장에서도 이 점은 중요합니다. 내부 평가를 만들 때 처음부터 거대한 benchmark를 만들 필요는 없습니다. 오히려 팀의 실제 issue 10개, 반복 실행, token budget, cache hit, human review outcome, rollback 여부를 작은 표로 시작하는 편이 더 실용적입니다. 다만 그 표가 무엇을 말할 수 있고 무엇을 말할 수 없는지 명확히 해야 합니다. Joule Index V0.1은 그 균형을 보여주는 사례입니다.

pricing preview는 읽는 법이 다릅니다

leaderboard에는 verified run과 별도로 pricing preview가 있습니다. 이 부분은 자극적인 숫자를 만들기 쉽습니다. 예를 들어 reference task의 token budget을 일부 미제출 frontier model의 May 2026 list price에 적용하면 GPT-5.5나 GPT-5.5 Pro 같은 row가 10달러 cap을 넘는 것으로 표시됩니다. 그러나 methodology는 이를 capability claim이 아닌 list-price calculation으로 분리합니다. 측정된 run도 아니고, Joule Score에도 들어가지 않습니다.

이 구분은 중요합니다. 실제 agent run에서는 provider별 cache, compression, output style, tool loop, model routing이 달라집니다. 어떤 모델은 더 비싸도 더 적은 step으로 끝낼 수 있고, 어떤 모델은 싼 token을 많이 쓰며 돌아갈 수 있습니다. 따라서 pricing preview를 "저 모델은 나쁘다"로 읽으면 안 됩니다. 더 정확한 해석은 "long-horizon agent task에서 list price가 benchmark eligibility 자체를 흔들 수 있다"입니다. 에이전트 시대에는 모델 가격표가 research leaderboard와 조달 기준에 직접 영향을 줍니다.

이 대목은 기업 구매자에게 특히 중요합니다. 월정액 IDE 요금이나 seat price만 보면 agent cost가 숨습니다. 그러나 내부적으로는 API 호출, cache read, search, sandbox, storage, telemetry가 누적됩니다. vendor가 이를 bundle로 감추면 초기 도입은 쉬워지지만, 대규모 배포에서 비용 예측은 어려워집니다. 좋은 플랫폼은 단순히 "무제한처럼 보이는" 경험을 주는 것이 아니라, 작업 유형별 예산과 실패 비용을 보여줘야 합니다.

코딩 에이전트의 다음 경쟁은 cache policy입니다

최근 AI coding 도구 경쟁은 모델 이름 중심으로 보입니다. Claude Code, Codex, Gemini CLI, Cursor, OpenHands, Aider, Continue, enterprise agent platform이 각각 더 강한 모델과 더 긴 context를 붙입니다. 그러나 실제 운영에서는 cache policy가 조용한 차별점이 됩니다. stable prefix를 어떻게 구성하는지, repository summary를 언제 갱신하는지, tool schema를 매번 같은 순서로 넣는지, user-specific memory를 cacheable context와 분리하는지, test output을 얼마나 압축하는지가 비용을 바꿉니다.

이것은 개발팀이 직접 통제할 수 있는 영역이기도 합니다. 같은 모델을 써도 harness가 매번 system prompt를 조금씩 바꾸면 cache hit가 낮아집니다. tool list를 동적으로 재정렬하거나, 긴 policy 문서를 매 turn 새로 생성하거나, repository summary를 매번 새 timestamp와 함께 붙이면 cacheable prefix가 깨질 수 있습니다. 반대로 고정된 instruction, versioned tool schema, stable repo map, short structured event log를 분리하면 비용이 내려갈 여지가 생깁니다.

따라서 Joule Index가 던지는 실무 메시지는 "항상 싼 모델을 쓰라"가 아닙니다. 더 정확히는 "agent harness를 비용 측정 가능한 시스템으로 만들라"입니다. run마다 model, prompt version, cache-read ratio, input/output token, tool call count, wall time, retry count, final human verdict를 기록해야 합니다. 이것이 있어야 더 강한 모델을 써야 하는 task와 더 싼 tier로 충분한 task를 나눌 수 있습니다.

한국 개발팀에 필요한 체크리스트

한국의 개발 조직도 이미 코딩 에이전트를 실험 단계를 넘어 도입하고 있습니다. 개인 개발자는 Claude Code나 Codex를 바로 쓰고, 기업은 Copilot Business, Cursor Teams, 내부 agent runner, 사내 MCP 서버를 붙입니다. 이때 가장 쉬운 실수는 seat price만 보는 것입니다. seat price는 사람당 예산을 설명하지만, agent가 실제로 몇 번의 model call을 만들고 어떤 repository에서 긴 context를 반복하는지는 설명하지 못합니다.

첫째, task unit을 정해야 합니다. "하루에 AI를 얼마나 썼나"보다 "버그 수정 1건, 테스트 보강 1건, migration 1건, incident triage 1건" 같은 단위로 비용을 봐야 합니다. 그래야 사람 시간과 비교할 수 있습니다.

둘째, 성공과 실패를 같이 기록해야 합니다. 성공한 PR의 token cost만 보면 낙관적입니다. 실패한 run, 사람이 버린 patch, test를 깨뜨려 되돌린 run, review에서 reject된 run까지 포함해야 실제 비용이 보입니다.

셋째, cache metric을 공급자에게 요구해야 합니다. prompt cache를 지원하는지, cache read token이 billing에 어떻게 보이는지, agent run별 cache hit를 export할 수 있는지 확인해야 합니다. 이것은 단순 discount가 아니라 architecture signal입니다.

넷째, 내부 benchmark에는 공개 가능한 trace와 비공개 trace를 나눠야 합니다. source code와 prompt 전체를 외부에 공개할 수는 없어도, file touch set, diff summary, token count, tool call type, final verdict 정도는 내부 audit에 남길 수 있습니다. 에이전트가 만든 코드는 나중에 장애와 보안 사고의 일부가 될 수 있기 때문입니다.

다섯째, 작은 모델과 큰 모델을 역할로 나눠야 합니다. routine dependency update, 간단한 UI copy fix, test snapshot update, 작은 parser bug는 낮은 cost tier로 충분할 수 있습니다. 반대로 security-sensitive refactor, payment path, data migration, concurrency bug는 비싼 모델과 더 강한 human review가 맞을 수 있습니다. 중요한 것은 이 결정을 감으로 하지 않고 task-level data로 하는 것입니다.

벤치마크가 마케팅을 이기려면

Joule Index는 아직 검증받아야 할 점이 많습니다. Blankline이 자체 Dropstone CLI를 포함해 benchmark를 운영한다는 점은 이해상충 질문을 부릅니다. 공개 GitHub 저장소는 초기 상태이고, 커뮤니티 검증도 아직 충분하지 않습니다. energy estimate는 직접 측정이 아니며, Attention F1이 merge-readiness 전체를 대표한다고 보기도 어렵습니다. 실제 maintainer가 읽는 코드 품질, test coverage, maintainability, style fit은 파일 집합 일치보다 더 복잡합니다.

그럼에도 이번 release가 의미 있는 이유는 benchmark 시장의 약점을 정확히 찌르기 때문입니다. 에이전트 벤치마크가 늘어날수록 vendor는 자기에게 유리한 숫자를 골라 말할 수 있습니다. 사용자는 "점수가 높다"는 말만 듣고 비용, trace, 실패 mode를 보지 못합니다. Joule Index는 이 흐름에 "그 점수의 청구서와 전력 사용 추정치, 그리고 다시 계산 가능한 trace를 보여달라"고 요구합니다. 이 요구 자체는 오래 남을 가능성이 큽니다.

결국 코딩 에이전트의 다음 성숙 단계는 더 화려한 데모가 아니라 더 지루한 ledger일 수 있습니다. 어떤 파일을 읽었고, 어떤 도구를 호출했고, 어떤 모델이 몇 token을 썼고, cache가 얼마나 맞았고, 사람이 어떤 verdict를 내렸는지 남기는 장부입니다. 개발자는 그 장부를 바탕으로 어떤 작업을 agent에게 맡길지, 어느 모델 tier를 기본값으로 둘지, 언제 사람 review를 강제할지 결정해야 합니다.

Joule Index V0.1은 작은 표입니다. 하지만 그 작은 표가 던진 질문은 큽니다. 같은 PR이 8센트에도 나오고 1달러에도 나온다면, 우리는 더 이상 "AI가 코드를 고칠 수 있나"만 물을 수 없습니다. 이제 질문은 "그 코드를 어떤 비용 구조와 어떤 증거 체계 안에서 고쳤나"입니다. 코딩 에이전트가 개인 실험을 넘어 팀의 생산 시스템이 되는 순간, 이 질문이 실제 경쟁력이 됩니다.

출처

• Blankline Research: The Joule Index paper
• Joule Index 공식 사이트
• Joule Index leaderboard
• Joule Index methodology
• blankline-org/joule-index GitHub 저장소