EdgeWise가 긴 에이전트 작업의 핵심 단계만 클라우드로 넘긴다

무엇인가

이 논문이 다루는 문제는 긴 호흡의 에이전트 작업, 특히 코딩과 딥리서치에서 매 스텝마다 클라우드의 프런티어 LLM을 호출할 때 발생하는 추론 비용이다. 저자들은 모든 중간 단계가 같은 수준의 모델 능력을 요구하지는 않는다는 점에 주목한다. 기존 연구의 한계도 두 가지로 정리한다. 첫째, 대부분의 라우팅 방법이 단일 질의 추론이나 멀티홉 QA에서만 평가돼 실제 코딩·딥리서치 같은 장기 작업에서는 검증되지 않았다는 점(TwinRouterBench의 지적), 둘째, 미리 정의된 모델 풀 위에 학습된 별도 결정 모델에 의존하기 때문에 모델 풀이 바뀌면 결정이 신뢰를 잃을 수 있다는 점이다.

어떻게 동작하나

출발점은 무작위 위임 실험이다. 로컬 모델로 Qwen3.5-9B를, 클라우드 모델로 GPT-5.5(xhigh 추론)를 쓰고 궤적당 최대 80턴, Terminal-Bench 2.1과 SWE-Rebench, 하네스는 Terminus2와 OpenHands를 사용했다. 각 스텝 전에 정해진 확률로 위임 여부를 독립적으로 샘플링한 결과, 클라우드 비율이 40%일 때 무작위 배치에 따라 성능 편차가 크게 나타났다. 그런데 일부 배치는 전체를 클라우드로 돌린 것과 비슷한 성능을 내면서 비용을 최소 25% 줄였다. 즉 강한 모델을 얼마나 쓰느냐보다 궤적 위 어디에 배치하느냐가 더 중요하다는 관찰이다.

무엇과 다른가

어디에 배치할지를 찾기 위해 저자들은 코딩 에이전트 궤적 2.4k를 Write/Edit, Read/Search, Diagnose/Reproduce, Test/Validate, Discover/Navigate, Wait/Poll의 여섯 액션 타입으로 분류하고, 같은 벤치마크·태스크·위임 예산 그룹 안에서 중심화한 뒤 상관관계를 측정했다. Write/Edit의 클라우드 커버리지가 과제 성공과 가장 강하게 연관됐고 상관계수 0.200, 95% 신뢰구간 [0.099, 0.297]을 기록했다. Read/Search는 약한 양의 상관을 보였고 나머지 타입은 신뢰구간이 0을 포함했다. 성공한 궤적은 Write/Edit에 더 많은 클라우드 커버리지를 배분했는데, 그 격차는 Terminal-Bench 2.1에서 9.4%포인트, SWE-ReBench에서 5.6%포인트였다.

어떻게 쓰나

제안 프레임워크 EdgeWise는 로컬 SLM을 주 실행자로 두고 두 가지 위임 메커니즘을 쓴다. 하나는 외부 judge 기반 방식으로, GPT-5.4-mini가 매 스텝 궤적 이력 h_t를 보고 다음 스텝을 로컬로 처리할지 클라우드로 넘길지 이진 결정 a_t = J(h_t)를 내린다. 학습이 필요 없는 변형이다. 다른 하나는 self-delegation으로, SLM 자체가 과제 해결과 위임을 함께 학습한다. 1단계 SFT에서는 GPT-5.5가 생성한 해결 궤적에 위임 라벨을 붙여 형식 감독으로 쓴다. 이 라벨은 "반드시 위임해야 한다"는 정답이 아니라 위임을 유효한 행동으로 익히게 하는 용도다. 2단계 RL에서는 보상 R_i = V_i + I(V_i=1)·1/(1+λC_i)를 쓴다. V_i는 정답 여부, C_i는 LLM 호출 수이고 λ는 0.1로 두었다. 이 궤적 수준 항은 전체 위임량만 조절할 뿐 어느 스텝에 써야 하는지는 알려주지 않으므로, GPT-5.4-mini를 가벼운 critic으로 삼아 각 위임 결정에 스텝 수준 크레딧을 부여한다. 위임 토큰의 최종 어드밴티지는 A_t = A_traj + β(N_trajectory/N_route)·A_i^del로, 위임 토큰이 드물 때 스텝 신호가 희석되지 않게 스케일링한다. 클라우드가 생성한 토큰은 정책 손실에서 제외한다. 결과적으로 위임 횟수를 줄이는 동시에 클라우드 용량을 중요한 스텝에 집중시킨다.

전제와 한계

협업 설계 변수도 실험으로 비교한다. LLM에 넘길 컨텍스트는 전체 이력, 직전 스텝만, 최근 k턴(k=3), SLM 추론을 뺀 이력, 관련 스텝 선별의 다섯 가지를 비교했는데 전체 이력이 성능은 가장 좋지만 비용도 가장 컸고, SLM 추론을 제거한 방식이 상호작용 이력을 거의 보존하면서 두 번째 성능을 더 낮은 비용에 냈다. judge에는 전체 이력이 가장 좋았고, SLM의 현재 분석을 함께 주면 그 해석이 틀렸을 때 편향이 생겨 위임이 필요한 핵심 스텝을 놓칠 수 있었다. 호출 빈도는 이진 결정 대신 연속 위임 점수 s_t와 임계값 τ로 제어한다. τ가 낮으면 위임이 늘고 높으면 로컬 처리가 늘어나며, 검증셋에서 0.2~0.4 구간이 좋은 성능-비용 트레이드오프를 보였다.

학습은 SWE-Smith로, SLM은 Qwen3.5-9B, LLM은 Kimi-K3를 사용해 SFT 2K 예시에 이어 A100 80GB 40장에서 175스텝, 배치 8, 예시당 16롤아웃으로 RL을 돌려 EdgeWise-9B를 만들었다. 평가는 Terminus2 하네스로 Terminal-Bench 2.1과 SWE-ReBench-03에서 80턴 제한을 두고 진행했고, 베이스라인은 LLM-only, 무작위 위임, RSD, STEER, MTRouter였다. 클라우드 LLM은 GPT-5.5(xhigh) 또는 Bedrock 경유 Claude Opus 4.8을 썼다. self-delegation은 Pass@3 기준 비용을 SWE-ReBench에서 53%/63%, Terminal-Bench 2.1에서 35%/33% 줄이면서(GPT-5.5/Opus 4.8 순) LLM-only에 필적하는 성능을 유지했다. 초록 기준으로는 SWE-Rebench 최대 62%, Terminal-Bench 2.1에서 34% 절감이며, 서론은 모델과 벤치마크 전반에서 평균 46% 절감을 보고한다. Opus 4.8과 Terminal-Bench 2.1 조합에서는 Pass@1이 LLM-only에 뒤졌지만 Pass@3에서 동등해졌는데, 저자들은 SLM-LLM 협업이 과잉 사고를 완화하고 궤적 간 탐색 다양성을 높였을 가능성을 제시한다. 실제 배포 검증에서는 self-delegation 모델을 NVIDIA DGX Spark에 올리고 클라우드 LLM을 API로 호출해, A100 기반 평가와 비슷한 Pass@3 성능을 내면서 vanilla LLM 대비 약 50%의 비용 절감을 확인했다.

개발자 관점에서 이 논문이 주는 실무적 시사점은 명확하다. 에이전트 파이프라인 비용을 줄이려면 모델을 통째로 바꾸기보다 단계 단위로 개입 지점을 정하는 편이 효율적이며, 특히 코드 쓰기·편집 단계에 강한 모델을 몰아주는 전략이 근거를 갖는다. 또한 모델 전환 시 컨텍스트를 무작정 압축하면 성능이 떨어지고, 위임 판단을 내리는 주체에게 무엇을 보여주느냐가 위임 품질을 좌우한다는 점은 직접 구현할 때 그대로 적용되는 설계 지침이다. 다만 비용 계산은 클라우드 LLM API의 입력·출력 토큰 가격 기준이고 로컬 SLM 연산 비용은 제외되며, 이진 위임 방식에서는 judge API 비용이 포함된다는 전제를 확인해야 한다. 궤적 수준의 비용 항도 금전적 비용을 직접 최적화하는 것이 아니라 클라우드 호출량을 억제하는 정규화 항이라는 점, 그리고 SFT 라벨 생성과 critic에 각각 GPT-5.5와 GPT-5.4-mini를 사용한다는 점은 재현 시 고려할 조건이다.