Yohji Sakamoto

MCP 상호작용의 LLM 턴을 75% 이상 줄이는 방법: 5회에서 1회로

한 줄 요약

코딩 에이전트가 탐색 → 수정 → 빌드 → 테스트 → 린트를 처리할 때, 보통 도구 결과마다 모델이 다시 들어와 다음 호출을 결정합니다. 단순한 흐름도 LLM 턴이 5번이 됩니다.

Tura의 command_run은 의존 관계가 있는 명령 계획을 한 번에 보낼 수 있게 합니다. 런타임은 빌드·테스트·린트를 그대로 실행하지만, 예측 가능한 단계 사이에서 모델을 다시 깨울 필요가 없습니다.

예시 기준으로 모델 재진입은 5회에서 1회가 됩니다. 즉 80% 감소입니다. 이는 검증을 생략하는 방식이 아니라, 대화와 도구 호출의 반복 비용을 줄이는 방식입니다.

저는 Tura를 작업하고 있어 이를 공개합니다.

작업 단위 benchmark:
https://turaai.net/benchmark-task?task=workflow-ecommerce-ad-package#runs

GitHub:
https://github.com/Tura-AI/tura

MCP 에이전트에서 반복적인 tool-loop 비용을 줄이는 다른 접근도 궁금합니다.

코딩 에이전트 5턴 vs command_run 1회: 전체 예제

먼저 밝힙니다. 저는 오픈소스 Tura의 유지보수자입니다.

코딩 에이전트를 만드는 분들이 바로 이해할 수 있는 간단한 예제입니다.

일반적인 agent는 아래 작업을 5번의 LLM 턴으로 처리합니다.

Turn 1 — 확인
rg -n "TODO|command_run|handler" crates/
rg --files crates/runtime/src crates/tools/src

Turn 2 — 패치 적용

• // old command handler logic

• // patched command handler logic

Turn 3 — 빌드
cargo build -p runtime

Turn 4 — 테스트
cargo test -p runtime --lib

Turn 5 — lint
cargo clippy -p runtime --all-targets

명령 자체보다 큰 오버헤드는 모델을 5번 깨우고, 길어진 대화 기록을 매번 다시 보내는 부분입니다.

Tura는 command_run이라는 Macro 도구 하나로 같은 흐름을 한 번에 보냅니다.

{
"name": "command_run",
"arguments": {
"commands": [
{ "step": 1, "command_type": "shell_command", "command_line": "rg -n "TODO|command_run|handler" crates/" },
{ "step": 1, "command_type": "shell_command", "command_line": "rg --files crates/runtime/src crates/tools/src" },
{ "step": 2, "command_type": "apply_patch", "command_line": "*** Begin Patch\n*** Update File: crates/tools/src/command_run/handler.rs\n@@\n- // old command handler logic\n+ // patched command handler logic\n*** End Patch" },
{ "step": 3, "command_type": "shell_command", "command_line": "cargo build -p runtime" },
{ "step": 4, "command_type": "shell_command", "command_line": "cargo test -p runtime --lib" },
{ "step": 4, "command_type": "shell_command", "command_line": "cargo clippy -p runtime --all-targets" }
]
}
}

빌드, 테스트, lint는 그대로 실행합니다. 예측 가능한 단계 사이에서 LLM을 다시 호출하지 않는 것입니다.

전체 DeepSWE 비교에서 Balanced는 Codex CLI보다 턴을 35.8%, 토큰을 31.1% 적게 사용했습니다. Direct는 턴을 69.1%, 토큰을 77.5% 적게 사용했습니다.

GitHub: https://github.com/Tura-AI/tura

Benchmark: https://turaai.net/benchmark

코딩 에이전트의 5턴을 command_run 한 번으로 묶는 예제

먼저 밝힙니다. 저는 오픈소스 Tura의 유지보수자입니다.

코딩 에이전트를 만드는 분들이 바로 이해할 수 있는 간단한 예제입니다.

일반적인 agent는 아래 작업을 5번의 LLM 턴으로 처리합니다.

Turn 1 — 확인

rg -n "TODO|command_run|handler" crates/

rg --files crates/runtime/src crates/tools/src

Turn 2 — 패치 적용

- // old command handler logic

+ // patched command handler logic

Turn 3 — 빌드

cargo build -p runtime

Turn 4 — 테스트

cargo test -p runtime --lib

Turn 5 — lint

cargo clippy -p runtime --all-targets

명령 자체보다 큰 오버헤드는 모델을 5번 깨우고, 길어진 대화 기록을 매번 다시 보내는 부분입니다.

Tura는 command_run이라는 Macro 도구 하나로 같은 흐름을 한 번에 보냅니다.

{

"name": "command_run",

"arguments": {

"commands": [

{ "step": 1, "command_type": "shell_command", "command_line": "inspect files" },

{ "step": 2, "command_type": "apply_patch", "command_line": "apply patch" },

{ "step": 3, "command_type": "shell_command", "command_line": "cargo build -p runtime" },

{ "step": 4, "command_type": "shell_command", "command_line": "cargo test -p runtime --lib" },

{ "step": 4, "command_type": "shell_command", "command_line": "cargo clippy -p runtime --all-targets" }

]

}

}

빌드, 테스트, lint는 그대로 실행합니다. 예측 가능한 단계 사이에서 LLM을 다시 호출하지 않는 것입니다.

전체 DeepSWE 비교에서 Balanced는 Codex CLI보다 턴을 35.8%, 토큰을 31.1% 적게 사용했습니다. Direct는 턴을 69.1%, 토큰을 77.5% 적게 사용했습니다.

GitHub: https://github.com/Tura-AI/tura

Benchmark: https://turaai.net/benchmark

“토큰 90% 절감”이 실제 작업 비용 90% 절감은 아니었습니다

코딩 에이전트용 출력 압축 도구를 비교하다가, 애초에 보고 있던 지표가 잘못됐다는 생각이 들었습니다. 셸 출력 한 번을 얼마나 줄였는지가 아니라, 테스트를 통과한 작업 1건당 총비용을 봐야 했습니다.

Rust로 작성된 eza를 동작 호환 Python 구현으로 다시 만드는 동일한 작업을 세 조건에서 실행해 봤습니다. 검증 항목은 52개였고, 모든 실행은 GPT-5.6-sol High와 Codex CLI 0.144.1을 사용했습니다.

• 플러그인 없음: 평균 검증 점수 78.85%, 666만 토큰, $5.28, 62.5라운드

• Ponytail: 점수 80.77%, 토큰 -7.56%, 비용 -8.87%, 실행 시간 +13.51%

• RTK: 점수 76.92%, 토큰 +13.20%, 비용 +7.18%, 라운드 +44.00%

조건별 실행이 2회뿐이라 도구의 우열을 단정할 수는 없습니다. 오히려 눈에 띈 점은 같은 조건 안에서도 비용 편차가 30.78~51.69%였다는 사실입니다. 단 한 번의 좋은 결과만으로 “몇 % 절감”이라고 말하기에는 실행 경로의 변동성이 너무 컸습니다.

전체 140회 실행을 합쳐 보니 비용 구조도 예상과 달랐습니다. 캐시된 입력이 전체 토큰의 96.46%, 모델링 비용의 63.91%를 차지했고, 새 입력은 토큰의 3.16%지만 비용의 20.94%, 출력은 토큰의 0.38%지만 비용의 15.14%였습니다. 특정 명령의 출력만 크게 줄여도 전체 작업 비용에는 거의 반영되지 않을 수 있는 이유입니다.

그래서 지금은 다음 네 가지를 함께 봅니다.

1. 같은 작업을 도구 사용 전후로 여러 번 반복

2. 테스트나 외부 검증기로 최종 결과 확인

3. 재시도·실패·도구 호출·오케스트레이션 비용까지 전부 포함

4. 토큰 수가 아니라 ‘검증에 성공한 작업 1건당 비용’으로 비교

여러분은 코딩 에이전트 도구를 평가할 때 어떤 분모를 쓰고 계신가요? 특히 토큰은 줄었는데 재시도나 실행 시간이 늘어난 경험이 있었는지 궁금합니다.

실험 방법과 원자료 링크를 포함한 전체 분석:

https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea

공개 저장소:

https://github.com/Tura-AI/tura

이해관계 공개: 저는 Tura를 유지보수하고 있으며, 위 분석도 직접 작성했습니다.

MCP에서 낭비되는 턴은 툴 호출 수보다, 단계 사이의 전달에서 생길 때가 많습니다.

데모는 보통 한 번 호출로 끝나지만 실제 작업은 프로젝트 생성 → ID 읽기 → 미디어 가져오기 → clip ID 전달 → 내보내기처럼 이어집니다. 일반적인 에이전트 루프는 매 단계의 결과를 다시 모델에 넣고, 다음 호출의 ID를 채웁니다.

Tura의 command_run Macro는 이 의존성 그래프를 한 번에 기술합니다. 앞 단계가 성공해 만든 값은 뒤 단계가 참조하고 런타임이 그때 해석합니다. 의존성이 없는 명령은 함께 실행할 수 있습니다.

공개 이커머스 광고 워크플로에서는 두 실행이 같은 5개 검사를 통과하고 같은 산출물을 만들었습니다. Tura Direct는 모델 요청 3회, 비교 실행은 11회였고 총 토큰은 56,372 대 262,915로 78.6% 낮았습니다. MCP 호출 수는 오히려 11 대 9였습니다. 일을 덜 한 것이 아니라 누적 문맥을 모델에 반복해서 되돌려 보내지 않은 결과입니다.

의존성 체인이 길수록 Macro 안에 남기는 전달 하나마다 모델 재진입을 하나 줄일 수 있어 반복 문맥 절감은 누적될 수 있습니다. 다만 캐시·재시도·워크플로 구조에 따라 달라지는 값이지, 모든 작업에서 엄밀히 선형인 법칙은 아닙니다.

전체 trace와 변수 상속 규칙:
https://turaai.net/blog#what-we-learned-from-the-mcp-workflow-benchmark

소스 코드:
https://github.com/Tura-AI/tura

공개: Tura-AI의 작업을 공유합니다. 이 방식이 여러분의 MCP 워크플로에서도 유효한지 궁금합니다.

mini-swe-agent를 실제 디버깅이나 개발에 써보신 분 있나요?

DeepSWE의 agent harness 비교가 궁금해서 같은 디버깅 과제와 GPT-5.6 SOL High로 직접 돌려봤습니다.

현재 결과는 이렇습니다.

• Codex CLI High: 151.91M tokens, 성공률 60%
• 순정 mini-swe-agent: 70.33M tokens, 성공률 67%
• prompt는 그대로 두고 mini harness에 매크로 실행만 추가: 60.59M tokens, 성공률 78%

이 과제 묶음에서는 순정 mini-swe-agent가 Codex보다 token을 약 54% 적게 쓰면서 성공률은 7%p 높았습니다. 실행 방식만 바꾼 ablation에서도 token이 추가로 약 14% 줄고 성공률은 11%p 올랐습니다.

물론 어떤 저장소에서나 항상 더 낫다는 뜻은 아닙니다. DeepSWE도 system prompt와 평가 방식의 궁합이 격차 일부를 설명할 수 있다고 적었습니다. 그래도 디버깅 위주라면 “bash 하나 + 선형 히스토리”라는 단순한 구조가 꽤 강해 보입니다.

실제 업무에서 버그 수정이나 기능 개발에 써보신 분 계신가요? benchmark 밖에서는 환경 설정, 오래 걸리는 테스트, 권한, patch 품질 중 무엇이 먼저 문제가 됐나요?

• 직접 돌린 결과: https://turaai.net/benchmark
• mini-swe-agent: https://github.com/swe-agent/mini-swe-agent
• DeepSWE 설명: https://deepswe.datacurve.ai/blog/deepswe

공개: 저는 Tura를 유지보수하고 있고, 위 benchmark를 직접 실행했습니다.

LLM 턴은 줄이고, 한 턴의 명령은 늘리면 리서치 에이전트가 더 믿을 만해질까?

에이전트 작업에서 LLM 턴은 줄이고, 한 턴 안의 명령은 늘리는 방식을 시험해 봤습니다.

15장짜리 조사+제작 과제에서 직접 실행 방식은 평균 10턴·82회 도구 호출, CLI 방식은 13.5턴·10.5회 호출이었습니다. 한 턴에서 약 20개의 레시피/영상 검색을 동시에 돌렸고, 마지막에는 출처 10개, 중복 없는 영상 10개, 에셋 15개, 화면 폭 3개를 검증하면서 잘못된 주소 하나도 수정했습니다.

4회 사례라서 보편적인 속도 주장은 아닙니다. 핵심은 턴은 판단을 하고, 명령은 검색·테스트·검증 가능한 일을 하게 만드는 것입니다.

과제: https://turaai.net/benchmark-task?task=east-asian-squid-recipes-slides

결과: https://github.com/Tura-AI/benchmark/tree/main/results/design/east-asian-squid-recipes-slides/report-20260711-design-matrix

공개: 저는 Tura와 이 benchmark를 관리합니다.

토큰 절약 도구가 정말 효과가 있는지 반복해서 검증할 수 있는 프레임워크를 만들었습니다

안녕하세요, Yu입니다. 요즘 RTK나 Ponytail 같은 토큰 절약 도구의 테스트 결과가 많이 올라오는데, 작업과 로그 형식이 모두 달라 숫자를 직접 비교하기가 어렵더라고요.

그래서 제가 사용하던 벤치마크 프레임워크를 공개했습니다.

https://github.com/Tura-AI/benchmark/tree/main

실행을 관리하고 로그와 결과물을 공통 스키마로 저장합니다. 결과 폴더를 저장소에 올리면 CI가 자동으로 색인하고, 웹에서 비용·점수 비교 그래프와 실행 상세를 보여줍니다.

테스트했으면 하는 도구나 하네스가 있다면 알려 주세요. 로컬에서 재현한 결과를 Pull Request로 추가해도 됩니다. 이 방식에 어떤 편향이 있을지도 솔직한 의견을 듣고 싶습니다.

공개 사항: 저는 Tura와 이 벤치마크 프레임워크의 메인테이너입니다.

제 오픈소스 프로젝트는 왜 기대만큼 성장하지 못했을까요?

공개 사항: 저는 Tura의 메인테이너입니다. 이 글은 제 프로젝트에 대한 독립적인 리뷰가 아니라, 오픈소스 프로젝트를 알리는 방법과 평가 방식을 개선하기 위해 솔직한 조언을 구하는 글입니다.

2026년 초부터 RTK, Caveman, Ponytail 같은 프로젝트들이 토큰 사용량을 80~90% 줄일 수 있다고 주장해 왔습니다. 일부 프로젝트는 매우 짧은 기간에 GitHub 스타 수만 개를 얻기도 했습니다.

이전 스타트업에서는 전자상거래 챗봇을 만들었습니다. 실제로 그 제품은 나중에 공개된 Universal Commerce Protocol(UCP)과 거의 비슷했습니다. UCP가 공개된 뒤에는 그 방향을 계속 추구하지 않기로 결정했습니다.

올해 초, 전자상거래 챗봇 에이전트를 위해 만들었던 아키텍처를 SDK로 전환하기 시작했습니다. 핵심 아이디어를 간단히 설명하면, 상태 머신과 결정론적 실행 순서를 사용해 같은 작업에서 LLM 제공자와의 왕복 횟수를 약 80% 줄이고, 그 결과 토큰 소비를 크게 낮추는 것입니다.

저는 RTK 같은 도구가 실제 장기 실행 작업에서 왜 효과가 없는지 이해하고 있다고 생각합니다. 저는 7월 18일에 보고서를 공개했고, JetBrains는 7월 20일에 사실상 같은 결론의 보고서를 발표했습니다. RTK와 Caveman 같은 토큰 절약 플러그인은 현실의 장기 실행 작업에서 효과가 거의 없거나 전혀 없다는 결론입니다.

• JetBrains 보고서: https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/
• 제 보고서와 재현 가능한 방법: https://github.com/Tura-AI/tura/blob/main/docs/blog/token-saving-plugins-are-mostly-stupid-idea.md

저는 장기 실행 작업에서 실제로 80% 이상의 토큰을 줄이는 방법도 알고 있다고 생각합니다. 하지만 이 오픈소스 프로젝트를 만드는 일보다 가치를 설명하고 알리는 일이 훨씬 더 어렵다는 것을 경험하고 있습니다.

무엇이 잘못되었을까요?

많은 코딩 에이전트 사용자는 토큰 소비의 실제 원인을 중요하게 생각하지 않습니다

정규 소프트웨어 공학 교육을 받은 개발자와 독학한 “바이브 코더” 모두를 포함해, 코딩 에이전트 사용자 사이에는 이해 수준의 큰 격차가 있습니다.

작동 원리를 체계적으로 설명하고 기존 가정에 도전하는 긴 글은 AI가 작성한 게시물과 “토큰 95% 절감”을 주장하는 플러그인으로 가득한 커뮤니티에서 확산되기 어렵습니다.

단순한 아이디어가 더 쉽게 퍼집니다. 사람은 완전히 합리적이지 않으며, 이해하기 쉬운 설명을 믿는 경향이 있습니다. 잘못된 인과 설명에 기반한 유사과학 콘텐츠가 수학적 원리를 신중히 설명하는 콘텐츠보다 훨씬 더 많은 관심을 받는 이유도 비슷할 것입니다.

작성자의 오만함

아마 두 가지 문제가 결합되어 있다고 생각합니다.

과학적 테스트, 평가, 벤치마크를 중요하게 생각하는 입장에서는 평가가 없는 소프트웨어 공학 주장이 무의미하게 느껴질 수 있습니다.

하지만 제 오만함, 그리고 RTK 같은 도구에 대한 경멸이나 질투가 실제로 효과적인 방식으로 제 작업을 설명하고 홍보하려는 의지를 약하게 만들었을 수도 있습니다.

여기까지 읽으셨다면 솔직한 조언을 부탁드리고 싶습니다.

• 엄격한 평가와 벤치마크를 포기하지 않으면서 프로젝트를 더 효과적으로 알리려면 어떻게 해야 할까요?
• 잘 알려지지 않은 코딩 에이전트 SDK를 직접 사용해 보게 만드는 증거는 무엇일까요?
• 메시지가 지나치게 기술적이거나 공격적이거나, 잘못된 독자를 대상으로 하고 있을까요?
• 저장소 첫 화면이나 벤치마크 표현 방식에서 무엇을 바꿔야 할까요?

Codex나 Claude로 코딩 에이전트를 만드는 일 자체는 비교적 쉽습니다. 그래도 벤치마크와 평가 하네스의 가치를 이해하는 사람은 항상 존재할 것이라고 믿습니다.

프로젝트는 7월 16일 공개되었고 현재 GitHub 스타는 400개를 조금 넘었습니다.

https://github.com/Tura-AI/tura

사용하지 않을 이유를 포함해 비판적인 피드백도 환영합니다.