IBM watsonx Orchestrate로 설계하는 엔터프라이즈 에이전트 거버넌스

IBM watsonx Orchestrate의 멀티에이전트 컨트롤 플레인과 정책 집행, 감사 추적, 인간 감독 구조를 분석한다.

2026-08-14 · 최초 발행 2026-05-20

에이전트가 늘어나면 운영의 중심도 달라진다

수십 개의 AI 에이전트를 다루던 방식으로 수천 개의 에이전트를 통제하기는 어렵다. 팀마다 다른 플랫폼과 프레임워크를 사용하면 개별 에이전트의 성능보다 조직 전체의 가시성, 정책 일관성, 책임 추적이 더 큰 문제가 된다.

IBM은 Think 2026에서 이런 변화를 AI 도입의 두 번째 파도로 설명했다. 첫 번째 파도가 에이전트를 만들고 실험하는 시기였다면, 다음 과제는 여러 조직이 구축한 수천 개의 에이전트를 안전하고 투명하게 운영하는 것이다.

현재 프라이빗 프리뷰인 차세대 watsonx Orchestrate는 이 문제를 다루는 에이전틱 컨트롤 플레인으로 설계됐다. IBM 네이티브 에이전트뿐 아니라 Langflow, LangGraph, 오픈 A2A(Agent-to-Agent) 프로토콜 기반 에이전트를 하나의 레이어에 등록하고 거버넌스와 작업 라우팅을 적용한다. 향후에는 더 넓은 범위의 상호운용성을 지원할 예정이다.

엔터프라이즈 에이전트 생태계watsonx Orchestrate멀티에이전트 컨트롤 플레인IBM 네이티브 에이전트Langflow 에이전트LangGraph 에이전트A2A 프로토콜 에이전트서드파티 프레임워크에이전트 레지스트리(등록 메타데이터 관리)정책 집행 엔진(신원·접근·감사 정책)작업 라우팅 엔진(에이전트 위임)중앙화 모니터링(실시간 추적)일관된 거버넌스 적용

핵심은 오케스트레이션 범위를 작업 연결에 한정하지 않는 데 있다. 에이전트가 어디에서 만들어졌는지와 관계없이 등록, 정책 적용, 통신 통제, 모니터링을 같은 운영 계층에서 처리한다.

등록 단계에서 권한과 호출 관계를 묶는다

컨트롤 플레인에 들어오는 모든 에이전트에는 고유한 신원과 접근 권한 프로파일, 데이터 접근 범위가 정의된다. 구조만 보면 기존 IAM(Identity and Access Management)과 닮았지만, 관리 대상의 행동 방식은 다르다.

사용자는 대체로 주어진 권한 안에서 시스템을 직접 사용한다. 반면 에이전트는 자율적으로 작업하고 다른 에이전트를 호출할 수 있다. 따라서 데이터 접근 권한만 정해서는 충분하지 않다. watsonx Orchestrate는 등록 과정에서 각 에이전트가 접근할 수 있는 데이터와 호출할 수 있는 다른 에이전트를 함께 명시하도록 강제한다.

이 등록 정보는 단순한 인벤토리가 아니다. 이후 모든 실행 요청에서 정책을 평가하는 기준이 된다.

실행 중에는 요청마다 정책을 평가한다

등록된 에이전트가 작업을 시작하면 정책 집행 엔진이 동작을 실시간으로 감시한다. 적용 범위는 신원과 접근, 행동, 에이전트 간 통신으로 나뉜다.

신원 및 접근 정책은 에이전트가 허용된 데이터 범위를 벗어나는지 검사한다. 범위를 초과한 요청은 차단되고 알림이 발생한다. 기업 네트워크의 방화벽처럼 접근 경계를 실행 시점에 집행하는 셈이다.

행동 정책은 외부 API 호출이나 대용량 데이터 처리 같은 특정 작업에 사전 정의된 승인 절차를 적용한다. 에이전트가 기술적으로 실행할 수 있는 작업이라도 정책상 승인이 필요하면 곧바로 진행할 수 없다.

에이전트 간 통신 정책은 한 에이전트가 다른 에이전트를 호출할 권한이 있는지 확인한다. 승인되지 않은 호출 관계라면 컨트롤 플레인이 통신을 차단한다.

"인간 감독자""감사 로그 시스템""데이터 소스""컨트롤 플레인 정책 엔진""에이전트 (외부 소스)""인간 감독자""감사 로그 시스템""데이터 소스""컨트롤 플레인 정책 엔진""에이전트 (외부 소스)"alt[정책 통과][정책 위반]데이터 접근 요청에이전트 신원 확인접근 권한 정책 평가데이터 접근 허용데이터 반환접근 성공 로그 기록접근 거부 응답정책 위반 알림 기록즉시 알림 전송감사 추적 영구 보존

결과보다 결정 경로를 남기는 감사 구조

엔터프라이즈 환경에서는 에이전트가 어떤 결과를 냈는지만 확인해서는 책임 소재를 설명하기 어렵다. watsonx Orchestrate는 에이전트의 결정, 데이터 접근, 서비스 호출을 불변(immutable) 로그로 기록해 결과가 만들어진 경로를 추적한다.

특정 비즈니스 결과에서 출발해 어느 에이전트의 어떤 결정이 영향을 미쳤는지 역추적할 수 있다. 에이전트가 접근한 데이터의 전체 기록도 남기므로 데이터 프라이버시 사고가 발생했을 때 영향 범위를 파악하는 근거가 된다.

감사 로그는 규제 준수(Regulatory Compliance) 보고에 활용할 수 있도록 설계된다. 금융 서비스 기업은 이를 바탕으로 AI 에이전트의 의사결정이 GDPR, DORA, SOX 등의 규제를 준수했는지 입증할 수 있다. 기업 이사회와 규제 당국이 요구하는 추적 가능성을 운영 계층에서 확보하려는 접근이다.

자율 실행과 인간 승인의 경계를 조정한다

IBM의 거버넌스 구조는 모든 작업을 사람이 승인하도록 만들지 않는다. 시스템이 실행 중인 에이전트의 위험도를 평가하고, 임계값을 넘는 상황을 인간 감독자에게 넘기는 방식이다.

평소와 다른 패턴으로 대용량 데이터에 접근하거나, 특정 금액 이상의 금융 거래를 승인하려 하거나, 민감 데이터를 외부 서드파티 서비스로 보내려는 경우가 에스컬레이션 대상이 될 수 있다. 정책 위반을 반복적으로 시도하는 상황도 포함된다.

위험도가 낮으면 에이전트가 자율적으로 실행을 이어간다. 중간 수준에서는 알림을 남기고 모니터링을 강화하며, 높은 수준에서는 작업을 일시 중단한 뒤 인간의 승인을 기다린다. 긴급한 상황은 즉시 차단하고 인시던트로 전환한다.

에이전트 실행위험도 평가 엔진위험도 수준낮음: 자율 실행계속 진행중간: 소프트 알림모니터링 강화높음: 인간 승인 필요실행 일시 중단긴급: 즉시 차단인시던트 생성감사 로그 기록인간 감독자 알림보안 즉시 통보감독자 결정승인: 실행 재개거부: 작업 취소에스컬레이션: 추가 검토

이 구조에서 인간 감독은 에이전트 자율성을 없애는 장치가 아니라, 위험 수준에 따라 통제 강도를 바꾸는 수단이다.

IBM이 거버넌스를 제품의 중심에 둔 이유

watsonx Orchestrate 컨트롤 플레인은 IBM이 제시한 AI 운영 모델(AI Operating Model)의 핵심 구성 요소다. IBM은 기업의 AI 도입에서 기술 역량만큼 거버넌스 인프라가 중요하다는 입장을 취한다. AI의 기능과 성능을 앞세우는 경쟁 구도에서 정책 집행과 책임 추적을 차별점으로 내세운 것이다.

이 접근은 IBM의 하이브리드 클라우드 전략과도 맞닿아 있다. 퍼블릭 클라우드와 프라이빗 클라우드, 온프레미스에 분산된 에이전트를 하나의 거버넌스 레이어에서 관리할 수 있도록 설계했다. 금융 규제나 데이터 주권 요건 때문에 온프레미스 환경을 유지해야 하는 기업에 맞는 선택지다.

IBM Sovereign Core 발표와 결합하면 국가 주권 데이터 요건을 충족하는 에이전트 운영 환경도 제공할 수 있다. 이는 정부 기관과 고도로 규제된 산업의 도입을 가속화할 것으로 전망된다.

경쟁 플랫폼과 갈리는 지점

2026년 엔터프라이즈 에이전트 플랫폼 시장에서는 IBM watsonx Orchestrate, Salesforce Agentforce, ServiceNow AI Agents가 주요 경쟁자로 거론된다.

비교 항목 IBM watsonx Orchestrate Salesforce Agentforce ServiceNow AI Agents
핵심 차별점 멀티소스 에이전트 거버넌스 CRM/영업 특화 에이전트 IT 서비스 관리 특화
에이전트 소스 벤더 무관 (오픈) Salesforce 생태계 중심 ServiceNow 플랫폼 내
거버넌스 성숙도 엔터프라이즈급 감사 추적 기본 수준 중간 수준
배포 옵션 하이브리드 클라우드 주로 클라우드 하이브리드 가능
주요 타겟 대형 엔터프라이즈·금융·정부 영업·마케팅 조직 IT·HR 부서

Salesforce와 ServiceNow는 각자 보유한 플랫폼 생태계 안에서 에이전트를 관리하는 데 초점을 맞춘다. IBM의 차별점은 여러 출처에서 만든 에이전트를 통합하는 벤더 중립적 거버넌스다. 이미 복수의 AI 벤더와 프레임워크를 사용하는 대형 기업이라면 기존 에이전트를 하나의 제품군으로 교체하기보다 상위 관리 레이어를 두는 방식이 더 현실적일 수 있다.

가시성에서 예측적 거버넌스로 확장한다

IBM이 제시하는 도입 모델은 조직의 에이전트 현황을 파악하는 단계에서 시작한다.

1단계에서는 조직 안의 모든 에이전트를 컨트롤 플레인에 등록해 인벤토리를 만든다. 이 과정에서 많은 기업은 예상보다 훨씬 많은 에이전트를 운영하고 있다는 사실을 발견한다.

2단계에서는 신원 및 접근 정책을 정의하고 감사 로깅을 시작한다. 컴플라이언스 팀과 협력해 규제 요건을 실행 가능한 정책으로 옮기는 시기다.

3단계는 에이전트 간 작업 라우팅을 최적화하고 비즈니스 규칙에 따라 적합한 에이전트를 동적으로 선택하는 단계다.

4단계에서는 에이전트의 행동 패턴을 학습해 정책 위반을 사전에 예측하고 예방하는 적응형 거버넌스 체계를 구축한다.

(1) 에이전트 가시성모든 에이전트 등록·현황 파악(2) 기본 정책 적용신원·접근·감사 로깅(3) 지능형 오케스트레이션동적 라우팅·규칙 기반 선택(4) 예측적 거버넌스행동 학습·사전 예방가시성 확보에이전트 인벤토리규제 준수GDPR·DORA·SOX운영 효율성최적 에이전트 활용리스크 최소화자율 거버넌스

각 단계는 별도의 기능 목록이라기보다 운영 성숙도의 흐름을 나타낸다. 에이전트의 존재와 권한을 알 수 있어야 정책을 적용할 수 있고, 정책과 실행 기록이 쌓여야 동적 라우팅과 사전 예방으로 범위를 넓힐 수 있다.

산업 현장에서 확인하는 활용 방향

IBM Think 2026에서는 EY, Salesforce, JPMorgan과의 협력 사례가 소개됐다. JPMorgan은 금융 서비스 환경에서 수백 개의 내부 에이전트를 단일 거버넌스 레이어로 통합하는 파일럿을 진행 중이다.

EY는 클라이언트를 대신해 세금·감사 워크플로우를 처리하는 에이전트의 감사 추적을 규제 당국에 제출 가능한 형태로 생성하는 데 활용하고 있다. 두 사례 모두 개별 에이전트의 기능보다 여러 에이전트의 활동을 통제하고 설명하는 운영 기반에 초점이 맞춰져 있다.

watsonx Orchestrate가 겨냥하는 자리는 분명하다. 여러 환경과 벤더에 흩어진 에이전트를 없애거나 한 제품으로 통일하는 대신, 그 위에 일관된 정책 집행과 감사 추적 계층을 두는 것이다. 하이브리드 클라우드를 유지하면서 수천 개의 에이전트를 운영해야 하는 대형 엔터프라이즈에서 이 컨트롤 플레인의 가치가 드러난다.

Sources

IBM watsonx멀티에이전트AI 거버넌스정책 집행감사 추적