원본: arxiv.org/abs/2605.24426 | HTML 전문
형식: 논문 내용을 바탕으로 핵심 질문과 답변을 인터뷰 스타일로 재구성함.
에이전트 학습에서 강화학습을 쓸 때, 우리는 보통 “모델(정책)을 어떻게 업데이트할까”에만 집중한다. 환경은 고정되어 있다고 가정한다. 하지만 에이전트가 배우면서 능력이 변하면, 환경이 제공하는 학습 신호도 함께 바뀌어야 하지 않을까?
SEAL은 이 질문에서 출발한다. 에이전트 정책과 학습 환경을 폐루프 공동 진화(closed-loop co-evolution) 시키는 프레임워크다.
Q1. SEAL이 뭔가요?
Synergistic Evolution of Agents and Learning Environments의 약자예요. Ant Group, 서호대학교(Westlake University), 미시간대, 중국과기대 연구진이 2026년 5월에 발표했어요.
핵심 아이디어는 간단합니다: 에이전트가 실패한 이유를 진단하고, 그 진단 결과를 에이전트 정책 업데이트와 환경 개선에 동시에 사용한다.
기존 방식은 둘 중 하나만 건드렸어요. 모델 중심 진화는 정책만 업데이트하고 환경은 그대로, 환경 중심 진화는 과제 난이도나 다양성만 바꾸고 정책은 그대로. SEAL은 양쪽을 같이, 그리고 서로 연결해서 움직입니다.
Q2. 왜 필요한가요? 기존 방식의 문제가 뭔가요?
논문은 이걸 Agent-Environment Misalignment(에이전트-환경 정렬 불일치) 라고 부릅니다.
구체적인 예를 들어볼게요. 에이전트가 항공권 검색 도구를 쓸 때, 도시 이름을 넣어야 할 자리에 공항 코드를 넣었다고 칩시다. “서울”이라고 넣어야 하는데 “ICN”이라고 넣은 거죠.
기존 환경은 이렇게 응답합니다:
Error: Invalid parameter
에이전트는 실패했다는 건 압니다. 하지만 왜 실패했는지, 어디서부터 고쳐야 하는지 모릅니다. 전제 조건 조회를 빠뜨린 건지, 인자 타입을 잘못 쓴 건지, 에러 후 복구를 못 한 건지 구분이 안 돼요.
문제는 에이전트가 학습하면서 능력이 변하면 어디서 막히는지도 달라진다는 거예요. 초반에는 도구 자체를 모르니까 기본 사용법에서 막히고, 중반에는 인자 타입 오류에서 막히고, 후반에는 복구 실패에서 막혀요. 그런데 환경이 고정되어 있으면, 중반에 막히는 에이전트에게 계속 초반 수준의 피드백만 줍니다.
이게 Agent-Environment Misalignment예요.
Q3. 어떻게 작동하나요?
SEAL은 세 단계로 돌아갑니다.
1단계: 검증 기반 실패 진단
에이전트가 환경과 상호작용해서 궤적(trajectory)을 만들면, 각 턴마다 실행 가능한 증거(executable evidence) 로 진단 라벨을 붙입니다. LLM이 자유 형식으로 평가하는 게 아니라, 파서 체크, 도구 스키마 검증, 실행 에러, 상태 전이 같은 결정론적 규칙으로 분류해요.
진단 라벨의 예: invalid_tool_call, argument_mismatch, missing_tool_call, recovery_failure, response_mismatch 등.
2단계: 학습 인터페이스 진화
진단 결과를 바탕으로 훈련 시간에만 환경이 노출하는 정보를 바꿉니다. 벤치마크 자체는 건드리지 않아요.
세 가지 컴포넌트가 있어요:
- ϕ_schema: 도구 스키마에서 유도하는 단서. 필수 인자, enum 제약, 인자 타입, 올바른 호출 형식을 노출
- ϕ_err: 실행 에러를 복구 지향 피드백으로 변환. 정답은 알려주지 않으면서 어떻게 고쳐야 하는지 힌트 제공
- ϕ_cap: 현재 에이전트의 반복적 실패 패턴에서 타겟팅된 피드백 선택
예를 들어 argument_mismatch 진단이 반복되면 스키마 단서와 제약 정보가 활성화되고, recovery_failure가 반복되면 구조화된 에러 피드백이 활성화됩니다. 정답 시퀀스나 숨겨진 파라미터는 절대 노출하지 않아요.
3단계: 진단 가이드 장점 재가중
같은 보상(실패 = 0)을 받은 두 궤적이라도 학습 가치가 달라요. invalid_tool_call이 명확한 수정 방향을 주는 반면, response_mismatch는 애매해요.
SEAL은 각 진단 유형에 학습 효용(utility) 점수를 매기고, 궤적별 진단 프로파일로 가중치를 계산합니다. 이 가중치로 GRPO 장점(advantage)을 재조정해요. 보상의 방향은 그대로(A_j), 각 궤적의 기여도만 진단 효용으로 조절하는 방식입니다.
Q4. 결과가 어떤가요?
세 백본 모델, 400개 훈련 샘플만으로 측정한 결과예요.
| 백본 | 베이스라인 | SEAL | 향상 |
|---|---|---|---|
| Qwen2.5-7B | 29.75 | 56.00 | +26.25 |
| Llama-3.1-8B | 37.75 | 51.25 | +13.50 |
| Qwen2.5-72B | 60.75 | 69.00 | +8.25 |
400개 샘플이라는 게 포인트예요. 보통 에이전트 RL은 수천~수만 개의 롤아웃이 필요한데, SEAL은 환경 진화로 롤아웃의 질을 끌어올려서 샘플 효율성이 극적으로 높아진 거예요.
OOD(Out-of-Distribution) 전이도 확인했어요. 훈련에 쓰지 않은 도구 세트와 과제에서도 성능이 올라갑니다. 환경이 에이전트의 구체적 실패에 맞춰 진화하니까, 특정 과제에 과적합되는 게 아니라 도구 사용 능력 자체가 개선되는 거죠.
Q5. 기존 방법과 어떻게 다른가요?
세 가지 축으로 비교할 수 있어요.
vs. 모델 중심 진화 (AgentEvolver, RAGEN 등) 이 방법들은 정책만 업데이트합니다. 환경이 고정되어 있으니, 에이전트가 배우면서 능력이 변해도 동일한 환경에서 계속 롤아웃을 수집합니다. 초기에 유용했던 학습 신호가 나중에는 노이즈가 되는 거죠. SEAL은 환경도 같이 진화하니까 학습 신호의 질이 유지됩니다.
vs. 환경 중심 진화 (커리큘럼 러닝, 과제 난이도 조절 등) 이 방법들은 과제의 다양성이나 난이도를 조절합니다. 하지만 에이전트의 실제 실패 원인에 기반하지 않으면, 어려운 과제를 준다고 해서 에이전트가 고쳐야 할 약점을 정확히 타격하진 못해요. SEAL은 검증 기반 진단으로 에이전트가 지금 어디서 막히는지 알아내고, 그 지점을 정확히 공략합니다.
vs. 에이전트-환경 공동 설계 (AgentGym, GenEnv 등) 가장 가까운 선행 연구들이에요. 차이점은 SEAL이 벤치마크 공정성을 보존한다는 거예요. 과제, 도구 의미론, 검증기는 그대로 두고, 오직 훈련 시간 학습 인터페이스만 진화시킵니다. 평가할 때는 진화된 인터페이스를 제거하고 원래 환경으로 측정해요.
Q6. 한계점은 없나요?
논문이 명시적으로 논의하지는 않지만, 몇 가지 생각해볼 점이 있어요.
진단 분류기의 의존성. 실패 원인을 규칙 기반으로 분류하는데, 이 분류가 정확하지 않으면 환경 진화도 엉뚱한 방향으로 갈 수 있어요. 복잡한 멀티턴 실패에서는 여러 원인이 꼬여 있을 텐데, “주된 원인”을 하나만 고르는 게 항상 가능한지 의문이에요.
범위 제한. 현재는 도구 사용(tool-use) 환경에서만 실험했어요. 웹 탐색, 코드 생성, 로봇 제어 같은 다른 에이전트 영역에서도 같은 프레임워크가 통할지는 추가 검증이 필요합니다.
학습 인터페이스 진화의 한계. 환경이 노출하는 정보를 바꾸는 건 “더 좋은 설명서를 써준다”에 가깝습니다. 근본적으로 과제 구조나 도구 자체를 개선하는 건 아니에요. 물론 논문은 이걸 의도한 설계选择이라고 명확히 하고 있지만요.
정리
SEAL의 통찰은 명확합니다: 에이전트가 배우면 환경도 따라서 배워야 한다.
고정된 환경에서 에이전트만 업데이트하는 건, 학생이 성장하는데 교과서는 예전 버전인 것과 같아요. SEAL은 학생이 틀린 문제를 진단하고, 그 진단으로 교과서를 업데이트하고, 업데이트된 교과서로 다시 공부하게 만드는 폐루프 시스템이에요.
400개 샘플로 +26%p라는 숫자는 이 폐루프가 얼마나 강력한지 보여줍니다. 데이터가 부족한 실제 환경에서 특히 유용할 거예요.
한 줄 결론
에이전트와 환경을 같이 진화시키니, 400개 샘플만으로도 26%포인트가 올랐다.
참고 링크
- SEAL arxiv.org/abs/2605.24426 | HTML 전문 | HuggingFace