IDC 보고서에 따르면, 2025년까지 전 세계 데이터의 80% 이상이 비정형 데이터가 될 것으로 예상됩니다 (IDC FutureScape: Worldwide DataSphere 2023 Predictions). 이는 데이터 과학자와 ML 엔지니어들이 관리해야 할 데이터 자산의 복잡성과 규모가 기하급수적으로 증가한다는 의미입니다. 특히, AI 에이전트가 데이터 처리 및 분석의 핵심 주체가 되는 '에이전트 우선(agent-first)' 레이크하우스 환경에서는 이러한 복잡성이 더욱 심화됩니다. 여러 AI 에이전트가 동시에 독립적으로 데이터에 접근하고 변경하며, 새로운 피처를 엔지니어링하고, 모델을 훈련하며, 데이터를 정제하는 과정에서 예측 불가능한 데이터 충돌, 불일치, 그리고 롤백의 어려움에 직면하게 됩니다. 이러한 문제들은 데이터 무결성을 훼손하고, 모델의 재현성을 저해하며, 결국 개발 속도를 늦추는 주된 원인이 됩니다.
에이전트 주도 레이크하우스의 데이터 관리 난제
현대의 AI 개발 팀에서는 수많은 AI 에이전트나 머신러닝 파이프라인이 레이크하우스 내의 대규모 데이터셋을 독립적으로 다룹니다. 예를 들어, 한 에이전트는 특정 피처 엔지니어링 파이프라인을 개선하고, 다른 에이전트는 새로운 모델 훈련을 위해 데이터를 준비하며, 또 다른 에이전트는 과거 데이터의 정제 작업을 수행할 수 있습니다. 이 모든 에이전트가 동일한 논리적 데이터셋을 읽고 쓰는 상황에서 발생하는 가장 큰 문제는 '데이터 일관성'과 '변경 이력 관리'입니다. 전통적인 데이터 관리 방식으로는 다음과 같은 문제에 봉착합니다.
첫째, 데이터 충돌과 오염: 여러 에이전트가 동시에 동일한 데이터 영역을 수정할 때, 누가 어떤 변경을 했는지 추적하기 어렵고, 의도치 않은 데이터 오염이나 유실이 발생할 수 있습니다. 이는 특히 모델 훈련에 사용되는 데이터셋의 신뢰성을 떨어뜨려 예측 성능 저하로 이어집니다.
둘째, 변경 이력 추적 및 롤백의 어려움: 특정 시점의 데이터 상태를 정확히 파악하고, 문제가 발생했을 때 이전의 안정적인 상태로 완벽하게 롤백하는 것이 거의 불가능합니다. Apache Iceberg와 같은 테이블 포맷은 단일 테이블 스냅샷을 제공하지만, 레이크하우스 전체의 여러 테이블에 걸친 일관된 '커밋' 개념은 부족합니다.
셋째, 협업 및 재현성 부족: 각 에이전트의 작업이 독립적으로 격리되지 않으면, 한 에이전트의 변경이 다른 에이전트의 작업에 예기치 않은 영향을 미칠 수 있습니다. 이는 협업을 방해하고, 특정 모델이 어떤 데이터 버전을 기반으로 훈련되었는지 재현하기 어렵게 만듭니다. 결과적으로 MLOps 파이프라인의 안정성이 저해됩니다.
기존 데이터 관리의 기술적 한계와 근본 원인
이러한 문제의 근본 원인은 데이터 관리 방식이 코드 버전 관리 시스템인 Git의 강력한 기능을 따라가지 못하기 때문입니다. Git은 코드베이스의 변경 사항을 효율적으로 추적하고, 브랜치를 통해 독립적인 개발 환경을 제공하며, 병합을 통해 변경 사항을 통합합니다. 하지만 대규모 데이터셋, 특히 레이크하우스 환경에서는 다음과 같은 기술적 한계에 부딪힙니다.
레이크하우스 전체를 포괄하는 버전 관리의 부재: Apache Iceberg와 같은 개방형 테이블 포맷은 개별 테이블에 대한 스냅샷 기반의 버전 관리를 제공합니다. 이는 단일 테이블의 변경 이력을 추적하는 데는 효과적이지만, 여러 테이블, 스키마, 메타데이터를 포함하는 레이크하우스 *전체의 일관된 상태*를 하나의 원자적인 단위로 관리하는 메커니즘은 제공하지 않습니다. 즉, 데이터 레이크하우스의 여러 구성 요소에 걸친 변경 사항을 단일 '커밋'으로 묶어 관리할 수 없습니다.
동시성 제어 및 격리 문제: 여러 에이전트나 파이프라인이 동시에 동일한 논리적 데이터에 쓰기 작업을 수행할 때, 적절한 격리 메커니즘 없이는 데이터 무결성이 깨지기 쉽습니다. 데이터베이스의 트랜잭션 개념은 여기에 적용하기 어렵고, 파일 시스템 수준의 잠금은 대규모 분산 환경에서 비효율적입니다.
데이터 브랜칭 및 병합의 복잡성: 코드와 달리 수 테라바이트에 달하는 데이터셋을 효율적으로 '브랜칭'하고, 두 브랜치에서 발생한 변경 사항을 '병합'하는 것은 기술적으로 매우 어렵습니다. 데이터의 물리적 복사본을 만드는 것은 비용과 시간이 많이 들며, 스키마 진화나 데이터 내용 충돌 시의 병합 전략은 복잡한 문제입니다. 이로 인해 에이전트들은 독립적인 실험 환경을 갖기 어렵고, 결국 프로덕션 데이터에 직접 변경을 가해야 하는 위험한 상황에 놓이게 됩니다.
GitLake: 에이전트 우선 레이크하우스를 위한 데이터용 Git
이러한 난제들을 해결하기 위해 GitLake는 '에이전트 우선(agent-first)' 레이크하우스 설계를 위한 '데이터용 Git' 모델을 제시합니다. 이 시스템은 단일 테이블의 Iceberg 스냅샷을 레이크하우스 전체의 커밋, 브랜치, 병합 개념으로 확장하여 데이터 관리의 새로운 패러다임을 제공합니다. GitLake의 핵심 원리와 단계별 솔루션은 다음과 같습니다.
- 레이크하우스 전체 커밋(Lakehouse-wide Commits): GitLake는 개별 테이블의 스냅샷을 넘어, 레이크하우스 내의 모든 테이블과 그 관계를 포괄하는 '일관된 상태'를 하나의 원자적인 커밋으로 정의합니다. 이 커밋은 특정 시점의 레이크하우스 전체를 나타내며, Git의 커밋과 유사하게 변경 이력을 추적하고 롤백할 수 있는 기준점이 됩니다. 이는 데이터 거버넌스 및 감사 측면에서 큰 이점을 제공합니다.
- 격리된 에이전트 작업 공간(Isolated Agent Branches): 각 AI 에이전트 또는 ML 파이프라인은 자신만의 독립적인 '브랜치'에서 작업합니다. 이 브랜치는
main브랜치의 특정 커밋에서 파생되며, 에이전트는 이 브랜치 내에서 데이터를 자유롭게 수정하고, 스키마를 변경하며, 새로운 실험을 수행할 수 있습니다. 이는 다른 에이전트나 프로덕션 환경에 영향을 주지 않으므로, 개발자는 데이터 손상에 대한 두려움 없이 과감하게 실험하고 반복할 수 있습니다. 데이터 과학자는 새로운 피처를 안전하게 테스트하고, ML 엔지니어는 모델 훈련 파이프라인을 최적화할 수 있습니다.
- 인간 검토 및 발행(Human Review & Publishing): 에이전트 브랜치에서 이루어진 변경 사항은 자동으로 프로덕션에 반영되지 않습니다. 대신, Git의 풀 리퀘스트(Pull Request)와 유사하게, 변경 사항이
main또는production브랜치로 병합되기 전에 인간(데이터 엔지니어, MLOps 전문가)의 검토 과정을 거칩니다. 이 과정에서 데이터 품질 검증, 모델 성능 평가, 비즈니스 로직 확인 등이 이루어지며, 승인된 변경 사항만이 최종적으로 병합되어 발행됩니다. 이는 데이터 무결성과 신뢰성을 확보하는 핵심 단계입니다.
- 파이프라인 통합 및 최종 병합(Pipeline Integration & Final Merge): 데이터 파이프라인은 임시 브랜치에서 실행됩니다. 파이프라인이 성공적으로 완료되면, 그 결과물은 해당 임시 브랜치에 커밋되고, 이후
main브랜치로의 병합 요청이 시작됩니다. GitLake는 데이터 병합 시 발생하는 스키마 충돌이나 데이터 내용 충돌을 감지하고, 해결 전략을 제시하여 안정적인 통합을 지원합니다. 이로써 데이터 파이프라인의 안정적인 배포와 변경 관리가 가능해집니다.
GitLake 도입으로 인한 변화와 검증 방안
GitLake의 도입은 개발자, 아키텍처, 운영, 보안, 비용, 성능, 마이그레이션 등 전반적인 데이터 생태계에 긍정적인 변화를 가져옵니다.
- 개발자/데이터 과학자: 안전한 실험 환경을 통해 데이터 기반 실험 속도가 향상됩니다. 명확한 데이터 변경 이력과 손쉬운 롤백 기능은 개발자의 생산성을 크게 높입니다. 특정 모델이 어떤 데이터 버전을 사용했는지 정확히 알 수 있어 재현성이 보장됩니다.
- 아키텍처: Iceberg와 같은 개별 테이블 포맷 위에 레이크하우스 전체를 포괄하는 버전 관리 계층을 추가하여, 데이터 아키텍처의 견고성과 확장성을 강화합니다. 데이터의 불변성 원칙을 브랜치 수준에서 구현하여 시스템의 안정성을 높입니다.
- 운영: 데이터 변경 사항의 배포가 Git 기반 워크플로우를 따르므로, CI/CD 파이프라인에 쉽게 통합될 수 있습니다. 자동화된 테스트 브랜치에서 데이터 품질 검증이 이루어져 프로덕션 데이터의 안정성이 확보됩니다. 잘못된 데이터 푸시로 인한 시스템 다운타임이 감소합니다.
- 보안: 브랜치 수준에서 세분화된 접근 제어(RBAC)를 구현하여, 특정 에이전트나 사용자가 접근할 수 있는 데이터 범위를 제한할 수 있습니다. 모든 데이터 수정 이력이 커밋으로 기록되므로, 강력한 감사 추적(Audit Trail)이 가능합니다.
- 비용: 명확한 데이터 계보(Lineage)와 롤백 기능을 통해 잘못된 데이터 처리로 인한 재처리 비용을 줄일 수 있습니다. 효율적인 증분 변경 관리와 스냅샷 기반 스토리지는 저장 비용을 최적화하는 데 기여할 수 있습니다.
- 성능: 각 에이전트의 작업이 격리된 브랜치에서 이루어지므로,
main브랜치에 대한 동시성 충돌이 줄어듭니다. 데이터 파이프라인이 임시 브랜치에서 실행되므로, 프로덕션 데이터 경로를 방해하지 않고 작업을 수행할 수 있습니다. - 마이그레이션: 기존 Iceberg 기반 레이크하우스는 GitLake의 메타 레이어를 추가하여 점진적으로 버전 관리 기능을 도입할 수 있습니다. 이는 대규모 리팩토링 없이도 데이터 거버넌스를 강화할 수 있는 유연한 경로를 제공합니다.
검증 방안:
GitLake 시스템의 효과를 검증하기 위해서는 다음과 같은 지표들을 지속적으로 모니터링해야 합니다.
- 데이터 무결성 및 일관성: 병합 전 자동화된 데이터 품질 검사(예: 고유성, 완전성, 범위 검사)를 도입하여, 실패 시 병합을 차단합니다. 정기적인 데이터 감사(Audit)를 통해 브랜치 간 데이터 불일치 발생 여부를 확인합니다.
- 재현성: 특정 커밋으로 롤백했을 때, 레이크하우스 전체가 정확히 그 시점의 상태로 복원되는지 확인하는 롤백 훈련을 주기적으로 수행합니다. 해당 시점의 데이터로 훈련된 모델의 성능이 재현되는지 검증합니다.
- 개발 속도 및 에이전트 효율성: 데이터 관련 문제 해결에 소요되는 시간, 새로운 피처 개발 및 배포 주기, 에이전트의 실험 성공률 등을 측정하여 생산성 향상을 정량적으로 평가합니다.
- A/B 테스트 및 실험 관리: 다른 데이터 브랜치를 활용하여 모델 또는 피처에 대한 A/B 테스트를 수행하고, 각 브랜치에서 얻은 성능 지표를 비교하여 GitLake의 실험 관리 능력을 검증합니다.
GitLake는 데이터 관리의 복잡성을 Git의 단순하고 강력한 모델로 해결함으로써, AI 에이전트가 주도하는 미래의 레이크하우스 환경에서 데이터의 신뢰성, 재현성, 그리고 개발 효율성을 극대화할 수 있는 핵심적인 인프라가 될 것입니다.
참고: arXiv CS.AI