1부. 회사는 사람이 아니라 상태 전이로 굴러간다

2장. 에이전트는 일을 하는 사람이 아니라 상태를 옮기는 작업자다

에이전트 컴퍼니 v0.4.0

에이전트라는 말은 쉽게 과장된다.

마치 사람처럼 생각하고, 알아서 판단하고, 무엇이든 처리하는 디지털 직원처럼 들린다. 하지만 실제 회사에서 쓸 수 있는 정의는 더 좁아야 한다.

에이전트는 특정 객체를 특정 상태에서 다음 상태로 옮기도록 설계된 작업자다.

이 정의가 중요하다.

"마케팅 에이전트"라고 하면 너무 넓다. 무엇을 하는지 알 수 없다. "신규 계정 후보를 발견해 ICP 적합도와 근거를 붙여 검토 대기 상태로 옮기는 에이전트"라고 하면 일이 보인다.

"고객지원 에이전트"라고 하면 너무 넓다. "비밀번호, 결제, 설정 문의를 해결하거나, 해결 불가 시 담당자에게 필요한 로그와 함께 escalate하는 에이전트"라고 하면 설계할 수 있다.

좋은 에이전트 정의에는 다섯 가지가 들어간다.

요소
객체
질문
무엇을 다루는가?
요소
입력
질문
무엇을 보고 시작하는가?
요소
상태 전이
질문
무엇을 어떤 상태로 바꾸는가?
요소
권한
질문
어디까지 자동 실행할 수 있는가?
요소
기록
질문
무엇을 남겨야 다음 agent와 사람이 쓸 수 있는가?

이 정의는 copilot과 autopilot의 차이도 분명하게 만든다.

Copilot은 사람이 일을 할 때 옆에서 돕는다. 글을 써주고, 요약하고, 초안을 만들고, 추천한다. 고객은 여전히 도구를 산다.

Autopilot은 일을 산다. 고객은 "NDA 초안을 만들어주는 도구"를 사는 것이 아니라 "NDA가 처리되는 상태"를 산다. "회계 소프트웨어"를 사는 것이 아니라 "월말 장부가 닫히는 결과"를 산다. "영업 자동화 도구"를 사는 것이 아니라 "적합한 고객 후보가 발견되고 미팅까지 연결되는 결과"를 산다.

에이전트 컴퍼니는 내부적으로는 autopilot 회사를 닮아간다. 사람은 도구를 눌러 일을 처리하는 대신, agent가 처리할 수 있는 work unit을 정의하고, agent가 처리한 결과를 검증하고, 점점 더 큰 work budget을 agent 운영체제로 옮긴다.

예를 들어 Demand Agent는 "좋은 회사 후보를 찾아주는 AI"가 아니다. 더 정확히는 "외부 신호와 내부 ICP 기준을 보고 account 후보를 만들고, 근거와 score를 붙여 sales 검토 queue로 보내는 에이전트"다.

Inbound Agent는 "챗봇"이 아니다. "웹 방문자의 질문을 받고, 의도와 fit을 판단하고, 답변 또는 미팅 예약 또는 human handoff로 상태를 옮기는 에이전트"다.

Customer Success Assistant는 "CSM을 도와주는 AI"가 아니다. "사용량, 지원 이력, 계약 상태, 최근 신호를 보고 오늘 챙겨야 할 account를 추천하고 outreach 초안을 만드는 에이전트"다.

이렇게 좁히면 에이전트는 마법이 아니라 운영 부품이 된다.

그리고 운영 부품은 설계할 수 있다.

Early Reader Feedback

원고 피드백 남기기

읽다가 헷갈린 곳, 더 듣고 싶은 사례, 동의하기 어려운 문장을 알려주세요. 공개 댓글이 아니라 저자에게만 전달되는 피드백입니다.

본문에서 문장을 드래그한 뒤 누르면 선택 문장이 함께 저장됩니다.

피드백 유형

BiteMark Press는 Cloudflare Web Analytics로 익명 트래픽을 보고, 동의한 경우에만 GA4와 Microsoft Clarity를 켭니다.