하네스

요즘 하네스가 유행입니다. 하네스로 바벨탑이라도 쌓을 기세로 많은 이야기가 오가고 있습니다.

개인적으로 기술이란 단기적으로는 과대평가되고 장기적으로는 과소평가되는 측면이 강하다고 생각합니다. 사실 이건 제 통찰이 아니라 이름까지 붙어 있는 법칙입니다. 아마라의 법칙(Amara's Law) 입니다. Roy Amara가 한 말인데, "We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run." 정확히 이 이야기입니다.

이 렌즈로 보면, 현시점에 하네스로 엔터프라이즈급 시스템을 만들겠다는 식의 주장은 다소 과한 이야기로 들립니다. 단기 과대평가의 전형입니다. 다만 그것은 어디까지나 단기적인 이야기이고, 장기적인 관점에서 하네스는 앞으로 개발자에게 익숙하고 중요한 기술이 될 것이라고 봅니다. 하네스라는 관점 자체가 상당히 흥미롭기 때문입니다. 이 글은 그 "왜"에 대한 정리입니다.

그래서 하네스가 무엇인가

하네스, 한글로는 마구(馬具) 입니다. 말에 채우는 장비 일체를 뜻합니다. 통제되지 않은 상태로 움직이는 에이전트에게 일종의 고삐를 채워서, 원하는 방향으로 이끌고 제어함으로써 더 높은 품질과 일관된 결과를 얻어내는 것이 목적입니다. 어원과 비유가 정확히 들어맞습니다.

조금 더 요즘 통용되는 정의로 말하면, 하네스는 모델 주변의 시스템 계층 입니다. 컨텍스트를 어떻게 관리하고, 어떤 도구를 제공하며 그것을 어떻게 설명하고, 상태를 어떻게 유지하고, 권한을 어떻게 강제하고, 에러를 어떻게 복구하는지를 다룹니다. 한마디로 모델과 세계(world) 사이를 중개하는 코드 계층입니다. LLM은 본질적으로 텍스트만 출력하기 때문에, "이 파일을 읽어라"라는 의도는 내놓을 수 있어도 직접 파일을 열거나 결과를 기억하거나 다음 행동을 결정하지는 못합니다. 그 빈틈을 메우는 것이 하네스입니다.

흥미로운 점은 이 단어가 처음부터 에이전트 용어는 아니었다는 것입니다. 원래는 소프트웨어 테스팅의 test harness, 즉 테스트 대상을 격리해 입력을 주입하고 출력을 수집하는 고정 장치에서 왔습니다. 이후 EleutherAI의 lm-evaluation-harness 같은 평가 하네스 로 넘어왔는데, 여기서 핵심 통찰이 하나 나옵니다. "모델 성능은 종종 사소한 구현 디테일에 의해 좌우된다"는 것입니다. 즉 모델 점수가 모델만의 속성이 아니라 측정 장치의 속성이기도 하다는 인식입니다. 그리고 지금의 에이전트 하네스 로 오면서 역할이 뒤집힙니다. 평가 하네스가 모델을 제약 했다면, 에이전트 하네스는 모델에게 손발을 부여 합니다. 같은 단어인데 구속에서 권능으로 의미가 이동한 셈입니다.

실제로 결과가 바뀐다

동일한 모델에 어떤 하네스를 채웠는지에 따라 벤치마크 값이 변한다는 연구가 실제로 존재합니다. The harness & model relationship

이것은 단순한 인상론이 아니라 수치가 뒷받침합니다. 가장 직접적인 사례는 Qihoo360이 발표한 Harness-Bench 입니다. 106개의 현실적인 과제에서 같은 모델에 스캐폴딩만 바꿔 끼우면 점수가 거의 24점 가까이 움직였습니다. 8개 모델 백엔드 × 6개 하네스로 총 5,194개의 트래젝토리를 돌린 결과입니다. 여기서 HKUDS의 오픈소스인 NanoBot이 76.2점으로 가장 높았고, 최하위 하네스와는 23.8점 차이가 났습니다. 같은 과제, 같은 모델 풀, 다른 스캐폴딩이었습니다.

다른 연구들에서도 방향은 같습니다.

SWE-bench: 같은 베이스 모델이 하네스 설정에 따라 해결률 약 5%에서 30%+ 범위로 갈렸습니다.
OS Symphony: 제어 로직을 코드에서 자연어로 다시 쓴 것만으로 30.4% → 47.2% 로 올랐습니다(런타임 361분 → 41분, LLM 호출 1,200회 → 34회).
전이성: 한 모델에서 최적화한 하네스가 다른 다섯 모델로 옮겨가서 전부 개선시켰습니다. 재사용 가능한 자산은 모델이 아니라 하네스라는 것입니다.

도구 설명의 품질 하나만으로도 과제 완수율에 측정 가능한 차이가 났다는 보고도 있습니다. 디자인 시스템 MCP 매핑이든 PR 리뷰 도구든, 도구 스키마에 공을 들이는 일이 실제로 수치로 보상받는다는 이야기입니다.

그렇다면 하네스가 만능인가, 그것은 아니다

이 글에서 가장 하고 싶은 이야기가 여기에 있습니다. 하네스 효과가 크다는 주장은 맞지만, 누가 그 주장을 하는지 를 함께 봐야 합니다.

하네스 효과를 강조하는 출처들 상당수가 하네스 툴링을 판매하는 회사 입니다. MindStudio 같은 곳입니다. "모델보다 하네스가 중요하다"가 참이면 자사 제품 카테고리의 가치가 올라가기 때문에, 이쪽은 이해관계가 직접 걸려 있습니다. 반면 METR이나 Scale AI 같은 독립 평가기관 의 데이터를 보면 그림이 한결 신중해집니다. Scale AI의 SWE-Atlas는 일부 모델 패밀리에서 하네스 선택이 오차 범위 안이었고, METR 벤치마크는 Claude Code나 Codex가 기본 스캐폴드를 일관되게 능가하지 못하는 경우를 보였습니다. The Agent Harness — MongoDB 글이 이 양쪽을 잘 정리해 두었는데, 결론은 "하네스 가치는 과제 유형과 모델 능력에 따라 다르며, 두 효과 모두 실재하고 서로 다른 영역에서 지배적이다"입니다.

Swyx는 이 긴장을 아예 "Big Model vs Big Harness" 라고 이름 붙였습니다. 그리고 이 논쟁의 뿌리는 Rich Sutton의 Bitter Lesson입니다. 결국 범용 학습과 스케일이 인간이 짜 넣은 구조를 이긴다는 것입니다. 이 관점에서 보면 하네스 엔지니어링은 모델이 충분히 강해지면 폐기될 임시 비계에 불과합니다. 실제로 Manus는 모델이 진화하면서 하네스를 여러 차례 갈아엎었고(6개월에 다섯 번이라는 이야기도 있습니다), 매번 복잡도를 덜어냈습니다. 복잡한 도구 정의가 범용 셸 실행으로, "관리 에이전트"가 단순한 핸드오프로 바뀌었습니다. 모델이 강해질수록 하네스 간 점수 분산도 줄어듭니다. 약한 모델은 하네스에 크게 좌우되지만, 강한 모델은 그 차이를 흡수해 버립니다.

그래서 "하네스로 바벨탑을 쌓는다"는 현시점의 주장은 과한 이야기가 맞습니다. 단기 과대평가입니다.

그렇다면 왜 장기적으로는 중요해지는가

여기서 아마라의 법칙 후반부가 작동합니다. 핵심은 하네스를 두 부분으로 나누어 봐야 한다 는 것입니다.

하나는 보상성(compensatory) 스캐폴딩 입니다. 모델의 약점을 메우려고 덧붙인 플래너, 크리틱, 복잡한 도구 라우터입니다. 이것은 모델이 똑똑해지면 실제로 사라집니다. 모델이 추론으로 대체해 버리기 때문입니다. 앞서 본 "비계는 건물이 완성되면 철거된다"가 이 부분에 해당합니다.

다른 하나는 환원 불가능한 인프라 입니다. 컨텍스트 윈도우 관리, 상태 영속화, 도구 호출 실행, 검증 루프입니다. 이것은 추론 문제가 아니기 때문에 모델이 아무리 똑똑해져도 사라지지 않습니다. 어느 글의 표현을 빌리면, "모델이 자신의 진행 상황을 디스크에 저장하는 데 더 똑똑해질 필요는 없다. 상태를 지속시켜 줄 하네스가 필요할 뿐이다"라는 것입니다. 가장 유능한 모델조차 자기 컨텍스트 윈도우를 스스로 관리하거나, 도구 호출을 스스로 실행하거나, 자기 작업을 스스로 검증할 수는 없습니다.

게다가 더 흥미로운 반전이 있습니다. 하네스가 사라지는 것이 아니라 모델 안으로 융합되고 있다 는 점입니다. 요즘 모델은 특정 하네스를 루프에 넣은 채로 사후학습됩니다. Claude Code의 모델은 자신이 학습된 바로 그 하네스를 쓰도록 배웠습니다. 그래서 도구 구현을 바꾸면 이 긴밀한 결합 때문에 오히려 성능이 떨어질 수 있습니다. 하네스가 가치를 잃는 것이 아니라 모델 가중치 안으로 공진화(co-evolution)해 들어가는 것입니다.

종합하면 이런 그림입니다. 모델이 강해질수록 외부 스캐폴드는 얇아지고, 모델 간 점수 차이는 수렴하지만, 컨텍스트와 상태, 실행 같은 환원 불가능한 계층은 사라지지 않으며, 오히려 모델과 한 몸이 됩니다. "모델이 좋아지면 하네스는 무가치해진다"는 이 논쟁의 한쪽 극단을 단순화한 버전일 뿐입니다.

결론

하네스로 지금 당장 엔터프라이즈급 시스템을 완성하겠다는 주장은 단기 과대평가에 가깝습니다. 그 점에는 동의합니다. 다만 그 과한 이야기에 질려서 하네스 자체를 가볍게 보면, 그것이 바로 아마라의 법칙 후반부, 즉 장기 과소평가에 걸리는 셈입니다.

하네스는 얇아질 뿐 사라지지 않고, 오히려 모델과 융합되면서 더 본질적인 계층이 됩니다. 모델의 출력을 세계의 행동으로 바꾸는 중개라는 본질은 변하지 않기 때문입니다. 그래서 저는 하네스가 앞으로 개발자에게 익숙하고 중요한 기술이 될 것이라고 봅니다. 지금의 과열된 기대가 가라앉은 그 자리에서 말입니다.

통제되지 않은 대상에 고삐를 채우는 기술. 모델이 똑똑해질수록 고삐는 가늘어지겠지만, 고삐 그 자체가 없어지지는 않을 것입니다.

참고 자료

The harness & model relationship — Cobus Greyling (Harness-Bench 해설. 다만 저자가 Kore.ai 에반젤리스트라 편집자적 프레이밍은 감안할 것)
The Agent Harness — MongoDB (Big Model vs Big Harness 양쪽 데이터 정리. 가장 균형 잡힘)
Harness-Bench 논문 (arxiv 2605.27922) (Qihoo360, 프리프린트)
장시간 실행 앱을 위한 하네스 설계 — sehyunny

하네스

요즘 하네스가 유행입니다. 하네스로 바벨탑이라도 쌓을 기세로 많은 이야기가 오가고 있습니다.

그래서 하네스가 무엇인가

실제로 결과가 바뀐다

동일한 모델에 어떤 하네스를 채웠는지에 따라 벤치마크 값이 변한다는 연구가 실제로 존재합니다. The harness & model relationship

다른 연구들에서도 방향은 같습니다.

SWE-bench: 같은 베이스 모델이 하네스 설정에 따라 해결률 약 5%에서 30%+ 범위로 갈렸습니다.
OS Symphony: 제어 로직을 코드에서 자연어로 다시 쓴 것만으로 30.4% → 47.2% 로 올랐습니다(런타임 361분 → 41분, LLM 호출 1,200회 → 34회).
전이성: 한 모델에서 최적화한 하네스가 다른 다섯 모델로 옮겨가서 전부 개선시켰습니다. 재사용 가능한 자산은 모델이 아니라 하네스라는 것입니다.

그렇다면 하네스가 만능인가, 그것은 아니다

이 글에서 가장 하고 싶은 이야기가 여기에 있습니다. 하네스 효과가 크다는 주장은 맞지만, 누가 그 주장을 하는지 를 함께 봐야 합니다.

그래서 "하네스로 바벨탑을 쌓는다"는 현시점의 주장은 과한 이야기가 맞습니다. 단기 과대평가입니다.

그렇다면 왜 장기적으로는 중요해지는가

여기서 아마라의 법칙 후반부가 작동합니다. 핵심은 하네스를 두 부분으로 나누어 봐야 한다 는 것입니다.

결론

통제되지 않은 대상에 고삐를 채우는 기술. 모델이 똑똑해질수록 고삐는 가늘어지겠지만, 고삐 그 자체가 없어지지는 않을 것입니다.

참고 자료

The harness & model relationship — Cobus Greyling (Harness-Bench 해설. 다만 저자가 Kore.ai 에반젤리스트라 편집자적 프레이밍은 감안할 것)
The Agent Harness — MongoDB (Big Model vs Big Harness 양쪽 데이터 정리. 가장 균형 잡힘)
Harness-Bench 논문 (arxiv 2605.27922) (Qihoo360, 프리프린트)
장시간 실행 앱을 위한 하네스 설계 — sehyunny