구글의 Harness²·RRSI와 내가 만드는 하네스의 방향
비슷한 시기에 발견한 같은 고민
코드 컨벤션을 템플릿으로 만들고, AI가 이를 선택해 구현하도록 하네스를 정리하던 중 구글 연구진이 공개한 Harness²와 RRSI를 접했다.
공교롭게도 내가 하네스를 만들고 정리하던 시기와 두 연구의 공개 시기가 겹쳤다. RRSI는 2026년 9월, Harness²는 같은 해 10월에 공개됐다.
독립적으로 고민하며 만들던 구조가 연구에서 다루는 문제와 맞닿아 있다는 점이 흥미로웠다. 특히 작업 경험을 다음 실행에 반영한다는 생각과, 개선 과정에서 규칙과 비용이 불필요하게 늘어날 수 있다는 문제가 익숙했다.
구글이 공개한 Harness²와 RRSI는 무엇인가
두 프로젝트는 AI 모델 자체를 다시 학습시키기보다, 모델 주변의 프롬프트·도구·기억·작업 절차를 개선하는 연구 프레임워크다. 이 주변 실행 구조를 하네스라고 부른다.
| 연구 | 핵심 질문 | 접근 |
|---|---|---|
| Harness² | 처음 만나는 작업에서도 실행 방식을 개선할 수 있을까? | 하네스 변경안을 제안하고 실행을 비교해 개선한다. 근거 있는 교훈은 다음 작업에 반영한다 |
| RRSI | 반복 개선이 특정 평가에만 맞춰지거나 비용만 늘어나지는 않을까? | 변경 범위와 채택 기준을 관리하고 성능·비용·일반화 효과를 평가한다 |
Harness²는 현재 작업에서 실행 구조를 개선하는 과정과, 경험을 축적해 다음 개선에 활용하는 과정을 연결한다. RRSI는 자동 개선이 평가에 과적합되거나 불필요하게 복잡해지는 것을 억제하는 데 초점을 둔다. Harness² 공식 저장소, RRSI 공식 저장소
내가 만드는 하네스와 닮은 점
내 하네스도 작업이 끝날 때마다 모든 맥락을 버리고 새로 시작하는 비용을 줄이려는 데서 출발했다.
설계 의도는 ADR과 Knowledge에 남기고, 반복해서 사용하는 코드 구조는 템플릿으로 만들었다. 오케스트레이션은 작업에 필요한 템플릿과 실행 절차를 연결한다.
합의한 규칙과 설계 의도
↓
구현·테스트·E2E 템플릿
↓
작업에 맞는 원셋 선택
↓
복사 후 도메인 차이 반영
↓
검증과 개선 후보 발견
AI가 매번 구조를 새로 설계하기보다, 준비된 구조를 재사용하도록 하는 방식이다. 이를 통해 토큰 소비를 줄이면서도 변경 위치와 책임을 예측할 수 있게 하려 한다.
작업 경험을 재사용 가능한 형태로 남기고 다음 실행을 개선한다는 방향은 두 연구와 닮아 있다. 다만 같은 기능을 구현했거나 연구 결과를 재현했다는 의미는 아니다.
차이는 개선안을 채택하는 방식에 있다
| 구분 | 내 하네스 | Harness² | RRSI |
|---|---|---|---|
| 중심 자산 | 컨벤션과 구현·테스트·E2E 템플릿 | 실행 하네스와 축적된 교훈 | 개선 후보와 평가 이력 |
| 실행 개선 | 검증된 원셋 재사용과 차이 반영 | 변경안의 실행 결과를 비교해 구성 | 후보를 평가하고 선택·제거 |
| 공통 기준 변경 | 사람이 검토하고 승인 | 자동 개선 과정에서 채택 | 평가와 선택 규칙에 따라 채택 |
| 효과 확인 | 테스트·리뷰·실제 작업 경험 | 실행 비교와 벤치마크 | 성능·변동성·비용·일반화 평가 |
나도 처음에는 하네스 개선을 자동으로 반영하려고 했다. 하지만 의도보다 넓게 변경하거나 규칙을 과하게 추가하는 문제가 생겨, 공통 기준은 직접 검토하고 채택하는 방식으로 바꿨다.
한 작업에서 필요했던 수정이 모든 작업에 적용할 규칙은 아니다. 개인의 선호와 조직이 함께 지킬 기준도 구분해야 한다.
결정
현재는 다음 방식을 유지한다.
- 저장소의 프로젝트 규칙과 기존 구현 패턴을 우선한다.
- 적용 가능한 원셋을 재사용하고 이번 작업의 차이만 반영한다.
- 요구사항과 필요한 검증을 충족하는 방법 중 토큰 소비가 가장 적은 경로를 선택한다.
- AI는 반복 문제와 개선안을 제안한다.
- 공통 컨벤션·Knowledge·템플릿·오케스트레이션의 변경은 사람이 승인한다.
- 토큰 절약을 이유로 테스트를 생략하거나 통과 기준을 낮추지 않는다.
자동 개선 연구에서는 변경을 작게 나누고 근거를 남기며, 효과가 없는 규칙을 제거한다는 접근을 참고한다. 현재 하네스에 두 프레임워크를 직접 통합한 것은 아니다.
결과와 앞으로의 과제
이 방식은 AI의 코드 생성 속도를 활용하면서도, 내가 이해하고 관리할 수 있는 구조를 유지하는 데 목적이 있다. 대신 템플릿과 하네스를 관리하는 시간이 필요하고, 개선 효과를 판단하는 과정에도 사람이 관여해야 한다.
앞으로 대표 작업과 비교 가능한 실행 기록이 쌓이면 제한된 범위에서 자동화를 다시 검토할 수 있다. 그때는 변경 범위와 평가 기준, 비용 한도, 되돌리기 조건을 먼저 정하려 한다.
비슷한 시기에 공개된 구글의 연구는 내가 고민하던 문제를 다른 규모와 방법으로 다루고 있었다. 지금은 그 방법을 그대로 도입하기보다, 내 작업에 맞는 재사용과 검증의 기준을 다듬는 데 참고하려 한다.