SI 하네스로 더 이상 사람이 필요없는 회사를 만든다.

AI에게 일을 시키는 능력에서, AI가 일하는 구조를 설계하는 능력으로

“이 상품으로 상세페이지 하나 만들어줘.”

AI에게 자료를 주고 작업을 맡긴다. 결과가 나오면 부족한 부분을 고친다. 제품 설명을 보완하고, 이미지 구성을 바꾸고, 과장된 표현을 지운다. 그렇게 상세페이지 하나를 완성한다.

그런데 다음 상품을 작업할 때도 같은 설명을 반복해야 하고 있는 사람들이 대부분이다. 어떤 자료를 먼저 확인해야 하는지, 무엇을 강조해야 하는지, 어떤 표현을 쓰면 안 되는지 다시 알려줘야 하는 수고로움이 발생한다.

결과물은 있지만, SNS나 이곳 저곳에서 떠들고 있는 자동화는 아니다. 즉, 일하는 방식이 충분하지 않다는 뜻이다.

반대로 이 과정을 정리해두면 이야기가 달라진다. 필요한 자료를 확인하는 순서, 부족한 정보가 있을 때 멈추는 조건, 결과물을 검토하는 기준까지 다음 작업에 재사용할 수 있다.

결과물 하나를 얻는 것과, 결과물이 반복해서 나오는 구조를 만드는 것은 완전히 다른 일이다.

‘하네스가 곧 회사다’라는 주장은 바로 이 차이에서 출발한다.

하네스는 AI가 일할 수 있도록 만드는 전체 구조다

소프트웨어 서비스 기업의 핵심 업무가 AI 에이전트로 이동할수록, 회사 자체가 모델을 둘러싼 ‘하네스’가 될 수 있다고 주장하는 사람들이 있다. 여기서 하네스는 특정 프로그램 하나가 아니다. AI가 일하는 데 필요한 업무 지식, 도구, 권한, 작업 상태, 검토 절차를 포함하는 넓은 개념인데,

쉽게 말하면, AI에게 “잘해봐”라고 말하는 데서 끝나지 않고 무엇을 보고, 사용하고 어디까지 실행하고, 언제 검토해달라고 물어볼지를 정해놓은 운영 구조를 말한다.

회사에 새로운 직원이 들어온 상황을 떠올리면 이해하기 굉장히 쉬운데, 일을 잘하는 사람을 채용했다고 해서 곧바로 모든 업무를 맡길 수 있는 것은 아니라는 것을 모두가 안다.

제품에 관한 정보를 전달하고, 필요한 시스템에 접근하게 하고, 업무 기준과 승인 절차를 알려줘야 한다.

즉, 내부 구조는 물론이고 이해관계 인과관계들을 알아서 다음을 선택을 할 수 있다.

이건 그냥 기본 중에 기본이다.

AI를 업무에 넣을 때도 비슷한 질문이 생긴다.

고객 정보를 어디서 확인하게 할 것인지.서로 다른 자료의 내용이 충돌하면 무엇을 기준으로 삼을 것인지. 초안 작성까지만 맡길 것인지, 실제 게시까지 허용할 것인지.

이 질문에 대한 답을 작업 과정에 반영하면, 이게 하네스의 일부가 된다.

이렇게 보면 하네스 설계는 단순한 도구 설정이 아니다. 우리 조직이 어떻게 일하고 판단하는지를 구체적으로 표현하는 작업에 가깝다.

사람이 일을 시키는 단계에서, AI가 판단을 요청하는 단계로

원문이 제시하는 변화의 핵심은 AI 사용량이 늘어난다는 데 있지 않다. 누가 다음 일을 찾아서 시작하느냐가 달라진다는 데 있는데, 처음에는 사람이 일을 정하고 AI를 보조 도구로 사용한다. 그다음에는 여러 에이전트에 작업을 나누어 맡기고 결과를 취합한다.

더 나아가면 정해진 목표와 권한 안에서 에이전트가 먼저 할 일을 찾아 제안하거나 실행하고, 사람에게 필요한 검토를 요청하는 구조를 상정할 수 있다.

다만 이러한 전체 업무 순환을 에이전트에 믿고 맡기기는 아직 어렵다.
이미 완성된 현실이라기보다 앞으로의 조직을 바라보는 가설이다.

이 논의를 작은 판매 업무에 적용해보자.

운영자가 고객 문의를 읽다가 같은 질문이 반복된다는 사실을 발견한다. 제품 설명이 부족하다고 판단하고, AI에게 수정안을 요청한다. 이것은 사람이 문제를 발견하고 AI에게 일을 시키는 방식이다.

다른 구조도 설계해볼 수 있다.

시스템이 고객 문의를 모아 반복되는 질문을 찾아낸다. 제품 정보와 기존 설명을 대조한 뒤, 설명이 부족한 부분에 대한 수정안을 만든다. 그리고 운영자에게 수정 이유와 근거를 함께 보여주며 승인을 요청한다.

이때 운영자는 모든 문의를 처음부터 읽고 수정안을 작성하는 대신, 제안이 적절한지를 판단한다.