AI 에이전트 프롬프트 최적화, 실패를 걸러야 성능 오른다

에이전트가 실패했다고 다 가르칠 필요는 없다

AI 에이전트를 실제 업무에 붙여본 사람이라면 익숙한 광경이 있다. 어제까지 잘 돌던 작업이 오늘은 엉뚱한 버튼을 누르고, 같은 프롬프트로 열 번 돌리면 세 번은 실패한다. 이럴 때 요즘 흔히 쓰는 처방이 프롬프트 자동 최적화다. 실패한 기록을 모델에게 되돌려 보여주고 프롬프트를 스스로 고치게 하는 방식으로, GEPA가 대표적이다.

그런데 이 처방에는 조용한 가정이 하나 깔려 있다. 실패 기록에는 배울 것이 있다는 가정이다. 10월 27일 arXiv에 공개된 GEPA-Curator 논문은 바로 그 가정을 문제 삼는다.

무엇을 했는가

저자들의 출발점은 단순하다. 에이전트의 실패 원인은 크게 네 갈래다.

네 갈래 중 하나만 프롬프트 수정으로 해결된다. 나머지 세 경우에 프롬프트를 고치는 것은 멀쩡한 지시문을 엉뚱한 방향으로 비트는 일이다. 그래서 저자들은 최적화기에 무엇을 보여줄지 고르는 단계를 앞에 붙였다.

GEPA-Curator는 두 부분으로 되어 있다. 첫째는 과제 큐레이션으로, 학습 신호가 불안정할 것 같은 과제를 최적화 대상에서 미리 빼낸다. 둘째는 성공 사례 검색으로, 같은 과제에서 과거에 성공했던 궤적을 찾아 최적화기에 참고 자료로 함께 넣는다. 실패만 보던 최적화기에 성공의 모습도 같이 보여주는 셈이다.

결과는 GoBrowse, ALFWorld, AppWorld, tau-bench 네 개 에이전트 벤치마크에서 측정했다. 최적화를 수행하는 모델로는 Gemini 3.1 Pro와 Claude Opus 5를 각각 썼다. 평균 성능에서 GEPA 대비 최대 20.7%, 또 다른 비교군인 ACE 대비 최대 21.2% 개선됐다.

그래서 진짜 의미하는 것

숫자만 보면 프롬프트 최적화 20% 개선으로 읽힌다. 하지만 더 중요한 것은 개선의 방향이다. 이 논문은 최적화 알고리즘을 더 똑똑하게 만들어 점수를 올린 것이 아니다. 알고리즘에 덜 보여줘서 점수를 올렸다.

오해하기 쉬운 지점이 있다. 실패 데이터를 버리면 정보가 줄어드니 손해라는 직관이다. 여기서 버리는 것은 실패 자체가 아니라 신뢰할 수 없는 실패다. 환경이 멈춰서 실패한 기록을 가지고 프롬프트를 고치면, 다음에는 멈추지 않은 환경에서도 프롬프트가 나빠진다. 잡음을 신호로 착각한 학습은 아무것도 안 한 것보다 나쁘다.

실무에서 바로 가져갈 함의는 세 가지다. 첫째, 에이전트 성능이 안 나올 때 프롬프트부터 의심하는 습관을 잠시 접고 실패 로그를 원인별로 분류해 보는 것이 좋다. 둘째, 자동 최적화 도구를 도입하더라도 입력 데이터를 그대로 흘려보내지 말고 선별 장치를 앞에 두는 것이 안전하다. 셋째, 채점기의 품질이 곧 최적화의 상한이다. 채점이 흔들리면 그 위에 쌓은 모든 자동화가 흔들린다.

한계도 분명하게 짚어 둘 필요가 있다. 개선 폭 최대 20.7%는 말 그대로 최대치이고 벤치마크 평균이 아니다. 네 개 벤치마크 모두 연구용 환경이라 실제 업무 환경에서 같은 폭이 재현된다고 보기는 어렵다. 또 어떤 과제를 걸러낼지 판정하는 기준 자체가 추가 설정을 요구하는 부분이라, 도입 부담이 공짜는 아니다.

마무리

더 많이 학습시키면 좋아진다는 직관이 통하지 않는 영역이 점점 늘고 있다. 에이전트의 실패 기록도 그중 하나다. 무엇을 보여줄지 고르는 일이 어떻게 학습시킬지 정하는 일만큼 중요해졌다.

출처: Zack Yu, Nicholas Lee, Minjae Lee 외, "GEPA-Curator: Curated Learning for Self Improving Agents", arXiv:2610.37651, 2026년 10월 27일.