AI 에이전트 도입 논의에는 종종 “얼마나 자율적으로 움직일 수 있는가”가 앞에 나온다. 하지만 실제 업무에서는 반대 질문이 더 유용하다. 어디에서 멈춰야 하는가, 누가 예외를 결정하는가, 같은 요청에 비슷한 결과를 낼 수 있는가. Product Hunt에 소개된 Controller AI는 AI에 전면 자율성을 주는 대신, 명확한 프로세스와 규칙 안에서 작업하도록 하는 도구로 설명된다. 업무 프로세스를 워크플로로 정의해 에이전트의 도구로 붙이면, 에이전트가 행동할 때 같은 단계와 같은 출력을 실행한다는 것이 공개 페이지의 주장이다.
이 설명은 화려한 자율형 에이전트 데모와는 결이 다르다. 여기서 매력적인 부분은 모델의 판단을 없애겠다는 것이 아니라, 결과를 만들어 내는 실행 단계를 좁은 경로로 묶으려는 데 있다. 고객 데이터 변경, 승인 요청, 보고서 생성처럼 실수 비용이 있는 작업에서는 이쪽이 더 현실적인 출발점이 될 수 있다.
‘결정론적’이라는 단어를 과하게 읽지 않기
도구가 같은 워크플로를 실행한다고 해도, 언어 모델이 처음 요청을 해석하는 과정까지 항상 동일해진다고 단정할 수는 없다. 공개 소개 역시 정의한 프로세스와 워크플로 실행을 강조한다. 따라서 “결정론적 에이전트”라는 표현은 모델의 모든 판단이 완전히 고정된다는 뜻보다, 실제 조치 단계의 순서를 통제하려는 방향으로 이해하는 편이 안전하다.
예를 들어 사용자의 질문을 분류하고 필요한 정보를 찾는 단계에는 여전히 해석의 여지가 있다. 그러나 주문 상태를 바꾸거나, 특정 양식의 티켓을 만들거나, 고객에게 안내를 보내는 단계는 사전에 정의한 워크플로로 제한할 수 있다. 이 구분이 있으면 오류가 생겼을 때 원인을 좁히기도 쉬워진다. 요청 해석이 문제인지, 워크플로 설계가 문제인지, 외부 시스템의 결과가 문제인지 나눠 볼 수 있기 때문이다.
자동화 후보는 ‘자주 하는 일’보다 ‘결과가 정해진 일’이다
반복 횟수가 많다는 이유만으로 에이전트 자동화에 적합한 것은 아니다. 매번 사람의 예외 판단이 핵심인 업무를 성급히 워크플로로 고정하면, 예외가 우회 경로로 쌓인다. 반면 시작 조건, 필요한 입력, 완료 기준을 한 문서로 적을 수 있는 업무는 좋은 후보가 된다. 정형화된 정보 수집 후 검토 요청 만들기, 정해진 형식의 보고서 초안 만들기, 특정 조건에 따른 상태 확인 같은 작업이 그렇다.
팀은 먼저 한 가지 업무를 문장으로 끝까지 써 볼 수 있다. 누가 시작시키는지, 어떤 입력이 필수인지, 외부 도구를 어느 순서로 부르는지, 실패하면 어디서 멈추는지, 누가 승인하는지를 적는다. 이 문서가 애매하면 에이전트에게 맡겨도 애매함이 사라지지 않는다. Controller AI 같은 프로세스 중심 도구는 이 문제를 숨기기보다 드러내는 데서 가치를 낼 가능성이 크다.
예외 처리와 사람의 개입 위치
워크플로가 길어질수록 정상 흐름보다 예외가 더 중요해진다. 고객 정보가 없거나, 외부 API가 느리거나, 정책상 자동 처리하면 안 되는 요청이 들어오는 상황은 반드시 생긴다. 이때 에이전트가 계속 추측하며 다음 단계로 넘어가면, 통제된 프로세스라는 장점이 사라진다.
도입 전에 정해야 할 것은 각 단계의 성공 조건뿐 아니라 중단 조건이다. 데이터가 하나라도 부족하면 초안을 만들고 멈출지, 사람에게 질문을 보낼지, 아무 작업도 하지 않을지를 명시한다. 금액, 권한, 외부 발송처럼 되돌리기 어려운 동작 앞에는 승인 단계를 둔다. 이 규칙은 에이전트의 능력을 제한하는 장치가 아니라 팀의 책임 경계를 보존하는 장치다.
공개 페이지에서는 워크플로를 에이전트 도구로 연결하는 방향을 확인할 수 있다. 반면 버전 관리, 감사 로그, 권한 모델, 재시도 방식 같은 세부 사항은 소개만으로 확인하기 어렵다. 이런 항목은 구매 전 질문 목록에 넣는 것이 좋다. 특히 같은 실행이 실패했을 때 다시 실행해도 중복 생성이나 중복 발송이 일어나지 않는지 확인해야 한다.
파일럿의 성공 기준을 바꾸기
초기 파일럿에서 성공을 “사람 없이 끝낸 비율”로 잡으면 무리한 자동화로 흐르기 쉽다. 대신 사람이 검토하는 데 필요한 정보를 빠짐없이 모았는지, 정해진 절차를 건너뛰지 않았는지, 실패를 안전하게 멈췄는지를 측정하는 편이 낫다. 첫 번째 버전은 사람의 클릭 몇 번을 없애는 정도면 충분하다.
한 업무를 골라 읽기·초안 생성·승인이 필요한 실행을 분리해 본다. 처음에는 읽기와 초안까지만 에이전트에 맡긴 뒤 적용은 사람이 한다. 이때 예외 요청을 일부러 섞어 본다. 필요한 정보가 빠진 요청, 두 정책이 충돌하는 요청, 권한이 없는 요청에 대해 도구가 어느 지점에서 멈추는지 보는 편이 일반 성공 사례보다 더 많은 정보를 준다.
Controller AI는 공개 정보 기준으로 에이전트를 정해진 프로세스 안에서 실행하려는 도구다. 실무에서 이 접근이 유효한 이유는 에이전트의 자율성을 크게 보이게 해서가 아니라 위험한 동작을 예측 가능한 절차로 바꾸려 하기 때문이다. 다만 워크플로 자체가 불완전하면 도구가 그 불완전함을 자동으로 해결하지는 않는다. 좋은 도입은 모델을 믿는 데서 시작하지 않는다. 사람이 설명할 수 있는 업무 경계를 먼저 만드는 데서 시작한다.
답글 남기기