AIDive인트로: 같은 검사, 두 배 미터, 다섯 가지 상한
ultracode는 Claude Code에 입력하는 요청 하나를 에이전트 팀 전체로 바꿔 주는 키워드이자 토글입니다. 같은 사양으로 진행한 페어 테스트에서 두 실행은 같은 숨겨진 검사를 통과했지만, ultracode 실행은 세션 미터를 두 배 넘게 썼습니다. 이유는 더 똑똑한 모델이 아닙니다. 하네스가 주입하는 문장 하나와 꺼지는 안전장치 세 개 때문입니다.
이 글에서 다루는 내용은 네 가지입니다.
- 플랜 미터로 읽은 페어 테스트
- 더 많은 쌍에서 본 토큰 배수
- 팀이 심어 둔 버그 70개 중 66개를 찾은 반면 단일 에이전트는 14개를 찾은 작업 유형
- 한 주치 사용량을 다 먹기 전에 실행을 막는 다섯 가지 설정, 그중 하나는 사용 한도에서 실행 자체를 멈추는 설정
ultracode가 켜는 것: 키워드, 토글, 에이전트 워크플로
ultracode는 스위치가 두 개입니다. 프롬프트 안에 ultracode를 입력하면 세션의 effort 수준은 건드리지 않고 그 작업 하나만 워크플로로 실행합니다. /effort 명령으로 토글을 켜면 Claude가 의미 있는 모든 작업마다 워크플로를 계획하므로, 요청 하나가 워크플로 여러 개로 이어질 수 있습니다.
워크플로는 Claude가 스스로 작성하는 스크립트이고, 이 스크립트가 에이전트 팀을 단계별로 실행합니다. 약간의 허술한 프라미스 처리가 있는 파일 두어 개짜리 작은 샌드박스에서 읽기 전용 리뷰를 요청하자, Claude는 파일을 훑어본 뒤 "unhandled promise audit"라는 이름의 워크플로를 펼쳤고, 프롬프트 입력창 아래에 진행 막대, 에이전트 수, 경과 시간, 계속 올라가는 토큰 합계가 있는 작업 행이 나타났습니다. /workflows 명령은 에이전트마다 한 줄씩, 각자의 토큰 수와 함께 보여 주고, 일시 정지, 중지, 재시작 키도 제공합니다.
그 실행에서 검증 에이전트가 시작되기도 전에 파인더 하나하나가 이미 약 45,000 토큰을 읽었습니다. 코드는 몇 줄뿐이었는데도 그렇습니다.
모든 세션에는 규모 가이드라인도 있습니다. Claude가 넘지 않도록 권고받는 에이전트 수입니다.
| 규모 가이드라인 | 권고 에이전트 수 |
|---|---|
| small (Pro 기본값) | 5개 미만 |
| medium | 10개 미만 |
에이전트는 저마다 대화 위에 자기 요청을 따로 보냅니다. 워크플로는 청구서 한 장이 아니라 에이전트마다 한 장이고, 미터는 그 전부를 셉니다.
페어 테스트: 같은 136개 검사, 8퍼센트 대 18, 그리고 멈추지 않음
한 개발자가 최상위 구독 플랜에서 깔끔한 환경으로 비용을 측정했습니다. 작은 스프레드시트 앱의 같은 사양, 같은 effort의 같은 모델로 일반 실행 한 번과 ultracode 실행 한 번을 돌렸습니다. 두 실행 모두 모델이 볼 수 없는 테스트인 숨겨진 검사로 채점했고, 둘 다 136개를 모두 통과했습니다.
| 실행 | 종료 | 사용한 세션 한도 | 통과한 검사 |
|---|---|---|---|
| 일반 | 스스로 종료, 25분 | 8 % | 136 / 136 |
| Ultracode | 76분에 시계 때문에 중단, 아직 검사 중 | 18 % | 136 / 136 |
ultracode 실행 안에서 Claude는 팀을 돌리는 것만이 목적인 스크립트를 작성했습니다. 집계된 에이전트는 12개로, 테스터, 심판 몇 명, 그리고 나중에는 페이지를 부수는 것이 임무인 "브레이커"들이었습니다. 브레이커 하나는 수식 입력줄에서 실제 버그를 찾았습니다. 다른 셀을 클릭한 뒤에도 이전 텍스트가 계속 표시되는 버그였습니다.
분당으로 보면 ultracode 실행은 일반 실행과 비슷한 속도로 한도를 썼고, 평균적으로는 조금 더 느렸습니다. 더 빨리 타지도 않았고, 멈추지도 않았습니다. ultracode는 Claude를 더 똑똑하게 만들지 않고 더 많이 검사하게 만들며, 그 검사 하나하나에 비용을 냅니다. 작은 사양에서의 한 쌍이고 두 번째 실행은 시계로 중단됐지만, 모양은 분명합니다. 같은 답에 세션 창을 두 배 넘게 썼고, 늘어난 시간은 전부 검사였습니다.
비용이 드는 이유: 문장 하나와 꺼진 안전장치 셋
모델은 같습니다. 바뀌는 것은 하네스가 모델에 건네는 텍스트입니다. 하네스란 Claude Code 자체, 그 도구들, 그리고 모델을 둘러싼 지시문입니다.
ultracode가 켜져 있으면 Claude Code는 워크플로를 작성하기 전에 참조 문서를 불러옵니다. 이 텍스트는 의미 있는 모든 작업에 기본적으로 워크플로를 실행하라고 모델에 지시하고, 청구서를 설명하는 문장을 담고 있습니다. "The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint." 이것은 하네스 자체의 텍스트이며, 공개된 GitHub 이슈도 같은 문장을 인용합니다.
같은 순간에 안전장치 세 개가 꺼집니다.
- 실행이 너무 많은 에이전트를 예약하면 보통 뜨는 대형 워크플로 경고가 나타나지 않습니다.
- 동시에 실행할 수 있는 에이전트 수에 대한 세션 제한이 Claude가 생성한 에이전트에는 적용되지 않습니다.
- 자동 모드에서는 첫 실행이 승인 요청에 올라가지 않습니다.
규모 가이드라인은 조언일 뿐 상한이 아닙니다. 샌드박스에서 small(5개 미만)로 설정했는데도 ultracode 실행은 9개를 띄웠습니다. 공정하게 말하면, 이 문장은 모델이 여전히 가늠해 볼 수 있는 기본값이고, 아주 큰 작업을 위해 안전장치를 일부러 뺀 것입니다. 답은 한 줄로 정리됩니다. ultracode는 모델을 바꾸지 않고, 지시문을 "모든 것에 팀을 쓰고, 비용은 제약이 아니다"로 바꿉니다.
배수: 세 쌍, effort 사다리, 30배 페어
두 번째 개발자는 Pro 플랜에서 단일 에이전트와 워크플로를 비교하는 쌍을 여러 번 돌렸습니다. 리뷰 방식의 스크립트였고, 매번 전후로 사용량 미터를 읽었습니다.
| 측정 항목 | 단일 에이전트 | 워크플로 |
|---|---|---|
| 리뷰 스크립트 하나의 토큰 | 약 115,000 | 972,000 |
| 여러 쌍에 걸친 토큰 배수 | 1x | 최대 18x, 결과는 거의 같음 |
| 미터 변화 | 1x | 최대 3x |
| 소요 시간 | 거의 같음 | 거의 같음 |
워크플로가 더 빨리 끝나지는 않았습니다. 기다리는 시간은 같은데 더 많이 썼습니다. 병렬이 값을 한 곳은 독립적인 리서치 작업 묶음 하나였고, 거기서는 에이전트들이 더 빨리 끝났지만 토큰은 두 배 넘게 들었습니다.
세 번째 테스트는 API 가격으로 모든 effort 수준에서 작은 앱 몇 개를 만들었습니다. 사다리를 한 단계 오를 때마다 청구액이 대략 두 배가 되었고, ultracode는 max의 몇 배 비용에 이르렀으면서도 한 번도 1등이 되지 못했습니다. 그 토큰의 대부분은 저렴한 캐시 읽기였고, 아주 작은 비중의 출력 토큰이 비용의 거의 절반을 차지했습니다.
또 한 쌍은 도시 장면입니다. 단일 에이전트는 API 가격으로 몇 달러에 약 한 시간이 걸렸습니다. ultracode 실행은 거의 하루를 쓰고 서브에이전트가 수십 개였으며, 비용은 약 30배였습니다.
이것들은 정수 단위의 미터 값, API 가격의 신규 앱, 도시 장면 하나이므로 하나만으로는 성적표가 아닙니다. 하지만 함께 보면 패턴은 매번 같습니다. 작업이 독립적인 조각으로 나뉘지 않는 한, 팬아웃이 사 주는 것은 더 나은 답이 아니라 검사와 범위입니다.
팬아웃이 값을 하는 곳: 심판이 되는 테스트 스위트와 한 줄 규칙
실제로 이런 모양인 작업도 있습니다. 마이그레이션, 감사, 코드베이스 전체 정리 같은 것들입니다.
Bun은 Claude Code의 동적 워크플로 약 50개를 11일 동안 계속 돌려 Zig에서 Rust로 다시 쓰였습니다. 50만 줄이 넘는 Zig 코드이고, 시작부터 전체 테스트 스위트가 모든 플랫폼에서 통과하기까지 그 기간 안에 끝났습니다. 이를 가능하게 한 것은 에이전트 수가 아니라 심판이었습니다. 누구의 의견도 없이 통과인지 실패인지 말해 주는 방대한 기존 테스트 스위트였습니다.
Anthropic의 버그 사냥도 같은 점을 보여 줍니다. 큰 코드베이스에 버그 70개를 심고 단일 에이전트를 여러 번 돌렸습니다.
| 에이전트 | 70개 중 찾은 버그 |
|---|---|
| 단일 에이전트 (3회 실행) | 14, 15, 27 |
| 워크플로 (3회 실행) | 매번 66 |
한 가지 단서가 있습니다. 이 테스트는 Claude Code가 아니라 API 제품인 Claude Managed Agents에서 진행됐고, 비용은 공개되지 않았습니다.
출시 스레드에는 보고된 다른 성공 사례들이 더 있는데, 모두 비슷해 보입니다. 규칙 파일에 대한 리뷰, 코드베이스 전체 번역, 스캔된 페이지 더미 정리입니다. 출시 블로그는 분명히 말합니다. 전통적인 코딩 작업 대부분에는 리뷰어 다섯 명으로 이루어진 패널이 필요하지 않다고요.
규칙은 이렇습니다. 테스트 스위트나 규칙 세트가 출력을 판정하고 작업이 독립적인 조각으로 나뉠 때만 팬아웃하세요. 나머지는 모두 high로 일반 실행합니다. 페어 테스트를 진행한 개발자도 자신의 말로 같은 얘기를 했습니다. 수백 개 파일에 걸친 마이그레이션처럼, 검사가 곧 일인 작업을 위해 아껴 두라는 것입니다.
실행을 막는 다섯 가지 설정
상한은 모두 이미 아는 곳에 있습니다.
| # | 설정 | 위치 | 효과 |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config의 Dynamic workflow size 항목 또는 settings.json |
조언일 뿐이며(5개 미만), 대형 워크플로 경고 임계값도 낮춥니다 |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
환경 변수, 실행 전에 export | 기본값은 동시에 최대 16개이며, 4로 설정하면 나머지는 대기열에 들어가 실행을 죽이지 않고 소모 속도를 늦춥니다 |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
환경 변수 | 다른 서브에이전트는 자기 모델을 유지한 채, 모든 워크플로 에이전트를 고른 모델 하나로 실행합니다. 더 저렴한 모델이면 검사가 저렴해집니다 |
| 4 | ultracode 키워드, 토글은 절대 안 됨 |
프롬프트 안, settings의 ultracode 키는 절대 안 됨 |
키워드는 작업 하나를 워크플로로 실행하고 멈추며, 토글은 끌 때까지 상시 적용됩니다 |
| 5 | autoContinueAtUsageLimit |
settings | 켜면 한도에 닿은 실행이 멈추고 리셋을 기다렸다가 계속하며, 여러 번 반복됩니다. 끄면 에이전트가 한도에서 실패하고 실행이 거기서 끝납니다 |
여기에 습관 세 가지가 따라옵니다. 출시 블로그에 따르면 프롬프트에 "use 10k tokens" 같은 예산을 적으면 그것이 상한이 됩니다. 실행이 끝난 뒤에는 /usage가 최근 사용량 중 서브에이전트와 워크플로에 간 비중을 보여 주고, 그 비중이 지배적이면 경고합니다. 실행 중에 이상해 보이면 /workflows 창에서 x 키로 멈출 수 있고, 이미 끝난 작업은 대개 남습니다.
이 중 어느 것도 에이전트 하나를 더 싸게 만들지는 않습니다. 한 번의 실행이 쓸 수 있는 에이전트 수와, 계속 쓸 수 있는 시간에 상한을 둘 뿐입니다.
폭주한 실행, 한도, 그리고 결론
공개된 보고 하나가 한 주가 어떻게 사라지는지 보여 줍니다. 최상위 플랜에서 모델이 작성한 스크립트가 한 시간도 안 되어 에이전트 221개를 시작했습니다. 첫 세션 한도 오류 뒤에도 스크립트는 계속 에이전트를 보냈고, 이후 몇 분 동안 189개가 더 시작됐습니다. 제보자 본인의 표는 한도에 닿기 전 단계들에서 수천만 토큰을 집계합니다.
| 단계 | 토큰, 캐시 포함 |
|---|---|
| Ground | 11,063,801 |
| Find | 35,885,272 |
| Merge | 516,226 |
| 합계 | 47,465,299 |
원인은 생성된 스크립트의 한 줄이었습니다. 에이전트가 아무것도 반환하지 않으면 원본 목록을 쓰고 계속 진행하라는 폴백이었습니다. 병합은 실패했는데 실행은 계속 이어졌습니다. 그 버전은 사용 한도에서 멈추는 기능이 나오기 전의 것이며, 제보자는 그 토큰이 실패한 에이전트에서 나온 것이 아니라고 말합니다. 동시 실행 상한이 있었다면 그 실행을 성기게 만들었을 것이고, auto-continue를 꺼 두었다면 한도에서 끝났을 것입니다.
결론은 이렇습니다. 같은 작업에서 같은 검사를 통과했는데, ultracode는 일반 실행보다 미터를 두 배 넘게 썼습니다. 더 똑똑해서가 아니라 주입된 문장과 그것이 끄는 안전장치 때문입니다. 테스트 스위트나 규칙 세트가 출력을 판정하고 조각들이 서로 기다리지 않을 때 값을 합니다. 그 밖의 경우에는 입력하는 순간 검사 비용을 내게 됩니다. 다섯 가지 설정이 한 번의 실행이 쓸 수 있는 양을 막습니다. 규모 가이드라인, 동시 실행 상한, 워크플로 모델, 토글 대신 키워드, 그리고 한도에서의 정지입니다.
