하네스 어댑터: 모델 대신 '작업 환경'을 맞추는 법

왜 필요했나: 모델만 바꾸면 하네스가 맞지 않는다

에이전트는 언어 모델 혼자 움직이지 않는다. 무엇을 관찰할지, 도구를 어떻게 부를지, 행동을 실제로 어떻게 실행할지, 실패 메시지를 어떻게 돌려줄지, 언제 멈출지를 정하는 실행 틀이 모델을 감싸고 있고, 이것을 하네스(에이전트 하네스)라고 부른다. Life-Harness 연구논문는 에이전트가 모델뿐 아니라 관찰·도구 사용·행동 실행·피드백 해석·Trajectory(행동 기록) 제어를 맡는 런타임 하네스에 의해서도 만들어진다고 짚었다.

문제는 하네스가 보통 특정 프런티어 모델에 맞춰 설계된다는 점이다. SLM 하네스 최적화 연구논문에 따르면 프런티어 LLM 에이전트는 추론 비용이 높아 대규모로 배치하기 어렵다. 그런데 비용을 줄이려고 SLM(소형 언어 모델)을 프런티어용 하네스에 그대로 끼우면 대개 성능이 기대에 못 미친다. 하네스가 바뀌지 않았는데 모델만 작아졌기 때문이다.

지금까지 에이전트를 업무에 맞추는 방법은 주로 파인튜닝이나 강화학습으로 모델 파라미터를 고치는 것이었다. Life-Harness논문는 규칙이 분명하고 결과가 정해진(deterministic) 영역에서는 실패의 상당수가 모델 능력 부족이 아니라 모델과 환경 사이 인터페이스의 어긋남에서 생긴다고 봤다. 이 경우 고칠 대상은 모델이 아니라 인터페이스, 즉 하네스다. 하네스 어댑터는 이 관찰에서 나왔다.

핵심 아이디어: 사람을 바꾸지 말고 작업대를 맞춘다

공장에서 새 작업자가 오면 그 사람을 재교육하기도 하지만, 지그(작업 보조 틀)와 작업 지침서를 그 사람 손에 맞게 바꾸는 편이 빠를 때가 많다. 하네스 어댑터도 같은 발상이다. 모델 가중치는 고정해 두고, 모델이 일하는 작업대인 지시문·도구·실행 순서를 그 모델과 그 업무에 맞게 다듬는다.

SLM 하네스 최적화 연구논문는 이 발상의 근거를 이렇게 설명한다. 업무 난이도의 상당 부분은 개별 사례마다 다른 것이 아니라 여러 사례에 공통으로 나타난다. 공통된 어려움이라면 모델이 매번 혼자 알아내게 할 필요 없이 맞춤 지시문, 도구, 오케스트레이션 루프의 형태로 하네스에 한 번 넣어 두면 된다. 연구진은 이것을 어려움을 모델에서 하네스로 '들어 옮긴다'고 표현했다.

이 방식이 무엇을 맞바꾸는지도 분명하다. 파인튜닝은 모델 안에 능력을 새기므로 다른 하네스로 옮겨도 어느 정도 유지되지만 학습 비용과 데이터가 필요하고, 가중치를 공개하지 않는 API 모델에는 쓸 수 없다. 하네스 적응은 학습 없이 바로 적용되고 사람이 읽을 수 있는 형태로 남지만, 그 모델·그 업무 조합에 묶이기 쉽다. 그래서 하네스 어댑터는 '어느 모델에나 맞는 최고의 하네스'를 찾는 것이 아니라 '이 모델에 맞는 하네스'를 찾는 일에 가깝다.

어떻게 작동하나: 실패에서 하네스 수정까지

자동 하네스 적응은 대체로 다음 순서로 돌아간다. 첫째, 고정된 모델로 학습용 작업을 여러 번 실행해 Trajectory를 모은다. 둘째, 실패한 Trajectory를 살펴 실패 유형을 나눈다. SLM 하네스 최적화 연구논문는 에이전트의 실패 유형을 하네스 적응 전략과 짝지은 틀을 만들고, 메타 에이전트(다른 에이전트를 고치는 에이전트)가 실패 Trajectory에서 효과적인 수정을 자동으로 찾게 했다.

셋째, 실패를 고칠 수정안을 만든다. 무엇을 고치는지는 연구마다 조금씩 나누는 방식이 다르다. SLM 하네스 최적화 연구논문는 지시문·도구·오케스트레이션 루프를 손봤다. Life-Harness논문는 반복되는 상호작용 실패를 네 갈래의 재사용 가능한 개입으로 바꿨다. 환경과의 약속을 분명히 적는 '환경 계약', 절차를 담은 '절차적 스킬', 모델이 말한 행동을 실제 실행으로 바꾸는 '행동 구현', 실행 흐름이 엇나가지 않게 잡는 'Trajectory 조절'이다.

넷째, 수정안을 평가해 나아진 것만 남긴다. 다섯째, 이렇게 만든 하네스는 평가 단계에서 고정한 채 처음 보는 작업에 쓴다. Life-Harness논문가 학습 Trajectory로 하네스를 진화시킨 뒤 평가할 때는 고정해 둔 것이 그 예다. 모델 가중치와 평가 환경은 내내 바뀌지 않는다는 점이 파인튜닝과 가장 크게 다르다.

발전 흐름: 출발점 연구들이 새로 한 것

Life-Harness논문는 '인터페이스를 고치지 모델을 고치지 않는다'는 입장을 분명히 했다. AgentBench, τ-bench, τ²-bench, AppWorld의 8개 환경에서 18개 오픈웨이트 모델로 평가했고, Qwen3-4B-Instruct 기준으로 공통 7개 환경의 평균 정확도에서 기존 자동 하네스 방법인 Meta-Harness와 AHE보다 각각 28.7%p, 7.5%p 높았다. 최적화에 쓴 토큰은 각각 8.5%, 68.4% 적었다. 이렇게 진화시킨 하네스를 GPT 5.5, Opus 4.8, Gemini 3.1 Pro 같은 프런티어 모델에 붙였을 때도 평균 3.5%p가 올랐다.

SLM 하네스 최적화 연구논문는 비용 측면을 정면으로 다뤘다. 7개 업무형 에이전트 과제와 3개 SLM 계열을 조합한 21쌍 가운데 16쌍에서 최적화된 하네스가 성능을 유의하게 높였고, 7쌍은 SLM과 LLM의 성능 차이를 메웠다. 가장 좋은 SLM 에이전트는 LLM 성능의 89.7%를 4%의 비용으로 냈다. 연구진은 많은 일상 업무에서 적응된 하네스와 짝지은 SLM이 90% 낮은 비용으로 LLM 성능에 맞먹을 수 있다고 정리했다.

적응 대상을 하네스 전체가 아니라 그 안의 부품으로 좁힌 연구도 있다. RASO논문는 에이전트 스킬, 즉 특정 하네스에서 에이전트가 일을 잘하도록 이끄는 재사용 가능한 자연어 문서에 주목했다. 공개된 스킬이 수백만 개 쌓였는데도 기존 방법은 비싼 Rollout(실제 실행)만으로 스킬을 고쳤다. RASO는 외부 스킬 모음에서 관련 지식을 찾아 대상 작업과 하네스에 맞게 옮기는 'Cross-Harness Adaptation'을 제안했다. Rollout 없이 초기 스킬을 만드는 단계(RASI)와 실행 피드백을 따라 검색·수정하는 단계(RASU)로 나뉘며, 4개 벤치마크와 2개 모델에서 검색 기반 초기화·갱신이 없는 기준선보다 꾸준히 나았다.

하네스 적응은 안전과 학습 쪽으로도 넓어졌다. HASTE논문는 위협 보고서의 짧은 설명이나 공격 예시 몇 개 같은 빈약한 증거만으로 하네스를 진화시킨다. 안전 명세를 만드는 쪽과 공격 사례를 만드는 쪽을 서로 맞붙게 하고, 여러 모델·공격 유형에서 정상 작업의 효용은 지키면서 공격 성공률을 낮췄다. ScienceBuddy논문는 하네스 진화와 모델 강화학습을 이중 고리로 엮었다. 안쪽 고리는 모델을 고정한 채 하네스를 고치고, 바깥 고리는 개선된 하네스 아래에서 모델을 학습시킨다. 하네스가 학습 경험을 바꾸고, 학습된 모델이 다시 새 하네스 적응의 기회를 만든다는 구도다.

궁합은 왜 바뀌나: 모델-하네스 상호작용

하네스 어댑터가 따로 다룰 만한 주제인 이유는 모델-하네스 궁합 연구논문에서 잘 드러난다. 연구진은 설정을 바꿀 수 있는 4개 하네스(OpenHands, DeepSeek Harness, PI, openJiuwen)와 5개 모델, 그리고 Codex-GPT와 Claude Code-Claude 같은 자사 조합까지 합쳐 66개 구성을 TUA-Bench, ALE-CLI, Terminal-Bench 4에서 비교했다. 이를 위해 여러 모델을 여러 하네스에 연결하는 어댑터를 만들었고, 그 어댑터와 평가 코드, 점수가 매겨진 6,204개 Trajectory를 공개했다.

결과는 '좋은 모델'이라는 말이 하네스 없이는 성립하지 않는다는 것이었다. Terminal-Bench 4에서 Claude는 OpenHands에서 GPT보다 7.94점 앞섰지만 PI에서는 30.16점 뒤졌다. 5개 모델 중 4개는 벤치마크가 바뀌면 최적 하네스도 바뀌었다. 모델 제작사의 자체 하네스가 늘 최선은 아니었고, 비용을 더 쓴다고 점수가 오르지도 않았다. Terminal-Bench 4에서 GPT는 DeepSeek Harness보다 PI에서 더 높은 점수를 냈는데, 작업당 비용은 4분의 1도 되지 않았다.

연구진은 같은 작업의 Trajectory를 맞대어 이유를 찾았다. 수리는 거의 언제나 모델이 스스로 시작하므로, 하네스가 실패를 모델이 쓸 수 있는 형태로 돌려주는지가 성패를 크게 가른다. GPT는 군더더기 없는 PI에서 가장 잘했고, 형식이 잘못된 도구 호출을 자주 내는 Kimi는 openJiuwen에서 세 벤치마크 모두 최고 점수를 냈다. 이 연구는 모델·하네스·작업을 함께 평가해야 한다고 결론지었다. 하네스 어댑터를 설계할 때 '이 모델이 어떤 실수를 자주 하나'부터 묻는 이유가 여기에 있다.

요즘 어디로 가고 있나

첫째 방향은 하나의 하네스를 고치는 대신 작업마다 하네스를 조립하는 것이다. STITCH논문는 하네스의 각 메커니즘(맥락 수집, 도구 호출, 검증, 상태 보존, 종료)이 작업에 따라 득이 되기도 하고 부담이나 주의 분산이 되기도 해서, 하나로 고정된 하네스는 최적일 수 없다고 봤다. 그렇다고 작업마다 하네스 코드를 새로 생성하면 생성·디버깅 비용과 실행 위험이 쌓인다. 그래서 실패 Trajectory에서 적용 범위와 조합 규칙이 분명한 재사용 부품('Harness Primitives')을 캐 두고, 테스트 시점에 작업 정보에 맞는 부품만 골라 조립한다. 고정 하네스보다 작업 성공률이 최대 12점 올랐고, 부품 라이브러리가 커질수록 성능도 좋아졌으며, Codex CLI 같은 사람이 설계한 하네스도 앞섰다.

둘째 방향은 하네스와 함께 평가 환경도 진화시키는 것이다. HERA논문는 풀 수 없는 작업을 알아보고 멈추는 '에이전트 기권' 능력을 다뤘다. 고정된 작업 묶음에 대해서만 하네스를 최적화하면 처음 보는 실패 유형에 약하다는 문제를 풀려고, 풀 수 있는 작업을 일부러 변형해 기권해야 하는 작업을 만들고, 이전 약점을 노리는 새 환경을 계속 생성했다. 진화한 하네스는 기권 정확도를 61.7%에서 83.3%로, 수행 가능한 작업의 완료율을 68.3%에서 76.7%로 올렸다. 이 하네스는 모델별 최적화 없이 다른 19개 LLM에 옮겨도 기권 정확도를 평균 15.3%p 높였고, 작은 모델이 비용을 약 85% 줄이면서 큰 모델 성능에 맞먹게 했다.

셋째 방향은 운영 중 지속 학습을 안전하게 하는 것이다. VIGIL논문은 스프레드시트 질의응답에서 나중에 도착하는 정답 라벨로 하네스를 개선하되, 기본 모델·프롬프트·검색기는 고정하고 계약 보정기와 열 선택기만 갱신했다. 이 좁은 범위의 갱신만으로 정확도가 정적 기준선 75.8%에서 82.0~82.4%로 올랐고, 더 엄격한 분할에서는 보류 데이터 평균 정확도가 80.3%에서 86.7%로 올랐다. 보정기만 갱신해도 5.9점이 올라 전체 갱신의 6.4점에 가까웠다. '하네스의 어디까지를 바꾸게 둘 것인가'를 좁게 잡는 설계다.

한계와 쟁점, 그리고 실무 판단 기준

언제 쓰나. SLM 하네스 최적화 연구논문의 분석에 따르면 하네스 적응은 워크플로가 반복적인 작업과 기본 능력이 충분한 SLM에서 가장 잘 통한다. 21쌍 중 성능이 유의하게 오른 것은 16쌍이었고, 나머지는 하네스만으로 부족했다. 하네스는 공통된 어려움을 덜어 줄 뿐 모델에 없는 능력을 만들어 주지는 않는다. 작업마다 요구가 크게 다른 열린 문제라면 파인튜닝이나 더 큰 모델이 맞을 수 있다.

흔한 실수 1: 게이트를 통과했으니 안전하다고 믿는 것. VIGIL논문에서 게이트가 승인한 26개 갱신 가운데 3개는 보류 데이터에서 이전 버전보다 정확도를 떨어뜨렸다. 연구진은 재생 버퍼(과거 데이터를 다시 돌려 보는 검사)에서 퇴보가 없어도 처음 보는 데이터에서 퇴보가 없다는 뜻은 아니라고 적었다. 하네스 수정은 학습 Trajectory에 과적합될 수 있으므로 적응에 쓰지 않은 보류 세트로 따로 확인해야 한다.

흔한 실수 2: 한 조합에서 얻은 결론을 다른 조합에 그대로 옮기는 것. 모델-하네스 궁합 연구논문가 보여 주듯 모델 순위와 최적 하네스는 하네스·벤치마크에 따라 뒤집힌다. 모델을 바꾸면 하네스를 다시 평가해야 하고, 공급사 하네스나 비싼 구성이 최선이라고 가정하지 않는다. 반대로 Life-Harness논문와 HERA논문처럼 다른 모델로 옮겨도 이득이 남는 사례도 있으니, 이전 효과는 가정이 아니라 측정으로 확인한다.

흔한 실수 3: 결과 숫자만 남기고 증거는 남기지 않는 것. 에이전트 안전 평가 연구논문는 같은 작업 성공률·공격 성공률이라도 그 밑의 증거 수준이 크게 다를 수 있다고 지적했다. 이 연구는 여러 하네스의 실행 기록을 받아 결정마다 '증거 충분성 카드'를 내는 하네스 간 어댑터를 만들었는데, 겉으로는 같은 결과로 읽히는 4개 입력의 충분성 점수가 0.458~0.833으로 갈렸고, 채점한 모든 기록이 재실행 전제 조건을 충족하지 못했다. 하네스가 자동으로 진화할수록 무엇이 왜 바뀌었는지 재구성할 수 있는 기록이 중요해진다. 안전 규칙도 하네스에 들어 있으므로, 새 공격이 나오면 HASTE논문처럼 공격 사례로 다시 검증하는 고리가 필요하다.

더 공부하려면

처음이라면 SLM 하네스 최적화 연구논문부터 읽는 것이 좋다. 왜 어려움을 하네스로 옮길 수 있는지, 실패 유형과 적응 전략을 어떻게 짝짓는지, 어떤 작업에서 잘 통하는지가 업무 관점에서 정리돼 있다. 이어 Life-Harness논문에서 환경 계약·절차적 스킬·행동 구현·Trajectory 조절이라는 개입의 분류를 보면 하네스의 어느 부분을 고칠 수 있는지 감이 잡힌다.

모델을 고르는 실무자라면 모델-하네스 궁합 연구논문가 필수다. 공개된 어댑터와 6,204개 Trajectory로 직접 비교해 볼 수도 있다. 하네스를 작업마다 다르게 쓰고 싶다면 STITCH논문, 스킬 단위로 재사용하고 싶다면 RASO논문를 이어서 본다.

운영과 안전을 맡는다면 VIGIL논문의 게이트 설계와 그 한계, HERA논문의 기권 평가, HASTE논문의 공격 대응 진화, 에이전트 안전 평가의 증거 재구성 지표논문를 차례로 읽으면 된다. 하네스와 모델 학습을 함께 돌리는 큰 그림은 ScienceBuddy논문의 이중 고리 구조가 잘 보여 준다.