Agents Learn Their Runtime: Interpreter Persistence as Training-Time Semantics

이 논문은 도구 활용 에이전트의 학습 데이터에 인터프리터 상태 지속성이 포함되는지 여부가 해결 능력에는 영향을 주지 않지만 토큰 효율성과 안정성에는 결정적인 차이를 만든다는 점을 규명하고, 학습 데이터와 배포 런타임의 정렬을 강조합니다.

핵심

이 논문은 **"AI 에이전트 (작업 수행 인공지능) 가 어떻게 '기억'을 배우는지"**에 대한 흥미로운 연구 결과를 다루고 있습니다.

핵심 주제는 매우 간단합니다: **"AI 가 문제를 풀 때, 컴퓨터 메모리 (변수) 를 계속 유지해 주는지, 아니면 매번 초기화하는지"라는 환경 설정이 AI 의 학습 방식에 어떤 영향을 미치는가?**입니다.

이 복잡한 연구를 일상적인 비유로 쉽게 설명해 드리겠습니다.

---

🧠 비유: "메모장" vs "기억력"

이 논문의 실험은 두 가지 다른 방식으로 문제를 풀게 하는 **두 명의 학생 (AI)**을 비교하는 것과 같습니다.

1. 상황 설정: "투명하지 않은 배낭 (Opaque Knapsack)" 게임

학생들에게 어려운 미션이 주어졌습니다.

• 미션: 무게와 가치가 숨겨진 여러 개의 보석 (아이템) 중에서, 배낭에 들어갈 수 있는 가장 가치 높은 조합을 고르는 것입니다.
• 규칙: 보석의 무게와 가치는 직접 볼 수 없고, "검사 도구"를 써야만 알 수 있습니다. 하지만 도구를 쓸 수 있는 횟수 (예산) 는 제한되어 있습니다.
• 문제: 모든 보석을 다 검사할 시간이 없으므로, 어떤 보석을 검사할지, 어떤 것을 배낭에 넣을지 매 단계마다 계획을 세우고 기억해야 합니다.

2. 두 가지 학습 환경 (훈련 방식)

연구진은 이 학생들을 두 가지 다른 방식으로 훈련시켰습니다.

• A 그룹 (지속적 메모리 학습):

  • 환경: 컴퓨터 메모리가 계속 유지됩니다.
  • 상황: 1 단계에서 "보석 A 를 검사했다"고 메모리에 적어두면, 2 단계에서도 그 메모리가 그대로 남아 있습니다. 학생은 "아, 내가 방금 A 를 검사했지?"라고 생각하며 다음 행동을 합니다.
  • 학습 내용: "메모리에 적어두면 나중에 다시 쓸 수 있구나. 그래서 매번 다시 적을 필요가 없어."

• B 그룹 (무기억 학습):

  • 환경: 매 단계가 끝날 때마다 메모리가 초기화됩니다.
  • 상황: 1 단계에서 보석 A 를 검사하고 메모리에 적었지만, 2 단계로 넘어가면 메모리는 다 지워집니다.
  • 학습 내용: 학생은 "아, 메모리가 지워지니까 매번 **메모장 (텍스트)**에 다시 적어서 다음 단계에 가져가야 해!"라고 배웁니다.

---

🚨 실험 결과: 환경이 바뀌면 무슨 일이?

이제 이 두 학생을 실제 시험 (배포) 에 내보냈습니다. 그런데 흥미로운 일이 벌어졌습니다.

1. A 그룹 학생이 "무기억 환경"에서 시험을 보다가... (학습과 환경 불일치)

• 상황: 메모리가 계속 유지되는 방식으로 훈련받았지만, 시험에서는 매번 메모리가 지워지는 환경에 놓였습니다.
• 결과: 대참사! 🤯
  • 학생은 "아까 검사한 보석 데이터가 메모리에 있을 거야"라고 생각하며 코드를 짜는데, 메모리가 비어있어서 **"변수가 정의되지 않았습니다 (NameError)"**라는 오류가 터집니다.
  • 학생은 당황해서 오류를 수정하려다 보니, 같은 실수를 반복하며 **말이 막히는 상태 (루프)**에 빠집니다.
  • 비유: "내 기억력이 좋다고 믿고 공부했는데, 시험장에 가보니 내 머리가 다 지워져서 아무것도 기억나지 않아서 당황해서 멍청해지는 상황"입니다.

2. B 그룹 학생이 "지속적 메모리 환경"에서 시험을 보다가...

• 상황: 메모리가 매번 지워지는 방식으로 훈련받았지만, 시험에서는 메모리가 계속 유지되는 환경에 놓였습니다.
• 결과: 성공은 했지만 비효율적! 🐢
  • 학생은 메모리가 유지된다는 사실을 모릅니다. 그래서 "아, 메모리가 지워졌겠지"라고 생각하며 매번 메모장에 모든 것을 다시 적어 넣습니다.
  • 실제로는 메모리에 이미 데이터가 있는데도, 굳이 다시 적어 넣는 불필요한 작업을 반복합니다.
  • 비유: "메모장이 계속 유지되는 방에 들어갔는데, 내가 '매번 메모장을 새로 써야 해'라고 배워서, 이미 적힌 내용을 지우고 다시 똑같은 내용을 적는 시간 낭비를 하는 상황"입니다. 이를 논문에서는 **'망각세 (Amnesia Tax)'**라고 부릅니다.

---

💡 핵심 교훈: "학습할 때의 환경이 중요하다"

이 연구는 AI 개발자들에게 중요한 메시지를 줍니다.

1. AI 는 단순히 문제를 푸는 법만 배우는 게 아니다: AI 는 **"어떻게 기억을 관리할지"**라는 습관까지 함께 배웁니다.
2. 학습 환경과 실제 환경은 꼭 맞춰야 한다:
   • 만약 실제 서비스에서 AI 가 메모리를 계속 유지한다면, 학습 데이터도 메모리가 유지되는 방식으로 만들어야 합니다.
   • 반대로, 학습 데이터가 메모리 초기화 방식이라면, 실제 서비스에서도 메모리를 초기화해야 AI 가 효율적으로 작동합니다.
3. 단순한 기술적 설정이 아니다: "메모리를 유지할까 말까"는 단순한 코드 설정이 아니라, AI 의 두뇌 구조 (행동 패턴) 를 결정하는 핵심 요소입니다.

📝 한 줄 요약

"AI 에게 '기억'을 어떻게 가르치느냐에 따라, 실제 일할 때 그 AI 가 얼마나 똑똑하게 (혹은 멍청하게) 행동하는지가 결정된다."

이 논문은 AI 개발자들이 단순히 "정답"을 가르치는 것뿐만 아니라, AI 가 일하는 **환경 (런타임)**까지 고려하여 학습 데이터를 만들어야 함을 강력하게 주장합니다.

기술 요약

1. 연구 배경 및 문제 제기 (Problem)

• 배경: 도구 활용 (Tool-augmented) LLM 에이전트들은 자연어 추론과 실행 가능한 Python 코드 (인터프리터) 를 교차하여 작업을 수행합니다. 많은 에이전트 프레임워크 (예: CodeAct) 는 변수와 데이터 구조가 턴 (turn) 간에 유지되는 지속적 (Persistent) 인터프리터를 제공합니다.
• 문제: 그러나 모델의 미세 조정 (Fine-tuning) 을 위한 학습 데이터 (Trace) 는 종종 이 런타임 가정을 명시적으로 드러내지 않습니다.
  • 핵심 질문: 인터프리터의 지속성 (Persistence) 은 단순히 추론 시 (Inference-time) 필요한 실행 환경의 '발판 (Scaffold)'일 뿐인가, 아니면 학습 데이터의 속성으로서 에이전트가 도구를 사용하는 방식을 형성하는 **학습 가능한 행동 우선순위 (Learnable Behavioral Prior)**인가?
• 현실적 문제: 모델은 한 런타임 환경에서 생성된 데이터로 학습된 후, 다른 런타임 환경 (예: 지속적 vs 상태 비저장) 에 배포되는 경우가 많습니다. 이 불일치가 에이전트의 효율성과 안정성에 어떤 영향을 미치는지 규명할 필요가 있습니다.

2. 방법론 (Methodology)

저자들은 이 문제를 해결하기 위해 통제된 2x2 실험 설계를 수행했습니다.

• 작업 환경: OPAQUE KNAPSACK (불투명한 배낭 문제)

  • 기존 배낭 문제를 기반으로 한 부분 관측 가능 (Partially Observable) 한 최적화 작업입니다.
  • 비축소성 (Non-collapsible) 설계: 단일 스크립트로 해결할 수 없도록 설계되었습니다.
    • 아이템의 속성 (무게, 가치, 클래스) 은 숨겨져 있으며, 제한된 예산 (Budget) 으로만 inspect 도구를 통해 확인할 수 있습니다.
    • 클래스 제약 조건도 숨겨져 있어, 단계별 상호작용과 상태 수정을 강제합니다.
  • 도구 API: list_items(), inspect(id), take_item(id) 등 3 가지 도구만 사용 가능합니다.

• 실험 설계 (2x2 Cross-Evaluation)

  • 학습 조건 (Training Semantics):
    1. 지속적 (Persistent): 인터프리터 상태가 턴 간 유지되는 데이터로 학습.
    2. 상태 비저장 (Stateless): 각 턴 후 인터프리터 상태가 초기화되는 데이터로 학습.
  • 실행 조건 (Runtime Semantics):
    1. 지속적 런타임: 배포 시 인터프리터 상태가 유지됨.
    2. 상태 비저장 런타임: 배포 시 인터프리터 상태가 초기화됨.
  • 모델: 동일한 Qwen3-8B 모델을 두 가지 학습 데이터 변형 각각으로 미세 조정 (LoRA) 하여 총 4 가지 조합을 평가했습니다.

• 데이터 생성: 동일한 작업 인스턴스와 프롬프트를 사용하되, 인터프리터 상태 처리 방식 (지속 vs 초기화) 만을 다르게 하여 매칭된 트레이스 (Trajectory) 를 생성했습니다.

3. 주요 기여 (Key Contributions)

1. 비축소성 벤치마크 (OPAQUE KNAPSACK) 및 쌍대 트레이스 생성 파이프라인: 작업, 도구, 감독 신호는 고정하되 인터프리터 지속성 계약 (Persistence Contract) 만을 변경하여 다중 턴 제어 흐름과 상태 수정을 강제하는 벤치마크를 제안했습니다.
2. 지속성은 학습된다는 증거: 2x2 교차 평가를 통해 인터프리터 지속성이 학습 시 행동적 우선순위 (Behavioral Prior) 로 흡수됨을 증명했습니다. 이는 프롬깅과 무관하게 배포 시까지 유지되며, 학습과 런타임이 불일치할 때 특징적인 실패 모드를 유발합니다.

4. 실험 결과 (Results)

A. 효율성 및 토큰 비용 (Efficiency & Token Cost)

• 일치된 조건 (Persistent-Trained + Persistent Runtime): 가장 효율적입니다. 실행 가능한 상태를 재사용하여 토큰 소모가 가장 적습니다.
• 기억 상실세 (Amnesia Tax): 상태 비저장 (Stateless) 으로 학습된 모델은 지속적 런타임에 배포되더라도, 인터프리터가 상태를 유지할 수 있음에도 불구하고 매 단계마다 상태를 텍스트로 다시 유도하고 재정의합니다. 이는 약 3.5 배 더 많은 토큰을 소모하게 만듭니다.
• 결과: 토큰 비용 차이는 학습된 행동 패턴에 기인하며, 런타임 환경이 제공하더라도 모델이 이를 활용하지 않습니다.

B. 안정성 및 실패 모드 (Stability & Failure Modes)

• 불일치 실패 (Persistent-Trained + Stateless Runtime):
  • 학습 시 지속적 상태를 가정하도록 훈련된 모델이 상태 비저장 런타임에서 실행될 때, 약 80% 의 에피소드에서 NameError (변수 정의 없음) 와 같은 누락된 변수 오류가 발생합니다.
  • 모델은 이전 턴의 변수를 참조하려 하지만 런타임이 이를 초기화했으므로, 오류 복구 루프에 빠져 토큰 예산을 소모하며 진전이 멈춥니다.
  • 이는 모델이 지속성을 단순한 '도움'이 아니라 실행 전략의 필수 요소로 학습했음을 보여줍니다.

C. 해결 품질 (Solution Quality)

• 흥미롭게도, 효율성과 안정성의 큰 차이에도 불구하고 최적 해 (Optimality) 의 통계적 유의미한 감소는 관찰되지 않았습니다.
• 즉, 인터프리터 지속성은 에이전트가 해결하는지 여부가 아니라, 어떻게 (얼마나 효율적이고 안정적으로) 해결하는지를 결정합니다.

5. 의의 및 결론 (Significance & Conclusion)

• 런타임은 학습 시 의미론 (Training-Time Semantics) 이다: 인터프리터의 지속성은 추론 시의 단순한 인프라가 아니라, 학습 데이터의 핵심 속성입니다. 학습 데이터 생성 시 사용된 런타임의 실행 의미론 (Execution Semantics) 은 모델이 상태를 관리하는 방식을 형성합니다.
• 설계 결정으로서의 런타임: 에이전트 개발자들은 미세 조정 (Fine-tuning) 을 위한 트레이스 생성 시, 런타임의 지속성 여부를 **숨겨진 구현 세부사항이 아닌 명시적인 설계 결정 (Explicit Design Choice)**으로 다뤄야 합니다.
• 불일치의 위험: 학습 환경과 배포 환경이 불일치하면, 모델이 학습된 행동 패턴 (예: 변수 재사용 또는 매번 재정의) 이 런타임의 실제 능력과 충돌하여 비효율적인 토큰 사용이나 치명적인 실행 오류를 초래할 수 있습니다.

요약하자면, 이 논문은 에이전트 모델이 단순히 도구를 사용하는 법을 배우는 것이 아니라, 도구가 실행되는 환경 (런타임) 의 상태 관리 방식을 함께 학습한다는 점을 증명했습니다. 따라서 에이전트의 성능과 안정성을 극대화하려면 학습 데이터의 실행 환경과 배포 환경의 실행 의미론을 정렬 (Align) 시키는 것이 필수적입니다.