Reasoning effort(추론 강도)가 도구 접근보다 agentic 코드 생성의 첫 시도 신뢰성을 결정한다: 관찰 연구

TL;DR Highlight

Claude Code로 90번 반복 실험한 결과, Playwright 같은 테스트 도구는 비용만 올리고 실패율엔 무효였으며 xHigh reasoning effort가 첫 시도 완성률을 28%→89%로 끌어올렸다.

Who Should Read

Claude Code, Cursor 같은 agentic 코딩 도구를 팀에 도입 중인 개발자나 엔지니어링 리더. 도구/프롬프트/모델 선택으로 품질을 높이려는 상황에 직접적으로 적용 가능.

Core Mechanics

모델 등급(capability tier)이 결과를 가장 크게 좌우함. Claude Opus 4.7/4.6, Sonnet 4.6 등 프론티어 모델은 평균 41점대(42점 만점)로 수렴했고, 로컬 모델 Qwen은 30.5점으로 10점 이상 격차가 났다.
Playwright(브라우저 자동화 테스트 도구)를 붙여도 기능 점수는 그대로였고 비용만 42~68% 올랐다. 실패가 주로 Docker 빌드·환경 문제에서 발생했는데, Playwright는 렌더된 UI만 보기 때문에 그 실패를 잡을 수 없었던 것.
Playwright가 추가 비용을 쓴 방식을 토큰 레벨로 분석했더니, 추가 코드 생성이 아니라 cache read(이미 본 컨텍스트 재독)에 비용이 집중됐다. 도구 호출로 스크린샷·응답이 쌓이면서 모델이 세션을 반복해서 다시 읽는 것.
reasoning effort를 High → xHigh로 올리자 첫 시도 완성률이 28%(18회 중 5회) → 89%(18회 중 16회)로 뛰었고, 수정 프롬프트(사람 개입) 횟수는 약 5분의 1로 줄었다. 비용 증가는 9~29% 수준이었다.
xHigh가 잡아낸 실패는 npm install 오류, Docker 빌드 실패 같은 환경 문제들이었다. 전체 90회 실험에서 Docker 첫 시도 실패가 44%로 가장 많았고, 두 환경 criteria가 전체 첫 시도 실패의 55%를 차지했다.
디자인 프롬프트(시각 품질 요청)는 기능엔 영향 없이 미적 점수를 3.0 → 4.5~4.7(5점 만점)로 올렸다. 단 한 문단짜리 파라프레이즈도 원본 서드파티 프롬프트와 동일한 효과를 냈으며, 모델 버전이나 reasoning effort와 무관하게 작동했다.

Evidence

xHigh effort vs High effort: 첫 시도 완성(42점, 수정 없음) 비율 89%(16/18) vs 28%(5/18), Fisher exact p < 0.001. 수정 프롬프트 횟수는 3회 vs 16회로 약 5배 차이.
Docker 첫 시도 통과율이 Opus 4.6 High에서 20회 중 2회(10%)였다가, Opus 4.7 High에서 18회 중 13회(72%), xHigh에서 18회 중 17회(94%)로 급상승. 그러나 총점 평균 차이는 1점 미만(40.7 vs 41.3)이라 총점만 보면 이 차이가 안 보임.
Playwright 추가 시 Opus 4.7 기준 비용 중앙값: High에서 $3.06 → $4.34(+42%), xHigh에서 $3.33 → $5.59(+68%). 기능 점수 중앙값은 두 경우 모두 동일.
디자인 프롬프트(full) 22회 평균 미적 점수 4.5, 한 문단 축약 프롬프트 18회 평균 4.7 vs 디자인 프롬프트 없는 45회 전부 정확히 3.0. 한 문단 버전의 중앙값 비용 $4.14로 원본($4.28)과 거의 동일.

How to Apply

Claude Code에서 첫 시도 신뢰성이 중요한 태스크(CI 자동화, Docker 배포 포함 프로젝트)라면 Playwright 같은 UI 테스트 도구 추가 대신 reasoning effort를 xHigh로 올려보라. 비용 증가 9~29%로 사람 개입을 80% 줄일 수 있다.
UI 퀄리티가 중요한 프로젝트(제품 데모, 내부 대시보드)라면 CLAUDE.md에 아래 한 문단 디자인 지시문을 추가하면 된다. 긴 서드파티 프롬프트 없이도 미적 점수가 3→5점으로 오른다. 다만 drag-and-drop 같은 인터랙션 heavy 기능의 첫 시도 실패율이 소폭 올라가는 트레이드오프가 있음.
에이전트 도구(Cursor, Antigravity 등)가 hidden system prompt를 주입하는지 먼저 확인하라. 모델 A vs 모델 B를 비교할 때 사실은 서로 다른 hidden prompt를 비교하는 상황일 수 있다. 모델 비교 시 serving backend가 무엇을 추가하는지 먼저 파악하는 게 선행되어야 한다.

Code Example

snippet

# CLAUDE.md에 추가하는 한 문단 디자인 지시문 (논문에서 실제 사용한 abridged prompt)

Treat visual quality as a first-class priority for any user interface you build.
The result should feel premium, modern, and polished at first glance, never plain or minimal.
Use a curated, harmonious color palette instead of generic default colors;
sleek dark themes are welcome.
Use modern typography (for example a Google font such as Inter or Outfit)
instead of browser defaults.
Use smooth gradients and subtle micro-animations,
and add hover effects so the interface feels responsive and alive.
Do not ship a design that looks like a simple minimum viable product.

# 결과: 미적 점수 3.0 → 5.0 (5점 만점), 기능 점수는 유지, 비용은 base 대비 약 35% 증가

Terminology

reasoning effort모델이 답을 내기 전에 얼마나 깊이 '생각'하게 할지 설정하는 파라미터. High, xHigh처럼 단계가 있으며, 높을수록 토큰을 더 써서 내부적으로 더 많이 검토한 뒤 답을 냄.

agentic coding사람이 한 줄씩 지시하지 않고, AI가 스스로 파일을 만들고, 명령어를 실행하고, 오류를 수정하는 방식으로 코드를 완성하는 것. Claude Code, Cursor Agent 모드가 대표적.

first-try reliabilityAI가 첫 시도에 수정 없이 요구사항을 모두 통과하는 비율. 사람이 개입해서 수정해줘야 하는 횟수와 반비례함.

reasoning effort xHighClaude Opus 4.7에서 지원하는 최고 추론 강도 설정. 일반 High보다 더 많은 내부 추론 단계를 거쳐 답을 생성하며, 환경 설정 오류 같은 복잡한 문제를 첫 시도에 더 잘 잡아냄.

Playwright브라우저를 코드로 자동 조작해서 웹 앱을 테스트하는 도구. 버튼 클릭, 화면 스크린샷 등을 자동화할 수 있음. 이 논문에서는 AI 에이전트에게 이 도구를 주었을 때 효과를 실험함.

capability tier모델의 전반적인 능력 등급. 프론티어 모델(Claude Opus, Sonnet 등)과 저비용 로컬 모델(Qwen 등)처럼 성능 차이가 큰 그룹으로 나뉨.

cache read tokens이미 처리한 컨텍스트(대화 기록, 파일 내용)를 다시 읽을 때 발생하는 토큰 비용. 새로운 생성(output tokens)과 달리 이미 본 내용을 재탕하는 비용이라 효율이 낮음.

hidden system prompt서비스 제공자가 사용자 모르게 모델에 주입하는 지시문. Antigravity 에이전트가 자체 시스템 프롬프트를 몰래 추가하는 것처럼, 사용자가 제어할 수 없는 프롬프트.

Related Resources

Original Abstract (Expand)

Agentic coding assistants are increasingly given extra capabilities, such as browser based testing tools and design oriented system prompts, on the assumption that more capability yields better software. This study tested that assumption directly. Ninety independent agent runs built the same application, a real time retrospective board, from one detailed specification, each scored on a fixed 14 criterion functional rubric (42 point maximum) and a visual quality review. The runs spanned several model generations, two agent harnesses, two reasoning effort levels, a testing tool, and two design oriented prompts. Capability tier dominated: frontier models clustered near the ceiling while a low cost local model fell to 24 to 37 points. A criterion level analysis revealed what run totals conceal. Container deployment was the dominant defect, failing first try in 44 percent of runs, with its failure rate shifting sharply across model generations while mean totals moved less than a point. The testing tool raised cost by 42 to 68 percent without improving functional score or reliability, even on interface visible criteria. Raising reasoning effort from High to xHigh lifted first try perfect runs from 28 percent to 89 percent and cut corrective prompts about five fold, for 9 to 29 percent more cost. A design oriented prompt raised visual quality, 4.5 versus 3.0 on a 5 point scale, without lifting function, and a one paragraph paraphrase of its directive reproduced the entire lift. The practical lesson is to match the fix to the failure: most first run failures came from weak reasoning, which a stronger model or more effort prevents, not from visible flaws a checking tool would catch.