아키텍처가 그래비티를 거스를 때 증가하는 운영 부담

핵심 요약 읽기(6분)

- - - 스토리지 내장형 스택은 데이터가 네임스페이스로 전송된다고 가정합니다. 엔터프라이즈 자산에 작용하는 요인은 그렇지 않으리라고 주장합니다.
    - “통합 네임스페이스” 가치 제안은 데이터가 세 가지 형태라는 가정에 배치됩니다.
    - 아키텍처로 인해 발생하는 부담은 파이프라인 소유권, 불일치 조정 비용, 스키마 결합, 거버넌스 이중 관리, 비용 불투명성 등과 같이 구조적입니다.
    - 외부 요인(규제, 애플리케이션 결합, 계약, 소유권)으로 인해 일시적이 아닌 영구적인 부담이 발생합니다.
    - 통합 컨트롤 플레인은 데이터가 존재하는 위치에서 작동하며, 데이터 이동이 반드시 필요한 경우에만 데이터를 옮깁니다.

AI 데이터 플랫폼을 평가할 때 견적에 표시된 항목만 비용으로 고려해서는 안 됩니다. 실질적인 비용은 구축해야 하는 파이프라인, 파이프라인을 유지하기 위해 고용하는 인력, 사용을 위해 데이터를 이동해야 할 때마다 포기하는 선택 사항 등을 통해 나중에야 드러납니다.

데이터 이동에는 부담이 발생하고, 실제 엔터프라이즈 자산은 데이터를 제자리에 유지하는 데 따르는 왜곡으로 가득 차 있습니다. 또한 “데이터” 자체는 하나의 실체가 아니라 특성과 요구 사항이 제각각인 세 가지 형태(데이터, 메타데이터 및 벡터)를 가집니다. 이 게시물은 아키텍처가 이러한 법칙이 적용되지 않는 듯 가장할 때 어떤 일이 발생하는지를 설명합니다.

모든 스토리지 내장형 스택의 아키텍처 가정

VAST AI OS가 가장 눈길을 끄는 예시인 스토리지 내장형 AI 스택은 AI 서비스가 이미 플랫폼에 저장되어 있는 데이터를 기반으로 실행된다는 단일 아키텍처 가정을 기반으로 구축됩니다. 데이터는 플랫폼 내에 있어야 하며, 플랫폼의 관점에서 네임스페이스 외부의 모든 것은 보이지 않습니다.^1,4

따라서 플랫폼에는 데이터를 가져올 수 있는 툴이 함께 제공됩니다. 여기에는 데이터를 중앙 집중화하면 운영이 단순해진다는 스토리도 따라옵니다. 데모에서는 통합 UI가 사용되어 전체 자산이 하나의 통일성 있는 구조로 보입니다.

이러한 일관성은 내부에 국한됩니다. 또한 실제 엔터프라이즈 자산에 작용하는 구조적 작용을 무시한 가정이기도 합니다.

방대한 데이터를 이동할 필요가 없음을 나타내는 세 가지 형태

기업이 “데이터”라고 부르는 대상은 사실 세 가지의 서로 다른 요소로 구성되어 있습니다.

- 데이터는 무겁습니다. 저장된 위치에 그대로 두는 것이 일반적이며 파일, 레코드, 이미지, 비디오, 텔레메트리, 규격화된 테이블을 예로 들 수 있습니다.
- 메타데이터는 가볍습니다. 저렴한 비용으로 전파가 가능합니다. 모든 AI가 어디서나 모든 자산을 확인할 수 있게 됩니다.
- 벡터는 인접성(locality)에 민감합니다. 데이터 자체를 이동하지 않고도 자산 전체에 의미를 전달할 수 있습니다.

이러한 세 가지 형태를 모두 동일한 실체로 취급하는 아키텍처는 기본적으로 모든 것을 이동시킨다는 잘못된 답을 제공합니다. 반면, 이 세 가지 형태를 구분하는 아키텍처에서는 대용량 데이터를 해당 데이터가 위치한 곳에서 관리하고, 자산 전체에 메타데이터를 전파하며, 벡터가 실제로 AI에 필요한 환경 간 추론을 수행할 수 있습니다.

인식하는 유일한 형태가 데이터뿐이라면 일관되게 통합 네임스페이스에서 답을 찾을 것입니다. 하지만 메타데이터와 벡터를 중요한 요소로 받아들이는 순간 이는 오답이 됩니다.

자산을 안으로 끌어들이는 아키텍처에서 발생하는 부담

AI가 데이터를 다루기 전에 데이터를 결집해야 한다는 가정 아래 아키텍처를 구축하면 기업의 모든 외부 요인이 운영상의 부담으로 변합니다.

- 파이프라인 소유권. Snowflake, SharePoint, S3, Kafka, 타사 스토리지, SaaS를 비롯한 모든 소스는 동기화 작업이 필요합니다.¹ 모든 동기화 작업에 인력이 동원되어야 합니다.
- 불일치 조정 비용. 모든 복제본에서 소스와의 편차가 발생합니다. 소스 필드 길이가 변경되었으나 이 사실이 알려지지 않으면 스키마가 변경되고, 지역별 레이턴시가 급증하며, 자동으로 잘리고 맙니다. 누군가는 이를 계속해서 탐지하고 수정해야 합니다.
- 스키마 결합. 소스 시스템이 변경되면 다운스트림 복제본이 중단되고 이에 따라 AI 서비스가 중단됩니다.
- 거버넌스 이중 관리. 소스와 복제본에서 모두 액세스 제어, 보존 정책, 규정 유지 및 감사 추적이 유지되어야 합니다.
- 비용 불투명성. 귀사의 FinOps 팀은 통합 형태로 판매된 아키텍처 전반에서 데이터 이동, 스토리지 중복 및 전송을 추적하고 있습니다.

그 어떤 것도 악의적으로 숨겨진 것이 아니라 구조적으로 발생한 문제입니다. 폐쇄형 스토리지 내장형 모델이 개방형 분산 데이터 자산을 만나 자산을 내부로 가져오려고 할 때 발생하는 현상입니다.^1,4

여기서 공급업체 언어가 중요합니다. “동기화 엔진 무료”와 “동기화 무료”는 동일한 문장이 아닙니다. 동기화 작업은 일회성 마이그레이션이 아닙니다. 스키마 변경, 네트워크 이벤트, 사용 권한 변경, 보존 정책, 규정 유지 및 간헐적 운영 중단 등 영구적으로 일관성을 유지해야 하는 두 시스템 간의 영구적인 관계입니다.⁴ AI 워크로드가 처리하는 모든 소스 시스템에 이를 곱하면 아키텍처가 간소화되지 않습니다. 새로운, 공급업체 고유의 복제본 플레인이 그 아래에 추가되었습니다.¹

외부 요인으로 인한 영구적 부담 발생

이 부담이 시간이 지나도 사라지지 않는 이유는, 이러한 부담을 발생시키는 요인이 일시적이지 않기 때문입니다. 기업의 구조적 특징에서 비롯됩니다.

- 규제 및 주권 제약. GDPR, HIPAA, 데이터 레지던시 법률, 수출 통제. 일부 데이터는 상주하는 위치에서 처리되어야 합니다. 주권 경계를 넘어서는 동기화 작업에서는 규정 준수 인시던트가 발생하게 됩니다.
- 애플리케이션 요구 사항. ERP, CRM, EHR 및 트랜잭션 시스템과 같은 정보 소스 애플리케이션은 소유자와 결합됩니다. 공급업체 네임스페이스에 데이터를 공급하도록 설계된 것이 아닙니다. 비즈니스를 운영하기 위해 설계되었습니다.
- 계약상의 마찰. 하이퍼스케일러 전송 수수료와 독점 형식은 데이터를 그대로 두는 것보다 추출하는 데 더 많은 비용이 듭니다. 데이터를 가져와 다른 곳에 배치하면서 발생하는 비용은 결국 CFO의 눈에 들어오게 됩니다.
- 조직 역학. 동일한 데이터를 주장하는 두 사업부, 갑작스럽게 유입된 피인수 회사의 자산, 거버넌스를 공유하지 않는 관리 책임자 등으로 인해 조직도는 이상적인 아키텍처를 반복적으로 무력화합니다.
- 알 수 없거나 카탈로그화되지 않은 데이터. 존재하는 것을 알지만 카탈로그화할 수 없는 데이터가 있습니다. 찾을 수 없는 데이터는 동기화할 수도 없습니다. 동기화할 수 없는 데이터는 AI도 볼 수 없으며, 적어도 스토리지 내장형 모델에서는 그렇습니다.

이러한 모든 요인은 실제 엔터프라이즈 환경에서 영구적으로 존재하는 특성입니다. 이 요인들이 사라질 것이라는 전제를 기반으로 한 아키텍처는 비용을 끝없이 치르게 될 것입니다.

대안: 페더레이션

Dell AI Data Platform은 매우 다른 전제를 기반으로 구축되었습니다. 고객이 데이터를 사용하기 전에 공급업체가 제어하는 네임스페이스에 데이터를 복사하도록 요청하는 대신, Dell은 페더레이션 방식을 활용합니다. 실제로는 PowerScale, ObjectScale, 타사 스토리지, 웨어하우스, SaaS 및 퍼블릭 클라우드에 상주하는 데이터에서 작동하고 데이터가 이동할 때만 데이터를 이동하는 컨트롤 플레인이 정답입니다.^4,5

이러한 단일 설계 결정은 세 가지 형태의 프레이밍을 그대로 적용한 결과입니다.

- 데이터는 저장된 곳에 유지되고 기존에 해당 데이터를 관리하는 팀이 관리합니다.
- 메타데이터는 어디에나 전파되므로 어떤 AI를 선택하더라도 위치와 무관하게 모든 자산을 볼 수 있습니다.
- 벡터는 자산 전체에 의미를 전달하므로 AI는 데이터를 재배치하지 않고도 데이터를 추론할 수 있습니다.

페더레이션 아키텍처가 데이터를 전혀 옮기지 않는다는 의미는 아닙니다. 이동하는 것이 합리적일 때는 그렇게 합니다. 하지만 데이터 이동을 플랫폼에서 가치를 얻기 위한 전제 조건으로 삼지는 않습니다. 그리고 이러한 단일 아키텍처 선택은 위에서 설명한 운영상의 부담을 대부분 없앱니다. AI가 데이터를 처리하기 전에 데이터를 재배치해야 한다는 가정하에 아키텍처를 구축한 경우에만 부담이 발생하기 때문입니다.⁴

또한 CFO가 가장 중요하게 생각하는 선택권을 유지합니다. 통합 컨트롤 플레인은 공급업체의 네임스페이스 내부에 데이터 자산을 묶어두지 않습니다. 이미 위치하고 있던 곳에 자산을 유지하고 이미 관리하고 있던 팀이 자산을 관리하므로 AI가 유용하게 사용할 수 있습니다.^2,4

외부 분석가들은 이러한 역학 관계를 점점 더 강조하고 있습니다. 최근 한 기사에서는 개방형 표준에 대한 VAST의 지원에도 불구하고 “통합 아키텍처에서 종속성이 발생할 수 있으며 이로 인해 향후 마이그레이션이 어려워질 수 있다”고 언급했습니다. 데이터를 더 많이 동기화할수록 유지하기 어렵다는 것을 완곡하게 표현한 것입니다.² 또 다른 관측에 따르면 VAST의 접근 방식은 “하이퍼컨버지드 인프라스트럭처 모델과 더 유사하며, VAST가 전체 경험을 제어하는 긴밀하게 통합된 독자적인 스택을 제공합니다.”³ HCI는 해당 모델이 대규모로 이기종을 충족하면 어떤 일이 발생하는지 업계에 알려주었습니다. 여기에도 같은 교훈이 적용됩니다.

최종 결정에 앞서 물어야 할 세 가지 질문

이러한 내용은 그대로 RFP에 반영됩니다.

1. 안정적인 상태에서 네임스페이스로 몇 개의 파이프라인을 실행할 예정입니까? 그린필드 중심으로 구축된 레퍼런스 아키텍처가 아닌 유사한 데이터 자산을 기반으로 현실적인 추정치를 요청하십시오. 이를 규제 및 애플리케이션 연계 자산과 비교하여 매핑합니다.
2. 소스 시스템이 변경되면 조정의 책임은 누구에게 있습니까? 귀사의 툴을 사용하되 상대 팀에 책임을 묻는다면, 결국 귀사의 운영 비용이 됩니다. 비용을 매겨야 합니다.
3. 3년 차에 소스 동기화를 중지하고 싶다면 어떻게 해야 합니까? 답은 얼마나 많은 선택권을 포기하게 되는지, 그리고 탈출 과정에서 아키텍처가 얼마나 큰 마찰을 빚는지에 달려 있습니다.

짧게 정리하자면, 구매 사실을 누구도 말해주지 않았던 기반 비용에 돈을 쓰지 마십시오.

다음으로 알아볼 사항

다음 게시물에서는 데이터 센터 현장을 다시 살펴보겠습니다. 아키텍처 부담의 결과가 FTE 문제에 그치지 않기 때문입니다. GPU의 경제성과도 관련된 문제입니다. 컴퓨팅을 실행하기 전에 데이터가 먼저 모여야 하는 구조라면 AI 인프라스트럭처에서 가장 비용이 많이 드는 항목은 결국 비용을 지출하는 그 구조입니다.

¹ VAST 데이터, “DataSpace and SyncEngine” 제품 설명서.

² DataPro.news, “VAST Data: Revolutionary AI OS or Silicon Valley Hyperbole?” 2025년 6월.

³ NAND 연구, “How to Think about VAST Data,” 2026년 2월.

⁴ Dell Technologies의 의뢰로 작성된 Prowess Consulting의 “Architectural and Operational Comparison: Dell AI Data Platform vs. VAST AI OS”, 2026년 4월.

⁵ Dell Technologies, “Dell AI Data Platform with NVIDIA, 획기적인 데이터 오케스트레이션과 스토리지 혁신으로 엔터프라이즈 AI 강화”, PR Newswire, 2026년 3월.