Opus보다 저렴하게 Fable 활용하기

Opus 4.8을 Fable 5로 교체했더니 Devin의 비용이 줄었습니다.

Fable 5는 토큰당 비용이 Opus 4.8의 두 배입니다. 하지만 두 모델을 새로운 Fusion 아키텍처로 FrontierCode 1.1에서 실행했을 때, Fable의 비용이 더 적게 들었습니다. 당연히 점수도 더 높았습니다. 이 글은 그 이유와 이것이 에이전트 작업의 가격 책정에 의미하는 바를 설명합니다.

소개

코딩 에이전트를 운영하는 사람이라면 누구나 더 강력한 모델이 더 나은 결과를 제공하지만, 그만큼 비용이 발생한다는 것을 알고 있습니다.

Devin Fusion을 소개할 때 우리는 해결책을 제시했습니다: 최첨단 모델이 주도권을 쥐고, 더 저렴하고 빠른 조수에게 작업을 위임하게 하면 최첨단 수준의 성능을 35% 낮은 비용으로 얻을 수 있습니다.

하지만 리드 모델이 대부분의 작업을 위임한다면, 토큰당 가격이 여전히 비용을 좌우할까요? Fable 5는 토큰당 비용이 Opus 4.8의 2배이므로, Fable이 주도하는 에이전트의 비용이 더 많이 들어야 합니다. 이를 확인하기 위해 우리는 FrontierCode 1.1에서 3,000개의 평가 세션을 네 가지 구성으로 실행했습니다: Fable과 Opus가 각각 리드 역할을 맡고, 각각 동일한 저렴한 조수를 사용하거나 사용하지 않았습니다.

순수 실행 결과는 직관과 정확히 일치합니다: Fable이 Opus를 점수에서 앞서고(60.8 vs 55.4) 비용도 더 많이 듭니다. 더 좋은 모델, 더 큰 비용입니다.

조수를 사용한 실행에서 흥미로운 점이 드러납니다.

동일한 조수를 사용할 때 비용 순서가 반전됩니다: Fable + 조수가 Opus + 조수보다 비용이 적게 들면서($1.86 vs $2.04) 점수는 더 높습니다(60.7 vs 54.6). 순수 Fable과 비교하면 Fable + 조수는 비용을 54% 절감하면서 점수는 거의 그대로 유지합니다.

토큰당 2배 프리미엄은 사실 잘못된 지표였습니다. 에이전트의 비용은 리드 모델이 몇 번의 턴을 수행하는지, 얼마나 많은 컨텍스트를 끌어오는지, 그리고 무엇보다도 스스로 하지 않기로 결정하는 것이 무엇인지에 의해 결정됩니다. 그 차이는 관리 스타일에서 비롯됩니다: Opus는 인턴과 함께하는 마이크로매니저처럼 행동하고, Fable은 유능한 엔지니어와 함께하는 매니저처럼 행동합니다.

설정

Fusion의 조수 아키텍처가 어떻게 작동하는지 간단히 복습해 보겠습니다. 리드 에이전트가 세션을 소유합니다: 사용자와 대화하고, 계획을 세우고, 작업을 검토하고, 커밋합니다. 또한 작업을 위임하기 위한 지속적인 조수 하위 에이전트가 있습니다. 리드는 일반 언어로 핸드오프 브리핑을 작성하고, 훨씬 저렴한 모델로 구동되는 하위 에이전트가 자체 컨텍스트에서 이를 수행하고 보고합니다. 리드는 결과를 검토하고 다음에 무엇을 할지 결정합니다.

비용이 어디서 발생하는지 알아보기 위해 두 가지 작업을 수행했습니다. 첫째, 3,000개 세션 전체에서 모든 LLM 호출을 분석했습니다: 어떤 모델이 말했는지, 어떤 도구를 호출했는지, 몇 개의 토큰을 읽고 썼는지, 각 호출의 비용은 얼마인지. 둘째, 자세히 살펴볼 40개의 작업을 선정했습니다: Fable이 훨씬 저렴했던 작업, Opus가 저렴했던 작업, 그리고 중간에서 무작위 샘플을 더했습니다. 각 작업에 대해 Fable이 주도한 실행과 Opus가 주도한 실행을 나란히 분석하고, 궤적을 조사하여 비용이 어디에 사용되었는지 관찰했습니다.

에이전트의 비용

실험에서 리드와 조수 간 비용 분할은 다음과 같습니다.

Fable은 Opus보다 조수에 더 많은 비용을 지출합니다 — 실행당 $0.27 더 많습니다. 하지만 자신에게는 $0.45 덜 지출합니다. Fable의 리드는 실행당 11.5턴을 사용하는 반면 Opus는 26.5턴을 사용하며, 출력 토큰은 1/3(6.1k vs 19.0k), 입력 토큰도 1/3을 소비합니다. Fable은 토큰당 훨씬 비싸지만, 컨텍스트 관리와 턴 수에서 우위를 점합니다.

Fable의 토큰 절감은 작업을 아예 회피함으로써 발생합니다. 흥미롭게도 Fable이 주도한 실행의 81%에서 리드는 단 한 번도 코드 편집을 하지 않습니다. Opus의 경우 실행의 24%만 그렇습니다. Fable이 주도한 실행의 13%에서는 리드가 저장소 파일을 한 번도 읽지 않습니다.

인턴과 함께하는 마이크로매니저 vs 엔지니어와 함께하는 매니저

이 차이가 흥미로운 이유는 다음과 같습니다: 두 리드는 동일한 횟수로 위임합니다, 실행당 약 3회의 핸드오프입니다. 호출별 로그는 Fable이 단순히 더 많이 위임한다는 쉬운 설명을 반박합니다. 차이는 언제 그리고 무엇을 위임하는지에 있습니다. Fable의 첫 번째 핸드오프는 일찍 발생합니다. Opus는 종종 긴 탐색과 구현 세션 후에 늦게 위임합니다. 그때쯤이면 설계 결정이 이미 내려지고 중요한 파일이 컨텍스트에 들어와 있으며, 값비싼 작업은 이미 완료된 상태입니다.

GIF

일반적인 Fable 주도 실행은 저장소에 대한 몇 번의 정찰 작업을 수행한 후, 구현 + 테스트 + 린트 루프 전체를 위임하는 스펙 수준의 브리핑 하나를 작성합니다. 그런 다음 git show 한 번으로 diff를 검토하고 커밋합니다.

일반적인 Opus 주도 실행은 20~45턴의 단독 탐색, 설계 및 구현을 거치며, 기계적인 꼬리 부분을 위해 늦은 핸드오프 한 번을 수행합니다.

때로는 Fable의 세션 첫 번째 작업이 핸드오프입니다. 동일한 작업에서 두 리드는 다음과 같이 시작했습니다:

명백한 해결책은 Opus가 더 많은 탐색을 위임하도록 만드는 것이지만, 그러한 행동을 강제하면 성능이 저하되는 경향이 있습니다. 언제 조사가 위임해도 안전하고 언제 직접 수행해야 하는지를 아는 것은 그 자체로 판단력입니다. 위임하도록 강요받은 모델은 그 판단력을 얻지 못합니다. 단지 잘못된 것들을 위임할 뿐입니다.

각 모델의 관리 스타일은 핸드오프 브리핑 자체에서도 드러납니다. Opus가 구현을 위임할 때는 지시하는 반면, Fable은 설계 문서를 작성합니다:

위임은 비용을 이동시킬 뿐만 아니라 작업의 품질도 변화시킵니다. 위의 해싱 작업은 극명한 예입니다. 작업 사양은 해시 함수가 포인터 길이에 대해 O(1)이어야 한다고 요구했습니다. Opus는 직접 구현했으며 그 요구 사항을 어디에도 기록하지 않았습니다. 어느 시점에서 제약 조건을 잊어버리고 선형 시간 구현을 출시하여 25점을 받았습니다. 반면 Fable은 높은 수준의 제약 조건을 사용하여 위임했습니다. 브리핑에는 "operator()는 포인터 길이에 대해 O(1)이어야 함: 전체 토큰 스캔 금지"라고 명시되어 있었습니다. 조수는 이를 성공적으로 구현하여 94점을 받았습니다.

우리는 이 패턴이 작업 전반에 걸쳐 일반화됨을 발견했습니다. Fable의 핸드오프는 제약 조건, 엣지 케이스, "완료"의 정의를 열거하여 노력을 절약하면서도 조수가 저렴하고 정확하게 구현을 완료할 수 있도록 했습니다.

핸드오프 후

나머지 절반은 리드 에이전트가 조수로부터 돌아온 작업을 어떻게 처리하는지입니다. 두 리드 모두 종종 동일한 저렴한 검사를 실행합니다: 두세 번의 git diff/git show 호출입니다. 하지만 Opus는 거기서 멈추지 않습니다. 조수의 파일을 자체 컨텍스트로 다시 가져오는 횟수가 2배 더 많고, 리드 가격으로 수정 편집을 하는 횟수가 4배 더 많습니다. 극단적인 경우, 조수의 작업을 되돌리고 직접 다시 작성했습니다:

Opus의 불신은 정확성을 높이지도 않습니다. 일부 평가 작업에서 Fable의 단일 diff 검토가 실제 조수 버그를 발견했고, Opus가 자주 사용하는 리드 수준의 재작성 대신 또 다른 저렴한 핸드오프를 선택했습니다.

위임이 도움이 되지 않는 경우

Fable의 위임 전략이 항상 유용한 것은 아닙니다. 위임할 수 있는 구성 요소가 없는 작업에서는 실패합니다. 다음 유형의 작업은 분해하기 어려워 보였습니다:

• 결정과 출시 사이에 위임할 것이 없는, 몇 번의 리드 모델 턴만 포함된 짧은 작업.
• 근본 원인 추적이 긴 판단 체인으로 이어지는 직렬 디버깅 작업. 여기서 축적된 컨텍스트는 그 자체가 작업입니다.

특히, 이러한 작업에서 Fable은 거의 위임하지 않습니다. 좋은 브리핑을 작성하는 동일한 판단력이 언제 브리핑을 작성하지 말아야 하는지도 알고 있습니다. 하지만 작업에 위임할 가치가 있는 것이 없으면 위임은 비용에 대한 레버리지를 갖지 못합니다.

프로덕션에서 Fusion은 이를 다른 계층에서 처리합니다: 위임은 값비싼 모델이 어떤 작업을 맡을지 제어하고, 라우팅은 값비싼 모델이 전혀 관여할지 여부를 결정합니다.

마무리

우리는 이 실험을 시작할 때 Fable의 2배 프리미엄이 비용을 얼마나 증가시킬지 측정할 것으로 예상했습니다. Fable의 효과적인 위임이 실제로 전체 비용을 감소시킨다는 사실에 놀랐습니다. Fable은 구현을 구체화하는 대신 제약 조건과 결과를 명시하고, 직접 수정하는 대신 피드백을 제공했으며, 대부분의 경우 코드를 전혀 건드리지 않았습니다. 이는 좋은 매니저의 습관입니다.

조수 모델이 더 저렴해지고 좋아짐에 따라 더 많은 작업을 그들에게 넘길 수 있습니다. 최첨단 가격을 유지할 가치가 있는 것은 판단력입니다: 무엇을 구축할지, 무엇을 제약할지, 그리고 누가 그것을 작성해야 할지.