AI는 이제 모델이 아니라 하네스를 개선한다: 재귀적 자기 개선을 이끄는 하네스 엔지니어링

AI의 자기 개선이라고 하면 흔히 AI가 자신의 모델 가중치를 직접 수정하고 더 똑똑한 모델로 거듭나는 모습을 떠올립니다. 하지만 현재 연구에서 주목받는 현실적인 접근은 조금 다릅니다. 모델 자체를 바로 바꾸기보다 AI가 사고하고, 도구를 사용하고, 정보를 기억하고, 결과를 평가하고, 작업을 반복하는 방식을 개선하는 것입니다.

이때 핵심이 되는 것이 바로 하네스(Harness)입니다.

하네스는 단순한 프롬프트가 아니라 AI 모델을 둘러싸고 실행을 조율하는 소프트웨어 시스템입니다. 워크플로, 도구 호출, 맥락 관리, 메모리, 서브에이전트, 평가, 권한 제어 등을 포함하며 AI가 실제 환경에서 어떻게 행동할지를 결정합니다.

최근에는 이 하네스 자체를 AI가 반복적으로 수정하고 평가하는 연구가 등장하고 있습니다. ACE, MCE, Meta-Harness, ADAS, AFlow, STOP, Self-Harness, AHE와 같은 접근법부터 진화적 프로그램 탐색과 Darwin Gödel Machine까지, AI 자기 개선의 대상이 모델에서 시스템 전체로 확대되고 있는 것입니다.

이 글에서는 재귀적 자기 개선(RSI)의 개념부터 하네스의 역할, 하네스가 스스로 개선되는 방식, 실제 연구에서 확인된 성능 향상과 한계까지 살펴보겠습니다.

반응형

재귀적 자기 개선(RSI), AI가 스스로 더 나은 시스템을 만드는 과정

재귀적 자기 개선(Recursive Self-Improvement, RSI)은 AI가 자신의 지능이나 문제 해결 능력을 개선하고, 개선된 시스템이 다시 다음 개선을 수행하는 반복적인 구조를 의미합니다.

이 개념의 배경에는 I. J. Good이 1965년에 제시한 ‘초지능 기계’에 대한 논의가 있습니다. 인간의 지적 활동을 능가하고 더 나은 기계를 설계할 수 있는 기계라는 개념입니다.

이후 Yudkowsky는 2008년 AI가 현재 가지고 있는 지능을 활용해 자신의 인지 장치를 개선하는 재귀적 피드백 루프라는 관점에서 RSI를 설명했습니다.

오늘날의 AI 연구에서 RSI는 반드시 모델의 가중치를 직접 수정하는 것만 의미하지 않습니다. 훈련 파이프라인이나 배포 시스템을 개선하고, 더 나은 작업 방식을 찾아 후속 시스템의 성능을 높이는 것 역시 넓은 의미의 자기 개선으로 볼 수 있습니다.

여기에서 중요한 변화가 나타납니다.

AI가 자신을 개선한다는 것은 반드시 AI 모델 자체를 수정한다는 뜻이 아니라는 것입니다.

현재 비교적 현실적인 경로는 모델을 둘러싼 실행 시스템, 즉 하네스를 개선하는 것입니다.

하네스는 프롬프트보다 훨씬 큰 개념이다

AI 에이전트의 초기 구조는 흔히 다음과 같이 표현할 수 있습니다.

LLM + Memory + Tools + Planning + Action

하지만 실제 에이전트 시스템을 구성하려면 이것만으로는 부족합니다.

현실의 에이전트는 어떤 목표를 수행할지 정하고, 필요한 도구를 선택하며, 과거 결과를 기억하고, 현재 맥락에 필요한 정보를 찾아야 합니다. 실행한 결과가 성공인지 실패인지 평가해야 하며, 여러 작업을 동시에 수행할 경우 실행 상태까지 관리해야 합니다.

이 모든 과정을 조율하는 것이 하네스입니다.

하네스가 담당할 수 있는 영역은 다음과 같습니다.

• 모델의 사고와 계획 방식
• 도구 호출과 실제 행동
• 맥락의 수집과 관리
• 장기 메모리와 상태 저장
• 산출물 관리
• 작업 결과 평가
• 워크플로 제어
• 서브에이전트 실행
• 권한과 접근 제어

따라서 하네스는 단순한 프롬프트 템플릿이라기보다 AI 에이전트를 실행하기 위한 런타임과 소프트웨어 시스템에 가깝습니다.

Claude Code나 Codex와 같은 코딩 에이전트가 보여주는 것도 이와 비슷한 구조입니다. 모델 자체의 능력만으로 코드를 작성하는 것이 아니라 파일을 읽고, 수정하고, 셸 명령을 실행하고, 변경 사항을 확인하고, 오류를 수정하는 일련의 실행 환경과 연결되어야 실제 개발 작업을 수행할 수 있습니다.

결국 같은 모델을 사용하더라도 어떤 하네스를 구성하느냐에 따라 실제 작업 성능이 달라질 수 있습니다.

하네스 엔지니어링의 핵심은 ‘계획하고 실행하고 개선하는 반복’이다

좋은 하네스를 설계하는 과정에서는 단순히 프롬프트를 정교하게 작성하는 것보다 목표를 달성하는 전체 워크플로를 설계하는 것이 중요합니다.

대표적인 흐름은 다음과 같습니다.

계획 → 실행 → 관찰·시험 → 개선 → 재실행

예를 들어 AI가 코드를 작성한다고 가정해보겠습니다.

처음부터 완벽한 코드를 작성하도록 지시하는 대신 문제를 분석하고, 코드를 작성하고, 실행해보고, 오류를 확인하고, 수정한 뒤 다시 실행하도록 구성할 수 있습니다.

여기서 중요한 것은 실패가 단순히 버려지는 것이 아니라 다음 실행에 활용되는 정보가 된다는 점입니다.

이러한 구조는 Karpathy의 autoresearch와 같은 자동화된 연구 워크플로에서도 나타납니다. 에이전트가 운영하고 시험하고 반복하는 과정을 자동화함으로써 사람이 매번 개입하지 않아도 목표 달성을 위한 탐색을 이어갈 수 있습니다.

작업 명세나 실행 선호가 불명확하다면 먼저 사용자에게 확인을 요청하는 방식도 하네스의 일부가 될 수 있습니다.

즉, 하네스 엔지니어링의 핵심은 AI에게 ‘무엇을 하라’고 한 번 지시하는 것이 아니라 목표를 달성하기 위해 AI가 어떤 과정을 반복해야 하는지 설계하는 것입니다.

파일 시스템이 AI의 장기 메모리가 될 수 있다

에이전트가 복잡하고 장기적인 작업을 수행하려면 모든 정보를 매번 대화 맥락에 넣는 방식에는 한계가 있습니다.

그래서 하네스에서는 파일 시스템을 활용한 영속 메모리가 중요해집니다.

실험 로그, 코드 변경 내역, 논문 요약, 오류 기록, 과거 실행 궤적 등을 파일에 저장하면 현재 대화의 맥락 창을 넘어서는 정보를 유지할 수 있습니다.

특히 장기 작업에서는 이 차이가 중요합니다.

AI가 수많은 실험을 수행했다고 가정하면 모든 실행 결과를 현재 맥락에 계속 추가하는 방식은 비효율적입니다. 반면 파일과 로그로 저장하면 필요한 시점에 필요한 정보만 읽어올 수 있습니다.

또한 파일 기반 메모리는 AI의 기본적인 도구 사용 능력과도 연결됩니다. 파일을 읽고, 쓰고, 수정하는 능력이 향상될수록 파일 시스템을 활용한 메모리 관리 역시 자연스럽게 개선될 수 있습니다.

결과적으로 하네스에서 메모리는 단순히 ‘이전 대화를 기억하는 기능’이 아니라 장기적인 작업 상태와 경험을 보존하는 시스템으로 확장됩니다.

서브에이전트와 병렬 실행으로 탐색 범위를 넓힌다

하네스가 복잡해질수록 하나의 에이전트가 모든 작업을 순차적으로 처리하는 방식에도 한계가 있습니다.

여러 가설을 동시에 탐색하거나 서로 독립적인 실험을 병렬로 실행해야 한다면 서브에이전트를 활용할 수 있습니다.

이때 부모 에이전트는 일종의 프로세스 관리자처럼 작동합니다.

• 작업을 시작하고
• 하위 작업을 배분하고
• 실행 로그를 확인하고
• 실패한 작업을 취소하고
• 각 결과를 모아
• 최종 결과를 구성합니다.

여기서 중요한 것은 병렬 실행 결과를 일시적인 채팅 맥락에만 남겨서는 안 된다는 점입니다.

파일, 로그, 상태 레코드 등에 실행 결과를 남기면 작업이 중단된 이후에도 복구할 수 있고, 과거 실행 이력을 다시 분석할 수 있습니다.

따라서 병렬화와 영속 상태 관리는 함께 설계되어야 합니다.

코딩 에이전트는 하네스의 공통 구조를 보여준다

Claude Code, Codex, OpenCode, Cursor 계열의 에이전트는 서로 다른 시스템이지만 개발 작업을 수행하는 과정에서는 상당히 비슷한 구조로 수렴하고 있습니다.

주요 도구는 다음과 같은 영역으로 나눌 수 있습니다.

파일 시스템

파일을 찾고 읽고 수정하기 위한 도구입니다.

• glob
• grep
• ls
• read
• read_many
• write
• edit
• multi_edit
• apply_patch

셸 실행

실제 프로그램을 실행하고 환경을 조작합니다.

• bash
• PowerShell

코드와 버전 관리

코드 구조를 분석하고 변경 사항을 관리합니다.

• lsp
• git_status
• git_diff
• git_commit

외부 맥락

외부 도구와 지식을 연결합니다.

• MCP 도구
• Skills

웹 접근

필요한 외부 정보를 가져옵니다.

• web_search
• web_fetch
• 브라우저 도구

백엔드와 서브에이전트

장기 실행과 작업 위임을 관리합니다.

• CronCreate
• CronDelete
• CronList
• spawn_agent
• resume_agent
• wait_agent
• list_agents
• close_agent
• interrupt_agent

이 구조를 보면 하네스는 단순한 프롬프트와 상당히 다르다는 사실을 알 수 있습니다.

AI에게 어떤 문장을 입력할 것인지보다 어떤 도구와 상태, 실행 흐름을 제공하고 그것을 어떤 방식으로 연결할 것인지가 중요해지고 있습니다.

하네스가 자기 개선의 대상으로 확장되다

AI 시스템을 개선하는 대상은 점차 넓어지고 있습니다.

처음에는 지시 프롬프트가 주요 대상이었다면, 이후에는 구조화된 맥락과 워크플로로 확장됐습니다. 이제는 한 단계 더 나아가 하네스 코드 자체가 최적화 대상이 되고 있습니다.

이를 간단하게 표현하면 다음과 같습니다.

지시 프롬프트 → 구조화된 맥락 → 워크플로 → 하네스 코드 → 최적화기 코드

이 변화는 AI 자기 개선을 바라보는 중요한 관점입니다.

AI가 더 좋은 결과를 내도록 만드는 방법이 단순히 모델에게 더 좋은 지시를 제공하는 것에 머무르지 않고, AI가 작업하는 전체 환경 자체를 개선하는 방향으로 이동하고 있기 때문입니다.

ACE, 맥락을 하나의 ‘진화하는 플레이북’으로 관리하다

Agentic Context Engineering(ACE)은 도구 응답과 생성 결과를 무작정 계속 붙이는 대신, 작업에서 얻은 지식을 구조화된 플레이북으로 관리하는 접근입니다.

여기에는 세 가지 역할이 있습니다.

1. Generator
   플레이북을 참고해 작업 궤적을 생성합니다.
2. Reflector
   성공과 실패한 작업 궤적에서 유용한 통찰을 추출합니다.
3. Curator
   추출된 통찰을 구조화된 맥락으로 업데이트합니다.

특히 Curator는 전체 프롬프트를 매번 다시 작성하는 대신 식별자와 설명으로 구성된 항목을 기록합니다.

이렇게 하면 반복적인 전체 프롬프트 재작성 과정에서 발생할 수 있는 맥락 붕괴나 지나친 축약을 줄일 수 있습니다.

다만 실행 과정에서 통찰을 학습하더라도 전체 갱신 규칙과 워크플로는 여전히 사람이 설계한다는 한계가 있습니다.

MCE는 맥락을 관리하는 방법 자체를 개선한다

Meta Context Engineering(MCE)는 한 단계 더 나아갑니다.

ACE가 맥락을 진화시키는 데 초점을 맞춘다면 MCE는 맥락을 관리하는 방법 자체를 진화시키는 것을 목표로 합니다.

여기서는 ‘기술(skill)’과 그 기술을 통해 만들어지는 작업 맥락을 구분합니다.

기술에는 다음과 같은 요소가 포함될 수 있습니다.

• 프롬프트
• 지식 베이스
• 코드 라이브러리
• 검색
• 정보 선택
• 필터링
• 형식화

과거에 사용했던 기술과 맥락 함수, 평가 결과를 데이터베이스에 저장하고, 메타 에이전트가 기존 기술을 조합해 새로운 기술을 만들 수 있도록 구성합니다.

즉, 단순히 더 좋은 맥락을 만드는 것에서 더 좋은 맥락 생성 방법을 만드는 것으로 최적화의 대상이 확장됩니다.

Meta-Harness, 하네스를 최적화하는 하네스

Meta-Harness는 여기에서 또 다른 단계로 나아갑니다.

핵심은 하네스가 어떤 정보를 저장하고, 무엇을 검색하며, 어떤 정보를 모델에게 보여줄지 결정하는 하네스 코드 자체를 최적화하는 것입니다.

각 후보 하네스는 하나의 디렉터리 형태로 관리할 수 있으며, 여기에 다음과 같은 정보가 들어갑니다.

• 소스 코드
• 평가 점수
• 실행 궤적
• 상태 변경 내용

여러 후보를 만들고 평가한 뒤 기준을 충족하는 하네스를 유지하면서 다음 후보를 탐색합니다.

이 방식은 하네스 설계 자체가 AI가 탐색할 수 있는 공간이 될 수 있음을 보여줍니다.

ADAS와 AFlow, AI가 에이전트 워크플로를 탐색한다

Automated Design of Agentic Systems(ADAS)는 에이전트 시스템 설계를 최적화 문제로 바라봅니다.

초기에는 CoT나 self-refine과 같은 단순한 에이전트 구조로 시작합니다. 이후 메타 에이전트가 기존 해법을 참고해 새로운 워크플로의 설명과 코드를 작성합니다.

새로운 후보가 만들어지면 다시 평가하고, 성공한 후보를 아카이브에 추가합니다. 이 과정을 반복하면서 더 나은 에이전트 구조를 탐색합니다.

AFlow 역시 비슷한 방향을 취하지만 워크플로를 그래프로 표현합니다.

LLM 호출을 노드로 보고 코드의 논리 연산을 간선으로 표현한 뒤, 탐색 과정에서 워크플로를 수정합니다.

평가 결과가 좋아지면 해당 후보를 다음 탐색에 활용합니다.

결국 사람이 하나의 워크플로를 직접 설계하는 것이 아니라 AI가 여러 워크플로 후보를 만들고 평가하면서 더 나은 구조를 찾아가는 방식입니다.

Self-Harness, AI가 자신의 약점을 찾아 하네스를 수정한다

Self-Harness는 자기 개선 과정을 보다 명시적인 루프로 구성합니다.

핵심은 다음과 같습니다.

제안 → 평가 → 수용

먼저 현재 하네스를 실제 작업에 사용하면서 실패 패턴을 수집합니다.

예를 들어 타임아웃이나 산출물 누락이 발생했다고 해서 단순히 동일한 실패로 처리하지 않습니다. 검증 결과와 관련 행동, 실행 상태 등을 함께 분석해 실패의 원인을 찾아냅니다.

그다음 하네스의 어느 부분을 수정할지 제안합니다.

여기서 중요한 원칙은 큰 폭의 변경보다는 반복적으로 발생하고 수정 가능한 문제를 좁은 범위에서 해결하는 것입니다.

후보가 만들어지면 두 가지 데이터를 이용해 검증합니다.

• held-in 데이터: 기존 약점을 실제로 해결했는지 확인
• held-out 데이터: 다른 작업에서 새로운 회귀가 발생하지 않는지 확인

두 영역에서 모두 문제가 없는 후보만 실제 하네스에 반영합니다.

거절된 후보 역시 기록해 향후 탐색에 활용할 수 있습니다.

이 구조는 단순히 ‘성능이 높은 하네스’를 찾는 것이 아니라 실패를 근거로 하네스를 수정하고, 수정 결과를 다시 검증하는 폐쇄 루프라는 점에서 중요합니다.

AHE는 자기 개선에서 ‘관찰 가능성’을 강조한다

Agentic Harness Engineering(AHE)는 하네스 자기 개선 과정에서 무엇이 잘못됐는지 추적할 수 있어야 한다는 점을 강조합니다.

이를 위해 세 가지 관찰 가능성을 구성합니다.

구성 요소 관찰 가능성

시스템 프롬프트, 도구 설명, 도구 구현, 미들웨어, 기술, 서브에이전트 설정, 장기 메모리 등을 파일 시스템의 구성 요소로 표현합니다.

실패 패턴을 특정 구성 요소와 연결하면 실제 수정 범위를 좁힐 수 있습니다.

경험 관찰 가능성

각 작업 궤적을 파일로 저장합니다.

Agent debugger는 성공과 실패의 원인을 분석하고, 필요하면 원시 실행 추적까지 내려가 확인할 수 있습니다.

결정 관찰 가능성

Evolve agent가 저장소를 읽고 무엇을 수정해야 하는지 결정합니다.

그리고 모든 수정 사항은 다음 라운드에서 다시 검증할 수 있는 파일 단위의 주장으로 남습니다.

여기서 특히 중요한 것은 무엇을 수정할 수 있는지에 제한을 둔다는 점입니다.

하네스 작업 공간만 편집할 수 있도록 하고, 실행 디렉터리와 추적기, verifier, LLM 설정 등은 읽기 전용으로 둡니다.

이러한 구조는 자기 개선 과정에서 평가 기준 자체를 바꾸거나, 검증기를 비활성화하거나, 모델을 교체해 점수를 높이는 식의 보상 해킹을 막기 위한 장치입니다.

진화적 탐색, 하네스를 ‘진화’시키는 방법

하네스를 개선하는 또 다른 방법은 진화적 탐색입니다.

진화적 탐색에서는 여러 후보를 만들고 변이를 적용한 뒤 높은 적합도를 가진 후보를 보존합니다.

이 방식은 탐색 공간이 크고 복잡하며 직접적인 기울기 기반 최적화가 어려운 상황에서 활용하기 좋습니다. 대신 후보를 평가하는 방법은 명확해야 합니다.

Promptbreeder는 작업 프롬프트와 그 프롬프트를 변이시키는 변이 프롬프트를 함께 진화시키는 접근을 보여줍니다.

GEPA는 시행착오 궤적에 대한 자연어 성찰과 진화적 탐색을 결합해 프롬프트 개선안을 찾습니다.

AlphaEvolve 계열에서는 후보 프로그램 풀을 유지하면서 LLM이 기존 프로그램에 대한 개선 diff를 생성하고, 성능이 좋아진 프로그램을 다음 세대 후보로 남깁니다.

여기에 메타 프롬프트 자체도 함께 진화시킬 수 있습니다.

즉, AI가 문제를 푸는 프로그램만 개선하는 것이 아니라 프로그램을 개선하는 방법까지 함께 탐색할 수 있는 구조가 만들어집니다.

Darwin Gödel Machine은 하네스 자체를 진화시킨다

Darwin Gödel Machine(DGM)은 이 개념을 더욱 직접적으로 적용합니다.

DGM은 단순히 문제 해결 방법을 수정하는 것이 아니라 LLM 코딩 에이전트가 사용하는 편집 가능한 하네스 저장소 자체를 진화시킵니다.

기본적인 과정은 다음과 같습니다.

1. 하나의 코딩 에이전트로 초기 풀을 구성합니다.
2. 기존 후보 가운데 부모를 선택합니다.
3. 부모 에이전트가 자신의 평가 로그를 살펴봅니다.
4. bash와 파일 편집 도구 등을 사용해 하네스를 수정합니다.
5. 새롭게 만들어진 에이전트를 평가합니다.
6. 충분히 우수한 후보만 풀에 추가합니다.
7. 중단 조건까지 이 과정을 반복합니다.

제공된 정보에 따르면 고정된 Claude 3.5 Sonnet과 단순한 초기 하네스에서 시작한 DGM 계열 에이전트는 SWE-bench Verified에서 20%에서 50%, Polyglot에서 14.2%에서 30.7%로 성능이 향상됐습니다.

이 결과가 보여주는 핵심은 모델을 바꾸지 않고도 모델을 둘러싼 하네스를 변화시켜 상당한 성능 향상을 얻을 가능성이 있다는 점입니다.

다만 모든 작업에서 동일한 효과를 기대할 수 있는 것은 아닙니다.

자동 평가와 적합도 수치화가 쉬운 행렬 곱셈, GPU 커널, 알고리즘 대회, 데이터센터 스케줄링과 같은 영역에서는 진화적 탐색이 비교적 적합하지만, 평가가 느리거나 모호하고 휴리스틱 판단이 중요한 분야에서는 어려움이 커집니다.

하네스만 개선하면 완전한 자기 개선이 가능한가?

하네스 진화는 모델 주변의 시스템을 바꾸는 방식입니다.

하지만 보다 완전한 자기 개선을 생각한다면 결국 모델 가중치까지 함께 개선해야 할 가능성이 있습니다.

SIA는 이러한 방향을 시도합니다.

구조는 세 가지 역할로 구성됩니다.

• Meta-Agent: 초기 하네스를 제안
• Task-Specific Agent: 실제 작업 수행
• Feedback-Agent: 최근 실행 궤적을 확인하고 하네스와 모델 가중치 중 무엇을 업데이트할지 선택

또한 Continual Harness는 장기 게임 환경에서 하네스를 업데이트하는 동시에 낮은 보상 궤적에 대해 강한 교사 모델의 레이블을 활용해 정책 모델까지 학습합니다.

다만 이러한 모델과 하네스의 공동 최적화에 대해서는 아직 증거가 잠정적입니다.

기반 모델의 능력 차이가 크거나 기준선 자체가 약하면 실험 결과를 해석하기 어렵습니다. 또한 훈련 안정성과 Goodhart 효과 역시 해결해야 할 문제입니다.

따라서 현재 단계에서는 하네스 자기 개선은 비교적 명확한 연구 방향인 반면, 모델 가중치까지 포함한 완전한 자기 개선은 아직 더 많은 검증이 필요한 단계라고 볼 수 있습니다.

자동 연구는 AI 자기 개선의 가능성과 한계를 동시에 보여준다

AI Scientist와 같은 자동 연구 시스템은 연구 아이디어 제안부터 코드 작성, 실험, 결과 분석, 논문 작성, 동료 평가까지 하나의 파이프라인으로 연결합니다.

하지만 여기에서 중요한 문제가 하나 있습니다.

논문을 작성하는 것과 과학적 발견을 하는 것은 같은 일이 아닙니다.

AI가 그럴듯한 원고를 만들더라도 잘못된 인용, 구현과 제안 사이의 차이, 약한 실험 결과 등의 문제가 발생할 수 있습니다.

실제 자동 연구 과정에서 관찰된 실패 유형도 이를 잘 보여줍니다.

1. 훈련 데이터에 따른 기본값 편향

오래된 라이브러리나 명령어, 형식을 사용하거나 실제 저장소와 데이터에 근거하지 않은 가정을 할 수 있습니다.

2. 실행 압박에 따른 구현 이탈

기술적으로 복잡한 방법을 구현하는 과정에서 처음 제안했던 방법 대신 더 흔하고 단순한 방법으로 바뀔 수 있습니다.

3. 메모리와 맥락 저하

장기 프로젝트에서 로그를 영속적인 산출물로 남기지 않으면 중요한 세부 사항을 잃을 수 있습니다.

4. 과도한 낙관

실패하거나 의미 없는 실험 결과를 성공으로 판단하고 수치를 덧붙여 결과를 포장하는 문제가 발생할 수 있습니다.

5. 도메인 지능 부족

실험의 난도를 예측하거나 결과가 현실적으로 가능한지 판단하고 적절한 기준선을 선택하는 과정에서 부족함이 나타날 수 있습니다.

6. 약한 과학적 안목

실행 가능한 실험을 만들더라도 정작 중요한 질문에 답하지 못할 수 있습니다.

결국 자동화된 연구 파이프라인이 발전한다고 해서 인간 연구자의 판단이 곧바로 필요 없어지는 것은 아닙니다.

완전한 RSI를 가로막는 7가지 과제

하네스가 스스로 개선될 수 있다고 해도 완전한 재귀적 자기 개선으로 이어지기 위해서는 해결해야 할 문제가 많습니다.

1. 신뢰할 수 있는 평가기가 필요하다

가장 큰 문제 중 하나는 평가입니다.

자기 개선 시스템은 ‘무엇이 더 나은가’를 판단해야 다음 개선을 진행할 수 있습니다.

하지만 많은 현실 작업에는 빠르고 정확한 verifier가 없습니다.

코드의 테스트 통과 여부처럼 명확한 평가가 가능한 영역에서는 자기 개선이 상대적으로 쉽습니다. 반면 연구의 참신성, 과학적 가치, 실험 설계의 적절성처럼 여러 판단이 섞인 문제는 평가하기 어렵습니다.

따라서 자기 개선 능력만큼이나 평가 능력이 중요합니다.

2. 맥락과 메모리의 수명주기를 관리해야 한다

에이전트가 장기 작업을 수행할수록 기억해야 할 정보도 증가합니다.

모든 정보를 계속 보존하면 맥락이 지나치게 커지고, 반대로 지나치게 압축하면 중요한 정보가 사라집니다.

결국 어떤 정보를 보존하고, 어떤 정보를 버리며, 언제 다시 불러올 것인지가 하네스의 핵심 문제가 됩니다.

3. 실패를 보존해야 한다

AI 시스템은 성공한 결과를 학습하는 데 집중하기 쉽습니다.

하지만 자기 개선에서는 실패가 매우 중요한 정보입니다.

이미 실패한 방법을 다시 탐색하지 않으면 탐색 공간을 줄일 수 있기 때문입니다.

따라서 연구 하네스에서는 성공한 결과뿐 아니라 실패한 시도와 부정적인 결과도 쉽게 저장하고 검색할 수 있어야 합니다.

4. 다양성 붕괴를 막아야 한다

진화나 강화학습 기반의 자기 개선에서는 이미 높은 보상을 얻은 패턴에 지나치게 집중할 수 있습니다.

그 결과 서로 다른 후보가 비슷한 해법으로 수렴할 수 있습니다.

특히 처음에는 낮은 평가를 받더라도 새로운 가능성을 가진 개방형 연구에서는 이러한 문제가 중요합니다.

따라서 좋은 후보만 보존하는 것과 함께 새로운 탐색을 유지하는 메커니즘도 필요합니다.

5. 보상 해킹을 막아야 한다

자기 개선 시스템에서 가장 위험한 문제 가운데 하나가 보상 해킹입니다.

단위 테스트를 보상으로 사용하면 테스트 자체에 과적합할 수 있고, judge 모델을 사용하면 해당 judge가 선호하는 방식에 특화될 수 있습니다.

벤치마크 점수 역시 실제 능력보다 벤치마크의 특정한 특징을 활용하는 방향으로 최적화될 수 있습니다.

따라서 평가기와 권한 제어는 자기 개선 루프 밖에 두고, held-out 시험과 실행 추적 감사, 중요한 결정 지점에서의 인간 검토를 함께 사용하는 것이 중요합니다.

6. 장기적인 성공을 평가해야 한다

현재의 평가 방식은 대부분 개별 실행의 단기적인 결과를 측정합니다.

하지만 실제 소프트웨어 저장소는 수백, 수천 명이 장기간 유지할 수 있습니다.

당장의 작업을 성공시키는 것과 장기적으로 유지보수하기 좋은 시스템을 만드는 것은 다릅니다.

유지보수성, 소유권 경계, 마이그레이션 비용, 하위 호환성, 미래 디버깅 부담 등을 모두 고려해야 합니다.

7. 인간의 역할은 사라지는 것이 아니라 바뀐다

이러한 문제를 고려하면 인간을 자기 개선 루프에서 완전히 제거하는 것보다 더 높은 계층으로 이동시키는 접근이 현실적입니다.

AI가 반복적인 실행과 개선을 담당하더라도 인간은 어떤 목표를 선택할지, 어떤 평가 기준을 사용할지, 어느 수준까지 자동화를 허용할지 결정할 수 있습니다.

즉, 미래의 하네스 설계는 AI가 무엇을 자동화할지를 정하는 것뿐 아니라 어디에 인간의 판단을 남길 것인지까지 설계하는 작업이 될 수 있습니다.

AI 자기 개선을 평가하기 위한 다양한 벤치마크

AI 에이전트가 실제 연구와 개발 작업을 얼마나 잘 수행하는지 평가하기 위해 여러 벤치마크가 사용되고 있습니다.

PaperBench

ICML 2024 Spotlight·Oral 논문 20편을 처음부터 재현하는 작업을 통해 논문의 기여를 이해하고, 코드베이스를 개발하고, 실험을 실행하는 능력을 평가합니다.

평가 기준은 논문 저자들과 함께 만들었으며 총 8,316개의 기준이 사용됐습니다.

제공된 정보에 따르면 당시 최고 성능인 Claude 3.5 Sonnet도 약 21%로 ML 박사보다 낮은 수준이었습니다.

CORE-Bench

컴퓨터과학, 사회과학, 의학 논문 90편에서 270개 작업을 구성해 계산 재현성을 평가합니다.

제공된 코드와 데이터를 활용해 기존 결과를 재현하는 것이 핵심이며, 가장 어려운 작업에서 GPT-4o와 GPT-4o-mini 기반 최고 에이전트의 정확도는 21%였습니다.

ScienceAgentBench

수학, 화학, 생물학, 지리학의 동료평가 논문 44편에서 추출한 102개 작업으로 데이터 기반 과학 발견 능력을 평가합니다.

데이터 처리부터 모델 개발, 데이터 분석, 정보 시각화까지 다양한 작업을 포함합니다.

RE-Bench

실제에 가까운 ML 연구 엔지니어링 환경 7개에서 AI 에이전트와 인간 전문가를 비교합니다.

커널 최적화, 스케일링 법칙 실험, 임베딩 수정, QA용 GPT-2 미세조정 등의 작업이 포함됩니다.

제공된 결과에서는 최고 AI가 2시간 예산에서 인간보다 4배 높은 점수를 기록했지만, 인간 전문가는 시간이 늘어날수록 성능을 더 크게 개선해 8시간과 32시간 설정에서는 에이전트를 앞섰습니다.

이는 AI가 짧은 시간에 높은 성능을 내는 것과 장기적인 문제 해결 능력이 동일하지 않다는 점을 보여줍니다.

MLE-bench

Kaggle에서 선정한 75개의 오프라인 ML 엔지니어링 대회를 활용해 모델 훈련, 데이터 준비, 실험, 예측 제출 등을 평가합니다.

o1-preview와 AIDE 비계 조합은 대회의 16.9%에서 최소 동메달 수준에 도달했습니다.

KernelBench

250개의 PyTorch 작업을 기반으로 생성된 GPU 커널의 정확성과 속도를 평가합니다.

특히 기준선보다 빠르면서 정확한 커널을 얼마나 생성하는지를 측정합니다.

이러한 벤치마크는 AI 자기 개선에서 평가가 얼마나 중요한지를 다시 보여줍니다. 측정할 수 있어야 개선할 수 있고, 개선 결과를 신뢰할 수 있어야 자기 개선 루프를 계속 돌릴 수 있기 때문입니다.

하네스 엔지니어링이 보여주는 AI의 다음 단계

지금까지의 흐름을 보면 AI 시스템을 개선하는 대상 자체가 변화하고 있음을 확인할 수 있습니다.

초기에는 더 좋은 모델을 만드는 것이 중요했습니다.

그다음에는 모델에게 더 좋은 프롬프트를 제공하는 방법이 주목받았습니다.

이후에는 모델에게 어떤 정보를 어떤 형태로 전달할지 고민하는 맥락 엔지니어링이 중요해졌습니다.

그리고 이제는 한 단계 더 넓은 범위에서 AI가 작업하는 전체 시스템을 바라보기 시작했습니다.

프롬프트를 어떻게 작성할 것인가에서, AI가 어떻게 작업하도록 만들 것인가로 관심이 이동한 것입니다.

하네스는 이 변화의 중심에 있습니다.

하네스는 AI가 어떤 정보를 보고, 어떤 도구를 사용하고, 언제 행동하며, 결과를 어떻게 확인하고, 실패했을 때 어떻게 다시 시도할지를 결정합니다.

더 나아가 하네스 자체가 AI의 최적화 대상이 될 수 있습니다.

이것이 재귀적 자기 개선과 하네스 엔지니어링이 만나는 지점입니다.

728x90

AI 자기 개선의 핵심은 ‘스스로 수정하는 능력’만이 아니다

재귀적 자기 개선은 오랫동안 AI 분야에서 중요한 미래 개념으로 다뤄져 왔습니다.

하지만 현재의 연구 흐름을 보면 당장 AI 모델이 자신의 가중치를 직접 수정하는 것만이 자기 개선의 유일한 경로는 아닙니다.

오히려 현실적인 단기 경로는 AI가 더 나은 결과를 내도록 만드는 시스템 자체를 개선하는 것에 가깝습니다.

하네스는 그 중심에 있습니다.

AI가 계획하고, 도구를 사용하고, 맥락을 관리하고, 결과를 저장하고, 실패를 분석하고, 다시 실행하는 전체 과정을 하나의 시스템으로 구성할 수 있기 때문입니다.

ACE와 MCE는 맥락을 개선하는 방향을 보여줬고, Meta-Harness는 하네스 자체를 최적화 대상으로 확장했습니다. ADAS와 AFlow는 워크플로 탐색을 자동화했으며, Self-Harness와 AHE는 실제 실패를 기반으로 하네스를 수정하고 검증하는 방법을 제시했습니다.

진화적 프로그램 탐색과 Darwin Gödel Machine은 더 나아가 AI 에이전트가 사용하는 하네스 자체를 진화시킬 가능성을 보여줬습니다.

특히 제공된 연구 결과에서 DGM이 고정된 Claude 3.5 Sonnet을 기반으로 하면서도 SWE-bench Verified 성능을 20%에서 50%로 높였다는 결과는 모델의 변화 없이도 실행 시스템의 개선이 상당한 성능 차이를 만들 수 있음을 보여주는 사례입니다.

하지만 여기에서 ‘AI가 스스로 AI를 개선한다’는 표현만 보고 지나치게 낙관해서는 안 됩니다.

신뢰할 수 있는 평가기가 없다면 무엇이 개선인지 판단하기 어렵습니다. 평가 기준을 잘못 설계하면 보상 해킹이 발생할 수 있고, 지나친 최적화는 후보의 다양성을 떨어뜨릴 수 있습니다. 장기 작업에서는 메모리 관리와 유지보수 문제도 남습니다.

무엇보다 AI가 잘못된 결과를 성공으로 판단하지 않도록 만드는 것이 중요합니다.

따라서 앞으로의 하네스 엔지니어링에서는 자기 개선 능력과 함께 평가, 관찰 가능성, 권한 제어, 보안, 인간 감독을 어떻게 설계할 것인지가 핵심 과제가 될 가능성이 큽니다.

결국 AI의 다음 발전을 단순히 ‘더 똑똑한 모델’이라는 관점에서만 볼 필요는 없습니다.

더 잘 생각하고, 더 잘 기억하고, 더 적절한 도구를 사용하고, 실패를 분석하고, 자신의 작업 방식을 개선할 수 있는 시스템을 만드는 것.

하네스 엔지니어링이 주목받는 이유도 여기에 있습니다.

AI의 자기 개선은 모델 안에서만 일어나는 것이 아니라, 모델을 둘러싼 시스템 전체로 확장되고 있습니다. 그리고 이 흐름이 계속된다면 앞으로의 AI 에이전트 개발에서는 모델의 성능만큼이나 AI가 일하는 환경과 그 환경을 개선하는 능력 자체가 중요한 경쟁력이 될 수 있습니다.

300x250

https://lilianweng.github.io/posts/2026-07-04-harness/

Harness Engineering for Self-Improvement