제로 카피: ETL의 종말과 AI의 미래

이것이 AI 붐의 더러운 비밀입니다. 모델은 훌륭하지만 배관은 오래되었습니다.

최첨단 변압기 모델을 구축합니다. H100 GPU 클러스터를 보호합니다. 그러나 모델이 실제로 새 판매 데이터를 볼 수 있도록 ETL(추출, 변환, 로드) 파이프라인이 실행될 때까지 24시간을 기다립니다. 추론이 실행될 때 고객은 이미 이탈했습니다.

이것이 바로 “데이터 마찰세”이며 AI ROI를 죽이고 있습니다.

2025년, 업계는 마침내 배관을 수리합니다. 엔지니어링 팀은 데이터 웨어하우징 시대에서 통합 데이터 플랫폼, 특히 “제로 복사(Zero-Copy)” 철학을 기반으로 구축된 아키텍처 시대로 이동하고 있습니다. AI 시스템을 구축하는 경우 데이터 복사가 아키텍처의 안티 패턴이 되는 이유를 이해해야 합니다.

문제의 물리학: ETL의 확장성이 떨어지는 이유

Zero-Copy가 중요한 이유를 이해하려면 기존 스택의 비효율성을 살펴봐야 합니다.

표준 기업에서 데이터는 CRM용 Salesforce, ERP용 SAP, 로그용 AWS S3 등 “중력 우물”에 효과적으로 존재합니다. 이 데이터를 분석하기 위해 엔지니어들은 역사적으로 소스 A에서 대상 B(일반적으로 Redshift 또는 Snowflake와 같은 데이터 웨어하우스)로 데이터를 물리적으로 복사하는 파이프라인을 구축했습니다.

이는 기본적인 대기 시간 방정식을 소개합니다.

$$\text{Latency} = T_{extract} + T_{transfer} + T_{load} + T_{indexing}$$

데이터를 복사할 때마다 다음이 발생합니다.

1. 지연: “오래된 데이터” 문제. 파이프라인이 야간에 실행되는 경우 AI는 항상 현실보다 24시간 늦습니다.
2. 비용: 기업은 복제에 대해 특정 스토리지 비용을 지불합니다. 1PB의 데이터를 저장하는 것은 관리 가능합니다. 5개의 복사본(Raw, Bronze, Silver, Gold, Warehouse)을 저장하는 것은 엄청납니다.
3. 직렬화 오버헤드: JSON/CSV를 Parquet/Avro(SerDes)로 표준화하는 데 드는 CPU 비용은 추론에 사용할 수 있는 엄청난 양의 컴퓨팅을 소비합니다.
4. 드리프트: 소스 A의 스키마가 변경되어(예: 개발자가 user_id의 이름을 uuid로 변경) 대상 B로의 파이프라인이 중단됩니다.

Dataversity는 이러한 취약한 파이프라인에서 비롯되는 열악한 데이터 품질로 인해 **내년 AI 프로젝트의 60%**가 중단될 수 있다고 경고합니다. 해결책은 더 빠른 파이프라인이 아닙니다. 아니요 파이프라인이 아닙니다.

데이터 중력의 진화

Zero-Copy 혁명을 이해하려면 지난 20년 동안의 데이터 아키텍처의 궤적을 매핑하는 것이 도움이 됩니다. 업계는 결합과 분리 사이에서 진동했습니다.

1단계: 모놀리스(1990-2010)

태초에는 Oracle Database가 있었습니다. 스토리지와 컴퓨팅은 긴밀하게 결합되었습니다. 더 빠른 쿼리를 실행하려면 더 큰 상자를 구입하세요. 일관되고 빠르지만(ACID 규격) 수평 확장이 불가능했습니다. 웹 규모의 데이터 양에 질식했습니다.

2단계: 데이터 레이크/“늪”(2010-2018)

Hadoop 시대에는 HDFS가 도입되었습니다. 철학은 “읽기의 스키마”였습니다. 모든 JSON 로그를 저렴한 저장소에 저장하고 나중에 알아보세요. 이로써 보관 비용 문제는 해결됐지만 ‘늪’이 생겼다. 쿼리 성능이 형편없었고 트랜잭션이 없으면 데이터 무결성이 사라졌습니다. 이 데이터에 대해 훈련된 AI 모델은 입력 데이터가 쓰레기이거나 불완전했기 때문에 종종 환각을 느꼈습니다.

3단계: 클라우드 웨어하우스(2018-2023)

Snowflake 및 BigQuery는 컴퓨팅에서 스토리지(S3/GCS)를 분리합니다. 이것은 획기적인 일이었습니다. 스토리지를 무한대로 확장하고 필요에 따라 컴퓨팅 클러스터를 가동할 수 있습니다. 그러나 형식은 여전히 ​​독점적이었습니다. Snowflake를 사용하려면 Snowflake를 COPY INTO해야 했습니다. 데이터는 마이크로 파티션에 잠겨 있었습니다. 여전히 바이트를 이동해야 했습니다.

4단계: 제로 카피 레이크하우스(2024+)

이것이 현재의 변곡점이다. 데이터는 S3에 유지되지만 개방형 형식(예: Apache Iceberg)으로 유지됩니다. 컴퓨팅 엔진(Snowflake, Spark, Trino, Dremio)은 데이터가 있는 곳을 방문합니다. COPY INTO이 없습니다. SELECT * FROM만 있습니다.

기술 심층 분석: Zero-Copy의 실제 작동 방식

“제로 카피(Zero-Copy)“는 잘못된 명칭입니다. 비트는 디스크 어딘가에 존재합니다. 그러나 구조적으로 이는 시스템이 바이트를 컴퓨팅으로 이동하지 않음을 의미합니다. 바이트에 대한 컴퓨팅 권한을 가져옵니다(또는 특히 포인터를 공유합니다).

Apache Iceberg, Delta Lake, Apache Hudi와 같은 최신 “오픈 테이블 형식”이 이를 가능하게 합니다. 이를 통해 서로 다른 컴퓨팅 엔진이 해당 파일을 “소유”할 필요 없이 객체 스토리지에 있는 동일한 파일을 볼 수 있습니다.

메타데이터 레이어

메타데이터에서 마법이 일어납니다. 10TB 테이블을 복사하는 대신 Zero-Copy 시스템은 S3에 있는 Parquet 파일에 대한 포인터 목록인 매니페스트 파일을 공유합니다.

엔지니어가 Snowflake에서 데이터베이스를 “복제”하거나 Dremio Arctic에서 분기를 생성하는 경우 시스템은 10TB를 복제하지 않습니다. 이는 메타데이터(킬로바이트)를 복제하고 동일한 기본 스토리지 블록을 가리킵니다.

격리의 역학: Zero-Copy는 스냅샷 격리에 크게 의존합니다.

1. 매니페스트 목록은 특정 “스냅샷”(예: 스냅샷 S1)을 가리킵니다.
2. 스냅샷 S1은 매니페스트 파일 세트를 가리킵니다.
3. 매니페스트 파일은 실제 데이터 파일(Parquet)을 가리킵니다.

AI 모델이 오전 10시에 훈련을 시작하면 Snapshot S1에 고정됩니다. ETL 작업이 오전 10시 5분에 테이블을 업데이트하면 스냅샷 S2가 생성됩니다(새 Parquet 파일 및 새 매니페스트 작성). AI 모델은 방해받지 않고 계속해서 S1을 읽습니다. 잠금 장치도 없고 작성자를 차단하는 리더도 없습니다.

쿼리 푸시다운 최적화: 분석 엔진은 필터를 소스 데이터베이스에 푸시합니다. 쿼리에서 SELECT * WHERE region = 'Western-Region'을 요청하면 소스 시스템은 메타데이터를 사용하여 ‘Western-Region’ 데이터가 포함된 특정 마이크로 파티션을 식별합니다. 특정 블록만 반환합니다. 이는 전체 테이블 스캔에 비해 네트워크 전송을 효과적으로 줄입니다.

“유니스토어” 컨셉

Zero-Copy의 궁극적인 목표는 흔히 HTAP(하이브리드 트랜잭션/분석 처리)라고 불리는 개념인 트랜잭션(OLTP) 및 분석(OLAP) 워크로드를 통합하는 것입니다.

Snowflake의 Unistore와 Databricks의 Lakehouse 패러다임은 이러한 격차를 해소하는 것을 목표로 합니다. 구매가 트랜잭션 행 저장소에 기록되는 소매 애플리케이션을 상상해 보십시오. 기존 환경에서는 야간 일괄 작업이 완료될 때까지 해당 행이 분석 웨어하우스에 표시되지 않았습니다. Zero-Copy Unistore 환경에서는 통합 테이블 추상화를 통해 해당 행이 분석 엔진에 즉시 표시됩니다.

AI의 경우 이는 판도를 바꾸는 일입니다. 추천 시스템은 다음 날뿐만 아니라 동일 세션 내에서 사용자의 클릭에 반응할 수 있습니다.

2026년 현실: “살아있는 생태계”

이러한 아키텍처 변화는 단지 디스크 공간 절약에만 국한되지 않습니다. 조직의 민첩성에 관한 것입니다.

Slalom의 2026년 금융 서비스 전망은 “정적이고 사일로화된 솔루션”에서 데이터가 자유롭게 흐르는 “살아있고 적응 가능한 생태계”로의 전환을 예측합니다. 그들은 통합 데이터 기반을 이를 위한 전제 조건으로 식별합니다. 은행의 사기 탐지 AI가 야간 배치 작업을 기다려야 한다면 실시간 2026 위협에 대해서는 쓸모가 없습니다. 보고서는 “거버넌스가 속도와 신뢰성을 모두 가능하게 한다”고 강조하며 메타데이터 계층이 새로운 제어 평면이 될 것임을 시사합니다.

McKinsey의 기술 동향은 AI의 “실행 격차”가 주로 데이터 가용성 문제라는 점을 강조하면서 이를 뒷받침합니다. 분석에 따르면 실시간 통찰력을 바탕으로 조치를 취할 수 있는 조직은 두 자릿수 성장을 이룰 가능성이 1.6배 더 높습니다. 데이터를 “그 자리에서” 쿼리하는 기능을 사용하면 새 파이프라인을 설정하는 데 따른 어려움 없이 다른 팀이 즉시 사용할 수 있는 데이터 제품을 생성할 수 있습니다.

“헤드리스” 데이터 아키텍처의 부상

분석가들은 2026년 내내 “헤드리스” 데이터 아키텍처가 우세할 것으로 예상합니다. 이 모델에서는 저장소와 의미 계층이 소비 도구에서 완전히 분리됩니다.

• 스토리지: S3/Azure Blob(저렴함, 무한).
• 형식: Iceberg/Delta(공개, 트랜잭션).
• 카탈로그: ​​Nessie/Unity 카탈로그(포인터를 추적하는 “브레인”).
• 컴퓨팅: 사용자가 원하는 모든 것. 데이터 과학자는 PySpark를 사용합니다. 분석가는 SQL을 사용합니다. CEO는 대시보드를 사용합니다. 그들은 모두 동일한 단일 진실 소스에 도달했습니다.

결론: 플랫폼은 파이프라인이다

데이터 엔지니어의 기술 세트가 변화하고 있습니다. A에서 B로 데이터를 이동하기 위해 효율적인 PySpark ETL 스크립트를 작성하는 것은 강력한 메타데이터 거버넌스 전략을 설계하는 것보다 덜 가치가 있습니다. 가치는 데이터 이동에 있지 않습니다. 데이터를 이동하지 않고도 액세스할 수 있도록 하는 것입니다.

전통적으로 이해되어 온 것처럼 파이프라인은 죽었습니다. 플랫폼이여 영원하라.

출처 (5)

• engineering.salesforce.com Zero Copy Revolutionizes Data Cloud
• slalom.com Financial Services Outlook 2026
• dataversity.net Data Management Trends 2026
• mckinsey.com Top Trends in Tech 2025
• arcadia.io Zero-Copy Data Lake