며칠 전 Aakash Gupta의 미디엄 아티클 “2025 Was Agents. 2026 Is Agent Harnesses“를 읽고 상당히 흥미로운 개념을 접하게 됐습니다. 바로 ‘Agent Harness(에이전트 하니스)’입니다. AI PM 분야에서 독보적 콘텐츠를 쌓고 있는 Gupta는 2026년 AI 에이전트 시장의 승패를 가르는 핵심이 모델이 아니라 하니스에 있다고 주장합니다.

처음에는 다소 생소한 개념이었지만, 그의 논리와 실제 사례들을 살펴보니 상당히 설득력이 있었습니다. 특히 AI 기반 제품을 준비 중인 창업자라면 반드시 이해해야 할 개념이라는 생각이 들었습니다. 그래서 이번 포스팅에서 에이전트 하니스가 어떤 의미인지, 그리고 AI 기반 제품을 준비하는 창업자가 어떤 부분을 염두해야 하는지 Gupta의 글의 주요 내용 요약 중심으로 정리하고자 합니다.

하니스(Harness)란 원래 말이나 가축을 제어하기 위해 착용하는 ‘마구(馬具)’를 의미합니다. AI 에이전트 맥락에서 하니스는 모델을 감싸서 장기 실행 작업을 신뢰성 있게 관리하는 시스템을 뜻합니다. 쉽게 비유하자면, 모델이 강력한 엔진이라면 하니스는 조향장치, 브레이크, 안전장치를 갖춘 완성된 자동차라고 할 수 있습니다.

출처 : https://aakashgupta.medium.com/2025-was-agents-2026-is-agent-harnesses-heres-why-that-changes-everything-073e9877655e

Gupta가 강조하는 핵심 메시지는 명확합니다. 2025년까지는 모델의 성능이 경쟁우위였지만, 2026년부터는 하니스의 품질이 진짜 차별화 요소가 된다는 것입니다. GPT-4, Claude, Gemini의 성능이 수렴하는 상황에서, 동일한 모델을 어떻게 감싸고 제어하느냐가 AI 에이전트 비즈니스의 성패를 좌우한다는 주장입니다.

이 글을 읽으며 프로젝트 지식에 정리해둔 ‘AI 기반 제품의 시장 정의’, ‘데이터 전략’ 콘텐츠와 자연스럽게 연결되었습니다. AI 기반 제품은 단순히 모델을 호출하는 Wrapper가 아니라, 특정 과업(Job)을 안정적으로 수행하는 시스템이어야 합니다. 그리고 그 안정성의 핵심이 바로 하니스에 있다는 것을 깨달았습니다.

본 글에서는 Gupta의 아티클에서 소개된 개념과 사례들을 바탕으로, AI 에이전트 스타트업이 왜 모델이 아닌 하니스에 집중해야 하는지 세 가지 이유를 정리하고, 초기 스타트업이 실제로 어떻게 하니스를 구축할 수 있는지 살펴보겠습니다. AI Wrapper 비즈니스를 준비 중이거나, AI 에이전트 제품 개발을 고려하는 창업자라면 이 개념을 이해하고 전략에 반영하는 것이 필요합니다.

이유 1: 모델은 상품화되고 있지만, 하니스는 구축 가능한 경쟁우위입니다

모델 시장의 상품화 가속

Gupta는 “모델은 상품(Commodity)이다”라고 단언합니다. 실제로 AI 모델 시장은 빠르게 상품화되고 있습니다. GPT-4, Claude Sonnet, Gemini Pro의 성능 차이는 점점 줄어들고 있으며, 6개월이면 경쟁력 있는 모델을 학습할 수 있는 시대가 되었습니다. 오픈소스 모델의 발전 속도도 놀랍습니다. Llama, Mistral과 같은 오픈소스 모델들이 상업용 모델과 비슷한 성능을 보여주고 있습니다.

이는 모델 자체가 더 이상 지속 가능한 경쟁우위가 될 수 없음을 의미합니다. Hugging Face에서 모델을 다운로드하거나, API를 호출하는 것만으로는 차별화된 가치를 제공할 수 없습니다. 모든 경쟁사가 동일한 모델에 접근할 수 있다면, 승부는 다른 곳에서 결정됩니다.

하니스가 만드는 구조적 이점

Gupta가 제시하는 대안이 바로 하니스입니다. 하니스는 모델을 감싸서 실제 작업을 신뢰성 있게 수행하도록 만드는 시스템입니다. 그는 하니스의 6가지 핵심 컴포넌트를 제시합니다.

첫째, 중요한 결정에서 인간의 승인을 받는 휴먼-인-더-루프 제어(Human-in-the-loop)입니다. 데이터베이스 삭제나 고객 이메일 발송 같은 중요한 작업 전에 반드시 확인을 받습니다.

둘째, 파일시스템과 데이터베이스 접근을 관리하는 보안 시스템(Filesystem Access)입니다. 어떤 디렉터리에 접근할 수 있고, 어떤 작업이 허용되는지를 정확히 제어합니다.

셋째, 무한 루프와 연쇄 실패를 방지하는 툴 호출 오케스트레이션(Tool Orchestration)입니다. 올바른 툴을 올바른 시간에 올바른 순서로 호출하도록 관리합니다.

출처 : https://aakashgupta.medium.com/2025-was-agents-2026-is-agent-harnesses-heres-why-that-changes-everything-073e9877655e

넷째, 복잡한 작업을 나누어 처리하는 서브 에이전트 조율(Sub-agent Coordination)입니다. 하나의 에이전트가 조사하고, 다른 에이전트가 작성하며, 세 번째 에이전트가 검토하는 식으로 전문화된 작업 분담이 가능합니다.

다섯째, 작업별로 최적화된 프롬프트를 관리하는 프롬프트 프리셋 시스템(Prompt Presets)입니다. 코드 리뷰와 코드 생성, 버그 수정과 기능 개발은 서로 다른 지시가 필요합니다.

여섯째, 재시도 로직과 에러 핸들링을 포함한 라이프사이클 관리(Lifecycle Hooks)입니다. 실패를 감지하고, 복구하며, 필요시 인간에게 폴백하는 메커니즘입니다.

출처 : https://aakashgupta.medium.com/2025-was-agents-2026-is-agent-harnesses-heres-why-that-changes-everything-073e9877655e

이러한 하니스를 구축하는 데는 수천 시간의 엔지니어링이 필요합니다. Gupta가 인용한 사례에서 Manus는 6개월 동안 하니스를 5번 재작성했고, LangChain은 1년 동안 4번의 아키텍처 재설계를 단행했습니다. 실패하고, 학습하고, 재구축하는 반복적 과정을 거쳐야 합니다. Hugging Face에서 다운로드할 수 없고, 단기간에 모방할 수도 없습니다. 이것이 바로 하니스가 지속 가능한 경쟁우위가 되는 이유입니다.

이유 2: 실제 성공 사례들이 하니스의 중요성을 증명합니다

Manus: 동일한 모델, 5가지 아키텍처

Gupta는 Manus의 사례를 첫 번째로 소개합니다. Manus는 AI 에이전트 플랫폼을 개발하면서 6개월 동안 하니스를 5번 재작성했습니다. 흥미로운 점은 사용한 모델은 처음부터 끝까지 동일했다는 것입니다. 변한 것은 오직 하니스 아키텍처였습니다. 그리고 각 재작성마다 안정성이 개선되었고, 작업 완료율이 높아졌습니다.

첫 번째 버전에서는 단순한 프롬프트 체인으로 시작했지만, 복잡한 작업에서 실패율이 높았습니다. 두 번째 버전에서는 상태 관리를 추가했지만, 서브 작업 간 조율 문제가 발생했습니다. 세 번째 버전에서는 에러 핸들링을 강화했지만, 성능 병목이 생겼습니다. 네 번째와 다섯 번째 재작성을 거치며 비로소 프로덕션 수준의 안정성을 확보했습니다.

이 사례가 시사하는 바는 명확합니다. 모델 성능은 처음부터 충분했지만, 실제 프로덕션에서 안정적으로 작동하게 만드는 것은 하니스의 몫이었습니다.

LangChain: 워크플로우 구조의 진화

LangChain의 Deep Research 개발 과정도 비슷합니다. 1년 동안 4번의 아키텍처 재설계를 했지만, 모델이 개선되어서가 아닙니다. 워크플로우 구조, 컨텍스트 관리, 서브 작업 조율의 더 나은 방법을 발견했기 때문입니다.

초기 아키텍처는 단일 에이전트가 모든 조사 작업을 처리했습니다. 그러나 복잡한 주제에서는 컨텍스트가 너무 길어져 효율이 떨어졌습니다. 두 번째 아키텍처에서는 여러 조사 에이전트로 작업을 분산했지만, 결과를 통합하는 과정에서 일관성 문제가 발생했습니다. 세 번째와 네 번째 재설계를 통해 효과적인 서브 에이전트 조율 메커니즘을 구축했고, 이것이 현재의 안정적인 Deep Research 기능으로 이어졌습니다.

Vercel: 80% 제거를 통한 성능 개선

Gupta가 가장 강조하는 사례는 Vercel입니다. Vercel은 AI 에이전트가 사용하는 툴의 80%를 제거하고 오히려 더 나은 결과를 얻었습니다. 처음에는 포괄적인 툴 라이브러리를 제공했습니다. 검색, 코드 생성, 파일 조작, API 호출 등 모든 기능을 갖췄습니다. 그러나 결과는 예상과 달랐습니다. 에이전트는 너무 많은 선택지 앞에서 혼란스러워했고, 중복된 호출을 반복했으며, 불필요한 단계를 밟았습니다.

Vercel은 과감하게 필수 툴만 남기고 나머지를 제거했습니다. 중복 옵션을 정리하고, 결정 트리를 단순화했습니다. 결과는 놀라웠습니다. 더 적은 툴로 더 빠르고 신뢰성 있는 성능을 달성했습니다. 더 적은 단계, 더 적은 토큰 사용, 더 빠른 응답 시간, 그리고 더 높은 작업 성공률이라는 결과를 얻었습니다.

이는 Gupta가 강조하는 하니스 설계의 핵심 원칙을 보여줍니다. ‘모델의 길을 비우는 것(Getting out of the model’s way)’입니다. 모델은 충분히 똑똑합니다. 하니스는 재앙적 실패만 방지하고, 나머지는 모델에게 맡기는 것이 오히려 효과적일 수 있습니다.

이유 3: 하니스는 모델 발전과 함께 더욱 중요해집니다

기능 확장이 가져오는 복잡성

Gupta는 흥미로운 역설을 지적합니다. 더 나은 모델은 하니스를 덜 중요하게 만들지 않습니다. 오히려 더 중요하게 만듭니다. 모델의 기능이 확장될수록 처리할 수 있는 작업의 범위가 넓어지고, 이는 곧 더 많은 실패 모드(Failure Mode)를 의미합니다. 더 많은 실패 모드는 더 정교한 에러 핸들링과 복구 메커니즘을 필요로 합니다.

예를 들어, 파일 시스템에 접근할 수 있는 에이전트는 중요한 시스템 파일을 실수로 삭제할 위험이 있습니다. 데이터베이스를 조작할 수 있는 에이전트는 잘못된 쿼리로 전체 데이터를 손상시킬 수 있습니다. 외부 API를 호출할 수 있는 에이전트는 과도한 요청으로 비용 폭탄을 만들 수 있습니다. 모델이 똑똑해질수록 이런 위험을 감지하고 방지하는 하니스의 역할이 더 중요해집니다.

비용 최적화와 신뢰성 확보

더 강력한 모델은 더 비쌉니다. GPT-4o, Claude Opus와 같은 최신 모델은 이전 세대보다 훨씬 높은 API 비용을 요구합니다. 모든 작업에 최고 성능 모델을 사용하는 것은 비효율적입니다. 좋은 하니스는 작업의 복잡도를 평가하고, 간단한 작업은 저렴한 모델로, 복잡한 작업은 비싼 모델로 라우팅합니다.

프로덕션 환경은 99.9% 가동 시간을 요구합니다. 그러나 모델은 본질적으로 확률적입니다. 동일한 입력에도 다른 결과를 낼 수 있고, 때로는 예상치 못한 방식으로 실패합니다. 하니스는 이러한 불확실성을 관리합니다. 재시도 로직으로 일시적 실패를 극복하고, 폴백 메커니즘으로 대안 경로를 제공하며, 검증 단계로 출력의 품질을 보장합니다.

초기 스타트업을 위한 하니스 MVP 구축 가이드

Gupta의 아티클을 읽으며 가장 실용적이라고 느낀 부분은 구체적인 구축 가이드였습니다. 그가 제시하는 방법론을 초기 스타트업 관점에서 정리하면 다음과 같습니다.

하나의 작업에 집중하기

하니스 구축의 첫 단계는 하나의 명확한 작업에 집중하는 것입니다. 고객에게 실질적인 가치를 제공하는 단일 에이전트 작업을 선택해야 합니다. 그 작업을 신뢰성 있게 수행하는 최소한의 하니스를 만드는 것이 목표입니다. 처음부터 모든 기능을 갖춘 완벽한 하니스를 만들려고 하지 마세요. 대신 핵심 작업 하나를 끝에서 끝까지 완성하는 데 집중해야 합니다.

모든 것을 측정하기

Gupta는 “측정하지 않는 것은 개선할 수 없다”고 강조합니다. 모든 툴 호출, 에러 발생, 인간 개입, 타임아웃을 기록해야 합니다. 초기에는 간단한 로깅으로 시작하되, 점차 구조화된 모니터링 시스템으로 발전시켜야 합니다. 어떤 작업에서 실패가 자주 발생하는지, 어떤 툴이 비효율적인지, 사용자가 어디서 개입하는지를 파악해야 합니다.

실패 모드 기반 반복

프로덕션에 배포한 후 실패 사례를 수집해야 합니다. 각 실패는 누락된 가드레일을 드러냅니다. 실패 패턴을 분석하고, 그에 맞는 안전장치를 추가하세요. 다시 배포하고, 다음 실패 모드를 찾으세요. 이 반복적 과정을 통해 하니스는 점점 견고해집니다.

활동이 아닌 결과에 집중

얼마나 많은 활동을 했는지 관리하는 것이 아니라 이 에이전트가 만들어 낸 결과에 집중해야 합니다. 토큰 수가 아니라 작업 완료를, 속도가 아니라 만족도를 그리고 기능이 아니라 신뢰성을 최적화해야 합니다.

세 가지 설계 원칙 적용

Gupta가 제시하는 세 가지 하니스 설계 원칙을 기억하세요. 첫째, 최소 필요 개입 원칙입니다. 모델이 스스로 수정할 수 있는 경우에는 개입하지 마세요. 되돌릴 수 없는 작업이나 보안 경계에서만 개입하세요. 둘째, 점진적 공개 원칙입니다. 제한된 툴과 권한으로 시작하고, 작업이 필요로 할 때만 확장하세요. 셋째, 빠른 실패와 복구 원칙입니다. 실패를 신속히 감지하고, 에이전트가 무한 루프에 빠지지 않도록 하며, 실패 시 명확한 복구 경로를 제공해야 합니다.

결론

Aakash Gupta의 아티클을 통해 접한 하니스 개념은 AI 에이전트 비즈니스를 준비하는 창업자에게 중요한 시사점을 제공합니다. 2026년 AI 에이전트 시장에서 승자와 패자를 가르는 것은 모델이 아닙니다. 모델은 이미 상품화되었고, 누구나 접근할 수 있습니다. 진정한 차별화는 하니스에서 나옵니다.

Manus, LangChain, Vercel의 사례가 증명하듯, 하니스 구축에 투자한 기업들이 지속 가능한 경쟁우위를 만들고 있습니다. 수천 시간의 엔지니어링과 반복적 개선을 통해 구축된 하니스는 경쟁사가 쉽게 모방할 수 없는 자산이 됩니다.

AI 기반 제품을 준비 중이라면 아마 LLM 대비 어떤 부분에서 경쟁우위를 갖췄는지 혹은 해자(Moat)는 무엇인지에 대한 챌린지를 준비해야 합니다. AI-driven Product를 만드는 스타트업이 갖춰야 할 해자로써 하니스에 보다 집중해보시길 바랍니다. 모델 선택에 과도한 시간을 쓰는 대신 하나의 작업을 선택하고, 그것을 신뢰성 있게 수행하는 하니스를 만드는데 집중하는 것입니다.

감사합니다.