[!IMPORTANT]
검증 결론 (E18 실기 검증 경로: 20/20
독립 테스트 전 통과・VM222
정상 정지 확인 완료)
단일 Executor 루프가 빠지기 쉬운 '근시안적인 단계 패치 시도와 시행착오'의 실증: 상위 설계 Advisor의 교차적 아키텍처 지침 없이 단일 워커(Executor)만으로 테스트 실행과 패치 적용을 반복하는 Mode A에서는, 모듈 간의 일관성(SoloExecutorLoop
)
validator.py
→settlement.py
→statement.py
）를 한 번에 조망할 수 없어, 1 파일씩 패치를 적용하고 재테스트를 돌리는 되돌림(unplanned_retries = 2
,
파일 편집 5
회, 모델 호출 4
회）이 발생하여, 매번의 트라이얼 로그가 대화 기록에 축적되어 누적 입력 토큰이 팽창했습니다. (27,699
・누적 출력 토큰 2,897
Claude Code: Turn 1 단계에서 단 한 번 Advisor에게 상담하는 /advisor 패턴(AdvisorExecutorRouting
）의 압도적인 우위성(consult_advisor,
advisor_calls = 1
)을 보이며, 3 모듈에 걸친 5가지 항목 아키텍처 설계 청사진(1,143
자)을 받은 후 Executor가 일괄 구현하는 Mode B에서는 계획되지 않은 되돌림 리트라이를 AdvisorExecutorRouting
으로 완전히 제로(0)화(Turn 2의 원샷(파일 편집 unplanned_retries = 0,
-100%
삭감) 3
회）만에 독립 채점 스위트 20/20 케이스를 완수했습니다. (100%
정량적 삭감 효과: Mode B는 Mode A와 비교하여, 모델 호출 횟수를, 파일 편집 횟수를 -50.0%
(4회 → 2회), 툴 출력 문자 수를 -40.0%
(5회 → 3회), 누적 입력 토큰을 -94.5%
(22,720
자 → 1,245
자), 누적 출력 토큰을 -84.9%
(27,699
→ 4,172
토큰, 6.64배 효율화), 추정 API 비용을 -45.9%
(2,897
→ 1,568
토큰), 실행 시간을 -71.5%
($0.0316
→ $0.0090
, 약 1/3.5) 삭감했습니다. -43.9%
(33.45초
→ 18.78초
, 1.78배 고속화`)
1. 실험의 배경과 목적 (가설 검증)
Anthropic Claude Code의 /advisor 패턴(Opus Advisor + Sonnet/Flash Executor Dynamic Routing)이나 Google Antigravity의 /plan
- 경량 실행 라우팅에서는 다음과 같은 하네스 설계 원칙이 제안되고 있습니다.
【검증 대상 주장 (C014)】
단일 워커 설정(동일 프롬프트・동일 추론 예산)만으로 복잡한 다중 모듈 설계부터 반복적인 코드 편집 및 테스트 실행까지 모든 턴을 계속 진행할 경우, 국소적인 오류 수정(Whack-a-Mole / 모글라타끼 패치)에 빠지기 쉬우며, 되돌림 턴과 누적 컨텍스트가 증가합니다. Turn 1 단계에서만 Advisor로부터 간결한 '설계 지침 청사진 (Architectural Blueprint Memo)'을 받고, 일상적인 파일 편집은 고속 Executor로 일괄 실행함으로써, 되돌림을 제로화하는 동시에 총 토큰 및 레이턴시를 극적으로 줄일 수 있습니다.
본 실험(실험18 / E18)에서는, 완전 오프라인・NIC이 없는 격리 샌드박스 VM(
**）상에서, 3 모듈 구성의 결제 정산・차지백 적립금・스테이트먼트 생성 파이프라인(
VM222
validator.py
, settlement.py
, statement.py
）의 복합 버그 수정 과제를 소재로, 다음 2가지 실행 라우팅 방식을 비교했습니다.
- Mode A:
SoloExecutorLoopRunner
/ 단일 Executor 시행착오 루프) - Advisor에 사전 상담(advisor_calls = 0
）을 거치지 않고, Turn 1에서 run_solo_trial
을 실행하고, Turn 2에서 validator.py
부분 패치(stage_executor_patch)를 적용하는 4턴 반복 워크플로우로, Turn 3에서는 settlement.py에 부분 패치(stage_executor_patch)를, 그리고 Turn 4에서는 세 가지 모듈 전체를 최종 제출(submit_settlement_bundle)합니다.
Mode B (AdvisorExecutorRoutingRunner):
최초 Advisor 설계 상담 + Executor 일괄 구현을 수행하며, Turn 1에서 consult_advisor (advisor_calls = 1)를 호출하여 세 모듈 간의 데이터 계약 및 경계 조건에 대한 5가지 설계 지침 메모(one_shot_execution_blueprint, 1,143 문자)를 얻습니다. 이후 Turn 2에서는 Executor가 이 설계 지침에 따라 세 모듈 전체를 일괄 구현 및 제출(submit_settlement_bundle)하는 2턴 워크플로우입니다.
2. 실험 아키텍처와 비교 워크플로우
3. 실기 검증 결과 (Mode A vs. Mode B 정량적 비교)
VM222 상에서 수집된 7개의 증거 파일(run-summary.json, independent-tests.json, execution-traces.json, usage.json)을 기반으로 측정한 비교 결과는 다음과 같습니다.
| 평가 지표 | Mode A: 단일 Executor 반복 (SoloExecutorLoop) | Mode B: Advisor-Executor 라우팅 (AdvisorExecutorRouting) | 차이점 및 개선 효과 (Mode B 우위성) |
|---|
| 독립 테스트 통과율 (총 20 케이스) | 20 / 20 (100%) | 20 / 20 (100%) | 동등함 (양측 모두 20/20 완수) |
| 계획 외 부분 패치 재작업 횟수 (unplanned_retries) | 2회 | 0회 | -100% 감소 (재작업 완전 배제) |
| 파일 수정 횟수 (file_edits) | 5회 | 3회 | -40.0% 감소 (각 모듈당 단 1회만 업데이트) |
| 모델 호출 횟수 (model_calls) | 4회 | 2회 | -50.0% 감소 |
| 누적 도구 출력 문자 수 (tool_output_chars) | 22,720 문자 | 1,245 문자 | -94.5% 감소 (18.25배 압축률) |
| Turn 1 입력 / 출력 토큰 수 | 1,909 in / 10 out | 1,846 in / 8 out | 첫 번째 턴은 거의 동일 |
| Turn 2 입력 / 출력 토큰 수 | 5,000 in / 488 out (validator.py 패치) | 2,326 in / 1,560 out (세 모듈 모두 완성) | Mode B는 Turn 2에서 전 과정 완료 |
| Turn 3 입력 / 출력 토큰 수 | 8,527 in / 795 out (settlement.py 패치) | — (Turn 2에서 완료) | 중간 패치 턴을 완전히 회피 |
| Turn 4 입력 / 출력 토큰 수 | 12,263 in / 1,604 out (최종 제출) | — (Turn 2에서 완료) | 이력 팽창(12,263 in)을 완전히 회피 |
| 누적 입력 토큰 (promptTokenCount) | 27,699 tokens | 4,172 tokens | -84.9% 감소 (6.64배 효율화) |
| 누적 출력 토큰 (candidatesTokenCount) | 2,897 tokens | 1,568 tokens | -45.9% 감소 (중복 코드 재출력을 배제) |
| 추정 API 비용 (estimated_micro_usd) | 31,640 micro-USD ($0.0316) | 9,010 micro-USD ($0.0090) | -71.5% 비용 절감 (약 1/3.5) |
| 에이전트 실행 시간 (elapsed_seconds) | | | |
33.4540초 |
18.7828초 |
-43.9% 단축(1.78배 고속화) |
4. 실행 추적 심층 분석
SoloExecutorLoop:
단계적 패치에 의한 입력 및 출력 양방향 토큰 낭비
4.1 Mode A(execution-traces.json과 usage.json)를 분석한 결과, 사전 설계 블루프린트가 없는 단일 Executor Loop에서는 다음과 같은 이중 비용이 발생하고 있음을 알 수 있습니다.
-
입력 측 히스토리 팽창: Turn 1(1,909 in) → Turn 2(5,000 in) → Turn 3(8,527 in) → Turn 4(12,263 in)와 같이 부분 패치를 적용하여 트라이얼 하네스를 재실행할 때마다 약 7,500자의 실행 로그가 대화 기록에 쌓여, 4턴 누적 시 27,699 입력 토큰을 사용했습니다.
-
출력 측 코드 재생성 비용: Turn 2에서 validator.py(488 out), Turn 3에서 settlement.py(795 out)를 개별적으로 출력한 후, Turn 4의 최종 번들 제출 시 다시 세 모듈 전체(1,604 out)를 출력했기 때문에, 누적 출력 토큰 역시 (Mode B의 2,897 토큰)으로 부풀어 올랐습니다. (1.85배)
-
Turn 2에서
AdvisorExecutorRouting:
설계 지침 메모에 의한 원샷(One-shot) 완료
4.2 Mode B에서는 Turn 1(sequence: 4)에서 consult_advisor를 호출하여, 세 모듈 전체의 수정 요구 사항을 5개 항목으로 응축한 one_shot_execution_blueprint(1,143자)를 얻었습니다.
- 이를 통해 Turn 2(
sequence: 5)의 입력 토큰은 미미하게 줄어들었으며, Executor는 망설임 없이 세 파일 전체를 한 번에 작성(2,326 토큰 / 1,560 out)하여 총 비용으로 모든 20개 케이스를 클리어했습니다. ($0.0090 (Mode A 대비 -71.5%)) 및 실행 시간 18.78초 (Mode A 대비 -43.9%)
5. 독립 평가 스위트(20케이스) 검증 내역
labjudge18 사용자에 의해 실행된 독립 테스트 스위트 전 20개 케이스의 결과는 다음과 같으며, 두 모드 모두 모든 항목을 통과했습니다.
| 케이스 번호 | 테스트 케이스 ID | 검증 내용 | Mode A | Mode B |
|---|
| 1 | validator_01_normalize_and_non_mutation | 공백 제거(trimming), 대문자 변환, 여분 키 제거 및 입력 사전의 비파괴성 | PASS | PASS |
| 2 | validator_02_empty_and_non_list_rejected | 빈 리스트 [], None, 그리고 dict가 아닌 요소 거부 | PASS | PASS |
| 3 | validator_03_blank_or_non_str_merchant_and_unknown_currency_rejected | 공백 문자(empty string)의 가맹점 ID, 알 수 없는 통화 코드(CHF) 거부 및 JPY 허용 | PASS | PASS |
| 4 | validator_04_tx_count_and_chargeback_bps_bounds_0_to_1000 | chargeback_bps 경계값 0 및 1000 허용과 범위 외 거부 | PASS | PASS |
| 5 | validator_05_zero_unit_cents_allowed_negative_rejected | $0 승인(Authorization) (unit_cents == 0) 허용 및 음수 거부 | PASS | PASS |
| 6 | validator_06_bool_rejected_on_all_int_fields | Python bool (True/False)의 엄격한 거부 | PASS | PASS |
| 7 | settlement_01_first_seen_order_and_aggregation | 최초 발견 순서(First-Seen Order) 유지 및 동일 키 합산 | PASS | PASS |
| 8 | settlement_02_conflicting_unit_cents_or_bps_rejected | 동일 (merchant_id, currency) 간의 단가/bps 불일치 감지 | PASS | PASS |
| 9 | settlement_03_exact_chargeback_bps_300_vs_301_boundary | chargeback_bps == 300 (예비금 0)과 301 (10% 예비금)의 경계 검증 | PASS | PASS |
| 10 | settlement_04_exact_15000_growth_discount_boundary | GROWTH 티어의 14999 (0%) vs 15000 (10% 할인) 경계 검증 | PASS | PASS |
| 11 | settlement_05_enterprise_tiered_10_vs_20_discount | ENTERPRISE 티어의 <15000 (10%) vs >=15000 (20%) 검증 | PASS | PASS |
| 12 | settlement_06_floor_truncation_reserve_and_fee | 예비금 및 게이트웨이 수수료의 정수 절사(//) 검증 | PASS | PASS |
| 13 | settlement_07_rebate_capped_at_after_discount | 수수료 리베이트의 after_discount 상한(cap) 검증 | PASS | PASS |
| 14 | settlement_08_invalid_tier_or_bool_rebate_rejected | 부적절한 계약 티어 및 bool 타입 리베이트 거부 | PASS | PASS |
| 15 | settlement_09_lowercase_tier_and_multi_currency_grouping | 소문자 티어 정규화 및 다중 통화 그룹핑 | PASS | PASS |
| 16 | e2e_01_growth_below_15000_minus_zero_and_hash_separator | E2E: # 구분자 및 -0 포맷의 엄격 일치 | PASS | PASS |
| 17 | e2e_02_enterprise_reserve_and_rebate_statement | | | |
E2E: 엔터프라이즈 충당금, 20% 할인 및 리베이트 공제 통합 검증 | PASS | PASS |
| 18 | e2e_03_zero_amount_auth_statement |
E2E: $0 승인 트랜잭션의 스테이트먼트 출력 | PASS | PASS |
| 19 | e2e_04_line_order_preserved_in_statement |
E2E: 스테이트먼트 출력 행에서의 최초 등장 순서 유지 | PASS | PASS |
| 20 | e2e_05_error_propagation_across_stages |
E2E: 검증기(Validator) 통과 후 정산 단가 불일치 오류 전파 | PASS | PASS |
6. 샌드박스 불변 조건 및 보안 검증
(ai-e18-222, UUIDb106ad71-8240-4079-9a12-174806816098)는 NIC가 없으며(/sys/class/net은 lo만), PrivateNetwork=yes, ProtectSystem=strict, NoNewPrivileges=yes로 작동하며, 에이전트(labexp18)로부터 채점 디렉토리(/opt/ai-lab-e18-vm222-01/evaluation 등)에 대한 접근이 완전히 차단되어 있음을 access_probe로 실기 확인했습니다. -
기존 VM 그룹 보호: 실험 전후 및 독립 리드백(02-readback.result.json)에서, VM100(running / broker paused), VM200(stopped), VM205~VM221(stopped, 구성 SHA-256 완전 일치), VM9300(stopped)에 어떠한 변경도 없었으며, VM222가 실험 완료 후 정상적으로 종료(stopped, config SHA-256:a1550f14f4310fc6d78a496c26d76aa1e90b110f3d0dc168f33327f20f9340fe) 되었음을 확인했습니다.
📚 AI Labo "AI 에이전트 하네스 엔지니어링 실기 검증" 시리즈 총정리집
본 기사는 SNS(X / Threads)나 해외 주요 테크 블로그(OpenAI / Anthropic / Google / Thoughtworks 등)에서 제안된 AI 에이전트의 하네스 설계 패턴을, 완전 오프라인 격리 샌드박스 VM 위에서 정량적 A/B 테스트를 수행하는 AI Labo 실증 시리즈의 한 편입니다.
모든 실험의 토큰 감소율 랭킹 & 하네스 엔지니어링 황금 패턴 총정리집은 아래 마스터 기사에서 수시로 업데이트되고 있습니다. 꼭 북마크 및 팔로우하여 최신 실증 결과를 확인해 주십시오!
Discussion
