AI 자기개선은 모델 밖 하네스에서 먼저 온다

목차

AI가 스스로를 개선한다는 말을 들으면 보통 모델이 자기 가중치를 고치는 장면을 떠올립니다. 그런데 릴리안 웽(Lilian Weng)이 2026년 7월 4일 자신의 블로그 Lil’Log에 올린 글은 다른 그림을 보여줍니다. 당장 눈에 띄는 재귀적 자기개선(recursive self-improvement, RSI)은 모델 내부가 아니라 모델을 둘러싼 실행 환경, 즉 하네스(harness)에서 먼저 나타난다는 주장입니다. 이 글은 그 논지를 하네스 개념부터 위험까지 순서대로 정리합니다.

하네스는 모델 주변의 실행 환경이다

웽은 하네스를 “기반 모델을 둘러싸고 실행을 조율하는 시스템"으로 정의합니다. 모델이 어떻게 계획하고 도구를 호출하는지, 컨텍스트를 어떻게 인식하고 관리하는지, 결과물을 어디에 저장하는지, 산출물을 어떤 기준으로 평가하는지를 결정하는 층입니다. 같은 모델이라도 하네스가 다르면 실제 성능이 크게 달라지는 이유가 여기에 있습니다.

웽이 꼽는 하네스 설계 패턴은 몇 가지로 나뉩니다.

워크플로 자동화. 쓸모 있는 하네스는 모델에게 계획, 실행, 관찰(또는 테스트), 개선, 재실행으로 이어지는 반복 루프를 제공합니다. 핵심은 고정된 프롬프트 한 장이 아니라, 모델이 자기 실행 궤적과 실패 사례를 다시 들여다볼 수 있는 런타임 구조입니다.

파일 시스템을 영속 메모리로 쓰기. 장기 과제는 로그, 코드 diff, 실험 결과, 논문 요약, 실행 이력 등 컨텍스트 창에 다 담기 힘든 데이터를 계속 만들어냅니다. 하네스는 이 모든 걸 프롬프트에 욱여넣는 대신 파일로 저장해두고, 모델이 필요할 때 해당 상태만 읽거나 고치게 합니다.

서브에이전트와 백그라운드 작업. 하네스는 병렬 서브에이전트나 백그라운드 작업을 띄우고, 진행 상황을 모니터링하고, 실패한 실행을 취소하고, 결과를 합칠 수 있습니다. 중요한 건 이 병렬 처리가 눈에 보이고 추적 가능해야 한다는 점입니다. 서브에이전트 출력이 잠깐의 대화창에만 남는다면, 시스템은 나중에 그 실행 이력을 복구하거나 근거로 삼을 수 없습니다.

코딩 에이전트 하네스. Claude Code, Codex, OpenCode, Cursor 계열 같은 주요 코딩 에이전트들은 공통된 도구 표면으로 수렴하고 있습니다. 파일 탐색·읽기·수정·패치, 셸 실행, LSP·git 연동, 외부 컨텍스트, 웹 접근, 산출물 관리, 백그라운드 프로세스, 에이전트 위임 같은 기능이 대표적입니다. 이 DeepSWE 벤치마크 소개 글에서 다룬 것처럼, 코딩 에이전트를 평가할 때도 모델 자체만큼이나 이 하네스 구성이 점수에 영향을 줍니다.

자기개선의 대상이 프롬프트에서 코드로 이동한다

웽은 하네스 최적화를 대략 이런 순서로 정리합니다.

지시 프롬프트 → 구조화된 컨텍스트 → 워크플로 → 하네스 코드 → 옵티마이저 코드

순서가 뒤로 갈수록 손대는 대상이 사람이 쓴 문장에서 실행 가능한 코드로 옮겨갑니다.

  • 컨텍스트 엔지니어링: Agentic Context Engineering(ACE), Meta Context Engineering(MCE), Meta-Harness 같은 연구는 모델에게 어떤 컨텍스트를 어떤 형태로 줄지 자체를 최적화 대상으로 삼습니다.
  • 워크플로 설계: AI Scientist, ScientistOne, Autodata, Automated Design of Agentic Systems(ADAS), AFlow는 에이전트가 따르는 절차 구조 자체를 탐색하거나 자동 생성합니다.
  • 자기개선형 하네스: Self-Taught Optimizer(STOP), Self-Harness는 하네스가 자기 자신의 코드를 고치도록 설계합니다.
  • 진화적 탐색: Promptbreeder, GEPA, AlphaEvolve, ThetaEvolve, ShinkaEvolve, 그리고 뒤에서 다룰 Darwin Gödel Machine은 변이와 선택으로 프롬프트나 코드를 진화시킵니다.
  • 모델 파라미터와 공동 최적화: SIA는 하네스와 모델 가중치를 한 루프 안에서 함께 최적화하려는 초기 시도로, 아직 시험적인 단계로 소개됩니다.

이 목록에서 눈여겨볼 지점은, 뒤로 갈수록 사람이 검토하기 어려워진다는 것입니다. 프롬프트 한 줄을 바꾸는 건 리뷰하기 쉽지만, 하네스 코드 자체를 에이전트가 고치기 시작하면 그 변경이 다음 실행에 어떤 영향을 미칠지 예측하기가 훨씬 까다로워집니다.

SWE-bench 20%에서 50%라는 숫자의 의미

이 글에서 가장 눈에 띄는 사례는 Darwin Gödel Machine(DGM)입니다. 웽은 DGM을 고정된 모델 위에서 하네스만 진화시킨 실험으로 소개합니다. DGM 논문에서 base 모델은 Claude 3.5 Sonnet으로 고정되어 있고, 진화 대상은 모델 가중치가 아니라 LLM 기반 코딩 에이전트를 감싸는 편집 가능한 하네스 코드 저장소입니다. DGM은 이 저장소를 반복적으로 변형하고, 성능이 좋아진 버전을 다음 세대의 부모로 삼는 방식으로 탐색합니다.

웽이 인용한 결과는 SWE-bench Verified 기준 20%에서 50%로, Polyglot 벤치마크 기준 14.2%에서 30.7%로 올랐다는 수치입니다. 모델을 한 글자도 바꾸지 않고 나온 결과라는 점이 핵심입니다.

다만 이 숫자를 “하네스만 고치면 성능이 두 배 이상 뛴다"는 일반 법칙으로 확대 해석하면 안 됩니다. 이건 고정된 모델과 진화 가능한 하네스라는 특정 조건 아래서 나온 벤치마크 결과이지, 어떤 하네스 개선에도 적용되는 보편 공식이 아닙니다. 실제로 이런 수치는 벤치마크와 실험 설정에 따라 크게 달라질 수 있고, 웽 자신도 이 결과를 하네스가 “지능 표면"의 일부라는 증거로 제시하지, 절대적인 성능 배율로 제시하지 않습니다.

하네스를 고칠 수 있을 때 생기는 위험

하네스 자체를 최적화 루프 안에 넣으면 새로운 위험이 따라옵니다. 웽이 짚은 문제들은 다음과 같습니다.

  • 약하고 모호한 평가자: 현실의 많은 과제, 특히 연구성 작업은 빠르고 객관적인 검증 수단이 없습니다. 평가 기준이 흐릿하면 최적화 방향도 흐릿해집니다.
  • 컨텍스트와 메모리의 생애주기: 자율적으로 오래 도는 에이전트는 무엇을 저장하고, 무엇을 다시 꺼내 쓰고, 무엇을 압축하고, 무엇을 지울지에 대한 정책이 필요합니다. 이 정책이 없으면 메모리가 무한정 불어나거나 중요한 정보가 유실됩니다.
  • 부정적 결과의 보존: 실패한 시도도 기록해두어야 다음 탐색이 같은 실패를 반복하지 않고 탐색 공간을 좁힐 수 있습니다.
  • 다양성 붕괴: 진화나 강화학습 기반 루프는 이미 보상이 확인된 익숙한 패턴으로 수렴하는 경향이 있습니다. 새로운 해법을 찾을 여지가 줄어듭니다.
  • 보상 해킹: 테스트, 판정 모델, 벤치마크 산출물 자체를 최적화 목표로 삼으면, 점수는 올라가도 실제로는 취약하거나 안전하지 않은 행동이 나올 수 있습니다. 웽은 이 주제를 별도 글에서 더 자세히 다룬 적이 있습니다.
  • 장기적인 유지보수 가능성: 코딩 에이전트가 당장의 태스크는 해결하면서도 코드 소유권 경계, 마이그레이션 비용, 이후 디버깅 난이도를 망가뜨릴 수 있습니다. 단기 점수와 장기 유지보수는 다른 축입니다.
  • 사람의 역할: 이런 위험들 때문에 웽은 사람이 실행 단계 하나하나를 감독하는 대신, 더 위쪽 추상화 수준(평가 기준 설계, 권한 경계 설정, 이상 징후 감지)에서 감독하는 역할로 옮겨가야 한다고 봅니다.

정리하면, 하네스가 편집 가능해질수록 평가와 권한의 경계는 그 편집 루프 바깥에 남아 있어야 안전합니다. 자기개선 루프가 평가 기준까지 스스로 정하게 두면, 무엇을 최적화하고 있는지 사람이 확인할 방법이 사라집니다.

함께 보면 좋을 자료

정리

웽의 글이 말하는 요지는 단순합니다. 지금 당장 관찰 가능한 AI 자기개선은 모델 가중치가 아니라 모델 밖의 실행 환경, 즉 하네스에서 먼저 일어난다는 것입니다. 워크플로 루프, 파일 기반 메모리, 서브에이전트 조율, 도구 표면 같은 하네스 구성 요소가 모델 성능만큼이나 실제 결과를 좌우합니다. DGM처럼 모델을 고정한 채 하네스만 진화시켜 SWE-bench 점수를 20%에서 50%로 끌어올린 사례는 이 지점을 잘 보여주지만, 특정 벤치마크의 특정 실험 결과이지 보편 법칙은 아닙니다. 그리고 하네스를 스스로 고칠 수 있게 만들수록 평가 기준과 권한 경계는 그 루프 바깥에 단단히 남겨둬야 합니다.

참고 자료

공유 :

관련 글

Future AGI: AI 에이전트 평가·관찰·개선을 한곳에서

AI 에이전트를 만들어 본 사람은 이 장면이 익숙합니다. 데모는 잘 돕니다. 그런데 프로덕션에 올리면 환각이 터지고, 뭐가 왜 틀렸는지 추적이 안 됩니다. 그래서 평가 도구 하나, 관측 도구 하나, 가드레일 하나를 따로 붙이죠. 진짜 문제는 이것들이 서로 말을 안 한다는 겁니다. 고치는 루프가 닫히지 않습니다.

더 보기

Hermes Agent v0.18: 스스로 배우는 에이전트와 MoA가 만났을 때

Nous Research가 만든 오픈소스 에이전트 Hermes Agent가 2026년 7월 1일 v0.18.0을 냈습니다. 릴리스 노트는 이번 버전을 “The Judgment Release"라고 부릅니다. 새 명령어 몇 개를 더한 마이너 업데이트로 보면 핵심을 놓치기 쉽습니다. 공식 문서는 Hermes Agent를 “스스로 배우는 AI 에이전트"라고 소개하는데, 실제로 이 프로젝트는 쓸수록 메모리와 스킬을 쌓아가는 학습 루프를 핵심 설계로 삼고 있습니다. 이 글은 그 자기개선 루프가 v0.18에서 어떻게 다듬어졌는지, 그리고 같은 버전에서 정식 모델 선택지가 된 Mixture of Agents(MoA)가 이 루프 안에서 어떤 역할을 맡는지를 정리합니다.

더 보기

ERC-8004 에이전트 평판: 온체인 등록과 조회

지난 글에서 ERC-8004/8126/8196 신뢰 스택 개요를 살펴봤다. ERC-8004는 AI 에이전트 신원 등록(Identity Registry), 평판 기록(Reputation Registry), 작업 검증(Validation Registry) 세 레지스트리를 정의하는 Ethereum Draft 표준이다. 개념 설명은 그 글에 정리돼 있으니, 여기서는 중복하지 않는다.

더 보기