TL;DR

  • 많은 소프트웨어 서비스 기업이 핵심 업무를 에이전트에 맡기는 단계로 이동하면, 사람 대신 하네스가 서비스 생산을 주도하는 기업으로 바뀜.
  • 여기서 하네스(harness)는 상태가 없는 대형 언어 모델(LLM)을 둘러싼 인프라, 인터페이스, 맥락, 상태를 모두 포함함.
  • 하네스는 사람의 주의와 판단을 고객 가치가 가장 커지는 지점에 배치하며, 사람은 검토와 취향·판단을 제공하는 구성 요소가 됨.
  • 하네스의 설계와 운영이 신뢰, 유통, 효능, 도메인 맥락을 좌우하면서 기업의 핵심 역량으로 자리 잡음.
  • 기업은 최상위 하네스를 직접 소유하고 특정 작업에는 외부 제품을 연결하며, 핵심 업무 경로의 소프트웨어는 하네스가 실행할 수 있도록 헤드리스(headless) 형태가 필요함.

하네스란 무엇인가

  • 좁은 의미에서 하네스는 LangGraph 같은 프레임워크나 Codex, Claude Code, OpenCode 같은 코딩 에이전트처럼, 상태가 없는 모델 API에 작업 수행에 필요한 도구와 상태를 더하는 구성을 가리킴.
  • 여기서는 하네스를 상태가 없는 대형 언어 모델(LLM)을 둘러싼 인프라, 인터페이스, 맥락, 상태 전체를 뜻하는 넓은 개념으로 사용함.
  • 하네스는 조정자 역할을 하는 메타 하네스(meta-harness) 아래에 적용형 또는 작업별 하네스를 조합할 수 있음.
  • 소프트웨어 공장(software factory)은 사양 작성, 코드 작성, 검토 등 각각 작은 하네스로 구성되고, 상위 요소가 작업의 실행 시점을 결정하는 하네스임.

소프트웨어 서비스 기업이 하네스로 바뀌는 과정

  • 이런 넓은 정의를 받아들이면, 많은 소프트웨어 서비스 기업이 다음 경로를 따를 수 있음.
  • 전통적인 SaaS 방식으로 소프트웨어 서비스를 판매하며 하네스는 사용하지 않음.
  • 엔지니어가 에이전트와 협업하고, 제품 및 영업 등 다른 직무도 생산성을 위해 에이전트와 협업함. 개인이 하네스를 운영함.
  • 핵심 업무 다수를 클라우드에서 실행되는 백그라운드 에이전트로 옮김. 노트북 한 대로 에이전트 스무 개를 실행할 수 없기 때문임. 엔지니어링, 제품, 영업 담당자가 에이전트를 실행하고 프롬프트를 작성한 뒤 결과를 검토함. 개인이 하네스를 조정함.
  • 핵심 업무 다수를 선제적으로 작동하는 백그라운드 에이전트로 옮기고, 엔지니어링, 제품, 영업 담당자는 에이전트 결과를 검토하는 역할로 이동함. 일관된 검토는 표본 검토로 바뀌며, 사람의 사전 설계 대신 에이전트가 점차 수행할 일을 선제적으로 결정함. 하네스가 개인을 조정함.
  • 이 경로를 따라가면 기업 자체가 하네스로 바뀌며, 소프트웨어 서비스 생산 업무가 사람에게서 하네스로 이동함.
  • 에이전트가 핵심 업무를 수행하고, ‘제품’은 전적으로 모델 출력물이 됨. 기업은 맥락과 통합 기능, 사람을 위한 검토 인터페이스를 제공함.
  • 조직 구조와 소프트웨어의 관계도 뒤집힘. 조직도는 하네스가 사람에게서 최대한의 취향과 판단을 끌어낼 수 있도록 사람을 어디에 배치할지의 문제가 됨. 사람도 하네스의 일부임.
  • 기업의 도메인 지식, 도구, 권한, 검토 루프, 맥락 등이 모두 비즈니스 하네스를 구성함.

AI 슬롭 공장이 될까

  • AI가 주로 만들고 검토하는 제품은 본질적으로 품질이 낮고, 사람 대신 하네스를 통해 생산하면 대규모 슬롭 공장이 된다고 생각하기 쉬움. 그러나 이런 우려는 이런 방식으로 운영되는 기업이 사람의 개입 없이 완전히 자동화된다고 가정함.
  • 핵심적인 완화책은 사람의 입력이 가장 중요한 지점을 하네스가 선택하게 하는 것임.
  • 에이전트가 고객 미팅에 참석하는 영업 담당자에게 질문을 분산하고, 답변을 종합해 제품 책임자가 검토할 제품 데모를 만들 수 있음.
  • 고객 미팅에서 나온 기능 제안을 에이전트가 주요 아키텍처 결정으로 발전시켜 엔지니어링 분야의 취향·판단 담당자에게 제시할 수 있음.
  • 피드백을 모아 UI 재설계를 시작하고, 여러 안을 시험한 뒤 상위 선택지를 디자인 분야의 취향·판단 담당자에게 제시할 수 있음.
  • 좋은 하네스는 고객 가치를 극대화하면서 직원과 고객의 주의를 필요한 지점에만 사용함.
  • 회의적인 시각도 타당함. 현재의 최첨단 모델과 잘 설계된 하네스를 사용하더라도, 에이전트가 이처럼 외부 루프를 처리한다고 신뢰하기는 상당히 어려우며 실제로 많은 시간을 들여 시도해 온 영역임.
  • 다만 모델이 결국 이를 해내지 못하리라는 데 베팅할 가치는 없다고 봄. 계획과 검토 작업이 연구소에서 학습에 활용할 수 있는 검증 가능한 보상 기반 과제로 더 많이 분해되기 때문임.
  • ‘취향·판단 담당자’로 구성된 조직에 관한 추가 내용은 [The Transposed Organization]에서 다루며, 이 글은 해당 글의 아이디어를 상당 부분 바탕으로 함.

하네스가 제품을 생산하고 판매하면 그것이 핵심 역량임

  • 서비스에 따라 기업의 차별화 요소는 신뢰, 유통, 효능, 도메인 맥락 등에서 나오는 경우가 많음.
  • 선제적 백그라운드 에이전트 환경에서는 하네스를 구성하는 능력, 즉 하네스가 학습하는 방식, 감시하는 항목, 사람의 취향·판단 담당자와 상호작용하는 방식, 통합하는 시스템이 차별화를 유지하는 수단으로 점점 중요해짐.
  • 하네스는 업무 출시를 위해 충족해야 하는 조건인 신뢰, 제품의 출시 속도와 방식인 유통, 피드백 루프의 속도와 맥락인 효능, 조직 지식을 받아들이고 유지하는 방식인 도메인 맥락을 형성함.
  • 하네스는 기꺼이 구매할 수 있는 내부 도구에서 제품·엔지니어링 조직이나 시장 진출(GTM) 팀보다 외주하기 어려운 대상으로 바뀜.
  • 이는 소프트웨어를 사용하는 사람에 따라 결과물의 범위가 주로 제한됐던 AI 이전 시대와 뚜렷하게 다름.

이미 시작된 변화

  • Ramp, Stripe, DoorDash 등에서 볼 수 있는 사내 인공지능(AI) 개발 도구가 변화의 시작임.
  • AI를 적극적으로 활용하는 기업에서는 소프트웨어 개발 수명 주기(SDLC) 도구 공급업체가 통합 기능을 추가하거나 특정 인터페이스를 지원하거나 비용 대비 효율성을 높일 때까지 기다리는 일이 제품 구축과 유지보수의 병목이 되는 경우가 점점 늘어남.
  • 특히 단기적으로는 제3자 도구가 기업의 전체 소프트웨어 공장을 대신 운영하지 못하는 경우에 이 문제가 두드러짐. 기술 스택이 지나치게 맞춤형이거나, 거버넌스가 지나치게 제한적이거나, 핵심 기능 지원이 너무 느리거나, 선호하는 비용 모델이 다를 수 있음.
  • 모든 것을 사내에서 구축하고 유지해야 한다는 뜻은 아님. 기업은 무엇을 만들지 결정하고 결과를 검토하는 최상위 하네스를 소유하고, 특정 워크플로에는 공급업체 제품을 연결해야 함.
  • 장차 제3자가 기업 수준의 ‘사양에서 테스트된 풀 리퀘스트까지’를 상당히 잘 처리하게 되면, 기업은 소프트웨어 루프의 해당 부분을 그 제품으로 교체할 수 있음. 동시에 입력 사양을 작성하는 에이전트와 풀 리퀘스트 결과물 이후의 단계를 처리하는 에이전트는 계속 유지할 수 있음.
  • 외부 하네스가 선제적 백그라운드 에이전트 서비스로 전체 비즈니스의 외부 루프를 처리할 수 있게 된다면, 해당 비즈니스는 이미 상품화된 상태라고 볼 수 있음.

그렇다면 무엇을 예상해야 하나

  • 이 관점이 맞다면 구축 측과 판매 측 모두에서 이례적으로 많은 사내 하네스 구축이 나타날 것으로 예상됨.
  • 하네스 안에서 조직과 개인 역할이 맡는 위치에 따라 조직 구조와 역할이 재편될 것으로 예상됨.
  • 해자가 하네스로 쉽게 대체될 수 있는 분야에서는 AI 네이티브 스타트업이 기존 기업을 앞설 것으로 예상됨.
  • 핵심 구축·판매 경로에 있거나 연결된 소프트웨어는 최상위 하네스가 실행할 수 있도록 헤드리스 형태가 되어야 함.