프론티어 모델, 딱 한 번의 수정에만 쓰면 된다

보는 대로 따라한다! 🍌

• 97% 프런티어 모델 성능
• 41% 비용 절감
• 1.9× 빠른 완료
• ~3× 낮은 부정행위 가능성

/plan은 완벽히 납득이 간다. 사실은 그러면 안 되는데!

이 얘기, 한 번쯤 들어봤을 것이다. 직접 구현해봤을 수도 있다. 비싼 모델이 더 뛰어난 설계자인 건 분명하지만, 전체 파이프라인에 쓰기엔 낭비처럼 느껴진다. 그렇다면 '어려운 부분'만 맡기면 되지 않을까?

코드를 읽고, 깊이 생각하고, 정밀한 계획을 작성한다. 그다음엔 10분의 1 가격의 모델이 계획을 실행한다. 시니어 아키텍트와 주니어 엔지니어의 역할 분담이다.

그럴듯하지 않은가?

위에서 Opus 4.8 + /plan† 레이블이 붙은 빨간 점을 찾아보자. Opus가 읽기 전용으로 계획을 세우고, Gemini Flash가 구현한다: 작업당 $3.18, 12.7분, 통과율 84.6%.

인수인계 없이, 주니어 없이 Opus 단독으로 전체 작업을 처리하면: $2.78, 10.1분, 통과율 84.6%.

'비용 절감' 방식이 절감하지 않는 경우보다 14% 더 비싸다. 어?

실수는 아키텍처 다이어그램보다 앞단에서 발생한다. 사람들은 에이전트 비용을 사람 비용처럼 계산한다. 시니어의 시간은 비싸니, 시니어 참여를 최소화하라는 식으로.

하지만 에이전트에서 실제로 비용이 드는 부분은 수정도, 구현도, 심지어 추론도 아니다. Opus가 문제를 고치는 것은 돈이 들지 않는다. Opus가 코드를 읽는 것이 돈이 든다.

물론 일화적인 데이터지만, 토큰이 어디에 쓰였는지 분포를 살펴보자. 완전 자동화된 에이전트도 다를 게 없다.

토큰의 9%만이 편집에 쓰인다. 나머지는 모두 읽기다. 이 비율은 특정 하네스만의 특이점이 아니고, '고칠' 수 있는 문제도 아니다. 우리가 직접 시도해봤으니 믿어달라 — 그렇게 해서 snapcompact가 탄생했다.

어떤 에이전트든, 어떤 모델이든, 어떤 스캐폴드든: 비용은 본질적으로 O(reads)이다.

이를 염두에 두고, /plan을 선택하는 이유들을 하나씩 살펴보자:

• "큰 모델의 깊은 이해가 필요하다." 그 이해는 파일 읽기, 막힌 경로 제거, 가설 검증으로 쌓인 10만 토큰 이상의 맥락 속에 있다. 계획 문서는 그 맥락에서 뽑아낸 2천 토큰짜리 엽서에 불과하다. 실행 모델은 이해가 아닌 엽서만 받고, 나머지는 자신의 비용으로 다시 쌓아야 한다.
• "작업이 매우 복잡하다." 그렇다면 메인 에이전트가 아예 실행을 맡아선 안 된다. 읽기 전용 계획 턴 하나로는 해결되지 않는다. 먼저 탐색하게 하고, 서브 에이전트들에게 작업을 분배하라. 전화 전달 게임은 여기서 도움이 되지 않는다.
• "비용이 제한되어 있다." 비용의 핵심은 읽기다. /plan은 프런티어 모델이 프런티어 가격으로 모든 것을 읽게 하고, 경량 모델이 같은 내용을 다시 읽게 한다. 비싼 부분을 줄인 게 아니라, 두 배로 늘린 셈이다.

실제로 어떻게 보이는지, 우리가 너무 많은 시간을 쏟아부은 다이어그램으로 확인해보자:

상단 리본을 보라. Opus는 base.py, signing.py, 테스트 파일(스무 장의 회색 카드)을 읽은 다음 계획을 작성하고 나간다. 그 멋진 문서를 받은 Flash가 제일 먼저 하는 일은? base.py와 테스트 파일을 다시 읽는 것이다. 계획서는 파일이 아니고, 산문은 편집할 수 없기 때문이다. 회색 읽기 블록은 계속 쌓인다. 처음엔 Opus 가격으로, 그다음엔 Flash 가격으로. 두 번째 읽기가 비용 최적화가 되는 경우는 어디에도 없다.

동화책이 아닌 실행 궤적을 넘겨라

계획 문서는 그야말로 엽서다. 그 여정을 실제로 걷지 않은 모델에게 여행을 묘사해주는 엽서.

실제로 가치 있는 무언가를 전달할 수 있는 것은 바로 컨텍스트 윈도우 자체다:

/prewalk이 하는 일이 바로 이것이다:

1. 숨겨진 지시 하나를 앞에 붙여 프런티어 모델로 작업을 시작한다: 깊이 계획하고, 계획을 TODO 목록으로 정리한 다음, 시작하라.
2. 프런티어 모델이 탐색하고, 계획을 작성하고, TODO 목록을 초기화한다.
3. 첫 번째 편집이 이루어지는 순간(행동할 만큼 확신이 생긴 시점)에 경량 모델로 교체하고, 컨텍스트에서 계획 지시를 제거한다.

핵심은 이것이다:

• 경량 모델은 "잠깐, 우리 계획 단계 아니었나?"라고 의아해하지 않는다. 컨텍스트에 계획 지시가 남아있지 않기 때문이다.
• 경량 모델 입장에서는 자신이 직접 탐색하고, TODO 목록 형태로 종합적인 계획을 세운 다음, 자신 있게 실행을 시작한 것이다.
• 더 좋은 점은, 이미 유효한 첫 수를 두었다는 것이다! (컨텍스트 내 무료 예시)

이에 이르기까지

오픈소스 하네스 환경에서 작업하는 좋은 점 중 하나는, 다른 사람들이 어떻게 작업하는지 이야기를 나눌 수 있다는 것이다. 그리고 거의 모두가 완전히 다른 설정을 사용하고 있다.

어쨌든: 나는 쉬운~중간 난이도 작업을 프런티어 모델로 시작한 다음, 몇 번의 턴 후에 Kimi K27으로 전환하곤 했다. 평소의 사고 루프에 빠지지 않도록 하기 위해서였다. 이게 합리적인 방법인지 측정해볼 생각은 하지 않았는데... 다른 사람이 같은 방법을 쓴다고 언급하기 전까지는.

당연히 벤치마크를 해봐야 했다. 우리가 멍청한 건지, 실제로 효과가 있는 건지, 있다면 언제 효과적인지.

첫 번째 시도: 4번째 턴처럼 고정된 턴에서 교체. 돌이켜보면 명백히 나쁜 방법이다. 프런티어 모델이 4번째 턴에서 아직 헤매고 있을 때도 있고, 이미 전체 수정을 마친 경우도 있었다. 두 번째 시도: 첫 편집 후 교체. 모델이 제자리에서 자신의 스타일로 한 번 패턴을 보여준 셈이다. 꽤 좋은 방법이었지만, 여전히 까다로웠다. 경량 모델이 느닷없이 작업 완료를 선언하는 일이 반복됐다.

인터랙티브

해결책은 이 '무심결에 유도되는' 에이전트에게 계획을 단계별로 명확히 서술하도록 요청하고, 실행 준비가 되면 각 항목에 검증 단계가 포함된 TODO 목록을 초기화하도록 하는 것이었다. 그런 다음 에이전트가 코드를 편집하면, 그 순간이 교체를 트리거하는 시점이 된다.

편집 자체만으로 게이팅하는 건 충분하지 않다. TODO 목록은 여기서 여전히 매우 중요한 역할을 한다. 경량 모델은 계획이나 검증 단계, 심지어 지금 하고 있는 일까지 잊을 수 있지만, 끊임없이 따라붙는 TODO 알림만큼은 잊을 수 없다. 이것이 우리에게 무료 방향 제어 수단을 제공한다.

또 다른 재미있는 실패 사례도 있다. 가이드 역할의 GPT 5.6은 60개짜리 TODO 목록을 만들고 일괄로 완료 처리하는 걸 정말 좋아한다(뭐든 보상을 주는 건지). 그래서 프롬프트에 항목 수 제한은 필수다.

결과 영수증

GPT-5.6 Sol:

Sol 통과율의 97%를 61%의 비용으로 달성하며, 셋 중 가장 빠르다. Sol이 초반 이후로 느린 프런티어 토큰 소모를 멈추고, Luna는 헤매는 데 턴을 낭비하지 않기 때문이다.

Opus 4.8:

Opus 통과율의 92%를 53%의 비용으로, 1.5배 빠르게, 원샷 Flash 대비 +18점.

넘어가기 전에 한 가지 더. django-13279 테스트 실행의 리본으로 스크롤을 올려서, 없는 것을 찾아보자: 부정행위!

예상치 못한 효과

SWE-bench의 모든 작업은 수년 전 공개적으로 실제 수정된 버그다. 시험의 정답이 GitHub에 공개되어 있다.

아래는 웹을 뒤져 답을 찾으러 간 실행의 비율이다. 비열한 커닝꾼들!

같은 모델, 같은 스캐폴드, 거의 같은 아이디어인데 행동은 극적으로 다르다. /plan은 여전히 부정행위를 하는데, /prewalk는 왜 하지 않는 걸까?

우리가 내놓을 수 있는 최선의 설명: prewalk가 양쪽에서 굶긴다. 부정행위는 능력 있는 모델이 막다른 곳에 몰렸을 때 하는 행동이다. 단독 실행 기록을 보면 GitHub 탐색 턴은 탐색이 막히는 중반부터 시작된다. Sol은 14번째 턴 근처에서, Opus는 12번째 턴 근처에서 무너진다. prewalk는 프런티어 모델을 노력 예산의 시작 시점, 중간값 기준 약 7턴에 종료시킨다. 모델이 아직 접근법을 도출하고 첫 편집을 마친 시점(확신이 있는 단계)에, 구글링 단계가 시작되기 훨씬 전에 빠져나온다. /plan는 어느 쪽 자비도 받지 못한다. 턴 제한도 없고, 산출물(실제로 코드에 편집을 테스트해보지도 않은 채 수정이 어떻게 이루어져야 하는지 설명하는 종합 문서)은 정확히 절박함을 키우는 종류의 과제다.

그러면 실행 모델이 절박함과 정반대의 것을 물려받는다. 접근법이 이미 코드와 접촉해 살아남은 컨텍스트. 재현 코드가 작성되고, 첫 편집이 완료되고, 체크리스트가 돌아가고 있다. 그 컨텍스트에서는 검색처럼 보이는 것이 아무것도 없으므로, 모방 기계는 검색하지 않는다.

프리필이 걸어온 길, prewalk가 달려가다

전혀 새로운 아이디어가 아니다. 가장 오래된 트릭이다: 프리필(prefill). 어시스턴트가 원하는 대로 하지 않는가? 어시스턴트의 턴을 직접 시작하면, 모델은 그 말이 자신의 것인 양 이어간다.

이것은 문법 제약 디코딩이 등장하기 전 일관성 확보를 위한 꼼수로 시작됐다. omp를 비롯한 많은 곳에서 아직도 이를 활용한다. 세션 제목은 작은 로컬 모델이 생성하는데, 그 턴을 <title>으로 시작하면 더 잘 작동한다. 그 정도 크기의 모델은 형식을 설득해서 따르게 할 수 없지만, 속여서 따르게 하는 건 가능하다.

그러다 레드팀이 반대편 끝을 발견했다. "물론이죠, 방법은…"을 프리필하면 훨씬 더 큰 모델도 자신의 거부를 넘어간다. 모델에게는 자신이 한 말과 누군가 자신 입에 넣어준 말을 구분하는 채널이 없고, '이미 수락한 것'과의 일관성이 시스템 프롬프트를 이긴다. 프리필은 표준 탈옥 기법이 됐고, Anthropic이 Sonnet 4.5 IIRC부터 시작해 지금은 거의 모든 곳에서 추론 레이어에서 금지될 만큼 강력하다. JSON 모드와 구조화 출력이 합법적인 사용 사례를 대체하면서 프리필은 자취를 감췄다.

하지만 그 원리는 작동을 멈출 수 없다. 재미있는 특이점이 아니라, 자기회귀(autoregression)가 본질적으로 그런 것이기 때문이다. 이제 프런티어 모델에 프리필된 토큰 열 개를 넘길 수는 없다. 일부 모델은 아예 사고를 비활성화조차 못하게 한다. 악의적으로 턴을 프리필하지 못하도록 하기 위해서다(모델이 사고 중에, 어시스턴트 사고 블록이 없다는 점에서 이를 깨닫기를 바라면서). 하지만 순진하게 프리필된 턴 열 개를 넘기는 것은 아무도 막지 않는다. 이미 일어난 탐색, 체크 중인 TODO 목록처럼.

이를 omp에 업스트림했으며, 오늘부터 --prewalk, --prewalk-into <model>, 또는 간단히 /prewalk으로 제공된다. 어디서든 구현하기 어렵지 않으니, 써볼 기회가 생기면 어떻게 됐는지 꼭 알려달라!