에이전트 하네스 엔지니어링

핵심은 이렇다. 에이전트가 실수를 저지를 때마다, 같은 실수가 다시는 반복되지 않도록 해결책을 엔지니어링하는 데 시간을 투자하는 것이다.

지난 2년간 우리는 모델 논쟁에 열을 올렸다. 어떤 모델이 가장 똑똑한지, 어느 모델이 더 깔끔한 React 코드를 쓰는지, 어느 모델이 환각을 덜 일으키는지. 이런 논의가 무의미하다는 게 아니다. 다만 시스템의 절반을 놓치고 있다는 게 문제다. 모델은 에이전트를 구성하는 여러 입력 중 하나일 뿐이다. 나머지는 하네스가 담당한다. 모델이 실제로 무언가를 완수할 수 있도록 감싸고 있는 프롬프트, 도구, 컨텍스트 정책, 훅(hook), 샌드박스, 서브에이전트, 피드백 루프, 복구 경로가 바로 그것이다.

평범한 모델에 훌륭한 하네스를 씌우면, 훌륭한 모델에 엉성한 하네스를 씌운 것보다 낫다. 내 작업에서 이 패턴이 반복되는 걸 수없이 목격했다. 갈수록 흥미로운 엔지니어링은 어떤 모델을 고르느냐가 아니라, 그 주변에 어떤 스캐폴딩을 설계하느냐에 달려 있다.

이 분야에 이제 이름이 생겼다. Viv Trivedy가 하네스 엔지니어링이라는 용어를 만들었고, 그의 글 "Anatomy of an Agent Harness"는 하네스가 실제로 무엇이고 각 구성요소가 왜 존재하는지를 가장 명료하게 정리한 글이다. Dex Horthy는 이 패턴이 자리 잡아가는 과정을 꾸준히 추적해 왔다. HumanLayer는 대부분의 에이전트 실패가 모델 가중치가 아닌 설정 문제에서 비롯된 "스킬 이슈"라고 규정한다. Anthropic 엔지니어링 팀은 장기 실행 작업을 위한 하네스 설계 방법에 관해 내가 본 것 중 가장 체계적인 공개 자료를 발표했다. Birgitta Böckeler은 사용자 관점에서 이 모든 것이 어떻게 보이는지를 잘 정리해 두었다.

이 글은 그 실마리들을 한데 엮으려는 시도다.

하네스란 정확히 무엇인가

Viv의 한 문장이 대부분을 설명해 준다.

에이전트 = 모델 + 하네스. 당신이 모델이 아니라면, 당신은 하네스다.

하네스는 모델 자체를 제외한 모든 코드, 설정, 실행 로직을 가리킨다. 모델만으로는 에이전트가 되지 않는다. 하네스가 상태, 도구 실행, 피드백 루프, 강제 가능한 제약을 부여했을 때 비로소 에이전트가 된다.

구체적으로 하네스는 다음을 포함한다.

• 시스템 프롬프트, CLAUDE.md, AGENTS.md, 스킬 파일, 서브에이전트 프롬프트
• 도구, 스킬, MCP 서버 및 각각의 설명
• 번들 인프라(파일시스템, 샌드박스, 브라우저)
• 오케스트레이션 로직(서브에이전트 생성, 핸드오프, 모델 라우팅)
• 결정론적 실행을 위한 훅과 미들웨어(컴팩션, 연속 실행, 린트 검사)
• 관찰 가능성(로그, 트레이스, 비용 및 지연 시간 측정)

Simon Willison은 루프의 본질을 이렇게 압축한다. 에이전트란 "목표를 달성하기 위해 루프 안에서 도구를 실행하는 시스템"이라고. 진짜 실력은 도구와 루프를 어떻게 설계하느냐에서 갈린다.

표면적이 넓다고 느껴진다면, 실제로 그렇다. 그리고 그 표면적은 모델 제공자가 아닌 당신의 것이다. Claude Code, Cursor, Codex, Aider, Cline은 모두 하네스다. 내부 모델이 같은 경우도 있지만, 실제로 경험하는 동작은 하네스가 무엇을 하느냐에 의해 결정된다.

coding agent = AI model(s) + harness

Viv이 정식화하고 HumanLayer가 공명한 이 등식이 바로 실제 작업이 이루어지는 곳이다. 등호 왼쪽을 둘러싼 논쟁은 시끄럽다. 하지만 실제 레버리지의 대부분은 오른쪽에 있다.

"스킬 이슈"라는 재해석

엔지니어들이 빠지는 전형적인 패턴이 있다. 에이전트가 뭔가 어처구니없는 짓을 하면, 엔지니어는 모델 탓을 하고, 그 원인은 "다음 버전을 기다리면 해결될 것"이라는 서랍 속으로 사라진다.

하네스 엔지니어링의 사고방식은 이런 기본값을 거부한다. 실패는 대부분 판독 가능하다. 에이전트가 관례를 몰랐다면 AGENTS.md에 추가하면 된다. 에이전트가 파괴적인 명령을 실행했다면 이를 차단하는 훅을 추가하면 된다. 에이전트가 40단계짜리 작업에서 길을 잃었다면 플래너와 실행자로 역할을 나누면 된다. 에이전트가 망가진 코드를 계속 "완성"이라고 우겼다면 타입 체크 역압 신호를 루프에 연결하면 된다.

HumanLayer는 말한다. "모델 문제가 아니라 설정 문제다." 하네스 엔지니어링은 이 말을 진지하게 받아들였을 때 일어나는 일이다.

Viv의 글과 HumanLayer 모두에서 등장하는 인상적인 데이터가 있다. Terminal Bench 2.0에서 Claude Code 내에서 실행한 Claude Opus 4.6은, 동일한 모델을 커스텀 하네스에서 실행했을 때보다 훨씬 낮은 점수를 기록했다. Viv의 팀은 하네스만 바꿔서 코딩 에이전트의 순위를 상위 30위에서 상위 5위로 끌어올렸다. 모델은 훈련에 사용된 하네스와 함께 포스트 트레이닝된다. 이 모델을 다른 하네스로 옮기되, 코드베이스에 맞는 더 나은 도구와 더 정교한 프롬프트, 더 날카로운 역압 신호를 갖추면 기존 하네스가 끌어내지 못했던 역량을 끌어낼 수 있다.

이는 "GPT-6만 기다리면 된다"는 서사와 정반대다. 오늘날 모델이 할 수 있는 것과 실제로 하는 것 사이의 격차는 대부분 하네스의 격차다.

래칫: 모든 실수는 규칙이 된다

하네스 엔지니어링에서 가장 중요한 습관은 에이전트의 실수를 영구적인 신호로 취급하는 것이다. 한 번 웃고 넘길 해프닝도 아니고, 재시도하면 그만인 "불운한 실행"도 아니다. 신호다.

에이전트가 테스트를 주석 처리한 채 PR을 올리고 내가 실수로 머지했다면, 그것은 하나의 입력이다. 다음 버전의 AGENTS.md에는 "테스트를 주석 처리하지 말 것. 삭제하거나 고칠 것"이 추가된다. 다음 버전의 pre-commit 훅은 diff에서 .skip(와 xit(을 grep한다. 다음 버전의 리뷰어 서브에이전트는 주석 처리된 테스트를 블로커로 표시한다.

제약은 실제 실패를 목격한 뒤에만 추가한다. 제거는 그 제약이 충분히 성숙한 모델에 의해 불필요해졌을 때만 한다. 잘 다듬어진 AGENTS.md의 모든 줄은 과거에 실제로 잘못됐던 특정 사건으로 소급될 수 있어야 한다.

이것이 하네스 엔지니어링이 프레임워크가 아니라 하나의 규율(discipline)인 이유다. 당신의 코드베이스에 맞는 올바른 하네스는 당신의 실패 이력에 의해 형성된다. 다운로드할 수 없다.

원하는 동작에서 거꾸로 설계하기

실제로 하네스를 설계할 때 내가 가장 유용하게 쓰는 Viv의 프레임은 원하는 동작에서 출발해 그것을 구현할 하네스 구성요소를 도출하는 것이다. 그의 패턴은 이렇다. 원하는(또는 수정하고 싶은) 동작 → 모델이 이를 달성하도록 돕는 하네스 설계.

이렇게 역방향으로 도출하면 각 하네스 구성요소가 구체적인 역할을 갖게 된다. 어떤 구성요소가 어떤 동작을 위해 존재하는지 말할 수 없다면, 그 구성요소는 없는 게 낫다.

이어지는 내용은 Viv가 다루는 순서에 따라 각 구성요소를 살펴보면서, 내가 실제로 가져다 쓸 만하다고 느낀 패턴을 함께 정리한 것이다.

파일시스템과 Git: 지속 가능한 상태

파일시스템은 가장 근본적인 기본 요소지만, 지루하다는 이유로 과소평가되는 경향이 있다. 모델은 컨텍스트에 들어 있는 것만 직접 다룰 수 있다. 파일시스템이 없다면 채팅창에 내용을 복붙하는 것이 전부인데, 그건 워크플로라 부를 수 없다.

파일시스템이 생기면 에이전트는 데이터, 코드, 문서를 읽을 작업 공간을 갖게 된다. 컨텍스트에 붙들고 있는 대신 중간 작업물을 내려놓을 장소도 생긴다. 여러 에이전트와 사람이 공유 파일을 통해 조율할 수 있는 공간도 마련된다. 여기에 Git을 얹으면 버전 관리가 무료로 따라온다. 에이전트가 진행 상황을 추적하고, 오류를 롤백하고, 실험을 브랜치로 분기할 수 있게 된다.

다른 하네스 기본 요소 대부분은 결국 파일시스템 어딘가를 참조하게 된다.

Bash와 코드 실행: 범용 도구

오늘날의 주요 에이전트 루프는 ReAct 루프다. 모델이 추론하고, 도구 호출로 액션을 취하고, 결과를 관찰하고, 이를 반복한다. 그런데 하네스는 로직이 구현된 도구만 실행할 수 있다. 가능한 모든 액션에 대한 도구를 미리 만들 수도 있지만, 에이전트에게 bash를 주고 필요한 도구를 즉석에서 만들게 하는 방법도 있다.

Willison의 관점은 이렇다. 에이전트는 이미 셸 명령어를 잘 다룬다. 대부분의 작업은 몇 가지 잘 선택된 CLI 호출로 귀결된다. 하네스는 여전히 목적에 맞는 도구를 제공하지만, bash와 코드 실행은 자율적 문제 해결을 위한 기본 범용 전략이 됐다. 특정 주방 가전 사용법을 가르치는 것과 주방 전체를 맡기는 것의 차이라 할 수 있다.

샌드박스와 기본 도구 환경

bash는 안전한 실행 환경이 있을 때만 유용하다. 에이전트가 생성한 코드를 로컬 머신에서 실행하는 건 위험하고, 단일 로컬 환경으로는 병렬 에이전트 여러 개를 감당할 수 없다.

샌드박스는 에이전트에게 격리된 실행 환경을 제공한다. 로컬에서 직접 실행하는 대신, 하네스가 샌드박스에 연결해 코드를 실행하고, 파일을 점검하고, 의존성을 설치하고, 작업을 검증한다. 명령어 허용 목록을 정의하고, 네트워크를 격리하고, 필요에 따라 새 환경을 즉시 생성하고, 작업이 끝나면 철거할 수 있다.

좋은 샌드박스에는 좋은 기본값이 포함된다. 주요 언어 런타임과 패키지, Git과 테스트 CLI, 웹 상호작용을 위한 헤드리스 브라우저가 미리 설치되어 있다. 브라우저, 로그, 스크린샷, 테스트 러너는 에이전트가 자신의 작업을 관찰하고 자기 검증 루프를 닫을 수 있게 해준다.

모델은 자신의 실행 환경을 설정하지 않는다. 에이전트가 어디서 실행될지, 무엇을 사용할 수 있을지, 결과를 어떻게 검증할지는 모두 하네스가 결정한다.

메모리와 검색: 지속적 학습

모델은 가중치와 현재 컨텍스트 안에 있는 것 이상의 지식을 갖지 못한다. 가중치를 직접 수정할 수 없다면, 지식을 추가하는 유일한 방법은 컨텍스트 주입뿐이다.

여기서도 파일시스템이 기본 요소다. 하네스는 AGENTS.md 같은 메모리 파일 표준을 지원해 매 시작 시 이를 주입한다. 에이전트가 해당 파일을 수정하면 하네스가 다시 불러오고, 한 세션에서 얻은 지식이 다음 세션으로 이어진다. 조잡하지만 효과적인 지속적 학습 방식이다.

훈련 시점 이후에 등장한 지식, 즉 새로운 라이브러리 버전, 최신 문서, 오늘의 데이터 등을 채워 넣는 데는 웹 검색과 Context7 같은 MCP 도구가 훈련 데이터 컷오프를 보완한다. 사용자에게 맡기기보다 하네스에 기본 탑재해 두는 게 유용한 기본 요소다.

컨텍스트 부패와의 싸움

컨텍스트 부패란 컨텍스트 창이 채워질수록 모델의 추론 능력과 작업 완수 능력이 저하되는 현상이다. 컨텍스트는 희소 자원이며, 하네스는 상당 부분 양질의 컨텍스트를 효율적으로 전달하는 장치다.

반복해서 등장하는 세 가지 기법이 있다.

컴팩션. 창이 거의 다 찼을 때 무언가를 포기해야 한다. API 오류를 내는 건 프로덕션 하네스에서 선택지가 될 수 없다. 하네스는 오래된 컨텍스트를 지능적으로 요약하고 오프로드해 에이전트가 계속 작동할 수 있게 한다.

도구 호출 오프로딩. 2,000줄짜리 로그 파일처럼 거대한 도구 출력은 컨텍스트를 잠식하면서도 유효한 신호는 거의 추가하지 않는다. 하네스는 임계값 이상의 출력에서 앞뒤 일부 토큰만 남기고 전체 출력은 파일시스템으로 오프로드하며, 에이전트는 필요할 때 이를 직접 읽는다.

점진적 공개 방식의 스킬. 시작 시점에 모든 도구와 MCP를 컨텍스트에 올리면 에이전트가 첫 액션을 취하기도 전에 성능이 저하된다. 스킬은 하네스가 해당 작업이 실제로 필요로 할 때만 지침과 도구를 꺼내 보이도록 해준다.

Anthropic의 하네스 글은 정말 긴 작업을 위한 기법을 하나 더 추가한다. 전체 컨텍스트 리셋이다. 하네스가 세션을 종료하고, 압축된 인계 파일을 바탕으로 새 세션을 재구성한다. 그들은 컴팩션만으로는 장기 작업에 충분하지 않았다고 명시한다. 때로는 잘 구조화된 브리핑으로 새로 시작해야 한다. 이는 "메모리"를 보통 생각하는 방식보다는, 신규 엔지니어를 온보딩하는 방식에 더 가깝다.

장기 실행: Ralph 루프, 계획, 검증

자율적인 장기 실행은 궁극의 목표이자 가장 다루기 어려운 영역이다. 오늘날 모델은 조기 중단, 복잡한 문제의 분해 실패, 여러 컨텍스트 창에 걸쳐 작업이 이어질 때 발생하는 비일관성 문제를 안고 있다. 하네스는 이 모든 것을 감안한 설계가 필요하다.

나는 이전에 자기 개선 에이전트와 2026년 트렌드 글에서 Ralph 루프 같은 자율 코딩 루프를 다룬 바 있다. 이 프레임에서 다시 짚어볼 만한 내용이 있다. 훅이 모델의 종료 시도를 가로채 원래 프롬프트를 새 컨텍스트 창에 재주입하고, 에이전트가 완료 목표를 향해 계속 나아가도록 강제한다. 각 반복은 깨끗하게 시작하되, 파일시스템을 통해 이전 반복의 상태를 읽어온다. 단일 세션 에이전트를 다중 세션 에이전트로 전환하는 놀랍도록 단순한 방법이며, "더 스마트한 모델을 쓰면 되지"라는 사고방식으로는 결코 도출할 수 없는 기본 요소다.

계획은 모델이 목표를 단계 시퀀스로 분해하는 과정으로, 보통 디스크의 계획 파일에 저장된다. 하네스는 프롬프팅과 계획 파일 사용법 안내로 이를 지원한다. 각 단계 이후 에이전트는 자기 검증을 통해 작업을 점검한다. 훅이 사전에 정의된 테스트 스위트를 실행하고 실패 내용을 오류 텍스트와 함께 모델에 피드백하거나, 모델이 명시적인 기준에 따라 자신의 출력을 직접 검토한다.

플래너/생성자/평가자 분리. Anthropic의 장기 실행 하네스 연구는 생성과 평가를 별도의 에이전트로 분리하는 것이 자기 평가보다 성능이 낫다고 명시한다. 에이전트는 자신의 작업을 채점할 때 체계적으로 긍정 편향을 보이기 때문이다. 산문을 위한 GAN이라 할 수 있다. 연관된 패턴은 스프린트 계약으로, 코드 작성이 시작되기 전에 생성자와 평가자가 "완료"의 의미를 협상하는 방식이다. 내 워크플로에서도 시작 전에 완료 조건을 명문화하는 것이 지금까지 어떤 프롬프트 수정보다 범위 이탈을 더 많이 잡아냈다.

훅: 강제 실행 레이어

훅은 "에이전트에게 X를 하라고 말했다"와 "시스템이 X를 강제한다"를 가르는 경계선이다.

훅은 특정 라이프사이클 시점에 실행되는 스크립트다. 도구 호출 전, 파일 수정 후, 커밋 전, 세션 시작 시. 에이전트가 잊어서는 안 되지만 자주 잊어버리는 것들을 처리하기에 적합한 자리다. 모든 수정 후 타입 체크, 린트, 테스트를 실행하고 실패를 표면화한다. 파괴적인 bash(rm -rf, git push --force, DROP TABLE)를 차단한다. PR을 열거나 main에 푸시하기 전 승인을 요구한다. 에이전트가 공백에 토큰을 낭비하지 않도록 파일 저장 시 자동 포맷을 적용한다.

HumanLayer가 강조하고 나도 동의하게 된 원칙이 있다. 성공은 조용하고, 실패는 말이 많아야 한다. 타입 체크를 통과하면 에이전트는 아무것도 듣지 않는다. 실패하면 오류 텍스트가 루프에 주입되고 에이전트가 스스로 수정한다. 대부분의 경우엔 피드백 루프가 사실상 무료이고, 문제가 생겼을 때는 즉시 조치 가능하다.

AGENTS.md와 도구 선택

저장소 루트에 있는 평범한 마크다운 규칙 파일은 여전히 레버리지가 가장 높은 단일 설정 지점이다. 매 턴 시스템 프롬프트에 포함되기 때문이다. 관례는 여기에 담는다. 패키지 매니저, 테스트 프레임워크, 포맷, "/legacy는 절대 건드리지 말 것", "항상 우리 로거를 사용할 것". 경험에서 얻은 두 가지 교훈이 있다.

짧게 유지하라. HumanLayer는 자신들의 파일을 60줄 이내로 관리한다. 모든 줄이 주의를 두고 경쟁하며, 규칙이 많아질수록 각 규칙의 비중은 줄어든다. 스타일 가이드가 아니라 파일럿의 체크리스트다.

각 줄을 벌어서 넣어라. 규칙은 과거의 특정 실패나 외부의 불가피한 제약으로 소급될 수 있어야 한다. 그렇지 않다면 그건 소음이다. 브레인스토밍이 아니라 래칫이다.

같은 원칙이 도구에도 적용된다. 각 도구의 이름, 설명, 스키마는 매 요청마다 프롬프트에 포함된다. 열 개의 집중된 도구가 쉰 개의 중복된 도구보다 낫다. 모델이 메뉴 전체를 머릿속에 담을 수 있기 때문이다. HumanLayer는 여기서 실질적인 보안 위협도 지적한다. 도구 설명이 프롬프트에 직접 들어가기 때문에, 설치한 MCP 서버는 모델이 읽을 신뢰된 텍스트다. 허술하거나 악의적인 MCP는 당신이 무언가를 입력하기도 전에 에이전트에게 프롬프트 인젝션을 시도할 수 있다.

프로덕션에서 실제로 어떻게 보이는가

내가 본 것 중 성숙한 하네스의 가장 명료한 공개 사례는 Fareed Khan의 Claude Code 아키텍처 추정 분석이며, 다이어그램을 잠시 천천히 들여다볼 가치가 있다.

앞서 살펴본 거의 모든 개념이 이 다이어그램에 이름을 가진 구성요소로 등장한다. 컨텍스트 주입은 지식 레이어다. 루프 상태는 메모리 저장소와 워크트리 이솔레이터에 산다. 파괴적 액션 훅은 퍼미션 게이트 뒤에 자리한다. 서브에이전트 컨텍스트 방화벽은 멀티에이전트 레이어 전체다. 도구 디스패치 레지스트리는 MCP 서버와 bash가 모두 연결되는 곳이다. Khan의 주장은 Viv의 것과 같다. 단지 실제 출시 제품을 통해 확인된 버전이다. Claude Code의 궤적은 내부 모델만큼이나, 아니 그 이상으로 하네스에 달려 있다.

하네스는 줄어들지 않는다, 이동할 뿐이다

Anthropic의 글에서 나온 관찰 중 가장 인상 깊은 것이 있다. 모델이 발전할수록 흥미로운 하네스 조합의 공간은 줄어드는 게 아니라, 이동한다는 것이다.

단순하게 생각하면 더 나은 모델이 하네스를 쓸모없게 만들 것 같다. 모델이 계획할 수 있다면 플래너는 필요 없다. 모델이 긴 작업에서 일관성을 유지한다면 컨텍스트 리셋도 필요 없다. 실제로 Opus 4.6은 컨텍스트 불안 실패 모드를 대부분 해결했다. Sonnet 4.5는 컨텍스트 한계가 다가온다고 판단하면 작업을 조기에 마무리하는 경향이 있었는데, 그 탓에 여섯 달 전까지 내가 작성했던 불안 완화 스캐폴딩 한 묶음이 이제 죽은 코드가 됐다.

그런데 모델과 함께 천장도 올라갔다. 이전에는 닿지 않았던 작업이 이제 손에 닿고, 그 작업에는 또 그만의 실패 모드가 있다. 불안 스캐폴딩이 사라진 자리에는 며칠짜리 메모리 정책이 필요하거나, 세 가지 특화된 에이전트를 조율하는 하네스가 필요하거나, 생성된 UI의 디자인 품질을 평가하는 평가자가 필요하다. 가정이 바뀌고, 그 가정을 코드로 새긴 스캐폴딩도 함께 바뀐다.

Anthropic은 간명하게 말한다. "하네스의 모든 구성요소는 모델이 혼자서 할 수 없는 것에 대한 가정을 담고 있다." 모델이 어떤 부분에서 나아지면, 그 부분을 떠받치던 구성요소는 아무것도 지탱하지 않게 되므로 제거해야 한다. 모델이 새로운 가능성을 열면, 새 천장에 닿기 위한 새 스캐폴딩이 필요하다.

모델-하네스 훈련 루프

또 하나의 현상이 있다. Viv가 명시적으로 언급한 것인데, 하네스 설계와 모델 훈련 사이에 피드백 루프가 작동하고 있다는 점이다.

오늘날의 에이전트 제품은 하네스가 루프에 포함된 채로 포스트 트레이닝된다. 하네스 설계자가 잘해야 한다고 판단한 액션, 즉 파일시스템 조작, bash, 계획 수립, 서브에이전트 디스패치에서 모델이 구체적으로 더 나아진다. Opus 4.6이 Claude Code 내에서와 다른 하네스 내에서 다르게 느껴지는 이유, 도구 로직을 바꿨을 때 예상치 못한 회귀가 발생하는 이유가 여기 있다. 진정으로 범용적인 모델이라면 apply_patch을 썼는지 str_replace을 썼는지 신경 쓰지 않겠지만, 공동 훈련은 과적합을 만들어 낸다.

실질적 함의는 두 가지다. 하네스는 한 번 세팅하면 끝나는 설정 파일이 아니라, 살아있는 시스템이다. 그리고 "최고의" 하네스는 반드시 모델이 훈련된 하네스가 아니라, 당신의 작업에 맞게 설계된 하네스다. Viv의 Terminal Bench 상위 30위에서 상위 5위 도약이 내가 본 것 중 가장 명확한 증거다.

서비스로서의 하네스

Viv의 또 다른 기여는 HaaS, 즉 Harness-as-a-Service 프레임이다. 그의 관찰에 따르면, 우리는 완성(completion)을 제공하는 LLM API 위에서 개발하던 시대에서 런타임을 제공하는 하네스 API 위에서 개발하는 시대로 이동 중이다. Claude Agent SDK, Codex SDK, OpenAI Agents SDK는 모두 같은 방향을 가리킨다. 루프, 도구, 컨텍스트 관리, 훅, 샌드박스 기본 요소를 기본으로 제공받고, 그것을 커스터마이징하는 방식이다.

이 전환이 중요한 이유는, 이전의 기본 경로가 이것이었기 때문이다. 루프를 직접 만들고, 도구 호출을 직접 연결하고, 대화 상태를 직접 관리하고, 승인 흐름을 직접 고안하는 것. 이제 기본 경로는 달라졌다. 하네스 프레임워크를 선택하고, 네 가지 축(시스템 프롬프트, 도구, 컨텍스트, 서브에이전트)을 따라 설정하고, 나머지 노력은 도메인 특화 프롬프트와 도구 설계에 쏟는 것이다.

이것이 "스킬 이슈"를 다룰 수 있는 것으로 만들어 준다. 무언가 잘못될 때마다 에이전트를 처음부터 다시 만드는 게 아니라, 이미 잘 구조화된 설정 표면을 조율하면 된다.

이에 대한 Viv의 말은 처음에 어설프게 시작하는 것에 대한 가장 좋은 논거이기도 하다. "좋은 에이전트 개발은 반복의 연속이다. v0.1이 없으면 반복도 없다."

앞으로의 방향

주요 코딩 에이전트들(Claude Code, Cursor, Codex, Aider, Cline)을 나란히 놓고 보면 기반 모델들보다 서로 더 닮아 있다. 모델은 서로 다르다. 하네스 패턴은 수렴하고 있다. 이게 우연이라고 생각하지 않는다. 업계가 천천히 생성 모델을 실제로 무언가를 출시할 수 있는 것으로 만드는 스캐폴딩의 핵심 구성요소를 찾아가고 있는 것이다.

Viv가 제시하는 미해결 과제 중 내가 가장 흥미롭게 보는 것은 이것이다. 공유 코드베이스에서 병렬로 작동하는 다수의 에이전트 조율, 자신의 트레이스를 분석해 하네스 수준의 실패 모드를 스스로 식별하고 수정하는 에이전트, 시작 시 미리 설정되는 방식이 아니라 특정 작업에 맞는 도구와 컨텍스트를 필요한 순간에 동적으로 조립하는 하네스.

특히 마지막 방향은 하네스가 정적인 설정을 벗어나 컴파일러에 가까운 무언가로 진화하는 지점처럼 느껴진다.