자율 진화하는 에이전트는 모델을 교체하지 않고도 프롬프트, 메모리, 도구 및 워크플로우를 변경합니다. 이제 과제는 무엇이 지속될 수 있는지 제어하는 것입니다.
에이전트의 하네스(harness) — 즉 프롬프트, 메모리, 워크플로우, 도구, 그리고 제어 코드 조각들 — 은 더 이상 초기 설정에만 국한되지 않습니다. 최근 논문들은 이러한 진행을 진화의 목표로 다루고 있습니다: 모델은 고정된 상태를 유지하고, 실행 간에 변화하며 지속되는 것은 에이전트가 무엇을 보고, 호출하고, 결정하는지를 정의하는 소프트웨어 구조물입니다.
Self-Evolving Agent Harness (arXiv:2610.18813, 10월 13일)는 수용된 개정 사항들이 남아있는 피드백 기반의 프로세스를 공식화합니다. 이는 해석된 상태의 변경(프롬프트, 메모리)과 도구, 레포지토리 로직 및 플러그인 구성의 개정을 구분합니다. 독립적인 검증을 갖춘 채택 메커니즘을 제안하고, 작업 분포와 평가자까지 변화할 때 일반화의 한계에 대해 논의합니다. Harness² (arXiv:2610.14224, 10월 9일)은 이 아이디어를 두 번째 수준으로 끌어올립니다: 현재 작업 내에서의 재귀(진행 중인 하네스 편집)와 지속적 개선 하네스에서의 재귀를 통해, 편집 경험을 다음 단계로 추출합니다. 전문 벤치마크에서 이미 한 단계만 거쳐 GLM-5 및 Gemini 3.5 Flash를 사용한 설정이 기본 하네스 대비 성능 향상을 이끌어냈습니다.
실제 프로덕션 환경에서 에이전트를 운영하는 사람들에게 중요한 점은 자율 진화가 '작동하는지' 여부가 아닙니다. 무엇을 지속시킬지 결정하는 주체입니다. 성공적인 실행 경험이 영구적인 규칙으로 변할 수 있으며, 심지어 다음 변화를 판단하는 규칙까지도 그럴 수 있습니다. 만약 변경 제안과 수용 기준이 같은 루프 안에 존재한다면, 시스템은 명확한 인간 승인 경로 없이 스스로를 통치하게 됩니다. 지속적인 검증(Continuous Validation), 회귀 예산(Regression Budget), 그리고 에이전트가 제안할 수 있는 것과 공유 하네스에 기록할 수 있는 것을 분리하는 것은 더 이상 연구의 세부 사항이 아니라 엔지니어링 요구사항이 됩니다.
실제 적용: harness가 재작성할 수 있는 내용을 목록화하고; 지속적인 변경을 승격하기 전에 증거와 신선한 검증을 요구하며; 에이전트가 다음 실행에서 상속받는 내용에 대한 롤백(rollback) 및 버전 식별자를 유지해야 합니다. 이것들을 정의하지 않는 사람은 에이전트가 결과에 책임질 사람이 서명하지 않은 채 게임의 규칙을 변경하도록 내버려두고 있는 것입니다.
아래를 클릭하여 더 심층적인 글을 읽어보세요.
도서 시리즈 "AI 지원 소프트웨어 엔지니어링(Engenharia de Software Assistida por IA)" 저자 (Amazon에서 이용 가능). 컨텍스트부터 에이전트 거버넌스까지의 주제를 구조적으로 깊이 있게 알아보고 싶다면 아래 이미지를 클릭하여 "AI 지원 소프트웨어 엔지니어링" 시리즈를 참고할 수 있습니다:
- 30% 할인 쿠폰:
LEIA30.
- Kindle Unlimited에서도 이용 가능합니다.
참고 문헌 (Referências)
- Wei et al., 2026년 10월 13일 - Self-Evolving Agent Harness (arXiv:2610.18813)
- Xu et al. (Google Cloud AI Research et al.), 2026년 10월 9일 Harness2: Open World를 위한 재귀적 에이전트 하니싱 (arXiv:2610.14224)
#소프트웨어엔지니어링 #AI #인공지능 #SoftwareEngineering #AI #에이전트 #Harness #거버넌스 #AI지원소프트웨어엔지니어링