Google Harness²: NEW Self-Improving AI Agent!
Quick Summary
Google Harness²는 모델 가중치를 바꾸지 않고 에이전트의 실행 환경과 개선 절차를 반복 수정해 성능을 높이는 자기개선 접근이다.
영상 보기
클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론
Google Harness²는 모델 가중치를 바꾸지 않고 에이전트의 실행 환경과 개선 절차를 반복 수정해 성능을 높이는 자기개선 접근이다.
📌 핵심 요점
- 하네스는 모델을 둘러싼 지침·규칙·메모리·도구·스킬·작업 위임 구조다. 영상은 새 모델을 기다리기보다 이 환경을 개선하는 데 주목한다.
- 영상이 소개한 단일 개선 라운드 결과는 ‘work buddy bench’ 최대 11.5점, ‘jobbench’ 4.5점 상승과 ‘lab’ 부분 통과율 11.8%포인트 상승이다. 서로 다른 지표이므로 구분해서 읽어야 한다.
- 핵심 절차는 propose–probe–compose다. 수정안을 제안하고, 같은 작업을 여러 설정으로 실행한 뒤, 비교 결과를 바탕으로 최종 설정을 구성한다.
- 자기개선에는 두 층이 있다. 작업 안에서 설정을 다듬는 반복과, 작업 후 경험을 다음 개선에 재사용하는 반복이다. 후자는 실행 근거가 있는 교훈을 축적하는 방식으로 설명된다.
- 병렬 탐색과 순차 개선으로 추가 성능을 추구하지만 실행 횟수와 API 비용도 늘어난다. 영상은 이를 초기 연구 프로젝트이자 기술적 설치가 필요한 도구로 소개한다.
🧩 배경과 문제 정의
영상은 에이전트가 일을 못할 때 더 좋은 모델만 기다리는 관행에 문제를 제기한다. 모델을 두뇌나 요리사에 비유하고, 지침·도구·메모리·스킬 등 주변 환경인 하네스를 주방에 비유한다. 같은 모델이라도 작업 환경이 부실하면 결과가 나빠질 수 있다는 설명이다.
사람이 한 번 설계한 고정 하네스는 처음 예상하지 못한 작업을 만나는 ‘오픈 월드’에서 한계를 드러낸다. Harness²는 사람이 수동으로 하던 설정 수정을 에이전트의 제안·실험·비교 과정으로 옮기고, 작업에서 얻은 교훈을 다음 개선에 활용하려는 접근으로 소개된다. 여기서 자기개선은 모델 가중치의 변화가 아니라 실행 환경과 개선 절차의 변화다.
🕒 시간순 섹션별 상세정리
1. 새 모델 대신 하네스를 개선한다
- Google Research의 무료 오픈소스 도구로 Harness²를 보여준다. 모델은 그대로 두고 주변 설정을 고쳐 업무 성능을 높인다는 것이 출발점이다. [00:59]
- 하네스는 지침·규칙·메모리·도구·스킬·보조 에이전트를 포함한다. 사람이 한 번 만든 설정으로 예상하지 못한 작업까지 처리하려는 것이 문제라고 보여준다. [02:26]
- 진행자는 자신의 공유 메모리 기반 에이전트 환경을 예로 들며, 실패 원인이 새 모델의 부재보다 누락된 규칙이나 모호한 지침에 있는 경우가 많다고 드러낸다. Harness²는 이런 수정 작업을 에이전트에 맡긴다. [02:54]
2. 성능 수치와 공개 프로젝트의 반응
- 세 평가군과 두 모델, 네 가지 모델·하네스 조합을 보여준다. 전사상 ‘work buddy bench’ 최대 11.5점, ‘jobbench’ 4.5점, ‘lab’ 부분 통과율 11.8%포인트 상승이며, 부분 통과율은 작업 일부라도 맞힌 비율이라고 보여준다. [03:41]
- 소개된 향상은 단일 개선 라운드의 결과이며 모델 가중치는 바뀌지 않았다고 강조한다. 추가 라운드에서도 개선이 이어진다고 전하고, 약 2주 동안 GitHub 별 12,600개 이상과 포크 1,200개를 얻었다고 보여준다. [04:12]
- 이어지는 유료 커뮤니티 홍보에서는 여러 에이전트가 메모리·스킬 파일·작업 보드를 공유하는 환경과 설치 자료, 코칭을 제시한다. 이는 연구 결과 설명과 구분되는 진행자의 서비스 소개다. [04:58]
3. 제안·시험·조합으로 설정을 고른다
- propose 단계에서 하네스 편집기가 지침이나 스킬 등의 수정안을 만든다. 여러 업무에 통하는 일반 수정안과 해당 작업 유형에 맞춘 수정안을 함께 제안한다. [05:33]
- probe 단계에서는 각 수정안을 적용해 같은 작업을 실행한다. compose 단계에서는 실행 결과를 비교하고 효과가 있었던 변경을 바탕으로 최종 설정을 구성한다. [05:55]
- 영상은 이 과정에 정답을 알려주는 피드백이 필요하지 않다고 보여준다. 같은 작업을 여러 방식으로 수행한 결과를 비교해 도움이 된 변경을 남기는 구조다. [06:25]
4. 여덟 수정 영역과 두 층의 개선 루프
- 수정 대상으로 시스템 프롬프트, 가드레일, 메모리, 도구 지침, 서브에이전트, 스킬, 스크립트, 플러그인을 제시한다. 각각 시작 시의 지식, 도구 사용, 업무 분담, 실행 단계의 동작에 관여한다. [07:24]
- 한 작업 안의 반복은 작업 수준 재귀로 보여준다. 그 위의 하네싱 수준 재귀에서는 경험 반영기가 작업 후 선택된 설정과 교훈을 저장하고, 다음 작업의 수정안을 제안하기 전에 이를 읽는다. [08:24]
- 저장 대상은 실행 결과로 뒷받침되는 교훈이라고 강조한다. 추측으로 가득 찬 메모리는 에이전트를 악화시킬 수 있으므로, 무엇을 기억하는지가 개선의 핵심이라는 설명이다. [08:49]
5. 병렬로 넓히고 순차적으로 다듬는다
- 병렬 방식은 여러 설정을 동시에 시험한다. 예산을 3으로 두는 예에서는 일반 설정 3개와 작업 특화 설정 3개를 시험하고, 이를 바탕으로 조합 설정 3개를 만든다고 보여준다. [09:10]
- 순차 방식은 한 라운드의 최선 설정을 다음 라운드의 출발점으로 삼는다. 병렬은 탐색 범위를 넓히고 순차는 선택한 설정을 더 깊이 다듬으며, 영상은 예산 증가에 따라 두 방식 모두 추가 개선을 보였다고 전해진다. [09:30]
- 실제 작업을 수행하는 실행기로 OpenCode와 Codex를 지원하고 OpenCode가 기본이라고 보여준다. 연구실 전용 환경이 아니라 기존 에이전트 도구와 연결하는 접근임을 강조한다. [09:51]
6. 운영 비용과 초기 단계의 한계, 마지막 메시지
- 각 probe는 작업 전체를 다시 실행하므로 시험 비용이 발생한다. API 요금 때문에 작은 작업 집합부터 시작하라는 안내를 전하며, 공식 지원 Google 제품이 아닌 초기 연구 프로젝트라는 점도 짚어 본다. [10:26]
- Linux, Python 3.12, Node.js, Google Cloud 설정 등 기술적 준비가 필요하다고 보여준다. 이어 비개발자도 지침·규칙·메모리·스킬을 개선한다는 원리는 적용할 수 있고, 관련 지식은 점진적으로 쌓인다고 강조한다. [11:21]
- 마지막에는 공유 메모리와 스킬 파일을 사용하는 에이전트 운영 환경, 설치 자료, 코칭과 일일 튜토리얼을 다시 홍보한 뒤 시청 인사로 마무리한다. [12:13]
🧾 결론
- 영상에서 말하는 자기개선은 모델 재학습이 아니라 모델 주변의 지침·메모리·스킬·도구 사용 방식을 수정하는 것이다.
- 차별점은 한 작업의 설정 최적화에 더해, 개선 과정에서 얻은 교훈을 다음 작업의 개선 절차에 반영한다는 데 있다.
- 실제 도입 가치는 벤치마크 상승폭만으로 판단하기 어렵다. 자신의 작업에서 품질 향상과 추가 실행 비용을 함께 확인해야 한다.
📈 투자·시사 포인트
- 에이전트 성능을 평가할 때 기반 모델뿐 아니라 하네스 설계와 운영 방식을 함께 살펴볼 필요가 있다.
- 오픈소스 공개와 운영비 무료는 구분해야 한다. 여러 설정을 시험하는 구조에서는 API 비용과 실행 시간이 경제성을 좌우한다.
- 업무 자동화에서는 실패 기록을 근거 있는 규칙·메모리·스킬 개선으로 연결하는 운영 역량이 중요해진다는 시사점을 준다.
- 영상에 제시된 연구 성과와 프로젝트 관심도만으로 상용 서비스의 수익성이나 특정 기업의 투자 가치를 판단할 수는 없다.
⚠️ 불확실하거나 확인이 필요한 부분
- 벤치마크·모델 이름 일부는 전사상 불명확하다. 정확한 명칭, 평가 조건, 기준 점수와 조합별 결과는 제공된 전사만으로 확정하기 어렵다.
- 본문에서는 업무 벤치마크 최대 11.5점 상승과 부분 통과율 11.8%포인트 상승을 구분하지만, 후반에는 사무 업무 개선을 11.8점으로 표현한다. 수치와 지표가 혼용된 대목이다.
- 정답 피드백 없이 실행 결과를 비교한다고 설명하지만, 비교 판단의 정확성이나 잘못된 개선안을 걸러내는 구체적 기준은 충분히 제시되지 않는다.
- 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
- 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
- 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.
✅ 액션 아이템
- 반복 수행하는 소규모 업무를 선정하고 현재 설정의 결과 품질·실행 시간·API 비용을 기록한다.
- 실패 사례를 지침, 규칙, 메모리, 도구 사용법, 스킬 등 하네스 구성 요소별로 분류한다.
- 같은 작업에서 설정 변경 전후를 비교하고, 관찰된 실행 결과로 뒷받침되는 교훈만 다음 작업에 반영한다.
- 영상에 등장한 벤치마크 이름과 개선 수치, 지원 실행기, 설치 요건을 원문 자료에서 확인한다.
❓ 열린 질문
- 정답 피드백 없이 비교하는 과정에서 실제로 더 정확한 결과와 그럴듯한 결과를 어떻게 구별하는가?
- 특정 작업에서 얻은 교훈이 다른 작업의 성능을 떨어뜨릴 때 이를 어떻게 발견하고 수정하는가?
- 병렬 탐색과 순차 개선 중 어떤 방식이 업무 유형별로 더 나은 비용 대비 효과를 내는가?