기술 요약: 에이전트 워크플로우를 LLM 가중치로 컴파일하기

문제 제기

에이전트 오케스트레이션 프레임워크 (예: LangGraph, CrewAI, OpenAI Agents SDK) 가 급증하여 총 290,000 개 이상의 GitHub 스타를 기록했습니다. 이러한 시스템은 대형 언어 모델 (LLM) 위에 위치하는 외부 오케스트레이터에 의존하여, 매순간 지시를 주입하고 라우팅 결정을 내립니다. 최근 연구에 따르면 절차적 작업의 경우, 프론티어 모델의 시스템 프롬프트에 전체 절차를 제공하는 것 (인-컨텍스트 프롬프팅) 이 오케스트레이션보다 더 나은 성과를 보인다고 하지만, 이 접근법은 세 가지 치명적인 한계를 안고 있습니다:

1. 비용: 모든 대화마다 프론티어 모델이 필요하며, API 호출마다 절차를 내포함으로써 토큰 소비를 급증시킵니다.
2. 컨텍스트 창: 상당한 컨텍스트 창 용량을 소모합니다.
3. 개인정보 보호: 독점적 절차를 제 3 자 제공업체에 노출시킵니다.

대안인 절차 를 소형 파인튜닝 모델의 가중치로 컴파일하는 것 ( "지하 에이전트" 생성) 은 이전 학술 연구 (예: SimpleTOD, FireAct, SynTOD) 에서 탐구되었으나 개발자 채택률은 낮았습니다. 본 논문은 채택을 저해하는 것으로 인식되는 세 가지 장벽을 식별합니다: 품질(소형 모델이 프론티어 모델과 경쟁할 수 있는가?), 비용(자체 호스팅이 실제로 더 저렴한가?), 그리고 유연성(재학습이 과도하게 느린가?).

방법론

저자들은 오케스트레이터를 훈련 데이터 생성 시에만 사용하고 런타임에는 사용하지 않는 "지하" 아키텍처를 제안합니다. 파이프라인은 다음과 같습니다:

1. 절차 정의: 워크플로우를 노드 (에이전트/사용자 턴) 와 엣지 (전이) 를 가진 방향성 그래프 ($F = (N, E, n_0, T)$) 로 표현합니다.
2. 합성 데이터 생성: 프론티어 모델 (Claude Sonnet 4.5) 을 사용하여 플로우차트의 모든 유효한 경로를 탐색하며 합성 대화를 생성합니다. 모델은 노드 프롬프트 템플릿과 전체 대화 기록을 기반으로 턴별 대화를 생성합니다.
3. 전체 파라미터 파인튜닝: 저자들의 이전 연구 [Dennis et al., 2026b] 에서 절차적 내면화에 불충분하다고 밝혀진 LoRA 와 같은 저랭크 방법을 배제하고, 합성 대화를 기반으로 소형 모델 (3B 및 8B 파라미터) 을 전체 파라미터 업데이트로 파인튜닝합니다.
4. 런타임 배포: 컴파일된 모델은 외부 오케스트레이터 없이 실행되며, 최소한의 시스템 프롬프트만 받습니다. 절차는 모델의 가중치에 암묵적으로 내재됩니다.

평가 설정:
본 연구는 복잡도가 증가하는 세 가지 도메인을 평가합니다:

• 여행 예약: 14 개 노드, 3 개 의사결정 허브, 86 개 고유 경로.
• Zoom 지원: 14 개 노드, 병렬 구조, 제품별 지식 (UI, 오류 코드) 필요.
• 보험 청구: 55 개 노드, 6 개 의사결정 허브, 2,381 개 고유 경로, 확장성 테스트.

베이스라인:

• LangGraph 오케스트레이터: 명시적 플로우차트 기반 상태 추적을 사용하는 Claude Sonnet 4.5(프론티어 모델 베이스라인).
• 인-컨텍스트 베이스라인: 시스템 프롬프트에 직렬화된 플로우차트를 포함하는 Claude Sonnet 4.5.
• 동일 모델 오케스트레이터: 명시적 오케스트레이션을 사용하는 3B 모델 (컴파일 효과를 분리하기 위해 사용).

지표:
LLM-as-a-judge 접근법 (Claude Sonnet 4.5 및 GPT-4.1) 을 사용하여 대화의 작업 성공, 정보 정확도, 일관성, 우아한 처리, 자연스러움을 1~5 점 척도로 평가합니다.

주요 결과

1. 품질

• 컴파일 vs. 동일 모델 오케스트레이션: 여행 작업에 대한 통제된 비교 결과, 3B 컴파일 모델이 3B 명시적 오케스트레이션 모델보다 다섯 가지 지표 중 네 가지 (작업 성공, 일관성, 우아한 처리, 자연스러움; $p < 0.001$) 에서 현저히 우수한 성과를 보였습니다.
• 소형 모델 vs. 프론티어 오케스트레이터:
  • 여행 (3B): 3B 컴파일 모델은 작업 성공과 일관성 측면에서 LangGraph 오케스트레이터와 맞먹었으나, 우아한 처리와 자연스러움 측면에서는 뒤처져 인-컨텍스트 품질의 약 82% 수준에 도달했습니다.
  • Zoom 및 보험 (8B): 8B 모델로 확장하면 격차가 해소되었습니다. 8B 컴파일 모델은 인-컨텍스트 프론티어 베이스라인 품질의 **87–98%**를 달성했습니다. 보험 청구 작업에서는 약 70 배 더 큰 모델을 기반으로 구축된 LangGraph 오케스트레이터보다 우아한 처리와 자연스러움 측면에서 더 나은 성과를 보였습니다.
• 실패율: 컴파일된 모델은 여행 (5.5% 대 24%) 및 보험 (9% 대 17%) 에서 LangGraph 오케스트레이터보다 낮은 실패율을 보였는데, 이는 노드 수준 오케스트레이션에 내재된 라우팅 오류를 제거했기 때문입니다.

2. 비용

컴파일된 모델은 인-컨텍스트 베이스라인보다 대화당 128–462 배 더 저렴합니다.

• 토큰당 감소: A100 과 같은 상용 하드웨어에서 8B 모델을 자체 호스팅하는 것은 프론티어 API 요금 대비 토큰당 약 65 배 더 저렴합니다.
• 토큰 볼륨 감소: 인-컨텍스트 베이스라인은 모든 프롬프트에 전체 절차를 포함해야 하므로 복잡도에 따라 오버헤드가 2 배에서 7 배까지 증가합니다. 반면 컴파일된 모델의 프롬프트 크기는 일정합니다.
• 손익분기점: 일회성 컴파일 비용 (~50–80 달러) 은 500 회 대화 내에서 회수됩니다.

3. 유연성

재컴파일 주기 (데이터 생성, 파인튜닝, 평가) 는 생산 하드웨어 (8× H200) 에서 30–50 분이 소요되거나 단일 A100 에서 3–4 시간입니다. 이는 표준 CI/CD 빌드 주기와 유사하며, 재학습이 패러다임을 바꾸는 과도하게 긴 노력이라는 가정을 반증합니다.

중요성과 주장

본 논문은 에이전트 워크플로우 컴파일에 대한 인식된 장벽이 일반적으로 가정된 것보다 작다고 주장합니다:

• 품질 격차: 컴파일된 8B 모델과 프론티어 인-컨텍스트 베이스라인 간의 격차는 작으며 (87–98%), 컴파일된 모델은 종종 LangGraph 를 통해 오케스트레이션된 프론티어 모델을 능가합니다.
• 비용 격차: 비용 우위는 두 자릿수 (100 배 이상) 에 달하며, 컴파일된 모델의 프롬프트 크기는 일정하게 유지되는 반면 인-컨텍스트 프롬프트는 커지므로 절차 복잡도가 증가함에 따라 더욱 커집니다.
• 유연성 격차: 적응은 재학습 병목 현상이 아닌 배포 주기 (CI/CD) 입니다.

저자들은 한 번의 대화 컨텍스트를 넘어 지속성이 필요한 절차적 지식에 대해 **"지속적인 구조는 가중치에, 일시적인 상태는 프롬프트에 속한다"**고 결론지었습니다. 컴파일은 절차적 작업에 대한 자연스러운 해결책으로 제시되며, 외부 오케스트레이션의 구조적 실패 모드 (단편화된 추론, 라우팅 오류, 제한된 대화 스타일) 를 피하면서 비용과 지연 시간의 일부로 프론티어 수준의 품질을 제공합니다.