Meta-Harness 논문 핵심 정리

원문: Meta-Harness: End-to-End Optimization of Model Harnesses (Lee et al., 2026)
성격: 블로그 초안으로 바로 옮겨 적기 쉽게, 핵심 주장·기여·실험 결과·시사점을 중심으로 정리한 문서
메모: 아래 figure는 원문 PDF의 핵심 영역만 신중하게 crop해서 넣었습니다. 수치는 업로드된 논문 본문 기준으로 정리했습니다.

---

1. 이 논문을 한 문장으로 요약하면

LLM의 성능은 모델 weights만이 아니라 하네스(harness)—즉, 무엇을 저장하고, 무엇을 검색하고, 어떤 순서로 모델에 보여줄지 결정하는 코드—에 크게 좌우되며, Meta-Harness는 이 하네스 자체를 coding agent가 end-to-end로 탐색하도록 만든 시스템입니다.

핵심 메시지
이 논문의 승부처는 “더 많은 샘플링”이 아니라, 이전 시도의 코드·점수·실행 추적(execution traces)을 압축하지 않고 그대로 활용하는 방식에 있습니다.

 

한눈에 보는 핵심 성과

영역	비교 기준	Meta-Harness 결과	핵심 포인트
온라인 텍스트 분류	ACE 40.9 / MCE 40.0	48.6	정확도를 끌어올리면서도 context cost를 낮춤
수학 추론 (200개 IMO-level 문제, 5개 held-out 모델 평균)	No Retriever 34.1 / BM25 37.5	38.8	“retrieval을 붙이는 것”보다 “어떻게 retrieval할지”를 찾는 것이 중요함
TerminalBench-2	Opus 4.6: Terminus-KIRA 74.7 / Haiku 4.5: Goose 35.5	76.4 / 37.6	hand-engineered agent harness를 자동 탐색으로 추월

 

 

그림 1. 원문 Figure 1의 핵심 패널을 재구성한 이미지. 왼쪽은 텍스트 분류 search progress, 오른쪽은 TerminalBench-2에서의 harness 성능 비교.

---

2. 왜 이 논문이 중요한가

이 논문이 던지는 가장 중요한 질문은 단순합니다.
“정말 모델 자체만 좋아지면 되는가?”

저자들의 답은 명확합니다. 아니다.
같은 모델이라도 그 모델을 감싸는 하네스가 어떻게 설계되느냐에 따라 성능 차이가 크게 벌어질 수 있습니다. 하네스는 단순 프롬프트 템플릿이 아니라, 다음과 같은 의사결정을 담당합니다.

• 어떤 과거 정보를 메모리에 저장할 것인가
• 무엇을 언제 retrieval할 것인가
• 어떤 순서와 형식으로 모델에 보여줄 것인가
• 모델 호출 전후에 상태를 어떻게 갱신할 것인가

즉, 이 논문은 “프롬프트 최적화”보다 한 단계 바깥의 문제, 다시 말해 시스템 레벨의 context engineering을 자동화하려는 시도라고 볼 수 있습니다.

기존 text optimizer가 여기서 잘 안 맞는 이유

저자들이 보기에 기존 방법들의 공통적인 한계는 feedback compression입니다.
많은 방법이 다음 셋 중 하나에 의존합니다.

1. 점수만 본다.
   어떤 candidate가 좋았는지/나빴는지만 알고, 왜 그랬는지는 모릅니다.
2. 짧은 summary만 본다.
   실패 사례의 원인을 압축해서 주기 때문에, 긴 실행 흐름에서 발생한 문제의 원인을 거슬러 올라가기가 어렵습니다.
3. 현재 candidate 근처만 본다.
   전체 search history를 가로질러 비교하기보다, 직전 후보나 제한된 window만 참조합니다.

하지만 harness engineering은 본질적으로 long-horizon credit assignment 문제에 가깝습니다.
예를 들어 메모리에 무엇을 저장하는지에 대한 작은 변화가 몇 단계 뒤의 retrieval과 의사결정에 연쇄적으로 영향을 줄 수 있습니다. 이런 문제에서는 scalar score나 짧은 summary만으로는 실패 원인을 파악하기 어렵습니다.

저자들은 이 지점을 정면으로 찌릅니다.
하네스 탐색에는 더 덜 압축된 진단 정보(raw code, traces, scores)가 필요하다는 것이 이 논문의 핵심 문제의식입니다.

---

3. Meta-Harness의 핵심 아이디어

Meta-Harness는 구조상 매우 단순합니다.

1. 이전 후보 하네스들의 코드, 점수, 실행 로그를 파일시스템에 저장한다.
2. coding agent가 그 파일시스템을 직접 탐색해 다음 하네스를 제안한다.
3. 제안된 하네스를 평가하고, 다시 그 결과를 파일시스템에 저장한다.
4. 이 과정을 반복한다.

 

 

그림 2. 원문 Figure 2 (p.2). Meta-Harness의 propose → evaluate → log 반복 구조.

이 구조에서 중요한 설계 포인트 4가지

3.1 Raw LLM이 아니라 coding agent proposer

저자들은 proposer를 일반 LLM이 아니라 developer tools를 다룰 수 있는 coding agent로 둡니다.
이유는 간단합니다. search history가 커지면 모든 정보를 한 번에 prompt에 넣을 수 없기 때문입니다. 그래서 proposer는 grep, cat 같은 표준 도구로 필요한 파일만 골라 읽습니다.

3.2 전체 히스토리를 filesystem으로 노출

Meta-Harness는 이전 시도들을 summary로 압축해서 prompt에 넣지 않습니다.
각 candidate마다 별도 디렉터리를 만들고, 그 안에 소스 코드, 점수, 실행 traces를 저장합니다. proposer는 여기서 원시 로그를 선택적으로 검사합니다.

3.3 Search heuristic을 최소화

기존 evolutionary/program search 류 방법은 parent selection, mutation template, critique format 같은 구조를 강하게 고정하는 경우가 많습니다. 반면 Meta-Harness는 outer loop를 의도적으로 단순하게 두고, 무엇을 읽고 어떤 수정을 할지는 proposer가 결정하도록 맡깁니다.

3.4 Search space를 code space로 둔다

최적화 대상은 한 줄짜리 prompt가 아니라, retrieval/memory/prompt-construction/orchestration logic를 포함한 실행 가능한 하네스 코드 전체입니다. 그래서 국소적인 prompt tweak가 아니라, 알고리즘적 구조 자체를 바꿀 수 있습니다.

왜 이게 먹히는가

이 논문에서 가장 설득력 있는 포인트는 “full history access가 실제로 유의미한가?”에 대한 대답입니다.
저자들은 TerminalBench-2 search에서 proposer가 iteration당 median 82개 파일을 읽었다고 보고합니다. 즉, proposer가 형식적으로만 filesystem을 받는 것이 아니라, 실제로 과거 코드와 실행 traces를 넓게 훑으면서 원인을 추적하고 있다는 뜻입니다.

---

4. 실험 결과: 어디서 얼마나 좋아졌는가

4.1 온라인 텍스트 분류

이 설정에서는 LLM이 라벨이 붙은 예시를 순차적으로 보면서 메모리를 갱신하고, 이후 test set에서 분류 성능을 평가합니다. 저자들은 LawBench, Symptom2Disease, USPTO-50k 세 데이터셋을 사용했습니다.

결과 요약

• Meta-Harness: 48.6
• ACE: 40.9
• MCE: 40.0

즉, 논문 기준으로 Meta-Harness는 ACE 대비 +7.7 point, MCE 대비 +8.6 point 향상을 보입니다.

더 흥미로운 점은 context cost까지 줄였다는 것입니다.

• Meta-Harness: 11.4K
• ACE: 50.8K
• MCE: 28.5K

즉, 더 많은 문맥을 욱여넣어서 이긴 것이 아니라, 더 나은 retrieval/구성 전략으로 이긴 것입니다.

 

 

그림 3. 원문 Figure 3 (p.6). Meta-Harness는 정확도-문맥 비용 Pareto frontier 자체를 바꿉니다.

이 실험에서 진짜 중요한 포인트

이 부분은 단순히 “성능이 올랐다”보다 더 중요합니다.

저자들은 ablation으로 proposer에게 주는 정보를 줄여 봅니다.

• Scores only: 점수와 코드만 제공
• Scores + summary: 점수, 코드, LLM이 만든 요약까지 제공
• Full Meta-Harness: 점수, 코드, raw execution traces 제공

결과는 명확합니다. raw execution traces에 접근한 full 설정이 압도적으로 좋습니다.
즉, Meta-Harness의 핵심은 단순한 evolutionary search가 아니라, 실패 로그를 압축하지 않고 읽게 하는 인터페이스에 있습니다.

---

5. 이 논문이 “무엇을 발견했는가”: 발견된 하네스의 구조

논문의 재미는 결과 숫자만이 아니라, search가 실제로 읽을 만한 전략을 찾아낸다는 데 있습니다.

5.1 텍스트 분류에서 찾은 고성능 하네스: Label-Primed Query-Anchored

 

 

그림 4. 원문 Figure 6 (p.19). 최고 정확도 쪽 frontier를 구성한 분류 하네스.

이 하네스는 한 번의 큰 호출 안에서 세 가지 블록을 만듭니다.

1. Label primer
   가능한 라벨 공간을 먼저 명시합니다.
2. Coverage block
   각 라벨마다 query와 관련성이 높은 대표 예시를 하나씩 넣습니다.
3. Contrastive pairs
   현재 query 주변에서 서로 비슷하지만 라벨이 다른 예시들을 나란히 보여 줍니다.

이 설계의 장점은 분명합니다.
모델이 단순 nearest neighbors만 보는 것이 아니라, 전체 라벨 공간과 국소 decision boundary를 동시에 보게 됩니다.

5.2 저비용형 분류 하네스도 함께 발견함

논문은 최고 성능형 외에도 Draft Verification 같은 저비용 variant를 함께 보고합니다.
이 방식은 먼저 짧은 문맥으로 draft label을 만든 뒤, 그 draft를 지지하는 예시와 반박하는 예시를 다시 가져와 최종 판정을 내립니다.
즉, Meta-Harness는 하나의 단일 해답만 찾는 것이 아니라, 성능-비용 trade-off 상의 여러 운영점을 찾아냅니다.

---

6. 수학 추론: retrieval policy를 “붙이는 것”이 아니라 “찾는 것”

수학 추론 실험은 특히 흥미롭습니다.
저자들은 올림피아드급 문제 풀이에 retrieval을 붙이되, 단순 dense retrieval이나 random few-shot이 아니라 retrieval policy 자체를 code space에서 search하게 만듭니다.

• 검색 코퍼스: 50만 개 이상의 solved problems
• search set: OlympiadBench + Omni-MATH hard 기반 250문제
• 최종 평가: 200개 IMO-level 문제
• 평가 모델: search에 쓰지 않은 5개 held-out 모델 포함

결과 요약

• No Retriever: 34.1
• BM25 Retrieval: 37.5
• Meta-Harness: 38.8

즉, 평균적으로 no retrieval 대비 +4.7 point 향상입니다.

이 결과가 중요한 이유는, 단순히 retrieval을 더해서 좋아졌다는 뜻이 아니기 때문입니다.
논문은 naive dense retrieval이나 random few-shot은 모델에 따라 오히려 역효과가 날 수 있음을 보여 줍니다. 결국 중요한 것은 “retrieval을 쓸까 말까”가 아니라, 문제 유형에 따라 무엇을 어떻게 가져오고 어떻게 넣을까입니다.

 

 

그림 5. 원문 Figure 8 (p.21). 질의를 과목별로 라우팅해 서로 다른 retrieval policy를 적용하는 수학 하네스.

발견된 retrieval harness의 요지

Meta-Harness가 찾은 최종 수학 하네스는 문제를 대략 네 가지 route로 보냅니다.

• 조합론: 더 많은 BM25 후보를 가져온 뒤 dedup + difficulty rerank
• 기하: 구조적으로 맞는 raw BM25 이웃을 선호
• 정수론: 기법이 초반에 분명히 드러나는 해설에 bonus
• 기타/대수: score concentration에 따라 adaptive하게 예시 수 조절

핵심은 retrieval을 하나의 고정된 규칙으로 보지 않고, 문제 유형별 작은 프로그램으로 본다는 점입니다.

---

7. TerminalBench-2: agent harness도 자동으로 좋아질 수 있는가

TerminalBench-2는 긴 호흡의 자율적 CLI 작업을 요구하는 어려운 에이전트 벤치마크입니다. 저자들은 이 환경에서도 Meta-Harness가 의미 있는 개선을 만든다고 보여 줍니다.

결과 요약

• Claude Opus 4.6
  • Terminus-KIRA: 74.7
  • Meta-Harness: 76.4
• Claude Haiku 4.5
  • Goose: 35.5
  • Meta-Harness: 37.6

즉, Opus 4.6에서는 strong hand-engineered baseline을 넘고, Haiku 4.5에서는 reported agent 중 1위를 기록합니다.

더 흥미로운 점: 발견된 개선이 매우 “구조적”이라는 것

 

 

그림 6. 원문 Figure 9 (p.22). TerminalBench-2에서 발견된 핵심 아이디어는 agent loop를 건드리기보다, 시작 전에 환경 스냅샷을 주는 bootstrap입니다.

최종적으로 나온 가장 좋은 아이디어는 복잡한 prompt rewrite가 아니라 environment bootstrap이었습니다.
즉, 에이전트가 첫 턴을 시작하기 전에 현재 sandbox의 상태를 한 번에 요약해서 넣어 줍니다.

• 현재 디렉터리
• /app 내용
• 사용 가능한 언어/컴파일러
• 패키지 매니저
• 메모리 정보

이게 왜 중요할까요?
장기 실행 에이전트는 초반 2~4턴을 “환경을 탐색하느라” 날리는 경우가 많습니다. 이 bootstrap은 그 낭비를 줄여 줍니다. 중요한 것은 이 개선이 hand-written heuristic으로 미리 넣어진 것이 아니라, search 과정에서 안전하고 additive한 수정으로 발견되었다는 점입니다.

---

8. 이 논문에서 꼭 잡아야 할 포인트 5가지

8.1 “모델 최적화”만큼 “하네스 최적화”가 중요하다

이 논문은 같은 base model 위에서도 외부 하네스 설계만으로 큰 차이가 날 수 있음을 보여 줍니다. 앞으로 agent/system 평가에서는 모델 버전만 보는 것이 불충분할 수 있습니다.

8.2 압축된 feedback보다 원시 실행 흔적(raw traces) 이 더 중요하다

점수, 짧은 critique, 요약만으로는 long-horizon failure를 추적하기 어렵습니다. Meta-Harness의 핵심은 실패의 과정 자체를 보게 한다는 데 있습니다.

8.3 더 좋은 search loop보다 더 좋은 인터페이스가 중요할 수 있다

이 논문은 복잡한 search heuristic보다, proposer가 과거 경험을 어떤 형태로 볼 수 있는지가 더 중요하다고 주장합니다.
즉, 똑똑한 에이전트에게 충분히 덜 압축된 경험 저장소를 주는 것이 핵심입니다.

8.4 발견된 전략이 사람이 읽을 수 있는 수준으로 남는다

최종 산출물이 weight update가 아니라 코드이기 때문에, 무엇을 배웠는지 사람이 검토하고 재사용하기 쉽습니다.
이 점은 실무적으로도 매우 큽니다.

8.5 “Prompt engineering”의 다음 단계는 “Harness engineering”

프롬프트 한 줄을 만지는 수준을 넘어, memory/retrieval/tool orchestration 전체를 설계·탐색하는 쪽으로 무게중심이 이동하고 있다는 신호로 읽을 수 있습니다.

---

9. 한계와 주의해서 볼 점

이 논문이 강한 결과를 보여 주는 것은 맞지만, 그대로 일반화할 때는 몇 가지를 함께 봐야 합니다.

1. 강한 proposer에 많이 기대고 있습니다.
   실험에서는 Claude Code + Opus 4.6 같은 강한 coding agent가 쓰였습니다. proposer의 성능이 낮아지면 같은 효과가 재현될지는 별도 검증이 필요합니다.
2. search cost가 0은 아닙니다.
   저자들은 wall-clock 기준 몇 시간이라고 말하지만, 그 안에는 task-specific evaluation 인프라와 충분한 자동화가 전제되어 있습니다.
3. TerminalBench-2는 search와 final evaluation이 같은 benchmark입니다.
   저자들은 이것을 discovery problem으로 정당화하고 leakage audit도 수행했지만, 엄격한 일반화 관점에서는 보수적으로 읽을 필요가 있습니다.
4. 범용 하네스 하나를 찾은 것은 아닙니다.
   Meta-Harness는 “모든 작업에 통하는 단일 정책”보다, 도메인별로 좋은 실행 절차를 자동으로 찾는 프레임워크에 가깝습니다.

---

10. 결론

이 논문은 “더 좋은 모델을 만드는 일”과 별개로, 같은 모델을 더 잘 쓰게 만드는 하네스 자체를 자동으로 최적화할 수 있다는 점을 설득력 있게 보여 줍니다. Meta-Harness의 핵심은 이전 시도의 코드, 점수, 실행 로그를 summary로 압축하지 않고 파일시스템에 그대로 남겨 두고, coding agent가 필요한 부분을 직접 탐색하게 만드는 것입니다. 그 결과 텍스트 분류, 수학 추론, agentic coding 모두에서 hand-engineered baseline을 넘어서는 하네스가 발견되었습니다. 결국 이 논문은 “LLM 성능은 모델 weights만의 문제가 아니다”라는 사실을, 꽤 강한 실험 결과와 함께 보여 주는 작업이라고 볼 수 있습니다.

---

11. 참고 자료

• Lee, Yoonho, et al. Meta-Harness: End-to-End Optimization of Model Harnesses. arXiv:2603.28052v1, 2026.
• Project page: https://yoonholee.com/meta-harness/
• 본 문서의 figure는 원문 PDF에서 핵심 영역만 crop·재배치했습니다.