더 똑똑한 모델이 에이전트 하네스를 바꿨다: 이제 남은 역할은 무엇인가

URL: https://www.youtube.com/watch?v=7Y4sbZgBdnc 날짜: 2026-10-19 채널: aiDotEngineer

📌 핵심 질문 / 핵심 논점

핵심 질문은 “모델이 똑똑해지면서 에이전트 하네스(agent harness)는 죽었는가?”다. 코딩 능력의 빈틈을 메우던 프롬프트·가드레일·작업 절차는 모델이 내재화하면서 실제로 사라지고 있다. 그러나 하네스는 더 어려운 과업의 개척, 장시간 실행을 위한 런타임과 인프라, 신뢰·보안, 비용·속도 효율을 책임지므로 죽지 않았다. 하네스가 모델을 보완하고, 그 하네스가 더 넓은 과업을 가능하게 하며, 그 과정에서 생긴 데이터가 다음 모델을 더 똑똑하게 만드는 순환이 핵심이다.

• 2023년의 프롬프트 엔지니어링에서 2025년의 컨텍스트 엔지니어링, 2026년 초의 하네스 엔지니어링으로 업계의 관심사가 이동했다.
• 최근 평가 연구에서 하네스 종류는 최신 모델의 코딩 점수를 크게 바꾸지 않았지만, 과업당 비용은 유의미하게 바꿨다.
• 코딩 이후에는 지식 노동, 장기 자율 업무, 소프트웨어 개발 생애주기 전체가 새로운 프런티어가 된다.

하네스는 모델의 눈과 손이며, 모델을 실행 환경·도구·외부 서비스에 연결하는 제품·시스템 계층이다. 모델이 이미 배운 능력을 다시 가르치는 하네스는 줄어들지만, 모델이 아직 해결하지 못한 새 과업과 신뢰할 수 있는 운영을 가능케 하는 하네스는 더 중요해진다.

1. 코딩 모델의 성숙이 하네스의 역할을 바꾸다

1.1. 프롬프트에서 하네스로: 하네스의 구성과 발전

1. 업계의 초점은 모델 주변의 작업 설계로 이동했다.

   1. 프롬프트 엔지니어(prompt engineer): 2023년 초 가장 주목받던 역할은 모델에 효과적인 지시문을 작성하는 일이었다.
   2. 컨텍스트 엔지니어(context engineer): 2025년 중반에는 모델이 실행되는 순간 가장 적절한 맥락을 프로그램으로 구성하는 일이 강조됐다.
   3. 하네스 엔지니어링(harness engineering): 2026년 초에는 모델을 감싸고 일의 흐름 전체를 관리하는 시스템을 설계하는 일이 별도 개념으로 자리 잡았다. 발표자와 팀은 이 명칭이 생기기 전부터 관련 작업을 해 왔다.

2. 하네스는 모델의 눈과 손처럼 작동한다.

   1. 사용자와 실행 환경 연결: 사용자는 앱을 통해 하네스에 접속하고, 하네스는 모델을 컴퓨터 및 MCP 같은 제3자 서비스에 연결한다.
   2. 런타임(runtime): 핵심 에이전트 루프가 어디서 실행되는지, 상태를 어떻게 저장해 중단된 작업을 재개할지 결정한다. 전통적인 소프트웨어 엔지니어링에 가까운 기반 계층이다.
   3. 컨텍스트·오케스트레이션(context and orchestration): 어떤 모델을 언제 부르고 무엇을 보여줄지 정한다. 프롬프트·도구뿐 아니라 메모리 압축(memory compaction)과 모델 행동을 조정하는 여러 기법이 포함된다. 발표자가 주로 맡아 온 영역이다.

3. 발표는 가벼운 자기풍자와 함께 출발한다.

   1. 발표자는 자신을 Jediah(자막 표기는 Jedidiah)라고 소개하고, 2025년 초 Cursor에 합류해 에이전트 하네스를 오래 담당했으며 Cursor 인수의 일부로 SpaceX에 왔다고 말했다.
   2. 첫 대목의 원고를 “더 자연스럽고 유려하게 다듬은 버전”이라고 소개하는 엉뚱한 자막을 읽어 청중이 여전히 농담을 감지하는지 확인한다고 했다. “아니, 진짜 이야기를 하겠다”며 본론으로 들어갔다.

1.2. ‘피크 하네스’ 이후 드러난 변화

1. 복잡한 하네스가 한때 에이전트 능력의 정점처럼 보였다.

   1. 새해 무렵 Cursor는 Grind Swarm이라는 장기 실행형 멀티모달 하네스로 브라우저를 처음부터 만드는 데모를 공개했다.
   2. 여러 에이전트와 여러 컴퓨터를 오케스트레이션한 값비싼 실험이었으며, 데모를 실행하는 과정에서 Cursor 서비스가 한두 차례 중단되기도 했다.

2. 모델이 발전하면서 코딩용 보정 장치가 제거되기 시작했다.

   1. Anthropic의 Tariq는 Claude Code의 시스템 프롬프트 상당 부분을 없앴다고 이야기했다. YC의 Garry Tan은 하네스가 퇴조하고 스킬만 중요해질 수 있다고 봤다.
   2. 발표자와 동료 Stefan도 Cursor의 모델 지능 부족을 메우던 가드레일을 제거했다고 썼다. 과거에는 작은 모델이 코드 파일 수정만 맡거나, 코드베이스 탐색·작업 지속·검증 방법을 코딩 전용 지시로 가르쳤다.
   3. 이런 제거 현상 때문에 “더 똑똑한 모델이 하네스를 죽였다”는 주장이 나왔다. 발표자 역시 코딩 지능을 직접 보태던 정교한 하네스가 더는 필요하지 않다는 점에는 동의한다.

3. 단순한 도구 환경만으로 충분한지 평가 연구가 질문을 구체화했다.

   1. 발표자는 셸과 모든 비밀 키만 모델에 주는 단순 하네스를 상정하고, 이것이 정교한 하네스만큼 코딩 평가를 잘할 것인지 청중에게 물었다. 청중 다수는 그렇지 않다고 반응했다.
   2. UC Berkeley 연구는 7개 최신 프런티어 모델을 Pi, Codex, Claude Code를 포함한 여러 하네스에서 평가했다. 특히 더 최신·고성능인 모델에서는 SWE-bench Lite 점수가 하네스에 따라 유의미하게 달라지지 않았다.
   3. Apple과 EPFL의 별도 연구에서도 전용 머신러닝 엔지니어링(MLE) 하네스가 MLE-bench 점수를 크게 높이지 않았다.
   4. 이 결과는 하네스가 무가치하다는 뜻이 아니다. 평가 점수와 별개로 과업당 비용 차이는 두 연구 모두에서 유의미했다.

1.3. 모델과 하네스가 서로를 밀어 올리는 데이터 플라이휠

1. 모델은 과거 하네스가 가르친 코딩 습관을 자체 능력으로 흡수한다.

   1. 코드베이스를 탐색하고, /goal 같은 기능으로 긴 작업을 지속하고, 테스트로 결과를 확인하는 능력이 대표적이다.
   2. 이 능력이 모델 자체에 들어오면, 같은 절차를 프롬프트·가드레일로 반복해서 강제할 필요가 줄어든다. 하네스는 모델이 배운 행동을 보정하던 코드를 지울 수 있다.

2. 하네스가 학습 데이터를 만들어 하네스 자체의 일부를 낡게 만든다.

   1. 하네스는 이전에는 어려웠던 코딩 작업을 현실적으로 시도할 수 있게 한다. 그 결과 더 많은 사용자가 에이전트로 어려운 과업을 생산적으로 수행한다.
   2. 사용 경험을 통해 더 많은 코딩 데이터가 AI 연구소로 공유되고, 연구소는 모델을 훈련해 해당 작업 능력을 모델 안에 내재화한다.
   3. 모델이 충분히 능숙해지면 최초에 그 작업을 가능하게 하려고 추가했던 하네스 요소를 제거할 수 있다. 이것이 발표자가 부른 **데이터 플라이휠(data flywheel)**이다.

3. 하네스의 사라짐은 역할의 종료가 아니라 다음 과업으로의 이동이다.

   1. 코딩 능력이 상품화(commoditized)되면, 하네스는 모델이 아직 풀지 못한 새로운 과업의 경계를 열어 다음 플라이휠을 시작한다.
   2. 새 경계는 코딩 밖의 업무일 수도 있고, 순수 코딩을 넘어서는 소프트웨어 엔지니어의 직무 전체일 수도 있다. 경력이 높아질수록 직접 코딩하는 비중은 낮아지고 다른 책임이 커진다.

2. 하네스가 여는 새로운 과업의 프런티어

2.1. GrokBot: 단발성 대화를 넘어서는 자율 동료

1. GrokBot은 코딩뿐 아니라 여러 지식 노동을 맡는 자율 동료를 지향한다.

   1. 발표자는 GrokBot 사용 여부를 청중에게 물었고, 코딩에 국한되지 않는 작업을 맡기는 새로운 제품 범주라고 소개하며 사용을 권했다.
   2. 하네스는 한 번의 채팅이 아니라 오래 살아 있는 조정자(coordinator) 봇을 중심으로 작동한다. 조정자 봇이 여러 작업자(worker) 에이전트를 조직해 장기 업무를 수행한다.
   3. 이를 고객과 직접 이야기하고 전략을 책임지는 고성능 변호사와, 실제 조사·문서 작업을 나눠 맡는 법률 보조원(paralegal) 팀에 비유했다.

2. 새 업무에서는 하네스에 프롬프트와 가드레일을 다시 보강해야 한다.

   1. Cursor의 코딩 하네스에서는 모델이 똑똑해지면서 프롬프트와 가드레일을 제거했지만, GrokBot에서는 새 도메인의 미해결 문제가 많아 관련 기능을 다시 추가하고 있다.
   2. 하네스가 하는 일은 모델을 대체하는 것이 아니다. 모델의 능력과 함께 작동하면서 아직 모델이 완전히 해결하지 못한 과업을 실행 가능한 범위로 가져온다.

2.2. 일반 지식 노동에서 필요한 제품 능력

1. 웹사이트의 핵심 업무 흐름을 안정적으로 처리해야 한다.

   1. 슬라이드 덱(slide deck) 만들기와 여행 예약은 여러 단계와 외부 시스템을 거치는 대표적인 웹 업무 흐름이다.
   2. 이러한 작업은 코드를 생성하는 것만으로 끝나지 않는다. 목표를 완료할 때까지 시스템을 조작하고, 사용자의 의도를 유지하며, 결과를 확인해야 한다.

2. 사용자와의 소통은 빈도와 타이밍을 함께 최적화해야 한다.

   1. 자율 동료는 자신이 무엇을 하고 있는지 사용자에게 계속 알려야 한다.
   2. 진행 상황을 알리는 일이 너무 잦아 사용자를 압도해서도 안 된다. 유용한 자율성은 일의 수행뿐 아니라 적절한 보고 방식을 요구한다.

3. 행동할지 물어볼지, 그리고 사용자의 방식에 맞출지 판단해야 한다.

   1. 이메일로 동료에게 연락하는 일은 유용하지만 위험할 수도 있는 행동이다. 에이전트가 실제로 행동하기를 사용자는 바라면서도, 사용자가 의도한 방식으로만 수행되기를 원한다.
   2. 행동과 확인 요청 사이의 경계를 조정하는 것이 중요하다. 무조건 행동하거나 매번 승인을 요구하는 방식으로는 의도에 맞는 동료가 될 수 없다.
   3. 메모리(memory)를 통해 시간이 지날수록 사용자가 일하는 방식을 학습하는 것도 핵심 과제다.

4. 코딩 에이전트에서 보이던 어려움이 이제 보편적 업무 문제로 커졌다.

   1. 코딩 에이전트를 깊게 사용한 사람은 소통, 승인, 장기 메모리와 같은 문제가 낯설지 않다.
   2. 그러나 GrokBot에서는 모두가 필요로 하는 일반 업무 능력이므로 중요성이 훨씬 커진다. 현재는 하네스가 이 작업들을 가능하게 하는 핵심 요소다.

2.3. 소프트웨어 팩토리: 개발 생애주기 전체를 오케스트레이션하다

1. 소프트웨어 팩토리는 여러 에이전트가 개발 전 과정을 함께 수행하는 비전이다.

   1. 한 에이전트가 코드를 작성하는 수준을 넘어, 여러 에이전트가 전체 소프트웨어 개발 생애주기(software development life cycle)를 조정한다.
   2. 발표자는 이 비전은 아직 해결된 문제가 아니지만, 업계 전반에서 하네스를 중심으로 많은 혁신이 진행 중이라고 말했다.

2. 버그 보고부터 배포 후 감시까지 이어지는 ‘메타 하네스’ 사례가 있다.

   1. 내부 채널에 버그가 보고되면 자동화가 즉시 이슈를 분류(triage)한다. 이어 클라우드 에이전트를 실행해 수정안을 만들게 한다.
   2. 수정 에이전트는 자체 도구로 수정 전후 영상을 만들어 문제 해결을 증명한다. 수정이 병합되고 배포를 시작하면 Rollouts 제품이 다른 에이전트를 시작한다.
   3. 후속 에이전트는 프로덕션에서 이상이 발생하는지 살핀다. 분류·수정·검증·배포 후 관찰을 이어 붙인 시스템은 여러 에이전트를 지휘하는 **메타 하네스(meta-harness)**로 볼 수 있다.

3. 모델이 흡수할 수 없는 하네스의 운영 가치

3.1. 장기 자율 업무를 지탱하는 인프라와 런타임

1. 에이전트의 작업 시간은 분에서 시간·일 단위로 늘고 있다.

   1. 지난 1년 이상 에이전트가 일반적인 업무를 처리하는 시간이 몇 분에서 몇 시간, 며칠, 그 이상으로 길어졌다.
   2. 장기 작업은 모델의 추론 능력만으로 해결되지 않는다. 실행 루프, 상태, 재개 가능성, 도구와 외부 시스템의 연결이 안정적으로 유지되어야 한다.

2. 자율 동료의 실행 환경은 개인 노트북에만 의존할 수 없다.

   1. 노트북은 잠자기 상태에 들어갈 수 있으므로 며칠간 이어지는 작업의 안정적인 기반이 되기 어렵다.
   2. 진정한 자율 동료를 만들려면 작업이 클라우드에서 계속 실행되어야 한다. 이러한 런타임·인프라는 모델 체크포인트가 좋아져도 사라지지 않는다.

3.2. 신뢰와 보안: 권한, 가드레일, 사용자 보호

1. 셸과 비밀 키를 전부 건네는 단순 하네스는 보안상 부적절할 수 있다.

   1. 셸과 모든 API 키 파일만 있어도 모델이 코딩 문제를 해결할 수는 있지만, 키 전체를 모델에 넘기고 싶은 사용자는 많지 않다.
   2. 이를 허용하더라도 회사의 보안 책임자가 문제를 제기할 것이다. 업무용 에이전트에는 능력뿐 아니라 무엇에 접근할 수 있는지에 관한 통제가 필요하다.

2. 권한을 사람·에이전트별로 제한하고 큰 피해를 예방해야 한다.

   1. 기업은 특정 에이전트와 특정 사용자에게 권한을 한정해야 한다.
   2. 개인도 어느 날 아침 돌이킬 수 없는 행동이나 10,000달러의 API 청구서를 마주하고 싶어 하지 않는다. 가드레일은 의도와 권한 범위를 넘는 행동을 방지한다.

3.3. 효율: 품질을 해치지 않으면서 비용과 속도를 개선

1. 평가 점수가 비슷해도 비용은 하네스에 따라 크게 달라진다.

   1. UC Berkeley 연구와 Apple·EPFL 연구는 하네스 선택이 특정 코딩·MLE 벤치마크 점수에 큰 영향을 주지 않을 수 있음을 보였다.
   2. 발표자는 두 연구 모두 과업당 비용(cost per task)에는 유의미한 차이가 있었다고 강조했다. 실사용에서는 같은 결과를 얼마나 효율적으로 얻는지가 중요하다.

2. GrokBot 하네스 최적화는 여러 운영 변수를 함께 조정했다.

   1. 발표자는 지난 한 달 동안 GrokBot 하네스의 효율을 개선하는 데 집중했다.
   2. 캐시 적중률(cache hit rate)을 높이고, 토큰 효율(token efficiency)을 개선하고, 어떤 모델을 조합해 쓸지(model mix) 조정했다.
   3. 이런 조정으로 품질 저하 없이 사용자 비용과 처리 속도를 크게 개선했다. 사용자가 이를 반겨 보람이 컸다고 말했다.

3. 에이전트 사용이 늘수록 효율적인 하네스의 가치도 커진다.

   1. 에이전트가 수행하는 작업량이 늘면 과업당 비용·속도 개선이 반복적으로 누적된다.
   2. 그러므로 하네스는 평가 점수를 올리는 장치가 아니더라도 제품의 사용 가능성과 운영 경제성을 좌우한다.

4. 다음 세대 하네스: 빠르게 바꾸고, 조합하고, 클라우드로 옮기다

4.1. 제품이 모델보다 앞서가며 하네스가 다시 복잡해진다

1. 데이터 플라이휠이 빨라지면서 제품 개발이 모델 개발보다 앞서게 됐다.

   1. 발표자는 지금 다시 제품이 모델보다 빠르게 움직이는 시대에 들어섰다고 진단했다.
   2. 그 결과 하네스는 정돈되기 전에 더 많은 기능이 추가되어 한동안 복잡해질 것이다.

2. 기능을 빠르게 출시하고 되돌릴 수 있도록 하네스를 설계해야 한다.

   1. 기능을 쉽게 추가할 수 있어야 할 뿐 아니라, 문제가 있거나 필요가 사라졌을 때 쉽게 제거할 수 있어야 한다.
   2. 하네스 내부 작동 방식을 사용자에게 덜 노출하는 제품이 GrokBot 등에서 나타나고 있다.
   3. 사용자에게 보여준 기능이나 동작은 사용자가 의존하게 된다는 Hyrum의 법칙(Hyrum’s Law)이 있다. 내부 세부사항을 적게 노출하면 변경 관리 부담을 줄여 반복 속도를 높일 수 있다.
   4. 대신 사용자는 진행 상황과 동작을 덜 들여다보게 되는 대가를 치른다. 가시성과 빠른 반복 사이의 절충이 필요하다.

4.2. 에이전트용 프리미티브와 관찰 가능한 임시 보정 장치

1. 프리미티브(primitives)는 기능을 조합하고 확장하는 기본 인터페이스다.

   1. 프리미티브를 사용하면 에이전트가 이해하는 구조를 복잡하게 만들지 않고 새 기능을 추가할 수 있다.
   2. 기능을 제거할 때도 코드베이스를 복잡하게 리팩터링하지 않아도 된다. 발표자는 이를 좋은 엔지니어링이라고 표현했다.

2. 구독(subscriptions)은 여러 이벤트를 하나의 인터페이스로 다루는 프리미티브다.

   1. 에이전트는 Slack에 새 글이 올라오거나, 관심 있는 PR의 CI가 실패하거나, 특정 시간이 되었을 때 깨어날 필요가 있다.
   2. 이벤트마다 별도 통합을 만들지 않고 하나의 프레임워크와 도구를 제공해 에이전트가 이벤트를 구독하도록 한다.

3. 모델 체크포인트를 기다리지 않고 임시 가드레일(shim)을 추적해 제거 시점을 찾는다.

   1. 결정론적 보정 장치는 모델의 좋지 않은 행동을 당장 보완한다. 예를 들어 GrokBot이 사용자에게 너무 늦게 답하면 “사용자가 기다리고 있다”고 살짝 재촉한다.
   2. 이런 보정은 해킹에 가깝지만, 다음 모델 업데이트까지 기다리기보다 지금 문제를 고치는 편을 택한다.
   3. 보정 장치를 중앙에서 shim으로 기록하고, 모델이 사용할 때마다 로그를 남긴다. 대시보드를 감시하는 봇은 특정 shim의 호출이 멈추면 그 shim을 정리할 수 있다는 PR을 제안한다.
   4. 이 구조는 보정 코드를 방치하지 않고, 모델이 스스로 그 행동을 잘하게 되었는지 관찰해 하네스를 정리하게 한다.

4.3. 에이전트 중심 추상화와 클라우드 실행

1. 하네스의 추상화 수준은 LLM 호출 조합에서 에이전트 조합으로 올라간다.

   1. 이전 세대 하네스는 여러 LLM 호출을 조합해 동작을 구성했다.
   2. GrokBot과 소프트웨어 팩토리 같은 새 하네스는 에이전트 자체를 핵심 구성 요소로 삼는다. 에이전트들이 일을 나누고 서로를 오케스트레이션한다.

2. 6개월 안에 에이전트 업무의 90%가 노트북 밖에서 실행될 것이라는 전망이다.

   1. 발표자는 자율 에이전트가 사용자가 원하는 방식으로 실제 함께 일하려면 클라우드·상시 실행 환경이 필요하다고 보며, 이 흐름이 이미 진행 중이라고 말했다.
   2. “6개월 안에 에이전트 작업의 90%가 노트북 밖에서 실행된다”는 수치는 관측된 결과가 아니라 발표자의 전망이다.

주요 발언 모음

“하네스는 모델의 눈과 손과 같다. 모델을 감싸고, 방향을 잡고, 세상과 연결한다.”

“멋진 하네스는 이제 코딩 지능을 더해 주지 않는다. 그 점은 사실이라고 생각한다.”

“하네스가 더 어려운 코딩 작업을 가능하게 하고, 더 많은 사용이 데이터를 만들며, 모델은 그 능력을 자체적으로 배운다.”

“GrokBot에서는 새로운 방식의 업무와 새로운 도메인 때문에 프롬프트와 가드레일을 다시 넣고 있다.”

“에이전트가 더 많은 일을 할수록, 가장 효율적인 하네스를 갖는 가치도 더 커진다.”

“어제의 하네스는 죽었을지 모르지만, 내일의 에이전트 하네스여 영원하라.”

핵심 데이터 & 수치

• 2023년 초 / 2025년 중반 / 2026년 초: 프롬프트 엔지니어 → 컨텍스트 엔지니어 → 하네스 엔지니어링으로 업계 용어와 관심이 이동했다.
• UC Berkeley 연구: 7개 프런티어 모델을 Pi, Codex, Claude Code 등 여러 하네스에서 비교했으며, 최신 모델의 SWE-bench Lite 점수는 하네스별로 크게 달라지지 않았다.
• Apple·EPFL 연구: 전용 MLE 하네스가 MLE-bench 점수를 크게 바꾸지 않았지만, 과업당 비용은 두 연구에서 유의미한 차이를 보였다.
• Grind Swarm: 브라우저를 처음부터 만드는 데 여러 에이전트와 여러 기계를 쓰는 장기 실행 멀티모달 하네스였고, 실행 비용이 높아 데모 중 Cursor가 한두 차례 중단되기도 했다.
• 10,000달러: 위험한 에이전트 동작뿐 아니라 사용자가 원치 않는 API 비용 청구도 가드레일이 막아야 할 사례로 언급됐다.
• 한 달: 발표자가 GrokBot 하네스의 효율 최적화에 집중한 기간이다. 캐시 적중률·토큰 효율·모델 조합을 조정해 품질 저하 없이 비용과 속도를 개선했다.
• 6개월 안에 90%: 에이전트 작업 대부분이 노트북 밖에서 실행될 것이라는 발표자의 전망이다.

결론 및 시사점

1. 코딩 보조 하네스와 에이전트 제품 하네스를 구분해야 한다. 코드 탐색·테스트처럼 모델이 이미 익힌 코딩 행동을 반복 지시하던 층은 줄어들 수 있지만, 장기·다중 단계·비코딩 업무를 가능하게 하는 하네스는 확장된다.
2. 하네스와 모델을 서로 대체재로 보면 안 된다. 하네스는 새 작업을 가능하게 해 사용과 데이터를 늘리고, 모델은 그 능력을 흡수해 다음 프런티어를 연다.
3. 제품 품질은 능력뿐 아니라 실행 안정성·권한 통제·사용자 의도 준수에 달려 있다. 클라우드 런타임, 상태 복구, 최소 권한, 승인·가드레일은 자율성이 커질수록 중요해진다.
4. 평가 점수와 운영 효율을 따로 측정해야 한다. 하네스별 점수가 비슷해도 캐시·토큰·모델 라우팅은 비용과 속도를 크게 바꿀 수 있다.
5. 하네스를 모듈형 프리미티브로 만들고 임시 보정 장치를 관찰 가능하게 관리해야 한다. 기능을 빠르게 넣고 빼며, 모델이 더 똑똑해져 필요 없어진 shim을 근거와 함께 정리할 수 있다.
6. 앞으로의 에이전트 하네스는 개별 LLM 호출보다 에이전트와 이벤트 중심으로 설계될 가능성이 높다. 조정자·작업자, 구독 이벤트, 클라우드 실행이 장기 자율 업무의 기반이 된다.

핵심 요약 (20줄)

1. 에이전트 하네스는 모델의 눈과 손처럼 작동하며, 모델을 실행 환경과 도구, 외부 서비스에 연결한다.

2. 업계의 초점은 2023년 프롬프트 엔지니어링에서 2025년 컨텍스트 엔지니어링을 거쳐 2026년 하네스 엔지니어링으로 이동했다.

3. 하네스는 실행 위치와 상태 복구를 맡는 런타임, 모델 호출·맥락·행동을 관리하는 컨텍스트·오케스트레이션 계층으로 나뉜다.

4. Cursor의 Grind Swarm은 여러 에이전트와 컴퓨터를 동원해 브라우저를 처음부터 만들었지만 실행 비용이 컸고 서비스 중단도 일으켰다.

5. 모델이 코드 탐색, 장시간 작업 지속, 테스트 검증을 직접 익히면서 이를 대신 가르치던 코딩 가드레일은 줄어들고 있다.

6. UC Berkeley의 7개 모델 비교와 Apple·EPFL의 MLE 평가에서는 전용 하네스가 최신 모델의 벤치마크 점수를 크게 바꾸지 않았다.

7. 두 연구에서는 점수가 비슷해도 과업당 비용이 달라 하네스 효율이 여전히 중요한 운영 변수로 드러났다.

8. 하네스가 더 어려운 작업을 가능하게 하고 사용 데이터를 늘리면, 모델이 그 작업 능력을 흡수해 하네스가 일부 보정 장치를 지우는 플라이휠이 생긴다.

9. 코딩 능력이 모델에 상품화될수록 하네스는 지식 노동과 소프트웨어 개발 생애주기 전체 같은 다음 프런티어를 연다.

10. GrokBot은 단발 채팅 대신 장기 조정자 봇이 여러 작업자 에이전트를 지휘하는 자율 동료를 지향한다.

11. 조정자와 작업자의 관계는 전략을 맡는 변호사와 조사·문서 업무를 분담하는 법률 보조원 팀에 비유된다.

12. 슬라이드 작성과 여행 예약은 다단계 웹 업무의 사례이며, 에이전트는 소통 빈도와 행동·승인 경계를 적절히 조절해야 한다.

13. 동료에게 이메일을 보내는 위험한 행동은 사용자의 의도에 맞춰야 하며, 메모리로 시간이 지날수록 사용자의 업무 방식을 배워야 한다.

14. 소프트웨어 팩토리는 버그 분류, 클라우드 수정 에이전트, 전후 영상 검증, 배포 후 감시를 잇는 메타 하네스 형태로 구현될 수 있다.

15. 장기 작업은 분에서 시간·일 단위로 늘어났으며, 잠드는 노트북 대신 상태를 유지하는 클라우드 런타임이 필요하다.

16. 에이전트별 최소 권한과 가드레일은 비밀 키 노출, 돌이킬 수 없는 행동, 10,000달러 규모의 API 비용을 방지한다.

17. 캐시 적중률, 토큰 효율, 모델 조합을 조정하면 품질을 유지하면서 에이전트의 비용과 속도를 개선할 수 있다.

18. 제품이 모델보다 빠르게 발전하는 동안 하네스는 복잡해질 수 있으므로 기능을 쉽게 출시하고 철회할 수 있어야 한다.

19. 이벤트 구독은 Slack 글, CI 실패, 특정 시간 같은 신호를 하나의 인터페이스로 처리하고, 로그 기반 shim 정리는 낡은 보정 장치를 제거한다.

20. 발표자는 6개월 안에 에이전트 업무의 90%가 노트북 밖에서 실행될 것으로 전망하며, 어제의 하네스가 바뀌어도 내일의 하네스는 계속 중요하다고 결론 내린다.