“우리가 도구를 만들고, 그다음엔 도구가 우리를 만든다”(McLuhan)는 인용으로 시작하는 하네스 선택 가이드. 다음 세대의 큰 기회는 모델에 맞는 하네스, 하네스에 맞는 모델을 고르는 co-optimization에서 나온다는 전제로, ① 역할별 구매/커스터마이즈/구축 기준, ② 하네스를 평가하는 8가지 진단 질문, ③ 하네스 엔지니어링이 향하는 방향(라우팅·서빙)을 순서대로 다룬다.
구매 vs 커스터마이즈 vs 구축
비개발자(GTM·Ops 등 대부분의 지식노동자): 커스터마이즈하지 말고 최적의 하네스를 “사는” 데 집중하라. Harvey(법률)·Clay(GTM)·Descript(영상) 같은 AI 네이티브 앱을 찾아 제약과 강점을 파악하고 워크플로우에 끼워 넣는다. 완제품 하네스가 민감한 업무에서 이탈행동을 막는 강한 가드레일을 제공하고, 최종 사용자가 직접 eval을 유지보수하는 건 현실적으로 불가능하기 때문. 진짜 할 일은 좋은 컨텍스트 엔지니어가 되는 것.
엔지니어(비기술 tinkerer 포함): 그림이 완전히 다르다. BYO-model 구조로 오픈소스·클로즈드·자체호스팅 모델을 섞어 성능과 비용을 함께 잡을 수 있다. 실전 팁:
- 에러 케이스·러프엣지를 파일로 문서화해 하네스가 같은 함정에 반복해서 빠지거나(“dumb zone”) 잦은 컴팩션에 걸리지 않게 한다.
- 거대 코드베이스 구조를 루트의
.md파일에 인코딩해 grep·탐색 반복을 줄인다. - 안 쓰는 툴은 연결 해제해 컨텍스트 윈도우를 절약한다.
- 사용자 궤적과 “좋음”의 기준(eval)이 갖춰졌다면, 모델과 하네스를 함께 post-training/fine-tuning하는 것도 고려한다 — Cursor·OpenCode가 특정 모델에 맞춰 시스템 프롬프트·툴 포맷을 최적화한 사례. 다만 RL/SFT는 프론티어 영역이라 대부분의 팀은 아직 여기 있을 필요가 없다 — 완제품과 커스터마이즈부터 소진하라.
하네스의 3계층
- 프레임워크/SDK — 하네스를 만들기 위한 빌딩블록(Django가 앱을 안 주고 도구만 주듯). 예: Vercel AI SDK, Anthropic Agent SDK, Mastra.
- Extensible — 기본 tool-use 루프 외엔 내장 기능이 거의 없음(에디터로 치면 vanilla emacs/vim). 예: Pi, Deep Agents.
- Turnkey — 기능이 풍부한 완제품, 대개 유료/독점 API에 묶임. 예: OpenCode, Codex, Claude Code, Cursor agent.
하네스를 고르는 두 축과 8가지 진단 질문
하네스 선택은 결국 두 가지로 압축된다: ① 하네스-태스크 적합도(필요한 모델·툴에 post-train 되어 있는가, 필요한 기능·추상화 수준을 제공하는가)와 ② 유창성(실제로 다룰 줄 아는 하네스인가). 하네스가 매주 바뀌므로 구체적 추천 대신, 후보를 채점할 8가지 시간불변 질문을 던진다(컨텍스트 관리 / 외부 연결 / 프로덕션 행동 세 갈래로 묶임):
- 컨텍스트·상태(태스크 내) — 턴 간 상태를 유지하는가? 중단·재개는? 장기 호라이즌에서 컴팩션 메커니즘의 손실률은? 컨텍스트 로트를 막기 위한 서브에이전트 기동, 워크스트림 병렬화가 되는가?
- 메모리(태스크 간) — 세션 사이 무엇이 로컬 캐시/DB/원격 중 어디에 남고 언제 재사용되는가?
- MCP/툴 지원 — MCP 서버 확장이 가능한가(Clay 데이터 연동, Grafana 출력, Notion 인제스트 등)? 다른 앱과 얼마나 충실히 상호작용하는가? 원하는 툴콜 집합과 호환되는가?
- 표준 준수 — 오픈 스펙 vs 독점 구조. 예: OpenCode는 SQLite와 오픈 컨벤션, Claude Code는 전용 구조(claude.md, 전용 디렉터리, 자체 세션 히스토리 포맷). 오픈 표준은 이식성·낮은 lock-in을, 독점 구조는 더 긴밀한 통합을 대가로 마이그레이션을 어렵게 한다.
- 모델 선택 유연성 — 새 모델 엔드포인트를 쉽게 시도할 수 있는가? 설정/환경변수로 비네이티브 엔드포인트를 가리킬 수 있는가? 모든 모델이 하네스에서 똑같이 잘 작동하는가?
- 원격 접근 — 세션을 원격으로 접근할 수 있는가(예: Claude Code의
/remote-control)? 서드파티 없이도 노트북을 닫아도 세션이 유지되는가? - 관측성/디버깅 표면 — 로깅·트레이싱이 어떻게 되는가? 실패 모드를 잡을 수 있는가? 잘못된 방향으로 갈 때 조기 신호가 있는가? 이전 상태로 롤백하거나 자가복구할 수 있는가?
- 해커빌리티 스펙트럼 — 팀·회사를 위해 하네스를 결정하는 기술 의사결정자에게 핵심 질문. 의견이 많은(opinionated) 하네스는 마찰이 적고 엔터프라이즈에 잘 채택된다(예: Copilot). 의견이 적고 유연한 하네스는 잠재력이 크지만 보안취약점·과도한 토큰 소비 같은 함정도 크다(예: OpenClaw). 성숙한 조직이라면 팀을 위한 가드레일 있는 opinionated 옵션이 낫다 — 실패의 바닥은 치명적이지 않으면서 생산성의 천장은 최대한 열려 있는 지점을 찾는 게 스위트스팟이다. 해커블한 하네스는 유지보수자의 업스트림을 기다리지 않고 사용자 스스로 문제를 다듬을 수 있게 해준다.
하네스 엔지니어링의 미래: 라우팅과 서빙
프로토타이핑 시대를 지나 프로덕션 시대로 접어들며, 여러 모델을 지원·라우팅·오케스트레이션할 수 있는 하네스가 다음 이정표가 된다. 개인이든 팀이든 회사든 결국 어떻게 라우팅할지와 어떻게 서빙할지 두 결정으로 수렴한다.
서브에이전트 라우팅: Karpathy가 지적한 LLM의 들쭉날쭉한 지능(jagged intelligence) — 어떤 도메인은 초인적이고 다른 도메인은 형편없음 — 은 특화가 지배적 패러다임이 될 것이라는 결론으로 이어진다. 독립 서브에이전트로 태스크를 적합한 모델에 라우팅하는 것. 하네스 내부에 경량 분류기를 두고 비용 절감용 오픈소스 기본값, 지연시간/처리량 최적화된 파인튜닝 모델, 리뷰 패스용 프론티어 클로즈드 모델 중 어디로 보낼지 동적으로 결정하는 패턴이 늘고 있다. 이때 캐시 재사용에 신경 써야 한다 — 멀티턴 세션 안에서 모델을 바꾸면 캐시 히트를 놓칠 수 있으므로, 하네스 아키텍처도 캐시를 인지해 가능하면 워밍된 캐시로 요청이 가도록 해야 한다. 읽기 전용 태스크(조사·리서치)는 작고 빠른 모델의 서브에이전트(또는 그 사본 여러 개)로 병렬화할 수 있다. 이는 OOP가 클래스·캡슐화를 중심으로 조직됐듯 서브에이전트가 모듈화 패턴으로 작동한다는 시사점이며, 컨텍스트 로트가 출력 품질 저하·환각의 주요 원인이므로 여러 모델을 독립적으로 돌리는 편이 컨텍스트를 깨끗하게 유지한다.
성능을 위한 서빙: 라우팅이 갖춰지고 워크로드가 알맞은 지능에 매칭되면, 모델 자체의 성능이 곧 사용자 경험이 된다. 하네스뿐 아니라 에이전틱 유스케이스에 맞는 모델을 고르는 것도 똑같이 중요하다 — 예로 GLM 5.2는 품질·성능 양면에서 뛰어난 후보로 꼽힌다. BYO-model 하네스나 프록시는 태스크별로 최적의 모델-하네스 조합을 고를 유연성을 준다(LangChain의 Harness Profiles가 이 목적으로 만들어짐). 벤더와 무관하게 남는 원칙: 성능은 하네스-태스크 적합도의 일부이며, BYO-model이 그것을 통제하는 방법이다. 보장된 rate limit·버스트 처리·가동시간이 필요하다면 자체 오픈/커스텀 모델 호스팅이 답이고, 전용 인프라라야 캐싱·배칭·디스어그리게이션을 통제해 품질을 희생하지 않고 응답성을 짜낼 수 있다.
결론
하네스는 원사이즈핏올이 아니다. 구체적 추천은 하네스가 추가·폐기되며 금세 낡으므로, 대신 시간이 지나도 유효한 질문들을 남긴다. 결국 하네스의 우수한 속성들은 점차 표준화·상품화되어 모든 하네스가 직관적으로 쓰이게 될 것이고, 적절한 모델로의 라우팅과 고성능 서빙은 하네스 자체에 흡수되어 표준 기능(table stakes)이 될 것이라는 전망으로 글을 맺는다. 실천적 조언은: (거대한 컨텍스트를 위한 강한 컴팩션, 멀티모델 상호운용성, 원격 접근 등) 자신의 비타협 조건을 정하고, 하나의 하네스에 유창해져라 — 유창함이 생기면 그 하네스를 포크·수정·지휘하는 방법도 함께 따라온다.