'더 똑똑한 모델'을 기다리는 시간 동안, 누군가는 지금 가진 모델로 이미 앞서 나가고 있다. Addy Osmani가 정리한 '하네스 엔지니어링(Harness Engineering)' 개념은 이 불편한 사실을 벤치마크 데이터로 정면에서 꺼낸다. 같은 Claude Opus 모델을 쓰더라도 하네스만 바꿨더니 터미널 벤치 30위권에서 5위권으로 뛰어올랐다는 사례다. 모델이 가진 잠재력을 깎아 먹고 있는 건 모델 자체가 아니라, 그 모델을 감싸고 있는 환경 설계의 빈틈이었다.
하네스란 무엇인가. 모델을 제외한 모든 것이다. 시스템 프롬프트, 도구와 외부 서버, 컨텍스트 관리 정책, 자동 점검 장치(훅), 샌드박스, 서브에이전트, 피드백 루프, 복구 흐름까지 전부 포함한다. Viv Trivedy의 정식화를 빌리면 AI 에이전트 = 모델 + 하네스다. Claude Code, Cursor, Codex, Aider, Cline 같은 제품은 모두 하네스이고, 그 안에 들어가는 모델이 동일하더라도 우리가 체감하는 행동은 하네스가 결정한다. '모델이 엉뚱한 짓을 한다'는 진단보다 '설정이 잘못됐다'는 진단이 먼저여야 하는 이유다.
이 관점을 실무 도구 차원에서 가장 직접적으로 구현한 것이 오픈소스 IDE Superset이다. 멀티 코딩 에이전트를 병렬로 운용할 때 부딪히는 가장 큰 문제는 에이전트들이 서로의 파일을 밟는 충돌이다. Superset은 이 문제를 git worktree로 해결한다. 각 에이전트는 같은 리포지토리와 히스토리를 공유하지만, 별도의 작업 디렉터리와 브랜치를 갖는다. Agent A가 파일을 수정해도 Agent B에게는 영향이 없다. 충돌은 구조적으로 불가능하다.
격리된 환경만큼 중요한 건 리뷰 가능성이다. Superset의 통합 대시보드는 모든 활성 에이전트가 무엇을 건드리고 있는지를 한눈에 보여 주고, 주의가 필요할 때 알림을 보낸다. 빌트인 diff 뷰어는 에이전트별 변경 사항을 사이드바이사이드로, 신택스 하이라이팅과 함께 보여 준다. 머지 전에 실제로 무엇이 만들어졌는지 검토할 수 있다는 것, 이게 워크플로우의 안전망이다. Claude Code, Codex, Cursor Agent, Gemini CLI, GitHub Copilot 등 에이전트에 구애받지 않고, 자신의 키와 모델과 프로바이더를 그대로 쓴다. 로컬 퍼스트다.
하네스 설계에서 놓치기 쉬운 또 하나의 차원이 컨텍스트 관리다. AI는 읽을 수 있는 양의 한계에 가까워질수록 판단력이 눈에 띄게 떨어진다(컨텍스트 부패, context rot). Osmani가 정리한 하네스 엔지니어링은 이 문제에 세 가지 장치로 대응한다. 한도가 찰 때 오래된 내용을 요약·압축하는 것, 대용량 출력은 머리와 꼬리만 남기고 파일로 빼 두는 것, 필요한 도구와 지시문을 필요한 순간에만 꺼내는 '점진적 공개'다. 정말 긴 작업에서는 아예 새 컨텍스트 창에서 구조화된 인수인계 문서만 들고 다시 시작한다. 인간 조직에서 신입에게 업무를 넘길 때 문서를 정리해 주는 방식과 같다.
이 흐름의 끝에는 MCP(Model Context Protocol) 기반 자동화가 있다. 국내 웹빌더 플랫폼 식스샵이 MCP를 무료 플랜까지 전면 개방한 것은 단순한 가격 정책 변화가 아니다. Claude, Cursor, ChatGPT, Gemini CLI 같은 AI 도구가 식스샵을 직접 제어하고, Figma·Google Stitch 같은 디자인 툴과 연동해 디자인 결과물을 실제 웹사이트로 즉시 구현·배포할 수 있다는 의미다. 자연어만으로 기획→디자인→구현의 전 과정을 자동화하는 파이프라인이 현실화되고 있다. 이 파이프라인의 핵심은 Claude가 얼마나 똑똑한가가 아니라, 식스샵이라는 환경이 Claude의 행동을 얼마나 명확하게 정의하느냐다.
세 흐름을 나란히 놓으면 하나의 패턴이 보인다. 하네스 엔지니어링은 '모델 탓' 대신 '설정 탓'을 선택하고, Superset은 병렬 에이전트의 충돌을 구조적으로 막으며, MCP 기반 플랫폼은 에이전트가 닿을 수 있는 영역을 환경 차원에서 확장한다. 모두 모델 선택이 아니라 배치 설계의 문제다. Osmani가 인용한 표현처럼, '오늘 보이는 AI의 한계와 모델이 실제로 가진 능력 사이의 간극은 대부분 하네스 간극'이다.
프론트엔드 개발자 입장에서 이 흐름이 실무에 던지는 질문은 구체적이다. AGENTS.md를 60줄 이하로 유지하고 있는가? 훅이 '말해 두는 것'이 아니라 '시스템이 강제하는 것'으로 작동하고 있는가? 에이전트가 저지른 실수를 규칙 문서에 한 줄씩 더해 가는 래칫 루프가 팀에 돌아가고 있는가? Superset의 .superset/setup.sh처럼 새 에이전트 워크스페이스가 자동으로 구성되는 셋업이 리포지토리에 있는가?
모델은 계속 좋아진다. 그런데 모델이 좋아질수록 하네스가 사라지는 게 아니라, 하네스가 다루는 문제의 층위가 한 단계 위로 옮겨 간다. Claude Opus 4.6가 컨텍스트 조급증을 없애자 그 자리를 메우던 안심용 보조 장치들이 죽은 코드가 됐지만, 새로 닿게 된 영역에는 새로운 약점이 생겼고 새로운 하네스가 필요해졌다. 지금 화제가 되는 모델을 매번 갈아 끼우는 일보다, 자기 작업에 맞는 하네스를 끊임없이 손보면서 모델이 닿는 천장을 한 칸씩 끌어올리는 작업이 더 오래 남는 경쟁력이다. 좋은 에이전트를 만드는 일은 반복의 예술이고, 첫 버전이 없으면 반복도 없다.