UiPath가 AI 에이전트에 같은 규칙을 건다…모델부터 실행까지 추적

UiPath는 2026년 9월 23일 라스베이거스 FUSION 플랫폼 발표 에서 AI 에이전트, 로봇, 사람에게 공통 정책 체계를 적용하는 거버넌스 업데이트를 공개했다. 발표에는 사용 모델을 파악하는 Model Hub, 실행 중 행동을 정책과 대조하는 Runtime Checker, 결과물을 평가하는 LLM-as-Judge Guardrail, 접근 권한을 정하는 정책과 규정 항목을 관리하는 Compliance Packs가 포함됐다. UiPath가 제시한 통제 범위는 모델 선택에서 실행과 자원 접근까지 이어진다.

독립 매체 SiliconANGLE의 FUSION 현장 보도 도 플랫폼 거버넌스 강화와 UiPath Coding Agents의 정식 제공을 확인했다. 기존 RPA 운영자가 구분해서 볼 부분은 기능마다 통제하는 시점이 다르다는 점이다. 모델 사용 현황은 실행 전에 영향을 받는 업무를 드러내고, Runtime Checker는 실행 중 행동을 살피며, 접근 정책은 애초에 사용할 수 있는 자원을 제한한다. 감사에 필요한 기록은 허용된 범위 안에서 실제로 무슨 일이 일어났는지를 설명하는 별도의 문제다.

공통 정책과 동일한 권한은 다르다

UiPath가 말하는 ‘같은 규칙’은 사람, 로봇, 에이전트에게 똑같은 권한을 준다는 뜻이 아니다. 각 주체에 정책을 적용하되 맡은 업무에 필요한 권한만 부여한다는 구상이다. 사람이 승인할 수 있는 변경, 로봇이 반복할 수 있는 처리, 에이전트가 호출할 수 있는 도구는 역할에 따라 달라질 수 있다. 공통인 것은 그 허용 범위를 정하고 실행을 그 기준과 연결해 살핀다는 방식이다.

이 구분은 에이전트가 기존 RPA 로봇과 함께 일할 때 선명해진다. 정해진 절차를 실행하는 로봇과 달리 에이전트는 작업 중 다음 행동이나 호출할 도구를 선택할 수 있다. 따라서 설계할 때 정한 권한만 확인해서는 실제 실행 경로를 모두 설명하기 어렵다. 발표된 정책 체계는 작업 주체가 바뀌어도 모델, 행동, 접근 범위를 같은 운영 틀에서 다루려는 시도다.

다만 공통 정책 체계가 곧 모든 자동화에 단일한 허용 목록을 적용한다는 의미는 아니다. 업무마다 필요한 데이터와 승인 주체가 다르기 때문이다. 운영상 핵심은 정책을 함께 관리하면서도 각 역할의 경계를 구체적으로 정할 수 있느냐다. 발표는 이 방향을 제시하지만, 개별 기업의 권한 설정이 자동으로 적절해진다고 보장하지는 않는다.

Model Hub는 모델 사용처와 처리 경로를 드러낸다

모델 단계에서 Model Hub의 역할은 가시성이다. 어떤 모델이 사용되는지, 어디에서 실행되는지, 요청이 어떻게 라우팅되는지를 중앙에서 파악하도록 설계됐다. 같은 자동화라도 연결된 모델이나 처리 경로가 달라지면 데이터 처리 조건과 결과의 특성이 달라질 수 있다. 모델 변경을 검토할 때 먼저 어떤 업무가 그 모델에 의존하는지 확인해야 하는 이유다.

여기서 보이는 것은 모델의 사용 현황이지, 개별 응답의 적합성 판정이 아니다. 특정 업무가 어떤 모델을 호출하는지 알더라도 그 업무에서 생성된 답변이 회사 기준을 충족했는지는 별도로 평가해야 한다. 모델을 바꾸는 결정과 생성된 내용을 승인하는 판단을 분리하면 Model Hub와 Guardrail의 역할이 겹치지 않는다.

모델이 여러 자동화에 연결돼 있다면 변경 영향도 한 업무에만 머물지 않을 수 있다. Model Hub가 제공하는 사용처와 라우팅 정보는 그 범위를 파악할 근거가 된다. 반대로 사용처가 보인다는 이유만으로 실행 중 도구 호출이나 데이터 접근까지 검증됐다고 볼 수는 없다. 그 부분은 다른 정책과 검사 지점이 맡는다.

Runtime Checker는 행동을, Guardrail은 내용을 검사한다

Runtime Checker의 검사 시점은 에이전트가 실행되는 동안이다. UiPath의 설명은 에이전트 행동을 정의된 정책과 지속해서 대조한다는 것이다. 이는 제작 당시의 설정만 확인하는 방식과 구별된다. 에이전트가 실제 업무에서 선택한 행동이 사전에 정한 경계와 맞는지를 운영 중에 살피겠다는 의미다.

LLM-as-Judge Guardrail은 다른 대상을 본다. 기업이 정한 기준으로 에이전트의 출력물을 평가하는 기능이다. 행동의 정책 적합성과 생성된 내용의 적합성은 서로 대체할 수 없다. 허용된 도구만 사용해도 부적절한 답변이 나올 수 있고, 답변이 그럴듯해도 허용되지 않은 자원에 접근했다면 별개의 문제가 남는다.

두 기능의 이름만으로 위반을 발견한 뒤의 처리까지 단정해서는 안 된다. Runtime Checker가 모든 환경에서 실행을 자동 중단하는지, 담당자에게 넘기는지, 기록을 남기는지는 발표문만으로 확정되지 않는다. Guardrail의 평가 역시 기업이 정한 기준과 검사 방식에 좌우된다. 평가 기능의 존재가 모든 답변의 정확성이나 업무 적합성을 보증하는 것은 아니다.

기존 RPA에서 쓰던 입력값 검증도 이 기능들과 목적이 다르다. 입력 형식이 맞는지 확인하는 일, 에이전트의 도구 사용이 정책에 맞는지 살피는 일, 생성된 답변을 평가하는 일은 각각 다른 질문이다. 이번 발표는 이 질문을 한 제품의 이름 아래 묶기보다 서로 다른 통제 지점에 배치했다는 점에서 읽을 가치가 있다.

접근 정책은 사용 범위를 정하고, 기록은 실행을 설명한다

Identity & Access Policies는 사람이나 자동화 주체가 특정 모델, 도구, 자원에 접근할 수 있는지를 정한다. 결과를 만든 뒤 평가하는 기능과 달리, 사용할 수 있는 자원의 범위를 먼저 제한하는 통제다. 에이전트가 여러 시스템의 도구를 호출하는 업무라면 어느 도구까지 허용되는지가 결과물의 품질만큼 중요한 조건이 된다.

최소 권한은 이 범위를 업무별로 좁힌다는 뜻이다. 예를 들어 기록을 조회하는 업무에 조회 권한이 필요하더라도 수정 권한까지 필요한 것은 아니다. 이는 특정 고객에게 이미 적용된 사례가 아니라 발표된 접근 정책의 운영상 의미를 설명하는 가상의 경우다. 공통 정책 체계와 최소 권한은 함께 성립할 수 있다.

Compliance Packs는 규제 기준과 내부 기준을 추적 가능한 통제 항목에 대응시킨다. 무엇을 기준으로 정책을 만들었는지 살필 수 있게 하는 기능이지, 그 자체가 특정 법규의 준수 인증이나 규제기관 승인을 뜻하지는 않는다. 기준을 항목에 연결하는 일과 실제 실행이 그 기준을 지켰는지 증명하는 일도 구분해야 한다.

감사 기록은 이 마지막 질문과 관련된다. 접근 정책이 가능한 행동의 경계를 정한다면, 기록은 실제 처리 과정의 흔적을 남겨 뒤에 설명할 단서를 제공한다. 다만 기록이 있다는 일반적인 설명을 모든 에이전트 행동의 상세한 판단 근거가 이미 저장된다는 주장으로 넓힐 수는 없다. 어떤 이벤트가 남고 얼마나 오래 보관되는지는 해당 기능과 고객 환경의 설정에 따라 확인해야 한다.

제공 상태는 기능별로 갈린다

행사에서 함께 소개됐다는 사실과 각 기능의 정식 제공 상태는 별개다. UiPath Coding Agents는 정식 제공으로 전환됐고, UiPath Cartographer도 행사 시점에 이용 가능한 제품으로 소개됐다. Cartographer는 문서, 시스템, 담당자의 설명을 바탕으로 업무 규칙과 예외를 담는 Map of Work를 만드는 역할을 한다. 이 업무 맥락은 자동화 설계에 쓰이지만 Runtime Checker의 실행 중 정책 검사를 대신하지 않는다.

반면 UiPath Agents 릴리스 노트 는 LLM as Judge Guardrail을 미리보기로 분류한다. 해당 설명에 따르면 이 기능은 출력물뿐 아니라 프롬프트와 LLM 호출도 사용자가 작성한 기준에 따라 평가할 수 있다. 검사할 때마다 별도의 LLM 호출이 발생해 에이전트 자체의 사용량 외에 추가 사용량이 집계된다는 점도 명시돼 있다.

Model Hub는 모델 사용을 파악하는 기능으로 발표됐지만, 그 상태를 Runtime Checker나 Compliance Packs의 제공 상태에 그대로 적용할 수는 없다. FUSION 플랫폼 발표문은 두 기능의 역할을 설명하면서도 개별 출시 단계, 국내 고객에게 적용되는 조건, 정책 위반 시 처리 방식을 상세히 밝히지 않았다. 따라서 발표된 통제 지점을 모두 즉시 동일한 조건으로 운영할 수 있다고 해석하면 범위를 넘는다.

현재 확인된 변화는 UiPath가 모델 사용, 실행 중 행동, 자원 접근과 감사 가능성을 공통 정책 아래 연결해 제시했다는 것이다. 정식 제공이 확인된 제품과 미리보기 기능은 구별되며, Runtime Checker와 Compliance Packs의 구체적인 제공 조건은 추가 확인이 필요하다. 특히 실제 운영에서 정책 위반이 어떻게 처리되고 어떤 실행 기록이 남는지는 발표된 기능 이름만으로 판단할 수 없는 부분으로 남아 있다.

함께 읽기:

• Microsoft가 AI 책임 기준을 다시 썼다, 에이전트가 바꾼 규칙
• Boomi가 AI 에이전트 통제판을 내놨다…토큰 폭주도 막는다
• Salesforce가 AI 에이전트 통제판을 꺼냈다…전면 출시는 내년이다