YouTubeJulian Goldie SEO·2026년 10월 20일·0

Google Harness²: NEW Self-Improving AI Agent!

Quick Summary

Google Harness²는 모델 가중치를 바꾸지 않고 에이전트의 실행 환경과 개선 절차를 반복 수정해 성능을 높이는 자기개선 접근이다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

Google Harness²: NEW Self-Improving AI Agent! 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

Google Harness²: NEW Self-Improving AI Agent!의 핵심 내용을 4단계로 요약한 인포그래픽
Google Harness²: NEW Self-Improving AI Agent! 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

Google Harness²는 모델 가중치를 바꾸지 않고 에이전트의 실행 환경과 개선 절차를 반복 수정해 성능을 높이는 자기개선 접근이다.

📌 핵심 요점

  1. 하네스는 모델을 둘러싼 지침·규칙·메모리·도구·스킬·작업 위임 구조다. 영상은 새 모델을 기다리기보다 이 환경을 개선하는 데 주목한다.
  2. 영상이 소개한 단일 개선 라운드 결과는 ‘work buddy bench’ 최대 11.5점, ‘jobbench’ 4.5점 상승과 ‘lab’ 부분 통과율 11.8%포인트 상승이다. 서로 다른 지표이므로 구분해서 읽어야 한다.
  3. 핵심 절차는 propose–probe–compose다. 수정안을 제안하고, 같은 작업을 여러 설정으로 실행한 뒤, 비교 결과를 바탕으로 최종 설정을 구성한다.
  4. 자기개선에는 두 층이 있다. 작업 안에서 설정을 다듬는 반복과, 작업 후 경험을 다음 개선에 재사용하는 반복이다. 후자는 실행 근거가 있는 교훈을 축적하는 방식으로 설명된다.
  5. 병렬 탐색과 순차 개선으로 추가 성능을 추구하지만 실행 횟수와 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 비용을 기록한다.
  • 실패 사례를 지침, 규칙, 메모리, 도구 사용법, 스킬 등 하네스 구성 요소별로 분류한다.
  • 같은 작업에서 설정 변경 전후를 비교하고, 관찰된 실행 결과로 뒷받침되는 교훈만 다음 작업에 반영한다.
  • 영상에 등장한 벤치마크 이름과 개선 수치, 지원 실행기, 설치 요건을 원문 자료에서 확인한다.

❓ 열린 질문

  • 정답 피드백 없이 비교하는 과정에서 실제로 더 정확한 결과와 그럴듯한 결과를 어떻게 구별하는가?
  • 특정 작업에서 얻은 교훈이 다른 작업의 성능을 떨어뜨릴 때 이를 어떻게 발견하고 수정하는가?
  • 병렬 탐색과 순차 개선 중 어떤 방식이 업무 유형별로 더 나은 비용 대비 효과를 내는가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.