자기 진화형 AI 에이전트 (Self-Evolving AI Agents): 최적화 도구는 쉬운 부분이다

현재 프로덕션 환경에는 두 종류의 AI 에이전트가 있습니다. 첫 번째는 당신이 보살펴야 하는 에이전트입니다. 시스템 프롬프트 (system prompt)를 수정하고, 새로운 종류의 작업에서 실패하는 것을 지켜보고, 다시 수정합니다. 그러다 보면 프롬프트는 아무도 건드리고 싶어 하지 않는 예외 케이스들의 벽으로 서서히 변해갑니다. 두 번째 종류는 실패를 스스로 감지하고, 자신의 프롬프트를 더 나은 버전으로 작성하며, 실제 작업에 대해 해당 버전을 테스트하고, 실제로 승리했을 때만 이를 유지합니다. 이 두 종류 사이의 격차가 바로 자기 진화형 에이전트 (self-evolving agents) 분야 전체이며, 올해 이 분야는 단순한 연구적 호기심의 단계를 넘어섰습니다.

자기 진화형 에이전트는 단순히 피드백 루프 (feedback loop)로 감싸진 에이전트일 뿐입니다. 에이전트가 작업을 수행합니다. 무언가가 출력을 점수화 (score) 합니다. 약점이 충분히 자주 나타나면, 시스템은 새로운 시스템 프롬프트를 제안하고, 실제 트래픽에서 기존 버전과 새 버전을 한동안 모두 실행한 뒤, 승자를 승격 (promote) 시킵니다. 만약 새 버전이 더 나쁜 것으로 판명되면, 마지막으로 확인된 양호한 버전으로 롤백 (roll back) 합니다. 과정 중에 인간은 없지만, 그렇다고 맹목적인 믿음도 없습니다. 왜냐하면 성과를 증명하기 전까지는 아무것도 승격되지 않기 때문입니다.

이것이 아이디어입니다. 흥미로운 부분은 실제로 어떤 부분이 어려운가 하는 점입니다.

최적화 도구 (The Optimizer)는 올해 해결되었다

모두가 논문을 쓰는 부분은 변이 (mutation) 단계입니다. 즉, 성능이 저하된 프롬프트가 주어졌을 때 더 나은 것을 만들어내는 것입니다. 수년 동안 진지한 해답은 강화학습 (reinforcement learning)이었으며, 이는 희소한 수치적 보상 (sparse numerical rewards)으로부터 모델을 조정합니다. 이것은 작동하지만, 비용이 많이 들고 풍부한 실패 사례를 단 하나의 숫자로 취급합니다.

2026년, 이 분야는 다른 해답으로 수렴했습니다. Genetic-Pareto의 약자인 GEPA가 ICLR에서 Oral 논문으로 채택되었으며, 이는 매우 직설적인 주장을 펼칩니다. 즉, 언어(language)가 스칼라 보상(scalar reward)보다 더 풍부한 스승이라는 것입니다. GEPA는 숫자를 통해 가중치를 미세하게 조정하는 대신, 실행의 실제 궤적(trajectory), 즉 추론(reasoning), 도구 호출(tool calls), 그리고 출력을 읽어 들입니다. 그런 다음 이를 평이한 언어로 성찰하여 무엇이 잘못되었는지 진단하고, 이를 수정할 수 있는 가장 작은 편집(edit)을 작성합니다. 또한 서로 다른 사례에서 승리하는 후보들의 파레토 프런티어(Pareto frontier)를 유지하며 그들의 강점을 결합합니다.

사람들이 주목한 이유는 수치 때문입니다. GEPA는 강력한 강화학습 (RL) 방법론인 GRPO를 평균 약 6%, 많게는 20%까지 앞서면서도, 롤아웃 (rollouts) 횟수는 최대 35배 적게 사용합니다. 또한 이전의 프롬프트 최적화 (prompt-optimization) 핵심 도구였던 MIPROv2를 10% 이상 앞섭니다. 더 적은 비용의 실행, 더 나은 결과, 그리고 구축해야 할 강화학습 (RL) 메커니즘이 필요 없다는 점. 이러한 조합 덕분에 GEPA는 빠르게 확산되었으며, 현재 가장 인기 있는 최적화 프레임워크인 DSPy 내부에 탑재되어 배포되고 있습니다.

따라서 실용적인 관점에서 최적화 도구 (optimizer) 문제는 해결되었습니다. 바로 그 점 때문에 최적화가 쉬운 부분인 것입니다.

어려운 부분은 그 주변의 모든 것이다

GEPA 연구를 면밀히 읽어보면 이것이 오프라인 (offline) 방식으로 최적화한다는 것을 알 수 있습니다. 학습 세트를 가져와서 이를 대상으로 롤아웃 (rollouts)을 실행하고, 성찰한 뒤, 더 나은 프롬프트를 제공합니다. 하지만 GEPA가 하지 못하는 일은 그 프롬프트가 실제 사용자 앞에 배치하기에 안전한지 알려주는 것, 라이브 트래픽 (live traffic)에서 관찰하는 것, 또는 다음 주 화요일에 조용히 성능이 퇴보 (regress)했을 때 이를 되돌리는 일입니다. 이것들은 GEPA의 결함이 아닙니다. 단지 다른 영역의 작업일 뿐입니다.

Decagon 팀은 실제 프로덕션 분류기(production classifier)에서 GEPA를 실행하는 데 무엇이 필요했는지에 대해 정리한 글을 작성했으며, 이 글은 실제 제품을 출시하는 사람들에게 논문보다 더 유용합니다. 세 가지 발견 사항이 눈에 띕니다. 첫째, 성찰 모델(reflection model)은 반드시 프런티어 모델(frontier model)이어야 합니다. 그들은 더 작은 모델들이 "프롬프트 최적화(prompt optimization)에 완전히 실패한다"는 것을 발견했는데, GPT-4o-mini는 아무런 변화도 만들어내지 못했습니다. 그들의 표현을 빌리자면, 프롬프트 최적화는 추론에 대한 추론(reasoning about reasoning)이기 때문입니다. 둘째, 데이터가 많다고 해서 더 좋은 것은 아닙니다. 그들의 최적 지점(sweet spot)은 20개에서 100개의 예시였으며, 500개까지 늘리자 프롬프트가 비대해지는 반면 성능은 하락했습니다. 일반적인 규칙을 배우는 대신 에지 케이스(edge cases)에 과적합(overfitting)된 것입니다. 셋째, 기본 구현체는 프롬프트 길이를 제한하지 않기 때문에, 통제 불능의 프롬프트가 컨텍스트 윈도우(context window)를 잡아먹기 전에 그들이 직접 이를 구축해야 했습니다.

그 후, 후보 모델이 오프라인 임계값(offline thresholds)을 통과한 후에야 실제 고객을 대상으로 통제된 A/B 롤아웃(A/B rollout)을 실행하여 새 버전으로 트래픽을 점진적으로 늘렸습니다. 마지막 문장이 이 글의 핵심입니다. 최적화 도구(optimizer)는 하나의 구성 요소일 뿐입니다. 그 주변에는 평가 하네스(evaluation harness), 후보 모델의 출시 여부를 결정하는 게이트(gate), 출시가 불가능할 때를 대비한 롤백 경로(rollback path), 변이(mutation)에 대한 길이 및 안전 제약 조건, 그리고 이 모든 것을 일회성 배치 작업(batch job)이 아닌 온라인 상태로 계속 실행할 수 있게 하는 배관(plumbing) 작업이 자리 잡고 있습니다. 신뢰성은 바로 그 주변 계층에서 발생하며, 논문에서 다뤄지는 경우는 거의 없습니다.

자기 진화형 루프의 구성 요소

프로덕션 루프는 실제로 각각 한 가지 일만 수행하는 작고 지루한 작업들의 집합체이므로, 각 부분의 이름을 명명하는 것이 도움이 됩니다.

스코어러(scorer) 또는 비평가(critic)는 출력을 숫자로 변환합니다. 단일 LLM이 다른 LLM을 채점하는 것은 자신의 스타일에 편향될 수 있으므로, 더 견고한 패턴은 서로 다른 기준 또는 서로 다른 모델 제공업체를 가진 여러 비평가가 중앙값(median)을 취하는 방식입니다. 점수는 그것을 생성한 패널(panel)만큼만 신뢰할 수 있습니다.

패턴 탐지기(pattern detector)는 시간이 지남에 따라 점수를 관찰하며, 단 한 번의 잘못된 실행(bad run)이 아니라 실제적인 약점이 존재하는 시점을 결정합니다. 이는 노이즈(noise)에 반응하는 것과 트렌드(trend)에 반응하는 것의 차이입니다.

최적화 도구(optimizer)는 위에서 설명한 GEPA 스타일의 리플렉터(reflector)입니다. 이는 새로운 프롬프트(prompt)를 작성하는 부분이며, 모두가 집착하는 부분입니다.

안전 게이트(safety gate)는 상황을 통제하는 중재자 역할을 합니다. 새로운 프롬프트가 제어권을 넘겨받기 전에, 게이트는 이를 기존 프롬프트(incumbent)와 정면으로 대결시키고, 개선 사항이 실제적인지 아니면 단순히 운(coin flip)에 의한 것인지 확인하며, 임계값(threshold) 이하로 퇴보하는 버전의 승격은 거부합니다. 이를 자동 롤백(automatic rollback) 및 마지막으로 확인된 양호한 프롬프트 기록과 결합하면, 잘못된 변이(mutation)가 발생하더라도 주말 전체를 날리는 대신 단 몇 번의 실행 비용만 치르면 됩니다.

실험 트래커(experiment tracker)는 모든 실행, 모든 점수, 그리고 모든 프롬프트 버전을 기억합니다. 이를 통해 루프(loop)는 기억력을 갖게 되며, 특정 프롬프트가 왜 활성화되어 있는지 감사(audit)할 수 있습니다. 이것이 없다면 당신은 눈을 감고 진화시키는 것과 같습니다.

이 중 그 어느 것도 화려하지 않습니다. 하지만 이 모든 것들은 하중을 지탱하는 핵심 요소(load-bearing)입니다. 게이트와 롤백을 제거한다면, 그것은 자기 진화형 에이전트가 아니라 안전벨트 없이 자신의 프롬프트를 변이시키는 에이전트일 뿐이며, 이는 처음에 시작했던 에이전트보다 더 나쁜 에이전트가 됩니다.

이것이 왜 Python 전용 이야기였는가

제가 이 일을 시작하게 된 계기가 된 격차(gap)가 여기 있습니다. 2026년의 모든 진지한 프롬프트 최적화 도구는 Python으로 작성되어 있습니다. DSPy, GEPA 자체의 레퍼런스 구현체(reference implementation), TextGrad, AdalFlow, Microsoft의 PromptWizard가 그러합니다. 만약 당신의 에이전트가 Python 데이터 과학 스택에서 실행된다면, 선택지가 매우 풍부합니다. 하지만 실제 운영 환경의 에이전트 중 엄청난 비중을 차지하는 TypeScript 환경에서 실행된다면, 지금까지 아무것도 없었습니다. 아주 작은 포팅(port)조차도 말입니다.

그 간극을 메우기 위해 존재하는 것이 바로 darwin-agents입니다. 이는 MIT 라이선스의 오픈 소스 TypeScript 라이브러리로, 에이전트에게 단순한 최적화 도구(optimizer)뿐만 아니라 전체 루프(loop)를 제공합니다. 즉, 멀티 모델 비평가(multi-model critics), A/B 테스트, 안전 게이트(safety gate), 자동 롤백(automatic rollback), 그리고 실험 추적(experiment tracking)을 제공하며, 최적화 도구는 그 내부에서 교체 가능한 하나의 구성 요소로 포함됩니다. 이 설계의 핵심 가설은 이 글의 주장과 동일합니다. 최적화 도구는 연구에서 빌려올 수 있는 부분입니다. 하지만 프로덕션 레이어(production layer)는 직접 구축해야 하는 부분입니다. 따라서 그 부분을 잘 구축하고, 최적화 도구를 플러그인 방식으로 연결할 수 있게 만드십시오.

최신 릴리스는 명백했던 루프를 완성했습니다. 지금까지 이 라이브러리는 사용자가 직접 호출할 수 있는 GEPA 스타일의 성찰적 최적화 도구(reflective optimizer)와 별도의 안전 게이트가 적용된 진화 루프(evolution loop)를 제공해 왔으나, 이 둘은 서로 연결되어 있지 않았습니다. 루프에는 여전히 더 단순한 최적화 도구가 사용되었습니다. 새 버전은 이 둘을 연결하여, 이제 성찰적 최적화 도구가 오프라인 스크립트가 아닌 프로덕션 게이트(production gate) 내부에서 실행됩니다. 제가 찾아본 바로는, 안전 게이트 뒤에서 TypeScript를 통해 프롬프트를 실시간으로 진화시키는 GEPA 스타일의 최적화 도구라는 이 특정 조합은 아직 다른 어디에도 존재하지 않습니다. 이는 선택 사항(opt-in)이므로, 기능을 활성화하기 전까지 기존 에이전트는 이전과 똑같이 동작합니다. 또한 아직 알파(alpha) 단계이므로 알파 단계로 취급해 주시기 바랍니다.

이러한 주변 아이디어들이 단일 에이전트가 아닌 에이전트 군단(fleet)에 적용되는 사례를 보고 싶다면, 벤더 비용 없이 전체 에이전트 군단을 튜닝하는 방법에서도 동일한 논리를 확인할 수 있습니다.

실제로 이것이 필요한 시점

자기 진화(Self-evolution)는 다음 세 가지 조건이 동시에 충족될 때 그 복잡성을 정당화합니다. 첫째, A/B 테스트가 합리적인 시간 내에 결론을 내릴 수 있을 만큼 충분한 트래픽이 있어야 합니다. 결정을 내릴 만큼 충분한 데이터를 수집하지 못하는 루프는 그저 오버헤드(overhead)일 뿐이기 때문입니다. 둘째, 작업에 '좋음'에 대한 측정 가능한 개념이 있어야 합니다. 비평가(critic)가 점수를 매길 기준이 필요하기 때문입니다. 셋째, 잘못된 변이(mutation)로 인한 비용을 회복할 수 있어야 하며, 이것이 바로 게이트(gate)와 롤백(rollback)이 보장하는 핵심 기능입니다.

이러한 조건들이 충족되지 않는다면, 자기 진화형 에이전트 (self-evolving agent)는 잘못된 도구이며, 사람이 가끔씩 프롬프트 (prompt)를 미세 조정 (tweaking)하는 것이 진정으로 더 낫습니다. 이 경계에 대해 솔직하게 인정하는 것이 기술을 제대로 사용하는 방법 중 하나입니다. 이 분야 전체의 실패 모드 (failure mode)는, 모호한 목표를 대상으로 일주일에 열 번 정도 실행되는 에이전트에 대해 자동 진화 (automatic evolution) 기능을 켜두고는, 왜 프롬프트가 터무니없는 내용으로 표류 (drift)하는지 의아해하는 팀의 모습입니다. 루프 (loop)의 품질은 그 루프에 공급되는 신호 (signal)의 품질만큼만 좋습니다.

최적화 도구 (optimizer) 경쟁은 대부분 끝났으며, 현재로서는 GEPA가 승리했습니다. 앞으로 2년 동안의 진짜 과제는 아무도 경쟁하지 않는 계층에 있습니다. 즉, 게이트 (gate), 롤백 (rollback), 평가 (evaluation), 그리고 사용자들이 지켜보는 동안 이 모든 것을 안전하게 실행하는 지루한 작업들입니다. 바로 이 부분이 자기 진화형 에이전트가 부채 (liability)가 될지, 아니면 여러분의 스택 (stack)에서 가장 신뢰할 수 있는 요소가 될지를 결정합니다.