모델은 그대로, 에이전트만 좋아지게 하는 법

에이전트 성능을 올린다고 하면 보통 두 가지를 떠올린다. 더 좋은 모델로 갈아타거나, 모델을 다시 학습시키거나.

지난주 상하이교통대·샤오홍슈 연구팀이 공개한 Harness-R1 논문은 세 번째 길을 검증했다. 모델은 한 글자도 건드리지 않고, 모델을 둘러싼 작업 환경만 고쳐서 에이전트 평균 성공률을 44.3%에서 53.6%로 올렸다.

논문의 훈련 방법 자체는 GPU 8장이 필요한 강화학습이다. 하지만 그 밑에 깔린 루프 — 실패 기록을 모으고, 환경을 고치고, 같은 작업을 다시 돌려 검증하는 순환 — 는 GPU 없이 프롬프트만으로 흉내 낼 수 있다. 이 글은 논문의 핵심을 비개발자도 따라올 수 있게 풀고, 마지막에 그 루프를 그대로 옮긴 프롬프트 4개를 붙였다.

하네스: 모델을 둘러싼 모든 것

에이전트를 신입사원이라고 생각해 보자. 같은 사람이라도 온보딩 문서가 정리된 회사와 아닌 회사, 결재 절차가 있는 회사와 없는 회사에서 성과가 완전히 다르다. 사람(모델)은 같은데 회사 쪽 장치가 다르기 때문이다.

하네스(harness)가 바로 그 회사 쪽 장치 전부다. 모델에게 어떤 맥락을 보여줄지, 모델이 하겠다는 행동을 실행 전에 검사할지, 일이 틀어지면 어떻게 복구시킬지를 정하는 실행 환경이다. 논문의 표현을 빌리면, 같은 모델도 하네스가 다르면 실질적으로 다른 에이전트가 된다.

Claude Code를 쓰고 있다면 이미 하네스를 만지고 있는 셈이다. CLAUDE.md, 훅(hook), 권한 설정, 스킬 — 전부 모델 바깥의 장치, 즉 하네스다.

논문이 한 일: 하네스를 고치는 전문 AI를 훈련했다

Harness-R1의 구조는 역할 분담이 명확하다. 일하는 에이전트(타깃)는 그대로 두고, 그 에이전트의 실패 기록만 읽고 하네스 수정안을 쓰는 별도의 "하네스 엔지니어" AI를 따로 훈련했다.

훈련 신호가 이 논문의 핵심이다.

엔지니어가 수정안을 내면, 고쳐진 환경에서 같은 작업 묶음을 처음부터 다시 실행한다. 성공률이 실제로 오르면 보상, 떨어지거나 형식이 깨지면 0점. 수정안이 그럴듯한지가 아니라, 재실행 점수가 올랐는지만으로 배우게 한 것이다.

결과가 흥미롭다. 이렇게 훈련한 9B(90억 파라미터)짜리 소형 엔지니어가, 프롬프트만 받은 최상위 대형 모델들을 전부 이겼다.

왜 큰 모델이 지는가. 논문에 실린 실패 사례가 답을 보여준다. 한 최상위 모델에게 실패 기록을 주고 하네스 수정을 맡기자, 그럴듯해 보이는 "이 상황에서는 무조건 이렇게 행동하라"는 광범위한 강제 규칙을 써냈고 — 성공률이 41.6%에서 35.4%로 오히려 떨어졌다. 잘 되던 작업까지 망가뜨린 것이다. 유명한 자기개선 기법인 Self-Refine도 세 벤치마크 평균 2.6점을 깎아 먹었다.

교훈은 한 줄이다. 그럴듯한 수정과 효과 있는 수정은 다르며, 둘을 구분하는 유일한 방법은 재실행이다.

개입할 수 있는 네 지점

논문은 하네스 수정이 들어갈 수 있는 위치를 에이전트 실행 루프 위의 네 지점으로 고정했다.

각 지점을 실무 도구로 번역하면 이렇게 대응된다.

네 지점 중 어디가 제일 중요할까. 논문의 제거 실험에서는 ③ 행동 검문소(-3.9점)와 ④ 사후 복구(-3.3점)를 빼면 가장 크게 무너졌다. ① 브리핑(-0.9)과 ② 메모(-0.6)는 상대적으로 작았다.

여기서 실무적으로 중요한 관찰 하나. 우리가 하네스 개선이라고 하면 대부분 ①번 — CLAUDE.md에 지침을 더 쓰는 일 — 만 한다. 그런데 점수를 가장 많이 지킨 것은 행동이 실행되기 직전과 직후의 개입이었다.

다만 어느 지점이 결정적인지는 환경마다 달랐다. 쇼핑 과제에서는 검문소가, 집안일 시뮬레이션에서는 사후 복구가 승부처였다. 우리 팀의 승부처가 어디인지는 일반론이 아니라 우리 팀의 실패 로그가 알려준다는 뜻이다.

좁은 가드 하나가 재설계를 이긴다

논문에서 가장 실무적인 대목은 사례 연구다.

쇼핑 에이전트가 반복하던 실패: 조건에 맞는 상품을 찾아놓고, 필수 옵션(색상)을 선택하지 않은 채 구매 버튼부터 누른다. 엔지니어가 설치한 수정은 단 하나였다.

구매 버튼이 눌리는 순간, 예산 초과이거나 필수 옵션이 미선택 상태면 실행을 차단하고 "보이는 옵션 중 조건에 맞는 것을 먼저 선택하라"고 되묻는다.

이 한 줄짜리 검문소로 10건 중 성공이 2건에서 5건이 됐고, 원래 잘 되던 작업은 그대로 유지됐다. 탐색 방식이나 판단 로직은 전혀 건드리지 않았다. 에이전트의 사고방식을 뜯어고치는 대신, 사고가 나는 지점 하나에 좁은 가드를 세운 것이다.

반대 사례도 있다. 앞서 본 최상위 모델의 실패는 정확히 반대 패턴 — 증거 없이 넓게 강제하는 규칙 — 이었고, 한 작업 묶음에서는 성공 7건을 0건으로 만들었다.

이 루프를 프롬프트로 옮기기

이제 실전이다. 논문의 루프를 Claude Code(또는 아무 에이전트 환경)에서 수동으로 돌리는 4단계 프롬프트다. 순서대로 쓰면 된다.

1단계 — 실패 묶음 만들기. 엔지니어에게 줄 재료를 만든다. 논문도 원본 로그 전체가 아니라 실패 사례만 압축한 "실패 패킷"을 쓴다.

최근 작업 세션에서 실패했거나 내가 손으로 고쳐야 했던 사례를 모아 '실패 묶음'을 만들어줘.
각 사례마다:
- 목표가 무엇이었는지 한 줄
- 실제 진행 순서 요약 (관찰 → 행동 → 결과, 핵심 단계만)
- 어디서부터 어긋났는지
성공한 사례는 빼. 로그 전문을 옮기지 말고 판단에 필요한 부분만 발췌해.
마지막에 여러 사례에서 반복되는 실패 유형이 있으면 유형별로 묶어줘.

2단계 — 하네스 엔지니어 프롬프트. 논문 부록에 실린 엔지니어 프롬프트의 규칙들을 실무용으로 번안한 버전이다. 새 세션을 열고 1단계 결과를 붙여 넣는다.

너는 '하네스 엔지니어'다. 일하는 에이전트의 설정은 그대로 두고,
그 주변의 작업 환경(지침·체크리스트·검증 절차)만 고치는 역할이다.
아래 실패 묶음을 분석해서 반복 실패 패턴을 찾고, 수정안을 제안해줘.

규칙:
- 개별 작업의 정답을 하드코딩하지 마. 다음 작업에도 재사용되는 개입만 제안해.
- 개입 위치는 넷 중에서 골라: ① 작업 시작 전 브리핑(CLAUDE.md)
  ② 단계별 체크리스트 ③ 행동 실행 직전 차단 조건 ④ 오류 발생 후 복구 지침
- 반복 증거가 없는 위치에는 개입을 추가하지 마. 개입은 최소한으로, 조건은 좁게.
- 각 개입마다 (a) 막으려는 실패 (b) 잘 되던 작업을 망칠 위험을 한 줄씩 적어.

[1단계에서 만든 실패 묶음 붙여넣기]

3단계 — 재실행 검증. 논문의 보상 단계에 해당한다. 수정을 반영했으면 반드시 같은 작업으로 되돌아가 확인한다.

방금 수정안을 CLAUDE.md와 작업 지침에 반영했어.
실패했던 작업들을 처음부터 다시 수행해줘.
끝나면 사례별로 '이전 실패 지점 → 이번 결과'를 전후 비교표로 정리하고,
여전히 실패한 건은 수정안이 왜 안 먹혔는지 다시 분석해줘.

4단계 — 회귀 점검. 논문은 재실행할 때 원래 성공하던 작업까지 전부 포함시킨다. 새 규칙이 잘 되던 것을 망치는지 확인하기 위해서다. 이 단계를 건너뛰면 앞서 본 최상위 모델의 실패를 그대로 반복하게 된다.

이번 수정 전에 잘 되던 대표 작업 3건도 같은 방식으로 다시 수행해줘.
새로 넣은 규칙 때문에 오히려 나빠진 지점이 있으면,
그 규칙을 삭제할지, 발동 조건을 더 좁힐지 중 하나로 제안해줘.

한 번에 끝내는 의식이 아니라 루틴이다. 주 1회, 그 주에 쌓인 실패 사례로 1→4단계를 한 바퀴 돌리는 것으로 충분하다. 논문의 엔지니어도 실패 묶음 하나당 수정안 하나씩, 여러 바퀴를 돌며 성장했다.

하지 말 것 세 가지

논문이 엔지니어에게 강제한 규칙들은 그대로 사람에게도 유효한 가드레일이다.

1️⃣ 정답을 하드코딩하지 않는다. "이 상품 ID를 골라라" 같은 개입은 그 작업 하나만 통과시키는 부정행위다. 논문 프롬프트에도 "task-specific answers를 인코딩하지 말라"가 명시돼 있다. 재사용되지 않는 수정은 하네스가 아니다.

2️⃣ 증거 없는 개입을 하지 않는다. 논문 프롬프트의 표현은 "관찰 가능한 반복 실패에서 개입을 추론하라"다. 한 번 실패한 것은 아직 데이터가 아니다. 같은 유형이 반복될 때만 규칙으로 승격한다.

3️⃣ 검증 없이 채택하지 않는다. 수정안이 아무리 논리적이어도 재실행 전에는 가설이다. 논문에서 최상위 모델들의 수정이 실패한 이유는 능력 부족이 아니라 자기 수정의 효과를 확인할 방법 없이 그럴듯함만으로 썼기 때문이다.

이 루프는 어디까지 가나

논문의 나머지 결과 두 가지가 이 루프의 일반성을 보여준다.

모델을 갈아타도 루프는 유효하다. 훈련 때 본 적 없는 20개 모델(Llama·Gemma·Qwen 계열, 1B부터 72B까지)에 같은 엔지니어를 적용하자 20개 전부에서 성능이 올랐다(평균 +7.1점). 실패 기록을 읽고 환경을 고치는 능력 자체가 특정 모델 전용이 아니라는 뜻이다.

모델이 좋아져도 루프는 유효하다. 타깃 모델을 파인튜닝으로 강하게 만든 뒤에도, 그 위에서 하네스 수정이 5.0점을 더 올렸다(59.2% → 64.2%). 모델 개선과 하네스 개선은 양자택일이 아니라 서로를 보완하며 같이 굴러간다. 논문은 이를 두 축의 "공진화(co-evolution)"라고 부른다.

다음 모델이 나오면 해결될 문제라며 하네스 정비를 미루는 팀이 많다. 이 결과는 반대를 가리킨다. 모델이 좋아질수록, 잘 정비된 하네스가 얹어주는 점수는 사라지지 않고 그 위에 쌓인다.

정리하며

Harness-R1이 검증한 것은 결국 세 문장이다.

• 에이전트 성능은 모델만큼이나 모델을 둘러싼 하네스가 결정한다.
• 하네스 수정은 그럴듯함이 아니라 재실행 점수로 판정해야 한다.
• 그 판정 루프 자체가 학습 가능한 역량이며, 작은 전문가가 큰 범용 모델을 이긴다.

세 번째는 조직에도 그대로 적용된다. 실패 로그를 모으고, 좁게 고치고, 재실행으로 검증하는 루틴을 가진 팀은 — 더 큰 모델을 기다리기만 하는 팀보다 빨리 좋아진다.

컨텍스트 파일(①번 지점)을 어떻게 채울지는 이전 글 '600억 토큰을 태우고 남은 8줄'에서 다뤘다. 이번 글의 루프와 합치면, 하네스 네 지점을 실패 데이터로 운영하는 체계가 완성된다.

AX LABS는 국내 대기업을 대상으로 AX 컨설팅과 AI 에이전트 개발 실무 교육을 수행하고 있습니다. 팀의 에이전트 하네스와 운영 루프를 함께 설계하고 싶다면 문의하기 →

참고

• Harness-R1 논문 원문: https://arxiv.org/abs/2608.02276
• 공개 코드: https://github.com/DeepExperience/Harness-R1
• 공개 모델: https://huggingface.co/ShaoShuai0605/Harness-R1
• Claude Code 훅 문서: https://docs.claude.com/en/docs/claude-code/hooks