지난 1년 동안 기업 AI 생태계에는 막대한 역량이 추가됐지만 합의는 전혀 이뤄지지 않았다.

이제 개발자는 다양한 툴셋을 사용해 AI 에이전트를 구축할 수 있다. 오픈AI 프레임워크, 앤트로픽 클로드(Claude) 툴, 랭체인(LangChain), 랭그래프(LangGraph), 크루AI(CrewAI), 마이크로소프트 오토젠(AutoGen)도 있고 그 외의 여러 대안도 계속 늘어나는 중이다. 각 툴은 저마다 추론 루프를 조율하고 다단계 작업 실행을 관리하고 에이전트를 툴과 API에 연결한다고 주장한다. 실험 측면에서는 상당한 진전이 이뤄졌다. 2년 전만 해도 몇 달이 걸렸을 복잡한 에이전트 워크플로우를 이제 며칠 만에 구성할 수 있다.

그러나 이 패턴을 과거에도 본 적이 있다. 20년 넘게 분산 시스템 플랫폼을 구축하고 판매해오면서 겪은 거의 모든 주요 인프라 변화마다 동일한 현상이 나타났다. 즉, 새로운 역량이 등장하면 그 역량을 거버넌스하기 위한 인프라보다 소비하기 위한 툴이 먼저 나온다는 점이다. 그 간극은 개발 환경에서는 눈에 잘 띄지 않다가 프로덕션에서 명확하게 드러난다.

현재 기업 AI가 처한 상황이 바로 그렇다.

에이전트 프레임워크가 못하는 일

현대 에이전트 프레임워크는 근본적으로 조율 시스템이다. 시스템이 무엇을 해야 하는지, 어떤 툴을 호출하고 어떤 순서로 작업을 처리하고 에이전트 간에 어떻게 작업을 위임할지를 결정한다. 어려운 작업이지만 이제 꽤 잘 처리할 만큼 발전했다.

그러나 에이전트 프레임워크는 이런 작업을 어디서, 어떤 조건 하에서 실행할 수 있는지에 대해서는 거의 다루지 않는다.

얼핏 단순해 보이는 워크플로우로, LLM을 사용해 고객 지원 통화 녹취록을 요약하는 경우를 예로 들어보자. 개발 환경에서의 구현은 명료하다. 에이전트가 모델 API를 호출하고 녹취록을 전달하고 요약을 반환한다. 그러나 동일한 요청이 엔터프라이즈 프로덕션 환경에서 이뤄지는 경우에는 특정 지리적 경계를 넘을 수 없는 데이터세트, 규제 대상 데이터 용도로 승인되지 않은 모델, 그리고 발생한 일에 대한 추적 가능한 기록을 요구하는 감사 요구사항 등 상황이 훨씬 더 복잡해진다.

에이전트 프레임워크는 ‘계획’ 문제를 해결하도록 설계되는데, 위와 같은 문제는 계획 문제가 아니라 실행 거버넌스의 문제다. 대다수 프레임워크는 이런 거버넌스가 스택의 다른 부분에서 처리될 것이라고 전제하지만, 많은 엔터프라이즈 환경에서 거버넌스는 전혀 처리되지 않는다. 가트너는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 중도에 취소될 것으로 전망하면서 불충분한 위험 통제를 실패의 주 원인으로 지목했다. 이 수치가 바로 간극을 정확히 보여준다.

누락된 계층이 하는 일

이런 거버넌스 문제를 해결하기 위해서는 에이전트 로직과 실행 사이에 부가적인 계층이 필요하다. 이 계층은 데이터가 어디에 위치할 수 있는지, 어느 모델이 이 데이터를 처리할 수 있는지, 누가 요청을 승인했는지, 그리고 그 작업이 기업 컨텍스트에 어떻게 부합하는지를 규정하는 정책을 기준으로 모든 에이전트 작업을 평가한다. 에이전트 프레임워크는 시스템이 해야 할 일이 무엇인지를 결정하고, 오케스트레이션 계층은 그 작업이 허용되는지 여부와 어디서 실행해야 하는지를 결정한다. 이렇게 책임을 분리하면 두 계층이 각기 독립적으로 발전할 수 있다. 또한 거버넌스 모델을 처음부터 다시 구축하지 않고도 새 에이전트 프레임워크를 도입할 수 있게 된다.

쿠버네티스 시대를 거쳐온 사람이라면 누구나 이 분리가 익숙하게 느껴질 것이다. 쿠버네티스는 컨테이너 안에 무엇이 들어있는지에 대해서는 관심이 없고 그저 용량을 찾고 리소스를 할당하고 작업이 실행되도록 하는 데 집중한다. 에이전틱 AI를 위한 오케스트레이션 계층의 역할도 비슷하다. 어느 에이전트 프레임워크가 요청을 생성했는지에는 관심이 없고 그 요청을 실행할 수 있는 조건을 강제한다.

더 풍부한 권한 부여 모델

전통적인 기업 액세스 제어는 ‘사용자 X가 리소스 Y에 액세스할 수 있는가?’라는 단순한 질문을 중심으로 구축된다. 자율 에이전트에는 이것으로 부족하다.

에이전트 요청에 대한 실제 권한 부여 결정은 다음과 비슷한 형태로 이뤄진다.

request = {    "agent": "support-summary-agent",    "task": "summarize",    "dataset": "customer_support_logs",    "model": "external_llm_api",    "delegated_by": "user_4821"}policy = evaluate_policy(request)if policy.allowed:    route_to_execution(policy.execution_environment)else:    raise AuthorizationError(policy.reason)

여기서 정책 엔진은 데이터세트 분류, 모델 승인 상태, 지리적 처리 규칙, 그리고 요청을 시작한 위임 체인을 평가한다. 이렇게 해서 작업을 공개 API 엔드포인트가 아닌 내부 추론 클러스터로 리디렉션하거나, 조건에 부합하는 실행 환경이 없는 경우 요청을 차단하게 된다. 에이전트 관점에서 작업은 여전히 실행된다. 오케스트레이션 계층은 그 작업이 기업 정책을 충족하는 환경에서 실행되도록 보장한다.

온톨로지가 전체 구조를 떠받치는 인프라인 이유

오케스트레이션 계층이 올바른 의사결정을 내리기 위해서는 데이터 라벨링 이상의 일을 해야 한다. 요청에 포함된 여러 엔티티가 서로 어떻게 연관되는지 이해하고, 그러한 관계를 바탕으로 추론해 허용 여부를 결정해야 한다.

고객 지원 녹취록 예시를 다시 생각해 보자. 메타데이터는 데이터세트에 PII(개인 식별 정보)가 포함돼 있음을 알려준다. 온톨로지는 시스템이 연결된 체인 전반에 걸쳐(개인 정보가 포함하는 데이터세트를 사용해 작업이 실행되고, 그 데이터는 GDPR의 규제를 받으며, 기업의 정책에 따라 승인된 EU 환경 내에서 데이터를 처리해야 하고, 선택된 모델은 그 경계 밖에서 실행됨) 추론할 수 있도록 한다. 오케스트레이션 계층은 연결된 이 4개의 사실을 통해 요청을 다시 라우팅하거나 차단해야 함을 추론할 수 있다. 여기서 시스템은 특정 데이터세트에 묶인 하드코딩된 규칙과 대조하는 것이 아니라 관계를 바탕으로 추론했다.

이를 통해 정책 집행, 실행 라우팅, 데이터 지역성, 감사 결정을 런타임에 계산할 수 있게 된다. 온톨로지는 기업에서 거버넌스가 필요한 거의 모든 엔티티-관계 집합, 즉 데이터세트, 모델, 에이전트, 사용자, 규제, 작업, 환경을 중심으로 구축이 가능하다. 중요한 관계는 거버넌스 계층이 내려야 하는 결정을 이끄는 관계다. 액세스 제어 목록은 리소스를 이용할 수 있는 사람을 제한할 수 있지만 연결된 엔티티 세트 전반에 걸쳐 추론할 수는 없다. 오케스트레이션 계층은 바로 이 추론에 의존한다.

의사결정 이력 추적을 핵심 요구사항으로

기업 시스템에는 감사 가능성도 필요하다. 자동화된 에이전트가 여러 시스템에 걸친 작업을 트리거한다면 기업은 그 결과까지 이어진 의사결정 경로를 재구성할 수 있어야 한다. 규정 준수뿐만 아니라 사고 대응과 기본적인 운영상의 신뢰 역시 이 기능에 의존한다.

오케스트레이션 계층은 요청을 시작한 주체, 에이전트, 모델, 데이터 소스, 권한 부여 과정에서 평가된 정책, 그리고 그 외에 기업이 온톨로지에 캡처하기로 한 거의 모든 정보를 설명하는 레코드를 생성한다. 이 관리 체인은 프로덕션 AI 시스템을 블랙박스처럼 다루지 않고도 사고를 조사하고 규정 준수 여부를 검증할 수 있게 해준다.

규제 및 감사 기관은 더 이상 AI 시스템이 무엇을 하도록 설계됐는지 아는 것만으로는 만족하지 않는다. 이들은 특정 상황에서 시스템이 무엇을, 어떤 권한에 따라 수행했고 그로 인해 어떤 결과가 나타났는지에 대한 사실 관계 기록을 원한다. 대시보드로는 이 기록을 제공할 수 없지만 잘 설계된 오케스트레이션 계층은 할 수 있다. EU AI 법 12조와 17조에는 ‘고위험 AI 시스템은 의사결정을 추적하고 감사할 수 있게 해주는 문서를 유지해야 하며 사후 조사를 지원하기에 충분한 기록을 보존해야 한다’는 점이 명시돼 있다.

기업은 어떻게 대처해야 하는가

에이전트 프레임워크는 계속 개선되는 중이다. 이 프레임워크가 해결하는 조율 문제는 실질적인 문제이며 관련 생태계도 계속 성숙해질 것이다. 그러나 기업이 풀어야 하는 아키텍처 측면의 과제는 바뀌었다. 핵심은 더 이상 에이전트 조율이 아니라, 이런 에이전트가 실제 인프라, 실제 데이터, 실제 규정 준수 의무와 어떻게 상호작용하는지를 거버넌스하는 데 있다.

이때 필요한 패턴은 이미 존재한다. 바로 컨텍스트 기반 권한 부여, 데이터 지역성 강제, 온톨로지 인지 정책 평가, 의사결정 이력 추적이다. 대다수 기업에서 부족한 것은 이런 역량이 별도의 계층에 속하며 이 계층은 그 위에 놓이는 에이전트 프레임워크로부터 독립적으로 움직인다는 인식이다. 이 계층을 구축하면 나머지는 관리 가능한 문제가 된다.
dl-itworldkorea@foundryco.com