하네스일까 모델일까, 코딩 에이전트의 실력은 어디에서 오는가

이번에 다룰 연구는 Harness or Model? Isolating the Harness Effect in Agentic Coding with a Contamination-Controlled Private Suite라는 제목으로 arXiv에 공개된 논문으로, 식별자는 arXiv:2609.11987입니다. 이 글의 주장은 한 문장으로 정리할 수 있는데, 같은 모델을 벤더 하네스와 중립 하네스에 얹어 오염이 차단된 비공개 과제로 겨뤄보니 평균 성공률에서는 어느 쪽도 이기지 못했다는 것입니다. 원문 논문은 제목 아래에 연결해 두었습니다.

안녕하세요, 패트릭입니다.

여러분이 새로운 코딩 모델이 나왔다는 소식을 들을 때, 가장 먼저 보는 숫자는 무엇인가요. 대개는 해결률 같은 정확도 숫자죠. 그런데 저는 요즘 그 숫자 아래에 깔린 질문이 더 신경 쓰입니다. 그 점수는 모델이 잘해서 나온 걸까요, 아니면 모델을 감싼 도구와 프롬프트와 실행 흐름, 즉 하네스가 잘해서 나온 걸까요. 솔직히 말하면 현장에서는 두 번째 가능성을 자주 잊습니다. 벤더가 자기 모델에 맞춰 만든 하네스가 당연히 더 잘 맞을 거라고 넘겨짚기 때문이죠. 제가 이 논문을 집어 든 이유도 바로 그 지점입니다. 막연한 믿음을 실험으로 갈라보겠다는 시도였기 때문입니다.

벤더 하네스가 이길 거라는 믿음부터 꺼내 보죠

다들 한 번쯤은 이런 경험을 해보셨을 겁니다. 같은 모델인데 누구 손에서 돌리느냐에 따라 결과가 완전히 달라지는 경우요. 코딩 에이전트에서는 그 손에 해당하는 것이 바로 하네스입니다. 하네스는 채팅 모델을 자율적인 소프트웨어 엔지니어로 바꾸는 껍데기인데, 어떤 도구를 주고, 어떤 프롬프트로 감싸고, 어떤 순서로 생각하고 실행하게 만드느냐가 전부 포함됩니다. 그래서 벤더들은 자기 모델에 맞게 하네스를 다듬고, 사용자들은 벤더 조합이 더 많은 과제를 풀 거라고 기대합니다. 자연스러운 기대죠. 자기 집 열쇠는 자기 집 문에 가장 잘 맞는 법이니까요.

그런데 여기서 재미있는 질문이 생깁니다. 그 기대는 검증된 적이 있을까요. 대부분의 공개 벤치마크는 모델과 하네스가 한 묶음으로 보고됩니다. 누가 점수를 올렸는지, 엔진이 좋아서인지 차체가 좋아서인지 알 수 없는 구조인 셈입니다. 게다가 한 번 공개된 과제는 학습 데이터에 스며들 수 있어서, 점수가 실력인지 암기인지도 헷갈립니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 무엇이 점수를 만드는지를 모르면 다음 선택을 할 수 없기 때문입니다. 새 모델을 살 것인가, 하네스를 갈아탈 것인가, 아니면 둘 다 그대로 두고 실행 조건을 손볼 것인가. 이 논문은 그 갈림길에서 하네스라는 변수 하나만 떼어내 보겠다고 선언합니다.

하네스라는 말은 도대체 무엇을 가리킬까요

하네스라는 단어는 자주 쓰이지만, 막상 뜯어보면 꽤 넓은 개념입니다. 이 연구가 말하는 하네스에는 도구를 정의하는 방식, 프롬프트를 짜는 방식, 그리고 에이전트가 멈추고 이어가는 방식을 정하는 제어 흐름이 모두 들어갑니다. 파일을 읽는 도구가 몇 개인지, 터미널 명령을 어떻게 감싸는지, 실패했을 때 다시 시도하는 루프가 어떻게 생겼는지가 전부 하네스의 영역이죠. 모델이 두뇌라면 하네스는 손과 발, 그리고 작업 수첩을 합친 것이라고 할 수 있는데, 두뇌가 같아도 손발이 다르면 일하는 방식이 달라집니다.

생각해 보면 사람도 비슷하게 일합니다. 같은 실력의 개발자라도 어떤 사람에게는 터미널과 에디터와 테스트 러너가 잘 갖춰진 환경이 주어지고, 어떤 사람에게는 최소한의 도구만 주어지죠. 전자가 더 빨리 일을 끝낼 가능성이 크지만, 그 차이가 정확히 어디에서 오는지는 따져봐야 합니다. 도구의 종류 때문일 수도 있고, 중간에 끼어드는 안내 문구 때문일 수도 있고, 단순히 더 오래 시도하게 허용했기 때문일 수도 있습니다. 그래서 이 논문이 던진 질문은 생각보다 날카롭습니다. 하네스를 바꿨을 때 성적 차이가 난다면, 그건 하네스의 설계가 좋아서일까요, 아니면 그냥 더 많이 시도하거나 더 오래 돌렸기 때문일까요. 저는 이 질문이 마음에 들었습니다. 숫자를 쪼개기 전에 무엇을 비교하는지부터 분명히 했기 때문입니다.

오염을 막기 위해 문제를 비공개로 돌린 이유

이 연구에서 제가 가장 흥미롭게 본 부분은 과제장을 만든 방식입니다. 연구팀은 256개 과제로 이루어진 비공개 문제 풀을 준비했는데, 저장소 기반 과제와 기준일 이후에 등장한 contest 과제를 함께 담았습니다. 과제는 공개하지 않고, 채점은 격리된 oracle이 맡습니다. 실행 환경과 채점 환경을 분리한 것이죠. 이렇게까지 하는 이유는 오염 때문입니다. 과제가 한 번이라도 공개되면 그 다음부터는 모델이 과제를 풀어본 적이 있는지, 아니면 처음 보는지를 알 수 없습니다. 외워서 맞힌 건지 풀어서 맞힌 건지 구분이 안 되는 셈이죠.

문제는 그다음입니다. 공개 벤치마크에서 하네스 A가 하네스 B를 이겼다는 결과가 나왔다고 칩시다. 그런데 하네스 A가 쓰는 모델이 그 과제를 학습 때 이미 봤다면 어떨까요. 그 승리는 하네스의 승리가 아니라 기억력의 승리일 수 있습니다. 특히 벤더 하네스와 벤더 모델의 조합에서는 이런 의심이 따라다닙니다. 자기 과제를 자기가 채점하는 것처럼 보일 수도 있기 때문입니다. 그래서 연구팀은 과제를 비공개로 묶고 채점자를 따로 두는 길을 택했습니다. 저는 여기서 멈칫했습니다. 과제를 감춘다는 건 재현성을 어렵게 만드는 선택이기도 하니까요. 남들이 같은 과제로 다시 돌려볼 수 없으니 검증의 문이 좁아집니다. 그 대가로 얻는 것은 오염에 대한 통제입니다. 이 교환을 받아들일 만한 가치가 있는지는 실험의 나머지 설계를 보고 판단해야 합니다.

같은 80개 과제를 두 하네스에 똑같이 얹는 법

실험 설계는 겉으로 보면 단순합니다. 실제로는 그렇지 않습니다. 연구팀은 80개 과제를 골라 claude-opus-4-8 위에서는 claude-agent-sdk와 deepagents를 겨루게 하고, gpt-5.5 위에서는 openai-codex SDK와 deepagents를 겨루게 했습니다. 곁가지로는 gemini-3.5-flash와 deepseek-v3.2를 쓰는 셀도 두었습니다. 같은 과제, 같은 모델, 다른 하네스라는 구조죠. 계획된 실행은 모두 800번이었고, 그 가운데 792번이 격리된 oracle의 채점을 받았습니다. 여덟 번이 빠진 이유까지 숫자에 포함해 보고한 점은 좋았습니다. 실행이 많은 연구일수록 빠진 실행을 어떻게 처리했는지가 해석을 바꾸기 때문입니다.

저는 이 숫자보다 그 뒤의 조건이 더 중요하다고 봅니다. 같은 과제라는 말은 쉬워 보이지만, 실제로는 실행 시간의 상한, 중단 규칙, 도구의 허용 범위까지 같아야 비교가 됩니다. 예를 들어 한쪽 하네스가 더 오래 돌도록 허용됐다면, 그건 하네스 설계의 차이가 아니라 예산의 차이가 됩니다. 연구팀은 이런 부분을 맞추려고 orchestrator를 직접 만들어 두 하네스를 같은 틀 안에서 돌렸다고 설명합니다. 물론 완벽한 통제는 어렵습니다. 하네스마다 기본으로 쓰는 시도 횟수나 멈춤 조건이 다르기 때문이죠. 그래서 이 실험을 읽을 때는 평균 숫자만 보지 말고, 뒤에서 다룰 시간 초과와 비용 이야기도 함께 봐야 합니다. 평균은 설계의 결과이자 예산의 결과이기도 하니까요.

평균에서는 아무도 이기지 못한 숫자들

이제 숫자를 보죠. claude-opus-4-8 위에서의 대결은 claude-agent-sdk 쪽이 48.8%, deepagents 쪽이 50.0%였습니다. 차이는 마이너스 1.25퍼센트포인트인데, 과제 단위 부트스트랩으로 구한 95% 구간이 마이너스 10.0에서 플러스 7.5까지 벌어집니다. 구간이 0을 넉넉히 포함하니 평균적인 하네스 우위를 가려내지 못했다는 해석이 됩니다. gpt-5.5 쪽도 비슷합니다. openai-codex SDK가 55.6%, deepagents가 54.4%로 플러스 1.25퍼센트포인트 차이였고, 95% 구간은 마이너스 4.4에서 플러스 6.9였습니다. 역시 평균의 차이를 확정하지 못했습니다.

표면적으로 보면 김빠지는 결과입니다. 벤더 하네스가 이길 거라는 기대가 있었는데, 평균에서는 동점에 가깝게 나왔으니까요. 하지만 저는 이 동점이 꽤 값지다고 봅니다. 이유가 두 가지 있습니다. 하나는 비교의 틀을 오염 통제 아래에 두었다는 점이고, 다른 하나는 불확실성을 구간으로 솔직히 보여줬다는 점입니다. 80개 과제에서 1퍼센트포인트 남짓한 차이는 과제 몇 개만 바뀌어도 뒤집힐 수 있습니다. 구간이 10퍼센트포인트 넘게 벌어진다는 건 그만큼 과제별 편차가 크다는 뜻이죠. 다시 말하면 평균 한 줄로 하네스의 우열을 말하기에는 과제의 성격이 너무 다르다는 신호입니다. 그렇다면 다음 질문은 자연스럽게 이렇게 이어집니다. 평균이 같다면, 과제 유형별로도 같았을까요.

평균이 가린 갈라짐이 과제 성격에 따라 드러나다

여기서 이야기가 조금 미끄러워집니다. 그래서 조심해서 읽을 필요가 있습니다. Opus 4.8 조건에서 61개 저장소 과제만 따로 보면 벤더 하네스가 9.0퍼센트포인트 뒤졌고, 19개 contest 과제만 보면 오히려 23.7퍼센트포인트 앞섰습니다. 라벨 순열 검정에서 p값은 0.003으로 보고됐습니다. 숫자만 보면 꽤 아픈 갈라짐이죠. 저장소에서는 중립 하네스가, contest에서는 벤더 하네스가 잘했다는 이야기니까요. 그런데 연구팀 스스로 이 분석을 사후적 partition이라고 밝히고 있으며, 재현이 필요하다고 선을 긋습니다. 저는 이 태도가 옳다고 봅니다.

왜냐하면 과제를 둘로 가른 기준을 결과를 보고 나서 정했다면, 갈라짐이 우연히 커 보일 수 있기 때문입니다. 19개라는 contest 과제 수는 작고, 작은 표본에서는 몇 개만 뒤집혀도 격차가 크게 출렁입니다. p값이 작다고 해서 설계 단계에서 예언한 차이가 입증된 것과 같지는 않습니다. (참고로 이런 사후 분석의 함정은 저도 글을 쓸 때마다 조심하는 부분인데, 재밌는 패턴을 발견했을 때 그걸 처음부터 찾은 것처럼 말하고 싶은 유혹이 크기 때문입니다.) 그럼에도 이 갈라짐을 그냥 버릴 수는 없습니다. 저장소 과제와 contest 과제는 요구하는 능력이 다를 수 있기 때문입니다. 저장소 과제는 긴 맥락을 읽고 기존 코드를 고치는 일이 많고, contest 과제는 짧지만 빡빡한 추론을 요구하는 경우가 많죠. 하네스의 도구 구성이나 시도 전략이 과제 성격과 맞물릴 수 있다는 가설은 충분히 그럴듯합니다. 다만 가설과 입증은 다릅니다. 다음 연구에서 같은 갈라짐을 미리 등록한 분석으로 다시 본다면, 그때는 이야기가 달라질 겁니다.

시간 초과로 멈춘 실행이 이미 답을 갖고 있었다면

이 논문에서 개인적으로 인상 깊었던 점은, 맞혔는지와 끝마쳤는지를 분리해서 본 대목입니다. 벽시계 상한에 걸려 취소된 81번의 실행 가운데 22번은 이미 통과하는 패치를 만들어둔 상태였습니다. 답은 있었는데 제출하지 못한 셈이죠. 실행이 멈춘 이유는 틀려서가 아니라 시간이 다 됐거나 중단 규칙에 걸렸기 때문입니다. correctness와 completion이 갈라지는 순간입니다. 일종의 타임아웃 앞에서 답안지를 들고 서 있다가 종이 울린 상황이라고 할까요.

이 차이는 생각보다 중요합니다. 우리가 평소에 보는 해결률은 정답 여부와 완주 여부를 한 숫자에 섞어 놓습니다. 그런데 하네스마다 멈춤 조건이 다르면, 같은 실력의 모델도 한쪽에서는 시간 초과로 떨어지고 다른 쪽에서는 통과할 수 있습니다. 더 오래 돌게 허용한 하네스가 유리해지는 건 당연하죠. 그렇다면 하네스 비교에서 시간 상한을 어떻게 잡느냐는 단순한 운영 변수가 아니라 해석을 바꾸는 설계 변수입니다. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 저희가 새로운 에이전트를 볼 때도 정확도 숫자만 보지는 않습니다. 같은 정확도라도 중간에 멈추는 방식이 다르면 운영에서 드는 손이 완전히 달라지기 때문입니다. 통과한 패치를 들고도 제출하지 못한 실행이 다섯 번 중 한 번꼴이라면, 그건 모델의 문제가 아니라 멈춤과 제출 흐름의 문제에 가깝습니다. 이 대목은 하네스를 고를 때 성공률 그래프 아래에 있는 시간 정책을 반드시 같이 보라는 조언으로 읽힙니다.

풀어낸 문제 하나당 얼마가 들었을까

좋은 건 알겠는데, 이걸 실제로 돌리면 얼마가 들까요. 이 논문은 비용 이야기도 피하지 않습니다. 연구팀은 턴 단위 사용량을 동결된 정가로 다시 계산해서 풀어낸 과제 하나당 비용을 비교했습니다. 결과는 Opus 4.8 조건에서 중립 하네스가 1.3배에서 1.6배 정도 더 들었고, GPT-5.5 조건에서는 1.2배 정도 더 들었다는 것입니다. 성공률이 비슷했는데 비용이 더 들었다면, 같은 답을 더 비싸게 산 셈이니 운영 관점에서는 벤더 하네스 쪽이 유리해 보입니다. 그런데 여기에도 꼬리표가 붙습니다. 58개 실행의 사용량 기록이 빠져 있어서, 청구 기준으로 순서를 확정할 수는 없다는 것입니다. 청구 순서가 뒤집힐 수 있는 범위가 0.7에서 2.3까지 벌어진다고 보고합니다.

저는 이 솔직함이 고맙지만, 동시에 이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. 동결된 정가로 다시 계산한 비용은 비교를 위한 잣대이지 실제 청구서가 아니기 때문입니다. 실제 요금은 할인, 캐시 적중, 모델별 단가 변경에 따라 달라집니다. 더구나 기록이 빠진 58건이 어떤 쪽에 쏠려 있는지에 따라 결론이 달라질 수 있습니다. 비싼 실행의 기록이 더 많이 빠졌다면 격차는 과장됐을 수 있고, 반대라면 축소됐을 수 있죠. 그럼에도 방향 자체는 눈여겨볼 만합니다. 성공률이 동점이어도 토큰을 얼마나 쓰고, 몇 번을 되돌아가고, 언제 멈추느냐에 따라 지갑에서 나가는 돈은 달라집니다. 하네스 선택은 정확도 대결이 아니라 정확도와 비용과 시간을 함께 보는 선택이라는 것, 이 논문의 비용 대목은 그 상식을 숫자로 붙잡아줍니다.

8월 원고의 숫자 오류를 직접 바로잡은 대목

이 논문에는 숫자를 다루는 태도에 대한 이야기도 들어 있습니다. 이번 원고는 2026년 8월 원고의 개정판인데, 당시 비용 수치가 저자들의 자체 측정 도구에 있던 사용량 의미 해석의 결함 위에 서 있었다고 밝힙니다. 쉽게 말하면 무엇을 셌는지를 잘못 셌다는 고백입니다. 턴마다 얼마를 썼는지를 재는 자 자체에 문제가 있었다는 것이죠. 그래서 이번에는 원시 사용량을 가져와 동결된 정가로 다시 계산하는 방식으로 고쳤습니다. 저는 이런 대목을 보면 신뢰가 조금 올라갑니다. 틀린 숫자를 슬쩍 고치는 대신 어디가 틀렸는지를 말해주기 때문입니다.

물론 고백했다고 해서 모든 문제가 풀리는 건 아닙니다. 앞서 말했듯이 기록이 빠진 실행이 남아 있고, 청구 기준의 순서는 여전히 열려 있습니다. 하지만 적어도 무엇이 고쳐졌고 무엇이 아직 안 고쳐졌는지가 드러났습니다. 연구팀은 orchestrator와 채점 oracle, 재분석 코드와 집계 결과를 공개하면서도 과제 자체는 비공개로 유지합니다. 코드를 열되 문제는 닫아두는 선택이죠. 오염 통제와 재현 가능성 사이에서 가능한 절충이라고 할 수 있습니다. 남들은 같은 과제로 돌려볼 수 없지만, 돌리는 틀과 채점하는 잣수는 들여다볼 수 있으니까요. 완벽한 검증은 아니지만, 다음 사람이 이어서 물을 수 있는 발판은 됩니다. 그렇다면 그 발판 위에서 무엇을 물어야 할까요. 그 이야기는 마지막에 다시 다루겠습니다.

그래서 다음에 무엇을 물어야 할까요

이제 처음으로 돌아가 보죠. 벤더 하네스가 당연히 이긴다는 믿음은 이 실험에서 확인되지 않았습니다. 평균에서는 두 번의 대결 모두 동점에 가까웠고, 과제 성격별 갈라짐은 흥미롭지만 사후 분석이라 확정이 필요하고, 시간 초과로 답을 들고도 떨어진 실행이 있었고, 비용은 한쪽이 더 들었지만 청구서의 순서는 아직 열려 있습니다. 한 문장으로 줄이면 이렇게 됩니다. 하네스의 효과는 평균 한 줄이 아니라 과제와 시간과 비용이 얽힌 자리에서 드러난다는 것입니다.

제가 앞으로 보고 싶은 것은 세 가지입니다. 첫째, 과제 유형별 갈라짐을 사전에 등록한 분석으로 다시 보는 일입니다. 저장소 61개와 contest 19개라는 이번 구성을 그대로 두는 대신, 더 많은 contest 과제를 모아 미리 가설을 걸고 돌려보는 것이죠. 갈라짐이 반복된다면 하네스 설계에 대한 조언이 구체화될 수 있습니다. 어떤 과제에서는 탐색을 넓게, 어떤 과제에서는 추론을 깊게 가져가라는 식으로 말이죠. 둘째, 시간 상한을 변수로 두는 실험입니다. 상한을 짧게, 중간, 길게 바꿨을 때 22대 81이라는 비율이 어떻게 움직이는지, 그리고 하네스 순위가 바뀌는지 보고 싶습니다. 셋째, 비용의 빈칸을 메우는 일입니다. 58건의 빠진 기록이 어디에서 생겼는지, 청구 기준으로 다시 계산하면 배율이 어떻게 되는지를 확인하는 것이죠.

저희가 새로운 에이전트 구조를 볼 때도 성공률 표만 보고 고개를 끄덕이지는 않습니다. 무엇과 겨뤘는지, 무엇이 통제됐는지, 무엇이 아직 열려 있는지를 함께 봅니다. 이 논문은 그 기준에서 꽤 정직한 편입니다. 이긴 쪽을 선언하는 대신 비긴 평균을 내놓고, 갈라짐은 갈라짐대로, 빈칸은 빈칸대로 보여줬기 때문입니다. 그래서 이 글을 읽는 분들께도 같은 질문을 남기고 싶습니다. 여러분이 쓰는 하네스는 어떤 과제에서 강하고, 언제 멈추고, 풀어낸 하나당 얼마를 쓰나요. 그 세 가지를 모르면 모델을 탓하기도, 하네스를 탓하기도 이릅니다. 다음 에이전트를 고를 때 성공률 옆에 시간과 비용 칸을 나란히 놓고 보는 것, 저는 그 습관부터가 이 논문이 남긴 수확이라고 봅니다.