방법론
전체 아키텍처: Training-Agent Disaggregation
Agent Lightning의 전체 시스템은 두 개의 독립적인 구성요소로 이루어진다. 각 블록을 클릭하면 세부 설명이 표시된다.
통합 데이터 인터페이스 (Unified Data Interface)
Agent Lightning의 출발점은 에이전트 실행에서 데이터를 어떻게 추출할 것인가에 있다. 논문은 AI 에이전트를 소프트웨어로 보고, 모든 소프트웨어 실행이 DAG(유향 비순환 그래프)로 표현될 수 있다는 사실에서 출발한다.
"AI agent is a special kind of software, and like all software execution, can be represented as a directed acyclic graph (DAG). [...] However, parsing a complete graph from disorganized agent execution traces is non-trivial and, as we have discovered, unnecessary for training purposes."AI 에이전트는 특수한 종류의 소프트웨어이며, 모든 소프트웨어 실행과 마찬가지로 DAG로 표현될 수 있다. 그러나 복잡한 에이전트 실행 흔적에서 완전한 그래프를 파싱하는 것은 간단하지 않으며, 우리가 발견했듯이 훈련 목적에는 불필요하다.
핵심 관찰: MDP 개념을 활용하면 현재 상태와 상태 전환에 영향을 미치는 핵심 요소(호출)만 식별하면 RL 최적화가 가능하다. 전체 DAG를 파싱할 필요가 없다.
의미 변수 (Semantic Variable)
상태(state)는 에이전트 실행의 스냅샷이다. 루프 카운터나 임시 문자열 조작 같은 보조적 연산은 에이전트 최적화에 불필요하다. 논문은 컴포넌트에 의해 사용/수정되고 의미론적으로 중요한 변수를 Semantic Variable(의미 변수)로 정의한다. 보충 이 개념은 Parrot: Efficient serving of LLM-based applications with semantic variable(Lin et al., 2024)에서 차용되었다.
| 변수 | 의미 | 비고 |
|---|---|---|
t | 타임스텝 | 에이전트 실행 중 단계 |
x | 태스크 | 에이전트에게 주어진 입력 태스크 |
k | 실행 인덱스 | 동일 태스크의 k번째 실행 (다른 결과 가능) |
V | 변수 개수 | 현재 상태의 의미 변수 수 |
직관적 해설
수학적 유도
컴포넌트 호출 (Call)
| 변수 | 의미 | 비고 |
|---|---|---|
C_i | 호출되는 컴포넌트 | LLM 또는 툴 (M ∪ T에서) |
meta | 메타 정보 | 컴포넌트 이름, 타입, API 엔드포인트, 샘플링 전략, temperature 등 |
input | 입력 데이터 | 현재 상태의 의미 변수에서 추출 |
output | 출력 데이터 | 컴포넌트 실행 결과, 다음 상태를 업데이트 |
직관적 해설
수학적 유도
RL을 위한 데이터 추출
| 변수 | 의미 | 비고 |
|---|---|---|
π_θ | 정책 LLM | 최적화 대상 LLM, 파라미터 θ |
T | 전환 수 | 해당 실행에서의 LLM 호출 횟수 |
r_t | 보상 | 중간 또는 최종 보상. 많은 경우 최종 r_T만 사용 |
직관적 해설
수학적 유도
예시: RAG 에이전트의 통합 데이터 인터페이스
논문에서 사용하는 RAG 에이전트의 실행 흐름을 단계별로 확인할 수 있다. ▶ 재생 버튼으로 각 전환이 어떻게 생성되는지 따라가 보라.
에이전트에서의 MDP (Markov Decision Process)
단일 LLM을 최적화하는 경우, 이 LLM을 정책 모델로 간주하고 부분 관측 MDP(POMDP)로 모델링할 수 있다:
| 변수 | 의미 | 비고 |
|---|---|---|
S | 상태 공간 | 가능한 모든 state_t의 집합 |
O | 관측 공간 | 정책 LLM에 대한 모든 가능한 입력 |
A | 행동 공간 | 단일 LLM 호출에서 생성된 전체 토큰 시퀀스 |
T(s'|s,a) | 전환 동역학 | 일반적으로 알 수 없음 (unknown) |
R(s,a) | 보상 함수 | 상태-행동 쌍을 스칼라 보상으로 매핑 |
직관적 해설
수학적 유도
LightningRL: 계층적 RL 알고리즘
기존 단일턴 RL 알고리즘(PPO, GRPO, REINFORCE++)은 단일 응답을 최적화하도록 설계되었다. 에이전트의 멀티턴 시나리오에 이를 확장하는 것이 LightningRL의 역할이다.
단일턴 RL의 기본 손실 함수:
| 변수 | 의미 | 비고 |
|---|---|---|
A_j | 토큰 j의 어드밴티지 추정치 | 알고리즘마다 추정 방법이 다름 |
y_j | j번째 토큰 | 응답 output = (y_1, ..., y_N) |
π_θ(y_j|x, y_{<j}) | j번째 토큰의 생성 확률 | auto-regressive 생성 |
직관적 해설
수학적 유도
LightningRL이 이것을 에이전트로 확장하는 방법:
보충 LightningRL이 기존 단일턴 RL 알고리즘과 호환되는 이유: 각 전환 (input_t, output_t, r_t)은 "하나의 프롬프트에 대한 하나의 응답"과 구조적으로 동일하다. 단일턴 RL 알고리즘이 처리하는 데이터 형태와 완전히 일치하므로, 알고리즘 자체를 수정할 필요가 없다.
에이전트 런타임 상세
Lightning Client의 에이전트 런타임은 RL 훈련을 위한 인프라 역할을 한다. 주요 구성요소를 드릴다운으로 탐색할 수 있다.
대규모 RL 훈련에서 큰 배치 크기는 필수적이다. Agent Lightning은 두 단계의 데이터 병렬화를 구현한다:
- 노드 내(intra-node) 병렬화: 하나의 클라이언트가 단일 머신에서 여러 워커를 실행하고, 각 워커가 서로 다른 에이전트 인스턴스를 처리한다.
- 노드 간(inter-node) 병렬화: 여러 클라이언트가 서로 다른 머신에서 실행되며, 각자 에이전트 인스턴스 집합을 관리한다.
보충 에이전트 실행은 GPU가 아닌 일반 CPU 서버에서 가능하므로, GPU 자원을 LLM 훈련에만 집중시킬 수 있다. 이것이 TA Disaggregation의 실질적 이점 중 하나다.
구현 세부사항 — 실험 설정
| 항목 | Text-to-SQL | Open Domain QA (RAG) | Math QA |
|---|---|---|---|
| 에이전트 프레임워크 | LangChain | OpenAI Agents SDK | AutoGen |
| 데이터셋 | Spider | MuSiQue | Calc-X |
| 기반 모델 | Llama-3.2-3B-Instruct | Llama-3.2-3B-Instruct | Llama-3.2-3B-Instruct |
| 사용 툴 | SQL 실행기 | Wikipedia 검색기 (BGE) | 계산기 |
| 에이전트 수 | 3 (2개 최적화) | 1 | 1 |
| 보상 함수 | 최종 답변 정확도 | 0.9×F1 + 0.1×형식 | 최종 답변 정확도 |
| 멀티에이전트 | ✓ (선택적 최적화) | ✗ | ✗ |
구체적인 하이퍼파라미터(lr, batch size 등)는 논문에 명시되지 않았다. GitHub 저장소(https://github.com/microsoft/agent-lightning)에서 확인할 수 있다.
코드: 기존 에이전트를 Agent Lightning에 통합하기
논문의 Appendix A에서 제공하는 통합 예시 코드다. 핵심은 기존 에이전트 코드(agent.py)를 수정하지 않고, 래퍼 훈련 스크립트(train.py)만 추가한다는 점이다.
from agent import agent_function
from environments.game_server import GameServer
from agent_lightning import Client, Resource, Task결과
Agent Lightning의 효과는 세 가지 서로 다른 태스크에서 검증되었다. 모두 다른 에이전트 프레임워크로 구현되었으며, 공통 기반 모델은 Llama-3.2-3B-Instruct다.
"Agent Lightning enables continuous and stable performance improvement across diverse scenarios, demonstrating strong potential for real-world agent optimization."Agent Lightning은 다양한 시나리오에서 지속적이고 안정적인 성능 향상을 가능하게 하며, 실제 에이전트 최적화에 대한 강력한 잠재력을 보여준다.
| 태스크 | 데이터셋 | 에이전트 유형 | 보상 추이 | 주목 포인트 |
|---|---|---|---|---|
| Text-to-SQL | Spider (10k+질문, 200DB) | 멀티에이전트 (3개, 2개 최적화) | 안정적 상승 | 선택적 에이전트 최적화 가능성 입증 |
| Open Domain QA (RAG) | MuSiQue (다중홉, Wikipedia 21M) | 단일 에이전트 | 안정적 상승 | 개방형 멀티홉 추론에서도 RL 효과적 |
| Math QA (툴 사용) | Calc-X (GSM8K·Ape210K 기반) | 단일 에이전트 (계산기 툴) | 일관된 상승 | 툴 통합 추론에서도 효과적 |
훈련 보상 곡선 시뮬레이션
논문에서 보고된 세 태스크의 훈련 보상 곡선 추세를 시각화했다. 모든 태스크에서 훈련 진행에 따른 안정적인 향상이 관찰되었다.
평가 위 차트는 논문의 Figure 5, 6, 7에서 보고된 추세를 도식화한 것으로, 정확한 수치가 아닌 일반적인 패턴을 반영한다. 실제 훈련 곡선은 논문 원본 Figure를 참조하라.
4.1 Text-to-SQL via LangChain — 멀티에이전트 선택적 최적화
이 태스크에서 Agent Lightning의 차별적 기능이 드러난다: 멀티에이전트 시스템에서 일부 에이전트만 선택적으로 최적화할 수 있다.
워크플로: SQL 작성 에이전트 → SQL 실행 → 검사 에이전트 → (필요시) 재작성 에이전트 → 최종 답변. 동일한 LLM이 3개의 역할을 수행하지만, 그 중 SQL 작성과 재작성 2개만 훈련에 포함된다.
보충 Spider 데이터셋은 138개 도메인에 걸쳐 200개 이상의 데이터베이스를 포함하는 복잡한 크로스도메인 벤치마크다. 테스트 시 훈련에서 보지 못한 새로운 데이터베이스가 등장하므로 일반화 능력이 중요하다.
4.2 RAG via OpenAI Agents SDK — 개방형 멀티홉 추론
보상 함수: R = 0.9 × R_correctness + 0.1 × R_format. 형식 점수(R_format)는 LLM이 <think>...</think>, <query>...</query>, <answer>...</answer> 형식을 준수하는지 평가한다. 정확도 점수(R_correctness)는 예측 답변과 정답 사이의 단어 수준 F1 스코어다.
MuSiQue 데이터셋은 단계적으로 연결된 단일홉 질문들로 구성된 다중홉 QA 벤치마크다. 전체 Wikipedia(2100만 문서)가 검색 공간이다. 이 규모의 개방형 검색 환경에서 3B 모델을 RL로 훈련하는 것이 이 실험의 도전 과제였다.
4.3 Math QA via AutoGen — 툴 통합 추론
Calc-X 데이터셋은 GSM8K, Ape210K 등 기존 수학 데이터셋을 수정해 계산기 툴 사용을 필수화했다. 에이전트는 중간 계산 값을 계산기 툴로 구하고, 그 결과를 통합해 최종 답변을 생성해야 한다.
이 태스크에서 LLM은 수학 문제를 이해하고, 정확한 툴 호출 형식으로 계산기를 사용하고, 툴 출력을 다음 추론 단계에 올바르게 통합하는 능력을 모두 갖춰야 한다.
한계점 & 트레이드오프
트레이드오프 정리
| 얻은 것 | 포기한 것 |
|---|---|
| 어떤 에이전트 프레임워크든 ZERO 코드 수정으로 통합 | 에이전트별 세밀한 최적화 제어 |
| 기존 단일턴 RL 알고리즘 그대로 사용 가능 | 정교한 크레딧 할당 (현재 균등 전략) |
| 복잡한 멀티에이전트·동적 워크플로 지원 | 멀티 LLM 공동 최적화 (미완성) |
| 위치 인코딩 연속성 보존 (마스킹 불필요) | 에피소드 컨텍스트 공유 불가 (전환이 독립적) |
영향력 & 후속 연구
Agent Lightning이 제시하는 것은 단순한 프레임워크 그 이상이다. 이 논문은 "에이전트 실행과 RL 훈련의 분리"라는 원칙이 미래 에이전트 최적화 연구의 핵심 방향이 될 수 있음을 주장한다.
누구에게 직접적인 영향을 미치는가?
저자가 제시한 미래 연구 방향
1. 더 정교한 크레딧 할당: 현재 균등 전략을 넘어, 학습된 가치 함수나 휴리스틱 기반의 크레딧 할당 전략으로 확장. 고수준 가치 함수를 도입해 각 행동 a_t의 기대 리턴을 개별 추정하는 방향.
2. RL 알고리즘 개선: 장기 크레딧 할당, 탐색 알고리즘, 오프폴리시 알고리즘 등. 전환 기반 데이터 구조가 새로운 알고리즘 통합을 용이하게 한다.
3. 시스템 인프라 발전: 트레이너-롤아웃-에이전트 워크플로의 더 세밀한 분리로 롤아웃 병목 해소. 장기 태스크를 위한 알고리즘-시스템 공동 최적화.
4. RL 이외의 최적화 방법: 컴포넌트 관심사(Component of Interest, CoI) 개념을 통해 자동 프롬프트 최적화 등 RL 이외의 에이전트 최적화 방법도 지원 예정.
관련 분야 더 탐색하기
Q&A — 연구자의 고민과 독자의 질문
저자들이 직면한 근본적인 딜레마는 이것이었다: 에이전트의 복잡한 실행 흐름을 RL에 맞게 어떻게 구조화할 것인가? 가장 직관적인 접근은 기존 방법처럼 모든 턴을 하나의 긴 시퀀스로 연결하는 것이다. 하지만 이 방식은 세 가지 문제를 낳는다.
첫째, 에이전트 실행 로직과 훈련 프레임워크가 강하게 결합된다(LangChain으로 만든 에이전트를 veRL에 통합하려면 대규모 재구현이 필요). 둘째, RoPE 같은 위치 인코딩이 가정하는 토큰 연속성이 깨진다(툴 출력 같은 비LLM 토큰을 마스킹하면 위치 불연속이 생긴다). 셋째, 다중 에이전트나 동적 워크플로처럼 선형이 아닌 실행 패턴을 처리할 수 없다.
전환 단위 구성은 이 세 문제를 동시에 해결한다: 에이전트 로직을 추상화하고, 위치 연속성을 보존하며, 어떤 실행 패턴도 (input, output, reward) 튜플의 시퀀스로 표현할 수 있다.
"our experimental results demonstrate that the simple identical assignment strategy is effective across multiple scenarios and datasets."우리의 실험 결과는 단순한 동일 할당 전략이 여러 시나리오와 데이터셋에서 효과적임을 보여준다.
이론적으로는 행동마다 다른 크레딧을 부여하는 것이 더 좋을 수 있다. 하지만 실용적 관점에서 균등 할당은 몇 가지 장점이 있다: 구현이 단순하고, 별도의 가치 함수 학습이 필요 없으며, GRPO 같은 기존 알고리즘과 즉시 호환된다. 실험 결과가 이 단순한 전략의 충분함을 지지한다.
평가 논문은 균등 할당의 한계를 인정하고 더 정교한 크레딧 할당을 미래 과제로 남긴다. 특히 에피소드가 길거나(예: 100턴 이상) 초기 행동이 최종 결과에 크게 영향을 미치는 경우, 균등 할당의 한계가 드러날 수 있다.
기존 방법들은 "RL 훈련 시스템 안에서 에이전트를 새로 구현"해야 한다. 즉, LangChain으로 이미 만들어진 에이전트가 있어도, veRL이나 다른 RL 시스템의 방식에 맞게 에이전트를 재작성해야 한다. 이는 다음을 의미한다: RL 전문 지식이 없는 에이전트 개발자는 접근하기 어렵고, 프로덕션에서 사용하는 에이전트를 RL용으로 마이그레이션하는 것은 노동집약적이다.
Agent Lightning의 차별점: 에이전트는 그대로 유지하고, 얇은 래퍼(train.py)만 추가하면 된다. 훈련 시스템은 에이전트 내부 구조를 알 필요가 없다.
완전히 호환된다. 단일턴 RL은 에이전트에서 T=1인 특수한 경우다: 하나의 LLM 호출, 하나의 전환, 최종 보상. LightningRL의 두 단계(크레딧 할당 + 단일턴 RL 적용) 모두 T=1에서도 그대로 작동하며, 이 경우 크레딧 할당은 의미가 없어지므로 표준 GRPO/PPO와 동일해진다.
"거의(almost) ZERO 코드 수정"이라는 표현에 주목해야 한다. LLM API 호출 시 엔드포인트 URL을 훈련 서버의 엔드포인트로 교체하는 것은 필요하다. 하지만 이것은 환경변수 하나를 바꾸는 수준이므로, 에이전트 비즈니스 로직은 실질적으로 변경되지 않는다고 볼 수 있다.
보충 Appendix A의 예시 코드를 보면, 기존 agent.py는 전혀 수정하지 않고 새로운 train.py 파일만 추가한다. agent_function(resource.model_api, game_url)에서 resource.model_api가 훈련 서버의 엔드포인트다.
논문에서 공개 GitHub 저장소를 제공한다: github.com/microsoft/agent-lightning. 다만 논문은 "공개 API가 수정될 수 있다"고 명시하므로, 최신 API 사용법은 저장소를 직접 확인하는 것이 좋다.
원본 Figure & Appendix
논문의 주요 Figure와 Appendix를 원본 그대로 보존합니다. 독자는 이 섹션에서 논문의 어느 부분을 펴야 할지 바로 알 수 있습니다.
이 그림은 Agent Lightning이 에이전트 실행과 RL 훈련을 완전히 분리하는 방식을 보여준다. 왼쪽의 다양한 에이전트 프레임워크(LangChain, OpenAI SDK, AutoGen, 자체 구현)가 오른쪽의 RL 훈련 시스템과 통합 데이터 인터페이스를 통해 연결된다. 논문의 핵심 주장인 "ZERO 코드 수정으로 ANY 에이전트 훈련"을 시각적으로 표현한다.
주목할 포인트: 초록 사각형이 현재 상태에서 유효한 의미 변수, 회색 사각형이 아직 할당되지 않은 변수를 나타낸다. LLM 호출만이 RL 훈련 전환으로 추출되며, 검색 툴 호출은 상태를 업데이트하지만 훈련에 직접 포함되지 않는다.
세 방법의 핵심 차이: 기존 멀티턴 GRPO(b)는 회색 점선 박스로 표시된 비LLM 토큰을 마스킹해야 한다. LightningRL(c)은 각 전환이 독립적인 (입력, 출력, 보상) 튜플이므로 마스킹이 불필요하다. 이것이 에이전트 로직 분리의 알고리즘적 근거다.
Lightning Server(왼쪽)와 Lightning Client(오른쪽)의 분리 구조. Server는 RL 프레임워크를 관리하고 OpenAI-like API를 노출한다. Client는 에이전트를 실행하고 데이터를 수집한다. 이 분리로 인해 에이전트는 GPU 서버에 종속될 필요가 없다.
보충 Appendix B에서 제공하는 전체 프로세스 다이어그램. 서버-클라이언트 간 태스크 배포, 에이전트 실행, 데이터 수집, 훈련 업데이트의 전체 흐름을 보여준다. 시스템의 이벤트 기반 orchestration을 이해하는 데 핵심적이다.