하니스(Harness). AI 에이전트가 올바르게 작동하도록 제어하는 모든 시스템의 총합이다. 지시 문서, 검증 루프, 외부 통합, 스코어링, 지식 축적, 격리 환경, 메모리, 권한 설정 — 에이전트 출력의 품질을 결정하는 모든 것.
하니스가 왜 중요한가.
Gemini 모델을 Claude Code의 하니스 위에서 돌리면 성능이 올라간다. 같은 Opus라도 하니스 없이 돌리면 성능이 떨어진다. 모델은 같은데 결과가 다르다. 모델이 아니라 하니스가 결과를 결정한다.
소프트웨어 엔지니어링의 세 번째 패러다임 전환이 진행 중이다. 천공카드에서 키보드로 — 물리적 제약에서 벗어났다. 로컬 에디터에서 클라우드로 — 배포와 확장의 혁명. 그리고 지금, 코드 작성에서 의미 전달로. 인간이 "무엇을" 정의하면 에이전트가 "어떻게"를 실행한다. 이 전환의 핵심에 하니스가 있다.
빌더에서 설계자로
이 전환은 엔지니어의 역할을 근본적으로 바꾼다. 코드를 직접 짜는 빌더에서, 시스템을 설계하는 설계자로.
두 가지 활동이 중심이 된다.
Planning — 하고자 하는 바를 구체화하는 과정이다. 어떤 스펙으로 만들지, 어떤 가이드라인을 줄지. 구체적으로 작성할수록 AI와의 alignment가 명확해진다. "좋은 코드 짜줘"는 아무 의미 없다. 어떤 아키텍처 패턴으로, 어떤 에러 핸들링 전략으로, 어떤 수준의 테스트 커버리지로, 어떤 네이밍 컨벤션으로 — 이 수준의 구체성이 결과를 가른다. CLAUDE.md에 프로젝트의 원칙을 쓰고, 스펙 문서로 각 기능의 요구사항을 명시하고, 아키텍처 문서로 시스템의 경계를 정의하는 것. 이것이 새로운 "코딩"이다.
Review — 결과물의 달성도를 평가하는 과정이다. 원하는 결과가 구체적일수록 스코어링 기준을 세울 수 있고, 체크리스트로 품질을 올릴 수 있다. 핵심은 이 과정에서 나의 감도, 암묵지, 평가 방식이 명시화된다는 것이다. 에이전트는 이 기준으로 품질을 개선한다. 내 머릿속에만 있던 "이건 아닌데"가 문서화되는 순간, 에이전트의 출력이 달라진다. "에러 메시지가 유저 친화적이지 않다"는 피드백을 "에러 메시지는 기술 용어 없이, 유저가 취할 수 있는 다음 행동을 반드시 포함해야 한다"로 바꾸는 것 — 이것이 암묵지의 명시화다.
결국 이 전체 과정이 하는 일은 두 가지다. 업무를 수행할 에이전트들의 스킬과 협업 방식을 구체화하고, 결과물에 대한 내 taste를 기준으로 만들어 에이전트가 학습하게 하는 것.
시간 배분이 뒤집힌다. 코드 작성 20%, 계획과 리뷰 80%. Dan Shipper(Every)의 말처럼 — "Plans are the new code."
왜 이렇게 되는가. 코드의 가치가 0에 수렴하기 때문이다. 에이전트가 만드는 코드의 양을 보라. Lablup은 50개 에이전트로 40일 만에 100만 줄을 생성했다. "코드를 잘 짜는 것"의 시장 가치는 빠르게 떨어지고 있다. 남는 건 무엇을 만들지 결정하는 능력, 그리고 그것을 올바르게 만드는 시스템을 설계하는 능력이다.
하지만 볼륨이 커질수록 위험도 커진다. AI Slop — 아무도 읽지 않고, 아무도 이해하지 못하는 코드가 코드베이스에 쌓이는 현상. 에이전트가 만든 코드를 사람이 검증하지 않으면 코드베이스는 빠르게 취약해진다. Planning과 Review가 중요한 이유가 여기에 있다. Planning으로 에이전트가 만들 코드의 방향을 통제하고, Review로 출력의 품질을 검증한다. 이 두 활동이 AI slop의 해독제다.
하니스의 구성요소
하니스는 단일 도구가 아니다. 시스템의 집합이다.
기본 요소들이 있다. 지시 문서(CLAUDE.md, Soul Documents) — 에이전트의 "헌법". 프로젝트의 원칙, 코딩 컨벤션, 금지 사항을 정의한다. 검증 루프(테스트, 린터, pre-commit hooks) — 에이전트가 스스로를 검증하는 메커니즘. 외부 통합(Sentry, Datadog, LaunchDarkly) — 에이전트가 개발자와 동일한 맥락을 이해하고 같은 제품을 사용할 수 있는 환경. 스코어링 체계 — 에이전트 출력의 품질을 정량화한다. 지식 축적(solutions DB, YAML 프론트매터) — 해결된 문제의 교훈이 축적되어 다음 사이클을 더 빠르게 만든다. 격리 환경(샌드박스, Docker) — 에이전트가 안전하게 실험할 수 있는 공간.
그리고 아직 확장 중인 영역이 있다. 메모리 관리(세션 간 맥락 유지), 권한과 환경 설정(에이전트에게 어디까지 허용할 것인가), 도구 사용 가이드(어떤 도구를 어떤 순서로, 어떤 상황에서 사용하게 할 것인가), 오케스트레이션(서브에이전트 스포닝, 에이전트 팀 위임과 검증).
이 요소들의 조합이 하니스의 품질을 결정하고, 하니스의 품질이 에이전트 출력의 품질을 결정한다.
제품들이 보여주는 하니스 철학
하니스 관점에서 보면, 지금 나오는 제품들은 각자 다른 철학으로 같은 문제를 풀고 있다.
Manus는 긴 작업의 라스트마일 품질에 집중했다. 딥리서치, 엑셀 데이터 분석, PPT 작성 — 사람이 시작하면 지루하고, AI에게 맡기면 80%까지는 금방이지만 마지막 20%에서 무너지는 작업들. 대부분의 AI 도구가 "80%까지 빠르게"에 집중할 때, Manus의 하니스는 나머지 20%를 고객이 실제로 제출할 수 있는 수준까지 끌어올리는 데 맞춰져 있다. 이 라스트마일이 진짜 어렵고, 여기서 하니스의 차이가 드러난다.
Claude Code는 로컬 퍼스트를 선택했다. 유저의 환경에서 시작하고, 길을 찾아주고, 선택지를 준다. 에이전트가 모든 걸 대신하는 게 아니라 인간과 함께 진화한다. CLAUDE.md, hooks, slash commands — 하니스 도구를 유저가 직접 설계하게 한 것이 핵심이다. 로컬에서 시작한 초기 결정이 탁월했다. 유저의 코드, 유저의 환경, 유저의 맥락 위에서 작동하기 때문에 하니스의 커스터마이징이 자연스럽다.
Codex는 정반대다. "내가 다 알아서 할게." 완전 자율 지향. 인간의 개입을 최소화하고 에이전트가 독립적으로 작업을 완수한다. 하니스의 주도권이 유저가 아닌 시스템에 있다.
OpenClaw는 개인 비서의 가능성을 보여줬다. 로컬에서, 가장 편한 인터페이스에서, 여러 앱을 실행해주는 경험. 코딩만이 아니라 일상 업무 전반을 에이전트가 처리할 수 있다. 올해 더 많은 사람들이 에이전트로 일상을 처리하면서 기존 앱을 직접 여는 시간이 줄어들 것이다.
기업들도 각자의 하니스를 설계했다. Ramp은 에이전트에게 자기 검증 능력을 줬다 — Sentry, Datadog, LaunchDarkly를 직접 연결한 closed-loop으로 PR이 인간에게 도달하기 전에 검증을 완료한다. PR의 30%가 에이전트에서 나온다. Uber는 생성 모델(Claude Sonnet)과 평가 모델(o4-mini)을 분리했다. 만드는 AI와 채점하는 AI가 다르다 — 자기 평가 편향을 구조적으로 차단. 주간 1,500시간 절약, 수정 반영률 65%로 인간 리뷰어(51%)를 넘었다. Every는 매 사이클의 교훈이 CLAUDE.md에 자동 축적되는 복리 구조를 만들었다 — 1인 팀이 5개 프로덕트를 운영한다. 사이클을 돌릴수록 시스템이 똑똑해진다. Lablup은 50개 에이전트로 40일 만에 100만 줄, 764 PR을 자동 처리했다. AI가 인간에게 "이 기술을 공부하세요"라고 학습 과제를 제시하는 역방향 지식 전이가 특히 인상적이다.
아직 풀리지 않은 과제들
솔직히 아직 부족한 게 많다.
메모리가 가장 큰 난제다. OpenClaw는 append-only markdown으로 메모리를 관리하는데, 세션이 길어지면 맥락을 잊는다. Manus는 세션 내 메모리가 뛰어나지만 세션 간 기억이 없다. Claude Code도 마찬가지. Hyperspell, Letta, Mem0, qmd, Supermemory — 수많은 팀이 이 문제를 풀고 있다. Markdown, SQLite, 벡터 DB, 그래프 DB — 어떤 조합이 맞는지 아직 아무도 모른다. 하니스의 가장 불안정한 레이어다.
긴 브라우저 세션과 도구 사용도 한계가 분명하다. 에이전트가 일정시간 넘게 웹을 탐색하면 맥락이 흐려지고, 도구 사용의 정확도가 떨어진다.