포스트

기존 AI 에이전트 코드를 안 고치고 RL을 붙일 수 있을까? Agent Lightning의 범위

Agent Lightning은 에이전트 비즈니스 로직을 크게 다시 쓰지 않고 RL 파이프라인을 분리할 수 있지만, 엔드포인트, 추적, 보상 함수까지 아무 변경 없이 붙는 것은 아닙니다. “코드 변경 없음”은 실행 프레임워크와 학습 알고리즘의 결합을 줄인다는 의미로 읽어야 합니다.

Microsoft의 Agent Lightning 저장소는 LangChain이나 다중 에이전트 시스템의 실행 이력을 학습 데이터로 바꾸는 미들웨어를 제안합니다. 핵심은 에이전트가 일하는 경로와 PPO, GRPO 같은 알고리즘이 정책을 업데이트하는 경로를 분리하는 것입니다.

Runner, Store, Trainer가 실행과 학습을 나눈다

Agent Runner는 기존 에이전트를 실행합니다. Lightning Store는 LLM 호출과 도구 사용을 span 형태로 받아 비동기 저장하고, 상태, 행동, 보상의 전이로 정리합니다. Algorithm과 Trainer는 이 데이터를 가져와 정책을 최적화합니다. 운영 요청이 학습 클러스터의 속도에 직접 묶이지 않게 하는 구조입니다.

원문은 OpenAI 호환 프록시로 에이전트의 LLM 호출을 경유시키는 방식을 설명합니다. endpoint나 환경 변수를 프록시로 바꾸면 호출 기록을 모을 수 있지만, 파일 작업과 외부 도구 결과까지 자동으로 완전한 MDP가 되는 것은 아닙니다. 성공 조건과 관찰값을 어떤 span에 담을지 설계해야 합니다.

“한 줄도 안 고친다”보다 관찰 가능한지가 중요하다

프록시가 보는 것은 주로 모델 요청과 응답입니다. 에이전트가 데이터베이스를 바꿨는지, 생성한 SQL이 실제 정답인지 알려면 실행 결과와 검증기를 추가해야 합니다. 기존 코드가 독자 프로토콜을 쓰거나 모델을 직접 로컬 호출하면 프록시 경로 자체가 맞지 않을 수 있습니다.

원문의 파이썬 코드는 Runner, PPO, Trainer의 관계를 단순화한 예시입니다. 실제 API 버전, 모델 서버, 데이터와 분산 학습 설정이 빠져 있어 그대로 실행되는 완전한 학습법이 아닙니다. 현재 전제는 Microsoft 소개 글과 저장소를 같은 시점으로 맞춰 확인해야 합니다.

보상 함수가 틀리면 에이전트는 더 효율적으로 틀린다

Text-to-SQL에서 실행 성공만 보상하면 의미가 틀린 쿼리도 점수를 받을 수 있습니다. 속도만 보상하면 SELECT 1처럼 질문을 피하는 행동을 학습할 수 있습니다. 정확성, 안전성, 비용, 사람 선호를 함께 반영하고 보상과 독립된 검증 세트를 둬야 합니다.

운영 로그에는 개인정보와 도구 출력의 비밀값이 섞일 수 있습니다. Store에 보내기 전 마스킹하고, 학습 데이터 보존과 삭제 정책을 정해야 합니다. 실패 사례가 적은 고위험 작업은 온라인 탐색보다 시뮬레이션이나 승인된 오프라인 데이터로 제한하는 편이 안전합니다.

코드 비용 대신 GPU, 지연, 운영 비용이 생긴다

PPO, GRPO를 제대로 돌리려면 추론용 vLLM과 학습용 verl 계열 인프라, 가중치 갱신과 버퍼 관리가 필요하다는 것이 원문의 설명입니다. 에이전트 코드를 덜 바꾸더라도 GPU 비용은 커질 수 있습니다. 모든 호출이 프록시를 거치면 네트워크 지연과 단일 장애점도 추가됩니다.

도입 시험은 보상이 명확한 작업 하나에서 시작해야 합니다. 기준 에이전트와 학습 후 에이전트의 성공률, 위험 행동, 토큰, GPU 비용, 프록시 지연을 함께 비교하고 롤백 가능한 정책 버전을 보관합니다. Agent Lightning의 강점은 에이전트와 RL을 분리하는 인터페이스이지, 보상 설계와 학습 운영을 없애는 자동 개선 버튼이 아닙니다.

어떤 에이전트가 학습 후보가 되기 쉬운가

정답과 실패를 자동으로 판정할 수 있고 같은 유형의 작업이 반복되는 에이전트가 첫 후보입니다. 테스트가 통과하는 코드 수정, 실행 결과를 비교할 수 있는 SQL, 정답 문서가 있는 검색 작업은 보상 신호를 만들기 비교적 쉽습니다. 반대로 전략 보고서나 사람 간 협상처럼 결과가 늦게 나타나고 평가가 주관적인 업무는 온라인 RL의 원인을 해석하기 어렵습니다.

현재 에이전트가 프롬프트, 도구, retrieval 문제로 실패하는지도 먼저 확인해야 합니다. 필요한 문서를 받지 못하는데 정책만 학습하면 모델은 부족한 정보로 보상 함수를 공략할 수 있습니다. 학습 전 baseline의 실패를 데이터, 도구 오류, 판단 오류와 실행 오류로 나누면 RL이 실제 병목에 맞는지 알 수 있습니다.

span을 학습 가능한 전이로 어떻게 바꾸나

LLM 요청 하나만으로는 상태와 행동의 경계가 충분하지 않을 수 있습니다. 사용자가 준 목표, 모델이 본 문서, 선택한 도구와 실행 결과, 최종 검증값을 같은 trace id로 묶어야 합니다. 도구가 외부 시스템을 바꾸는 경우 실행 전후 상태도 남겨야 보상과 행동을 연결할 수 있습니다.

그렇다고 모든 원문을 Store에 복사하면 개인정보와 저장 비용이 커집니다. 학습에 필요한 필드만 허용 목록으로 정하고, 비밀값을 수집 전에 지우며, 원문 대신 해시나 참조 id를 남기는 방식을 검토합니다. trace schema가 바뀌면 이전 데이터와 섞이지 않도록 버전을 붙이고, 누락된 span은 학습 대상에서 제외해야 합니다.

보상은 어떤 단계로 설계해야 하나

첫 단계에서는 결과 정확성과 안전 위반처럼 검증 가능한 항목만 둡니다. 다음으로 토큰 수와 지연 같은 비용을 추가하되 정확성보다 비용이 압도하지 않게 가중치를 확인합니다. 마지막에는 과정 보상을 넣더라도 최종 정답과 독립된 holdout 검증을 유지합니다. 보상 구성 요소별 점수를 로그에 남기면 총점이 올랐을 때 무엇이 변했는지 설명할 수 있습니다.

보상 해킹 검사는 의도적으로 쉬운 우회로를 넣어 진행합니다. 빈 답변, 도구를 호출하지 않는 답변, 검증기를 속이는 문자열, 실패를 성공으로 표시한 결과가 높은 점수를 받지 않는지 확인합니다. reward model 자체를 쓰는 경우에는 그 모델과 다른 사람 평가 또는 규칙 기반 검증을 함께 둬야 같은 편향을 강화하는 일을 줄일 수 있습니다.

offline과 online 학습은 어떻게 나눌까

처음에는 운영 로그의 승인된 trace로 offline 실험을 하는 편이 안전합니다. 고정 데이터에서 정책 후보를 만들고, holdout 작업과 시뮬레이터에서 위험 행동을 검사합니다. 다음 단계는 실제 변경을 하지 않는 shadow mode입니다. 새 정책의 제안과 기존 정책의 결과를 비교하되 사용자는 기존 결과를 받습니다.

제한된 online 탐색으로 넘어갈 때는 업무 범위, 사용자 수, 하루 rollout 수와 비용을 고정합니다. 삭제, 결제, 권한 변경은 학습 탐색에서 제외하거나 사람 승인 뒤에만 실행합니다. 정확도 하락, 위험 행동, 비용 초과 중 하나라도 임계값을 넘으면 직전 checkpoint로 되돌리는 자동 중단 조건이 필요합니다.

학습 뒤 개선을 어떻게 증명하나

학습에 사용하지 않은 시점과 도메인의 작업을 고정 평가 세트로 둡니다. 평균 성공률뿐 아니라 가장 어려운 작업군, 재시도 횟수, 잘못된 도구 호출과 안전 위반을 비교합니다. 모델이 답을 짧게 만들어 비용은 줄였지만 중요한 단계를 생략할 수 있으므로 품질과 비용의 Pareto curve를 보는 편이 좋습니다.

같은 데이터로 프롬프트 개선, supervised fine-tuning과 RL을 비교하면 복잡성의 대가를 판단할 수 있습니다. 단순 프롬프트 변경이 비슷한 개선을 낸다면 RL 인프라를 운영할 이유가 약합니다. 개선이 통계적으로 안정적이고 새로운 작업 분포에서도 유지될 때만 “스스로 학습했다”는 표현이 의미를 가집니다.

총비용에는 어떤 항목을 넣어야 하나

GPU 시간 외에 rollout을 위한 도구 사용료, Store 저장, 전송, 검증기 실행, 데이터 검수와 실패 복구 시간이 들어갑니다. 프록시와 Trainer의 가용성, 모델 checkpoint 배포와 롤백도 운영 대상입니다. 한 번의 실험 비용보다 월간 업무량당 추가 성공 건수와 비용을 비교해야 합니다.

팀이 RL 디버깅 경험이 없다면 장애 원인을 찾는 시간도 큽니다. 보상, trace, policy, 도구 버전을 한 실행에 묶어 재현할 수 있어야 하고, 학습 데이터 삭제 요청이 checkpoint에 어떻게 반영되는지도 정책으로 정해야 합니다. 인터페이스 분리가 운영 책임까지 외부로 옮겨 주지는 않습니다.

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

자주 묻는 질문

정말 에이전트 코드를 한 줄도 바꾸지 않아도 되나요?

기존 호출을 호환 프록시로 돌리는 경우 비즈니스 로직 변경은 작을 수 있습니다. 하지만 성공 결과, 도구 상태와 보상을 관찰할 계측은 필요하며 독자 호출 방식에는 adapter가 필요할 수 있습니다.

PPO와 GRPO 중 무엇을 먼저 써야 하나요?

알고리즘 이름보다 검증 가능한 보상과 안정적인 rollout이 먼저입니다. 저장소가 지원하는 현재 구성과 업무 특성, GPU 예산으로 작은 기준 실험을 한 뒤 선택해야 합니다.

운영 로그를 그대로 학습해도 되나요?

아닙니다. 비밀값, 개인정보를 제거하고 사용 목적과 보존 기간을 정해야 합니다. 실패나 특정 사용자군이 과대표집됐는지 확인하고 승인된 trace만 학습 세트에 포함해야 합니다.

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1

키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    13개 장 18 분읽는 시간