3줄 요약
- 품질 감사 목적으로 서브에이전트 2기를 동시에 띄워 계량했더니 감사 A는 156,772토큰·도구호출 22회·288초, 감사 B는 124,621토큰·도구호출 11회·182초였다(2026-08-16 실측).
- 합계 281,393토큰을 썼지만 부모 대화에 남은 것은 결과 요약 2건뿐이다. 서브에이전트는 부모 대화를 물려받지 않는다.
- 차이의 원인은 모델도 분량도 아니라 입력이었다. A는 URL만 받아 캐시 오류로 3편을 재수집했고, B는 URL과 제목을 쌍으로 받아 한 번에 맞춰 도구호출이 절반이었다.

이 글대로 하면 무엇이 달라지는가: 위임할지 말지를 감으로 정하는 대신, 도구호출 수를 예산으로 잡고 하네스에 파일을 못 박아 같은 작업을 절반 비용으로 끝낼 수 있게 된다.

서브에이전트 1기를 띄우면 실제로 토큰이 얼마나 드는가?

같은 목적(발행글 품질 감사)으로 서브에이전트 2기를 동시에 띄우고 각각의 토큰·도구호출·소요시간을 계량한 결과, 1기당 124,621토큰과 156,772토큰이 들었다(2026-08-16). 두 기 합계는 281,393토큰이다.

같은 모델, 같은 평가축, 같은 편수인데 비용이 26% 갈렸다. 이 26%가 어디서 나왔는지가 이 글의 본론이다.

감사 A와 B의 비용 차이는 어디서 났는가?

입력에 검증 가능한 정보가 하나 더 있었느냐 없었느냐에서 갈렸다. 감사 A에는 검사 대상 글의 URL만 넘겼다. 그런데 CDN 캐시 오류로 그중 3편이 엉뚱한 글로 매칭됐고, 에이전트는 제목과 canonical을 대조해 이를 알아챈 뒤 다시 수집해야 했다. 이 재수집이 도구호출을 22회까지 끌어올린 주된 원인이다.

감사 B에는 URL과 제목을 쌍으로 넘겼다. 캐시가 엉뚱한 글을 돌려줘도 제목이 일치하지 않으면 그 자리에서 알아챌 수 있었고, 재수집 없이 11회로 끝났다. 입력에 검증 가능한 정보 하나를 더 얹은 것만으로 도구호출이 절반이 됐다. 그래서 이후 감사 하네스에는 "글 목록은 URL과 제목 쌍으로 제공"을 고정 조항으로 넣었다.

다른 작업의 실측 단가는 어땠는가?

작업 종류보다 스코프를 못 박았는지가 토큰을 더 크게 갈랐다. 운영 기록에 남은 실측치를 나란히 놓으면 규칙이 보인다.

이 표에서 읽히는 것은 두 가지다. 첫째, 읽을 파일을 절대경로로 못 박고 탐색 도구 사용을 금지하면 탐색 호출이 0에 수렴한다. 도구 호출 9회로 끝난 사례가 그렇게 나왔다. 둘째, 스코프를 못 박을 수 없는 작업(웹 리서치)은 호출 편차가 커진다. 같은 날 병렬로 돌린 두 기가 45회와 6회로 갈렸고, 45회 쪽은 공식 문서가 차단돼 우회 검색을 반복한 탓이었다.

일반 단가로는 Sonnet 계열 에이전트 1기당 150k~220k 토큰을 잡아 왔고, 스코프가 무제한이면 탐색 도구 호출이 48~68회까지 늘었다. 위 표의 9~22회는 그 대비로 읽어야 한다.

도구 호출 수를 줄이는 하네스는 어떻게 쓰는가?

읽을 파일을 명시하고, 탐색을 금지하고, 반환 형식을 고정한다. 아래는 위 실측에서 실제로 도구 호출을 줄인 조항들을 골격으로 정리한 것이다.

# 읽을 파일 (이 목록 밖은 읽지 마라)
- <절대경로 1>
- <절대경로 2>
...
탐색 도구로 저장소를 훑지 마라. 위 목록이 전부다.

# 대상 목록 (검증 가능한 쌍으로 준다)
| URL | 제목 |
|---|---|
| ... | ... |
받은 내용과 제목이 일치하지 않으면 잘못 받은 것이다. 그 사실을 보고에 적어라.

# 완료 기준 (기계로 검사 가능한 형태로)
- 항목 N개 전부에 판정과 근거 인용 1개가 있다
- 확신도(높음/중간/낮음)를 각 발견에 붙였다
- 근거 없는 수치를 만들지 않았다. 확실하지 않으면 비우고 보고에 적어라

# 반환 (본문을 붙여넣지 마라)
- 결론만 반환한다. 항목별 한 줄 + 마지막에 미확인 항목

마지막 조항이 비용에 직접 걸린다. 에이전트 내부 토큰은 부모 컨텍스트에 쌓이지 않지만 반환 보고서는 부모 대화에 영구히 남는다(건당 약 3.8k 실측). 그래서 "결론만 반환"은 예의가 아니라 예산이다.

완료 기준을 기계로 검사할 수 있게 쓰면 품질도 같이 올라간다. 실제로 다른 배치에서 완료 기준에 grep으로 특정 패턴이 0행인지 세는 검사와 curl로 HTTP 200을 확인하는 검사를 넣었더니, 에이전트가 스스로 규격 이탈과 컴파일 실패를 잡아서 보고했다. 반대로 사람이 읽어야만 판정되는 완료 기준은 재작업을 부른다.

인라인으로 할 일과 위임할 일은 어떻게 가르는가?

작업 자체의 인라인 비용이 에이전트 1기 단가에 비해 무시할 만큼 작으면 위임하지 않는다. 판별은 세 줄이면 끝난다.

마지막 줄이 "작은 일은 인라인" 규칙의 상위 예외다. 에이전트는 토큰을 아끼는 장치이기도 하지만 사용자의 wall-clock을 병렬화하는 장치이기도 하다. 자체완결이고 소유 파일 경계가 명확하면, 대규모가 아니어도 백그라운드 1기 위임이 인라인으로 사용자를 붙잡아 두는 것보다 낫다. 이때도 파일 못 박기와 계약 명시는 그대로 간다.

위임을 정했다면 아래를 순서대로 확인한다.

• [ ] 읽을 파일을 절대경로로 나열했고, 목록 밖 탐색을 금지했다
• [ ] 대상 목록에 검증 가능한 정보를 쌍으로 넣었다(URL과 제목처럼)
• [ ] 완료 기준을 기계로 검사할 수 있는 형태로 썼다
• [ ] "결론만 반환"을 명시했다
• [ ] 동시 기수가 5기 이내다(그 이상이면 사용자에게 재확인)
• [ ] 순수 검색이면 발췌만 읽는 검색 전용 에이전트를 골랐다
• [ ] 여러 기가 같은 공용 파일을 각자 읽게 되지 않는다(겹치면 1기로 통합)
• [ ] 반복적이고 결정적인 작업이면 에이전트가 아니라 스크립트로 뺐다

마지막 항목은 실제 낭비 사례에서 나왔다. 한 배치에서 어떤 기가 도구를 35회 썼는데, 그중 상당수가 정규화 로직을 임시 스크립트로 반복 작성한 것이었다. 그런 결정적 처리는 메인이 스크립트로 만들어 넘기는 편이 싸다.

"서브에이전트는 비싸다"는 결론은 왜 틀렸는가?

원문이 "권고 + 경고" 한 쌍으로 쓰여 있었는데 요약 과정에서 경고만 살아남았기 때문이다. 이 오진은 우리 지침 파일에서 실제로 벌어졌고, 다른 세션이 발견해 복원했다(2026-08-09).

오진 1단계. 요약본에는 "에이전트 보고서는 부모 컨텍스트에 영구히 남는다"는 경고만 남았다. 그래서 지침을 읽는 쪽은 "위임은 비용이니 되도록 인라인"으로 이해하게 됐다. 왜 틀렸나. 원문의 앞 절반이 정반대였다. "에이전트는 부모 대화를 물려받지 않으므로 큰 조사와 대량 판독은 위임이 정답이다"가 권고였고, 보고서 잔류는 그 권고에 붙는 단서였다. 경고만 남은 요약은 결론을 뒤집는다. 진짜 원인. 압축이나 요약에서 살아남는 쪽은 언제나 짧은 쪽, 곧 금지와 경고다. 그래서 쌍으로 쓴 규칙은 쌍으로 요약해야 하고, 요약할 때 먼저 확인할 것은 긴 쪽(권고)이 남았는지다.

숫자로 보면 왜 권고가 먼저인지 분명하다. 감사 2기가 쓴 281,393토큰 중 부모 대화에 실제로 들어온 것은 결과 요약 2건이다. 같은 분량의 원문을 메인이 직접 읽었다면 그 전부가 부모 컨텍스트에 남아 이후 매 턴 비용을 밀어 올렸을 것이다. 이 계산은 압축이 누적이 아니라 한 턴에서 비롯된다는 실측과 같은 축에 있다.

위임 비용은 어떻게 계량하는가?

에이전트를 띄울 때마다 네 값을 기록해 두면 다음 위임의 예산이 된다. 절차는 짧다.

1. 위임 직전에 하네스에 무엇을 못 박았는지 한 줄로 적는다(파일 N개·탐색 금지 여부·쌍 정보 유무).
2. 완료 후 그 기의 토큰·도구호출 수·소요시간·재작업 여부를 기록한다. 도구호출 수가 가장 예측력 있는 단일 지표였다.
3. 보고 내용 중 핵심 주장 1~2개를 메인이 직접 재확인한다. 완료 보고를 그대로 믿지 않는다.
4. 효율 여부와 개선점을 운영 로그에 1줄 이상 남긴다. 다음 유사 작업 전에 이 로그를 먼저 본다.

# 운영 로그에 한 줄로 남긴다 (날짜·분야·용도·기수/토큰·효율·개선점)
# 예: 2026-08-16 · 품질 감사 2기 · A 22콜/156,772 · B 11콜/124,621
#     개선점: 목록은 URL+제목 쌍으로 고정 → 22콜이 11콜로 준다

3번을 빠뜨리면 계량이 무의미해진다. 실제로 발행 에이전트가 "성공"을 보고했는데 오브젝트 키에 접두어를 잘못 붙여 이미지가 전부 404였던 사고가 있었다. 데이터베이스 삽입은 성공했고 로그도 성공이었다. 그 뒤로는 제작·발행·검사를 서로 다른 에이전트로 갈랐고, 검사 에이전트의 보고조차 메인이 한두 항목은 직접 재확인한다. 이 3분할과 감사 하네스 설계는 교차 감사 하네스에서 자세히 다뤘고, 이 두 기의 결과를 포함한 전체 12편 감사의 배경은 AI 두 기에게 발행글 12편을 감사시킨 결과에서 다뤘다.

이 수치가 통하지 않는 조건은 무엇인가?

156,772와 124,621은 고정 단가가 아니다. 특정 모델 등급으로, 특정 날짜에, 발행글 6편 감사라는 특정 작업에서 나온 값이다. 작업 범위와 도구호출 횟수가 달라지면 값도 달라진다. 같은 운영 기록 안에서도 1기당 102,951에서 304,000까지 세 배 가까이 벌어졌다.

방법 쪽 한계는 더 분명하다. "파일을 못 박으면 호출이 준다"는 규칙은 대상이 파일일 때만 성립한다. 웹 리서치처럼 대상이 미리 특정되지 않는 작업은 못 박을 것이 없어 호출 편차가 그대로 남는다(같은 날 45회와 6회). 이런 작업에는 파일 목록 대신 "공식 문서가 차단되면 즉시 대체 출처로 전환하고 재시도는 2회까지" 같은 실패 경로 지시가 호출 폭주를 막는 데 더 유효했다.

마지막으로, 위임은 자체완결적인 작업에서만 싸다. 여러 기가 같은 공용 파일을 각자 읽으면 그 파일을 기수만큼 중복 결제한다. 경계가 크게 겹치면 기수를 늘리는 것이 아니라 1기로 합치는 쪽이 맞다.

자주 묻는 질문

Q. 서브에이전트 1기를 띄울 때마다 15만 토큰씩 드나?
A. 고정 단가는 아니다. 실측한 두 사례가 156,772토큰과 124,621토큰이었고, 다른 작업에서는 102,951에서 304,000까지 벌어졌다. 작업 범위와 도구호출 횟수가 결정한다.

Q. 부모 대화에 남는 것이 결과 요약뿐이라는 것은 무슨 뜻인가?
A. 서브에이전트는 부모 대화 기록을 물려받지 않고 결과만 반환하므로, 에이전트가 내부에서 쓴 토큰은 부모 컨텍스트에 쌓이지 않는다. 다만 반환된 보고서 자체는 부모 대화에 영구히 남는다(건당 약 3.8k 실측). 그래서 하네스에 "결론만 반환"을 명시한다.

Q. 도구호출을 줄이는 가장 확실한 방법은 무엇인가?
A. 읽을 파일을 절대경로로 못 박고 탐색 도구 사용을 금지하는 것이다. 이렇게 지시한 사례는 도구호출 9회로 끝났고, 스코프가 무제한이면 탐색 호출만 48~68회까지 늘었다.

Q. URL과 제목을 함께 주면 도구호출이 절반이 되나?
A. 실측 사례에서 22회가 11회가 됐다. 검증 가능한 정보를 함께 주면 캐시 오류 같은 외부 요인을 에이전트가 스스로 걸러내 재수집이 줄어드는 원리이며, 대상이 검증 가능한 식별자를 가질 때 적용된다.

Q. 소요시간과 토큰 소비는 비례하나?
A. 이 사례에서는 대체로 비례했다(288초·22회·156,772토큰 대 182초·11회·124,621토큰). 다만 도구호출 왕복 시간이 대부분을 차지한 작업의 특성일 수 있어, 계산이나 생성 비중이 큰 작업에는 그대로 적용하기 어렵다.