모델이 좋아질수록 모두가 비슷해질 것 같지만, 실제 시장은 꼭 그렇게 움직이지 않는다. 오히려 일정 수준 이상으로 모델 성능이 올라오면, 차이는 모델 자체보다 모델을 둘러싼 실행 환경에서 더 크게 벌어진다. 사용자는 "가장 똑똑한 모델"을 사는 것이 아니라, "내 일을 끝까지 맡길 수 있는 제품"을 사기 때문이다.1
같은 모델을 써도 어떤 팀의 제품은 믿고 맡길 수 있고, 어떤 팀의 제품은 데모까지만 근사하다. 이 차이를 만드는 것이 바로 하네스다. 다시 말해 앞으로의 경쟁은 엔진 마력만 겨루는 경주가 아니라, 엔진을 어떤 차체에 얹고 어떤 도로에서 달리게 하며 어떤 브레이크와 계기판을 붙였는지 겨루는 경주에 가깝다.

모델이 평준화될수록 제품 차이는 더 커진다
초기에는 모델 자체가 곧 제품처럼 보였다. 더 큰 모델, 더 높은 벤치마크 점수, 더 자연스러운 답변이 바로 경쟁력이었다. 하지만 지금은 많은 과업에서 상위권 모델들이 이미 "쓸 만한 수준"을 넘어섰다. 코드 작성, 문서 초안, 요약, 기본 분석 같은 작업에서는 모델의 절대 성능 차이보다 장기 실행에서의 안정성, 도구 사용 정확도, 실패 복구 능력이 사용자 경험을 더 크게 좌우한다.1
여기서 중요한 변화가 생긴다. 모델 성능이 조금 더 좋아지는 것만으로는 사용자 만족이 크게 뛰지 않는다. 반대로 하네스를 잘 설계하면 같은 모델로도 성공률, 속도, 비용, 신뢰도가 눈에 띄게 달라진다. 모델이 평준화된다는 말은 차별화가 사라진다는 뜻이 아니다. 차별화의 위치가 바뀐다는 뜻이다.
이제 경쟁력은 "무슨 모델을 썼는가"보다 "그 모델이 어떤 작업장에서 일하는가"로 이동한다. 같은 엔진을 얹어도 어떤 차는 장거리 레이스를 완주하고, 어떤 차는 첫 코너에서 멈춘다. 사용자에게 중요한 것은 엔진 이름이 아니라 완주 여부다.
같은 모델인데 왜 다른 제품이 나오는가
두 회사가 같은 모델 API를 쓴다고 해서 같은 제품이 되지는 않는다. 실제 차이는 모델이 호출되기 전과 후에 벌어지는 일에서 만들어진다. 모델은 스스로 제품이 아니라, 제품 안에서 일하는 한 구성 요소일 뿐이다.
어떤 제품은 모델에게 너무 많은 도구를 한꺼번에 쥐여 준다. 어떤 제품은 필요한 도구만 정리해서 준다. 어떤 제품은 문서를 잔뜩 밀어 넣고 끝낸다. 어떤 제품은 작업 목적에 맞게 컨텍스트를 압축하고 최신성과 우선순위까지 정리해 준다. 어떤 제품은 한 번의 출력으로 끝내지만, 어떤 제품은 중간 점검과 검증 단계를 거친다. 이 차이가 곧 결과물의 차이가 된다.
경영 현장에서도 비슷한 관찰이 나온다. 비슷한 AI 모델에 접근할 수 있는 기업들 사이에서 실제 격차를 만드는 것은 일반 지식이 아니라 각 회사만의 맥락, 즉 내부 데이터, 업무 흐름, 고객 관계, 그리고 사용자가 실제로 일하는 접점이다.23 같은 모델이어도 어떤 제품은 고객의 문맥 속으로 깊게 들어가고, 어떤 제품은 겉면만 스친다. 그래서 결과가 달라진다.
첫 번째 경쟁력은 운영 맥락이다
모델이 공용 인프라에 가까워질수록, 기업의 진짜 자산은 운영 맥락이 된다. 운영 맥락은 단순히 데이터베이스에 쌓인 데이터가 아니다. 어떤 정보가 중요한지, 어떤 순서로 판단해야 하는지, 무엇을 예외로 봐야 하는지, 언제 사람에게 넘겨야 하는지를 포함한 살아 있는 업무 문법이다.
이 맥락은 대개 세 층으로 쌓여 있다. 첫째는 내부 데이터다. 모델은 공개 웹의 평균적인 지식은 많이 알지만, 당신의 계약 구조, 고객 이력, 내부 정책, 실패 사례는 모른다. 둘째는 도메인 전문성이다. 숙련자가 암묵적으로 알고 있는 판단 기준이 구조화되어 있지 않으면 에이전트는 그 조직의 방식으로 일할 수 없다. 셋째는 배치 위치, 즉 사용자가 실제로 일하는 표면적이다. 사용자가 매일 여는 화면, 메일, CRM, 코드 저장소, 문서 편집기 안에 자연스럽게 들어가는 제품이 훨씬 강하다.3
여기서 한 가지 더 중요한 사실이 있다. 이제 지식 문서는 사람만 읽는 문서가 아니라, 에이전트도 읽을 수 있는 문서여야 한다.3 사람에게는 이해되는 스크린샷, 두루뭉술한 회의 메모, 암묵적인 약속은 에이전트에게는 거의 소음에 가깝다. 따라서 경쟁력 있는 조직은 지식을 많이 가진 조직이 아니라, 지식을 기계가 실행 가능한 형태로 정리한 조직이 된다.
두 번째 경쟁력은 하네스다
운영 맥락이 재료라면, 하네스는 그 재료를 실제 결과로 바꾸는 조리도구이자 주방 운영 방식이다. 하네스가 약하면 좋은 재료도 엉망으로 요리된다.
특히 장기 실행 과업에서는 하네스의 중요성이 훨씬 커진다. 열 단계짜리 작업에서 각 단계 성공 확률이 85%라면, 끝까지 모두 성공할 확률은 20%도 되지 않는다. 단계가 늘어날수록 실패는 눈덩이처럼 불어난다.4 이 문제는 "모델을 더 똑똑하게 바꾸면 되지 않을까?"로 해결되지 않는다. 각 단계에서 오류를 막고, 틀리면 바로 잡고, 상태를 외부에 저장하고, 루프를 끊고, 다음 단계로 넘어가기 전에 검증하는 구조가 필요하다.
결국 좋은 하네스는 다음 질문에 답할 수 있어야 한다. 에이전트는 어떤 도구를 어떤 순서로 쓸 수 있는가? 어디까지 읽고 어디까지 쓸 수 있는가? 얼마나 오래 실행할 수 있는가? 언제 멈추는가? 실패하면 무엇을 남기고 어떻게 재개하는가? 어떤 산출물을 통과 기준으로 삼는가? 이 질문에 대한 설계가 구체적일수록 제품은 안정적이 된다.14
같은 모델을 써도 어떤 팀은 에이전트가 한 시간짜리 작업을 이어서 하게 만들고, 어떤 팀은 다섯 분만 지나도 맥락이 흐려지게 만든다. 어떤 팀은 무한 루프를 비용 한도와 순환 감지로 끊고, 어떤 팀은 새벽 내내 토큰만 태운다. 그래서 하네스는 단순한 구현 디테일이 아니라, 제품 품질을 결정하는 핵심 경쟁력이다.
세 번째 경쟁력은 검증 체계다
모델 시대에는 "답이 그럴듯한가"를 보는 경우가 많았다. 에이전트 시대에는 그것만으로는 부족하다. 중요한 것은 최종 문장만이 아니라, 그 문장에 도달하기까지의 경로다. 겉으로는 맞는 답을 냈지만 잘못된 도구를 쓰고, 틀린 문서를 참고하고, 우연히 정답처럼 보이는 숫자를 말했을 수도 있기 때문이다. 이런 조용한 실패는 데모에서는 잘 안 보이지만 운영에서는 치명적이다.5
그래서 경쟁력 있는 팀은 결과뿐 아니라 궤적을 평가한다. 어떤 도구를 골랐는지, 파라미터를 올바르게 넣었는지, 불필요한 반복이 있었는지, 원래 계획에서 이탈했는지, 안전 정책을 어기지 않았는지를 본다.5 다시 말해 검증 체계는 품질 관리 부서가 아니라 제품의 일부가 된다.
이 점이 왜 경쟁력일까. 검증 체계가 있으면 실패를 빨리 발견하고, 작은 회귀를 배포 전에 막고, 모델 교체나 프롬프트 수정 이후의 성능 하락을 즉시 잡아낼 수 있다. 반대로 검증 체계가 없으면 매번 사용자에게서 버그 리포트를 받아야 하고, 팀은 "왜 갑자기 안 되지?"라는 막막한 디버깅에 시간을 허비한다. 결국 더 빨리 배우는 팀이 더 빨리 강해진다.
네 번째 경쟁력은 실행 궤적 데이터다
하네스는 단지 모델을 감싸는 껍데기가 아니다. 하네스는 학습 장치이기도 하다. 에이전트가 어떤 목표를 받았고, 어떤 계획을 세웠고, 어떤 도구를 불렀고, 어디서 실패했고, 어떤 수정이 효과 있었는지를 기록하면, 그것이 곧 조직만의 실행 궤적 데이터가 된다.6
이 데이터는 일반적인 문서 데이터보다 훨씬 값지다. 문서는 "무엇을 안다"를 보여 주지만, 실행 궤적은 "어떻게 일을 끝냈는가"를 보여 준다. 어느 검색 질의가 잘 먹혔는지, 어떤 오류 메시지에서 루프가 시작되는지, 어떤 검증 규칙이 실제 실패를 잘 잡는지 같은 운영 지식이 축적된다. 경쟁사는 같은 모델을 살 수 있어도, 당신 팀이 몇 달 동안 쌓아 온 실행 궤적과 거기서 얻은 튜닝 감각은 살 수 없다.6
이때 중요한 것은 이 데이터를 단순 로그로만 쌓아 두지 않는 것이다. 재시도 정책을 바꾸고, 도구 설명을 손보고, 평가 세트를 늘리고, 실패 패턴별 가드레일을 추가하는 데 써야 한다. 그렇게 해야 하네스가 스스로 더 나아지는 플라이휠이 만들어진다. 결국 해자는 모델 안이 아니라, 하네스가 매일 생성하고 학습하는 운영 데이터 위에 생긴다.
제품 경험도 해자다
모델 성능이 비슷해지면 사용자는 "어떤 답을 주는가"만이 아니라 "어떻게 내 흐름 안에 들어오는가"를 본다. 에이전트가 별도 앱에서만 작동하는지, 내가 이미 쓰는 도구 안으로 들어오는지, 요청 한 번으로 끝나는지 아니면 여러 시스템을 오가며 끊기는지에 따라 체감 가치는 크게 달라진다.3
그래서 앞으로는 오케스트레이션 계층과 연결성도 경쟁력이 된다. 어떤 제품은 다양한 시스템을 읽고 쓰며 작업을 이어 가고, 어떤 제품은 자기 울타리 안에서만 맴돈다. 개방된 API, 안정적인 권한 모델, 에이전트가 이해할 수 있는 인터페이스를 가진 제품이 더 넓은 생태계의 중심이 된다.7 반대로 외부 에이전트가 접근하지 못하는 도구는 점점 불리해질 수 있다.
가격 구조도 달라진다. 사람 수만큼 좌석을 파는 방식보다, 실제로 처리한 작업량이나 만든 성과에 따라 과금하는 방식이 점점 중요해진다.7 왜냐하면 사용자는 더 이상 "도구 사용권"이 아니라 "업무 수행 결과"를 사기 시작하기 때문이다. 이 변화는 제품 설계에도 영향을 준다. 이제 좋은 SaaS는 화면이 예쁜 서비스일 뿐 아니라, 에이전트가 믿고 일할 수 있는 실행 환경이어야 한다.
사람의 역할은 줄어드는 것이 아니라 바뀐다
여기서 오해하지 말아야 할 것이 있다. 모델 경쟁 이후의 경쟁력이 하네스에 있다면, 사람은 덜 중요해지는가? 오히려 반대다. 하네스를 잘 만드는 조직일수록 사람의 전문성을 더 중요하게 다룬다. 이유는 간단하다. 하네스는 허공에서 나오지 않기 때문이다.
어떤 판단을 자동화해도 되는지, 어떤 단계는 반드시 승인해야 하는지, 무엇을 실패로 정의할지, 예외 상황에서 어떤 원칙을 우선할지는 결국 숙련된 사람이 정한다. 과도한 자동화는 모든 회사를 비슷하게 만들 수 있지만, 원래부터 강한 조직은 인간의 전문성을 하네스 안에 녹여 자기 방식의 차이를 지킨다.8 창의성은 앞단에서, 품질 책임은 뒷단에서 사람이 붙잡고, 그 사이의 반복적 실행을 에이전트가 맡는 구조가 가장 현실적이다.8
그래서 장기적으로 강한 회사는 AI를 사람의 우회로로 쓰지 않는다. 사람의 판단력을 증폭하는 구조로 쓴다. 이 관점이 있어야 하네스도 단순 자동화 스크립트가 아니라 조직의 운영 철학을 담은 시스템이 된다.
결국 기업의 자산은 모델이 아니라 운영 방식이 된다
모델을 바꾸는 일은 점점 쉬워질 것이다. 더 싼 모델로 갈아타거나, 더 빠른 모델을 붙이거나, 특정 단계만 다른 모델로 라우팅하는 일은 시간이 갈수록 흔해진다. 그때도 남는 것은 무엇일까. 바로 그 모델들이 일하는 방식이다.
정리하면 모델 경쟁 이후의 경쟁력은 네 곳에 쌓인다. 조직 고유의 운영 맥락, 그 맥락을 실행으로 바꾸는 하네스, 실패를 줄이는 검증 체계, 그리고 매일 축적되는 실행 궤적 데이터다. 여기에 사용자의 실제 흐름 속으로 들어가는 제품 경험과, 인간 전문가가 설계한 판단 기준이 더해지면 쉽게 복제되지 않는 자산이 된다.
같은 모델을 써도 다른 제품이 나오는 이유는 단순하다. 작업장이 다르기 때문이다. 공구가 정리된 작업장, 위험한 장비에 잠금장치가 있는 작업장, 중간 검사가 있는 작업장, 문제가 생기면 바로 멈출 수 있는 작업장에서 일한 에이전트는 다르게 행동한다. 앞으로 시장은 가장 똑똑한 모델보다, 가장 잘 설계된 작업장을 가진 팀을 더 오래 기억하게 될 것이다.
참고
1The Harness as the Agentic Moat
2When Every Company Can Use the Same AI Models, Context Becomes a Competitive Advantage
3Harnessing the Agent Era: Moats, Global Reach, and a New Management Playbook
4The Harness Is the Moat: Why Autonomous AI Agents Live or Die by Their Architecture
5A methodical approach to agent evaluation: Building a robust quality gate
6The Harness is the Dataset: Why Agent Trajectories are the New Enterprise Moat
7The Rise of AI Agents: Reshaping SaaS and Business Operations
8Human Capital as a Competitive Moat in the Age of A.I. Agents
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.