원문은 commoditech.pl에 게시되었습니다.
터미널 에이전트에게 저장소(repository)와 "이 테스트를 수정해라(fix this test)"라는 지침을 주면, 모델 호출 한 번으로 루프가 끝나지 않습니다. 매 단계마다 검색 결과, 파일 창, 그리고 일부 stdout 출력이 컨텍스트에 추가됩니다.
2,000 토큰의 프리픽스(instruction, AGENTS.md, task)와 단계당 1,000 토큰의 새로운 관찰(observation), 그리고 프리픽스 캐시가 없는 경우를 가정해 봅시다. 총 12단계는 90,000개의 입력 토큰을 사용합니다. 동일한 프리픽스와 하나의 관찰로 호출할 경우 3,000 토큰이 소모됩니다. 이는 30:1의 비율입니다. 마지막 세 단계에서 36,000 토큰(청구서의 40%)이 발생하며, 첫 세 단계는 9,000 토큰(10%)을 사용합니다.
종이에 직접 계산해 볼 수 있습니다. 이는 특정 출시 과정에서 나온 청구서는 아닙니다. 하지만 아무도 단계 제한을 설정하지 않았고 루프가 테스트가 녹색(green)이 될 때가 아니라 모델이 "done"이라고 말할 때 멈추는 경우의 청구서와 같습니다.
두 번째 위험은 토큰보다 더 중요합니다. 이슈, README 또는 도구 결과를 읽는 에이전트는 그곳에 제3자가 작성한 모든 내용에 따라 행동하며, 그 밑에는 셸(shell)이 있습니다. AgentDojo (Debenedetti et al., arXiv:2406.13352)는 97개의 작업과 629개의 보안 테스트 케이스를 가지고 있습니다. 모델은 공격을 받지 않았음에도 일부 작업을 실패하며, 도구 출력에 숨겨진 프롬프트 인젝션(prompt injection)은 일부 보안 속성을 깨뜨리고 다른 속성은 온전하게 유지시킵니다.
따라서 리더보드 점수는 세 가지를 결합합니다: 모델, 스캐폴드(scaffold), 그리고 테스트 세트의 청결도입니다. API 비용은 증가하는 컨텍스트의 합계입니다. 사용자가 제어할 수 있는 것은 테스트에 연결된 중지 조건과 에이전트가 호출할 수 있는 도구 목록뿐입니다. $PATH에 있는 바이너리의 이름은 이들 중 어느 것도 아닙니다.
1. 구조 분석: 호스트(host), 루프(loop), MCP
터미널 에이전트(terminal agent)는 채팅(chat)이 아니라 루프(loop)입니다. 호스트(host)가 히스토리(history)를 유지하고, 모델을 호출하며, 액션(action)을 실행한 후 관찰 결과(observation)를 추가합니다. Grok CLI가 이러한 호스트 중 하나입니다. xAI는 이를 Grok Build로 문서화했으며, 명령어는 grok(docs, product page)입니다. 해당 문서는 다음 내용을 설명합니다:
- 대화형 TUI(Text User Interface)와 헤드리스 모드(
grok -p "...");
- 수정 전 계획(plan) 및 서브에이전트(subagents);
- git worktree당 세션(
grok -w);
AGENTS.md, 스킬(skills), 훅(hooks), 플러그인(plugins) 및 MCP 서버(MCP servers);-m을 이용한 모델 선택과 grok models;- 현재 디렉터리에서 발견된 규칙, 스킬, 플러그인, 훅 및 MCP 서버를 보여주는
grok inspect (또는 grok inspect --json);
- 브라우저 로그인 방식의 인증, 원격 장치에서의
grok login --device-auth, 또는 XAI_API_KEY 환경 변수를 통한 인증.
공식 설치 방법은 curl … | bash 형태의 한 줄 명령어이며, npm 패키지인 @xai-official/grok도 존재합니다.
본 기사에서 가장 중요한 플래그는 CLI 레퍼런스에 있는 제어 플래그들입니다:
# 루프를 제한하고, 샌드박스 프로필을 선택하며, 도구를 제한하고, 권한 규칙을 설정합니다.
grok -p "make tests/test_parser.py::test_dates pass" \
--max-turns 8 \
...
--max-turns는 위 산술 계산에서 파생된 단계(step) 제한이며, 내장되어 있습니다. --sandbox, --tools / --disallowed-tools, 그리고 --allow / --deny가 '어떤 도구가 쓸 수 있는지'를 결정하는 곳입니다. 프로덕션에 접근할 수 있는 어떤 장치에서도 피해야 할 플래그는 --always-approve이며, 이는 별칭으로 --yolo입니다. (위의 플레이스홀더들은 의도된 것이므로, 실제 프로필 및 규칙 구문은 Sandbox 및 Permissions 페이지를 참조하세요.)
이 모든 것은 해결률(resolve rate)을 의미하지 않습니다. 2026년 10월 기준으로 xAI의 공개 문서는 grok 바이너리에 SWE-bench 점수를 첨부하고 있지 않습니다. 만약 누군가 측정한다면, 그것은 특정 모델, 단계 제한 및 하네스(harness)에 속하는 것입니다.
Model Context Protocol
MCP는 호스트(host)를 그 도구들로부터 분리합니다. specification (개정판 2025-11-25)은 JSON-RPC 2.0을 기반으로 구축되었습니다. 호스트(Grok CLI 또는 다른 클라이언트)가 클라이언트 측을 담당합니다. 서버는 도구(모델이 호출할 수 있는 함수), 리소스(읽을 데이터), 그리고 프롬프트(템플릿)를 노출합니다. 라이프사이클은 다음과 같습니다: initialize에서 기능을 협상하고, tools/list가 스키마를 반환하며, tools/call이 하나의 도구를 실행합니다. 클라이언트 측에서는 이 사양(spec)이 샘플링(서버가 호스트에게 모델 호출을 요청하는 것)과 루트(서버가 볼 수 있는 디렉토리)도 정의합니다.
로컬 전송 방식(local transport)은 stdio입니다. 이는 포트가 없는 동일 기계의 프로세스를 의미합니다. 원격 전송 방식(remote transport)은 2025-03-26 개정판에서 도입되었고 2025-11-25에도 유지되고 있는 Streamable HTTP이며, 이전의 HTTP+SSE 설정은 더 이상 주요 원격 옵션이 아닙니다. 하나의 MCP 서버가 여러 호스트에 서비스를 제공할 수 있지만, 어떤 도구가 쓰기 권한을 가질지는 결정하지 못합니다. Grok CLI에서는 grok mcp list|add|remove|doctor 명령어로 서버를 관리합니다.
{
"jsonrpc": "2.0",
"id": 2,
...
}
메시지 형태는 MCP 도구 사양(tools spec)에서 가져옵니다. get_issue는 내장된 Grok CLI 도구가 아닌 가상의 읽기 전용 도구입니다.
step = 0
context = [system, AGENTS_md, task]
while step < LIMIT and not target_test_green():...
모델이 동일하게 유지되더라도 인터페이스는 중요합니다. SWE-agent (Yang et al., arXiv:2405.15793, NeurIPS 2024)가 GPT-4 Turbo를 사용하여 SWE-bench Lite에서 테스트한 결과는 다음과 같습니다:
- 일반 셸(plain shell)로 제한된 에이전트는 작업의 **11.00%**를 해결했지만, SWE-agent는 18.00% (300개 중 54개)를 해결했습니다.
- 파일 뷰어 제거 실험(file-viewer ablation)에서는 100줄 창이 18.0%의 점수를 기록했고 전체 파일을 붙여넣기 한 경우는 12.7%였습니다.
- 에디터 제거 실험(editor ablation)에서는 셸 전용 편집이 10.3%로 떨어졌으며, 구문 검사(syntax lint)를 실행하는 편집은 18.0%를 기록했습니다.
전체 파일에 대해 cat을 실행하면 모델이 패치에서 전혀 사용하지 않는 텍스트가 컨텍스트를 범람시킵니다.
전체 SWE-bench에서 동일한 설정은 논문 가격 기준으로 인스턴스당 평균 $1.59로 12.47%(2,294개 중 286개)를 해결했습니다. 논문의 초록에 언급된 87.7%는 짧은 함수 수정 세트인 HumanEvalFix이며, 2,294개의 GitHub 이슈가 아닙니다.
2. 재계산할 수 있는 숫자와 가져오지 말아야 할 숫자
SWE-bench (Jimenez et al., arXiv:2310.06770, ICLR 2024)는 12개의 Python 저장소에서 가져온 2,294개의 문제를 가지고 있습니다. 해당 논문에서 가장 좋은 성능을 보인 모델인 Claude 2는 도구 루프(tool loop) 없이 1.96%를 해결했습니다. 1.96%와 12.47%를 나란히 놓으면 모델, 연도, 스캐폴드(scaffold)가 혼동됩니다. 모델을 고정하고 인터페이스만 변경한 제거 연구(ablation) 결과는 Lite에서 18.00% 대비 11.00%로, 300개 작업 중 7점 차이입니다. 이는 원시 bash를 모델의 중립적인 API로 취급하는 것을 멈추기에 충분합니다. 또한, 제안서에 “에이전트가 이슈를 해결한다”고 쓰는 것만으로는 충분하지 않습니다.
SWE-bench Verified (OpenAI, 2024년 8월 13일): 주석 작성자들은 1,699개의 작업을 검토했으며 그중 500개가 유지되었습니다. 이 중 196개는 “쉬움”(15분 미만)이고 45개는 “어려움”(한 시간 초과)입니다. GPT-4o는 33.2%를 해결했습니다. 주석 분석 결과, 샘플의 38.3%는 문제 설명이 불충분했고(underspecified problem statement), 61.1%는 유효한 솔루션을 실패시킬 수 있는 테스트 케이스를 가지고 있었으며, 전체적으로 68.3%가 필터링되었습니다.
Verified retired (OpenAI, 2026년 2월 23일): 최전선은 6개월 만에 74.9%에서 80.9%로 이동했습니다. OpenAI는 모델들이 자주 실패하는 작업에 초점을 맞춰 세트의 27.6%를 감사(audited)했습니다. 감사를 거친 문제 중 최소 59.4%에서 그들은 테스트 설계 및/또는 문제 설명에 물질적인 결함이 있음을 발견했습니다. 정답 패치를 거부하는 테스트가 가장 큰 그룹이지만, 유일한 경우는 아닙니다. 오염(Contamination)은 별개의 문제입니다. OpenAI는 Verified 보고를 중단하고 SWE-bench Pro를 지적했습니다.
Pro questioned too (OpenAI, 2026년 7월 8일): SWE-bench Pro의 공개 분할(public split) (총 731개 작업)에서 프론티어 패스율(frontier pass rate)이 8개월 만에 23.3%에서 80.3%로 상승했습니다. 자동화된 검증은 200개 작업(27.4%)을 오류로 플래그 지정했으며, 인간 캠페인은 249개(34.1%)를 플래그 지정했습니다. 같은 게시물에서 OpenAI는 Pro의 약 30%가 오류라고 추정하며, 이전에 Pro 사용으로 전환하라는 조언을 철회했습니다. 점프와 오류 작업률을 함께 읽어보십시오.
공급업체(Vendor) 테이블. GPT-5.2 발표에서 GPT-5.2는 Verified에서 80.0%의 점수를 기록했고 Pro 공개 버전에서는 55.6%를 기록했습니다. 동일 모델에 대한 두 세트 간의 24.4% 차이는 2024년 전체 shell 대 ACI 제거 실험(ablation)보다 큰 수치입니다. GPT-5.4 발표는 Pro 공개 버전에서 57.7%, Terminal-Bench 2.0에서 75.1%를 보고했습니다. 이는 '프로그래밍 가능성'에 대한 세 가지 정의와 세 퍼센트 포인트의 차이입니다. 이 수치들은 독립적인 측정이 아닌 공급업체(vendor)가 제시한 수치입니다.
개발자 생산성. METR의 무작위 대조 시험(randomized trial) (Becker et al., arXiv:2507.09089)은 2025년 2월부터 6월까지 숙련된 오픈소스 개발자 16명을 대상으로 246개 작업을 추적했습니다:
- AI 도구 사용이 허용되자, 작업 소요 시간이 19% 더 오래 걸렸습니다 (CI +2%에서 +39%).
- 연구 이전, 같은 개발자들은 24%의 속도 향상을 예상했습니다. 하지만 이후에도 그들은 여전히 20% 더 빨랐다고 믿었습니다.
- 경제학자들은 39%의 속도 향상을 예측했고 ML 연구원들은 38%를 예측했습니다.
2026년 2월 업데이트에서 METR은 최신 도구를 사용한 후속 조사가 어느 쪽에서도 신뢰할 만한 신호를 제공하지 않았다고 밝혔습니다. +19%는 2025년 초를 설명하는 것이지, 2026년 4분기를 설명하는 것이 아닙니다.
핵심은 인터페이스가 가중치(weights)가 고정되어 있어도 점수를 이동시킨다는 것입니다. 팀의 인식은 스톱워치와는 반대 방향의 부호를 가질 수 있습니다. 그리고 아무런 지지 기반(scaffold)이나 테스트 감사(test audit)가 첨부되지 않은 Verified 또는 Pro 퍼센티지는 여러분의 스프린트(sprint)를 예측하지 못합니다.
3. 사례: 테스트가 "오류"라고 말하기 전 90,000 토큰
이 가정들은 명확하게 제시되어 있으므로 사용자가 자체적인 토큰 카운터로 교체할 수 있습니다:
- 접두사(Prefix) P = 2,000 토큰. 각 단계마다 D = 1,000 토큰이 추가됩니다. 접두사 캐시가 없는 경우, k단계에서의 입력은 P + (k−1)·D입니다.
- N = 12: 12·2,000 + 1,000·(12·11/2) = 24,000 + 66,000 = 90,000 입력 토큰. 단일 호출 비용은 3,000이므로 비율은 30입니다.
- 1단계부터 3단계까지는 9,000 토큰(10%)이 소요되며, 10단계부터 12단계까지는 36,000 토큰(40%)이 소요됩니다.
- N = 8로 제한할 경우 (
--max-turns 8): 16,000 + 28,000 = 44,000으로, 이는 51% 적습니다. 이 수치는 측정된 대시보드의 p99 값에서 나온 것이 아니라 더 짧은 루프(loop) 덕분입니다.
- 벤더 접두사 캐시(vendor prefix cache)는 컨텍스트의 공유되는 시작 부분을 할인해 줍니다. 이는 잘못된 단계를 제거하지 않으며, 중지 조건(stop condition)을 테스트로 바꾸지도 않습니다.
여전히 검사를 유지하는 절단 방식은 다음과 같습니다:
- 단계 제한(step cap), 그리고 목표 테스트가 통과할 때만 중지하는 경우;
- 약 100줄 분량의 파일 보기(file views);
- MCP가 이슈와 CI 상태 읽기로 제한되는 경우;
- 네트워크 및 비밀 파일이 없는 셸 환경;
- 에이전트당 하나의 git worktree;
- 인간이 병합(merge)을 수행하는 경우.
만약 테스트가 여전히 8단계에서 실패하면 루프는 중지됩니다. 패치(patch)를 얻지는 못하지만, 제한된 청구서와 검토할 diff를 받을 수 있습니다.
METR의 결과는 팀들이 여전히 "더 빠르다고 느낀다"고 말하는 이유를 설명합니다. 따라서 관문은 세션 후 설문조사가 아닙니다. 에이전트가 시작하기 전에 알고 있는 테스트에, 그리고 세션에 대한 토큰 카운터가 추가되는 것입니다.
4. 의사결정표 (Decision table)
| 패턴 | 복잡도 (Complexity) | 지연 시간 (Latency) | 비용 (Cost) | 사용 시점 (When to use it) |
|---|
| 에디터 내 제안, 인간이 diff를 수락하는 경우 | 낮음 (Low) | 에이전트 루프 후 지연 없음 (No agent-loop tail) | 단일 호출 정도 (About one call) | 사람이 전체 내용을 읽을 수 있는 로컬 편집의 diff |
| ... | | | | |
5. 호스트 튜토리얼에서 언급하지 않은 안티 패턴(Anti-patterns)
- 계약서에 작성된 리더보드 백분율. Verified는 2026년 2월에 폐지되었으며, 2026년 7월까지 공개 Pro의 약 3분의 1이 작동하지 않는 것으로 표시되었습니다. 계약은 귀하의 티켓과 테스트를 기준으로 평가되어야 합니다.
- 전체 파일에
cat을 실행하는 셸 전용 에이전트. SWE-agent 논문에서 11.00%와 12.7%를 기록했지만, 100줄 창(window)에서는 18.0%였습니다. 관찰 내용을 짧게 유지하거나, D가 1,000으로 유지되지 않도록 하십시오.
- 모델이 "done"이라고 말할 때 중지하는 것. N=12일 때, 단계 10~12가 입력 토큰의 40%를 차지합니다. 테스트가 없는 루프는 가장 비싼 3분의 1을 재시도에 사용합니다.
- MCP 도구와 네트워크 셸을 하나의 지원(grant) 아래 작성하고, 검토 없이 레포지토리(repo)에 커밋된 MCP 서버. 디렉터리가 무엇을 로드하는지 볼 수 있도록
grok inspect가 존재합니다. README와 이슈 본문은 주입 채널입니다. 그리고 프로덕션(production)에 접근할 수 있는 노트북에서 curl | bash 설치 프로그램을 실행하는 것은 공식 설치일지라도 온보딩 단계가 아니라 정책 결정 사항입니다.
FAQ
SWE-bench Verified에서 80%라는 것은 에이전트가 시니어 엔지니어의 티켓 중 80%를 해결한다는 의미인가요?
아닙니다. 점수는 모델, 스캐폴드(scaffold), 그리고 벤치마크의 청결도에 따라 달라지며, Verified와 Pro 모두 이를 홍보한 공급업체로부터 공개적으로 의문 제기를 받았습니다. 귀하의 스프린트는 자체 테스트로 측정됩니다.