Agent Lightning 완전 가이드 — AI 에이전트를 강화학습으로 훈련시키는 시대가 왔다

들어가며: AI 에이전트, '똑똑한 앵무새'에서 '경험으로 배우는 전문가'로

2025년, AI 에이전트 시장은 폭발적으로 성장했다. LangChain, AutoGen, CrewAI, OpenAI Agents SDK — 에이전트를 만드는 프레임워크가 넘쳐났다. 모두가 "에이전트의 시대"를 외쳤다.

하지만 한 가지 불편한 진실이 있었다. 대부분의 에이전트는 훈련되지 않은 채 배포되고 있었다.

무슨 뜻인가? 개발자가 프롬프트를 작성하고, 몇 번 테스트해보고, "이 정도면 되겠지"하고 프로덕션에 올린다. 에이전트가 실패하면? 프롬프트를 손으로 고치고 다시 배포한다. 이것은 마치 교과서만 읽고 시험을 보게 하는 것과 같다. 연습 문제도 안 풀어보고, 모의고사도 안 치르고.

인간이 전문가가 되는 방법을 생각해보자. 의사는 수천 건의 케이스를 경험하며 진단 능력을 기른다. 바리스타는 수백 잔의 커피를 추출하며 최적의 레시피를 찾는다. 경험과 피드백을 통한 학습 — 이것이 핵심이다.

AI 에이전트도 마찬가지여야 한다. 그리고 2025년 8월, Microsoft Research가 이 문제의 해답을 내놓았다.

Agent Lightning — AI 에이전트를 강화학습(RL)으로 훈련시키는 오픈소스 프레임워크.

"Agent Lightning은 ANY AI 에이전트를 강화학습으로 훈련시킬 수 있습니다. 프레임워크에 구애받지 않고, 코드 변경 거의 없이." — Microsoft Research 논문 (arXiv: 2508.03680)

이 글은 Agent Lightning의 모든 것을 해부한다. 왜 에이전트 훈련이 필요한지부터, 강화학습의 원리, 아키텍처의 세부 구조, 실전 적용 사례, 그리고 2026년 AI 개발의 미래까지.

제1장: 왜 에이전트를 '훈련'해야 하는가?

1.1 프롬프트 엔지니어링의 한계

2024년까지 AI 에이전트의 성능을 올리는 방법은 대부분 프롬프트 엔지니어링이었다. "너는 전문 SQL 분석가야. 사용자의 질문을 정확한 SQL로 변환해"같은 시스템 프롬프트를 정교하게 다듬는 작업이다.

문제는, 이 방법이 천장에 부딪힌다는 것이다.

위 수치는 Agent Lightning 논문의 Spider(Text-to-SQL) 벤치마크 기준. Qwen2.5-Coder-1.5B 모델 사용.

프롬프트를 아무리 다듬어도 62%에서 정체되던 SQL 에이전트가, 강화학습 훈련 후 74%까지 올라갔다. 12%p의 도약 — 이것은 프롬프트 수십 번 고쳐서는 절대 달성할 수 없는 성능이다.

1.2 왜 강화학습인가?

강화학습(Reinforcement Learning)을 비유로 설명하면 이렇다.

바둑의 알파고를 떠올려보자. 알파고는 인간의 기보(지도학습)만으로는 세계 챔피언이 될 수 없었다. 자기 자신과 수백만 판을 두며 강화학습을 한 뒤에야 이세돌을 이겼다. AI 에이전트도 마찬가지다.

1.3 에이전트 훈련이 어려운 진짜 이유

그런데 왜 지금까지 에이전트에 강화학습을 적용하지 못했을까? 이유는 세 가지다.

첫째, 프레임워크 파편화. LangChain으로 만든 에이전트와 AutoGen으로 만든 에이전트는 구조가 완전히 다르다. 각각에 맞는 RL 파이프라인을 만들어야 했다.

둘째, 훈련-실행 결합(Coupling). 기존 RL 프레임워크는 에이전트의 실행 환경과 훈련 루프가 단단히 묶여 있었다. 에이전트가 외부 API를 호출하거나, 파일을 생성하거나, 데이터베이스를 조회하는 복잡한 작업을 할 때 — 이 모든 것을 RL 훈련 루프 안에서 처리해야 했다.

셋째, 크레딧 할당(Credit Assignment). 에이전트가 10단계를 거쳐 작업을 완료했을 때, "어느 단계가 성공에 기여했고 어느 단계가 실패를 유발했는가?"를 판별하는 것이 극도로 어렵다.

Agent Lightning은 이 세 가지 문제를 모두 해결한다.

제2장: Agent Lightning의 핵심 철학

2.1 "ZERO CODE CHANGE (거의)"

Agent Lightning의 가장 파괴적인 특징은 기존 에이전트 코드를 거의 수정하지 않아도 된다는 것이다.

기존 LangChain 에이전트에 Agent Lightning을 적용하는 데 필요한 코드 변경은 딱 두 줄이다:

# 기존 에이전트 코드 (변경 없음)
from langchain.agents import create_react_agent
agent = create_react_agent(llm, tools, prompt)

# Agent Lightning 추가 — 이것뿐!
import agentlightning as agl
agl.emit_reward(score=0.85)  # 결과에 대한 보상 신호

이것이 가능한 이유는 Agent Lightning이 자동 계측(Auto-Instrumentation) 기술을 사용하기 때문이다. 에이전트가 LLM을 호출할 때, 도구를 사용할 때 — 이 모든 것을 투명하게 추적(trace)한다. 개발자가 명시적으로 로깅 코드를 넣을 필요가 없다.

2.2 프레임워크 불가지론(Framework-Agnostic)

Agent Lightning은 특정 에이전트 프레임워크에 종속되지 않는다.

핵심은 **경량 헬퍼 함수 agl.emit_xxx()**와 자동 추적(Tracer)의 조합이다. 에이전트가 어떤 프레임워크로 만들어졌든, Agent Lightning은 LLM 호출을 자동으로 포착하고, 개발자는 보상 신호만 보내면 된다.

2.3 훈련-에이전트 분리(Disaggregation)

전통적인 RL 시스템에서는 에이전트 실행과 모델 훈련이 같은 프로세스 안에서 돌아간다. 하지만 AI 에이전트는 외부 세계와 상호작용한다 — API를 호출하고, 웹을 검색하고, 데이터베이스를 조회한다. 이런 I/O 집약적 작업을 GPU 훈련 루프 안에 넣으면 GPU가 I/O를 기다리며 놀게 된다.

Agent Lightning은 이 문제를 훈련과 실행을 완전히 분리하여 해결한다. 이것이 논문이 "Training-Agent Disaggregation Architecture"라고 부르는 핵심 설계다.

제3장: 아키텍처 완전 해부

3.1 세 기둥: Algorithm, Runner, LightningStore

Agent Lightning의 아키텍처는 세 가지 핵심 컴포넌트로 구성된다. 이것을 이해하면 전체 시스템의 동작 원리를 파악할 수 있다.

이것을 식당에 비유하면 직관적이다:

• Algorithm = 주방장. 메뉴(작업)를 결정하고, 손님 피드백을 반영해 레시피(모델)를 개선한다.
• LightningStore = 주문 시스템(POS). 주방과 홀을 연결하는 유일한 통신 채널이다.
• Runner = 웨이터+요리사. 주문을 받아 음식을 만들고, 결과를 주문 시스템에 기록한다.

주방장이 직접 서빙할 필요 없고, 웨이터가 레시피를 개발할 필요도 없다. 관심사의 완전한 분리.

3.2 데이터 흐름: 작업은 어떻게 순환하는가

이 사이클이 수백~수천 번 반복되면서 에이전트의 성능이 지속적으로 향상된다.

3.3 핵심 용어 사전

Agent Lightning을 이해하려면 다섯 가지 핵심 개념을 알아야 한다.

이들의 관계를 정리하면:

Dataset = [Rollout1, Rollout2, ..., RolloutN]  (문제지)
  └── Rollout = 하나의 문제
        └── Attempt = 한 번의 풀이 시도
              └── [Span1, Span2, ..., SpanM]  (풀이 과정 각 단계)
                    └── Reward  (채점 결과)

3.4 실행 번들: 두 세계의 분리

Agent Lightning의 가장 중요한 설계 결정은 시스템을 두 개의 독립적인 번들로 나누는 것이다.

이 분리가 왜 혁명적인가?

1. 독립적 스케일링. Runner는 100개 병렬로 돌리면서 Algorithm은 GPU 1대만 쓸 수 있다. 또는 그 반대도 가능하다.

2. 이종 환경 지원. Runner는 인터넷 접근이 필요한 서버에서, Algorithm은 GPU 클러스터에서 — 완전히 다른 환경에서 실행될 수 있다.

3. 프레임워크 자유도. Runner가 어떤 에이전트 프레임워크를 사용하든, LightningStore를 통해 표준화된 데이터만 주고받으면 Algorithm은 동일한 방식으로 훈련할 수 있다.

3.5 실행 전략: 개발에서 프로덕션까지

ClientServer 모드에서는 LightningStoreServer가 HTTP API를 노출하고, 여러 대의 Runner가 LightningStoreClient를 통해 접속한다. MongoDB 백엔드를 사용하면 수천 개의 Runner를 동시에 운용할 수 있다.

제4장: 핵심 컴포넌트 심층 분석

4.1 Tracer — 에이전트의 모든 행동을 기록하는 블랙박스

비행기에 블랙박스가 있듯, Agent Lightning의 Tracer는 에이전트의 모든 행동을 기록한다.

Agent Lightning은 세 가지 Tracer 구현체를 제공한다:

• AgentOpsTracer (기본값) — AgentOps SDK를 부트스트랩하여 LangChain, LangGraph, LiteLLM, FastAPI를 자동 계측한다. 가장 포괄적.
• OtelTracer — 바닐라 OpenTelemetry TracerProvider를 사용한다. 기존에 OpenTelemetry 인프라가 있는 조직에 적합.
• WeaveTracer (실험적) — Weights & Biases의 Weave SDK와 통합한다.

4.2 Adapter — 원시 데이터를 훈련 데이터로 변환

Tracer가 기록한 원시 Span 데이터는 그대로는 RL 훈련에 사용할 수 없다. Adapter가 이 데이터를 훈련 가능한 형식으로 변환한다.

주요 Adapter 구현체:

• TracerTraceToTriplet — Span 데이터에서 (프롬프트, 응답, 보상) 트리플릿을 추출한다. RL 훈련용.
• TraceToMessages — Span 데이터를 OpenAI 채팅 메시지 JSON으로 변환한다. SFT(Supervised Fine-Tuning)용.
• LlmProxyTraceToTriplet — LLM Proxy를 경유한 Span에서 트리플릿을 추출한다.

4.3 LLM Proxy — 에이전트와 모델 사이의 투명한 다리

LLM Proxy는 Agent Lightning에서 가장 영리한 컴포넌트 중 하나다. LiteLLM 위에 구축된 이 프록시는:

특히 동적 모델 교체 기능이 중요하다. RL 훈련에서 모델 가중치는 계속 업데이트된다. 에이전트가 모델을 호출할 때, LLM Proxy가 자동으로 가장 최신 가중치를 사용하도록 라우팅해준다. 에이전트 코드는 한 줄도 바뀌지 않는다.

4.4 토큰 ID 문제 — RL 훈련의 숨겨진 난관

강화학습에서 토큰 ID가 왜 중요한가? RL 알고리즘(특히 PPO, GRPO)은 모델이 생성한 각 토큰의 확률을 알아야 한다. 이를 위해 정확한 토큰 ID가 필요하다.

문제는, LLM API가 보통 텍스트만 반환하고 토큰 ID는 반환하지 않는다는 것이다. 텍스트를 다시 토크나이즈(retokenize)하면 되지 않을까?

원본 생성: [15043, 382, 1234, 98]  ← 모델이 실제 생성한 토큰
재토크나이징: [15043, 38, 2123, 4, 98]  ← 텍스트를 다시 분해한 결과

→ 토큰 경계가 다름 → 확률 계산 불일치 → 훈련 불안정

이 문제가 발생하는 이유:

• 채팅 템플릿 차이 — 각 모델의 특수 토큰 삽입 방식이 다르다
• 도구 호출 파싱 — JSON 형태의 도구 호출은 토크나이저마다 경계가 다르게 잡힌다
• 토큰 경계 모호성 — 같은 텍스트도 분해 방법이 여러 가지일 수 있다

Agent Lightning은 이 문제를 vLLM 팀과 협업하여 해결했다. vLLM v0.10.2부터 return_token_ids 파라미터가 추가되어, API 응답에 토큰 ID가 직접 포함된다.

4.5 LightningStore — 모든 것의 중심

LightningStore는 메시지 큐 + 데이터베이스 + 리소스 레지스트리를 하나로 합친 컴포넌트다.

4.6 Hooks — 훈련 생명주기에 끼어드는 콜백

Hooks는 훈련 과정의 핵심 시점에 사용자 정의 로직을 삽입할 수 있게 해준다.

class MyHooks:
    def on_rollout_start(self, rollout):
        """Rollout 시작 전 — 환경 초기화, 데이터 준비"""
        print(f"Starting rollout: {rollout.id}")
    
    def on_trace_start(self, trace):
        """개별 추적 시작 — 타이머 시작"""
        pass
    
    def on_trace_end(self, trace):
        """추적 종료 — 결과 검증, 보상 계산"""
        score = evaluate(trace.result)
        agl.emit_reward(score)
    
    def on_rollout_end(self, rollout):
        """Rollout 종료 — 정리 작업, 메트릭 보고"""
        log_metrics(rollout)

제5장: 훈련 알고리즘 — 에이전트를 어떻게 똑똑하게 만드는가

5.1 VERL + GRPO — 강화학습의 핵심 엔진

Agent Lightning의 기본 RL 알고리즘은 GRPO(Group Relative Policy Optimization)를 사용하는 VERL 프레임워크다.

GRPO를 직관적으로 설명하면:

왜 GRPO인가? 기존 PPO(Proximal Policy Optimization)는 가치 함수(value function)라는 별도의 모델이 필요했다. GRPO는 가치 함수 대신 그룹 내 상대 비교를 사용하여 더 단순하고 안정적이다. DeepSeek-R1이 바로 이 GRPO로 훈련되었다.

VERL의 분산 처리 구조:

5.2 APO — 프롬프트 자동 최적화

모든 상황에서 모델 가중치를 업데이트할 수 있는 것은 아니다. 클로즈드 소스 모델(GPT-4o, Claude)을 사용하는 경우, 프롬프트만 최적화하는 것이 현실적이다.

APO(Automatic Prompt Optimization)는 텍스트 그래디언트라는 독특한 개념을 사용한다.

실전 결과 (Room Selector 벤치마크):

2라운드, 약 10분 만에 27% 성능 향상. 수동으로 프롬프트를 고치며 A/B 테스트를 반복하는 것보다 훨씬 효율적이다.

제6장: 실전 적용 사례

6.1 사례 1: Text-to-SQL 에이전트 훈련

문제: 사용자의 자연어 질문을 SQL로 변환하는 에이전트. Spider 벤치마크 기준.

설정:

• 모델: Qwen2.5-Coder-1.5B-Instruct (15억 파라미터, 소형 모델)
• 하드웨어: 단일 80GB GPU
• 훈련 시간: ~12시간

결과:

• 훈련 정확도: 46% → 72~74%
• 검증 정확도: Step 432에서 ~72% 도달
• 소형 모델만으로도 프롬프트 엔지니어링의 한계를 넘어서는 성능 향상을 달성했다.

6.2 사례 2: RAG 파이프라인 최적화

문제: MuSiQue 멀티홉 질의응답 데이터셋. "A의 출생지는 어디이고, 그 도시의 인구는?" 같은 다단계 추론이 필요한 질문.

RAG 에이전트가 검색 → 추론 → 재검색 → 최종 답변의 과정을 거칠 때, RL 훈련을 통해 언제 재검색할지, 어떤 키워드로 검색할지를 자동으로 학습한다.

6.3 사례 3: 수학 도구 사용 에이전트

문제: 복잡한 수학 문제를 풀 때 계산기, 방정식 풀이 도구 등을 적절히 활용하는 에이전트.

RL 훈련 전에는 모든 계산을 LLM이 직접 하려다 오류가 발생했지만, 훈련 후에는 "이 계산은 도구에 맡기는 게 낫겠다"는 판단을 자동으로 학습했다.

제7장: 대시보드 — 훈련 과정을 눈으로 보다

Agent Lightning은 React + Mantine UI로 구축된 웹 대시보드를 제공한다.

대시보드에서 확인할 수 있는 것들:

• Rollout 목록 — 각 작업의 상태, 보상, 실행 시간
• 트레이스 상세 — Waterfall 시각화로 에이전트의 행동을 시간순으로 추적

제8장: 역사적 맥락 — 여기까지 오는 길

8.1 RL의 여정: 게임에서 에이전트까지

강화학습이 AI 에이전트 훈련에 도달하기까지의 여정을 살펴보자.

8.2 핵심 전환점: RLHF에서 에이전트 RL로

RLHF(Reinforcement Learning from Human Feedback)는 "인간이 좋아하는 답변을 만들도록" LLM을 훈련시키는 기술이다. ChatGPT, Claude, Gemini — 모든 주요 모델이 RLHF를 거친다.

하지만 RLHF는 단일 턴 대화에 최적화되어 있다. "질문 → 답변"의 단순한 구조. AI 에이전트는 다단계 상호작용을 한다. 도구를 호출하고, 결과를 관찰하고, 다시 판단하고, 또 다른 도구를 호출한다.

이 다단계 과정에 RL을 적용하려면 MDP(Markov Decision Process)로 정형화해야 한다:

Agent Lightning 논문의 핵심 기여 중 하나가 바로 이 에이전트 행동을 MDP로 통합하는 프레임워크를 제시한 것이다.

제9장: 2026년, 에이전트 훈련의 현재와 미래

9.1 에이전트 훈련이 왜 '지금' 중요한가

2026년은 에이전트가 프로토타입에서 프로덕션으로 넘어가는 원년이다. Google의 Agent Development Kit(ADK), Anthropic의 MCP, OpenAI의 Agents SDK — 빅테크가 모두 에이전트 인프라에 올인하고 있다.

하지만 에이전트를 프로덕션에서 안정적으로 운용하려면, 프롬프트 엔지니어링만으로는 부족하다.

9.2 커뮤니티 생태계의 확장

Agent Lightning은 이미 활발한 커뮤니티를 형성하고 있다.

• DeepWerewolf — 중국 연구팀이 만든 늑대인간 게임 AI. AgentScope + Agent Lightning으로 에이전트끼리 사회적 추론을 RL로 학습
• AgentFlow — 스탠포드 연구팀의 멀티에이전트 프레임워크. Flow-GRPO라는 새로운 알고리즘으로 에이전트 간 협업을 최적화
• Youtu-Agent — 텐센트의 프레임워크. 128-GPU 분산 훈련 환경에서 Agent Lightning을 사용한 대규모 에이전트 훈련 시연

9.3 앞으로의 방향

선택적 에이전트 최적화. 멀티에이전트 시스템에서 모든 에이전트를 훈련할 필요는 없다. "계획 에이전트는 GPT-4o를 쓰고, 실행 에이전트만 RL로 훈련된 소형 모델을 쓴다" — 이런 하이브리드 구성이 가능하다.

연속 학습. 프로덕션에서 실행되는 에이전트의 결과를 지속적으로 수집하고, 이를 바탕으로 모델을 계속 개선하는 온라인 RL 파이프라인. Agent Lightning의 아키텍처는 이를 자연스럽게 지원한다.

멀티모달 에이전트 훈련. 텍스트뿐 아니라 이미지, 비디오를 처리하는 에이전트의 훈련. ChartQA 예제에서 이미 비전-언어 모델의 RL 훈련을 시연하고 있다.

제10장: 직접 시작하기

10.1 설치

pip install agentlightning

10.2 최소 예제: 5분 만에 첫 훈련

import agentlightning as agl

# 1. 에이전트 정의 (기존 코드 그대로)
def my_agent(question: str) -> str:
    # 여기에 기존 에이전트 로직
    response = call_llm(question)
    return response

# 2. Runner 함수에 보상 발행 추가
def run_agent(rollout):
    question = rollout.input["question"]
    expected = rollout.input["expected_answer"]
    
    result = my_agent(question)
    
    # 정답 여부에 따라 보상 발행
    score = 1.0 if result == expected else 0.0
    agl.emit_reward(score)
    return result

# 3. Trainer로 연결
trainer = agl.Trainer(
    algorithm=agl.algorithm.APO(),  # 프롬프트 최적화
    runner=agl.Runner(run_fn=run_agent),
)
trainer.run()

10.3 프로젝트 구조

agent-lightning/
├── agentlightning/        # 메인 Python 패키지
│   ├── algorithm/         # 훈련 알고리즘 (VERL, APO)
│   ├── adapter/           # 데이터 변환기
│   ├── store/             # 데이터 저장소 구현체
│   ├── tracer/            # 추적 백엔드
│   ├── runner/            # 작업 실행기
│   ├── emitter/           # emit_reward 등 헬퍼
│   └── trainer/           # 오케스트레이터
├── examples/              # 10개의 예제 프로젝트
│   ├── spider/            # Text-to-SQL RL
│   ├── rag/               # RAG 파이프라인
│   ├── calc_x/            # 수학 도구 사용
│   ├── apo/               # 프롬프트 최적화
│   └── ...
├── dashboard/             # React 웹 대시보드
└── docs/                  # 문서

마치며: 에이전트의 다음 10년

AI 에이전트 개발은 지금 패러다임 전환의 한가운데에 있다.

2024년까지는 "에이전트를 만드는 것" 자체가 도전이었다. 프레임워크가 부족했고, 도구 연결이 어려웠고, 운영 노하우가 없었다.

2025년, 에이전트를 만드는 것은 쉬워졌다. LangChain, CrewAI, OpenAI Agents SDK — 프레임워크는 넘쳐난다. 하지만 좋은 에이전트를 만드는 것은 여전히 어렵다.

2026년, Agent Lightning이 제시하는 방향은 명확하다. 에이전트를 만들지 말고, 훈련시켜라.

프롬프트를 수동으로 고치는 대신, 에이전트에게 수천 개의 문제를 풀게 하고, 경험에서 배우게 하자. 인간이 전문가가 되는 방식 그대로.

"AI 에이전트를 만드는 것은 코딩이다. AI 에이전트를 훈련시키는 것은 교육이다. Agent Lightning은 그 교육 시스템이다."

참고 자료:

• Microsoft Agent Lightning GitHub: github.com/microsoft/agent-lightning
• 논문: "Agent Lightning: Train ANY AI Agents with Reinforcement Learning" (arXiv: 2508.03680)
• GRPO 논문: "DeepSeekMath: Pushing the Limits of Mathematical Reasoning" (2024)
• VERL 프레임워크: github.com/volcengine/verl
• vLLM Token ID 블로그: "Token ID Handling in Agent RL Training" (2025.10)