계약서가 성능을 바꿨다

3주 동안 실서비스 Next.js/TypeScript/Supabase 코드베이스에서 52개 통제 벤치마크를 돌린 결과다. 작업자는 Sonnet 4.6, 채점자는 Opus 4.7을 사용했고, 전체 데이터와 도구는 공개됐다.

핵심 레버는 코딩 전에 쓰는 CONTRACT.md였다. 정확한 인터페이스, 컬럼명, import 경로, SQL 규칙, 비목표를 담은 구조화된 브리프를 먼저 제공하자, 비용은 54% 감소했고 품질은 5/10에서 9/10으로 상승했다. 같은 모델, 같은 코드베이스에서 나온 결과다.

반면 Agent Teams는 효율이 나빴다.

• 순차 실행 대비 73~124% 더 비쌌고, 품질 이득은 없었다.
• 각 에이전트가 전체 코드베이스 컨텍스트를 독립적으로 로드해 캐시 비용이 크게 늘었다.
• 병렬 에이전트 3개면 사실상 80K 토큰 컨텍스트를 3번 내는 셈이라는 설명이다.

재시도 루프도 역효과였다.

• 9/10 → 6/10으로 품질이 떨어졌다.
• 재시도 과정에서 모델이 기존 파일을 부분 수정하지 않고 파일 전체를 다시 생성해, 이미 맞아 있던 부분을 망가뜨리는 패턴이 반복됐다.

검토 단계에서도 추가 비용 대비 효과가 없었다.

• Opus 단발 리뷰는 브리프가 잘 되어 있을 때 품질을 더 올리지 못했고, 비용만 56% 증가했다.
• 반대로 Haiku는 Sonnet이 작성한 계약서를 구현할 때는 Sonnet과 비슷한 품질을 64% 더 싸게 냈지만, Haiku가 계약서까지 직접 쓰면 품질이 4.9/10으로 무너졌다.

코드베이스 탐색 구조도 중요했다.

• L0 요약 → L1 시그니처 → L2 원본의 3단 인덱스가 평면 덤프보다 낫다.
• 순차 작업자는 반복 컨텍스트에서 98% 캐시 읽기율을 기록했지만, 병렬 작업자는 매번 캐시를 새로 채워야 했다.

대표 사례로는 $5.45 세션이 $0.83까지 줄었다고 제시했다. 다만 일부 N=1 결과는 방향성 참고용이라고 명시했고, 더 큰 N=5 재검증도 예정돼 있다.