The Holy Trinity: AI가 실제로 일하려면 무엇이 필요한가

어느 제조 기업이 자사의 SKU 14,000개 중 실제로 수익을 내는 것이 무엇인지 알고 싶어 합니다. 그 답은 단 하나의 데이터 포인트도 서로 주고받은 적이 없는 세 개의 시스템에 흩어져 있습니다. 얼마 전까지만 해도 그 답을 얻는 데는 세 개 부서와 2주, 그리고 상당한 선의가 필요했습니다. 2026년 초부터는 AI가 이 질문에 몇 분 안에 답할 수 있습니다. 데이터를 뒤지고, 연관 관계를 만들고, 권고안을 내놓는 것입니다. 단, AI가 접근할 수 있다는 전제에서입니다.

모델은 이미 그 단계에 도달했습니다. 스스로 행동하고, 여러 단계와 시스템 경계를 넘어 과제를 수행하고, 의사 결정을 준비하고, 워크플로를 촉발합니다. 많은 기업이 Copilot을 통해 이미 그 첫인상을 얻었지만, Copilot이 아는 것은 M365 우주입니다. 메일, 문서, 캘린더 말입니다. 실제 비즈니스를 떠받치는 데이터, 즉 ERP와 CRM, IoT와 생산 시스템에 AI를 투입하려면 다른 기반이 필요합니다.

이 기반은 세 부분으로 이루어집니다. 저희는 그 각각을 Managed Service로 구축했고, 각 부분은 3~4주 안에 운영에 들어가며, 세 가지가 합쳐져 AI가 실제로 일을 해낼 수 있는 플랫폼을 이룹니다.

첫째: 질의할 가치가 있는 데이터

다시 14,000개의 SKU로 돌아가 봅시다. 생산 데이터는 ERP에, 판매 수치는 CRM에 들어 있고, 그 사이 어딘가에서는 한 사람이 표 하나를 관리하는데 그것이 우연히도 비즈니스에 결정적인 KPI의 유일한 출처입니다. 이는 예외적인 사례가 아닙니다. 이것이 일반적인 상황입니다. 그리고 이 데이터가 분리된 시스템에 남아 있는 한, AI는 비즈니스를 일관되게 바라볼 수 없습니다.

레이크하우스 아키텍처는 이를 세 개의 계층으로 해결합니다. 원천 시스템에서 온 원시 데이터(Bronze), 큐레이션되고 검증된 데이터셋(Silver), 그리고 분석 또는 AI 파이프라인으로 곧바로 흘러드는 비즈니스 집계 데이터(Gold)입니다. 이것이 Databricks에서 돌아가는지 Fabric에서 돌아가는지는 요구 사항에 따라 달라집니다. 둘 다 작동합니다. 둘을 섞은 하이브리드도 마찬가지입니다.

Azure Data Foundation이 이를 위한 저희의 Managed Service입니다. ERP, CRM, IoT 및 그 외 원천 시스템의 데이터를 하나의 플랫폼으로 통합하며, 전체가 Infrastructure as Code로 정의되고, 자동 드리프트 감지와 Unity Catalog 또는 Purview를 통한 일관된 데이터 거버넌스, 그리고 비즈니스 사용자와 분석가, 데이터 엔지니어에게 동일하게 적용되는 역할 기반 접근 권한을 갖추고 있습니다. 실질적인 결과는 이렇습니다. 이 기반을 갖춘 기업은 이전에는 답할 수 없었던 질문을 처음으로 던질 수 있게 됩니다. 원하지 않았기 때문이 아니라, 데이터는 있었지만 한 번도 연결된 적이 없었기 때문입니다.

둘째: 워크로드가 실제로 돌아가는 장소

데이터를 갖추는 것은 하나의 일입니다. 일회성 질의를 넘어서는 무언가를 그 데이터로 해내는 것은 또 다른 일입니다. AI 애플리케이션, 자동화된 비즈니스 로직, 장시간 실행되는 작업, 즉 기업 데이터에 자율적으로 반복 접근하는 모든 것에는 통제할 수 있는 런타임 환경이 필요합니다. 이 환경은 그렇게 계획했든 아니든 컨테이너로 이루어집니다.

Azure Container Foundation이 그 틀을 제공합니다. 워크로드에 따라 Azure Container Apps 또는 Azure Kubernetes Service를 기반으로 하는 표준화된 컨테이너 플랫폼입니다. 통일된 네트워크 접근, Managed Identity를 통한 Entra ID 중앙 인증, 일관된 모니터링을 갖추고 있습니다. 모든 것이 Terraform과 GitHub로 관리되며, 모든 것이 재현 가능합니다.

이것이 가능하게 하는 일은 이렇습니다. 각 팀이 자체 클러스터를 세우고 자체 규칙을 정의하는 대신, 워크로드가 돌아가기만 하는 것이 아니라 통제 가능한 상태로 유지되는 공통의 틀이 생깁니다. 이것이 워크로드에 자율성을 부여하기 위한 전제 조건입니다.

셋째: 모델이 에이전트가 되는 장소

모델은 아직 에이전트가 아닙니다. 언어 모델과, 주문을 안정적으로 접수하거나 청구서를 검토하거나 서비스 건을 에스컬레이션하는 무언가 사이에는 화려하지 않은 작업이 많이 놓여 있습니다. 어떤 모델을 쓸지, 어떤 도구와 어떤 데이터 소스를 쓸지, 어떤 가드레일을 둘지, 그리고 에이전트가 틀렸을 때 무슨 일이 일어나는지 말입니다. 이 작업은 어딘가에서 이루어져야 하며, 추적 가능하고 반복 가능해야 하고, 한 사람의 랩톱에 놓인 노트북 안에서 이루어져서는 안 됩니다.

Azure AI Foundation이 이 계층을 위한 저희의 Managed Service이며, Microsoft Foundry(구 Azure AI Foundry) 위에 올려집니다. 모델 카탈로그, 에이전트 오케스트레이션, 도구 및 데이터 소스 연결, 평가와 옵저버빌리티가 한곳에 모여 있습니다. 이곳에서 만들어진 에이전트는 나머지 환경과 동일한 Entra 신원을 통해 데이터와 워크로드에 접근하고, 정의된 가드레일 안에서 돌아가며, 검증할 수 있는 흔적을 남깁니다.

저희는 이를 코드로 정의된 형태로, 역할 기반 접근 권한과 콘텐츠 필터, 그리고 논의의 대상이 되지 않는 네트워크 경계와 함께 제공하며, 누군가 손으로 나사를 돌리지 않고도 에이전트를 개발에서 운영으로 옮기는 배포 경로도 함께 제공합니다. 이것이 갖춰져야 비로소 에이전트는 프로토타입이기를 그치고, 기업이 실제로 운영할 수 있는 무언가가 됩니다.

The Holy Trinity

세 개의 구성 요소, 각각 3~4주 안에 운영에 들어가고, 각각 단독으로도 투입할 수 있으며, 합치면 기업에서 실제로 가치가 생겨나는 지점에 AI가 도달하는 플랫폼이 됩니다.

Azure Data Foundation은 비즈니스를 설명하는 데이터에 AI가 접근할 수 있게 합니다. Azure Container Foundation은 그 워크로드가 지속적으로, 통제된 상태로 돌아갈 수 있는 장소를 제공합니다. 그리고 AI Foundation은 이 데이터와 이 워크로드로부터 구축하고 검증하고 운영할 수 있는 에이전트가 만들어지는 장소입니다.

세 가지를 모두 합치면, AI가 요약하기를 그치고 일하기를 시작하는 토대가 생깁니다.