여러 도구를 엮어 일을 처리하는 AI가 있다. 매주 월요일 아침, 이 AI가 사내 시스템 여러 곳을 뒤져 주간 현황 보고서를 만든다. 그런데 자료를 긁어오던 도구가 갑자기 응답을 멈춘다. 동시에 보고를 받던 상사가 끼어든다. "이번엔 지난주 말고 이번 분기 누적으로 봐 달라." 도구는 먹통이고, 기준은 바뀌었다. 이 순간 AI는 어떻게 해야 할까.
이런 AI를 '에이전트'라고 부른다. 한 번 묻고 한 번 답하는 챗봇과 달리, 에이전트는 도구를 부르고 그 결과를 본 뒤 다음 행동을 스스로 정한다. 문제는 현실의 도구가 챗봇 질문처럼 얌전하지 않다는 데 있다. 타임아웃이 나고, 권한이 막히고, 사용자가 중간에 방향을 튼다. 사람 운영자라면 당황하지 않을 일이다. 에이전트는 다르다.
런민대학교(Renmin University of China)와 싱가포르국립대 연구팀이 내놓은 Agent-Reflex는 이 어긋남을 정면으로 다룬다. 발상은 단순하다. 실패한 작업 기록에서 "이런 상황에서 이렇게 삐끗하면 이렇게 복구하라"는 규칙을 뽑아, 배포하기 전에 모델에 미리 심어둔다.
에이전트를 길러내는 훈련 환경에는 정작 이런 변수가 거의 없다. 현실의 도구는 흔들리는데, 훈련장은 지나치게 깔끔하다.
여기서 '환경'은 특정 업무에 쓰는 도구·데이터·작업 조건의 묶음을 말한다. 사내 이슈 트래커 하나, 운영 데이터베이스 하나가 각각 하나의 환경이다. 기존 훈련 환경은 이 도구들이 늘 깔끔한 값을 돌려준다고 가정한다. 그래서 에이전트는 실패를 감지하고 되돌아 나오는 연습을 한 번도 못 해본 채 배포된다.
빠진 건 두 종류의 흔들림이다. 하나는 도구가 뱉는 오류다. 다른 하나는 사용자의 끼어듦 — "그게 아니라 이걸로"라며 방향을 트는 교정이다. 특히 기존 사용자 시뮬레이터는 정형화된 템플릿에 머물러, 실제 사용자의 다양한 교정 지시나 말투를 거의 담지 못한다.
이게 작은 모델만의 문제도 아니다. 논문의 Figure 1을 보면, GPT-5.2와 Claude-4.5-Sonnet 같은 최상위 모델조차 노이즈가 없을 때, 사용자가 끼어들 때, 도구가 오류를 낼 때 성공률이 뚝뚝 달라진다. 프런티어급도 환경이 흔들리면 함께 흔들린다. 작은 모델은 더 심하다.
이 문제를 손대 온 방식은 몇 갈래다. 작업 도중 모델이 스스로에게 비판을 달아 고치는 쪽은, 그 비판이 틀린 바로 그 모델에서 나와 그럴듯한 오류를 못 거른다. 실패 기록을 복구가 담긴 형태로 다시 학습하는 쪽은, 복구가 그 작업 한 번에 그쳐 다음에 꺼내 쓸 규칙으로 남지 않는다. 풀 수 있는 과제와 환경을 더 찍어내는 쪽은, 환경은 늘려도 그 안의 실패를 복구 지식으로 바꾸는 장치가 없다. Agent-Reflex는 마지막 쪽에 가깝되, 실패를 환경을 늘리는 재료가 아니라 환경마다 쌓이는 재사용 규칙으로 되돌린다는 점이 다르다. (각 방식의 대표 연구는 부록에.)
Agent-Reflex의 핵심은 반성을 모델이 타고나길 기다리지 않고, 실패에서 뽑아 심을 수 있는 기술로 다룬다는 데 있다. 실패 한 건이 어떻게 규칙이 되고, 그 규칙이 어떻게 행동을 바꾸는지 따라가 보자.
캘린더 조회 도구가 응답을 멈춘다(타임아웃). 한 에이전트는 그대로 작업을 포기했다 — 실패 기록이다. 그런데 같은 타임아웃을 만난 다른 기록은 잠깐 기다렸다 한 번 더 부른 뒤 다음 단계로 넘어갔다 — 성공 기록이다. 두 기록을 짝지어 놓고 보면 갈림길이 선명하다. 여기서 규칙 하나가 나온다. "일시적 타임아웃이면 짧게 기다렸다 한 번만 재시도한다. 단, 권한 거부나 입력 오류처럼 다시 불러도 결과가 같은 오류에는 적용하지 않고 즉시 다른 경로를 찾는다."
이 규칙이 그냥 "오류 나면 재시도"와 갈리는 지점은 꼬리표다. 언제 쓰는지(일시적 타임아웃)와 언제 멈추는지(권한·입력 오류)를 함께 달고 있다. 이렇게 지어낸 오류가 아니라 실제로 관측된 오류에서만 규칙을 뽑아 쌓으면, 557개 환경에서 1,170개 규칙이 담긴 '기술 라이브러리'가 만들어진다. 한 모델이 아니라 여러 모델이 남긴 기록을 섞어, 특정 모델의 사고 습관에 규칙이 쏠리지 않게 했다.
규칙을 손에 쥐었다고 끝이 아니다. 배포된 모델은 이 라이브러리를 참고할 수 없다. 그러니 규칙을 모델에 배게 해야 한다. 세 갈래로 가르친다. 실패한 지점으로 되돌린 뒤 규칙을 참고해 스스로 이어가게 하고(자기 반성), 애초에 세운 계획 자체가 틀렸으면 환경을 처음 상태로 되돌려 과제를 새로 짜게 하고(기술 복구), 규칙을 사용자 교정 메시지로 바꿔 사용자가 중간에 끼어든 것처럼 끼워 넣는다(사용자 중심 반성). 세 갈래 모두 규칙을 '참고용'으로만 쓰고 학습 데이터에는 남기지 않는다. 그래야 모델이 '규칙을 보고 고치는 법'이 아니라 '규칙 없이도 스스로 복구하는 법'을 익힌다.
마지막으로, 모델 자신의 실행에서 복구를 더 끌어낸다. 같은 과제를 깨끗한 환경과 노이즈 낀 환경에서 여러 번 풀게 한 뒤, 두 종류의 신호를 겹쳐 본다. '작업을 끝까지 성공했는가'는 결과를 알려주지만 어디서 틀렸는지는 성기게 짚는다. '그 순간의 행동이 복구 규칙에 맞았는가'는 무엇을 고칠지 콕 짚지만 작업 전체의 성패와 어긋날 수 있다. 아까 그 타임아웃으로 돌아가자. '포기' 대신 '기다렸다 재시도'를 고른 쪽은, 복구 규칙을 미리 본 채점에서 더 높은 점수를 받는다. 그 점수 차이만큼, 규칙을 못 본 모델의 선택을 재시도 쪽으로 끌어올린다. 성긴 결과 신호와 촘촘한 행동 신호가 서로를 보정하는 셈이다.
모든 학습 방법은 같은 작은 모델(Qwen3-8B)에서 출발한다. 출발점을 맞춰야 공정한 비교가 된다. 재는 능력은 둘이다. 서로 다른 도구 환경에서 긴 작업을 끝까지 해내는 힘, 그리고 노이즈가 섞였을 때 버티는 힘. 비교 상대는 같은 크기의 반성 계열·환경 스케일링 계열 모델들, 그리고 참조용으로 상용 프런티어 모델과 29배 큰 오픈 모델이다.
이 비교가 재지 못하는 것도 분명히 해두자. 추론 비용이나 응답 지연 같은 운영 지표는 여기 없다. 성공률은 '할 수 있는가'를 잴 뿐, '얼마나 싸고 빠르게 하는가'는 재지 않는다. (벤치마크 목록과 평균 산식은 부록에.)
이 글의 출발점은 "도구가 먹통이고 기준이 바뀐 순간"이었다. 그 성적부터 보자. 노이즈 대응을 재는 AgentNoiseBench에서 Agent-Reflex의 전체 점수는 29.1이다(초록 기준). 같은 크기의 환경 스케일링·반성 베이스라인은 넘어섰다. 하지만 참조 표의 GPT-5.2(55.8)와는 아직 거리가 멀다.
솔직하게 읽자. 노이즈 견고함을 끌어올린 건 맞다. 그 절대 수준이 프런티어에 못 미치는 것도 맞다. 연구팀도 부록에서 AgentNoiseBench가 이 방법에 분포 밖(out-of-distribution, 학습 때 보지 못한 종류의 상황)이라고 밝힌다. 복구를 학습으로 심는다는 발상이 통하기 시작했다는 신호이지, 노이즈 문제를 풀었다는 선언은 아니다.
이제 노이즈가 적은 평범한 긴 작업으로 넘어가자. 여기선 이야기가 다르다.
| 모델(모두 같은 작은 모델에서 출발) | 장기 도구 사용 평균 |
|---|---|
| Qwen3-8B (베이스라인) | 40.2 |
| NoisyAgent-8B | 43.4 |
| Reflexion-8B | 44.7 |
| EnvScaler-8B | 50.9 |
| Agent-World-8B | 53.6 |
| Agent-Reflex-8B | 58.6 |
| 참조 — Qwen3-235B-A22B | 57.7 |
| 참조 — GPT-5.2 | 64.4 |
| 참조 — Claude-4.5-Sonnet | 72.6 |
| 참조 — Gemini 3 Pro | 72.8 |
작은 모델이 29배 큰 Qwen3-235B-A22B(57.7)를 종합 점수에서 근소하게 넘었다. 상용 프런티어와는 여전히 격차가 있지만, 같은 크기 모델들 사이에서는 머리 하나가 더 크다. 벤치마크별로도 VitaBench 17.5%(Reflexion-8B 6.8%), ACEBench 78.0%(NoisyAgent-8B 52.0%), τ²-Bench 62.1%(Agent-World-8B 54.6%)로 앞선다.
이득이 어디서 났는지도 들여다볼 만하다. ACEBench는 두 가지를 따로 잰다. 개별 행동 하나의 정확도는 85.0%로 베이스라인과 거의 같다. 반면 한 턴 안의 도구 호출을 전부 맞힌 턴의 비율(턴 단위 정확도)은 73.3%로 더 벌어진다. 다만 이 73.3%는 여러 턴을 끝까지 완주한 비율이 아니라 한 턴 단위의 정확도이므로, 그 숫자 자체를 긴 작업 복구 효과의 직접 증거로 읽어선 안 된다. 행동 하나하나의 정확도보다 한 턴을 통째로 틀림없이 채우는 쪽에서 상대적 이득이 더 컸다는 정도로 읽는 게 맞다.
두 성적을 하나로 합쳐 읽으면 안 된다. 58.6은 평범한 도구 작업, 29.1은 노이즈 대응 — 서로 다른 벤치마크 묶음이다.
저자가 인정한 한계는 노이즈 환경에서의 일반화다. 그 위에, 내가 더 깊이 따지고 싶은 지점이 있다.
작업이 성공했다고, 그걸 끌어낸 복구 규칙까지 옳다고 볼 수 있을까. 규칙은 성공 기록과 실패 기록의 대비에서 분석 모델이 뽑는다. 그런데 어떤 복구 행동은 그 상황에서 우연히 통했을 뿐일 수 있다.
같은 타임아웃 상황을 두 기록으로 놓고 보자. 한쪽은 재시도만 했는데 마침 서버가 되살아나 작업을 끝냈다. 다른 쪽은 재시도가 또 막히자 다른 도구로 경로를 틀어 끝냈다. 결과 라벨은 둘 다 '성공'이다. 하지만 앞쪽을 끝낸 건 복구 행동이 아니라 운이었을 수 있다. 여기서 규칙이 '언제 적용되나'(적용 범위)와 '그 규칙 덕분에 성공했나'(인과)는 다른 질문이 된다. 인과를 가리려면 같은 상황에서 그 복구 행동을 했을 때와 하지 않았을 때를 나란히 비교해야 한다. 그 대조 없이는 우연한 성공과 복구의 실제 효과를 가를 수 없다. 규칙의 정확도를 어떻게 보장하느냐는, 이 방법이 분석 모델과 검증기의 품질에 통째로 기댄다는 사실과 곧장 맞닿는다.
현실적인 제약도 둘 있다. 파이프라인이 무겁다 — 557개 환경을 짓고, 9개 모델로 기록을 모으고, 1,170개 규칙을 뽑고, 그 위에 2단계 학습까지. 재현 비용이 작지 않다. 다만 코드·모델·데이터가 공개돼 바닥부터 다시 짤 필요는 적다. 그리고 규칙은 환경 단위로 색인된다. 557개 주제 안에서의 재사용은 강점이지만, 전혀 새로운 유형의 도구 생태계로 얼마나 옮겨 가는지는 이 결과만으로 단정하기 어렵다.
온틀은 AI 프로젝트 매니저를 파견형으로 붙이는 서비스다. 먼저 분명히 해둘 게 있다. 논문은 모델을 다시 학습시켜 복구를 심었지만, 온틀의 복구 기준은 재학습이 아니라 운영 로직과 프롬프트 수준에서 설계된다. 발상은 빌려 오되, 같은 효과가 그대로 옮겨지는지는 따로 확인해야 한다.
앞의 월요일 보고서를 온틀의 AI PM이 맡았다고 하자. 이슈 트래커가 레이트리밋(429, 요청이 너무 잦아 잠시 막히는 오류)으로 멈추고, 운영 DB 조회가 타임아웃 나고, 사장님이 집계 기준을 바꾼다. 핵심은 어떤 오류를 자동으로 재시도하고 어떤 변경을 사람에게 물을지가 고객사마다 다르다는 점이다.
사례 하나를 끝까지 따라가 보자. 429는 잠시 기다렸다 재시도한다. 그래도 막히면 캐시된 과거 스냅샷으로 대체하되, "이 수치는 며칠 기준"이라고 반드시 표시한다. 여기까지는 자동이다. 그런데 "분기 누적으로 바꿔라"는 지시는 다르다. 조회 범위가 넓어지면 비용이 커지고, 건드리는 데이터의 권한도 달라진다. 비용·권한·데이터 범위가 움직이는 변경 — 이게 사람 확인을 요구하는 선이다. 단순히 "계획을 바꾸니까"가 아니라, 바뀌는 게 무엇이냐로 선을 긋는다.
그래서 첫 걸음은 하나다. 자사 핵심 도구 몇 개에 한정해 두 숫자를 재는 것. 기존 방식 대비 '복구 뒤에 작업을 실제로 끝까지 마친 비율', 그리고 '잘못된 대체 데이터를 쓴 비율'. 완주율만 보면 급하게 틀린 데이터로 채운 경우를 놓친다. 두 숫자가 같이 나와야 나머지 설계가 의미를 갖는다.
논문이 붙인 단계 이름은 복구 규칙 발굴(RSD), 규칙을 행동으로 바꾸기(ReSFT), 스스로의 실행에서 다듬기(ORPO)다. 세 가지 학습 전략은 자기 반성(SR)·기술 복구(KR)·사용자 중심 반성(UR)으로 표기된다.
기존 접근 세 흐름의 대표 연구와 한계는 다음과 같다.
| 접근 | 대표 연구 | 한계 |
|---|---|---|
| 실행 중 반성하기 | Reflexion, Self-Refine, ExpeL | 비판이 틀린 그 모델 자신에게서 나와, 그럴듯한 오류를 걸러내지 못한다 |
| 실패 기록으로 훈련하기 | Agent-R, ReflectRL, LoongReflect, NoisyAgent | 복구가 그 작업 한 번에 그치고, 다음에 꺼내 쓸 규칙으로 남지 않는다 |
| 연습 환경 늘리기 | EnvScaler, ScaleEnv, Agent-World, EnvACE / Simia, GenEnv | 환경은 늘려도 실패를 복구로 바꾸는 장치가 없다. 일부는 피드백을 지어내 환각 위험도 있다 |
평가 벤치마크. 장기 도구 사용은 BFCL-v4, ACEBench, ToolSandbox(200개 층화 과제), τ²-Bench(Barres et al.), VitaBench 다섯이고, 노이즈 상호작용은 AgentNoiseBench(τ²-Bench·VitaBench의 도구·사용자 노이즈 설정 위에서 측정)다. 전체 점수는 다섯 벤치마크 평균의 단순 평균이며, BFCL-v4와 ACEBench의 하위 평균은 각 벤치마크 공식 채점 방식을 따른다. 비교군에는 반성 계열(Reflexion, ExpeL, Agent-R, NoisyAgent), 환경 스케일링 계열(Simulator, TOUCAN, AWM, EnvACE, EnvScaler, Agent-World), 궤적 수준 RL 알고리즘들, 참조용 프런티어 모델(GPT-5.2, Claude-4.5-Sonnet, Gemini 3 Pro)과 Qwen3-235B-A22B가 들어간다.
환경 구축. Agent-World 방식을 따라 검색·브라우저·코딩·운영체제 도구를 갖춘 리서치 에이전트가 주제별 데이터베이스를 짓고, 코딩 에이전트가 도구와 단위 테스트를 만든다. 컴파일되고 테스트를 통과하며 상태 전이 제약과 검증을 만족하는 도구만 남는다. 각 환경은 데이터베이스, 검증된 도구 집합, 검증기(verifier, 과제가 제대로 끝났는지 판정하는 채점 장치)로 구성되고 주제당 60개의 검증 가능한 과제가 붙는다. 긴 궤적은 규칙 기반 지표만으로 평가하기 어려워, 분석 모델과 검증기가 함께 각 궤적에 성공·실패 라벨을 붙인다.
데이터 수집. 9개 공개 벤치마크에서 에이전트를 돌려 도구 반환값 177,700건을 모았고, 그중 오류가 24,510건이었다. 이를 겉으로 드러나는 형태에 따라 여덟 개 '오류 패밀리'로 묶어 각 환경의 도구 반환에 확률적으로 섞고, 드문 오류도 복구를 배울 만큼 쌓이도록 여덟 패밀리에 균형을 맞췄다. 궤적은 5개 계열·4B부터 284B까지 걸친 9개 모델에서 모았다.
학습 목적함수. 결과 기반 강화학습과 토큰 단위 반성 유도 증류(on-policy distillation)를 결합한다. 한 그룹을 롤아웃할 때 깨끗한 것과 오염된 것을 따로 정규화하지 않고 섞어서 정규화하는 것이 핵심이다. 그래야 진짜 실패가 별도 대비군으로 떨어져 나가지 않고 온폴리시 분포 안에 남는다. 규칙을 본 버전(교사)과 못 본 버전(학생)의 점수 차이는 신뢰도로 가중한 OPD 목적함수(Wu et al., 2026, SEED 방식)로 바뀐다. 그래디언트는 교사 가지로는 흐르지 않고 학생 가지로만 흘러, 교사가 인정한 토큰에서 학생 점수가 오르도록 최적화된다.
작은 모델을 쓰려는 이유는 배포와 운영 쪽에 있다. 다만 이 논문은 추론 비용이나 응답 지연을 직접 재지 않았으니, '비용 대비 유리하다'를 이 연구의 결론으로 내세울 수는 없다. 참조로 쓰인 Qwen3-235B-A22B는 총 235B 파라미터 중 22B만 활성화하는 MoE(전문가 혼합) 구조라, 총 크기가 29배라고 해서 운영 비용이 그만큼 벌어진다고 단정하기도 어렵다. 이 논문이 실제로 보여준 건 둘이다. Figure 1에서 보듯 큰 모델도 노이즈가 섞이면 흔들린다는 점, 그리고 작은 모델이 특정 환경의 복구를 익히면 같은 크기 모델들을 앞서고 참조 표의 Qwen3-235B-A22B와도 겨룰 수준에 올랐다는 점이다(성공률 기준).
에이전트가 외부 도구에 붙는 표준 통로인 MCP에서 왔다. 연구팀은 Smithery에서 많이 쓰이는 MCP 서버 명세 557개를 환경 주제로 삼았다. 실제 배포에서 이 통로가 타임아웃이나 서비스 오류 같은 노이즈를 돌려준다는 점이 바로 이 논문이 겨냥한 현실이고, 표준 MCP 포맷으로 평가했다는 점도 실제 배포 조건에 가깝다.
아니다. 규칙은 학습 때 '참고용'으로만 쓰고 버린다 — 모델이 규칙 없이도 스스로 복구하게 만드는 게 목적이기 때문이다. 예외가 하나 있다. 사용자 교정 메시지는 배포 때도 실제로 화면에 보이는 정보라, 그것만은 입력에 남긴다.