같은 모델을 쓰는데 어떤 팀의 에이전트는 끝까지 일을 마치고, 어떤 팀의 에이전트는 세 번째 단계에서 같은 실수를 반복합니다. 모델을 바꾸지 않고도 이런 차이가 생긴다면, 남은 변수는 모델 주변의 작업 환경입니다. 프롬프트, 도구 설명, 메모리, 스킬, 서브에이전트, 실행 스크립트 같은 것들입니다.
하네스라는 개념이 처음이라면 하네스 엔지니어링이란?에서 기본부터 볼 수 있습니다.
구글 연구팀이 10월 9일 arXiv에 공개한 Harness²는 이 환경을 "스스로 고치는" 프레임워크입니다. 이름의 제곱 기호는 두 단계의 재귀를 뜻합니다. 하나는 지금 하는 작업의 하네스를 고치는 루프, 다른 하나는 그 경험을 다음 작업의 개선 하네스에 쌓는 루프입니다. 모델 가중치는 건드리지 않습니다.
핵심은 점수보다 방법입니다. 정답 검증기가 없는 열린 세계에서, 하네스 수정안을 어떻게 비교하고 채택할 것인가. 이 글은 논문과 공식 저장소를 기준으로 그 구조를 풀고, 팀에서 바로 따라 해볼 수 있는 축소 실험으로 옮겨 봅니다.
공개된 것과 공개되지 않은 것
공식 저장소는 Apache 2.0 라이선스로 공개됐고, 논문은 arXiv:2610.14224로 올라와 있습니다. 저장소에는 실행 코드, 벤치마크 가이드, 데모가 포함됩니다. 다만 README에 "공식적으로 지원되는 구글 제품이 아니다"라고 명시돼 있습니다. 연구 코드로 읽어야 합니다.
논문이 보고한 실험 범위는 다음과 같습니다.
- 벤치마크 3개: WorkBuddy-Bench(코드·웹·오피스), JobBench(전문 직무), LAB(법률)
- 실행 모델 2개: GLM-5, Gemini 3.5 Flash
- 실행 하네스 2개: OpenCode, Codex
- 하네스 편집자: Claude Opus 4.8 (OpenCode에서 실행)
- 각 설정 3회 반복, 작업 순서를 섞어 평균
중요한 조건이 하나 있습니다. 실행 모델은 고정된 채, 하네스를 고치는 일은 더 강한 모델이 맡습니다. 논문은 이 편집자를 모든 비교군에 동일하게 적용해 조건을 맞췄다고 설명합니다. 그래도 "약한 모델이 스스로를 고쳤다"는 식으로 읽으면 안 됩니다. 약한 실행 모델의 주변을 강한 편집자가 고쳐 주는 구조에 가깝습니다.
두 개의 루프: 지금 고치고, 다음을 위해 남긴다
Harness²의 작업 수준 재귀는 세 단계로 이뤄집니다. Propose(제안), Probe(탐침), Compose(조합)입니다.
[작업 수준 재귀: 한 작업 안에서]
현재 하네스 H0
│
├─ Propose: 불변 편집 + 도메인 편집 후보를 만든다
│
├─ Probe: 후보 하네스로 같은 작업을 다시 실행한다
│
└─ Compose: 실행 결과의 행동 차이를 비교해
최종 하네스 H1을 조립한다
정답 라벨 없음. 점수 대신 "같은 작업에서 무엇이 달라졌는가"를 본다.
여기서 눈에 띄는 부분은 정답 검증기가 없다는 점입니다. 대신 같은 작업을 여러 하네스로 실행하고, 결과물과 실행 궤적의 차이를 비교합니다. 예를 들어 어떤 편집은 도구 호출 횟수를 줄였고, 어떤 편집은 파일 구조를 더 일관되게 만들었는지를 봅니다. 점수가 아니라 행동의 대비입니다. 논문은 이를 대조적(contrastive) 갱신이라고 부릅니다.
두 번째 루프는 이 경험을 다음 작업으로 넘깁니다. 작업이 끝나면 채택된 하네스와 "왜 그 편집이 통했는지"에 대한 근거를 개선 하네스에 축적합니다. 다음 작업에서는 이 라이브러리에서 재사용할 만한 구성 요소와 교훈을 꺼냅니다. 이전 실행 하네스를 통째로 물려주는 것이 아니라, 재사용 가능한 부분과 조건을 선택적으로 남기는 방식입니다.
이 구조가 흥미로운 이유는 자기개선의 단위를 "모델"이 아니라 "작업 환경"으로 옮겼기 때문입니다. 모델을 재학습하는 것보다 훨씬 싸고, 되돌리기도 쉽습니다. 대신 잘못된 교훈이 라이브러리에 쌓이면 다음 작업까지 오염시킬 수 있습니다. 그래서 논문도 라이브러리의 기여도를 따로 ablation으로 확인합니다.
숫자를 읽는 법
논문의 대표 수치는 "한 번의 개선 단계로 최대 +11.5점"입니다. 여기서 +11.5는 WorkBuddy-Bench 평균 점수에서 GLM-5/OpenCode 조합이 64.2에서 75.7로 오른 차이입니다. 같은 벤치마크에서 Gemini 3.5 Flash/OpenCode는 72.4에서 77.5로 +5.1에 그쳤습니다. 실행 모델이 약할수록 하네스 개선의 절대 이득이 컸다는 뜻입니다.
| 벤치마크 | 평가 대상 | 지표 | 한 단계 최대 개선 | 예시 |
|---|---|---|---|---|
| WorkBuddy-Bench | 코드 40·웹 35·오피스 25개 테스트 과제 | 복합 검증 통과 비율 | +11.5점 | GLM-5/OpenCode 64.2 → 75.7 |
| JobBench | 34개 전문 직무 과제 | 가중 루브릭 점수 | +4.5점 | Gemini 3.5 Flash/OpenCode 31.5 → 36.0 |
| LAB | 1,251개 중 100개 테스트 과제 | 기준별 통과율(Partial) | +11.8%p | GLM-5/OpenCode 59.6 → 71.4 |
재귀 예산을 k=1에서 k=5로 늘리면 추가 이득이 붙습니다. 논문은 WorkBuddy +3.9점, JobBench +4.2점, LAB +6.7%p를 보고합니다. 다만 이 수치는 앞의 한 단계 결과에 더해지는 값이고, 실행 비용도 함께 늘어납니다. Gemini 3.5 Flash/OpenCode 기준으로 k를 1에서 5로 올리면 JobBench 개선은 +4.5에서 +7.5로, WorkBuddy는 +5.1에서 +8.4로 커집니다. 공짜 향상이 아니라 계산량을 더 쓴 결과입니다.
어떤 구성 요소가 기여했는지도 분리돼 있습니다. 라이브러리를 빼면 WorkBuddy −3.1점, JobBench −1.8점. 편집자 역할을 범위별로 나누는 scoping을 빼면 −2.9점, −3.7점. 여러 후보를 조합하는 composition을 빼면 −1.6점, −1.9점입니다. 세 장치가 각각 일정 부분을 담당합니다.
하네스의 비용 구조: 항상 켜지는 것과 필요할 때 부르는 것
Harness²는 모델 주변을 여덟 개 구성 요소로 나눕니다. 이 구분은 프레임워크를 쓰지 않더라도 유용합니다. 어떤 구성 요소가 매 호출마다 컨텍스트를 차지하는지, 어떤 것이 필요할 때만 로드되는지가 비용과 성능을 가르기 때문입니다.
| 구성 요소 | 언제 컨텍스트에 들어가나 | 비용·역할 |
|---|---|---|
| 시스템 프롬프트 | 항상 | 매 토큰이 출력 예산과 경쟁 |
| 가드레일 | 항상 | 상시 규칙, 컨텍스트 비용 발생 |
| 장기 메모리 | 항상 | 도메인 사실, 컨텍스트 비용 발생 |
| 도구 설명·가이드 | 항상 | 도구 사용법, 컨텍스트 비용 발생 |
| 스킬 | 호출될 때만 | 필요 없는 작업에서는 비용 0에 가깝다 |
| 스크립트 | bash로 실행 | 토큰으로 추론하는 대신 결정적으로 실행 |
| 서브에이전트 | 작업을 위임할 때 | 별도 컨텍스트를 추가하는 유일한 구성 요소 |
| 플러그인 | 도구 루프 중간 | 미들웨어로 동작을 가로챈다 |
여기서 실무적인 교훈이 나옵니다. 많은 팀이 성능을 올리려고 시스템 프롬프트를 길게 만듭니다. 하지만 시스템 프롬프트는 항상 켜져 있어서, 길어질수록 모든 호출의 비용과 지연을 끌어올립니다. 반대로 스킬과 스크립트는 필요할 때만 쓰입니다. 반복되는 절차를 프롬프트에 길게 설명하는 대신 스킬로 빼고, 계산 가능한 일은 스크립트로 옮기는 편이 토큰 경제에 유리합니다. 서브에이전트는 강력하지만 새로운 컨텍스트를 하나 더 만든다는 점을 기억해야 합니다.
논문의 ablation도 이 구조와 맞닿아 있습니다. 라이브러리, scoping, composition이 각각 점수에 기여했다는 것은, 하네스를 "프롬프트 한 장"이 아니라 여러 구성 요소의 조합으로 다뤄야 한다는 신호입니다.
직접 해보는 최소 실험: 하루짜리 하네스 감사
공식 프레임워크를 바로 돌리려면 Vertex AI 인증, Docker, 벤치마크 의존성이 필요합니다. 팀에서 먼저 해볼 수 있는 것은 더 작습니다. 아래는 논문의 방식을 수작업으로 축소한 절차이며, 공식 도구를 실행한 결과가 아닙니다.
- 최근 에이전트 실행 로그에서 반복되는 실패 유형 세 개를 고릅니다. 예: 테스트 명령을 잘못 고름, 파일을 두 번 읽음, 완료 전에 요약함.
- 실패를 확인할 수 있는 작은 과제 하나를 정합니다. 결과물이 파일이나 테스트로 검증되어야 합니다.
- 현재 하네스로 같은 과제를 세 번 실행합니다. 점수, 모델 턴 수, 대략적인 토큰 비용을 적습니다.
- 한 번에 구성 요소 하나만 바꿉니다. 시스템 프롬프트를 늘리는 대신, 반복 절차를 스킬로 빼거나, 검증 명령을 스크립트로 고정하는 식입니다.
- 같은 과제를 다시 세 번 실행합니다. 점수만 보지 말고 실행 궤적의 차이를 봅니다. 어떤 단계가 줄었고, 어떤 오류가 사라졌는지.
- 다음 과제에 적용할 교훈을 한 줄로 남깁니다. "이 편집은 어떤 조건에서 통했는가"까지 적습니다.
실험 노트는 다음 형태로 충분합니다.
| 수정 | 기대한 변화 | 관찰한 변화 | 채택 여부 |
|---|---|---|---|
| 테스트 명령을 스크립트로 고정 | 잘못된 명령 선택 감소 | 턴 수 12 → 9, 테스트 실패 2 → 0 | 채택 |
| 완료 조건을 시스템 프롬프트에 추가 | 조기 종료 감소 | 변화 없음, 프롬프트 토큰만 증가 | 보류 |
| 파일 읽기 규칙을 스킬로 분리 | 중복 읽기 감소 | 중복 호출 3 → 1 | 채택 |
이렇게 하면 "모델을 바꿀까"를 논의하기 전에 "하네스에서 무엇을 고칠 수 있는가"를 먼저 확인하게 됩니다. 논문의 라이브러리 개념도 결국 이런 교훈의 축적입니다.
공식 데모를 실행해 보려면 README의 명령을 그대로 따르면 됩니다. 아래는 공식 문서에서 인용한 것이고, 이 글에서는 실행하지 않았습니다.
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2
이 데모는 결정적 편집자와 실제 Python 실행을 사용하며 모델 자격 증명이 필요 없다고 README는 설명합니다. 모델 기반 벤치마크를 돌리려면 Node.js 20+, Google Cloud CLI, Vertex AI 설정이 필요하고, WorkBuddy-Bench는 Docker, LAB는 Pandoc과 Poppler가 필요합니다. 비용이 발생하므로 작은 과제부터 시작하라고 안내합니다.
한계와 주의점
첫째, 독립 재현이 아닙니다. 이 글에서 확인한 수치는 모두 논문과 저장소의 저자 보고입니다. 이 글을 쓰는 시점에 제3자 재현 결과는 확인하지 못했습니다.
둘째, 편집자 모델의 영향입니다. 하네스를 고치는 일은 Claude Opus 4.8이 맡습니다. 실행 모델보다 강한 모델이 편집자로 들어가기 때문에, "하네스만 바꿔서" 얻은 이득이라고 단정하기는 어렵습니다. 논문은 비교군에도 같은 편집자를 썼다고 밝히지만, 절대 점수를 다른 시스템에 그대로 옮길 수는 없습니다.
셋째, 벤치마크 오염 위험입니다. README는 실행기의 네트워크 접근이 제한되지 않고 Codex가 샌드박스 없이 실행된다고 명시합니다. 공개 벤치마크의 루브릭이 온라인에 있을 수 있으므로, 평가 전에 네트워크 제한을 설정해야 합니다. 이 경고를 읽지 않고 돌리면 점수가 실제 실력이 아닐 수 있습니다.
넷째, 비용과 일반화입니다. 논문도 재귀적 개선에 추가 실행과 편집자 세션이 필요하다고 인정합니다. 재귀 예산의 최적값은 실험 범위 안에서만 확인됐고, 모든 작업에 통하는 값은 아닙니다. 실행 기반 피드백에 의존하기 때문에, 행동 차이를 관찰할 수 없는 작업에는 약합니다.
다섯째, 제품이 아닙니다. 저장소는 연구 공개물이고, 공식 지원 제품이 아니라고 스스로 밝힙니다. 프로덕션 의존성을 걸기 전에 코드와 라이선스, 유지보수 상태를 확인해야 합니다.
결론: 모델을 바꾸기 전에 하네스를 감사하라
Harness²의 진짜 메시지는 "에이전트가 스스로를 고친다"가 아닙니다. 하네스를 고치는 일을 측정 가능한 루프로 만들 수 있다는 것입니다. 같은 작업을 여러 하네스로 실행하고, 행동 차이를 비교하고, 통한 교훈을 다음 작업에 남기는 절차. 이 절차는 거대한 프레임워크 없이도 시작할 수 있습니다. 모델과 하네스의 역할 차이는 모델 vs 하네스에서, 성과당 비용으로 보는 관점은 AI 에이전트 KPI에서 더 다룹니다.
다만 자기개선이라는 말에는 조건이 붙습니다. 목표, 예산, 제약, 채택 기준은 여전히 사람이 정합니다. 시스템이 제안하고, 실행으로 비교하고, 사람이 책임지는 구조입니다. 이 경계를 흐리면 "자동으로 좋아졌다"는 착각만 남습니다.
모델 교체를 검토하고 있다면, 먼저 최근 실패 세 개를 골라 하네스에서 한 번씩만 고쳐 보십시오. 그 실험이 새 모델 비용보다 싼 경우가 많습니다.
참고 자료
- Harness²: Recursive Agent Harnessing for an Open World (arXiv:2610.14224, Oct 9, 2026)
- google-research/harness2 (GitHub, Apache 2.0)
- Harness² 논문 HTML
- Harness² 공식 사이트
이 주제를 직접 따라가며 배우고 싶다면
하네스를 구성 요소로 나누고, 실행과 검증이 반복되는 루프를 직접 설계해 보면 이 논문의 선택이 왜 그렇게 생겼는지 보입니다. 프롬프트 한 장을 늘리는 대신 스킬·스크립트·서브에이전트를 언제 쓸지 판단하는 감각이 핵심입니다.