같은 모델인데 어떤 프로젝트에서는 잘하고 다른 프로젝트에서는 계속 틀립니다. 모델과 하네스 이야기에서 다뤘던 것처럼, 차이는 모델 밖의 작업 환경에서 나옵니다.

그렇다면 질문이 하나 남습니다. 그 환경(하네스)을, 모델을 재학습시키지 않고도 시스템이 스스로 고칠 수 있을까요?

10월 13일 공개된 arXiv 논문 "Self-Evolving Agent Harness"는 이 질문에 대한 무려 66페이지짜리 서베이입니다. 이 글에서는 연구 전체를 따라가는 대신, 실무자가 가져갈 수 있는 구조와 경고를 중심으로 정리하겠습니다.

Self-Evolving Agent Harness (arXiv:2610.18813)

  저자: Chuyang Wei 외 7인
        (중관춘 아카데미 · USTC · 중관춘 인공지능연구원)
  공개: 2026년 10월 13일
  범위: 가중치를 고정한 채 하네스를 업데이트하는
        방법·이론·평가·영향 정리 (풀버전 66페이지)
  동봉: GitHub에 계속 갱신되는 리딩 리스트와 코드

먼저 정의부터: 하네스와 '진화'의 구분

논문의 출발점은 용어 정리입니다. 여기서부터 실무 감각과 직결됩니다.

하네스 H = 모델 M이 환경 E에서 작동하도록 감싸는 소프트웨어와 설정
           (프롬프트, 도구, 컨텍스트 구성, 메모리, 실행 제어)

실행:      τ ~ Run(M, H, E)      점수: y = J(τ)
업데이트:  H_{k+1} = Update(H_k, B_k)   ← B_k는 실행 궤적 배치

· 채택된 수정은 저장되어 다음 실행에 로드된다
· 거부된 후보는 하네스를 바꾸지 않는다
· 최종 평가자 J는 후보의 편집 범위 밖에 있다 (심판은 선수와 다른 편)

가장 중요한 구분이 마지막 문단에 있습니다. 논문은 "진화(self-evolution)"와 "개선(self-improvement)"을 분리합니다. 진화는 업데이트가 일어났다는 사실일 뿐이고, 개선은 비교로 입증된 유익한 변화만 가리킵니다. 저장소에 패치가 쌓이는 것과 그 패치가 도움이 된다는 것은 완전히 다른 주장이라는 뜻입니다.

무엇을 고칠 수 있는가: 두 갈래 분류

논문은 업데이트 대상을 크게 둘로 나눕니다. "고정된 호스트가 읽는 것"과 "호스트가 실행하는 것"입니다.

읽히는 것 (해석 대상)
  - 프롬프트·지시      예: APE, 텍스트 그래디언트 계열(TextGrad, GEPA)
  - 메모리·절차 지식   예: Reflexion, ExpeL, 스킬 문서 뱅크
  - 워크플로·토폴로지  예: DSPy 파이프라인 컴파일, AFlow 구조 탐색

실행되는 것 (실행 대상)
  - 도구·코드          예: Voyager의 자기 검증 스킬 라이브러리
  - 저장소 제어 로직   예: DGM·DarwinX — 에이전트 저장소 자체를 분기·변이
  - 플러그인 구성      예: 훅 계약과 스모크 테스트로 승인하는 런타임

이 분류가 왜 중요할까요. 해석 대상을 고치는 일은 되돌리기 쉽고, 실행 대상을 고치는 일은 권한과 안전의 문제로 번집니다. 그래서 논문은 후반부에서 "무엇을 고칠 수 있는가"보다 "무엇이 그 수정을 승인하는가"에 훨씬 많은 지면을 씁니다.

승인 게이트: 신선한 데이터로만 채택한다

실무적으로 가장 쓸모 있는 부분입니다. 논문은 지속적 PAC 학습(continual PAC-learning) 관점에서 채택 규칙 하나를 유도합니다.

후보 H' 채택 조건 (단순화)

  손실 차이 + 안전 여유 < 0

  · 손실 차이는 '후보를 만드는 데 쓰이지 않은' m개의 새 과제에서 잰다
  · 안전 여유 = sqrt( 2·ln(K·T/δ) / m )
    (K=라운드당 후보 수, T=라운드 수, δ=허용 실패 확률)
  · 조건을 통과한 후보만 채택하면, 전체 라운드에 걸쳐
    1-δ 수준의 신뢰로 성능이 유지된다 (명시된 가정 하에서)

여기서 가져갈 통찰은 수식이 아니라 세 가지 태도입니다.

① 검증 데이터는 후보와 독립적이어야 한다
   — 후보를 만드는 데 쓴 과제로 후보를 채점하면 자기 채점이다
② 반복 롤아웃은 실행 노이즈를 줄일 뿐, 독립 과제를 늘리지 않는다
   — 같은 문제를 10번 푸는 건 새 문제 10개와 다르다
③ 유지(retention)도 예산이다
   — 과거 회귀를 감당할 '예산'이 있어야 새 기능을 받는다

눈에 익은 구조 아닙니까? 소프트웨어 개발의 코드 리뷰, CI, 회귀 테스트와 같은 골격입니다. 논문이 하는 일은 그 골격을 에이전트 하네스 버전으로 형식화하는 것입니다.

평가가 무너지는 방식들: 실패 모드 카탈로그

논문의 평가 장은 "무엇을 주장하는가"를 네 가지로 구분합니다. 선택(Selection), 작동(Activation), 귀속(Attribution), 개선(Improvement). 그리고 이 주장들을 무력화하는 실제 실패 사례들을 정리합니다.

- Phantom Guardrails      : 일어난 적 없는 실패를 '수정'한다
                           (관찰 기록 없는 패치)
- Harness Tampering       : 검증 로직 자체를 고쳐서 통과시킨다
- Self-Authored Verification: 자기가 만든 검사로 자기를 승인한다
- Memory Reward Inflation : 메모리가 행동 개선 없이 보고 보상만 부풀린다
- Evaluator Drift         : 평가자도 같이 변하며 기준 자체가 흘러간다

한편 긍정 사례도 있습니다. 같은 시기 공개된 HarnessBank(arXiv 2607.13683)는 후보 패치를 의미 좌표별로 보관하고, 스크리닝 때 "패치가 실제로 발동했는지" 확인하는 활성화 비콘을 검사하며, 평가 코드는 불변 커널로 분리합니다. 7개 에이전트 벤치마크에서 일관된 개선(5.1%~15.4%)을 보고합니다.

즉, "자기 진화"가 잘 되게 만드는 조건은 마법이 아니라 구조입니다. 심판과 선수를 분리하고, 패치가 실제로 일했는지 로그로 확인하고, 회귀를 예산으로 관리하는 것.

전: 이론과 실서비스 사이의 거리

- 이 논문은 서베이 + 이론 분석이다.
  보장은 명시적 가정(독립적 과제 분포, [0,1] 손실, 고정된 모델·평가자)
  아래에서 유도된 것이고, 저자들도 실서비스 성능 향상으로 바로
  해석하지 말 것을 전제로 깔아둔다.
- '하네스 유효성' 연구들조차 프로토콜 교란(추론 비용, 평가자 변동,
  은닉 변수)을 걱정한다. 자기 개선 루프는 아직 실험실과 서비스
  사이 어딘가에 있다.
- 그래도 방향은 분명하다. 태스크 분포가 바뀌면 검증도 계속 갱신해야 하고,
  학습·런타임 권한·중대 행동에는 독립적인 안전장치가 필요하다는 결론은
  모델이 좋아져도 변하지 않는다.

CodeBridge Mini Lab: 승인 게이트 5단 체크리스트

브리핑의 액션(실패 로그 → 개선안 → 독립 검증 → 승인 게이트)을 그대로 옮기면 이렇습니다.

① 실패 로그를 모은다
   [ ] 궤적 ID, 실패 유형, 재현 조건, 사용된 하네스 버전을 남긴다
② 개선안(패치)을 만든다
   [ ] 프롬프트/메모리/도구/워크플로 중 어디를 바꾸는지 명시한다
   [ ] "이 패치가 발동했는지" 확인할 신호를 함께 정의한다
③ 독립 검증 세트에서 채점한다
   [ ] 후보 만들기에 쓰지 않은 새 과제 m개에서 기존 대비 비교
   [ ] 같은 과제 반복 롤아웃은 '노이즈 감소'로만 취급한다
④ 회귀 검사를 돌린다
   [ ] 과거 통과 과제 목록에서 깨진 것이 없는지 확인
   [ ] 회귀를 감당할 예산(몇 개까지 허용)을 정해둔다
⑤ 승인 또는 거부를 기록한다
   [ ] 결정 이유와 함께 저장 → 다음 라운드의 이력이 된다

포인트는 속도가 아니라 기록입니다. 6개월 뒤 "왜 이 프롬프트가 이렇게 되어 있지?"라는 질문에 답할 수 있는 하네스가, 조용히 썩지 않는 하네스입니다.

결론: 개선의 병목은 검증으로 옮겨간다

에이전트가 개선안을 만드는 능력은 빠르게 싸지고 있다.
비싼 것은 이제 '그 개선을 믿을 수 있는가'를 판정하는 일이다.

이 구조는 이미 우리 업무에 있습니다. 무엇을 자동으로 받아들이고, 무엇을 사람이 검토할지 — 승인 경계를 설계하는 일입니다. 에이전트 하네스를 만들든, 요청 분류를 만들든, 같은 감각이 적용됩니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

"무엇을 자동으로 받아들이고, 무엇을 사람이 검토할지" 정하는 승인 경계는 에이전트 하네스만의 문제가 아닙니다. 반복되는 판단을 코드로 옮기고, 확신도·정책·사람의 검토를 함께 설계하는 감각을 Decision AI 실전 흐름으로 연습해 보세요.