Meta-Harness: AI 에이전트가 자기 하네스를 스스로 다시 짜기 시작했습니다

저는 그동안 하네스를 손으로 다뤄 왔습니다. 여기서 하네스(harness)란 AI 모델을 실제로 굴리는 바깥 구조물을 말합니다.

 

프롬프트를 어떻게 조립할지, 컨텍스트에 무엇을 넣고 뺄지, 과거 기록을 어떻게 기억하게 할지 같은 것들입니다. 같은 모델이라도 이 구조물을 어떻게 짜느냐에 따라 성능이 크게 갈립니다.

 

이 블로그의 하네스 시리즈는 줄곧 "그래서 하네스를 어떻게 잘 설계하느냐"를 다뤄 왔습니다.

 

그런데 최근에 읽은 논문 한 편이 그 전제를 흔들었습니다. 하네스를 잘 설계하는 법이 아니라, 하네스를 설계하는 일 자체를 에이전트에게 맡기는 연구였습니다.

 

오늘 글은 제가 이 논문을 직접 돌려 본 결과가 아니라, 공개된 논문과 자료를 바탕으로 정리한 해설입니다. 다만 손으로 하네스를 튜닝해 온 사람으로서 이게 무슨 의미인지는 제 나름의 관점으로 붙여 보려 합니다.

 

먼저, 이건 예전에 다룬 그 "메타하네스"가 아닙니다

 

이름이 비슷해서 헷갈리실 수 있어 먼저 정리하겠습니다. 예전에 이 블로그에서 다룬 "메타하네스"는 Anthropic이 에이전트의 세션을 통째로 저장하고 다시 이어 붙이는, 플랫폼 차원의 가상화 이야기였습니다.

 

오늘 이야기하는 Meta-Harness는 그것과 이름만 겹칠 뿐 전혀 다른 연구입니다. 이쪽은 하네스의 성능을 에이전트가 스스로 다시 프로그래밍해서 끌어올리는 자동 최적화에 관한 것입니다.

 

Meta-Harness는 무엇을 하나

 

논문 제목은 "Meta-Harness: End-to-End Optimization of Model Harnesses"이고, arXiv 번호는 2603.28052입니다. 저자에는 DSPy를 만든 Omar Khattab과 Chelsea Finn이 포함돼 있고, 소속은 Stanford, MIT, 그리고 한국 게임사 KRAFTON입니다.

 

국내 회사가 공저로 들어간 점이 개인적으로 반가웠습니다.

 

핵심 아이디어는 이렇습니다. 보통은 하네스를 개선하는 로직을 사람이 바깥에 따로 짜 둡니다.

 

이 논문은 그 개선 작업 자체를 코딩 에이전트에게 넘깁니다. 에이전트에게 과거 시도의 원본 실행 기록에 자유롭게 접근할 권한을 주고, grep이나 cat 같은 도구로 필요한 부분을 스스로 골라 읽게 합니다.

 

그렇게 읽은 내용을 근거로 검색 로직과 메모리 관리, 프롬프트 조립 구조를 반복해서 다시 짜 나갑니다. 사람이 손대던 튜닝을 에이전트가 대신 하는 셈입니다.

 

숫자로 본 결과

 

논문이 보고한 대표적인 결과를 표로 정리했습니다.

 

과제	결과
온라인 텍스트 분류	기존 최고 성능 시스템(ACE) 대비 +7.7점, 동시에 컨텍스트 토큰 약 4배 절약
검색증강 수학추론	자동으로 찾아낸 단일 하네스가 학습에 안 쓴 모델 5종에서 평균 +4.7점
코딩 에이전트 벤치마크	자동 최적화 하네스가 사람이 수동으로 설계한 하네스들을 넘어섬

 

더 좋은 성능을 더 적은 연산으로 냈다는 점이 눈에 띕니다. 그리고 한 모델에 맞춰 찾은 하네스가 처음 보는 다른 모델에서도 성능을 올렸다는 점은, 이 방식이 특정 모델에만 통하는 요령을 넘어선다는 신호로 읽힙니다.

 

가장 인상적이었던 교훈: 원본 기록을 버리지 마라

 

개인적으로 가장 오래 곱씹은 대목은 성능 숫자가 아니었습니다. 이 방식이 통하려면 과거 실행의 원본 기록이 그대로 남아 있어야 한다는 점이었습니다.

 

논문에 따르면 그 기록을 요약본으로 갈아 끼우면 성능이 무너집니다. 압축되지 않은 실제 실행 디테일 안에 개선의 실마리가 들어 있다는 뜻입니다.

 

이건 제가 평소에 작업 기록과 실패 로그를 요약하지 않고 원본 그대로 보존해 온 습관과 정확히 맞닿습니다. 당장 사람이 다시 읽지 않더라도, 나중에 무언가가 그 기록을 뒤져 개선의 단서를 찾을 수 있기 때문입니다.

 

실패의 흔적을 깔끔하게 지우는 대신 지저분한 채로 남겨 두는 편이 낫다는 것을, 이 논문이 실험으로 보여 준 셈입니다.

 

하네스가 "설정"에서 "컴파일러"로

 

한 업계 관찰자는 이 흐름을 두고 하네스가 고정된 설정값에서 컴파일러에 가까운 무언가로 변하는 지점이라고 표현했습니다. 사람이 한 번 정해 두는 값이 아니라, 목표에 맞춰 알아서 코드를 다시 뽑아내는 도구로 바뀐다는 이야기입니다.

 

실제로 이 방식에서는 개선을 제안하는 쪽이 한 번 돌 때마다 수십 개의 파일을 읽어 가며 진단을 내립니다. 사람이 눈으로 훑기 어려운 규모입니다.

 

그래서 손으로 하네스를 짜 온 사람에게 무슨 의미인가

 

솔직히 처음엔 마음이 복잡했습니다. 하네스를 잘 짜는 감각이 1인 개발자에게는 나름의 차별화 지점이었는데, 그 감각마저 자동화된다면 남는 자리가 어디인가 싶었습니다.

 

며칠 생각해 보니 답은 한 칸 위로 옮겨 가 있었습니다. 에이전트가 하네스를 다시 짜 준다 해도, "무엇을 잘하게 만들 것인가"와 "무엇으로 잘함을 판정할 것인가"는 여전히 사람이 정해야 합니다.

 

문제를 정의하고 평가 기준을 세우는 일입니다. 튜닝의 손이 자동화될수록, 오히려 이 위층의 판단이 더 중요해집니다.

 

마지막으로 한 가지만 덧붙이겠습니다. 이 논문은 아직 동료 심사를 거치지 않은 arXiv 프리프린트입니다.

 

수치와 결론은 앞으로 검증 과정에서 다듬어질 수 있으니, 방향의 신호로 읽으시길 권합니다. 그래도 하네스를 짜는 일 자체가 자동화되는 프론티어가 이미 열렸다는 사실만큼은, 손으로 하네스를 다뤄 온 저에게 분명한 전환점으로 다가왔습니다.