Cursor·xAI 엔지니어 제다이아 카츠 강연: '에이전트 하네스는 죽었는가?'에 대한 아키텍처 해답

프롬프트 엔지니어에서 '하네스 엔지니어'로, 그리고 제기된 하네스 무용론

2023년 초 업계에서 가장 주목받던 직무가 '프롬프트 엔지니어(Prompt Engineer)'였다면, 2025년 중반에는 모델에 최적의 정보를 동적으로 조립해 주는 '컨텍스트 엔지니어(Context Engineer)'를 거쳐, 2026년 초부터는 모델의 눈과 손 역할을 하는 **에이전트 하네스(Agent Harness)**와 **하네스 엔지니어링(Harness Engineering)**이 핵심 화두로 자리 잡았습니다.

2026년 10월 19일 AI Engineer 공식 채널을 통해 공개된 강연(Is the Agent Harness Dead?)에서, 2025년 초부터 Cursor의 에이전트 하네스를 가장 오랫동안 개발해 왔고 인수 합류 이후 현재 SpaceX·xAI에서 그록봇(Grok Bot) 하네스를 만들고 있는 제다이아 카츠(Jediah Katz)는 최근 업계 일각에서 제기된 **"모델이 똑똑해지면서 에이전트 하네스는 죽었다"**는 주장을 실증 연구와 현장 데이터로 검증했습니다.

카츠는 에이전트 하네스를 두 계층으로 정의합니다.

• 런타임 계층(Runtime Layer): 코어 에이전트 루프가 어디에서 실행되고, 작업 재개를 위해 상태(State)를 어떻게 저장할지 제어하는 전통적 소프트웨어 공학 기반 계층입니다.
• 컨텍스트 및 오케스트레이션 계층(Context & Orchestration Layer): 언제 어떤 모델을 호출하고 어떤 프롬프트·도구·메모리 압축(Compaction) 기법을 적용해 에이전트 행동을 조향할지 다루는 영역입니다.

'피크 하네스(Peak Harness)'와 코딩 벤치마크가 보여준 역설

2026년 초 Cursor 팀은 다수의 머신과 에이전트를 멀티모달로 오케스트레이션하는 장기 실행 하네스 **'그라인드 스웜(Grind Swarm)'**을 가동해 웹 브라우저를 밑바닥부터 통째로 구현하는 데모를 선보였습니다. 그러나 이른바 '피크 하네스'에 도달한 지 불과 몇 달 만에 업계에서는 정반대의 목소리가 터져 나왔습니다.

• Anthropic 측은 Claude Code에서 시스템 프롬프트의 상당 부분을 걷어냈다고 밝혔고, YC의 개리 탄(Garry Tan)은 하네스는 사라지고 스킬(Skills)만 남을 것이라고 전망했습니다.
• 카츠 본인 역시 Cursor에서 모델의 지능 공백을 메우기 위해 넣었던 수많은 가드레일(파일 편집 적용 전용 소형 보조 모델, 코드베이스 탐색 절차 지시문, 작업 검증용 세부 프롬프트 등)을 대거 삭제했다고 고백했습니다.

실제 학계 연구도 이를 뒷받침했습니다. UC 버클리(UC Berkeley) 연구진이 7개의 프론티어 모델을 Pi, Codex, Claude Code 등 서로 다른 하네스에 올려 SWE-bench Lite를 측정한 결과, 최신 고성능 모델일수록 어떤 하네스를 쓰느냐가 최종 해결 점수에 유의미한 차이를 만들지 못했습니다. Apple과 EPFL의 공동 연구 역시 머신러닝 엔지니어링 벤치마크인 MLE-bench에서 전용 하네스의 유무가 큰 점수 차이를 내지 못한다는 사실을 확인했습니다.

왜 이런 일이 일어나는가: '데이터 플라이휠(Data Flywheel)'

카츠는 "오늘날 정교한 하네스가 더 이상 코딩 지능 자체를 높여주지 않는다는 말은 사실"이라며, 그 원인을 데이터 플라이휠로 설명합니다.

1. 초기에는 하네스가 정교한 보정 장치(코드 탐색법, /goal 같은 장기 지속 실행 루프, 테스트 실행 강제 등)를 덧대어 모델이 더 어려운 코딩 과제를 풀 수 있게 만듭니다.
2. 과제가 해결 가능해지면 수많은 사용자가 에이전트로 해당 작업을 수행하고, 이 과정에서 축적된 양질의 코딩 궤적 데이터가 모델 연구소로 공유됩니다.
3. 차세대 프론티어 모델은 이 데이터를 학습해 과거 하네스가 억지로 가르쳐야 했던 스킬들을 모델 가중치 내부의 기본 능력(Native Muscle Memory)으로 완전히 흡수합니다.
4. 결과적으로 모델이 충분히 똑똑해지면, 하네스는 처음에 그 작업을 가능하게 만들었던 자체 보정 코드를 스스로 삭제(Obsolete)하게 됩니다.

그럼에도 에이전트 하네스가 죽지 않은 2가지 결정적 이유

코딩 능력 보정용 하네스가 모델에 흡수되었다면 하네스 엔지니어링은 끝난 것일까요? 카츠는 **"아니다"**라고 단언하며 두 가지 핵심 근거를 제시합니다.

이유 1. 하네스는 모델이 아직 풀지 못한 '다음 프론티어'를 개척한다

단일 턴 코딩과 같은 역량이 모델에 내재화되면, 하네스는 그다음 단계의 미개척 영역(New Frontier)으로 이동해 플라이휠을 다시 돌리기 시작합니다.

• 그록봇(Grok Bot)과 범용 지식 노동: Cursor에서 프롬프트와 가드레일을 덜어내던 개발진은, 자율형 AI 동료인 그록봇을 개발하면서 정반대로 새로운 프롬프트와 새로운 가드레일을 다시 대거 추가하고 있습니다. 유능한 변호사(장기 실행 코디네이터 봇)가 여러 패러리걸(워커 에이전트 군단)에게 업무를 분배하는 구조로 슬라이드 제작, 출장 예약, 동료 이메일 발송 등을 처리할 때는 모델이 아직 완전히 체화하지 못한 난제들이 등장하기 때문입니다. 사용자를 압도하지 않으면서 적절히 진행 상황을 보고하는 소통 방식, 독단적 실행과 사전 질문 사이의 경계(Acting vs. Asking), 장기 메모리를 통한 업무 스타일 학습 등은 현재 전적으로 하네스가 지탱하고 있습니다.
• 소프트웨어 팩토리(Software Factory)와 메타 하네스: 순수 코딩을 넘어 소프트웨어 개발 생명주기(SDLC) 전체를 다중 에이전트로 연결하는 영역입니다. 내부 채널에 버그가 제보되면 ① 자동 분류(Auto-triage) 에이전트가 작동하고 ② 클라우드 에이전트가 수정 코드를 작성한 뒤 수정 전후 비교 영상(Before & After Videos)을 생성해 해결을 입증하며 ③ 코드가 병합·배포되면 롤아웃(Rollouts) 감시 에이전트가 프로덕션 이상 징후를 실시간 추적합니다. 이처럼 여러 에이전트를 조율하는 **메타 하네스(Meta-Harness)**가 새로운 경쟁력이 되고 있습니다.

이유 2. 모델이 구조적으로 절대 흡수할 수 없는 3대 영역이 존재한다

컨텍스트 계층 바깥에는 모델이 아무리 진화해도 가중치 안으로 흡수할 수 없는 세 가지 기둥이 있습니다.

모델이 흡수 불가능한 영역	엔지니어링 필요성 및 현장 사례
1. 인프라와 상시 런타임 (Infrastructure)	에이전트의 작업 호흡이 몇 분에서 몇 시간, 며칠 단위로 길어졌습니다. 덮개를 닫으면 절전 모드로 들어가는 개인 노트북에서는 진정한 자율형 동료를 구동할 수 없으며, 클라우드 기반 상시 런타임이 필수적입니다.
2. 신뢰와 보안 (Trust & Security)	배시(Bash) 셸과 모든 프로덕션 API 키가 담긴 평문 파일을 모델에 그대로 넘겨도 코딩 벤치마크 점수는 잘 나올 수 있습니다. 그러나 실무에서는 에이전트·사용자별 최소 권한 분리와 치명적 오작동 및 하룻밤 사이 1만 달러의 API 요금 폭탄을 막는 결정론적 가드레일이 반드시 하네스에 있어야 합니다.
3. 비용 및 속도 효율성 (Efficiency)	앞서 인용한 UC 버클리 및 Apple·EPFL 연구에서 하네스별 정답률은 비슷했지만, 작업당 소요 비용(Cost per task)은 하네스에 따라 극적인 차이를 보였습니다. 실제로 카츠 팀은 그록봇 하네스의 프롬프트 캐시 적중률(Cache Hit Rate), 토큰 효율성, 모델 조합(Model Mix)을 최적화해 품질 저하 없이 비용과 응답 속도를 대폭 개선했습니다.

차세대 에이전트 하네스 설계의 4가지 미래 트렌드

강연은 앞으로의 하네스 아키텍처가 나아갈 네 가지 구체적인 설계 패턴과 예측을 제시하며 끝을 맺습니다.

1. 내부 동작 은닉과 빠른 착탈(Hyrum's Law 대응): 제품 진화 속도가 다시 모델 진화 속도를 앞지르면서 하네스에는 임시 실험 기능들이 빠르게 추가되었다가 빠져야 합니다. "사용자에게 노출된 모든 내부 동작은 결국 누군가 의존하게 된다"는 하이럼의 법칙(Hyrum's Law)에 따라, 최신 에이전트 제품들은 하네스 내부 설정을 사용자에게 덜 노출하는 대신 변경 관리 부담을 줄이고 반복 주기를 높이는 추세입니다.
2. 조합 가능한 에이전트 프리미티브(Subscriptions): Slack 메시지 수신, PR의 CI 빌드 실패(Red), 특정 시각 도래 등 에이전트를 깨워야 하는 이벤트마다 개별 연동 코드를 짜는 대신, 에이전트가 어떤 이벤트든 단일 인터페이스와 도구로 구독할 수 있는 **Subscriptions 프리미티브(Primitive)**를 설계해 복잡도를 낮춥니다.
3. 스스로 삭제 시점을 알려주는 임시 보정 코드 '심(Shims)': 그록봇이 사용자에게 제때 응답하지 않을 때 하네스가 *"사용자가 기다리고 있다"*고 찔러주는(Nudge) 결정론적 보정 코드를 내부적으로 **심(Shim)**이라 부릅니다. 카츠 팀은 다음 모델 체크포인트를 기다리는 대신 당장 문제를 고치기 위해 심을 넣되, 모든 심을 중앙에서 추적하고 발화 횟수를 대시보드에 기록합니다. 그리고 감시 봇이 대시보드를 지켜보다가 새 모델 도입 후 특정 심이 더 이상 발화하지 않으면, 봇이 자동으로 해당 심을 삭제하는 PR을 올립니다.
4. 6개월 내 에이전트 작업의 90%가 노트북 밖(클라우드)으로 이동: 단일 LLM 호출을 조합하던 어제의 하네스를 넘어, 에이전트 자체를 기본 블록으로 삼는 고수준 추상화가 진행되면서 향후 6개월 이내에 전체 에이전트 작업의 90%가 로컬 노트북이 아닌 클라우드 런타임에서 실행될 것으로 전망했습니다.

관련 자료

• AI Engineer 공식 YouTube — Is the Agent Harness Dead? (Jediah Katz, SpaceXAI)
• VIVO News — xAI 워크숍으로 본 그록봇(Grok Bot): 지속 메모리와 공유 클라우드 컴퓨터를 갖춘 자율형 AI 팀원
• VIVO Wiki — Grok Bot 201: 멀티 봇 오케스트레이션과 무인 자율 루틴 구축하기
• VIVO Wiki — LLM 모델 라우터의 원리와 오픈라우터 아키텍처