Cursor에서 하네스를 만든 엔지니어는 모델 약점을 덮는 규칙마다 발동 로그를 달아 지울 때를 찾습니다 | DAKER 커뮤니티

유튜브 채널 AI Engineer가 10월 19일 공개한 18분 발표 「Smarter Models Killed the Harness. Here's What's Left」에서 Cursor의 에이전트 하네스를 오래 만들어 온 Jediah Katz는, 모델이 똑똑해지면서 하네스가 덧대던 코딩 요령은 모델 안으로 흡수됐고 이제 하네스에 남는 일은 인프라·권한·비용이라고 정리했습니다. 그가 근거로 든 UC Berkeley·Arena의 HarnessTax 연구에서는 같은 모델을 Claude Code·Codex CLI·Pi에 넣어도 SWE-bench Lite 성공률 차이가 평균 ±2% 안이었지만 비용은 최대 5배까지 벌어졌습니다. 에이전트로 해커톤 과제를 푸는 팀이 오늘 바로 할 일은 하나입니다. 모델 약점을 덮으려고 넣은 규칙마다 이름을 붙이고, 그 규칙이 실제로 작동할 때마다 로그를 남겨 더는 작동하지 않는 규칙을 지울 근거를 만드는 것입니다.

따뜻한 미색 종이 위에 신문지 질감과 망점으로 표현한 콜라주풍 생성 이미지. 가운데 나무 걸이에 신문지 띠로 된 가죽 마구가 걸려 있고, 가는 끈 여러 가닥은 찢긴 종이 조각이 되어 떨어져 나갑니다. 마구에는 초록 불이 켜진 작은 서버, 빨간 자물쇠, 동전 더미와 스톱워치가 단단히 매달려 있으며 오른쪽 위에 DAKER 공식 로고가 있습니다
설명용 생성 이미지입니다.

AI Engineer 하네스 발표는 무엇을 물었습니까

발표의 질문은 「에이전트 하네스는 죽었는가」입니다. Jediah Katz는 2025년 초 Cursor에 합류해 에이전트 하네스를 가장 오래 맡아 온 엔지니어라고 자신을 소개했고, 지금은 SpaceX에서 일한다고 밝혔습니다. 영상 설명란도 그를 Cursor에서 가장 오래 하네스를 만든 엔지니어로 소개합니다.

그가 말하는 하네스는 모델을 둘러싸고 모델이 무엇을 보고 어떤 도구를 쓰며 어디서 실행되는지를 정하는 소프트웨어입니다. 발표에서는 이를 두 층으로 나눴습니다. 첫째는 런타임 층으로, 에이전트의 핵심 반복 실행이 어디서 돌아가고 작업 상태를 어떻게 저장해 다시 이어 가는지를 맡습니다. 둘째는 컨텍스트·오케스트레이션 층으로, 언제 어떤 모델을 부르고 그 모델이 어떤 프롬프트·도구·메모리 요약을 보는지를 정합니다. 그는 런타임 층을 전통적인 소프트웨어 공학에 가깝다고 했고, 컨텍스트 층은 아직 정해진 방법이 없는 실험 영역이라고 설명했습니다.

직함의 변화도 짚었습니다. 2023년 초에는 프롬프트 엔지니어, 2025년 중반에는 컨텍스트 엔지니어가 주목받았고, 올해 초에야 하네스 엔지니어링이라는 이름이 업계에 자리 잡았다는 설명입니다.

하네스를 바꿔도 코딩 점수가 거의 같았다는 두 연구

발표자가 「하네스가 코딩 지능을 더해 주지 않는다」는 근거로 든 첫 연구는 UC Berkeley Sky Lab과 Arena가 9월 16일 공개한 HarnessTax입니다. 연구진은 모델 7개와 하네스 3개(Claude Code, Codex CLI, Pi)를 조합한 21쌍을 SWE-bench Lite와 Terminal-Bench 2.0에서 각각 무작위 30문항씩, 문항마다 세 번 돌렸습니다. 결과는 성공률보다 비용에서 크게 달랐습니다. 하네스에 따른 성공률 차이는 평균적으로 SWE-bench Lite에서 ±2%, Terminal-Bench 2.0에서 약 ±5% 안이었지만, 같은 모델이 비슷한 성공률을 내면서 비용은 최대 5배까지 차이가 났습니다.

구체적인 수치도 공개돼 있습니다. Claude Fable 5는 SWE-bench Lite에서 Claude Code로 97.8%, Codex와 Pi로 각각 96.7%를 풀었지만 시도당 비용은 Claude Code가 1.33달러, Pi가 0.67달러였습니다. 평균 턴 수는 15.3과 15.4로 거의 같았습니다. 공통 모델을 기준으로 보면 Claude Code의 비용은 SWE-bench Lite에서 Pi의 약 2.0배, Codex의 약 1.6배였습니다. 연구진은 읽기·쓰기·수정·bash 네 가지 도구만 주는 Pi가 두 벤치마크 모두에서 비용 대비 성공률의 최전선에 올랐다고 밝혔습니다.

두 번째 연구는 Apple과 EPFL 연구진이 9월 30일 공개한 논문 「How Much of a Harness Does a Strong Agent Need for Autonomous ML Engineering?」입니다. 이 논문은 Kaggle 대회 과제로 만든 MLE-bench에서 같은 모델·같은 시간 예산을 주면, 여러 에이전트를 조율하는 공개 MLE 하네스들이 최소한의 하네스로 돌린 코딩 에이전트 한 세션보다 낫지 않았다고 보고합니다. GLM 5.2 기준으로 최소 하네스 에이전트의 메달 획득률은 62.5%, 비교한 외부 하네스 중 가장 좋은 쪽은 47.1%였습니다. 논문은 가장 큰 효과가 채팅 인터페이스 대신 셸과 파일 시스템을 준 데서 나왔다고 정리합니다. 데이터 분석 대회를 에이전트로 풀어 보려는 DACON·DAKER 참가자에게 바로 닿는 결과입니다.

두 연구 모두 한계를 밝힙니다. HarnessTax는 공개 벤치마크 두 개만 시험했고, 모델이 학습 중에 그 문제를 봤을 가능성을 언급합니다. Apple·EPFL 논문도 결론을 현재 MLE 벤치마크에 한정합니다.

Cursor가 하네스에서 코딩 보조 규칙을 지운 이유

발표자는 Cursor도 하네스를 덜어 냈다고 말했습니다. 예전에는 최신 모델이 파일 수정 적용을 잘하지 못해 수정 적용만 맡는 작은 모델을 따로 두었고, 코드베이스를 어떻게 탐색하고 작업을 어떻게 검증할지 같은 코딩 전용 지시문도 많이 넣었다고 합니다. 모델이 이런 요령을 스스로 익히자 이 장치들을 지웠다는 설명입니다.

오늘날 정교한 하네스는 더 이상 코딩 지능을 더해 주지 않습니다. 코드베이스 탐색, 오래 붙잡고 일하기, 테스트로 결과 확인하기 같은 요령을 모델이 이미 흡수했습니다.

그는 이 과정을 데이터 플라이휠로 설명했습니다. 하네스가 더 어려운 코딩 과제를 풀 수 있게 만들면, 더 많은 사용자가 에이전트로 그 과제를 시도하고, 그만큼 많은 코딩 데이터가 모델 연구소로 모입니다. 결국 모델이 그 요령을 직접 익히고, 하네스는 그 과제를 위해 넣었던 장치를 지울 수 있게 됩니다. 발표자는 이것이 「하네스는 죽었다」는 말이 나온 배경이라고 봤습니다. 다만 그가 내린 결론은 하네스가 필요 없다는 것이 아니었습니다.

모델이 흡수하지 못하는 세 가지: 인프라, 신뢰, 효율

발표자는 하네스 가운데 모델이 대신할 수 없는 부분을 세 가지로 꼽았습니다. 첫째는 인프라와 런타임입니다. 에이전트가 한 과제에 쓰는 시간이 몇 분에서 몇 시간, 며칠로 늘어나면서, 잠자기 모드로 들어갈 수 있는 개인 노트북에서는 이런 작업을 안정적으로 돌릴 수 없다고 설명했습니다.

둘째는 신뢰와 보안입니다. 발표자는 셸 하나와 모든 비밀 키만 준 단순한 하네스도 코딩 평가는 잘 풀 수 있다고 인정하면서도, 모든 API 키를 한 파일에 넣어 모델에게 주는 방식은 회사 보안 책임자가 받아들이지 않을 것이라고 말했습니다. 에이전트와 사람마다 권한을 좁히고, 아침에 일어나 보니 되돌리기 어려운 동작이 실행됐거나 1만 달러짜리 API 요금이 청구된 상황을 막는 안전장치가 필요하다는 설명입니다.

셋째는 효율입니다. 발표자는 앞의 두 연구가 점수 차이는 작았지만 과제당 비용 차이는 컸다고 짚었습니다. HarnessTax에서는 이 차이가 수치로 확인됩니다. 연구진은 Claude Code가 첫 호출에 보내는 평균 초기 컨텍스트가 Pi의 10배를 넘는다고 보고했습니다. 발표자는 최근 한 달 동안 Grok Bot 하네스의 캐시 적중률, 토큰 효율, 모델 조합을 조정해 품질 저하 없이 비용과 속도를 크게 줄였다고 말했지만, 구체적인 수치는 발표에서 공개하지 않았습니다.

하네스가 다시 늘어나는 곳: 코딩 밖의 일

흥미로운 대목은 Cursor에서는 지시문과 안전장치를 걷어 냈지만, Grok Bot에서는 다시 넣고 있다는 이야기입니다. 발표자는 Grok Bot을 한 번의 대화가 아니라 오래 살아 있는 조정 에이전트가 여러 작업 에이전트에게 일을 나눠 주는 구조로 설명했습니다. 슬라이드 만들기와 여행 예약 같은 웹 작업, 사용자에게 진행 상황을 과하지 않게 알리는 소통, 실행할지 먼저 물어볼지의 판단, 메모리로 사용자의 작업 방식을 익히는 일은 모델이 아직 완전히 익히지 못해 하네스가 메워야 한다는 설명입니다. Grok Bot의 최근 기능 변화는 DAKER 잡담의 Grok Bot 작업 속도 소식에서도 다뤘습니다.

그는 여러 에이전트를 묶는 사례도 들었습니다. 사내 채널에 버그가 올라오면 자동화가 먼저 분류하고, 클라우드 에이전트가 수정을 시도해 수정 전후 영상을 남기며, 배포가 시작되면 또 다른 에이전트가 운영 환경 문제를 지켜보는 흐름입니다. 발표자는 이를 여러 에이전트를 조율하는 상위 하네스라고 불렀습니다. 앞서 DAKER에 정리한 Factory 소프트웨어 팩토리 발표와도 이어지는 이야기입니다.

심(shim)을 기록해 지울 때를 찾는 방법

오늘 바로 가져갈 수 있는 부분은 발표 후반의 운영 방식입니다. 발표자는 모델의 나쁜 습관을 임시로 막는 결정적 규칙을 심(shim)이라고 불렀습니다. 예를 들어 Grok Bot이 사용자에게 충분히 빨리 답하지 않으면 「사용자가 기다리고 있습니다」라고 살짝 재촉하는 장치가 여기에 해당합니다. 그는 이런 장치를 다음 모델이 나올 때까지 기다리기보다 지금 고치는 편을 택하되, 모든 심을 한곳에서 관리하고 모델이 심을 발동시킬 때마다 로그를 남긴다고 설명했습니다. 그리고 대시보드를 지켜보는 봇이 더는 발동하지 않는 심을 찾으면 그 심을 지우는 PR을 올린다고 했습니다.

제품이 다시 모델보다 빠르게 움직이는 시기에 들어섰고, 하네스는 정리되기 전에 더 복잡해질 것입니다. 그래서 기능을 쉽게 넣고 쉽게 뺄 수 있게 설계해야 합니다.

같은 맥락에서 그는 에이전트용 기본 구성 요소를 강조했습니다. Slack 메시지, PR의 CI 실패, 특정 시각처럼 에이전트를 깨워야 하는 사건마다 연동을 따로 만들지 않고, 사건을 구독하는 하나의 틀과 하나의 도구로 처리한다는 사례입니다. 기능을 더하거나 뺄 때 에이전트가 보는 도구 목록이 복잡해지지 않는다는 장점이 있습니다.

해커톤 규모의 에이전트라면 대시보드나 봇까지 필요하지 않습니다. 아래처럼 규칙 목록 하나와 로그 한 줄이면 충분합니다.

기록할 항목예시지울 때 보는 기준
규칙 이름답변 형식 재확인, 빈 출력 재시도이름만 보고 무엇을 막는지 알 수 있어야 합니다
덮는 약점모델이 제출 형식을 자주 틀림새 모델에서 같은 약점이 재현되는지 확인합니다
발동 기록날짜, 과제 번호, 사용 모델최근 실험에서 한 번도 발동하지 않았다면 제거 후보입니다
제거 실험 결과규칙을 끈 상태의 성공률과 비용같은 과제 묶음에서 성공률이 유지되면 지웁니다

오늘 에이전트 해커톤 팀이 할 일

  1. 시스템 프롬프트와 코드에 들어간 보정 문장·재시도·강제 검사 규칙을 모두 찾아 이름을 붙이고, 규칙이 작동할 때마다 이름과 과제 번호를 로그에 한 줄씩 남깁니다.
  2. 고정한 과제 묶음으로 성공 여부와 함께 과제당 토큰 수와 비용을 기록합니다. HarnessTax처럼 같은 모델에서도 하네스 설정에 따라 비용이 크게 달라질 수 있기 때문입니다. 비교 평가를 먼저 만드는 방법은 DAKER에 정리한 Braintrust 비교 평가 글을 참고하실 수 있습니다.
  3. 에이전트에게 모든 API 키를 한 파일로 넘기지 말고, 과제에 필요한 키와 권한만 따로 줍니다. 실행 위치와 비밀값 관리는 OpenHands 샌드박스 비교 글에서 자세히 다뤘습니다.
  4. 몇 시간 이상 걸리는 학습·실험 작업은 잠들 수 있는 노트북 대신 서버나 클라우드 작업 환경에서 돌리고, 중간 상태를 저장해 끊겨도 이어 갈 수 있게 합니다.

확인한 것과 확인하지 못한 것

HarnessTax의 실험 설정과 수치, Apple·EPFL 논문의 메달 획득률은 각 연구의 공개 문서에서 확인했습니다. 반면 발표자가 말한 Cursor 인수와 SpaceX 합류, Grok Bot 하네스의 비용·속도 개선, 심을 지우는 봇 운영은 발표자의 설명이며 별도 수치나 문서로 확인하지 못했습니다. 발표자는 Apple·EPFL 연구에서도 과제당 비용 차이가 컸다고 말했지만, 공개 초록에서는 비용 수치를 찾지 못했습니다. 6개월 안에 에이전트 작업의 90%가 노트북 밖에서 돌아갈 것이라는 말은 발표자의 예측입니다.

출처