AI 에이전트 QA 자동화 — 토큰 경제 분석

"QA용 MCP를 따로 빼는 게 이득인가, 스킬로 처리하는 게 이득인가, 서브에이전트로 격리하는 게 이득인가?" 세 옵션을 토큰 비용 모델로 직접 계산해 비교한다.

Seobway · 2026-06-11 · 10분

0. 비교 결과 한눈에 보기

• 메인 컨텍스트 오염: C가 A 대비 5.9배 작음
• QA 수행 중 메인 빌링: C가 A 대비 41배 적음
• 메인이 실제로 부담하는 총 토큰: C가 A 대비 10.1배 적음

세 선택지는 경쟁 관계가 아니라 서로 다른 레이어다. 그래서 "택1"이 아니라 "조합"이 정답이다.

1. 왜 같은 층위 비교가 아닌가

이 셋 중 토큰을 좌우하는 절대 변수는 "QA가 만들어내는 더러운 중간 산출물이 어느 컨텍스트에 누적되느냐" 다. 그건 오직 서브에이전트(격리)만 해결한다.

2. 핵심 원리 — LLM 비용은 준2차(quasi-quadratic)다

LLM은 매 턴 컨텍스트 전체를 input으로 다시 전송한다.

턴 t의 빌링 input = (그 시점까지 누적된 컨텍스트 크기)
세션 총 빌링 input = Σ_{t=1..N} (컨텍스트_at_t)

컨텍스트가 매 턴 커지면 비용은 선형이 아니라 누적합(준2차)으로 증가한다. 한 번 들어온 노이즈는 그 턴만 비싼 게 아니라 이후 모든 턴에서 계속 재청구된다. 이게 "QA 출력을 메인에 떨구면 안 되는" 진짜 이유다.

3. 모델 가정 — 계산에 사용한 파라미터

3.1 Playwright 단일 호출 출력 토큰 (실측 근사, char/4)

3.2 대표 QA 플로우 1회 = 10 스텝

navigate → snapshot → click → snapshot → type → click
        → snapshot → console → network → screenshot

플로우 1회 도구 출력 누계: 최소 11,600 토큰, 평균 33,850 토큰, 최대 56,100 토큰.

3.3 기타 상수

4. 옵션별 계산

계산 코드(요지):

def billed(base, outs):          # 한 플로우의 준2차 빌링
    ctx = base; tot = 0
    for o in outs:
        tot += ctx               # 이번 턴 컨텍스트 전체 재전송
        ctx += o                 # 도구 출력이 컨텍스트에 누적
    tot += ctx
    return tot, ctx

옵션 A — MCP를 메인 에이전트가 직접 호출 (격리 X)

QA 노이즈(평균 33,850/회)가 메인 컨텍스트에 그대로 누적되고, 이후 모든 턴에서 재청구된다.

QA가 끝나고 일반 작업으로 돌아가도, 부풀어 오른 119k 컨텍스트를 매 턴 계속 끌고 다닌다. 세션이 길수록 손해가 복리로 커진다.

옵션 B — 스킬만 (메인에서 실행)

절차는 고정되지만(신뢰성↑), 도구 출력은 여전히 메인에 떨어진다. 토큰 문제는 풀지 못한다.

스킬은 토큰 절감 수단이 아니라 절차 일관성 수단이다.

옵션 C — 서브에이전트 (격리)

노이즈(평균 33,850/회)는 서브에이전트의 격리된 컨텍스트에서 살다가 종료 시 폐기된다. 메인은 최종 리포트(800)만 수령한다.

5. 결과 비교

메인 부담 총 빌링 (서브 격리 비용 제외):
A  ████████████████████████████████████████  4,711,500
B  ████████████████████████████████████████  4,791,000
C  ████                                         464,400   (A의 1/10)

해석은 세 가지다.

1. 메인 컨텍스트 오염 5.9배 — 추론 품질에 직접 영향을 준다. QA 후에도 부푼 컨텍스트를 계속 끌고 다닌다.
2. QA 중 메인 빌링 41배 — QA를 자주 돌릴수록 격차가 폭발적으로 커진다.
3. 세션이 길수록 C 우위 확대 — POST_TURNS(QA 후 작업 턴)가 늘면 A는 큰 컨텍스트를 매 턴 재청구하고, C는 작은 컨텍스트만 유지한다.

6. "MCP 따로 빼기"가 이 환경에선 거의 의미 없는 이유

이 환경의 MCP 도구는 deferred(지연 로딩) 상태다.^[1]

The following deferred tools are now available via ToolSearch.
Their schemas are NOT loaded — ... Use ToolSearch ... before calling.

Playwright MCP(약 25개 도구)가 연결돼 있어도 스키마가 컨텍스트에 올라오지 않는다. 이름 한 줄(약 10토큰)만 차지한다. 실제로 쓸 때는 ToolSearch로 그 도구만 on-demand 로딩한다.

→ "QA용 MCP를 별도 서버로 분리"해서 얻는 스키마 절감 이득이 사실상 0이다.

7. 권장 구성 — 세 가지를 레이어로 합친다

세 개를 대체재로 보지 말고 레이어로 합친다.

오케스트레이터(메인)
   └─ 서브에이전트(qa) 스폰  ← 격리 경계 (토큰 절감의 본질)
        ├─ 절차: qa 스킬/qa.md 로 QA 순서 고정  ← 계획 재추론 절감
        └─ 도구: Playwright MCP를 내부에서 on-demand fetch  ← 스키마 0 (deferred)
   ← 받는 것: _workspace/03_qa_report.md (요약 ~800토큰) 만

이 구성의 토큰 효과는 다음과 같다.

• 노이즈 = 서브에 격리 후 폐기 → 메인 5.9배 슬림, 메인 부담 10배 절감
• 스키마 = deferred라 안 쓰면 0 → MCP 분리 불필요
• 절차 = 스킬로 고정 → 매번 "QA 뭐부터 하지" 재추론 제거 (회당 1~3k 추가 절감)

서브에이전트를 활용한 작업 분리에 대한 더 자세한 내용은 Context Engineering — 프롬프트, Rules, 메모리, Skill 시스템 → 글에서 다뤘다.

8. 부록 — 계산 재현

PYTHONIOENCODING=utf-8 python 로 3장 파라미터와 4장 billed() 함수를 사용, RUNS=3 / POST_TURNS=20으로 산출했다.

파라미터(snapshot 출력 크기, POST_TURNS)를 바꾸면 절감 배수는 달라지지만, C가 A·B를 항상 압도하는 방향성은 불변이다. 노이즈가 클수록, 세션이 길수록 격차는 더 벌어진다.

참고

1. [1] Claude Code Docs — Connect Claude Code to tools via MCP
2. [2] Claude Code Docs — Subagents

관련 글

• Context Engineering — 프롬프트, Rules, 메모리, Skill 시스템 →
• AI 개발 프로세스 — 작업 분할, Spec, TDD Workflow, Hook 설계 →

• ai-agent
• claude-code
• subagent
• mcp
• token-economics
• qa-automation