엔터프라이즈 에이전트 플랫폼의 거버넌스와 종속 리스크

플랫폼 선택은 통제 계층의 귀속을 정한다

2026년 중반 기업용 에이전트 시장은 거버넌스 계층형, 워크스페이스 태스크형, 조직 컨텍스트형으로 나뉘어 경쟁하고 있다. 모델의 벤치마크 점수나 컨텍스트 창만으로 우위를 설명하기는 어렵다. 사내 시스템에 연결할 수 있는 범위, 정책을 집행하는 위치, 조직 데이터 접근권을 누가 관리하는지가 실제 도입의 성패를 가른다.

워크스페이스 에이전트는 2026년 7월 6일 크레딧 기반 과금으로 전환했고, 데스크톱 중심이던 태스크 실행형 제품은 7월 7일 웹·모바일 채널까지 확장했다. 자율 에이전트의 실행 비용과 사용 채널이 넓어지면서 플랫폼은 단순한 도구 구매가 아니라 장기 종속을 동반하는 통제 구조의 선택이 됐다.

협업 도구 내장형 제품은 Teams·SharePoint·Outlook 안에서 네이티브로 동작하며 외부 인증 표면을 따로 관리할 필요가 없다는 장점을 제시한다. 반면 개발자 신원의 권한을 상속하고 정책 엔진을 내장하는 방식과, 거버넌스·관측을 서드파티에 맡겨 도입 마찰을 낮추는 방식은 운영 책임의 위치가 다르다.

실행 경로를 구성하는 계층

에이전트 오케스트레이션은 작업을 분해하고, 도구와 다른 에이전트 호출을 조율하며, 상태·재시도·에스컬레이션·완료 판정을 관리한다. 플랫폼 간 차이는 다중 에이전트 협업 지원 여부와 장시간 작업을 다루는 방식에서 특히 드러난다. 단발 태스크를 중심에 둔 제품과 다단계 워크플로를 전제로 한 제품은 설계 자체가 다르다.

사내 시스템 커넥터는 SaaS 업무 시스템, 데이터 웨어하우스, 문서 저장소, 티켓·CRM, 사내 API를 연결한다. 필요한 커넥터가 있는지, 위임 또는 서비스 계정 중 어떤 권한 모델을 쓰는지, 커스텀 커넥터를 얼마나 어렵게 개발해야 하는지를 함께 봐야 한다. 모델 품질의 차이보다 커넥터 공백이 도입 실패의 직접 원인이 되는 경우가 많다.

SSO는 사용자 인증을 통합하고 SCIM은 계정 프로비저닝과 해제를 자동화한다. 에이전트 전용 서비스 아이덴티티 역시 같은 체계 안에서 관리할 수 있다. 실행 사용자의 권한을 그대로 상속하면 관리가 단순해지는 대신 과다 노출 위험이 생기고, 에이전트에 별도 권한을 부여하면 노출을 줄일 수 있지만 권한 관리 부담이 늘어난다.

정책 엔진은 접근 가능한 데이터 범위, 허용 작업 목록, 금액·건수 상한, 외부 발신 승인, 에스컬레이션 조건을 통제한다. 이 정책이 프롬프트 안에 묻혀 있으면 모델을 교체할 때 통제가 흔들릴 수 있다. 정책을 별도 계층으로 분리한 구조가 유지보수에 유리하다.

감사 로그에는 실행 주체, 호출 도구, 접근 데이터, 수행 작업, 승인 이력, 비용이 남아야 한다. 관측 대상은 작업 성공률, 에스컬레이션율, 단계별 지연, 크레딧 소비량이다. 크레딧 과금 전환 이후 비용 관측은 선택 사항이 아니라 운영 항목이 됐다.

이식 가능한 자산은 프롬프트·지시문, 표준 프로토콜을 준수하는 도구 정의, 평가셋, 워크플로 정의다. 반대로 플랫폼 고유의 오케스트레이션 설정, 내장 커넥터 구성, 정책 엔진 규칙, 조직 컨텍스트 색인은 쉽게 옮길 수 없다.

⤢✕

커넥터와 권한 모델부터 검증한다

평가의 첫 항목은 필요한 사내 시스템 커넥터의 존재 여부다. 커넥터가 없으면 개발로 메워야 하고, 이 비용이 플랫폼 간 실질적인 차이를 만든다. 다음은 권한 모델과 정책 엔진이다. 규제 업종에서는 이 요소가 사실상 결격 판정 기준이 된다. 모델 교체 가능성과 이식 가능한 자산 범위는 그 뒤에 검토한다. 벤치마크 점수를 앞세운 선택은 도입 이후 커넥터와 권한 문제로 되돌려지는 경우가 많다.

초기 적용 대상은 반복적이고 정형화됐으며 결과를 검증하기 쉽고 실패 비용이 낮은 업무가 적합하다. 금액·계약 처리, 외부 고객 접점, 규제 문서 생성은 후순위로 둔다. 파일럿을 후순위 업무에서 시작하면 통제 요건에 막혀 진척이 없고 플랫폼 평가도 늦어진다.

권한 상속을 택했다면 상속된 권한을 실측으로 검증해야 한다. 사용자의 광범위한 권한이 에이전트를 거쳐 새 노출 경로가 되는지 확인하는 과정이다. 전용 아이덴티티를 쓸 때는 생성과 회수로 이어지는 계정 수명주기를 SCIM으로 자동화해야 한다. 수동 관리는 유령 계정을 남긴다.

저장소·폴더·테이블의 접근 범위는 명시적 허용 목록으로 관리한다. 전체 접근 뒤 필터링하는 방식은 로그에 과다 접근을 남긴다. 접근 범위 변경도 승인 절차의 대상이어야 한다.

계약에는 데이터·설정 반출 형식, 반출 지원 기간, 서비스 종료 유예 기간을 명시한다. 도구 정의는 표준 프로토콜 기반으로 작성해 플랫폼을 바꿀 때도 재사용할 수 있게 유지한다. 크레딧 과금 구조에서는 자율 에이전트의 반복 실행이 비용을 비선형으로 늘릴 수 있으므로, 워크플로별 크레딧 상한과 알림 임계를 미리 설정한다. 거버넌스 문서에는 허용 업무 목록, 승인 지점, 데이터 접근 범위, 에스컬레이션 기준, 비용 상한, 감사 주기를 포함한다.

각 플랫폼 유형이 감수하는 대가

구분	거버넌스 계층형	워크스페이스 태스크형	조직 컨텍스트형
강점	정책·감사·통제	개별 업무 실행 속도	업무 데이터 기반 정확도
통제 주체	플랫폼 내장	상당 부분 서드파티 위임	기존 권한 체계 상속
도입 마찰	높음	낮음	중간(테넌트 정합 필요)
적합 조직	규제·컴플라이언스 중심	속도 우선 실무팀	협업 도구 집중 사용 조직
커넥터 범위	거버넌스 대상 시스템	생산성 도구·업무 SaaS	자사 스택 우선
종속 강도	정책 규칙 이식 불가	상대적으로 낮음	컨텍스트 색인 종속 강함

태스크형은 개인 지식 노동자의 실행 속도에 강점이 있고, 거버넌스 계층형은 정책과 감사에 강하다. 조직 컨텍스트형은 보유 업무 데이터를 활용한 정확도에서 장점을 보인다. 규제·컴플라이언스 기능이 도입 승인권을 가진 조직에서는 태스크형의 서드파티 위임 구조가 결격 요소가 될 수 있다. 반대로 속도가 가장 중요한 팀에서는 거버넌스형의 도입 마찰이 진척을 막는다.

단일 플랫폼 표준화는 아이덴티티·정책·감사를 한곳으로 모아 운영 비용을 낮춘다. 대신 특정 업무에는 맞지 않는 플랫폼을 강요할 수 있다. 업무별 다중 플랫폼은 적합성을 확보하지만 권한 체계와 감사 로그가 분산되고, 크레딧 과금 체계가 달라 비용 비교도 어려워진다. 아이덴티티와 감사는 단일화하고 실행 플랫폼만 복수로 두는 절충이 현실적이다.

상용 플랫폼은 커넥터·정책 엔진·감사를 즉시 확보해 리드타임이 짧다. 다만 정책 규칙과 오케스트레이션 설정은 이식 불가 자산으로 남는다. 자체 구축은 종속을 피하고 통제를 온전히 보유할 수 있지만 커넥터 개발, 아이덴티티 연동, 감사 체계 구축을 모두 감당해야 한다. 커넥터 수요가 적고 통제 요건이 특수한 조직에서만 자체 구축의 총비용이 유리하다.

조달과 벤더 관리에 반영할 항목

에이전트 플랫폼 조달은 소프트웨어 구매보다 통제 계층을 고르는 일에 가깝다. 커넥터 범위, 권한 모델, 이식 가능 자산의 범위를 평가 항목에 명시해야 한다. 크레딧 과금은 사용량 예측을 어렵게 해 예산 산정 위험을 만든다. 비용 상한 설정 가능 여부를 조달 요건으로 두는 것이 방어 수단이 된다.

플랫폼 선택은 아이덴티티·정책·감사 계층이 어느 곳에 귀속되는지를 결정한다. 이 계층들이 실행 플랫폼에 결합돼 있으면 교체 비용은 급증한다. 분리 가능성을 아키텍처 요건으로 두는 이유다. 권한 상속은 구현이 간단하지만 기존 권한의 과다 부여를 그대로 증폭할 수 있으므로, 상속 결과 검증은 통합 설계의 필수 단계다.

과금 방식 변경과 채널 확장이 단기간에 이루어지는 시장에서는 단가와 과금 구조 변경 통지 조항을 계약에 확보해야 한다. 도입 시점부터 이식 가능 자산과 이식 불가 자산을 목록화하면, 이후의 플랫폼 교체 판단을 근거 있는 계산으로 바꿀 수 있다.

거버넌스가 운영 기준으로 자리잡는 흐름

거버넌스가 경쟁축으로 굳어지면서 정책 엔진·감사·관측 기능의 격차가 도입 결정의 주요 변수가 되는 흐름이다. 크레딧 기반 과금이 확산되면 워크플로 단위 비용 상한은 표준 운영 항목으로 편입된다.

대규모 조직에서는 아이덴티티와 감사를 단일화하고 실행 플랫폼은 복수로 두는 절충 구성이 표준 패턴으로 정착할 전망이다. 표준 프로토콜 기반 도구 정의가 넓게 채택되면서 이식 가능한 자산의 범위도 플랫폼 평가 항목으로 명문화될 전망이다.