많은 에이전트는 사내 문서를 찾고 표를 요약하는 데서 시작한다. 재고를 발주하거나 환불을 승인하고 계약 상태를 바꾸려면 별도의 쓰기 권한과 통제가 필요하기 때문이다. 사람이 답을 받아 시스템에 다시 입력한다면 정보 탐색은 줄어들어도 업무 전체가 자동화되지는 않는다.
에이전트가 답변을 만드는 단계에서 실제 상태를 변경하는 단계로 넘어가려면 권한, 검증, 감사 기록을 함께 설계해야 한다.
읽는 에이전트와 바꾸는 에이전트
읽기 결과는 사람이 사용 전에 검토할 수 있다. 반면 주문 생성이나 잔액 이동 같은 쓰기 작업은 시스템 상태를 바로 바꾸므로 오류의 영향이 크다. 그래서 쓰기 권한을 제한하거나 사람 승인을 두는 경우가 많다. 자동화 효과를 얻으려면 위험도에 따라 승인 없이 실행할 수 있는 범위를 구체적으로 정해야 한다.
위험은 쓰기 권한을 명확한 규칙 없이 열어두는 것에서 생긴다. LLM이 데이터베이스와 여러 API를 제한 없이 호출하게 두면 잘못된 변경의 범위가 커진다. 에이전트가 실행할 수 있는 행동을 미리 정의하고, 행동마다 권한·검증·복구 절차를 연결해야 한다.
행동을 '타입’으로 묶는다
Palantir의 온톨로지는 객체 변경을 Action Type으로 정의한다. 어떤 객체의 어느 속성을 누가 어떤 조건에서 바꿀 수 있는지를 정하고, 변경 결과를 연결된 데이터에 반영한다. 에이전트와 사람이 같은 행동 정의를 호출하게 하면 임의의 데이터 쓰기보다 권한과 검증 규칙을 일관되게 적용하기 쉽다.
이 구조에 권한과 Action Log를 함께 넣을 수 있다. 누가 무엇을 언제 바꿨는지 기록하면 에이전트의 변경도 사람이 한 변경과 같은 규칙으로 추적할 수 있다. 문제가 생겼을 때 원인이 된 행동을 찾고 복구하기도 쉬워진다.
행동 정의가 운영 자산이 되는 이유
모델은 교체할 수 있지만 환불 한도, 승인 단계, 예외 처리처럼 회사별 업무 규칙은 제품 안에 따로 남아야 한다. 행동 정의를 데이터 모델과 함께 관리하면 새 모델을 연결해도 같은 권한과 검증 절차를 다시 사용할 수 있다. 이 규칙과 실행 이력은 시간이 지날수록 조직의 운영 지식을 담는 자산이 된다.
1인 사업자라면 어디서 시작하나
Palantir를 살 필요는 없다. 개념만 가져오면 된다.
먼저 에이전트가 자주 실행할 행동 몇 개에 이름을 붙인다. refund_order, reschedule_delivery, flag_for_review처럼 입력과 결과가 분명한 단위가 좋다. 자유서술로 임의의 API를 호출하게 두기보다 허용 목록과 스키마를 사용한다.
그다음 각 행동에 세 가지를 붙인다. 실행 전 통과해야 할 검증(한도·상태 조건), 실패하거나 오작동했을 때의 되돌리기 경로, 그리고 누가 언제 왜 했는지 남는 로그. 금액이 크거나 외부로 나가는 행동은 사람 승인을 한 단계 끼운다.
이 원칙을 적용하면 에이전트가 실행할 수 있는 범위와 실패했을 때의 대응이 분명해진다. 운영자는 에이전트에게 맡길 업무를 단계적으로 넓힐 수 있다.
핵심 질문은 시스템에서 무엇을, 누가, 어떤 조건으로 바꿀 수 있는가이다. 이를 행동 타입과 정책으로 관리해야 에이전트의 실행을 실제 업무에 안전하게 연결할 수 있다.