요약본
-
기업은 명확한 권한 내에서 작업을 신뢰성 있게 완료할 수 있는 가장 비자율적인(least autonomous) 어시스턴트를 선택해야 합니다.
-
실용적인 네 가지 수준이 있으며, 코파일럿부터 자율 전문가까지 나뉘고, 각 단계마다 권한, 제어 장치, 그리고 파급 범위(blast radius)가 증가합니다.
-
어시스턴트가 중요한 시스템에 접근하게 될수록 승인 게이트(Approval gates), 외부 정책 강제화(external policy enforcement), 감사 가능한 기록(auditable receipts)이 더욱 중요해집니다.
고급 AI 어시스턴트를 구매하는 것은 마치 미니어처 정부를 설계하는 것과 같습니다. 누가 접근할 수 있나요? 누가 결제를 승인하나요? 로봇이 같은 고객에게 두 번 환불한 이유를 재무팀에 누가 설명하죠?
고급 AI 어시스턴트는 비즈니스 맥락을 이해하고, 다단계 작업을 계획하며, 연결된 도구를 사용하고, 명확한 권한 내에서 행동하면서 감사 가능한 기록을 남깁니다. 저는 예전에는 이러한 제품들을 데모로 판단했습니다. 매끄러운 대화, 12개의 앱 로고, 그리고 스타십 엔터프라이즈처럼 빛나는 인터페이스가요. 그것은 마치 아름다운 PowerPoint를 만들기 위해 CFO를 고용하는 것과 같습니다. 멋지지만, 관련성이 없습니다.
저는 어시스턴트를 위임된 권한에 따라 분류합니다. 코파일럿(Copilot)은 읽고 추천합니다. 워크플로우 어시스턴트(workflow assistant)는 행동을 준비한 다음 승인 게이트에서 대기합니다. 경계가 설정된 운영자(bounded operator)는 회사 정책 내에서 실행합니다. 완전히 자율적인 전문가(fully autonomous specialist)는 저 없이도 변화하는 상황 속에서 계속 작업합니다.
각 단계는 더 많은 가치를 창출하고 더 큰 파급 범위를 만듭니다. 저는 작업을 신뢰성 있게 완료할 수 있는 가장 비자율적인 시스템을 원합니다. 데모가 멋져 보인다고 해서 불안정한 에이전트에게 더 많은 권한을 주는 것은 기업용 신용카드를 든 창업자의 코스프레에 불과합니다.
코파일럿은 대부분의 기업이 시작해야 할 곳입니다
코파일럿은 승인된 비즈니스 시스템에서 맥락을 수집하고, 사람이 모든 중요한 행동을 통제하는 동안 작업을 추천합니다.
Copilots는 문서화되지 않은 예외, 모순되는 기록 또는 누군가의 머릿속에 갇힌 결정이 있는 프로세스에 적합합니다. 예를 들어 리서치, 이상 징후 검토 및 캠페인 초안 작성이 있습니다. 어시스턴트는 승인된 자료를 검사하고 답변을 준비하지만, 제가 카르보나라를 먹는 동안 계정 상태를 조용히 변경할 수는 없습니다.
작동 방식은 간단합니다. 저는 copilot에게 작업을 지시합니다. 그것은 허가된 출처를 확인하고, 관련 자료를 선택하며, 그 기록들을 제 지침과 비교하여 응답을 준비합니다. 유용한 제품은 중요한 주장이 어디서 왔는지 보여주는데, 특히 기록들이 상충할 때 그렇습니다. 저는 증거를 검사한 다음, 클릭하거나, 수정하거나, 작은 의식적인 매장을 수행합니다. 실행(Execution)은 여전히 저에게 남아 있어, 오류가 고객 이메일, 결제 또는 데이터베이스 변경이 되기 전에 복구 가능하게 만듭니다.
커넥터 커버리지만으로도 copilot을 실제보다 똑똑해 보이게 만들 수 있습니다. Salesforce, Gmail, Instagram 아이콘은 공급업체가 통합(integration)을 구축했다는 것을 증명할 뿐입니다. 그것들은 어시스턴트가 “증거를 찾지 못했습니다”와 “이것은 결코 일어나지 않았습니다”의 차이를 아는지 여부는 증명하지 않습니다. 이 두 문구는 데모에서는 비슷하게 들리지만, 돈이나 직원 기록이 채팅창에 들어가면 완전히 다릅니다.
저는 권한을 좁게 유지합니다. 읽기 전용(Read-only) 접근이라도 급여, 계약서 및 개인 대화 내용을 노출할 수 있습니다. 어시스턴트가 지난주 영업 통화를 요약하는 데 창업자의 전체 디지털 다락방이 필요하지는 않습니다.
기업 에이전트 벤치마크는 신중한 접근을 요구합니다. Argo-Bench에서 실제 분석 워크플로우를 테스트한 결과, 가장 성능이 좋은 모델도 약 35%의 작업에서 높은 점수 임계값에 도달하는 것으로 나타났습니다. 이 임계값은 95점으로, 그럴듯해 보이는 답변보다는 거의 완벽한 작업을 요구합니다. 세 번 중 한 번 정도 성공하는 에이전트는 코파일럿으로서 시간을 절약할 수는 있습니다. 하지만 급여 처리를 하룻밤 사이에 맡기지는 않을 것입니다.
승인 게이트가 있는 어시스턴트가 복잡한 워크플로우를 처리합니다
승인 게이트(approval-gated) 워크플로우 어시스턴트는 여러 비즈니스 시스템에 걸쳐 작업 준비 및 조정을 할 수 있지만, 회사에서 지정한 경계 지점에서 인증된 확인을 위해 일시 중지됩니다.
만약 제가 다음 주 캠페인을 준비해 달라고 요청하면, 허용된 기록들을 검토하고 카피를 초안 작성하여 올바르게 저장합니다. 게시하거나 돈을 쓰기 전에, 제게 제안된 조치를 보여주고 승인을 요청합니다. 기본적인 코파일럿보다 방해가 적으면서도, 비용이 많이 드는 결정은 여전히 제 책상 위를 거칩니다.
좋은 승인 워크플로우는 단계 간에 상태(state)를 유지합니다. 어시스턴트는 저의 목표를 작업들로 분할하고 각 작업에 허용된 도구를 선택합니다. 한 도구의 결과물은 다음 단계를 형성할 수 있으며, 예를 들어 영업 실적을 사용하여 캠페인 초안을 수정하는 식입니다. 정책이 멈추는 지점을 결정합니다. 이 게이트에서는 시스템이 조치, 지원 증거, 그리고 영향을 받는 시스템을 보여줍니다. 저의 승인은 그 특정 조치에 대한 인증된 지침이 됩니다. 워크플로우는 새로 시작하거나 새로운 모험을 꾸미기보다는 저장된 상태에서 재개됩니다.
승인 화면은 채팅창보다 더 중요합니다. '캠페인 승인' 버튼만으로는 대상 고객, 예산, 최종 카피가 없으면 쓸모가 없습니다. 환불, 직원 변경, 고객 계정 업데이트도 마찬가지입니다. 모호한 녹색 버튼 하나는 사람을 장식용 보안 통제 장치로 만듭니다.
저는 보기 흉한 입력값으로 이 제품들을 테스트합니다. 작업 도중에 접근 권한을 취소하고, 모순되는 기록을 삽입하며, 예상했던 도구를 제거해봅니다. 어시스턴트는 깔끔하게 중단하고 그 이유를 설명해야 합니다. 만약 취소된 권한 주변에서 즉흥적으로 작동한다면, 프로덕션 데이터에 연결하기 전에 그것을 알아야 합니다.
'승인 피로(Approval fatigue)'는 또 다른 실패 모드입니다. 어시스턴트가 모든 조회와 무해한 초안 작성마다 확인을 요청한다면, 저는 쿠키 배너를 볼 때 느끼는 영적인 인식을 가지고 '예'를 클릭할 것입니다. 벤더들은 되돌릴 수 있는 준비 단계(reversible preparation)와 결과를 초래하는 실행 단계(consequential execution)를 분리하는 커넥터 레벨의 경계가 필요합니다. 사적인 초안을 업데이트하는 것과 고객 계정 상태를 변경하는 것이 둘 다 API를 사용한다는 이유만으로 같은 정책을 공유해서는 안 됩니다.
이것이 제가 생각하는 크로스 애플리케이션 작업에 대한 기본 전제입니다. 현재의 에이전트들은 현실적인 엔터프라이즈 작업에서는 여전히 신뢰하기 어렵지만, 복사, 서식 지정, 조정 등의 많은 작업을 제거할 수는 있습니다. 인간의 승인은 결과가 시작되는 지점에 위치해야 합니다.
경계가 설정된 연산자(Bounded operators)는 모델 외부의 정책이 필요하다
경계가 설정된 AI 연산자(bounded AI operator)는 그 목표, 권한 및 에스컬레이션 경계를 정의하는 운영 범위(operating envelope) 내에서만 개별적인 승인 없이 작동합니다.
저는 저가치 회계 예외 처리, 기존 약정 내의 선적 통합 또는 실행 전에 규칙을 명시할 수 있는 모든 프로세스를 위해 이것을 고려할 것입니다. 그 조건이 창업자들이 인정하는 것보다 더 많은 유스케이스를 무력화시킵니다. '좋은 판단력을 사용하라'는 조언은 이탈리아 노냐(nonna)의 조언과 같습니다. 그것은 끔찍한 프로덕션 정책입니다.
Oracle Fusion Claw는 유용한 아키텍처를 제공합니다. 프론티어 모델(frontier model)이 태스크에 대해 추론하고, 계획을 세우고, 적응합니다. 런타임은 대용량 계산 및 실행을 결정론적 엔터프라이즈 소프트웨어로 이동시킵니다. 엔터프라이즈 운영 범위(Enterprise Operating Envelope)는 목표, 정책, 권한, 위험 임계값, 승인 요건, 의사결정 권한, 에스컬레이션 경계를 제공합니다. 아웃컴 트러스트 하네스(Outcome Trust Harness)는 각 실행에 신원(identity), 데이터, 역량(capability), 액션 제어를 적용합니다. 고객은 명시적으로 위임된 권한 내에서 지원부터 실행까지 자동화를 선택할 수 있습니다. 그 후, 아웃컴 영수증(Outcome Receipt)은 사용된 권한, 고려된 증거, 내려진 결정 및 결과 거래를 기록합니다. 모델이 해석하고; 일반적인 엔터프라이즈 계산은 정확하게 대규모로 실행됩니다.
EDPB 부의장 Jelena Virant Burnik은 다음과 같이 말했습니다:
새로운 EDPB 가이드라인은 데이터 보호 기관(DPA)이 자체적으로 또는 다른 시정 조치와 함께 행정 벌금을 부과할지 여부를 결정하는 방식을 더욱 정렬하는 데 있어 주요한 단계입니다. GDPR은 DPA의 시정 권한을 크게 증가시켰으며, 벌금은 효과적인 집행을 위한 중요한 수단으로 작용합니다. 이 가이드라인은 유럽 전역에서 GDPR의 일관된 적용을 보장하고 더 큰 명확성을 제공하겠다는 우리의 의지를 재확인합니다.
저는 그 분리가 마음에 듭니다. 언어 모델은 추론과 재계획에 도움을 줍니다. 급여 계산(Payroll arithmetic)은 매번, 가급적 창의성을 발견하지 않고도 급여 계산처럼 작동해야 합니다.
Oracle은 더 광범위한 포트폴리오인 75개의 에이전틱 애플리케이션 중 25개의 Claw 기반 애플리케이션을 발표했습니다. 이는 금융, 인력 관리, 공급망 전반에 걸친 진지한 야심을 보여줍니다. 하지만 이것이 제 회사 내부, 저의 권한과 저주받은 과거 데이터 내에서의 신뢰성을 증명하는 것은 아닙니다.
아무도 Fusion Claw의 비용 절감액, 오류율 또는 비즈니스 성과에 대한 독립적인 측정치를 가지고 있지 않습니다. 승인 빈도 또한 알 수 없습니다. Oracle의 영수증이 실행 과정을 감사 가능하게 만들 수는 있지만, 고객 증거는 해당 프로세스가 무인으로 실행될 자격이 있는지 여부를 보여줘야 합니다.
조달 과정에서 저는 실패한 워크플로우에 대한 결과 영수증을 요청할 것입니다. 이 영수증은 비즈니스 소유자, 위임된 권한 및 사용된 증거를 식별하고, 중단되기 전의 모든 거래 목록을 나열해야 합니다. 만약 여기에 “어시스턴트가 결정했다”고 적혀 있다면, 저와 제 회계사는 소프트웨어 세션(séance)에 초대받은 것과 같습니다.
완전히 자율적인 전문가는 드물어야 한다
완전히 자율적인 AI 전문가는 다른 메시지를 기다리지 않고 지속적으로 모니터링하고, 재계획하며, 도구를 호출하므로, 그 제어는 프롬프트와 독립적으로 작동해야 합니다.
지속 시간과 권한이 위험을 만듭니다. 장시간 실행되는 에이전트는 차단된 도구, 변경된 권한, 문서나 웹페이지의 적대적 콘텐츠를 만나게 됩니다. 이는 목표를 진전시키면서도 저의 의도를 위반하는 다른 경로를 찾을 수 있습니다. 프롬프트 주입(Prompt injection)은 외부 콘텐츠가 모델을 리디렉션하게 함으로써 이 문제를 악화시킵니다. IBM은 에이전트가 지침을 무시하거나 손상될 수 있으므로, 프롬프트만으로는 전체 보안 부담을 감당할 수 없다고 주장합니다. 신원 시스템(Identity systems), 런타임 제어(runtime controls), 네트워크 정책 및 인프라는 모델 주변의 규칙을 강제해야 합니다.
진지한 제어 평면(control plane)은 모든 단계를 확인합니다. 검증된 기계 신원(machine identity)은 어떤 워크로드가 접근을 원하는지 확립합니다. 짧게 유지되는 자격 증명(Short-lived credentials)은 그 도달 범위와 지속 시간을 제한합니다. 런타임은 접촉 전에 파일, 도구 및 네트워크 목적지를 확인합니다. 모니터링은 시도된 동작과 정책을 비교하고 편차를 기록합니다. 지출 한도는 재정적 손상을 방지합니다. 독립적인 비상 차단 스위치(kill switch)는 에이전트가 계속 움직임을 요청하는 동안 프로세스를 격리할 수 있습니다. 저는 이 범주를 프로덕션 인프라와 같이 취급하는데, 열정은 끔찍한 접근 제어 모델이기 때문입니다.
일부 벤더들은 금지된 도구를 숨기는 것만으로 충분하다고 주장합니다. 저는 그 매력을 이해합니다. 에이전트는 보이지 않는 도구를 선택할 수 없고, 필터링은 우발적인 오용을 줄여주기 때문입니다. 하지만 스크립트화된 클라이언트는 숨겨진 도구를 직접 호출할 수 있으며, 모델은 프롬프트에서 그 이름을 추론할 수도 있습니다. 한 MCP 평가에 따르면, 권한 부여가 도구 본체 내부에서만 이루어졌을 때 금지된 도구 노출이 21%였던 반면, 권한 인식 가시성(permission-aware visibility)과 호출 강제(invocation enforcement)를 결합했을 때는 보고된 노출이 0%였습니다. 표지판이 숨겨져 있어도 문에는 자물쇠가 필요합니다.
샌드박스 결과 역시 동등한 주의가 필요합니다. 한 컨설팅 회사가 OpenShell의 기본 정책을 테스트한 결과, OpenShell 없이 실행했을 때마다 누출되던 것과 달리 카나리 시크릿(canary-secret) 유출이 0건인 것으로 나타났습니다. 하지만 이 테스트는 하나의 Apple Silicon Mac에서 작은 로컬 모델을 사용했기 때문에 Docker, Podman 또는 Kubernetes 전반의 성능을 입증할 수는 없습니다. 운영자 활성화된 권한(Operator-enabled permissions) 역시 데이터가 외부로 나갈 수 있는 경로를 다시 열었습니다. 샌드박스를 설치하는 것은 보안 회의를 시작한다는 의미인데, 저는 그 회의를 건너뛰기를 바랐기 때문에 무례합니다.
대부분의 기업은 준비가 전혀 되어 있지 않습니다. ISACA에 따르면 설문 조사에 참여한 조직 중 단 8%만이 AI 관련 사고 대응 연습(incident-response exercises)을 정기적으로 수행하는 반면, 64%는 이를 전혀 수행하지 않았습니다. 에이전트 비활성화 연습을 해본 적 없는 회사는 주말 동안 그 에이전트를 작동시키게 해서는 안 됩니다.
저의 첫 자율 배포(autonomous deployment)는 제한적인 권한을 얻기 전에 몇 주 동안 섀도우 모드(shadow mode)로 운영될 것입니다. 벤더 데모에는 취소된 권한, 상충되는 증거, 그리고 시도된 과지출이 포함되어야 합니다. 저는 거부, 에스컬레이션(escalation), 그리고 롤백(rollback) 과정을 실시간으로 보고 싶습니다.
Clausebench는 다음과 같이 말했습니다:
나중 날짜가 적은 양의 작업이 아니라 같은 양의 작업을 할 수 있는 더 많은 시간입니다.
