모든 SaaS 기업은 모델을 둘러싼 하네스가 될 것이다
모든 SaaS 기업은 결국 모델을 둘러싼 하네스가 될 것이라 봄
기업 스스로 아직 깨닫지 못했더라도 이 방향으로 움직일 것임
하네스는 상태 없는 LLM을 둘러싼 인프라·인터페이스·맥락·상태 전체를 뜻함
좁게는 LangGraph 같은 프레임워크나 Codex·Claude Code·OpenCode 같은 코딩 에이전트를 가리킴
상태 없는 모델 API에 도구와 상태를 붙여 실제 작업을 할 수 있게 만듦
여기서는 더 넓은 뜻으로 사용함. 작업별로 조정된 작은 하네스들을 조합할 수 있고, 이를 조율하는 상위 구성은 ‘메타 하네스’라고 부름
‘소프트웨어 공장’도 하네스의 한 형태. 명세 작성·코드 작성·리뷰를 맡는 작은 하네스들과 무엇을 언제 실행할지 결정하는 상위 구성으로 이루어짐
많은 소프트웨어 서비스 기업이 다음 네 단계를 거칠 것임
하네스 없음: 전통적인 SaaS 방식으로 만든 소프트웨어 서비스를 판매
개인이 하네스를 운영: 엔지니어가 에이전트와 함께 작업하고, 제품·영업 등 다른 부서도 생산성을 높이기 위해 에이전트를 사용
개인이 하네스를 조율: 핵심 작업 상당수가 클라우드의 백그라운드 에이전트로 이동. 노트북으로는 에이전트 20개를 돌릴 수 없으므로 엔지니어링·제품·영업 담당자가 프롬프트로 작업을 시작하고 결과를 검토
하네스가 개인을 조율: 에이전트가 선제적으로 할 일을 결정하고 실행. 사람은 결과 검토에 집중하며, 일관된 검토가 가능해지면 표본 검토로 전환
이 경로를 따르면 회사 자체가 하네스로 바뀜
소프트웨어 서비스를 만드는 일을 사람에게서 하네스로 옮긴 셈
에이전트가 핵심 작업을 수행하면서 ‘제품’은 전적으로 모델의 출력이 됨
회사는 맥락·통합 기능·사람이 결과를 검토할 인터페이스를 제공
조직도는 하네스가 사람의 안목과 판단을 최대한 끌어내려면 누구를 어디에 배치할지의 문제가 됨
사람도 하네스의 일부가 됨
회사의 도메인 지식·도구·권한·검토 과정·맥락이 모두 비즈니스 하네스에 포함됨
AI가 만들고 검토한다고 저품질 결과물을 대량 생산하게 된다고 보지는 않음
그런 생각은 이 방식의 회사가 사람 개입 없이 돌아간다고 가정함
핵심 대응은 하네스가 사람의 의견과 판단이 가장 필요한 지점을 고르는 것
사람의 판단을 필요한 결정에 연결할 수 있음
제품 결정에서는 에이전트가 고객 미팅에 참여하는 담당자들에게 질문을 나눠 보내고, 답변을 종합해 제품 책임자가 검토할 데모를 만들 수 있음
고객 미팅에서 나온 기능 제안을 주요 아키텍처 결정으로 구체화해 기술적 안목을 갖춘 엔지니어에게 제시할 수 있음
UI 재설계에서는 피드백을 모아 몇 가지 변형을 시험한 뒤, 가장 좋은 후보들을 디자인 안목을 갖춘 사람에게 보여줄 수 있음
좋은 하네스는 고객 가치를 극대화하면서 사람의 주의를 필요한 곳에만 씀
직원과 고객 모두의 주의가 여기에 포함됨
현재 모델과 잘 만든 하네스만으로 전체 작업 흐름을 에이전트에 맡기기는 여전히 어려움
무엇을 할지 정하고 결과를 검토하는 ‘외부 루프’를 맡기는 데 회의적이어도 이해함. 우리도 오랜 시간을 들여 시도해 봤음
다만 모델이 결국 이 일을 해낼 수 없을 것에 베팅할 가치는 없음
특히 계획·검토 작업이 AI 연구소가 학습에 쓸 수 있는 검증 가능한 보상을 갖춘 과제로 더 많이 나뉘고 있음
안목과 판단을 맡는 사람들로 조직을 구성하는 모습은 The Transposed Organization에서 더 살펴볼 수 있음
이 글도 해당 글의 아이디어에 상당 부분 기대고 있음
하네스가 제품을 만들고 판매하면 하네스 구축이 핵심 역량이 됨
서비스에 따라 기업은 신뢰·유통·효과·도메인 맥락에서 차별화함
선제적으로 움직이는 백그라운드 에이전트가 일하는 환경에서는 하네스가 무엇을 학습하고 관찰하는지, 사람의 안목을 어떻게 반영하는지, 어떤 시스템과 통합되는지가 차별화를 유지하는 데 점점 더 중요해짐
기존 차별화 요소의 작동 방식을 하네스가 결정하게 됨
신뢰는 결과물을 내보내기 전에 충족해야 할 조건에 반영됨
유통은 제품이 고객에게 도달하는 속도와 방식에 반영됨
효과는 피드백 루프의 속도와 맥락에 반영됨
도메인 맥락은 조직의 지식을 받아들이고 유지하는 방식에 반영됨
하네스는 내부 도구에서 직접 소유할 핵심 조직 역량으로 바뀜
제품·엔지니어링 조직이나 시장 진출 팀을 통째로 외주화하지 않듯, 하네스도 외주화하기 어려워짐
AI 이전에는 결과물의 범위가 주로 소프트웨어를 사용하는 사람에게 제한됐음
사내 AI 개발 도구에서 이 변화가 이미 시작됐다고 봄
Ramp·Stripe·DoorDash 등의 사례가 그 시작이라고 생각함

AI 활용에 적극적인 기업에는 외부 SDLC 도구를 기다리는 일이 점점 병목이 됨
필요한 통합·인터페이스·비용 대비 효과를 공급업체가 갖출 때까지 기다리면 제품을 만들고 유지하는 능력이 제한됨
특히 단기적으로는 외부 도구가 기업의 소프트웨어 공장 전체를 운영하지 못하는 경우가 많음
기업별 기술 스택, 엄격한 거버넌스, 핵심 기능 지원 지연, 선호하는 비용 모델 등이 제약으로 작용함
모든 것을 사내에서 만들기보다 최상위 하네스를 직접 소유해야 함
무엇을 만들지 결정하고 돌아온 결과를 검토하는 하네스는 회사가 소유하고, 특정 워크플로에는 공급업체 제품을 연결하는 방식
언젠가 외부 제품이 기업 환경에서 ‘명세부터 테스트된 풀 리퀘스트까지’를 충분히 잘 처리하게 되면 그 구간을 교체할 수 있음
이때도 입력 명세를 작성하고 풀 리퀘스트 이후 단계를 처리하는 에이전트는 회사가 유지
외부 하네스가 사업의 외부 루프 전체를 맡을 수 있다면 그 사업은 범용화됐다고 보겠음
백그라운드 에이전트를 서비스로 제공해 사업 전체를 운영할 수 있는 경우를 뜻함
이 생각이 맞다면 개발과 판매 양쪽에서 사내 하네스 구축이 크게 늘고 조직 구조와 개인의 역할은 비즈니스 하네스 안에서 맡는 자리에 맞춰 재편될 것임
경쟁 우위를 하네스로 쉽게 구현할 수 있는 분야에서는 AI 네이티브 스타트업이 기존 기업을 이길 것임
핵심 개발·판매 경로에 쓰이거나 연결된 소프트웨어는 모두 헤드리스 방식이 필요해질 것
바깥의 하네스가 해당 소프트웨어를 실행할 수 있어야 하기 때문
source https://blog.sshh.io/p/the-harness-is-the-company
HN에서는 AI 에이전트가 도입되더라도 ‘SaaS의 소멸’로 이어지지는 않을 것이라는 시각이 우세했다. 개발 비용이 낮아져도 고객은 연동, 기술 지원, 비용 예측, 장애 책임까지 직접 떠안길 원치 않기 때문이다. 에이전트로 효율을 높이더라도 대다수 고객에게는 여전히 안정적인 완성형 SaaS가 필요하다. 다만 중요도가 낮은 업무라면 완성도를 조금 양보하더라도 프롬프트로 즉각 결과를 얻는 방식을 선호할 수 있다.
업무 자동화가 곧 조직의 완전한 무인화를 뜻하지도 않는다. 에이전트 오케스트레이션 체계(하네스)를 갖춰도 작업 이탈이 잦아 도메인 전문가의 검증은 여전히 필수적이다. 맞춤형 하네스 역시 복잡한 레거시 코드를 다루기 위한 고육지책일 뿐, 모든 기업의 표준이 될 수는 없다. 특히 검증이 쉬운 ‘코드 생성’과 달리, 비결정적인(예측 불가능한) LLM의 응답에 사업 운영 전체를 맡기는 것은 리스크가 너무 크다.
한편, ‘데이터 이동’이 쉬워지는 것과 ‘고유 데이터 확보’는 별개의 문제다. LLM 덕분에 마이그레이션이 쉬워져 락인 효과는 줄어들 수 있다. 그러나 누구나 최신 AI 도구를 쓸 수 있는 환경일수록, 원천 데이터를 수집하고 정제하는 데 들인 시간과 비용이 더 강력한 해자(Moat)가 된다. 합성 데이터나 모델 추론만으로는 현실의 미측정 영역을 온전히 대체할 수 없다.
결국 단순히 산출량을 늘리는 것만으로는 사업의 성공을 담보할 수 없다. 고객을 제대로 이해하지 못한 채 생산량만 1,000배 늘려봤자 쓸모없는 결과물만 양산할 뿐이다. 고객의 숨은 요구를 파악하고 협상을 이끄는 일은 여전히 인간의 영역이다. 에이전트 체계는 창업자의 통찰과 역량을 증폭하는 강력한 도구일 뿐, 사업 성공을 보장하는 충분조건은 아니다.
