에이전트 AI 프로젝트가 대규모로 확장할 때 발생하는 문제와 기업이 먼저 해결해야 할 것

에이전트 AI는 모든 기업에서 중요한 요소가 되고 있습니다. 기업들은 파일럿 프로젝트를 운영에 통합하고, 데모 환경은 리더십을 감동시키고, 로드맵은 자율적인 AI 워크플로우를 중심으로 다시 작성되고 있습니다.

그러나 이러한 프로젝트 중 많은 경우, 제어된 데모와 프로덕션 배포 사이에서 뭔가가 깨집니다. 프로젝트는 중단되고, 롤아웃은 몇 개월에서 몇 년으로 연장되고, 배달을 담당하는 팀은 테스트에서 완벽하게 작동하는 에이전트가 실제 세계에서 예측할 수 없는 방식으로 행동하는 이유를 설명해야 합니다.

거의 모든 경우,答案은 모델 자체가 아니라 데이터 에스테이트, 오케스트레이션 레이어, 거버넌스 프레임워크 및 대부분의 기업이 모델을 구축하기 전에 현대화하지 않은 레거시 인프라입니다. 이러한 기초가 해결되지 않는 한, 에이전트 AI는 계속해서 인상적인 데모와 실망스러운 배포를 생성할 것입니다.

POC 환경은 함정입니다

대부분의 기업은 모델을 평가합니다. 그러나 에이전트의 행동을 끝까지 평가하는 기업은 더 적습니다. 모델은 매우 정확할 수 있지만, 모델 위에 구축된 에이전트는 여전히 실패할 수 있습니다. 이는 에이전트가 도구 호출을 순차적으로 연결하고, 하나의 잘못된 단계가 잘못된 답변을 생성하며, 이는 다음 단계에서 올바른 입력으로 처리되어 하류에서 오류를 누적하기 전에誰도 알아차리지 못하기 때문입니다.

POC 환경은 이를 숨기도록 설계되었습니다. 입력은 제어되고, 범위는 狭く, 출력을 감시하는 사람이 있습니다. 이러한 조건은 프로덕션 환경에서는 존재하지 않습니다. 테스트에서 잘 작동하는 에이전트는 이제 모호한 지시를 처리하고, 권한 오류를 발생시키고, 테스트되지 않은 데이터에 대한 순차적인 결정을 내리고 있습니다. 에이전트를 구축한 팀은 모델 성능을 평가하기 위한 프레임워크가 에이전트가 올바르게 에스컬레이션되었는지, 에지 케이스를 우아하게 처리했는지, 언제 중지해야 하는지 알려주지 않는다는 것을 발견합니다.

McKinsey의 AI 2025 보고서에 따르면, 88%의 기업이 최소한 하나의 비즈니스 기능에서 AI를 사용하고 있지만, 약 3분의 1만이 이를 전사적으로 확대했습니다.採用과 확대 사이의 격차는 파일럿을 스코핑하고 평가하는 방법에서 시작됩니다. 성공적으로 확대하는 팀은 실패 모드 분석을 설계 요구 사항으로 처리합니다. 배포 전에 에이전트가 실패하는 방법과 응답하는 방법을 카탈로그화합니다. 이는 당연한 일이지만, 실제로 이를 수행하는 기업은 거의 없습니다.

쓰레기 데이터, 쓰레기 에이전트

企業들은 왜 에이전트가 프로덕션 환경에서 성능이 떨어지는지 계속 묻고 있습니다. 答案은 거의 항상 데이터로 돌아옵니다. 데이터 에스테이트는 준비가 안 된 상태였습니다. 소스는 다른 목적을 위해 다른 시기에 구축된 수십 개의 시스템에 걸쳐 분산되어 있었습니다. 비즈니스 단위 간에 정의는 일관성이 없었습니다. 의미 있는 레이어가 없었습니다. 단일 진실의 출처가 없었습니다. 오직 누군가가 우선순위를 지정하지 않았기 때문에 오래된 시스템이 충분히 작동하고 있었던 수년간의 데이터 부채가 있었습니다.

이 부채는 에이전트를 구축할 때 사라지지 않습니다. 그것은 에이전트의 작동 현실이 됩니다. 분산된 데이터 소스를 탐색하는 에이전트는 비즈니스의 일관된 그림을 추론하지 않습니다. 그것은 찾을 수 있는 모든 것을 최선을 다해 하고, 모순을 즉흥적으로 조정하고, 비즈니스를 아는 사람이 자세히 살펴보지 않는 한 설득력 있는 출력을 생성합니다. 에이전트가 고장 난 것이 아닙니다. 에이전트에게 주어진 데이터가 이미 고장 났기 때문입니다.

데이터 드리프트와 개념 드리프트는 시간이 지남에 따라 이를 더 악화시킵니다. 실제 입력 분포가 모델이 훈련된 것과 다르면, 에이전트는 오류를 발생시키지 않습니다. 그것은 계속 실행되고, 잘못된 출력을 생성하기 시작하며, 이는 확신과 규모에서 발생합니다. MLOps 또는 AIOps 파이프라인이 에이전트 오케스트레이션 레이어에 통합되지 않은 경우, 이는 처음부터 존재했던 데이터 문제로 인해 누적되는 피해를 방지할 수 있는 메커니즘이 없습니다. 런치 시점에서 수용 가능한 성능을 발휘했던 에이전트는 이제 조용히 몇 주 동안 저하되며, 이는 누구도 출력 품질을 데이터 문제와 연결하지 못합니다.

데이터 현대화와 AI 현대화는 종종 독립적으로 시퀀싱되고 별도로 자금이 지원됩니다. 그러나它们는 독립적이지 않습니다. 데이터 아키텍처가 프로젝트 시작 전에 이미 고장 났다면, 신뢰할 수 있는 에이전트를 구축할 수 없습니다. 순서가 enorm으로 중요하며, AI 레이어에서 더 빠르게 진행하기 위해 데이터 레이어를 건너뛰는 것은 기업이 가장 일반적이고 비싼 실수를犯す 것입니다.

잘못된 대시보드는 누군가에게 잘못된 숫자를 제공할 수 있습니다. 잘못된 에이전트 동작은 누군가가 알기 전에 다운스트림 프로세스를 트리거할 수 있으며, 이는 승인되지 않은 인보이스를 승인하거나, 규정 플래그를 잘못 라우팅하거나, 의도하지 않은 범위 밖으로 가격을 조정할 수 있습니다. 에이전트 시스템에는 일반 애플리케이션 모니터링의 대시보드를 재사용한 관측 가능성이 필요하지 않습니다.

통합 데이터 플랫폼의 이점

에이전트 AI 프로그램을 시작하기 전에 통합 데이터 플랫폼으로 이동한 기업은 그렇지 않은 기업보다 더 빠르게 확대하고 있습니다. 레이크하우스, 데이터 웨어하우스, 의미 모델 및 파이프라인이 모두 하나의 환경에 존재하는 경우, Microsoft Fabric 과 같이, 에이전트는 일관된 표면을 쿼리할 수 있습니다. 이는 다른 스키마, 다른 리프레시 주기 및 동일한 비즈니스 메트릭에 대한 다른 정의를 가진 시스템 사이를 에이전트가 뛰어다니는 것으로 인해 발생하는 실패 클래스를 제거합니다.

이것이 에이전트 AI 결과에 대해 데이터統一을 위한 플랫폼을 선택하는 것이 इतन 중요합니다. Microsoft Fabric의統一적인 접근 방식은 레이크하우스, 데이터 웨어하우스, 의미 모델 및 파이프라인을 하나의 환경에 통합하여, Microsoft (MSFT ) 중심의 기업이 실험에서 실제 운영으로 이동할 때 구조적인 이점을 제공합니다.

Databricks는 레이크하우스 아키텍처와 Unity Catalog를 통해 동일한 원리를 제공하며, 데이터 및 AI 팀에게 구조화된 데이터와 비구조화된 데이터에 대한統一적인 거버넌스 레이어를 제공하며, MLflow 통합을 통해 프로덕션에서 모델 동작을 추적할 수 있습니다. Snowflake의 접근 방식은 데이터 클라우드와 AI 추론 사이의 긴밀한 결합을 利用하여, 기업이 에이전트 워크로드를 직 接적으로 관리되는 라이브 데이터에 대해 실행할 수 있도록 합니다.

각각의 플랫폼은 동일한 결과에 대한 다른 경로를 나타냅니다. 에이전트의 의사 결정에 대규모로 지원할 수 있는 일관된, 관측 가능하며 신뢰할 수 있는 데이터 레이어입니다. 올바른 선택은 기업의 기존 스택에 따라 다릅니다. 선택이 필수는 아니지만, 에이전트 레이어를 구축하기 전에 그것에 대한 결정을 내리고 그것에 대한 헌신을 하는 것이 중요합니다. 진행 중인 팀과 아직 파일럿에 갇힌 팀을 구분하는 것은 선택한 플랫폼이 아니라, 데이터 레이어를 먼저 수정했는지 여부입니다.

배포 전 거버넌스

事後에 구축된 거버넌스는 거버넌스가 아닙니다. 에이전트가 다운스트림 의사 결정 권한을 가지고, 6개월 후에 가드레일을 추가하면, 기업은 이미 6개월간의 비감사 의사 결정이 축적되었습니다. 감사 트레일은 에이전트가 라이브되기 전에 설계되어야 합니다. 事後에 재구성되어서는 안 됩니다.

同じ 원칙이 AI 보안, 역할 기반 액세스 제어 및 권한 범위 지정에도 적용됩니다. 올바르게 범위가 지정되지 않은 에이전트는 접근해서는 안 되는 데이터에 접근할 수 있거나, 의도하지 않은 범위 밖에서 동작을 실행하거나, 공격 표면이 될 수 있습니다. 이러한 위험은 개발 단계에서 해결되어야 하며, 배포 검토 시점에 발견되어서는 안 됩니다.

거버넌스가 훈련 파이프라인을 구축하기 전에 포함되지 않으면, 잘못된 또는 적대적인 데이터가 훈련 프로세스에 들어올 수 있습니다. 잘못된 데이터에 훈련된 모델은 벤치마크에서 잘 작동하지만, 프로덕션에서漂います. 이는 에이전트의 의사 결정이 실제 비즈니스 결과를 초래하는 경우에 특히 위험한 조용한 실패의 유형입니다.

EU AI 법 및 AI 책임성에 대한 성장하는 규제 프레임워크는 이를 무시하기 더 어려워지고 있으며, 거버넌스를 에이전트 아키텍처에 구축하지 않은 기업은 이미 상당한 규제 비용을 축적하고 있습니다.

파일럿에서 프로덕션으로: 실제로 필요한 것

프로덕션 갭을 메우는 기업은 데이터 레이어를 수정하기 전에 에이전트 레이어를 구축하지 않는 기업입니다. 그들은 설계에 거버넌스를 포함시키며, 이미 손상을 입힌 후에가 아니라, 오케스트레이션 아키텍처에 관측 가능성을 구축하고, 기술적인 배달과 병렬로 변경 관리를 수행합니다. 그들은 실패 모드 분석을 중요한 설계 요구 사항으로 처리합니다.

Deloitte의 기업 AI 연구에 따르면, 2025년만에 AI에 대한 근로자의 접근이 50% 증가했으며, 40% 이상의 AI 프로젝트를 전면 프로덕션으로 실행하는 기업의 비중은 향후 6개월 내에 두 배로 증가할 예정입니다. 현재 승리하는 기업은 가장 발전된 모델을 보유한 것이 아닙니다. 그들은 에이전트를 구축하기 전에 신뢰할 수 있는 운영 인프라를 구축했습니다.

まだ 파일럿만 실행하고 있는 모든 기업은 모델과 인터페이스에 대한 투자가 데이터 준비도 및 거버넌스 아키텍처에 대한 투자와 비례하는지 확인해야 합니다. 이것이 많은 기업이 부족한 부분입니다.

이것이 변경되지 않는 한, 많은 에이전트 AI 프로젝트는 회사에서 자원을 투입하고, 결실을 맺기를หว