당신이 만든 에이전트는 아마 잘 읽는다. 사내 문서를 뒤지고, 표를 요약하고, 왜 매출이 꺾였는지 그럴듯하게 설명한다. 그런데 딱 거기까지다. 재고를 실제로 재발주하지도, 환불을 승인하지도, 계약 상태를 바꾸지도 못한다. 사람이 그 답을 받아 다시 손으로 시스템에 입력한다. 읽기만 하는 에이전트는 아무리 똑똑해도 결국 검색 상자다.
데모와 제품을 가르는 선이 여기다. 답을 내놓는 것과 상태를 바꾸는 것 사이. 대부분의 팀은 첫 번째에서 멈추고, 그걸 자동화라고 부른다.
읽는 에이전트와 바꾸는 에이전트
읽기는 실수해도 사람이 걸러낸다. 요약이 틀리면 안 쓰면 그만이다. 그런데 쓰기는 다르다. 에이전트가 주문을 넣고 잔액을 옮기는 순간, 그건 되돌려야 할 사고가 된다. 그래서 대부분의 회사는 에이전트에게 읽기 권한만 주고 쓰기는 사람 손에 남겨둔다. 안전하지만, 정작 비싼 노동은 그 ‘손으로 입력하는’ 구간에 다 몰려 있다.
문제는 쓰기 자체가 아니라 쓰기를 아무 규칙 없이 열어두는 것이다. LLM에게 데이터베이스 접근 권한과 자유서술 API를 쥐여주면, 그건 자동화가 아니라 시한폭탄이다. 필요한 건 에이전트가 부를 수 있는 행동을 미리 못 박고, 그 행동마다 권한·검증·되돌리기를 걸어두는 구조다.
행동을 '타입’으로 묶는다
Palantir가 온톨로지에서 파는 핵심이 정확히 이거다. 이들은 객체에 대한 변경을 Action Type으로 정의한다. 어떤 객체를, 어떤 속성을, 누가, 어떤 조건에서 바꿀 수 있는지를 타입으로 고정하고, 그 변경은 write-back 데이터셋에 커밋되어 모든 애플리케이션에 동일하게 반영된다. 에이전트든 사람이든 온톨로지가 노출한 이 행동 안에서만 움직인다. 자유롭게 쓰는 게 아니라, 허가된 행동을 호출하는 것이다.
핵심은 여기서 감사 로그와 권한 경계가 공짜로 따라온다는 점이다. 누가 무엇을 언제 바꿨는지가 데이터 모델에 박혀 있으니, 에이전트가 낸 변경도 사람이 낸 변경과 같은 규칙·같은 추적을 받는다. 사고가 나도 어느 행동에서 났는지 특정되고 되돌릴 수 있다.
왜 이게 해자인가
Palantir의 2026년 1분기 매출은 전년 대비 85% 늘었고, 미국 상업 부문은 133% 뛰었다. 그런데 실적 발표에서 대형 계약의 차별화 요인으로 꼽힌 건 모델 성능이 아니라 '정밀한 에이전트 거버넌스와 비용 통제’였다. 즉 이 회사가 파는 건 더 똑똑한 답이 아니라, 에이전트가 무엇을 어떤 규칙으로 바꿀 수 있는지를 통제하는 배관이다.
이유는 단순하다. 모델 성능은 매년 상품화된다. 오픈소스가 몇 달 뒤 따라잡고 가격은 계속 떨어진다. 하지만 "이 회사에서 환불은 누가, 어떤 한도로, 어떤 승인 단계를 거쳐 실행되는가"는 그 회사의 프로세스와 데이터에 박혀 있어서 옮겨지지 않는다. 검색은 이미 흔한 부품이 됐고, 남은 해자는 행동을 소유하는 쪽에 있다.
1인 사업자라면 어디서 시작하나
Palantir를 살 필요는 없다. 개념만 가져오면 된다.
먼저 당신의 에이전트가 부를 수 있는 행동을 5~10개로 좁혀 이름을 붙여라. refund_order, reschedule_delivery, flag_for_review 같은 식으로. 자유서술로 아무 API나 부르게 두지 말고, 이 목록 밖은 못 부르게 막는다.
그다음 각 행동에 세 가지를 붙인다. 실행 전 통과해야 할 검증(한도·상태 조건), 실패하거나 오작동했을 때의 되돌리기 경로, 그리고 누가 언제 왜 했는지 남는 로그. 금액이 크거나 외부로 나가는 행동은 사람 승인을 한 단계 끼운다.
이 세 줄만 지켜도 에이전트는 "그럴듯한 답을 주는 챗봇"에서 "믿고 상태를 맡길 수 있는 일꾼"으로 넘어간다. 그리고 그 경계선이, 남들이 못 따라오는 당신의 해자가 된다.
검색은 끝난 싸움이다. 이제 중요한 질문은 하나다. 당신의 시스템에서 무엇을, 누가, 어떤 규칙으로 바꿀 수 있는가. 그걸 타입으로 소유한 사람이 이긴다.