버클리·스탠퍼드 연구진, 강화학습 없이 LLM 최적화하는 GEPA 공개

특정 업무에 맞게 AI 시스템을 최적화할 때, 지금까지는 수만 번의 시행착오를 거치며 단순한 점수를 주는 강화학습(RL) 방식에 의존하는 경우가 많았습니다.

하지만 이 방식은 시간과 비용이 너무 많이 듭니다. UC 버클리, 스탠퍼드 대학교, 데이터브릭스 연구진은 이런 비효율을 크게 줄여주는 새로운 최적화 방법론 'GEPA'를 공개했습니다.

GEPA는 AI를 맹목적으로 반복 실행하지 않습니다. 대신 LLM 자체의 언어 이해력을 활용해 실행 오류를 스스로 진단하고 프롬프트를 진화시킵니다. 기존 기법보다 뛰어난 정확도를 내면서도, 필요한 시험 실행 횟수는 최대 35분의 1로 줄였습니다.

점수 매기기 대신 자연어 피드백으로 반성

요즘 기업들이 구축하는 AI는 단순히 모델을 한 번 호출하고 끝나는 구조가 아닙니다. 여러 LLM 모듈과 외부 데이터베이스, 코드 인터프리터 등을 하나로 엮은 복합 AI 시스템이 대다수입니다.

이런 시스템을 DeepSeek-R1 등에 쓰인 GRPO 같은 강화학습으로 최적화하려면 샘플 비효율성이라는 큰 장벽을 마주하게 됩니다. 시스템 전체를 블랙박스로 취급하고 '7점' 같은 단순한 수치 보상만 주다 보니, 올바른 방향을 잡기 위해 수만 번에서 수십만 번의 롤아웃이 필요합니다.

논문 공동 저자인 UC 버클리 박사과정 락샤 아그라왈(Lakshya A Agrawal)은 많은 팀에게 강화학습은 비용과 복잡성 때문에 비현실적이며, 결국 사람이 직접 프롬프트를 수정하는 수작업에 머물러 있었다고 지적했습니다. 게다가 미세조정이 불가능한 최상위 폐쇄형 모델을 쓸 때는 수십만 번의 API 호출 비용을 감당하기 어렵습니다.

GEPA(Genetic-Pareto)는 희소한 점수 보상 대신 풍부한 자연어 피드백을 도입했습니다. 시스템의 추론 과정, 도구 호출 내역, 컴파일러 오류 메시지는 모두 텍스트로 변환할 수 있다는 점에 착안한 것입니다.

GEPA는 여러 프롬프트를 유전자 풀처럼 관리합니다. 몇 차례 실행 후 전체 실행 기록과 결과를 LLM에 전달하면, LLM이 오류 원인을 자연어로 분석합니다. 예를 들어 코드 생성 중 컴파일러 에러를 확인한 LLM은 특정 라이브러리 버전을 명시하도록 프롬프트를 직접 수정합니다.

단일 최고점 대신 스페셜리스트 풀 유지

GEPA의 또 다른 축은 파레토(Pareto) 기반 선택 전략입니다.

평균 점수가 가장 높은 프롬프트 하나만 남기면 지역 최적해(local optimum)에 갇히기 쉽습니다. GEPA는 특정 사례에서 뛰어난 성과를 낸 '전문가' 프롬프트 풀을 다양하게 유지합니다.

비록 전체 평균 점수가 최고는 아니더라도, 까다로운 특정 엣지 케이스를 잘 해결한 프롬프트를 후보에 남겨둡니다. 이렇게 다양한 성공 전략에서 샘플링을 진행함으로써 광범위한 입력에서도 안정적으로 작동하는 일반화된 프롬프트를 찾아냅니다.

아그라왈은 비싼 실행 과정에서 최대한 알찬 학습 신호를 뽑아내는 '피드백 엔지니어링'이 이 시스템의 핵심이라고 설명했습니다.

왜 중요한가

우리는 GEPA가 최근 AI 업계의 지나친 강화학습 맹신을 꼬집는 매우 실용적인 대안이라고 생각합니다.

복합 AI 에이전트나 데이터 분석 파이프라인을 구축하는 개발자에게 GPU 클러스터를 빌려 강화학습 인프라를 운영하는 것은 진입 장벽이 너무 큽니다. 반면 GEPA를 활용하면 미세조정이 불가능한 최고 성능의 상용 API를 그대로 쓰면서도 프롬프트 수준에서 시스템 성능을 자동 최적화할 수 있습니다.

시행착오 횟수를 최대 35분의 1로 줄인다는 것은 API 호출 비용과 도구 실행 비용을 직접적으로 아끼고, 개발 주기를 대폭 단축한다는 의미입니다. 고가의 외부 API나 복잡한 코드 실행이 얽힌 파이프라인을 다룬다면 당장 도입을 검토해 볼 가치가 있습니다.

다만 한계도 뚜렷해 보입니다. GEPA의 성공 여부는 실행 로그와 오류 메시지가 얼마나 풍부한지에 전적으로 달려 있습니다. 도구의 실패 원인이 명확한 텍스트로 남지 않는 환경이라면 LLM도 제대로 된 진단을 내릴 수 없습니다. 그럼에도 단순한 숫자 점수에 기대 수만 번 무작위로 돌리는 것보다, 모델에게 에러 로그를 읽히고 지시사항을 고치게 하는 편이 훨씬 똑똑한 접근입니다.