-->

⏱️ 예상 읽기 시간: 7분

에이전트의 고질적 한계

현재 LLM 기반 에이전트는 대부분 정적이다. 프롬프트와 툴 정의는 사람이 직접 작성하고, 실패가 반복되어도 에이전트 자체는 바뀌지 않는다. 사람이 로그를 보고, 프롬프트를 수정하고, 다시 배포해야 비로소 다음 버전이 나온다. 이 사이클이 느리다는 사실은 누구나 안다. 문제는 이를 어떻게 자동화하느냐다.

arXiv:2604.15034 “Autogenesis: A Self-Evolving Agent Protocol”은 이 문제를 정면으로 다룬다. 핵심 주장은 단순하다. 에이전트를 구성하는 모든 요소, 즉 프롬프트, 툴, 메모리, 에이전트 그 자체를 버전 관리 가능한 “프로토콜 리소스”로 다루면, 에이전트가 스스로 개선 루프를 닫을 수 있다.

두 개의 계층: 리소스와 자기진화

AGP(Autogenesis Protocol)는 두 계층으로 구성된다.

Resource Substrate Protocol Layer

첫 번째 계층은 에이전트를 구성하는 모든 요소를 명시적 상태, 생명주기, 버전 인터페이스를 가진 “프로토콜 등록 리소스”로 모델링한다. 프롬프트 하나도 버전이 붙은 아티팩트다. 특정 버전의 프롬프트가 어느 실행에 쓰였는지 추적 가능하고, 롤백도 된다.

이 추상화가 실용적인 이유는 에이전트를 구성하는 요소들이 런타임에 교체 가능해지기 때문이다. “프롬프트 v2가 v1보다 낫다”는 판단을 에이전트 자신이 내린다면, 재배포 없이 자체적으로 교체할 수 있다.

Self Evolution Protocol Layer

두 번째 계층이 실제 자기진화를 담당한다. 이 계층은 세 단계의 폐루프(closed-loop)를 돈다.

  1. 제안(Propose): 현재 성능 데이터를 바탕으로 개선 후보를 생성한다.
  2. 평가(Assess): 제안된 변경이 실제로 나아지는지 검증한다.
  3. 커밋(Commit): 검증을 통과한 변경만 프로덕션에 반영한다.

중요한 점은 커밋 단계에 명시적 검증 게이트가 있다는 것이다. 검증을 통과하지 못한 변경은 반영되지 않는다. 무제한 자기수정이 아니라 통제된 자기개선이다.

실험 결과

논문은 복잡한 계획(planning)과 툴 사용(tool use)이 필요한 벤치마크에서 AGP 기반 Autogenesis 시스템이 일관된 성능 향상을 보였다고 보고한다. 구체적인 수치는 초록 기준 상세 미공개이며, 논문 본문에서 확인해야 한다. 논문이 강조하는 것은 단일 실행 성능보다 시간이 지남에 따라 성능이 누적되어 올라가는 궤적이다.

무엇이 다른가

기존 에이전트 자기개선 연구 대부분은 모델 파인튜닝에 집중한다. 더 좋은 데이터로 가중치를 업데이트하는 방식이다. AGP는 다른 경로를 택했다. 모델 가중치는 건드리지 않고, 에이전트를 둘러싼 프로토콜 리소스(프롬프트, 툴 정의, 메모리 구조)를 최적화한다. 이 접근의 장점은 빠르다는 것이다. 파인튜닝 사이클 없이 런타임에 변경이 적용된다.

단점도 있다. 프로토콜 리소스 수준의 개선은 모델의 근본적 능력 한계를 넘어서기 어렵다. 모델이 애초에 처리 못 하는 작업을 프롬프트 최적화로 해결할 수는 없다.

ThakiCloud 플랫폼 관점

ThakiCloud가 운영하는 K8s 기반 AI 플랫폼에서 AGP 아이디어가 가장 직접적으로 적용 가능한 곳은 에이전트 스킬 시스템이다.

현재 .claude/skills/ 아래에 있는 스킬들은 사람이 수동으로 작성하고 업데이트한다. AGP의 Resource Substrate 모델을 적용하면, 각 스킬을 버전 관리된 아티팩트로 관리하고, 실행 결과를 기반으로 스킬 개정 후보를 자동 생성하는 파이프라인을 구성할 수 있다. 이미 selfharness-evolve 워크플로가 야간에 스킬 진화를 시도하는 방향으로 가고 있고, AGP는 그 이론적 근거를 제공한다.

멀티테넌트 플랫폼에서 한 가지 고려 사항이 있다. 자기진화 에이전트가 수정하는 대상이 공유 리소스라면, 한 테넌트의 실행에서 파생된 개선이 다른 테넌트에 영향을 줄 수 있다. 커밋 게이트를 테넌트 격리와 어떻게 연계할지는 설계 결정이 필요한 부분이다.

마치며

AGP는 에이전트 시스템을 “코드처럼” 다루는 접근이다. 코드에는 버전이 있고, 테스트가 있고, 배포 파이프라인이 있다. 에이전트의 프롬프트와 툴에도 같은 원칙을 적용하면, 사람이 개입하지 않아도 에이전트 품질이 점진적으로 올라갈 수 있다.

아직 해결해야 할 질문들이 많다. 자기진화 루프가 수렴하는 조건은 무엇인가, 발산하거나 오염된 방향으로 진화하는 것을 어떻게 막는가, 큰 규모의 멀티에이전트 환경에서 리소스 버전 관리가 어떻게 작동하는가. 이 질문들에 대한 답이 후속 연구에서 나오길 기대한다.

원문: https://arxiv.org/abs/2604.15034

참고