연속 학습을 라우팅 문제로 재정의해 보상은 올리고 API 비용은 65% 줄인다

무엇인가

대규모로 배포된 에이전트는 서로 관련된 문제를 반복해서 만나지만, 매번 처음부터 시작한다. 서로의 경험을 공유하면 토큰 비용을 줄이고 성능을 올릴 수 있다. 문제는 '어떤 경험을 어떤 형태로 남기고, 어떤 인스턴스끼리 그 상태를 공유하게 할 것인가'다. 원문이 인용한 CL-Bench 결과에 따르면, 여섯 개 과제를 각각 따로 평가할 때는 특별한 메모리 시스템 없이 이전 대화를 그대로 붙이는 순수 ICL(Global ICL)이 전용 메모리 시스템보다도 강했다. 그러나 과제들을 하나의 스트림에 뒤섞으면 이야기가 달라진다. 하나의 거대한 이력은 A 과제에는 유용하지만 B 과제에는 무관한 경험을 섞어버리고, 반대로 하나의 고정된 요약으로 압축하면 비용은 줄지만 세부 정보를 잃는다. 저자들은 이 문제를 '표현 방식 선택'이 아니라 '라우팅 문제'로 재정의한다. 즉 매 인스턴스마다 (1) 경험을 어떻게 표현할지(메모리 시스템 선택)와 (2) 어떤 인스턴스들이 상태를 공유할지(클러스터 선택)를 동시에 결정하는 문제로 본다.

어떻게 동작하나

시스템은 네 가지 요소로 구성된다. 첫째, LLM 라우터는 인스턴스 하나가 들어올 때마다 에이전트 실행 전에 구조화 출력 호출 한 번을 수행한다. 라우터가 보는 것은 현재 문제의 자연어 프롬프트와 요구 응답 스키마, 각 메모리 시스템의 학습 동작 설명, 그리고 존재하는 클러스터마다의 식별자·메모리 시스템 종류·불변 설명·완료된 궤적 수뿐이다. 원본 궤적이나 메모리 시스템 내부 상태, 이전 라우팅 호출의 숨은 대화 상태는 볼 수 없다. 라우터는 학습되지 않고 프롬프트로만 구동되며, 태스크 레이블이나 보상은 받지 않는다. 둘째, 클러스터는 하나의 메모리 시스템이 상태를 유지하는 격리된 인스턴스다. 클러스터 c가 시스템 m으로 구성되면, 인스턴스 x_t에 대해 z_t = read_m(S_c,t, x_t; θ_c)로 에이전트 컨텍스트에 넣을 텍스트를 만들고, 실행 후 S_c,t+1 = update_m(S_c,t, τ_t; θ_c)로 상태를 갱신한다. 여기서 S는 클러스터 상태, θ_c는 클러스터별 설정, τ_t는 프롬프트·모델 행동·도구 출력·피드백을 담은 궤적이다. 선택된 클러스터만 갱신되고, read/update는 원자적으로 취급된다. 라우팅 결정은 인스턴스 실행 중에는 바뀌지 않는다.

무엇과 다른가

셋째, 메모리 시스템 라이브러리는 평가 전에 고정된 다섯 개로, 세 가지 표현 계열을 아우른다. 순수 ICL은 프롬프트·응답·피드백을 순서대로 쌓고 컨텍스트 한계에서만 오래된 메시지를 버린다. ReasoningBank 적응판은 궤적이 끝날 때마다 같은 백본 모델이 성공/실패를 판정하고 재사용 가능한 전략이나 실패 회피 교훈을 최대 3개까지 구조화 메모리 항목으로 추출하며, 이후 인스턴스에서 가장 유사한 과거 요청에 연관된 메모리를 검색해 주입한다(숨은 보상 없음, 고정 로컬 임베딩 사용, 테스트 시 확장 기법은 미사용). 나머지 셋은 수치 상태를 모델링하는 시스템으로, PyMC 기반의 Hierarchical Regression과 Hierarchical Discrete-Event State, River의 베이지안 선형회귀를 쓰는 Persistent-Entity State다. 이들 통계 라이브러리에는 CL-Bench 과제 이름이나 과제별 필드, 프롬프트, 채점 로직이 들어가지 않으며, 과제 의미는 어댑터 바인딩을 통해서만 유입된다. 넷째, Context Memory Adapter는 과제 스키마와 일반 상태 사이의 클러스터별 어댑터 설정 θ_c를 이전 실행 경험에서 유도하고, 첫 액터 턴 이전에 예산이 제한된 조언을 원래 프롬프트 옆에 주입한다. 이 어댑터는 환경에서 행동하거나 답을 제출하지 않으며, 숨은 테스트나 평가 보상에 접근하지 못한다. 메모리는 오직 컨텍스트를 통해서만 행동에 영향을 준다.

어떻게 쓰나

실험은 CL-Bench의 여섯 과제 301개 인스턴스와 τ³-Bench의 Banking Knowledge 97개 인스턴스를 무작위로 섞어 만든 398개 인스턴스 스트림에서 이뤄졌다. 각 소스 과제의 고유 순서는 유지하고, 동일한 5개 롤아웃을 모든 조건이 공유한다. 비교 조건은 단계적으로 능력을 추가한다. Stateless ICL(인스턴스마다 초기화), Global ICL(스트림 전체에 하나의 이력), Routed ICL(LLM 라우터가 ICL 이력들을 클러스터로 분할), Routed CL(다섯 개 메모리 시스템까지 선택). 모든 ICL 이력은 100K 토큰 컨텍스트 예산을 쓰며, Global은 스트림 전체에, 라우팅 조건은 클러스터마다 독립 적용된다. 모델은 Claude Opus 4.7, Claude Opus 5, GPT-5.6 Sol, Gemini 3.7 Flash 네 개이고, 액터와 라우터·어댑터 구성기·추출기·ReasoningBank 판정자 등 모델이 관여하는 모든 역할에 같은 모델을 쓴다. 별도로 ReasoningBank를 고정 시스템으로 쓰는 Global RB와 Routed RB 비교(3개 롤아웃), 소스 과제 정체를 아는 진단용 Ground-truth assignment도 평가한다. 지표는 정규화 보상(CL-Bench의 외부 stateless 기준선이 0, 과제 최대가 1, 기준선 미만은 음수; τ³-Bench는 자체 [0,1] 보상, 일곱 과제 동일 가중)과 stateless-reference gain, 그리고 토큰 캐싱을 반영한 고정 가격표로 추정한 API 비용이다.

전제와 한계

핵심 결과는 이질적 인터리빙에서 Global ICL의 우위가 사라진다는 것이다. 평균 stateless-reference gain은 Global ICL 0.015에서 Routed ICL 0.222, Routed CL 0.280으로 올라간다. Routed ICL은 Global ICL보다 모델별로 정규화 보상 0.117~0.241점 높고, Routed CL은 여기에 0.002~0.076점을 더 얹는다. Gemini의 평균 개선은 0.002로 작지만 5개 롤아웃 중 4개에서 양수다. 반면 ReasoningBank를 클러스터로 라우팅하는 것은 일관된 보상 이득이 없고 평균 비용을 8~29% 높였다. 저자들은 ICL은 클러스터 이력 전체를 노출하는 반면 ReasoningBank는 이미 요청 유사도로 선택적으로 검색하기 때문일 수 있다고 본다. 과제 수준에서는 Routed CL이 모든 모델에서 Cohort와 τ³-Bench, 4개 중 3개 모델에서 Spectrum의 Routed ICL 성능을 넘었고, Sales에서는 Opus 5가 비용을 0.34배로 줄이면서 보상을 사실상 유지했다. 라우팅이 실제로 옳은 결정을 하는지도 측정했다. 20개 모델-롤아웃 조합에서 라우터는 소스 과제 기준 86%에서 같은 메모리 시스템을, 91%에서 같은 클러스터 분할을, 79%에서 둘 다 독립적으로 선택했다. 소스 과제 정체를 알려주는 Ground-truth assignment로 라우터를 교체하면 정규화 보상은 Opus 5에서 0.008, GPT-5.6 Sol에서 0.014밖에 오르지 않지만, Opus 4.7과 Gemini 3.7 Flash에서는 각각 0.069, 0.071 올라간다. 불일치는 Gemini와 Opus 4.7이 Code에서 ReasoningBank를 ICL 대신 자주 고르는 경우, Gemini가 Sales에서 계층적 회귀를 전혀 고르지 않는 경우에 집중됐고, 이 지점에서 Routed CL이 Routed ICL보다 뒤처지기도 한다. 비용 면에서 Routed CL은 모든 모델의 경험적 보상-비용 파레토 프론티어에 놓인다. Global ICL보다 65~72% 낮은 비용으로 더 높은 보상을 내고, 세 모델에서는 Routed ICL보다도 25~33% 저렴하다. Opus 4.7만 예외로 Routed ICL보다 5% 비싸면서 보상은 0.034 높다. Global RB와 비교하면 31~44% 높은 비용으로 0.189~0.358점의 보상을 더 얻고, 모든 모델에서 Routed RB보다 높은 보상을 낸다.

실무적으로 이 논문이 주는 신호는 명확하다. 에이전트 메모리를 '하나의 누적 로그'로 설계하면 과제가 섞이는 순간 이득이 사라질 수 있다는 것, 그리고 라우팅은 별도 학습 없이 프롬프트만으로도 상당히 정확하게(79% 수준) 동작한다는 것이다. 특히 라우터에게 원본 궤적이나 내부 상태를 보여주지 않고 클러스터 요약과 메모리 시스템 설명만 주는 인터페이스는, 사내 여러 팀이 만든 에이전트를 건드리지 않고 프롬프트 가로채기 훅만으로 기억을 주입하는 배포 방식과 잘 맞는다. 다만 도메인 특화 메모리(예: 시계열 회귀)를 넣을 때는 어댑터가 스키마 바인딩만 하도록 경계를 강제해야 하고, ReasoningBank처럼 이미 선택적 검색을 하는 시스템에 클러스터링을 덧붙이는 것이 비용만 늘릴 수 있다는 점도 확인해야 한다.

저자들이 명시한 한계도 분명하다. 모든 실험은 인스턴스를 순차적으로 처리하며, 각 롤아웃에서 액터와 모든 모델 기반 메모리 역할에 하나의 언어 모델만 쓴다. 아키텍처가 클러스터 상태 격리와 원자적 읽기/쓰기를 정의하긴 하지만, 동시 갱신이나 오래된 읽기(stale read), 서로 다른 모델 간 클러스터 상태 재사용은 평가하지 않았다. 이는 분산 배포에서 반드시 검증해야 할 항목으로 남겨져 있다. 또한 메모리 시스템 라이브러리는 탐색적 개발 단계에서 CL-Bench 위에서 고르고 확증 평가 전에 동결한 것으로, 새로운 메모리 표현 계열을 합성하는 능력이 아니라 고정 라이브러리 안에서의 선택과 설정을 검증한 것이다. 향후 과제로는 한 인스턴스에서 여러 클러스터를 읽거나, 하나의 궤적으로 여러 클러스터·표현을 갱신하는 richer interaction을 비용과 간섭을 통제하면서 연구하는 것을 제안한다. 한편 윤리 진술에서 저자들은 경험 풀링이 개별 에이전트를 넘어서는 능력을 집단에 부여할 수 있고, 영속 상태가 민감·오류·적대적 정보를 전파할 수 있으므로 권한, 출처 추적, 보존·삭제 정책, 보안 경계 격리가 필요하다고 경고한다.