Self-Evolved Agents: 정적 LLM 도구에서 자기 개선형 AI 시스템으로

오늘날 배포된 대부분의 AI 에이전트는 탄생 순간에 고정됩니다. 프롬프트는 수작업으로 설계되고, 도구는 하드와이어되어 있으며, 개발자가 새 버전을 배포할 때까지 동작은 그대로 유지됩니다. 이는 초기 자동화에는 충분히 잘 맞았지만, 앞으로 몇 년 동안 가장 뛰어난 에이전틱 시스템이 작동하는 방식은 아닙니다.

Self-evolved agents는 근본적인 변화를 의미합니다. 즉, 인간이 다시 설계해 주기를 기다리는 대신 상호작용 데이터와 피드백을 바탕으로 자신의 정책, 도구, 메모리, 심지어 아키텍처까지 지속적으로 개선하는 AI 시스템입니다. 이 글에서는 self-evolved agents가 무엇인지, 어떻게 작동하는지, 그리고 제품 및 엔지니어링 팀이 오늘부터 이를 향해 어떤 구체적인 설계 패턴을 적용할 수 있는지 설명합니다.

Self-Evolved Agents란 무엇인가?

Self-evolved agent는 환경으로부터의 피드백을 바탕으로, 각 변경마다 명시적인 인간 재설계 없이도 자신의 스택 일부 — 모델, 메모리, 도구, 또는 조정 로직 — 를 자동으로 업데이트하는 AI 시스템입니다.

정의적인 특징은 지속적인 피드백 루프입니다. 에이전트는 결과를 관찰하고, 무엇이 효과적이었고 무엇이 아니었는지에 대한 신호를 받으며, 그에 따라 자신을 수정합니다. 프롬프트, 의사결정 규칙, 도구 선택은 고정된 상수가 아니라 수정 가능한 객체로 취급됩니다.

이는 오늘날 대부분의 프로덕션 AI 에이전트가 작동하는 방식과는 의미 있게 다릅니다.

정적 LLM 에이전트의 문제

현재 프로덕션에서 사용되는 대부분의 "AI 에이전트"는 대규모 언어 모델을 둘러싼 오케스트레이션 레이어로, 다음으로 구성됩니다.

• 고정된 시스템 프롬프트와 역할 설명
• LangChain, AutoGen, CrewAI 같은 프레임워크로 연결된 사전 정의된 도구 세트
• 정적 코드 또는 YAML 설정으로 구현된 라우팅 및 워크플로 그래프

이러한 시스템은 인상적일 수 있지만, 수동 개발자 업데이트가 없는 한 시간이 지나도 근본적으로 동작이 바뀌지 않습니다. 새로운 작업, 변화하는 사용자 선호도, 또는 바뀌는 환경에 스스로 적응할 수 없습니다. 모든 개선에는 인간의 개입이 필요합니다.

Self-evolved agents는 이 의존성을 끊어냅니다.

Self-Evolution을 이해하기 위한 프레임워크

최근 연구 문헌의 조사들은 self-evolving agents를 세 가지 핵심 질문으로 정리합니다: 무엇을 진화시킬 것인가, 언제 진화시킬 것인가, 어떻게 진화시킬 것인가.

무엇을 진화시킬 것인가

Self-evolution은 에이전트 시스템의 여러 계층을 대상으로 할 수 있습니다.

• 모델 파라미터 또는 어댑터 — 누적된 경험을 바탕으로 LoRA 모듈을 미세조정하거나 업데이트
• 장기 메모리와 지식 베이스 — 상호작용 로그를 요약, 인덱싱, 정리
• 도구 세트와 외부 스킬 — 코드 합성을 통해 새로운 도구를 생성하고, 성능으로 기존 도구를 평가하며, 성능이 낮은 도구는 폐기
• 내부 워크플로와 멀티에이전트 토폴로지 — 과거 데이터에 따라 계획 깊이, 조정 패턴, 위임 정책 변경

언제 진화시킬 것인가

진화는 두 가지 시간 스케일에서 일어날 수 있습니다.

Intra-episode(단일 작업 내): 에이전트는 중간 피드백을 바탕으로 재계획하고, 검색 전략을 수정하거나, reflection loop를 사용해 자신의 출력을 디버깅하고 다듬으면서 작업 도중에 적응합니다. 이는 모델 재학습이 필요 없으며 프롬프트 수준에서 구현할 수 있습니다.

Inter-episode(작업 및 사용자 간): 더 느리고 구조적인 진화는 많은 상호작용에 걸쳐 발생합니다. 예를 들어, 어댑터의 야간 재학습, 오프라인 최적화를 이용한 프롬프트와 도구의 주기적 재생성, 또는 에이전트가 더 유능해질수록 점점 더 어려운 과제를 도입하는 커리큘럼 생성이 이에 해당합니다.

Inter-episode 진화야말로 평생 학습하는 에이전틱 시스템과 초기 배포 후 정체되는 시스템을 구분 짓는 요소입니다.

어떻게 진화시킬 것인가

메커니즘에는 다음이 포함됩니다.

• 스칼라 보상과 강화학습
• 진화적 탐색과 품질-다양성 알고리즘
• 텍스트 기반 피드백, 자기 성찰, 메타 수준 계획
• 멀티에이전트 토론, 증류, 그리고 에이전트와 환경 간의 공진화

이들은 조합될 수 있습니다. Self-evolved agent는 한 에피소드 내에서는 텍스트 기반 자기 비판을 사용하고, 그 비판을 오프라인 RL 프로세스로 전달해 에피소드 간 보상 모델을 업데이트할 수 있습니다.

Self-Evolution의 핵심 메커니즘

자기참조형 에이전트: Gödel Machine 접근법

Gödel Agent 프레임워크는 이론적인 Gödel machine 개념 — 자기 개선이 증명 가능한 프로그램 — 에서 영감을 받아, 에이전트 자신의 로직, 프롬프트 템플릿, 의사결정 규칙을 수정 가능한 아티팩트로 취급합니다. LLM 자체가 고수준 목표와 메타 프롬프트의 지도를 받아 수정안을 제안하고 구현합니다. 후보 수정안은 채택되기 전에 보류된(held-out) 작업에서 평가됩니다.

이는 "작업 내 자기 성찰"을 넘어 진정한 재귀적 자기 개선으로 나아갑니다. 즉, 에이전트가 현재 문제에 대한 계획만 바꾸는 것이 아니라, 미래 문제에서 생각하고 행동하는 방식 자체를 바꾸는 것입니다.

Hyperagents: 스스로를 개선하는 개선

Meta의 Hyperagents(DGM-H)는 Darwin Gödel Machine을 확장하여, 작업 성능과 그 성능을 개선하는 과정 자체를 모두 향상시키는 에이전트를 만듭니다. 아키텍처는 다음으로 구성됩니다.

• 도메인 작업(코딩, 보상 설계, 논문 리뷰 등)을 처리하는 task agent
• task agent와 자체 self-improvement 절차를 모두 수정하는 meta agent
• 전체 시스템을 나타내는 단일 수정 가능한 프로그램으로, 메타인지적 자기 수정을 가능하게 함

실증 결과에 따르면 hyperagents는 다양한 도메인에서 성능을 꾸준히 향상시키는 동시에, 더 나은 성능 추적, 향상된 메모리 메커니즘과 같은 메타 수준의 혁신을 축적하며 이를 작업 간에 전이합니다.

Open-Ended Learning

Open-ended learning 연구는 고정된 정책으로 수렴하는 대신, 끝없이 새로운 문제와 해결책을 발명해 나가는 시스템을 목표로 합니다. 핵심 요소는 다음과 같습니다.

• 지속적으로 새로운 과제를 생성하는 환경 또는 생성기
• Novelty search — 단일 목표 최적화보다 새로운 행동의 발견에 보상
• 에이전트, 작업, 커리큘럼이 시간에 따라 서로를 형성하는 공진화 역학

ALOE(Agent Learning in Open-Endedness) 같은 워크숍에서 발전된 이 연구 흐름은 강화학습, 진화 계산, 인공 생명 관점을 하나의 목표 — 절대 멈추지 않는 에이전트 — 로 통합합니다.

LLM 에이전트에서의 실용적 Self-Evolution

오늘날 대규모 언어 모델로 구축하는 팀에서 self-evolution은 주로 다음과 같은 형태로 나타납니다.

• 자기 성찰 및 비판: 에이전트가 자신의 궤적을 분석하고, 오류를 식별하며, 프롬프트나 스킬을 업데이트
• 로그 기반 프롬프트 및 워크플로 탐색: 오프라인 프로세스가 상호작용 로그를 분석해 더 나은 분해 방식, 도구, 라우팅 휴리스틱을 제안
• 자동화된 도구 탐색: 에이전트가 새 API나 스크립트가 등장할 때 이를 호출하는 법을 학습해, 수동 연결 없이 기능을 확장
• 메모리 성장 및 압축: 에이전트가 장기 상호작용 메모리를 유지하고, 검색 성능 향상을 위해 주기적으로 이를 압축하고 재색인

Self-Evolved Agents가 실제로 진화시키는 것

모델 파라미터와 어댑터

가장 낮은 수준에서 에이전트는 누적된 경험을 바탕으로 모델이나 어댑터를 미세조정할 수 있습니다. 여기에는 도메인별 데이터에 대한 지속적 미세조정, 기본 모델을 특정 환경에 특화시키는 작은 LoRA 모듈 학습, 그리고 인간 피드백으로 보상 또는 선호 모델을 업데이트해 "좋은 행동"의 의미를 정교화하는 것이 포함됩니다.

메모리와 지식

많은 시스템은 핵심 모델보다 에이전트의 메모리를 진화시키는 데 초점을 맞춥니다. 즉, 상호작용 로그를 자동으로 요약하고 인덱싱하며, 반복되는 패턴을 재사용 가능한 "스킬" 또는 플레이북으로 승격하고, 오래된 지식을 탐지해 최신 정보로 대체합니다. 이는 외부 사실이 파운데이션 모델보다 더 빠르게 변하는 도메인에서 특히 중요합니다.

도구와 스킬

Self-evolved agents는 도구 — API, 스크립트, 서브 에이전트 — 를 시간이 지나며 변하는 개체군으로 취급할 수 있습니다. 새로운 도구는 프로그램 합성이나 코드 작성을 통해 생성되고, 성공률과 지연 시간으로 평가되며, 성능이 낮으면 폐기됩니다. 그 결과 환경과 사용 사례가 변함에 따라 에이전트의 기능도 적응하는 "도구 생태계"가 만들어집니다.

아키텍처와 조정

가장 높은 수준에서 self-evolution은 에이전트의 전체 구조를 바꿀 수 있습니다. 예를 들어, 단일 에이전트와 멀티에이전트 패턴 사이를 전환하거나, 통신 토폴로지를 재배선하거나, 과거 성능에 따라 계획 깊이 또는 위임 정책을 변경할 수 있습니다. Hyperagents와 Gödel 스타일 에이전트는 메타 수준의 개선 절차 자체를 다시 작성할 수 있게 함으로써 이를 잘 보여줍니다.

안전성, 평가, 그리고 통제

Self-evolving agents는 정적 시스템이 마주하지 않는 복잡성을 도입합니다.

평가의 도전 과제

Self-evolved agent는 움직이는 목표물입니다. 에이전트가 변함에 따라 표준 벤치마크는 구식이 될 수 있습니다. 일부 작업에서의 개선이 다른 영역의 성능 저하를 조용히 가릴 수도 있습니다. 전통적인 스칼라 지표는 다양성, 견고성, 새로운 정도(novelty)를 충분히 포착하지 못할 수 있습니다.

더 견고한 평가는 다양성 측정, 시간에 따른 종단적 평가, 그리고 일회성 벤치마크가 아닌 견고성 테스트를 필요로 합니다.

안전 및 윤리적 우려

에이전트가 스스로를 수정하도록 허용하면 심각한 안전 문제가 생깁니다.

• 엄격하게 통제되지 않으면 self-modification이 안전장치나 정렬 제약을 우회할 수 있음
• 개방형 탐색은 예상치 못한 영역에서 유해한 행동을 생성할 수 있음
• 공진화 시스템은 예측, 감사, 샌드박싱이 더 어려움

문헌에서 제안하는 모범 사례는 다음과 같습니다: self-modify할 수 있는 시스템 부분을 제한하고, 샌드박스 환경과 단계적 배포를 사용하며, 구조적이거나 영향이 큰 변경에는 인간 승인을 요구하고, 모든 self-modification을 감사 가능하도록 로깅하고 버전 관리하는 것입니다.

Self-Evolved Agents를 구축하기 위한 설계 패턴

1. 먼저 계측하고, 그다음 진화시키기

견고한 로깅 이후의 두 번째 단계로 self-evolution을 다루세요. 모든 에이전트 실행 — 사용된 프롬프트, 호출된 도구, 결과, 사용자 피드백 — 을 계측하세요. 각 작업군별로 명확한 성공 지표를 정의하세요. 그런 다음에야 프롬프트, 도구, 워크플로에 대한 변경을 제안하는 오프라인 프로세스를 추가하세요.

신뢰할 수 있는 자동화는 수작업과 반복적 정제에서 나옵니다. 깨끗한 로그와 명확한 지표가 없는데 self-evolution을 먼저 구축하려는 것은 모래 위에 집을 짓는 것과 같습니다.

2. 메타 에이전트와 작업 에이전트를 분리하기

주요 작업 에이전트가 즉흥적으로 자신을 다시 쓰게 두는 대신, 로그와 지표를 읽고, 설정 변경을 코드나 구조화된 diff로 제안하며, 프로덕션 전에 검토 또는 시뮬레이션 파이프라인에 변경을 제출하는 전용 메타 에이전트를 도입하세요. 이 설계는 Gödel Agent와 hyperagent 아키텍처에서 아이디어를 가져오면서도 현대적인 MLOps 및 거버넌스 기대에 맞습니다.

3. 스킬 및 도구 마켓플레이스

Self-evolved agents는 스킬과 도구의 내부 "마켓플레이스"를 유지할 수 있습니다. 새 도구는 코드 합성이나 외부 기여자를 통해 제안됩니다. 랭킹 메커니즘이 성능에 따라 트래픽을 배분합니다. 성능이 낮은 도구는 점차 트래픽을 잃고 폐기됩니다. 이는 에이전트의 행동 공간에서 미세한 진화 과정을 만들어내며, open-ended system이 해결책 개체군을 관리하는 방식과 유사합니다.

4. 버전 관리되고 설명 가능한 자기 수정

신뢰와 규제 준수를 유지하려면 self-evolved system은 모든 프롬프트, 도구, 워크플로의 버전 히스토리를 보관하고, 승인된 각 수정에 근거와 증거를 첨부하며, 주요 동작 변화에 대해 사용자에게 설명을 제공해야 합니다. 이러한 관행은 회귀를 디버깅하고 유해한 변경을 롤백하는 것을 가능하게 합니다.

Self-Evolved 디지털 동료를 향하여

이 글의 아이디어가 제품으로 이어진다면, 결과는 단순히 "더 자율적인 에이전트"가 아닙니다. 수개월과 수년에 걸쳐 개별 사용자의 워크플로와 선호를 학습하고, 환경에 맞춘 특화된 도구와 플레이북 포트폴리오를 성장시키며, 자신의 의사결정과 조정 전략을 지속적으로 정교화하는 디지털 동료가 됩니다.

이 비전을 실현하려면 자기참조형 에이전트, hyperagents, open-ended learning에서의 기술적 혁신뿐 아니라, 안전성, 거버넌스, 평가에 대한 세심한 주의도 필요합니다. 하지만 방향은 분명합니다. 최전선은 정적 모델 주변의 더 나은 프롬프트에서, 시간이 지나며 자신을 설계하고 테스트하고 진화시키는 에이전트로 이동하고 있습니다.

오늘 에이전트 제품을 만드는 팀에게 Eigent 같은 플랫폼은 이러한 아키텍처가 요구하는 로깅, 도구 오케스트레이션, 멀티에이전트 조정을 지원하는 모델-불가지론적 기반을 제공합니다. 단일 모델이나 고정된 워크플로 그래프에 갇히지 않아도 됩니다.

자주 묻는 질문

Self-evolved agent란 무엇인가요?

Self-evolved agent는 환경으로부터의 피드백을 바탕으로 모델, 메모리, 도구, 아키텍처 등 자신의 스택 일부를 자동으로 개선하는 AI 시스템입니다. 각 변경마다 명시적인 인간 재설계가 필요하지 않습니다. 정적 LLM 에이전트와 달리, self-evolved agent는 자신의 설정을 시간이 지나며 업데이트되는 수정 가능한 객체로 취급합니다.

Self-evolving AI agents는 일반적인 LLM 에이전트와 어떻게 다른가요?

일반적인 LLM 에이전트는 개발자가 업데이트를 배포할 때만 바뀌는 고정 프롬프트, 사전 정의된 도구 세트, 정적 워크플로를 사용합니다. Self-evolving agents는 관찰, 행동, 피드백 수신, 수정으로 이어지는 지속적인 피드백 루프를 실행하므로, 수동 개입이 아니라 경험에 따라 행동과 구조가 바뀝니다.

Gödel Agent란 무엇인가요?

Gödel Agent는 이론적 Gödel machine에서 영감을 받은 자기참조형 AI 프레임워크로, 에이전트가 자신의 코드, 프롬프트, 의사결정 규칙을 점검하고 수정할 수 있습니다. 에이전트는 LLM을 사용해 고수준 목표에 따라 self-modification을 제안하고 평가하며, 단일 작업의 자기 성찰이 아니라 재귀적 자기 개선을 가능하게 합니다.

Hyperagents란 무엇인가요?

Meta에서 개발한 Hyperagents(DGM-H)는 task agent와 meta agent를 모두 갖는 에이전트를 만들어 Darwin Gödel Machine 개념을 확장합니다. 메타 에이전트는 task agent와 자체 개선 절차를 수정하며, 이를 통해 다양한 도메인 전반에 성능 향상을 전이하는 메타인지적 자기 수정을 가능하게 합니다.

Self-evolving AI agents의 안전 리스크는 무엇인가요?

핵심 위험에는 self-modification을 통한 정렬 안전장치 우회, 개방형 탐색 중 예상치 못한 영역에서 유해한 행동 생성, 그리고 감사와 예측이 더 어려운 공진화 시스템의 생성이 포함됩니다. 모범 사례로는 self-modify할 수 있는 범위를 제한하고, 샌드박스를 통한 단계적 배포를 사용하며, 영향이 큰 변경에는 인간 승인을 요구하고, 모든 수정을 버전 히스토리와 함께 로깅하는 것이 있습니다.

Self-evolving agent를 만들 때 어떤 설계 패턴부터 시작해야 하나요?

먼저 계측부터 시작하세요. 자동 자기 수정을 시도하기 전에 프롬프트, 도구, 결과, 사용자 피드백을 포함해 모든 에이전트 실행을 로깅하세요. 깨끗한 로그와 명확한 성공 지표를 확보한 뒤에는, 작업 에이전트가 실시간으로 자신을 다시 쓰게 두는 대신 오프라인에서 변경을 제안하고 검토 파이프라인을 통해 제출하는 별도의 메타 에이전트를 도입하세요.