BigQuery에서 Databricks로: 현대적인 마이그레이션을 위한 전략적 프레임워크

전략적 진화로서의 마이그레이션

BigQuery는 빠르게 시작하기 위한 표준으로 자주 사용되지만, 많은 기업의 경우 규모가 커짐에 따라 결국 그 단순함이 관리상의 과제로 변하게 됩니다. 워크로드가 늘어나면서 가변적인 온디맨드 비용과 슬롯 예약으로 인해 성능과 예산 사이에서 타협해야 하고, 데이터 거버넌스 관리의 복잡성까지 증가하는 시점이 오면 아키텍처를 재고해야 할 때입니다.

ETL, Storage, BI 및 멀티 모델 AI를 통합 거버넌스 레이어를 갖춘 단일의 개방형 및 단순화된 레이크하우스 아키텍처로 통합함으로써, 기업은 독점적인 사일로를 제거하고 어떤 규모에서든 예측 가능한 성능을 얻을 수 있습니다. 이러한 전환을 통해 팀은 운영을 단순화하고, 데이터부터 AI에 이르는 컴플라이언스를 간소화하며, 새로운 AI 기반 사용 사례를 발굴할 수 있는 개방형 포맷으로 이동할 수 있습니다.

성공적인 마이그레이션은 단순히 테이블을 복사하는 것 이상을 필요로 합니다. 독점 스토리지에서 데이터를 마이그레이션하고, 논리를 신중하게 변환하며, 자동화된 툴링으로 결과를 검증하여 ROI를 확보하는 단계별 전략이 필요합니다. 이 가이드는 최소한의 중단과 측정 가능한 비즈니스 영향을 통해 이러한 전환을 탐색할 수 있도록 프로세스(Process), 기술(Technology), 사람(People) 전반에 걸친 실용적인 프레임워크를 개략적으로 설명합니다.

프로세스: 마이그레이션 여정 및 거버넌스 진화

프로세스 필러는 마이그레이션 방법을 정의합니다. 성공 여부는 올바른 진입점을 선택하고 전환 기간을 효과적으로 관리하는 데 달려 있습니다.

평가

마이그레이션 여정은 자산 평가, 진입점 선택, 마이그레이션, 이중 운영에서의 검증, 그리고 서비스 중단(decommission)의 순서로 진행됩니다. 평가는 다른 모든 것보다 먼저 이루어져야 합니다. 현재 실행 중인 항목을 모르면 올바른 진입점을 선택할 수 없기 때문입니다. 먼저 데이터 세트, 쿼리 기록, 슬롯 소비 등 BigQuery 자산을 프로파일링하여 어떤 워크로드가 비용을 유발하는지, 실제로 사용되는 대시보드는 무엇인지, 전혀 쿼리되지 않는 테이블은 무엇인지 파악하세요. 오픈 소스 Databricks Labs 마이그레이션 툴킷인 Lakebridge에는 이러한 검색을 자동화하는 BigQuery 프로파일러가 포함되어 있어, 단순히 존재하는 것이 아니라 실제로 사용되는 것을 중심으로 마이그레이션 웨이브를 계획할 수 있습니다.

전략 선택

• BI 우선: 의사 결정권자가 매일 보는 대시보드를 우선시합니다. 이는 대시보드가 느리거나 동시성 제한에 걸려 있고, 분석가들이 AI 기능을 원하는 분석 리더를 위한 경로입니다. 가장 많이 사용하는 대시보드를 Databricks에서 재구축하고, 처음에는 BigQuery 데이터를 그대로 읽은 다음, 동등성을 나란히 입증하면서 한 번에 하나의 사용 사례씩 팀을 전환하세요. 첫날부터 더 빠른 대시보드와 Genie를 통한 자연어 Q&A라는 확실한 보상을 얻을 수 있습니다.
• ETL 우선: 급증하는 비용이나 성능 병목 현상을 해결하기 위해 백엔드를 우선시합니다. 무거운 처리를 Photon/Spark 엔진으로 오프로드함으로써 "엔진"을 안정시키고 미래의 AI를 위한 깨끗한 기반을 마련할 수 있습니다. 이는 비용이 상승하고 파이프라인 윈도우가 밀리는 것을 지켜보는 데이터 플랫폼 소유자에게 적합합니다. 백엔드를 먼저 이동하고 결과로 증명하세요. 절충점은 가시성입니다. 파이프라인이 안착할 때까지 비즈니스 사용자는 거의 볼 수 없으므로, 각 웨이브마다 비용 및 런타임 개선 성과를 공유하세요. 확실하지 않을 때는 평가 결과에 따라 결정합니다. 대시보드 불만이 많다면 BI 우선을, 파이프라인 비용이 문제라면 ETL 우선을 선택하세요.

어떤 진입점을 선택하든 한 번에 모든 것을 바꾸는 빅뱅(big-bang) 방식이 아닌, 여러 웨이브에 걸쳐 단계적으로 마이그레이션하세요. 빅뱅 방식의 전환은 모든 리스크를 한순간에 집중시키며, 하나라도 잘못되면 전체 프로그램에 대한 신뢰도 깨지게 됩니다. 단계적 웨이브는 영향 범위를 작게 유지합니다. 조직에 대한 가치(리더십에 얼마나 노출되는지, 매출에 얼마나 직접적으로 영향을 미치는지, 관련 컴플라이언스 기한이 얼마나 시급한지, 얼마나 많은 사람들이 매일 의존하는지)와 마이그레이션 복잡성이라는 두 가지 축으로 워크로드의 순위를 매기고, 가치는 높고 복잡성은 낮은 곳부터 시작하세요. 그러면 각 웨이브마다 눈에 보이는 비즈니스 성과를 거두고, 다음 웨이브가 시작되기 전에 조정 작업을 마칠 수 있으며, 팀의 플레이북을 개선하여 다음 단계를 더 빠르게 진행할 수 있습니다. 빅뱅 방식은 두 플랫폼을 동시에 운영하는 비용이 리스크 방지 비용보다 더 큰, 드물고 규모가 작으며 리스크가 낮은 자산에만 아껴두세요.

실행

1. 리프트 앤 시프트(Lift and shift): 기존 SQL 논리를 Databricks SQL로 "있는 그대로" 마이그레이션합니다. 이를 통해 레거시 비용을 신속하게 줄이고 즉각적인 성능 향상을 보장할 수 있습니다.
2. 현대화: 안정화되면 가치가 높은 파이프라인을 Lakeflow Spark Declarative Pipeline으로 리팩터링하여 자동화된 오케스트레이션, 내장된 데이터 품질, 배치 및 스트리밍 모두를 위한 통합 프레임워크를 구축합니다.

대부분의 조직은 검증을 위해 워크로드를 "섀도잉(shadow)"하는 Lakehouse Federation을 사용하여 이중 운영(Dual Operation) 단계를 거칩니다. ROI의 핵심은 명확한 "성공 기준"(예: 99.9% 동등성)을 설정하여 레거시 파이프라인을 즉시 중단하도록 유도함으로써 두 플랫폼을 운영하는 비용을 제거하는 것입니다.

이중 운영은 양방향으로 작동하며, 올바른 브릿지는 진입점에 따라 다릅니다. BI 우선 팀은 대시보드가 먼저 이동하는 동안 Databricks가 BigQuery를 읽을 수 있도록 Lakehouse Federation을 사용합니다. ETL 우선 팀은 이를 반대로 적용합니다. 수집 및 변환을 Databricks로 이동하고, 정제된 테이블을 개방형 포맷으로 저장한 다음, BigQuery가 동일한 단일 사본에서 기존 대시보드 및 애플리케이션을 계속 서비스하도록 합니다. 이중 쓰기 파이프라인, 내보내기 작업, 조정할 두 번째 사본이 필요하지 않습니다. 단계적 웨이브로 마이그레이션하면 이중 운영 기간을 짧고 좁게 유지할 수 있습니다. 현재 웨이브의 워크로드만 두 플랫폼을 동시에 운영하는 비용을 부담하므로, 이중 운영 비용은 전체 자산이 아니라 실제로 진행 중인 워크로드에 비례하여 유지됩니다. BigQuery를 서빙 레이어로 사용하는 것은 최종 목적지가 아닌 과도기적 상태로 취급하세요. 외부 테이블은 BigQuery 측에서 읽기 전용이며 스키마 변경 후 수동 스키마 새로 고침과 같은 제한 사항이 있으므로, 서빙 레이어를 Databricks SQL로 전환하는 계획을 여정의 최종 단계로 수립하세요.

엔진으로서의 거버넌스

Unity Catalog는 거버넌스를 장애물에서 전략적 엔진으로 변화시킵니다. BigQuery 권한을 복제하는 동시에 자동 엔드투엔드 리니지를 추가하고 AI 모델을 일급 시민(first-class citizens)으로 취급하는 원활한 3계층 매핑(Project -> Catalog, Dataset -> Schema, Table -> Table)을 제공합니다.

매핑은 객체 계층 구조보다 더 깊이 들어갑니다. Unity Catalog는 동일한 미세 조정된 보호 기능을 기본적으로 제공합니다. 행 필터는 행 단위로 액세스를 제한하고, 열 마스크 및 태그는 열 수준 보안을 처리하므로 보호 기능이 처음부터 다시 구축되는 대신 데이터와 함께 이동합니다. 그리고 현장에서 얻은 한 가지 순서 규칙은 데이터보다 권한을 먼저 마이그레이션하는 것입니다. 그래야 각 웨이브의 전환 시 테이블이 위치한 곳만 변경되고, 해당 테이블을 볼 수 있는 사람은 변경되지 않습니다.

기술: 개방형 기반 구축

기술 필러는 폐쇄적이고 독점적인 스토리지 모델에서 개방형 고성능 아키텍처로 이동하는 데 중점을 둡니다.

BigQuery에서 Databricks로 현대화하는 작업은 데이터 마이그레이션, 논리 마이그레이션, 검증의 세 가지 워크스트림으로 구성됩니다.

데이터 마이그레이션

볼륨과 최신성에 따라 경로를 선택하세요. 대규모 이력 데이터는 Google Cloud Storage의 Parquet로 BigQuery를 내보내는 방식이 가장 빠르며, 이는 대규모 환경에서 대개 경제적인 경로입니다. 또한 내보낸 데이터는 검증을 단순화하는 특정 시점의 고정된 사본 역할을 겸합니다. 지속적으로 업데이트되는 테이블은 Storage API 커넥터를 통해 읽거나 소스에서 리디렉션되며, 자주 변경되는 소규모 데이터 세트는 해당 웨이브가 올 때까지 페더레이션을 통해 쿼리 가능한 상태로 유지될 수 있습니다. 모든 데이터는 메달리온 레이어에 사용할 준비가 된 개방형 포맷으로 저장됩니다.

논리 마이그레이션

자산을 수동으로 변환하지 마세요. 세 가지 계층으로 처리할 수 있습니다. 대부분의 일상적인 SQL을 위한 규칙 기반 트랜스파일레이션(예: Lakebridge), 방언의 특이성을 해결하기 위한 LLM 지원 변환, 그리고 진정으로 복잡한 나머지 부분을 위해 엔지니어를 배치하는 것입니다. 오케스트레이션도 동일한 패턴을 따릅니다. 예약된 쿼리와 Composer DAG는 Lakeflow Jobs에 매핑됩니다.

검증

마이그레이션 자체만큼이나 검증 예산도 진지하게 책정하세요. 현장에서는 종종 마이그레이션과 비슷한 수준의 노력이 소요됩니다. 검증은 완전성(행 수), 일관성(스키마 및 유형), 정확성(집계 조정 및 행 수준 해싱)의 세 가지 수준에서 실행하며, BigQuery를 네이티브 소스로 지원하는 Lakebridge 조정을 통해 자동화합니다. 현장에서 얻은 한 가지 교훈은 두 SQL 방언 간의 미세한 내장 함수 차이로 인해 해시 비교가 실패할 수 있다는 점입니다. 데이터 손실로 단정하기 전에 불일치 원인을 조사하세요. 여기서 동등성이 확인되면 프로세스 여정에서 서비스 중단이 트리거됩니다.

개방형 테이블 포맷

개방형 기반은 마이그레이션이 완료되기도 전에 그 가치를 발휘합니다. Delta Lake와 Apache Iceberg는 개방형 포맷이기 때문에 Google Cloud Storage에 저장하는 테이블은 Databricks뿐만 아니라 다른 플랫폼에서도 읽을 수 있습니다. BigQuery는 BigLake 외부 테이블을 통해 Delta를 읽고, Iceberg 외부 테이블을 통해 Iceberg를 읽습니다. 또한 Unity Catalog와 BigQuery 간의 카탈로그 페더레이션(현재 프리뷰 제공)을 통해 두 플랫폼 모두 데이터를 복사하지 않고도 동일한 테이블을 거버닝하고 쿼리할 수 있습니다. 스토리지는 엔진과 분리되어 있어, 하나의 데이터 사본으로 여러 엔진을 사용할 수 있습니다. 이러한 상호 운용성은 부가적인 이점이 아닙니다. 이는 '프로세스(Process)' 섹션에서 설명한 위험성이 낮은 전환 패턴을 가능하게 하는 핵심 기능입니다.

피플(People): 현대적인 데이터 및 AI 팀 구성

세 번째 기둥은 마이그레이션의 궁극적인 ROI인 더 유능하고 통합된 인력을 제공합니다.

인수인계 문화의 종식. 기존 레거시 스택에서는 SQL 분석가와 데이터 사이언티스트 간의 격차로 인해 사일로가 발생합니다. Databricks에서는 공유 Notebook을 통해 전체 "스쿼드(squad)"가 동일한 작업 공간에서 협업할 수 있으므로 커뮤니케이션 오버헤드가 줄어듭니다.

새로운 기술 역량 구축. Genie는 SQL 중심 팀을 위한 가교 역할을 합니다. 분석가는 자연어를 사용하여 Python 또는 Spark 코드를 생성할 수 있으므로, 가파른 학습 곡선 없이도 기존 분석가를 다재다능한 데이터 실무자로 전환할 수 있습니다. 이러한 일상적인 AI 지원을 체계적인 교육, Databricks Academy 과정 및 역할 기반 인증과 결합하여, 새로운 기술 역량이 몇몇 독학한 얼리어답터에게만 의존하지 않고 조직 전체에 안착되도록 하세요.

엔지니어링의 엄격함. 팀은 Unity Catalog, Git 통합, CI/CD와 같은 소프트웨어 엔지니어링 모범 사례를 도입함으로써 "쿼리 작성"에서 "데이터 제품 구축"으로 나아갑니다.

현장 실무에서 얻은 교훈

당사의 마이그레이션 프로젝트 경험을 바탕으로, 성공적인 BigQuery 마이그레이션에서 반복되는 6가지 패턴은 다음과 같습니다.

• 계획하기 전에 프로파일링하세요. 대부분의 환경에서 BigQuery 테이블의 상당 부분은 거의 또는 전혀 쿼리되지 않습니다. 쿼리 기록과 슬롯 사용량을 먼저 프로파일링하면 중요한 워크로드를 마이그레이션하고 나머지는 폐기할 수 있습니다.
• 이중 실행(dual-run)을 시작하기 전에 동등성 기준을 정의하세요. 성공 기준(예: 행 수, 집계 및 해시 전반에 걸친 99.9% 일치)을 미리 합의하세요. 이 기준이 없으면 병행 운영 기간(shadow period)을 끝낼 조건이 없어집니다.
• SQL을 수동으로 변환하지 마세요. 규칙 기반 트랜스파일레이션과 AI 지원 변환을 사용하면 대부분의 자산을 처리할 수 있습니다. 엔지니어는 정말로 복잡한 나머지 작업에만 투입하세요.
• 거버넌스는 먼저 일대일로 매핑하고, 현대화는 나중에 진행하세요. 프로젝트 → 카탈로그, 데이터 세트 → 스키마, 테이블 → 테이블 매핑을 통해 Unity Catalog로 전환하면 첫날부터 행 및 열 수준 정책을 포함한 기존 권한이 그대로 유지됩니다. 더 풍부한 태깅, 속성 기반 제어, 리니지 기반 거버넌스는 전환(cutover) 후에 점진적으로 발전시킬 수 있습니다.
• BI 우선 접근 방식을 변화 관리 프로젝트로 취급하세요. 기술적인 부분은 대개 더 쉬운 쪽에 속합니다. 대시보드가 이전되는 분석가들에게는 역량 강화 지원, 챔피언(전파자), 그리고 피드백 루프가 필요합니다.
• 적극적으로 서비스를 종료하세요. 두 플랫폼을 동시에 운영하는 기간이 매주 늘어날 때마다 ROI가 저하됩니다. 서비스 개시(go-live)뿐만 아니라 기존 서비스 종료(switch-off)도 축하하세요.

결론

Databricks로의 마이그레이션은 단 한 번의 도약이 아닙니다. 이는 실제로 계획할 수 있는 일련의 결정 과정입니다. 즉, 어떤 진입점이 팀에 적합한지, 다음 단계가 시작되기 전에 각 단계에서 성공을 거둘 수 있도록 단계를 어떻게 구성할지, 마지막 대시보드가 전환될 때까지 BigQuery와 Databricks를 병행하여 운영할 수 있는 가교는 무엇인지 결정하는 것입니다. 이러한 순서를 올바르게 설정하면 프로세스(Process), 기술(Technology), 피플(People)이 서로를 보완하게 됩니다. 한쪽에서는 데이터 마이그레이션, 로직 변환, 검증을 통해 기존 자산을 정리하고, 다른 쪽에서는 Genie를 통해 자연어로 쿼리하는 분석가와 거버닝된 데이터 제품을 배포하는 엔지니어가 그 위에 새로운 가치를 구축해 나갑니다.

그 결과는 단순히 독점적인 데이터 웨어하우스를 개방형 레이크하우스로 대체하는 것에 그치지 않습니다. 이는 조직이 단계별로 신뢰할 수 있는 마이그레이션이자, 마이그레이션된 환경을 기반으로 새로운 가치를 창출할 준비가 된 팀을 얻는 것입니다.

마이그레이션 계획을 시작할 준비가 되셨나요? Databricks 마이그레이션 허브를 살펴보고, 오픈 소스 Lakebridge 툴킷으로 자산을 평가하거나, Databricks 계정 팀에 문의하여 마이그레이션 평가를 받아보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)