같은 모델인데 어떤 에이전트는 결과 파일을 만들고 끝내고, 어떤 에이전트는 그 파일을 다시 열어 확인합니다. 차이는 프롬프트 한 줄뿐 아니라 도구 설명, 검증 스크립트, 메모리와 작업 절차에서 생길 수 있습니다. 모델 주변의 이 실행 환경을 하네스(harness)라고 부릅니다.
Harness²는 이 하네스를 현재 작업에 맞게 고치고, 그 개선 과정에서 얻은 근거를 다음 작업의 개선에 사용하는 프레임워크입니다. 모델 가중치는 고정합니다. 이 글은 도구 응답 크기를 설계한 앞선 글에서 한 걸음 더 나아가, 실행 환경을 무엇을 근거로 바꾸고 어떤 경험을 남길지 살펴봅니다.
자료 확인 기준은 2026년 10월 19일, Asia/Seoul입니다. 아래의 프로젝트 설명은 공식 자료에서 확인한 사실이며, 마지막 개발 업무 예시는 별도의 적용 제안입니다. 외부 저장소는 내려받아 읽었고, Harness² 설치·데모·모델 호출·벤치마크는 실행하지 않았습니다.
정확히 어떤 프로젝트인가
공식 저장소는 Google Research GitHub 조직의 google-research/harness2입니다. 이름은 Harness², 저장소와 Python 패키지 이름은 harness2입니다. 논문의 정식 제목은 Harness²: Recursive Agent Harnessing for an Open World이고, 저자 소속에는 Google Cloud AI Research와 Northwestern University가 기재되어 있습니다. 따라서 Google의 프로젝트라는 설명은 근거가 있습니다. Google DeepMind의 상용 서비스로 소개할 근거는 없습니다.
코드는 Apache-2.0 라이선스로 공개되어 있고, 패키지 메타데이터는 작성자를 Google LLC, 버전을 0.1.0으로 표시합니다. 다만 README에는 Google이 공식 지원하는 제품이 아니다라는 고지가 있습니다. 공개 연구 코드와 운영 지원 약속을 구분해야 합니다.
라이선스도 저장소 전체를 하나로 보면 안 됩니다. 제삼자 고지에 따르면 벤치마크·데이터와 파생 러너는 각 원본의 조건을 유지합니다. 특히 WorkBuddy-Bench에는 별도 Tencent 라이선스와 지역 제한이 있습니다. Harness²의 Apache-2.0만 보고 모든 데이터와 도구의 사용 조건까지 같다고 판단할 수 없습니다.
현재 작업과 다음 개선을 연결하는 구조
하네스를 미리 최적화해 고정하면 설계 때 보지 못한 작업에서 절차가 맞지 않을 수 있습니다. 반대로 새 작업마다 지침을 무작정 다시 쓰면 같은 실수를 반복하거나, 한 작업에만 유효한 규칙이 다음 작업으로 퍼질 수 있습니다. Harness²는 실행용 하네스와 개선을 이끄는 하네스를 구분합니다.
아래는 논문 2절을 읽고 재구성한 자체 도식입니다. 모델 학습이나 제품 배포 흐름을 나타내는 그림은 아닙니다.
현재 작업 + 공통 기본 하네스
│
├─ 기준 실행: 궤적과 산출물 관찰
│
└─ Propose: 일반 절차 후보 + 도메인 후보
→ Probe: 같은 작업에서 후보별 실행 비교
→ Compose: 근거가 있는 변경을 조합·수정·유지
→ 조합된 하네스로 실행 → 산출물 채택
│
Reflect: 적용 조건·교훈·근거 추출
↓
개선 라이브러리: 하네스 파일 + EXPERIENCE.md
│
다음 작업의 Propose·Compose에 참조작업 안에서는 Propose–Probe–Compose
Propose는 계획·도구 사용처럼 여러 영역에 반복되는 문제와, 현재 도메인의 절차·제약을 각각 겨냥한 후보를 만듭니다. Probe는 같은 모델·환경 조건에서 후보 하네스로 같은 작업을 실행합니다. Compose는 기준 실행, 후보의 변경 내용, 궤적과 산출물을 비교해 변경을 합치거나 고칩니다. 기존 하네스를 유지하는 선택도 가능합니다.
여기서 관찰한 행동 차이는 정답 판정이 아닙니다. 실행의 무작위성과 같은 모델의 공통 편향이 남습니다. “검증 스크립트를 실행했다”와 “정확한 산출물을 냈다”는 별도로 확인해야 합니다.
parallel 모드는 k개의 일반 후보와 k개의 도메인 후보를 탐색하고, 공유 증거로 k개의 조합을 만듭니다. sequential은 이전 하네스와 누적 증거를 다음 개선 단계에 넘기며 k번 깊게 수정합니다. k는 단순한 재시도 횟수와 다릅니다. 자세한 실행 방식은 공식 실험 가이드에 나와 있습니다.
작업 사이에는 개선 경험을 남기기
채택 후에는 하네스 파일과 적용 조건·교훈·관찰 근거를 라이브러리에 남깁니다. 다음 작업은 공통 기본 실행 하네스에서 다시 출발하고, 개선 과정이 이전 경험을 선택적으로 참조합니다. 직전 작업의 맞춤 지침을 무조건 물려주는 구조가 아닙니다.
이를 구현한 core/library.py는 도메인별 INDEX.md, 채택한 전체 하네스 트리, EXPERIENCE.md를 관리합니다. 경험의 cue, lesson, evidence가 비어 있으면 새 항목을 저장하지 않습니다. 이는 저장 형식에 대한 검사이며, 근거의 진실성을 자동으로 증명하는 장치는 아닙니다.
코드에서 따라갈 경계
아래 경로는 확인한 커밋 1cfe254e8d25b15f37048c3730134686abe60335 기준입니다. 외부 저장소의 지침을 실행 지시로 받아들이지 않고, 프레임워크 구현을 자료로 읽었습니다.
| 경로 | 읽어볼 역할 |
|---|---|
harness2/cli/run_sweep.py |
harness2 진입점, 작업 선택과 실행 전 준비 검사 |
harness2/core/schedule.py |
작업 순서, 재개, 라이브러리 복구와 실행 조율 |
harness2/core/recursion.py |
병렬·순차 개선의 후보 생성, 실행과 조합 |
harness2/core/selection.py |
기존 산출물 선택, 채택 이후 경험 추출 |
harness2/core/library.py |
도메인별 하네스와 경험 저장·검색용 인덱스 |
harness2/core/spec.py |
벤치마크 어댑터와 실행 기반의 계약 |
harness2/substrate/ |
OpenCode·Codex별 파일 배치와 실행 방식 |
harness2/benchmarks/ |
JobBench·LAB·WorkBuddy별 작업·산출물·채점 연결 |
core/spec.py의 BenchmarkAdapter에는 작업 읽기, 실행, 궤적·산출물 추출, 하네스 검증과 score() 경계가 있습니다. RunView에는 실행 상태·비용·시간이 있지만 정답 점수는 없습니다. 채점은 채택 후 별도 경로가 담당합니다. 개선 중의 행동 증거와 사후 평가를 분리하려는 구조를 코드에서도 볼 수 있습니다.
수정 가능한 요소는 시스템 프롬프트, 가드레일, 메모리, 도구 안내, 서브에이전트, 스킬, 스크립트, 플러그인의 여덟 가지입니다. 다만 실제 파일 배치는 실행기마다 다릅니다. OpenCode 구현은 systemprompt.md, guardrails.md, LongTermMEMORY.md, tool_descriptions/tool_guidance.md를 항상 읽는 요소로 정의합니다. 스킬과 스크립트는 별도 디렉터리를 사용합니다.
Codex 구현은 AGENTS.md, .agents/skills, 역할 파일과 .codex/hooks.json으로 연결합니다. 여덟 개의 추상적 역할이 모든 실행기에서 똑같은 파일 여덟 개가 된다는 뜻은 아닙니다. guardrails.md라는 이름의 지침 역시 운영체제의 실행 권한 제한과 같은 것은 아닙니다.
새 업무를 연결하려면 작업의 입력·산출물·관찰·평가를 어댑터로 정의해야 합니다. 현재 공개 CLI에서 Python·React·Rust·Tauri 프로젝트를 경로 하나로 지정하면 바로 최적화된다고 설명할 근거는 없습니다.
공식 사용 흐름: 로컬 데모와 모델 실험 구분하기
설치 가이드는 Linux와 Python 3.12를 안내하고, 패키지는 Python 3.13도 허용합니다. uv를 사용하며, 모델 기반 벤치마크에는 Node.js 20 이상과 Google Cloud CLI, 벤치마크별 추가 도구가 필요합니다.
다음은 저장소를 검토한 뒤 그 루트에서 사용하는 공식 명령 안내, 이 글에서는 실행 미검증입니다.
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2공식 데모는 결정적인 편집기와 실제 Python 실행을 사용하고 모델 인증은 요구하지 않습니다. 데모 진입점에서도 두 모드 실행과 결과 보고서 기록을 확인할 수 있습니다. 모델이 스스로 개선했다는 성능 실험과는 구분해야 합니다.
모델 기반 실험은 .env.example을 참고해 Vertex AI 프로젝트, 실행·개선·판정 모델을 설정하고 인증하는 과정이 추가됩니다. LAB에는 Pandoc·Poppler, WorkBuddy에는 Docker가 필요합니다. 아래는 LAB의 특정 도메인 한 작업으로 범위를 줄인 공식 안내 예시, 실행 미검증입니다. API 비용이 발생할 수 있고, 실행기의 격리·네트워크 조건을 먼저 준비해야 합니다.
cp .env.example .env
# .env에서 프로젝트와 모델 설정을 검토한 뒤 인증합니다.
gcloud auth application-default login
harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel \
--only-domains antitrust-competition --max-tasks 1
harness2-judge --bench lab --k 1 --mode parallel
harness2-report --bench lab --k 1 --mode parallel--max-tasks는 전체 합계가 아니라 도메인별 상한입니다. 실행·채점·보고서의 벤치마크, 실행기, 부분집합, k, 모드와 시드를 맞춰야 합니다. harness2-check가 통과해도 모델 접근 가능성까지 시험한 것은 아닙니다. 결과는 runs/ 아래에 저장되며, 모델이나 작업 선택을 바꾸면 새 HARNESS2_RUNS_DIR을 사용하라는 것이 공식 안내입니다.
성능 수치는 어느 조건의 결과인가
논문 표 1·2는 GLM-5와 Gemini 3.5 Flash를 각각 OpenCode·Codex에서 실행한 네 구성을 비교합니다. 주 실험의 개선 모델은 OpenCode 위의 Claude Opus 4.8입니다. 아래는 k=1의 저자 보고 결과 일부이며 직접 재현한 수치가 아닙니다. 괄호는 세 번 실행의 표준편차입니다.
| 평가·구성 | 기본 하네스 → Harness² | 절대 변화 |
|---|---|---|
| WorkBuddy 평균, GLM-5·OpenCode | 64.2 (1.4) → 75.7 (2.2) | +11.5점 |
| JobBench, Gemini 3.5 Flash·OpenCode | 31.5 (1.1) → 36.0 (2.3) | +4.5점 |
| LAB Partial, GLM-5·OpenCode | 59.6 (2.7) → 71.4 (2.9) | +11.8%p |
| JobBench, GLM-5·Codex | 23.6 (2.3) → 24.8 (0.2) | +1.2점 |
WorkBuddy 평균은 Code·Web·Office의 매크로 평균이고, LAB Partial은 개별 기준의 통과율입니다. LAB의 +11.8%p를 모든 법률 업무가 완전히 해결된 비율이나 상대 향상률로 읽으면 안 됩니다. 구성에 따라 개선 폭이 다르며, 세 번의 평균 상승만으로 모든 차이가 통계적으로 유의하다고 주장할 수도 없습니다.
저자들은 k=5 병렬 재귀에서 추가 향상을 보고하지만 연산은 늘어납니다. core/ledger.py의 한 모드 예산은 기준·후보·조합 실행을 합쳐 4k회, 개선 단계는 3k개입니다. 선택·회고와 재시도 호출은 이 계산 밖에 있습니다. k=1도 모델 호출 한 번이 아니며, 최종 산출물 실행 단계 수가 줄었다고 전체 비용과 지연이 줄었다고 결론 낼 수 없습니다.
가장 주의할 점은 실험 가이드의 Web access 절입니다. 공개 배포본은 실행기의 네트워크를 제한하지 않으며 Codex 샌드박스를 비활성화합니다. 저자들은 배포본 검증 중 Codex가 JobBench의 공개 채점 기준을 내려받은 사례를 기록하고, 평가 시 네트워크 제한을 요구합니다. 이 사실만으로 논문의 모든 수치가 오염됐다고 단정할 수는 없지만, 기본 설정을 그대로 실행한 결과를 독립 재현으로 받아들일 수도 없습니다.
재현할 때는 모델·개선기·판정기 버전, 작업 순서와 데이터 리비전, 전체 호출 비용·시간, 미채점 건수, 네트워크 정책을 함께 남겨야 합니다. 논문 부록 F·G도 실행 변동·공통 편향·비용을 한계로 밝히고, 커지는 경험 라이브러리의 정리와 오래된 경험 갱신을 향후 과제로 둡니다.
Python·React·Rust CLI·Tauri에 가져올 아이디어
이 절은 필자의 가상 적용 제안입니다. 해당 기술 스택의 공식 통합이나 측정된 성과를 뜻하지 않습니다. 시작점은 에이전트가 실제로 반복하는 실수 하나와, 그 실수를 확인할 수 있는 작은 공개·합성 작업 묶음입니다.
| 개발 업무 | 비교해 볼 하네스 변경 | 따로 확인할 결과 |
|---|---|---|
| Python CSV 처리 | 입력 형식·누락값을 확인하는 스킬과 출력 재검증 스크립트 | 합성 정답과 값·타입·행 수 비교, 새 입력에서의 회귀 |
| React 폼 수정 | 요구 상태를 나열하는 절차와 키보드·오류 상태 확인 스킬 | 제출·검증 오류·포커스 동작, 브라우저 화면 |
| Rust CLI 수정 | 종료 코드와 stdout·stderr 계약을 먼저 기록하는 지침 | 정상·실패 입력, 스트림 분리, 결정적인 결과 |
| Tauri 파일 작업 | 프런트 호출과 Rust 명령 경계를 확인하는 스킬 | 경로 검증·취소·권한 거부 동작, 플랫폼 차이 |
예를 들어 Rust CLI가 실패 메시지를 stdout에 섞어 내보낸다면 “주의하라”는 문장만 추가하기보다, 일반 후보에는 결과 계약 확인 절차를, 도메인 후보에는 CLI 스트림 규칙과 검증 방법을 넣어 비교할 수 있습니다. 같은 합성 작업에서 변경 전후 산출물을 검사하고, 관찰한 근거가 있는 규칙만 다음 개선에 참고하도록 남기는 방식입니다.
React·Tauri 화면에는 후보별 변경 diff, 실행 증거, 채택 이유를 보여줄 수 있습니다. Python 조율기는 모델·작업·하네스 버전을 묶어 기록하고, Rust 실행기는 허용 명령·작업 디렉터리·시간 제한을 강제하도록 설계할 수 있습니다. 이런 권한 경계는 개선 대상 프롬프트 바깥에 두어야 합니다. 이 UI와 실행기를 구현하거나 통합 테스트한 것은 아닙니다.
적용 순서는 다음처럼 작게 잡을 수 있습니다.
- 같은 모델·도구·작업으로 기본 실행을 기록합니다. 네트워크와 파일 권한은 실험 환경에서 제한합니다.
- 절차 후보와 도메인 후보를 분리해 비교합니다. 도구 권한이나 성공 판정 기준까지 후보가 바꾸게 두지 않습니다.
- 검증 가능한 행동 차이와 최종 결과를 따로 봅니다. 실패한 검사를 “미채점”이나 “통과”로 바꾸지 않습니다.
- 채택한 파일, 적용 조건, 근거와 실패 조건을 남깁니다. 다른 작업에서 검증하기 전에는 일반 규칙으로 승격하지 않습니다.
- 별도 회귀 작업에서 정확도·전체 비용·지연·권한 위반을 비교합니다. 변경이 나쁘면 이전 하네스로 되돌립니다.
출처와 확인 범위
- 공식 GitHub README — 소개·비지원 고지·사용 흐름. 확인 커밋은
1cfe254e8d25b15f37048c3730134686abe60335, 커밋 시각은 2026-10-14 UTC이며 README의 별도 발행·개정일은 미표기입니다. 확인 2026-10-19. - Xu 외, Harness² 논문 v1, HTML 본문 — 최초 제출 2026-10-09, 확인 당시 v1이며 별도 개정판은 표시되지 않았습니다. 2절·3절·부록 F·G를 참조했습니다. 확인 2026-10-19.
- 공식 pyproject.toml, LICENSE, 제삼자 고지 — 패키지·라이선스 확인. 각 파일의 별도 발행·개정일 미표기, 위 커밋 기준, 확인 2026-10-19.
- 공식 설치, 실험, 벤치마크 가이드 — 요건·예산·재개·채점과 네트워크 제한. 별도 발행·개정일 미표기, 위 커밋 기준, 확인 2026-10-19.
- 공식 구현 트리 — 본문에서 링크한
core·substrate·cli파일을 읽었습니다. 별도 발행·개정일 미표기, 위 커밋 기준, 확인 2026-10-19.
공식 README의 영상 링크 존재는 확인했지만 영상·음성·자막을 재생하거나 검증하지 않았으므로 구간 발언을 인용하지 않았습니다. 프로젝트 소개 사이트는 조회 도구에서 오류가 나 본문의 근거로 사용하지 않았습니다. 논문 HTML은 웹 조회 도구로 읽었으며, 셸에서의 원문 다운로드는 403으로 실패했습니다.
이 글의 사실 확인은 공개 문서·논문·소스 읽기 범위입니다. 설치 명령과 로컬 데모, 벤치마크 재현, 클라우드 인증·비용, Python·React·Rust·Tauri 통합은 미검증입니다. 블로그의 렌더링 검사는 외부 프레임워크의 실행 검증과 구분합니다.