에이전트에게 ‘실패하는 테스트’를 먼저 주면 통과율이 22%에서 90%가 된다: Claude Code와 Android CLI 검증 루프 해부

150K 컨텍스트 예산 및 결정론적 Hook 코어(좌측), 3단계 동심원 검증 루프(중앙: JVM → Compose Preview → Emulator/Device), 그리고 XR 글래스 및 30FPS 시스템 트레이스 타깃(우측)을 형상화한 3D 아이소메트릭 개념 일러스트다. 실제 프로파일러나 IDE 화면이 아니다.

Google이 공개한 Android Dev Summit 2026 에이전틱 엔지니어링 세션 영상(Agentic engineering with Claude Code and Android CLI)과 Android Bench 2.0 공식 방법론 문서는 코딩 에이전트(Claude Code, Codex, Antigravity 등)에게 수일 걸리는 대규모 마이그레이션이나 성능 최적화 과제를 맡겼을 때 왜 성공률이 20~40%대에 머무는지, 그리고 컨텍스트 예산 관리와 3단계 검증 루프(Verification Loop)로 이를 어떻게 **90%**까지 끌어올릴 수 있는지를 다룬다. Android 개발자 관계 엔지니어 Ben과 프로덕트 매니저 Steven은 온디바이스 테니스 코칭 앱 Sideline을 실제 사례로 들어 150K 토큰 스위트스폿, AGENTS.md·Hooks·Skills의 역할 분리, 그리고 Android CLI 기반의 계층형 검증 루프를 상세히 공개했다.

결론부터 말하면, 에이전트가 복잡한 엔지니어링 과제를 완수하지 못하는 주된 이유는 모델 지능이 부족해서가 아니라 ‘완료(Done)의 기준’과 ‘실행 환경(디바이스·프로파일러·크래시 로그)’이 주어지지 않았기 때문이며, 세션당 컨텍스트를 약 150K 토큰 이내로 유지하고 AGENTS.md는 에이전트가 직접 수정하지 못하게 막은 채 ‘빠른 JVM 테스트 → Compose 프리뷰 검증 → 에뮬레이터·실기기 스트리밍’의 3단계 검증 루프를 걸어주면 장기 과제 통과율이 22.7%에서 90%로 급증한다. 다만 이 글은 Google의 공식 발표 영상과 Android Bench 2.0 공개 지표를 교차 검증해 정리한 것이며, 자체 사내 저장소에서 에이전트 하네스별 토큰 비용을 직접 실측한 결과는 아니다.

왜 100만 토큰 윈도우 시대에도 ‘150K 토큰’이 마법의 구간인가

Android Dev Summit 2026 — Agentic engineering with Claude Code and Android CLI 공식 세션 썸네일 (원본 JPEG)

프론티어 모델들의 최대 컨텍스트 윈도우는 100만(1M) 토큰 수준에 도달했지만, 발표(07:56~11:58)에서는 실제 코딩 에이전트 하네스들이 100만 토큰을 끝까지 채워 쓰지 않는 이유를 **‘컨텍스트 부패(Context Rot)’**로 설명한다. 시스템 프롬프트, 워크스페이스 정보, 설치된 스킬 설명, MCP 도구 명세에 더해 매 턴마다 누적되는 전체 도구 호출 이력(특히 수천 줄에 달하는 장황한 Gradle 빌드 로그)이 쌓이면 모델의 추론 정확도가 급격히 떨어지고 비용만 폭증한다.

세션당 약 150,000 토큰 유지: 모델 지능을 손실 없이 끌어내는 실무 스위트스폿은 대화 이력을 포함해 약 150K 토큰 이내다. 최소한의 래퍼만 두는 경량 에이전트를 쓸 때는 반드시 gradle --quiet(-q) 옵션을 사용해 불필요한 빌드 로그가 컨텍스트를 잠식하지 않게 해야 한다.

150K 윈도우에 맞춘 4단계 이슈 분할 워크플로: 거대한 기능을 한 세션에서 통째로 짜게 하는 대신, ① grill-me 스킬로 에이전트가 개발자에게 역질문하며 요구사항의 모호성을 제거하고 → ② 상세 스펙(Spec) 문서를 작성한 뒤 → ③ 각각 150K 토큰 한 세션 안에 끝낼 수 있는 크기의 하위 이슈(Issue)들로 분할하고 → ④ 이슈 하나를 구현·검증할 때마다 컨텍스트를 완전히 초기화(clear)하고 다음 이슈로 넘어가는 패턴이 권장된다.

AGENTS.md, Hooks, Skills, CLI, MCP의 명확한 역할 경계

에이전트의 행동을 제어하기 위해 모든 규칙과 문서를 AGENTS.md 파일 하나에 몰아넣는 것은 흔한 안티패턴이다. 발표(12:00~20:18)에서는 다섯 가지 구성 요소의 역할과 흥미로운 실험 결과를 다음과 같이 구분한다.

구성 요소	컨텍스트 로드 시점	넣어야 할 내용과 피해야 할 안티패턴
`AGENTS.md`	모든 프롬프트마다 항상 로드 (250줄 이하 유지 권장)	클로즈드 소스 앱의 모듈 구조(“UI 컴포넌트는 디자인 시스템 모듈에 위치” 등), 프로젝트 고유 라이브러리 선호(`kotlinx-datetime` 등)만 기술. 주의: 에이전트가 스스로 `AGENTS.md`를 수정하게 두면 성능은 2~3% 하락하고 토큰 비용은 20% 증가하므로, PR 종료 시 회고(retrospective)만 출력하게 하고 파일 수정은 팀원이 직접 수행해야 함
`Hooks` (훅)	세션 시작·종료, 파일 읽기·쓰기 이벤트 발생 시 결정론적(Deterministic) 스크립트 실행	`AGENTS.md`에 “작업이 끝나면 항상 린터와 테스트를 돌려라”라고 적는 대신 Stop Hook으로 린터·테스트 스크립트를 강제 실행. 민감한 시크릿 파일이나 `AGENTS.md` 자체를 에이전트가 수정하지 못하게 막는 Write Hook 설정에 적합
`Skills` (스킬)	평소에는 이름과 짧은 설명(최대 1,024자)만 로드되고, 관련 작업일 때만 본문·스크립트 로드	`Navigation 3`나 `CameraX` 같은 특정 도메인 문서. 단, 검증되지 않은 ‘100개 에이전트 스킬 모음’ 저장소를 무분별하게 설치하면 보안 위험뿐 아니라 100개 × 1,000자 = 10만 자의 컨텍스트가 시작부터 낭비되므로 기본 Android CLI 스킬만 깔고 `skill-doctor` 등으로 미사용 스킬을 정리해야 함
`CLI` (Android CLI)	로컬 셸에서 에이전트가 필요시 명령 실행	로컬 SDK·에뮬레이터·실기기·`Perfetto` 프로파일러·`Gradle` 제어. 모델들이 `Terminal-Bench` 등을 통해 CLI 조작에 고도로 최적화되어 있어 로컬 작업에서 가장 빠르고 토큰 효율이 높음
`MCP Server`	도구 선언부가 컨텍스트에 상시 노출	`GitHub`, `Figma`, `Slack`처럼 이미 호스팅되어 있는 외부 원격 서비스의 컨텍스트(팀 채팅의 아키텍처 결정 맥락, PR 리뷰 코멘트 등)를 가져올 때 사용

실제로 Sideline 앱 데모에서는 에이전트에게 Android CLI를 통해 Firebase Crashlytics와 Android Device Streaming(원격 실기기 연결) 권한을 부여하자, 에뮬레이터에서는 재현되지 않던 Pixel 11 Pro Fold(Android 17) 단말의 ANR 이슈를 에이전트가 원격 실기기에 직접 붙어 재현하고 2줄짜리 수정 PR까지 검증해 제출했다. 또한 Pixel 10 Pro Fold에서 프레임이 20~22 FPS로 떨어지던 문제도 에이전트가 android profiler로 시스템 트레이스를 떠서 AI 추론 스레드가 가장 느린 CPU 코어에 스케줄링되고 있음을 스스로 찾아낸 뒤, android docs search로 PerformanceHintManager API 문서를 조회해 30 FPS를 달성했다.

Android Bench 2.0이 증명한 ‘검증 루프(Verification Loop)’의 위력: 22.7%에서 90%로

발표 후반부(22:32~28:54)에서 가장 주목할 데이터는 Android Bench 2.0 벤치마크에서 확인된 **검증 루프(Verification Loop)**의 효과다.

30개의 고난도 장기 과제(Long-Horizon Tasks, 수천 줄 규모의 앱 생성·마이그레이션)로 구성된 Android Bench 2.0 리더보드에서 기본 프롬프트만 주었을 때 모델들의 전체 통과율(Pass Rate)은 약 22~40% 수준(Claude Sonnet 5.5 40.0%, Claude Opus 5.5 37.3%, Claude Fable 5.1 22.7%)에 머문다. 에이전트가 Navigation 2를 Navigation 3로 마이그레이션하라는 지시를 받고 코드를 고친 뒤 스스로 “완벽히 끝났다”고 보고하지만, 실제로 화면을 회전해 보면 앱이 죽거나 애니메이션과 build.gradle 정리가 누락되어 있기 때문이다.

하지만 Fable 5.1 모델에게 정답 코드나 힌트를 주는 대신 ‘통과해야 할 실패 중인 테스트 스위트(Failing Test Suite)’를 사전에 함께 제공해 완료 조건을 명확히 정의하자, 벤치마크 통과율이 기존 22.7%에서 90%로 수직 상승했다.

이 원리를 실무에 적용할 때는 실행 속도가 빠르고 가벼운 검증부터 무겁고 정확한 검증 순서로 **3단계 계층형 검증 루프(Tiered Verification Loop)**를 구성해야 에이전트가 매 턴마다 수 시간짜리 전체 테스트를 돌리는 낭비를 막을 수 있다.

Sideline 팀은 차세대 XR 스마트 글래스용 실시간 스윙 속도 피드백 UI를 추가할 때 이 3단계 루프를 프롬프트에 명시했다. 그 결과 루프 1~2(JVM 테스트 및 Compose 프리뷰) 단계에서 에뮬레이터를 띄우지도 않고 6개의 프리뷰 상태 정의와 긴 문자열 오버플로 버그를 모두 잡아냈고, 마지막 **루프 3(XR 에뮬레이터)**에서는 런타임 상호작용 버그만 집중 수정해 한 번에 기능을 완성했다. 나아가 Claude Code의 /schedule 명령으로 이 검증 루프를 주기 실행해 신규 Crashlytics 이슈를 에이전트가 스스로 고치고 검증된 PR을 올려두는 자가 치유(Self-healing) 파이프라인까지 구축했다.

현업 Android 팀에서 에이전틱 엔지니어링을 도입할 때 확인할 점

사내 Android 프로젝트에 코딩 에이전트와 Android CLI를 결합할 때는 다음 네 가지를 먼저 점검하는 편이 좋다.

사람이 에이전트의 수동 QA 테스터 노릇을 하지 않도록 ‘완료 조건’을 선행 정의: 에이전트가 짠 APK를 개발자가 직접 폰에 깔고 눌러보며 버그를 채팅으로 다시 알려주는 방식은 병렬 에이전트 확장을 가로막는다. 작업 지시 전에 단위 테스트, android preview 렌더링 결과 확인, 또는 자연어 사용자 여정 테스트인 Journeys 통과 조건을 먼저 제시해야 한다.

AGENTS.md는 250줄 이내로 잠그고 반복 명령은 Stop Hook으로 이관: 에이전트에게 AGENTS.md 쓰기 권한을 주지 말고(Write Hook으로 차단), 린트·포맷터·기본 단위 테스트처럼 매번 지켜야 하는 규칙은 프롬프트 문구가 아니라 결정론적 Stop Hook 스크립트로 강제해야 비용(20% 절감)과 일관성을 모두 지킬 수 있다.

외부 스킬 무분별 설치 금지 및 Android CLI 기본 스킬 중심 운영: 출처 불명의 대량 스킬 팩을 설치하면 1,024자짜리 설명문들이 150K 컨텍스트 예산을 시작부터 갉아먹는다. 공식 Android CLI 스킬만 기본 장착하고 android skills list로 프로젝트에 꼭 필요한 최신 라이브러리(Navigation 3, Compose 등) 스킬만 선별 추가해야 한다.

온라인의 상충하는 프롬프트 팁보다 팀 고유의 소규모 Eval(평가셋) 구축: 모델 세대가 바뀔 때마다 대문자 강조(NEVER DO THIS)의 효과가 사라지는 등 프롬프트 요령은 수시로 변한다. Android Bench 2.0 방법론처럼 사내 코드베이스의 대표적인 마이그레이션·버그 수정 과제로 작은 자체 평가셋(Eval)을 만들어 두고 새 모델이나 워크플로가 실제로 효과가 있는지 측정하는 것이 가장 확실하다.

결국 에이전틱 엔지니어링의 핵심은 에이전트의 실패를 ‘AI의 한계’로 치부하는 대신, 소프트웨어 버그를 디버깅하듯 에이전트에게 부족했던 환경(실기기·프로파일러)과 완료 기준(계층형 검증 루프)을 채워 넣어 여러 에이전트가 사람의 개입 없이 병렬로 완주할 수 있는 트랙을 깔아주는 데 있다.