모델은 그대로 두고 SWE-bench 20%→50%, 릴리안 웽이 꺼낸 '하네스'

웽이 글에서 든 사례 가운데 하나가 다윈 괴델 머신(DGM)이라는 2025년 연구입니다. SWE-bench Verified는 실제 오픈소스 저장소에 올라온 버그 보고를 모델이 직접 고치게 하고, 고친 코드가 테스트를 통과하는지로 채점하는 시험입니다. DGM은 바탕 모델을 Claude 3.5 Sonnet 하나로 고정해 두고, 코딩 에이전트가 자기 평가 기록을 읽은 뒤 자기 하네스 코드를 고쳐 새 버전을 만드는 일을 되풀이하게 했습니다. 모델은 한 줄도 바뀌지 않았는데 SWE-bench Verified 점수는 20%에서 50%로, 여러 언어의 코딩 문제를 모은 Polyglot 점수는 14.2%에서 30.7%로 올랐습니다.

하네스는 바탕 모델을 둘러싸고 실행을 조율하는 시스템입니다. 모델이 어떻게 생각하고 계획할지, 어떻게 도구를 부르고 행동할지, 맥락을 어떻게 받아들이고 관리할지, 산출물을 어디에 저장하고 결과를 어떻게 평가할지를 정합니다.— 릴리안 웽, 「Harness Engineering for Self-Improvement」

웽은 Claude Code, Codex, OpenCode, Cursor 같은 코딩 에이전트의 기본 구조가 이미 비슷한 모양으로 수렴했다고 적었습니다. 파일을 찾고 읽고 고치는 도구, 셸 명령, git, 웹 검색, 하위 에이전트를 띄우는 도구가 모두 갖춰진 루프입니다. 그는 하네스에서 최적화하는 대상이 지시 프롬프트에서 구조화된 맥락으로, 다시 워크플로와 하네스 코드, 하네스를 고치는 최적화 코드로 옮겨 왔다고 정리했습니다.

앤트로픽이 먼저 기록한 실패 네 가지

하네스가 왜 필요한지는 앤트로픽이 2025년 11월 26일 엔지니어링 블로그에 공개한 실험에 잘 나와 있습니다. 저스틴 영(Justin Young)이 쓴 이 글에서 앤트로픽은 당시 자사 최상위 코딩 모델인 Opus 4.5를 자사 에이전트 도구 모음(Claude Agent SDK)에 얹어 여러 컨텍스트 창에 걸쳐 루프로 돌렸습니다. 그리고 「claude.ai를 복제해 줘」 같은 높은 수준의 지시만 주면 이 조합으로도 제품 수준의 웹앱을 끝내지 못한다고 적었습니다.

원인은 세션이 끊길 때마다 기억이 사라지는 데 있었습니다. 앤트로픽은 이를 교대할 때마다 전 근무조의 일을 전혀 모르는 엔지니어가 들어오는 소프트웨어 프로젝트에 빗댔습니다. 대화를 요약해 압축하는 기능(compaction)이 있어도 다음 세션에 완전히 깨끗한 지시가 넘어가지는 않았습니다. 저도 그날 스레드에서 이 구조를 교대 근무로 소개했습니다.

claude.ai 복제 실험에서 기능 목록은 200개가 넘었고, 처음에는 모두 「실패」로 표시됐습니다. 코딩 에이전트는 각 항목의 passes 필드만 바꿀 수 있었고, 지시문에는 「테스트를 지우거나 고치는 것은 기능이 빠지거나 버그가 생길 수 있으니 용납할 수 없다」는 강한 문장을 넣었습니다. 목록을 마크다운 대신 JSON으로 둔 이유도 적혀 있습니다. 모델이 JSON 파일을 함부로 고치거나 덮어쓰는 일이 더 적었기 때문입니다.

마지막 실패는 검증이었습니다. Claude는 코드를 고치고 단위 테스트나 curl 명령까지 돌리면서도 기능이 처음부터 끝까지 실제로 작동하는지는 확인하지 않았습니다. 브라우저 자동화 도구로 사람이 쓰듯 시험하라고 명시하자, 코드만 봐서는 보이지 않던 버그를 찾아 고쳤습니다. 브라우저 기본 경고창은 이 도구로 보이지 않아, 경고창에 기대는 기능은 버그가 더 많았다는 한계도 함께 적혔습니다.

4개월 뒤에는 일하는 쪽과 채점하는 쪽을 나눴습니다

2026년 3월 24일 앤트로픽 Labs 팀의 프리트비 라자세카란(Prithvi Rajasekaran)은 후속 글을 냈습니다. 그는 앞선 하네스가 한계에 부딪힌 이유를 두 가지로 봤습니다. 하나는 컨텍스트 창이 차 간다고 느낀 모델이 일을 서둘러 마무리하는 「컨텍스트 불안」으로, Sonnet 4.5에서 특히 심해 대화를 요약하는 대신 창을 비우고 인수인계 파일만 넘기는 리셋이 필요했습니다. 다른 하나는 자기 평가였습니다. 에이전트는 자기가 만든 결과물을 평가하라고 하면, 사람 눈에 평범한 수준이어도 자신 있게 칭찬했습니다.

그래서 생성적 적대 신경망(GAN)에서 착안해 만드는 에이전트와 채점하는 에이전트를 떼어 냈습니다. 평가자를 회의적으로 길들이는 편이 생성자에게 자기 작업을 비판하게 만드는 것보다 훨씬 쉬웠다는 것이 그의 설명입니다. 풀스택 앱에서는 기획자·생성자·평가자 셋을 두고, 생성자와 평가자가 코드를 쓰기 전에 이번 작업 단위의 완료 기준을 합의하는 「스프린트 계약」을 맺게 했습니다. 레벨 편집기를 다룬 세 번째 스프린트의 계약에만 기준이 27개 들어갔습니다.

실험의 지시는 레벨 편집기와 스프라이트 편집기, 개체 동작, 시험 플레이 모드를 갖춘 2D 레트로 게임 제작 도구를 만들라는 한 문장이었습니다. 하네스 쪽에서는 기획자가 이 문장을 기능 16개짜리 사양서로 늘렸고, 같은 지시를 받은 두 방식의 결과는 이렇게 갈렸습니다.

비용은 22배, 시간은 18배 들었습니다. 평가자를 이 수준으로 만드는 데도 손이 많이 갔습니다. 라자세카란은 기본 상태의 Claude를 형편없는 QA 담당자라고 적었습니다. 초기 실행에서 평가자는 진짜 문제를 찾아 놓고도 별일 아니라고 스스로 납득한 뒤 통과시켰고, 겉만 훑고 넘어가는 일도 잦았습니다. 그는 평가자의 기록을 읽고 자기 판단과 갈리는 대목을 찾아 지시문을 고치는 일을 여러 번 되풀이했습니다.

모델이 좋아지자 하네스를 덜어 냈습니다

라자세카란은 첫 하네스의 결과가 고무적이었지만 무겁고 느리고 비쌌다며, 성능을 떨어뜨리지 않고 부품을 덜어 내는 작업에 들어갔습니다. 그가 출발점으로 삼은 원칙은 이렇습니다.

하네스의 모든 부품은 모델이 혼자서는 못 하는 일에 대한 가정을 담고 있습니다. 그 가정은 틀렸을 수도 있고, 모델이 좋아지면 금방 낡을 수도 있습니다.— 프리트비 라자세카란, 앤트로픽 Labs

실제로 덜어 낸 부품이 둘 있었습니다. Opus 4.5는 컨텍스트 불안을 거의 보이지 않아 리셋을 없애고 한 세션으로 끝까지 돌렸고, Opus 4.6이 나온 뒤에는 작업을 잘게 쪼개던 스프린트 구조를 없애고 평가도 마지막에 한 번만 했습니다. 기획자와 평가자는 남겼습니다. 기획자 없이는 생성자가 범위를 좁게 잡아 기능이 빈약한 앱을 만들었고, 평가자는 작업이 모델 혼자 안정적으로 해내는 범위 밖에 있을 때만 비용만큼의 값을 했습니다.

덜어 낸 하네스에는 웹 오디오 API로 브라우저에서 돌아가는 완전한 음악 제작 프로그램(DAW)을 만들라는 한 문장을 줬습니다. 생성자는 스프린트로 쪼개지 않고도 2시간 넘게 흐트러지지 않고 작업했고, 단계별 기록은 이렇습니다.

세 번의 QA를 합친 비용은 10.39달러로 전체의 8% 남짓입니다. 이 8%가 1차 QA에서 타임라인의 클립을 끌어 옮길 수 없고 악기 조작 패널과 이펙트 편집 화면이 아예 없다는 점을, 2차 QA에서 녹음 버튼이 실제로는 마이크를 잡지 않는다는 점을 잡아냈습니다. 비용의 91%는 생성자가 코드를 쓰는 데 들었습니다.

라자세카란은 모델이 좋아질수록 어떤 문제는 다음 모델을 기다리면 저절로 풀리겠지만, 모델이 강해질수록 모델 혼자서는 못 하는 일을 해내는 하네스를 만들 여지도 커진다고 적었습니다. 그의 결론은 쓸 만한 하네스 조합의 가짓수가 모델이 좋아져도 줄지 않고, 찾아야 할 조합이 바뀔 뿐이라는 것입니다.

「모델이 하네스를 삼킨다」는 반론

반대편의 주장도 구체적입니다. 킬패트릭은 6월 11일 공개된 세쿼이아 캐피털 대담에서 2년 전만 해도 모델은 가중치의 집합이었지만, 지금은 도구 호출과 검색, 코드 실행까지 가중치를 둘러싸고 뻗어 나가는 시스템 전체를 모델이라고 부른다고 말했습니다. 바깥의 뼈대가 모델보다 몇 걸음 앞서 나가면, 모델이 그 뼈대를 삼켜 자기 기능으로 만든다는 설명입니다.

YouTube 영상 · 누르면 재생

다들 하네스를 만들어야 하고 하네스에서 남보다 앞설 수 있다고 하지만, 지금 우리가 생각하는 하네스의 모습으로는 12개월 뒤에 그 말이 맞지 않을 수 있습니다. 모델이 그 상당 부분을 소화할 것이고, 앞서는 이점은 다른 데서 나올 겁니다.— 로건 킬패트릭, 구글 딥마인드

그는 특정 모델 회사의 하네스에 묶이지 않으려고 자체 하네스를 만드는 회사가 많다는 질문에, 다른 하네스를 쓰지 못하는 모델은 일반 모델이라고 하기 어렵고 시간이 지나면 모델이 어떤 하네스든 쓰게 될 것이라고 답했습니다. 여러 모델이 다양한 하네스에 얼마나 잘 적응하는지 재는 「하네스 벤치」가 필요하다는 제안도 덧붙였습니다. 오픈AI 코덱스 앱을 이끄는 앤드루 암브로시노도 6월 28일 공개된 레니 팟캐스트에서 2월에 낸 코덱스 앱이 지난해 11월에 나왔다면 실패했을 것이고, 그 사이 달라진 것은 모델뿐이었다고 말했습니다.

앤트로픽의 기록은 두 주장을 모두 뒷받침합니다. Opus 4.5와 4.6이 나올 때마다 리셋과 스프린트가 필요 없어졌다는 점은 킬패트릭의 말과 같은 방향입니다. 반면 같은 모델로 단독 실행은 고장 난 게임을, 하네스는 플레이할 수 있는 게임을 냈다는 점은 웽과 라자세카란의 주장과 맞습니다. 웽도 하네스 개선의 상당수가 언젠가 모델 행동으로 흡수될 수 있다고 인정했습니다. 다만 프롬프트 요령이 모델이 좋아지며 덜 중요해졌어도 목표와 제약, 맥락, 평가 기준을 정해 주는 일은 사라지지 않았듯, 외부 맥락과 도구를 잇는 접점은 남을 것이라고 봤습니다.

가장 단순한 구조부터

앤트로픽은 2024년 12월 19일 에릭 슐런츠와 배리 장이 쓴 「효과적인 에이전트 만들기」에서 이미 같은 원칙을 적었습니다. LLM 애플리케이션은 가장 단순한 해법에서 시작해 필요할 때만 복잡도를 올리고, 경우에 따라서는 에이전트 시스템을 아예 만들지 않는 편이 낫다는 것입니다. 에이전트 시스템은 지연 시간과 비용을 더 나은 성능과 맞바꾸기 때문입니다. 라자세카란도 하네스를 줄이는 과정에서 이 문장을 다시 인용했습니다.

이 글은 미리 정한 코드 경로로 LLM과 도구를 엮는 워크플로와, 모델이 과정과 도구 사용을 스스로 정하는 에이전트를 구분합니다. 잘 정의된 일에는 예측 가능한 워크플로가, 유연한 판단이 필요한 일에는 에이전트가 맞고, 많은 애플리케이션은 검색과 예시를 붙인 LLM 호출 한 번을 다듬는 것으로 충분하다고 적었습니다.

라자세카란의 생성자·평가자 구조는 이 가운데 마지막 패턴과 같은 모양을 몇 시간짜리 작업으로 키운 것입니다. 2024년 글은 에이전트 시스템이 지연과 비용을 성능과 맞바꾼다고만 적었고, 그 값은 2026년 3월 글의 표에서 단독 실행 9달러 대 하네스 200달러라는 숫자로 처음 나왔습니다.

사람에게 남는 일

하네스가 일을 나누고 검증까지 맡으면 사람에게 남는 일도 달라집니다. Claude Code를 만드는 Thariq는 7월 3일 Fable 5 사용법을 정리한 글에서 Fable을 두고, 작업의 질이 사용자가 모르는 것을 얼마나 밝혀 주느냐에서 막히는 첫 모델이라고 적었습니다. 앤트로픽 하네스의 기능 목록과 스프린트 계약도 같은 문제를 다룹니다. 무엇이 끝난 상태인지를 파일로 미리 적어 두지 않으면, 모델은 모르는 부분을 추측으로 채우고 스스로 통과를 선언합니다. 앤트로픽은 그 목록을 쓰는 일도 초기화 에이전트와 기획자 에이전트에 맡겼고, 라자세카란이 직접 한 일은 평가자의 기록을 읽고 자기 판단과 어긋나는 대목을 찾아 지시문을 고치는 것이었습니다.

라자세카란이 글 끝에 남긴 조언은 세 가지입니다. 실제 문제에서 모델의 실행 기록을 읽고 원하는 결과가 나오게 조정할 것, 복잡한 작업은 나눠 전문화된 에이전트에 맡길 여지가 있다는 것, 새 모델이 나오면 하네스를 다시 살펴 더는 쓸모없는 부품을 덜어 내고 전에는 불가능했던 부품을 더할 것입니다. 킬패트릭이 말한 12개월은 내년 6월에 끝납니다. 그때 Claude Code와 Codex의 루프에서 무엇이 빠지고 무엇이 남았는지가 이 논쟁의 첫 성적표가 됩니다.

읽어 주셔서 고맙습니다.

초이 드림