에이전트가 스스로 만든 과제로 재사용 메모리를 부트스트랩한다

무엇인가

LLM 에이전트는 새로운 환경에 투입되면 특정 도구의 동작 방식이나 환경 관례를 스스로 알아내야 한다. 과거 시도의 기억이 없으면 같은 실수를 반복하고, 그만큼 작업 실패가 늘고 궤적이 길어진다. 기존 해법은 사람이 쓴 가이드라인에 의존하거나, 학습 과제와 오라클 검증기로 절차적 메모리를 구축한다. 둘 다 환경에 대한 사전 지식을 요구하므로, 사람의 감독 없이 자동 생성되는 에이전트 환경에서는 쓸 수 없다. 테스트 시점의 질의로부터 경험을 모으는 방법도 있지만, 첫 과제들은 메모리 없이 처리해야 하고 실패한 뒤에야 개선된다.

어떻게 동작하나

DAEDALUS는 학습 과제도 오라클 검증기도 없이 자기 생성 과제로 환경 특화 메모리를 만드는 학습 불필요(training-free) 방법이다. 두 에이전트를 짝지운다. Explorer는 환경과 상호작용하며 풀 수 있으면서도 도전적인 과제를 제안하고, Solver는 그 과제를 시도한다. 과제는 지시문과 명시적 성공 조건으로 구성되며, LLM Judge가 Solver의 궤적을 성공 조건과 대조해 채점한다. 시도가 실패하면 Extractor가 지시문과 실패 궤적만 보고 휴리스틱을 작성하거나 이전 실패 후 작성한 휴리스틱을 수정하고, Solver는 그 휴리스틱을 컨텍스트에 넣고 재시도한다. Extractor는 어떤 성공 조건을 놓쳤는지 보지 못하게 해서, 과제 특화 임시방편보다 일반화 가능한 지침이 나오도록 유도한다. 루프는 Solver가 연속 3회(N_s=3) 성공하거나 총 8회(N_f=8) 실패하면 멈춘다. 이때 결과는 세 갈래다. 연속 성공 전에 최소 한 번 실패했다면 휴리스틱이 채택되고, 한 번도 실패하지 않았다면 과제가 너무 쉬운 것이고, 8회 실패에 도달하면 너무 어려운 것이다.

무엇과 다른가

과제 난이도는 Solver에 맞춰 보정된다. Explorer는 환경과 상호작용해 현실적인 과제를 제안하고 직접 완수해 실행 가능성을 확인한다. 채택된 과제만 휴리스틱을 낳으므로 Solver 루프의 결과 자체가 난이도 신호가 되고, 너무 쉽거나 어려우면 Explorer가 이전 시도와 함께 그 결과를 받아 최대 5회(N_r=5)까지 과제를 수정한다. 수정을 다 소진한 세션은 휴리스틱을 남기지 않는다. 생성 비용을 줄이는 장치도 있다. 첫 세션 전에 Surveyor가 환경을 한 번 탐사해 영역별 목표 과제 분포를 정하고 Explorer가 이를 따르게 해 커버리지를 다양화한다. 또한 수정이 필요했던 세션마다 그 이력을 지침으로 바꿔 이후 세션의 난이도 보정을 돕는다. 마지막으로 Consolidator가 채택된 휴리스틱들을 LLM 호출 한 번으로 병합해 중복·겹침을 제거한 메모리 뱅크를 만들고, 이 뱅크는 동결되어 각 테스트 과제 시작 시점에 한 번 주입된다.

어떻게 쓰나

실험은 AppWorld(코드 기반 앱 자동화), τ²-bench(대화형 고객 서비스, 정답 오류가 있는 airline과 사용자 측 도구 시뮬레이션이 필요한 telecom을 제외한 retail 도메인), AutomationBench(Operations 분할)에서 수행했다. 학습/테스트 분할은 AppWorld 90/168, τ²-bench retail 74/40, AutomationBench 100개를 30/70으로 계층화한 것이다. 학습 과제 수에 맞춰 학습 과제당 생성 세션 하나를 돌렸고, 보조 에이전트에는 큰 모델(GPT-5.4, AutomationBench에서는 GPT-5.6 Terra), Solver와 베이스 에이전트에는 작은 모델(GPT-5.4-mini, GPT-5.6 Luna)을 썼다. 결과적으로 DAEDALUS는 무메모리 베이스라인 대비 평균 성공률(MSR)을 AppWorld 15.9점, τ²-bench 10.0점, AutomationBench 4.3점 올렸고 pass^5는 1.7배에서 2.2배로 높였다. 자기 생성 과제로 메모리를 만드는 유일한 기존 방법인 PREPING을 두 지표 모두에서 앞섰고, 벤치마크 학습 과제를 쓰는 방법들과 비교해도 6개 MSR·pass^5 열 중 4개에서 오차 범위 안이었다(AppWorld pass^5에서는 ACE, AutomationBench MSR에서는 ExpeL에 뒤짐). 같은 학습 과제를 준 Daedalus-curated 변형은 모든 벤치마크·지표에서 오차 범위 내 1위였고, 자기 생성 과제는 큐레이션 과제 대비 MSR이 0.6, 2.5, 4.0점만 낮았다. 한 모델 패밀리로 만든 뱅크가 다른 패밀리 베이스 에이전트에도 통하는데, Qwen·DeepSeek 조합의 9개 이득이 모두 양수였고 GPT-5.4-mini는 Qwen 뱅크에서 자기 뱅크와 비슷한 +16.8을 얻었다.

전제와 한계

절제 실험은 방법의 핵심이 어디에 있는지 보여준다. 탐사만으로 뽑은 휴리스틱은 무메모리 베이스라인보다 오히려 나빴고, Solver 궤적을 포함시키는 순간 MSR이 +15.8점 뛰었다. 재시도 기반 검증 루프를 더하면 +4.5점이 추가로 올랐다. 즉 성능을 만드는 것은 실패에 근거하고 경험적으로 확인된 휴리스틱이다. 과제 설계 지침은 품질보다 비용 효율을 개선해 수정 횟수를 183회에서 161회로 줄이고 생성 비용을 12% 낮췄으며(MSR 변화는 오차 범위 내 -1.1점), 환경 사전 조사와 합치면 (d) 대비 생성 비용을 48% 절감하고 Solver·Judge 비용을 60% 줄였다. LLM Judge는 공식 검증기와 κ_bench > 0.7, 반복 판정 간 κ_inter > 0.8의 일치도를 보였고 정밀도가 재현율보다 높아, 실패를 성공으로 잘못 받아들이기보다 성공을 거부하는 안전한 방향으로 치우쳤다. 탐사 예산을 늘리면 5세션만으로 90세션 정점 개선폭의 절반 이상을 얻었지만, 90세션을 넘기면 뱅크가 커져도 MSR이 오히려 떨어졌다(계층적 병합도 54.6 대 53.7로 회복 못 함). 보조 에이전트를 전부 GPT-5.4-mini로 낮춰도 무메모리 대비 +6.9 MSR, +5.3 pass^5로 GPT-5.4 대비 절반가량의 이득은 유지됐다.

추론 시점에는 병합한 뱅크를 과제 시작에 통째로 넣는 방식이 가장 좋고 가장 쌌다(MSR 60.2, 비용 3.2달러로 무메모리와 동일). 매 턴 검색(BM25, Qwen3-Embedding-4B, 랜덤 대조군)은 무메모리보다 최대 10점 높았지만 서로 유의미한 차이가 없었고, BM25로 k=30까지 늘려도 58.2%로 통째 주입에 못 미쳤다. 저자들은 유용한 휴리스틱이 현재 단계와 의미적으로 유사하지 않을 수 있는 '사선 검색(oblique retrieval)' 문제라고 해석한다. 또한 생성된 과제가 평가 프록시로 쓸 수 있는지도 확인했는데, 90세션 AppWorld 실행에서 채택된 81개 과제와 공식 테스트 분할에서 9개 모델을 무메모리로 평가한 순위가 MSR과 pass^3 모두 Kendall τ=0.89(p<.001)로 강하게 일치했고 36개 모델 쌍 중 34쌍의 순서가 같았다. 절대 성공률은 GPT-5.4-mini에 맞춰 보정된 탓에 다르지만 상대 순위는 보존된다.

실무 관점에서 이 논문이 주는 시사점은 명확하다. 사내 SaaS나 자체 도구처럼 학습 과제도 검증기도 없는 환경에 에이전트를 붙일 때, 사람이 가이드라인을 쓰지 않고도 소량의 탐사 예산(5세션 수준)만으로 쓸 만한 메모리를 확보할 수 있다는 것이다. 다만 메모리를 그대로 믿기 전에 확인할 것이 있다. 채택된 휴리스틱은 Solver가 연속 3회 성공해야 인정되므로 검증 강도가 세션 수와 모델 성능에 좌우되고, Judge가 완벽하지 않아 잘못된 판정이 난이도 보정이나 휴리스틱 채택을 오도할 수 있다. 또한 뱅크가 커질수록 병합이 일부 휴리스틱의 적용 범위를 잘못 기술해 테스트 분포의 특정 구간 성능을 흔들 수 있으므로, 환경별로 뱅크 크기와 커버리지 구성을 직접 점검해야 한다.

저자들이 밝힌 한계도 분명하다. DAEDALUS는 배포 전에 뱅크를 전부 만들어 두는 방식이라 테스트 시점에 메모리를 갱신하지 못하고, 불완전한 단일 LLM Judge에 의존한다. AppWorld에서는 90세션을 넘기면 메모리가 커질수록 성능이 하락했고, 계층적 병합으로도 이를 회복하지 못했다. 뱅크가 커질 때의 구성·커버리지 변화, 대규모 뱅크에 맞는 병합 방식, 사선 질의에 적합한 검색 메커니즘은 열린 문제로 남겨졌으며, 테스트 시점 메모리 갱신과 다중 Judge 검증 기법이 다음 단계로 제시된다.