Multi-Policy Agent의 메모리 효율화

오늘의 포스트는 리뷰가 아닌 내 연구에 대한 기본적 초석을 다지기 위해 간략히 정리하는 노트이다.
요즘 에이전트 태스크를 여럿 peaking을 해봤는데 적용 가능 분야가 무궁무진하고, 연구 잠재성도 엄청난 것 같아 흥미롭게 살펴보고 있는 분야 중 하나이다.
최근 다양한 에이전트 태스크를 탐색하며 깨달은 것은, 에이전트는 단순히 명령을 수행하는 도구를 넘어 이제는 자율적인 의사결정 system으로 자리잡기 시작했다는 점이다.

특히 에이전트가 장기적인 태스크를 수행하기 위해서는 단순히 '추론 능력'이 좋은 것을 넘어, '메모리'를 얼마나 효율적으로 다루느냐가 아키텍쳐의 핵심이 된다.

따라서 오늘의 글은 에이전트 연구에 대한 근본적인 나의 문제점들과 나만의 해답,
그리고 현재 호기심이 생긴 'Multi-Policy 환경에서의 메모리 최적화 전략'을 정리해보고자 한다.

이를 위해서는 우선 Agent (에이전트) 환경에 대한 정의를 확실히 하고 넘어가야 할 것 같다.

⚓️ 들어가기에 앞서

내가 처음 연구 분야에서의 "에이전트" 필드를 접할 때 들었던 의문점은 아래와 같다.

• MoE (Mixture of Experts)와 Agents의 차이점은 무엇인가?
• 단순 API 호출로 배포된 모델의 지식을 사용하는 거라면,
  연구 논문을 낼 때 수많은 실험을 진행할텐데 그럼 API 사용료가 너무 많이 낭비되지 않나?

이 두 가지였다.
특히, 자연어를 공부하는 나로서는 ACL 2025에도 Agent 연구가 수도 없이 많았으며, NeurIPS와 같은 CS의 제너럴한 분야를 모두 다루는 정상급 학회에서도 에이전트를 활용한 연구가 Accept 되었기에 더욱 궁금증이 생겼다.

러프한 공부를 통한 이 의문에 대한 나의 답변은 아래와 같이 정리할 수 있었다.

MoE vs. Agents

• MoE:
  모델 내부의 가중치 수준에서 Static Routing이 일어난다.
  
  $\to$ 이때, Static Routing이란?
  입력 토큰이 들어오면 Gating 네트워크가 즉각적으로 어떤 Expert(FFN)에게 보낼지 결정한다. 즉, 아키텍처에 종속된 효율화 방식이다.
  조금 더 자세히 설명하자면, 입력 토큰 $x$가 들어오면, 이 토큰을 어떤 Expert에게 전달할지 결정하는 매우 작은 Linear Layer를 'Router (Gating Network)'라 부른다. 이는 보통 토큰에 대한 가중행렬값의 Top-K에 Softmax를 적용한 확률분포값이다.

$G(x)=Softmax(TopK(x \cdot W_{gate}))$

이후, 우리가 흔히 아는 Transformer의 FFN 블록으로 보내져서 보통 GELU와 같은 활성화 함수와 Linear Layer로 구성되어 각 태스크에 Specialized된(가중치 학습된) Experts의 출력을 뽑을 수 있다.

$E_i(x)=\sigma(x W_{i, in}) W_{i, out}$

즉, 단순히 '아키텍처 종속'을 넘어, "학습된 가중치가 고정된 상태에서 토큰의 특징값에 따라 기계적으로 분기된다." 추론 시점에 모델이 스스로 "이번엔 다른 전문가를 써볼까?"라고 '의사결정'을 하는 것이 아닌, 입력값에 따른 연산 결과이다.

• Agents:
  모델 외부의 시스템 수준에서 작동한다.
  모델이 Action을 취하고, 환경(Environment)으로부터 Feedback을 받아 다음 행동을 결정하는 루프를 가진다. MoE가 '누구에게 물어볼까'를 고민한다면, 에이전트는 '어떤 도구로 이 환경을 바꿀까'를 고민한다.

  따라서 MoE가 모델 내부에 물리적으로 분리된 여러 가중치 집합(Experts) 중 최적의 연산 경로를 선택하는 '내부적 최적화'라면, 에이전트는 모델의 추론 능력을 엔진으로 삼아 외부 피드백 및 도구와 결합하여 최적의 행동 시퀀스를 설계하는 '시스템적 지능'이라 할 수 있다.
  
  💡 추가로, 최근에는 여러 LLM Agents의 응답을 합성하는 'Mixture of Agent (MoA)' 연구도 활발하나, 이는 시스템적인 앙상블에 가까운 수준이다.
  에이전트 연구의 본질적인 내용은 단발성 응답을 넘어선 '순차적 의사결정(Sequential Decision Making)'을 통해, 환경의 변화에 유연하게 대응하며 목표를 달성하는 '최적 전략(Policy)' 확보에 있다.

---

연구에서의 API 비용과 연구의 학술적 가치에 대한 의문

API 활용이 필수적인 해당 연구 분야의 연구 논문들을 읽어봤을 때, '실험을 위해 많은 시도를 했을 것인데 돈이 깨나 많이 들었겠다..'와 같은 생각을 한건.. 나만 한 생각이 아닐거라 믿는다. 또한 '단순 API 호출 연구가 어떻게 정상급 학회에 갈까?'라는 의문도 있었다.

하지만, 최근 많은 SOTA 에이전트 연구 (e.g., Reflexion, Voyager) 논문을 읽어본 결과, 연구적 가치는 단순히 많은 성능좋은 모델들의 API 호출 및 사용에서 끝나는 것이 아닌 아래의 두 가지가 주요하게 작용하는 것 같다.

• 호출을 유도하는 프롬프트 엔지니어링 및 논리 구조
• 피드백을 학습 데이터로 효과적으로 전환시키는 알고리즘

가령 Reflextion (Shinn et al., 2024)의 경우, 모델이 내놓은 결과에 대해 'Self-Reflection' 루프를 돌려, 실패 시 모델이 스스로 본인이 왜 틀렸는지를 Verbal Feedback을 하고, 이를 다음 시도의 Context로 삽입하여 성능을 비약적으로 높인 알고리즘을 제시했다.
Voyager (Wang et al., 2023)의 경우, Skill Library라는 개념을 도입해, 마인크래프트와 같은 환경에서 수행한 성공적인 Action을 Vector DB에 저장했다가 유사한 상황이 오면 이를 다시 Retrival하여 학습 없이도 복잡한 태스크를 수행한 알고리즘을 제시했다.

특히 최근에는 LLaMA4나 Phi-4와 같은 고성능 Open-Weights 모델의 배포로, 로컬 서버에서도 높은 학회 수준의 연구가 가능한 것 같다.

💾 KV-Cache Optimization for Long-term Reasoning

에이전트의 사고 과정(e.g., CoT)이 길어질수록 KV-Cache는 기하급수적으로 커질 것이다. 이를 해결하기 위해 아키텍처 차원에서의 접근이 필요하다.
해당 문제 해결을 위해 가장 쉽고 익숙하게 생각해낼 수 있는 것이 KV-Cache라 생각된다.

추론 과정에서 생성되는 모든 토큰은 완전히 동일한 가치를 가지지 않을 것이다. 가령 아무리 같은 토큰이어도 맥락과 세부적인 문장의 순서 등에 따라 가치가 변할 것이기 때문이다.

따라서 캐시 내부를 확인하며 동적으로 메모리를 Pruning하는 아래의 기법들이 주목할 만하다.

StreamingLLM, H2O

• StreamingLLM (Xiao et al., 2023):
  "Attention Sink" 개념을 도입하여, 문장의 아주 초기 토큰들이 전체 어텐션 안정성에 기여도가 높음을 밝혀냈다.
• H2O (Zhang et al., 2024):
  누적 어텐션 스코어가 높은 Heavy Hitter 토큰들만 유지하고 나머지는 Eviction(제거)하여 캐시를 압축한다.

SnapKV (Optimizing KV-Cache for Long Content)

에이전트가 긴 문서를 읽을 때, Attention 맵의 클러스터링을 통해 "중요한 정보가 밀집된 구간"만 캐시에 남기고 나머지는 버리는 방식이다. H2O가 토큰 단위라면 해당 SnapKV는 특정 레이어와 헤드에 맞춰 더 정교하게 캐시를 압축하는 방식이다.

혹은 실시간으로 KV-Cache 내의 중요도를 계산하는 기법도 존재한다.

Quest (Query-Aware KV-Cache Pruning)

현재 들어온 Query에 따라 실시간으로 에이전트는 단계마다 목표를 바꿔야한다. 이는 이전 단계에서 중요했던 캐시는 현재 단계에서는 불필요한 정보가 될 수 있다는 뜻이다. 이를 동적으로 해결하기 위해 KV-Cache 내를 모니터링하며 Pruning하는 방식이다.

특히, 강화학습 분야에 적용할 경우 Multi-Policy 환경에서는 각 정책이 중요하게 여기는 Features가 다르므로, 정책별 맞춤형 캐시 전략이 필수적일 것이다.

📑 Agent Memory Management & Retrival Utility

단순히 "DB에서 꺼내오는 것"이 아닌, 다양한 에이전트가 제한된 Context Window를 어떻게 효율적으로 관리하는지 또한 관건이다. 따라서 이를 다루기 위한 "시스템적 메모리 관리 기법"이 존재한다.

이때 제일 먼저 생각이 든 기법은 Self-RAG였다.

Self-RAG (Self-Reflective Retrieval; Asai et al., 2024)

무조건 검색을 하는 것이 아닌, '모델이 스스로 "지금 검색이 필요한 시기인지"를 판별IsRel 토큰 생성 등하고, 검색된 결과의 신뢰도를 평가하는 방식이다.
이는 불필요한 Retrieval API 호출을 줄여 Latency와 비용을 낮췄다.

짧은 내용이지만 내 호기심에 대해 공통적으로 초석이 되는 위 내용들을 기반으로 내 생각을 좀 더 정리할 수 있었다.
결국 현재로서 내가 나아가야 할 방향은 "멀티 정책 에이전트가 어떻게 하면 각자의 전략에 맞는 최적의 정보를 캐싱하고, 과거의 성공/실패 경험을 벡터 공간에서 효과적으로 인출하여 전략을 수정할 것인가?"이다.

즉, 개별 모델의 내부적 연구와 더불어 앞으로 어떻게 이미 최고 성능을 보이는 모델의 API를 "효율적으로" 사용할지에 대한 고민 또한 계속 해봐야될 것 같다.