구글의 '하네스 공식 논문'을 찾아봤다 — 카드에 적힌 그 논문은 없었고, 진짜는 더 재미있었다

이 카드를 받았다. 첫 줄이 이렇게 시작한다 — “구글에서 하네스 공식 논문을 공개됐습니다. 이 글 꼭 저장하세요.”
내용 자체는 나쁘지 않다. 오히려 좋다. 여섯 항목 다 실무에서 맞는 말이고, 마지막의 ‘래칫’ 결론은 특히 맞다. 문제는 출처다. 나는 이런 카드를 볼 때마다 원문을 찾아 읽는 습관이 있는데, 이번엔 찾는 데 한참 걸렸다. 찾지 못해서가 아니라, 찾고 보니 카드가 말하는 그 논문이 아니었기 때문이다.
결론부터 적는다.
- 구글은 하네스 논문을 냈다. 다만 이 카드의 내용이 아니다.
- 카드의 6가지 중 ①②의 용어는 구글이 아니라 ThoughtWorks 사람이 쓴 글에서 왔다.
- ①의 주장은 OpenAI 의 1차 보고와 정면으로 어긋난다. OpenAI 는 그 방식이 실패했다고 적었다.
- 그런데 마지막의 ‘래칫’은 맞다. 그것도 아주.
1. 구글이 실제로 낸 하네스 논문
있다. AutoHarness: improving LLM agents by automatically synthesizing a code harness (arXiv:2603.03329, 2026-02-10). 저자에 Kevin P. Murphy, Miguel Lázaro-Gredilla, Antoine Dedieu, Wolfgang Lehrach 등 구글 딥마인드 쪽 이름이 들어 있다. Murphy 는 『Probabilistic Machine Learning』 저자로 더 유명한 그 사람이다.
그런데 이 논문은 “하네스를 구성하는 6가지” 같은 분류학을 제시하지 않는다. 훨씬 좁고, 훨씬 날카로운 주장을 한다.
논문 초록에 이런 숫자가 나온다. Kaggle GameArena 체스 대회에서 Gemini-2.5-Flash 가 진 판의 78% 는 전략 실책이 아니라 ‘반칙 수’(illegal moves) 때문이었다. 룰을 몰라서가 아니다. 룰을 설명하라고 하면 잘 설명한다. 그런데 두질 못한다.
논문의 처방은 카드에 적힌 것과 방향이 다르다. 사람이 하네스를 손으로 짜는 대신 LLM 이 자기 하네스를 코드로 직접 합성하게 한다. 환경에서 오는 피드백을 받아 코드를 몇 번 다듬는 방식이고, 탐색은 Thompson sampling 기반 트리 탐색으로 돌린다. 결과가 이렇다.
- TextArena 게임 145종에서 반칙 수가 전부 사라졌다
- 그 상태의 Gemini-2.5-Flash 가 더 큰 Gemini-2.5-Pro 를 이겼다
- 극단까지 밀면 정책 전체를 코드로 뽑아, 실행 시점에 LLM 호출이 아예 없어진다
이게 “모델보다 하네스”라는 말의 측정된 버전이다. 카드처럼 “하네스가 중요합니다”라고 주장하는 게 아니라, 같은 모델을 하네스만 바꿔 붙여서 더 큰 모델을 이겼다는 수치를 낸다. 나는 이쪽이 훨씬 인용할 만하다고 본다.
한 가지 정직하게 덧붙이면, 이 논문의 실험은 게임 환경이다. “합법 수인가”처럼 판정이 기계적으로 명확한 곳이라 하네스 합성이 잘 먹힌다. 정답 판정이 애매한 업무 코드에 그대로 옮겨진다는 근거는 이 논문에 없다.
2. 그럼 카드의 6가지는 어디서 왔나
구글 쪽에도 하네스 문서가 하나 더 있다. Google Cloud 의 What is an agent harness? (2026-08-20 갱신). 읽어 보면 논문이 아니라 제품 설명 페이지다. MCP, 상태·메모리 관리, 가드레일, Cloud Run·Gemini Enterprise 로 이어지는 구성이고, 카드의 6항목 분류도, ‘래칫’도 여기 없다.
카드의 ①②를 보면 출처가 오히려 선명하다. “가이드(Guides)”와 “센서(Sensors)” 라는 이 짝은 ThoughtWorks 의 Birgitta Böckeler 가 쓴 Harness engineering for coding agent users 의 용어다. 거기서 가이드는 피드포워드 통제(행동 전에 미리 방향을 잡는 것), 센서는 피드백 통제(행동 후 관측해 스스로 고치게 하는 것)로 정의된다. 카드의 “사람이 보기 전에 에이전트가 자기 결과물을 먼저 통과시킵니다”도 이 글의 자기교정 개념 그대로다.
Böckeler 의 글에는 카드에 안 실린 구분이 하나 더 있는데, 이게 실무에서 더 쓸모 있다. 가이드와 센서를 각각 계산적(computational) — 린터·타입체커·테스트처럼 결정적이고 빠른 것 — 과 추론적(inferential) — AI 코드리뷰, LLM-as-judge 처럼 느리고 비결정적인 것 — 으로 가른다. “센서를 붙여라”보다 “이 센서가 결정적인가 아닌가”가 훨씬 실천적인 질문이다.
④⑥(외부 기억, 관측)과 AGENTS.md 실무는 OpenAI 쪽 1차 보고와 겹친다. Harness engineering: leveraging Codex in an agent-first world (2026-02-11, Ryan Lopopolo). 사람이 코드를 한 줄도 손으로 쓰지 않고 약 100만 줄 규모 제품을 만든 기록이고, 5개월간 PR 약 1,500건, 엔지니어 1인당 하루 3.5 PR 이라는 자체 수치를 낸다. 로그·메트릭·트레이스를 에이전트가 직접 LogQL/PromQL 로 질의하게 만들었다는 대목이 카드 ⑥의 실물이다.
3. 카드가 자기 출처와 어긋나는 한 곳
여기가 이 글을 쓴 이유다.
카드 ①은 이렇게 적었다 — “가이드 AGENTS.md, 룰 파일, 제약 문서. 한 줄 한 줄이 과거의 실패를 영구적인 수정으로 바꾼 기록입니다.”
좋은 문장이다. 그런데 이 실무를 가장 크게 굴려 본 OpenAI 의 보고는 정반대를 말한다. 그들은 “하나의 큰 AGENTS.md” 방식을 시도했고, 실패했다고 적었다. 이유를 네 가지로 든다 — 컨텍스트는 희소 자원이라 거대한 지시 파일이 정작 과제와 코드를 밀어낸다, 전부가 중요하면 아무것도 중요하지 않다, 즉시 썩는다, 기계적으로 검증하기 어렵다. 그래서 그들이 택한 표현이 “매뉴얼 1,000쪽이 아니라 지도를 줘라” 였다.
즉 “한 줄 한 줄 쌓아 올린 기록”은 카드가 그리는 이상향이지만, 1차 보고에서는 그게 실패 모드의 이름이다. 규칙은 쌓는 게 아니라 덜어내고 검증 가능하게 쪼개는 것이다.
나 자신도 이 함정에 걸려 있다. 내 전역 규칙 파일은 지금 계속 길어지는 중이고, “기계적으로 검증 가능한가”라는 기준으로 다시 볼 때가 됐다.
4. 그런데 ‘래칫’은 맞다 — 오늘 내가 한 번 돌렸다
카드의 마지막 결론은 이렇다.
실패 → 누락된 통제 발견 → 하네스 개선 → 검증 → 더 높아진 기준선
이건 옳다. Böckeler 의 ‘스티어링 루프’와 같은 것이고, 같은 문제가 반복되면 그때마다 통제를 고쳐 재발 확률을 낮춘다는 이야기다. 추상적으로 들리니까 오늘 내 리포에서 실제로 돌아간 한 바퀴를 그대로 적는다.
- 실패 — 내 PR 의 CI 가 빨간불이었다. 프론트엔드 테스트 잡이 죽었다.
- 원인이 내가 아니었다 — 로그를 읽으니 테스트는 하나도 안 깨졌고, 죽인 건 커버리지 임계치였다.
ERROR: Coverage for statements (88.16%) does not meet global threshold (90%). main 이 이미 88.15% 였다. 앞선 커밋이 화면 3개를 테스트 없이 넣으면서 기준선이 내려앉은 것이다. - 누락된 통제 — 이 리포에는 main 자체가 임계치 아래로 내려가는 걸 막는 장치가 없었다. 그래서 그 뒤로 올라오는 모든 PR 이 자기 잘못 없이 빨간불이 됐다.
- 하네스 개선 — 그 화면 3개에 테스트를 붙였다 (936줄).
- 검증 — statements 88.15% → 90.53% (8255/9118). typecheck · typecheck:tests · lint · build 까지 일부만 고르지 않고 전부 돌렸다. PR 체크 11개 전부 통과.
- 더 높아진 기준선 — 이제 90% 는 실제로 지켜지는 선이 됐다.
여기서 내가 배운 건 카드에 없는 쪽이다. 빨간 기준선은 자기 위의 모든 실패를 똑같이 빨갛게 만들어서 구분을 지운다. 내 변경이 깬 것과 원래 깨져 있던 것이 화면상 구분되지 않는다. 그래서 “내 PR 이 빨갛다”를 보고 제일 먼저 할 일은 내 코드를 고치는 게 아니라 기준선에서 같은 잡이 이미 빨간지 확인하는 것이다. 이걸 안 하면 남의 실패를 자기 실패로 착각하고 엉뚱한 데를 고치게 된다. 실제로 나는 로그를 읽기 전까지 “초록”이라는 말을 하지 않기로 하고 시작했는데, 그게 맞았다.
5. 그래서 이 카드를 어떻게 쓸 것인가
버릴 필요는 없다. 체크리스트로는 쓸 만하다. 다만 출처 라벨을 고쳐 붙여야 한다.
| 카드가 말하는 것 | 실제 출처 등급 |
|---|---|
| “구글 공식 논문” | ❌ 확인 안 됨. 구글의 하네스 논문은 AutoHarness 이고 내용이 다름 |
| ①② 가이드·센서 | ThoughtWorks Böckeler 의 용어 (피드포워드/피드백 통제) — 2차 저술, 좋은 글 |
| ①의 “한 줄 한 줄 쌓인 기록” | ⚠️ OpenAI 1차 보고와 어긋남. 그쪽은 실패 모드로 분류 |
| ④⑥ 외부 기억·관측 | OpenAI Codex 팀 1차 경험 보고와 부합 |
| 래칫 | ✅ 개념적으로 타당. Böckeler 의 스티어링 루프와 동일 |
| “모델보다 하네스” | ✅ AutoHarness 가 게임 환경 한정으로 수치까지 냄 |
내가 계속 지키려는 규칙이 하나 있다. 출처 등급을 섞지 않는다. 1차·공식 문서와, 좋은 2차 저술과, 출처 불명 요약 카드는 각각 쓸모가 있지만 같은 무게로 인용하면 안 된다. 카드의 문제는 내용이 틀린 게 아니라 — 대부분 맞다 — 2차 저술 두 편과 실무 통념을 묶어 놓고 1차 논문의 권위를 빌려 쓴 것이다. “이 글 꼭 저장하세요”라는 문장이 붙는 순간 검증 책임은 독자에게 넘어간다.
마지막으로 내 조사의 한계도 적어 둔다. 나는 웹 검색으로 하네스 관련 논문·문서를 훑고 구글 계열 1차 소스(arXiv, cloud.google.com, research.google)를 확인했다. “그런 논문이 없다”를 완전히 증명할 수는 없다. 카드의 6항목 분류를 그대로 담은 구글 1차 문헌을 아시는 분이 있다면 알려주시면 이 글을 고치겠다. 다만 주장하는 쪽이 링크를 대는 게 순서라고 생각한다. 그 카드에는 링크가 한 줄도 없었다.
\[\text{Agent} = \text{Model} + \text{Harness}\]이 등식은 Böckeler 의 글에 나오는 축약이다. 요즘 대부분의 논의가 오른쪽 두 번째 항으로 옮겨 가는 중이고, 그건 맞는 방향이다. 다만 그 항을 이야기할 때도 왼쪽 항을 다룰 때와 같은 인용 기준을 쓰면 좋겠다.
References
- Xinghua Lou, Miguel Lázaro-Gredilla, Antoine Dedieu, Carter Wendelken, Wolfgang Lehrach, Kevin P. Murphy, AutoHarness: improving LLM agents by automatically synthesizing a code harness, arXiv:2603.03329, 2026-02-10 — GameArena 체스 패배의 78% 가 반칙 수, TextArena 145종에서 반칙 제거, Flash > Pro (1차·저자 소속 구글 딥마인드)
- Google Cloud, What is an agent harness?, 2026-08-20 갱신 — 논문이 아니라 제품 설명 페이지임에 유의
- Birgitta Böckeler (ThoughtWorks), Harness engineering for coding agent users — 가이드/센서(피드포워드·피드백), 계산적 vs 추론적 통제, 스티어링 루프 (2차 저술)
- Ryan Lopopolo (OpenAI), Harness engineering: leveraging Codex in an agent-first world, 2026-02-11 — 약 100만 줄 / PR 약 1,500건 / 1인당 하루 3.5 PR, 그리고 단일 거대 AGENTS.md 의 실패 (1차 경험 보고, 자체 측정치)
- 4절의 커버리지 수치(88.15% → 90.53%, 8255/9118)와 CI 결과는 내 비공개 리포에서 오늘 실측한 값이다.