BigQuery에서 Databricks로: 전략적 프레임워크

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

오늘날 많은 조직이 BigQuery에서 다양한 데이터 및 분석 워크로드를 지원하고 있지만, BI, ETL, 멀티 모델 AI 워크로드를 단일 거버넌스 및 운영 모델로 통합할 수 있는 방법을 모색하고 있습니다. 통합 거버넌스 계층을 갖춘 개방형 Lakehouse는 운영을 단순화하고, 데이터와 AI 전반의 규정 준수를 간소화하며, 요구사항이 증가함에 따라 예측 가능한 성능을 제공하고, 새로운 AI 기반 유스 케이스의 기반을 마련하는 데 도움을 줍니다.

성공적인 마이그레이션은 단순히 테이블을 복사하는 것 이상을 요구합니다. 단계별 전략이 필요합니다. Google Cloud Storage와 같은 서비스의 개방형 형식으로 데이터를 이동하고, 로직을 신중하게 변환하며, 자동화된 툴링으로 결과를 검증하는 것입니다. 이 가이드는 최소한의 중단과 측정 가능한 비즈니스 영향으로 전환을 탐색하기 위해 프로세스, 기술, 사람이라는 세 가지 축을 중심으로 한 마이그레이션 프레임워크를 설명합니다.

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

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

진단

마이그레이션 여정은 자산 진단, 진입점 선택, 마이그레이션, 듀얼 오퍼레이션에서의 검증, 폐기 순서로 진행됩니다. 진단이 가장 먼저 선행되어야 합니다. 현재 운영 중인 시스템을 파악하지 않고는 올바른 진입점을 선택할 수 없습니다. 먼저 BigQuery 자산(데이터셋, 쿼리 기록, 슬롯 소비량)을 프로파일링하여 비용을 유발하는 워크로드, 실제로 사용되는 대시보드, 전혀 쿼리되지 않는 테이블을 파악하세요. Lakebridge는 오픈소스 Databricks Labs 마이그레이션 툴킷으로, 이러한 검색을 자동화하는 BigQuery 프로파일러를 포함하고 있어 단순한 존재 여부가 아닌 실제 사용량을 기반으로 마이그레이션 웨이브를 계획할 수 있습니다.

전략 선택

• BI 우선(BI-first): 의사결정권자가 매일 접하는 대시보드를 최우선으로 고려하세요. 이 경로는 대시보드 및 데이터 제품의 확장이 필요하고 분석가들이 AI 기능을 원하는 팀에 적합합니다. Databricks에서 가장 많이 사용되는 대시보드를 다시 구축하고, 처음에는 BigQuery 데이터를 제자리에서 읽어오며, 유스 케이스별로 팀을 전환하여 나란히 비교(side by side)하며 동등성을 입증합니다. 첫날부터 가시적인 성과를 얻을 수 있습니다. 더 빠른 대시보드와 Genie를 통한 자연어 질의응답이 그것입니다.
• ETL 우선(ETL-first): 변환 워크로드를 Databricks의 Photon/Spark 엔진으로 통합하고 비용과 성능을 최적화하는 것이 목표일 때 백엔드를 우선적으로 고려하세요. 이 경로는 AI 지원 데이터 기반을 먼저 구축하고 대시보드나 애플리케이션 같은 다운스트림 소비자가 그 뒤를 따르도록 하려는 팀에 적합합니다. 트레이드오프는 가시성입니다. 파이프라인이 안착될 때까지 비즈니스 사용자는 변화를 거의 느끼지 못하므로, 각 웨이브마다 런타임 및 효율성 지표를 공개하세요. 확실하지 않다면 진단의 결과에 따르세요. 대시보드 사용량이 높으면 BI 우선으로, 무거운 변환 워크로드는 ETL 우선으로 향해야 합니다.

어떤 진입점을 선택하든 한 번에 전환(big bang)하는 대신 웨이브 단위로 마이그레이션하세요. 일괄 전환은 모든 위험을 단 한 순간에 집중시킵니다. 무언가 문제가 생기면 전체 프로그램에 대한 신뢰도 무너집니다. 웨이브를 이용하면 영향 범위를 작게 유지할 수 있습니다. 조직 내 가치(리더십에 얼마나 가시적인지, 매출에 얼마나 직접적으로 연결되는지, 규정 준수 마감일이 얼마나 시급한지, 매일 얼마나 많은 사람이 의존하는지)와 마이그레이션 복잡성의 두 가지 축으로 워크로드를 평가하고, 가치가 높고 복잡성이 낮은 곳부터 시작하세요. 각 웨이브는 가시적인 비즈니스 성과를 제공하고, 다음 웨이브가 시작되기 전에 조율하며, 팀의 플레이북을 다음 단계로 더 빠르게 넘길 수 있게 해줍니다. 두 플랫폼을 운영하는 비용이 보호하는 것보다 더 큰 드문 소규모의 저위험 자산을 제외하고는 일괄 전환(big bang)을 지양하세요.

실행

1. 리프트 앤 시프트(Lift and shift): 기존 SQL 로직을 "있는 그대로" Databricks Lakehouse로 마이그레이션합니다. 이를 통해 작업 기준선을 빠르게 확립하고 팀이 최적화 전에 동등성을 검증할 수 있습니다.
2. 현대화(Modernize): 일단 안정화되면 가치가 높은 파이프라인을 Lakeflow Spark Declarative Pipelines로 리팩터링하여 자동화된 오케스트레이션, 내장된 데이터 품질, 배치 및 스트리밍 모두를 위한 통합 프레임워크를 활용하세요.

대부분의 조직은 검증을 위해 워크로드를 "쉐도잉"하는 Lakehouse Federation을 사용하여 듀얼 오퍼레이션 단계를 거칩니다. ROI의 핵심은 명확한 "성공 기준"(예: 99.9% 동등성)을 설정하여 레거시 파이프라인의 즉각적인 폐기를 유도하고 두 플랫폼을 운영하는 비용을 없애는 것입니다.

듀얼 오퍼레이션은 양방향으로 작동하며, 올바른 브릿지는 진입점에 따라 다릅니다. BI 우선 팀은 대시보드가 먼저 이동하는 동안 Databricks가 BigQuery를 읽을 수 있도록 Lakehouse Federation을 사용합니다. ETL 우선 팀은 이를 뒤집어 인제스션과 변환을 Databricks로 이동하고, 큐레이션된 테이블을 개방형 형식으로 안착시킨 후, 동일한 단일 복사본에서 BigQuery가 기존 대시보드와 애플리케이션을 계속 서빙하도록 합니다. 이중 쓰기(dual-write) 파이프라인도, 내보내기 작업도, 조율해야 할 두 번째 복사본도 없습니다.

웨이브 단위로 마이그레이션하면 이 듀얼 오퍼레이션 창이 짧고 좁게 유지됩니다. 현재 웨이브에 속한 워크로드만 두 플랫폼 동시 운영 비용을 부담하므로, 듀얼 오퍼레이션 비용은 전체 자산이 아닌 실제 진행 중인 작업량에 비례하여 유지됩니다. BigQuery를 서빙 계층으로 사용하는 것은 목적지가 아니라 과도기적 상태로 취급하세요. 외부 테이블은 BigQuery 측에서 읽기 전용이며 스키마 변경 후 수동 스키마 새로 고침과 같은 제한 사항이 있으므로, 여정의 마무리 단계로 서빙 계층을 Databricks Lakehouse로 전환하는 것을 계획하세요.

거버넌스

Unity Catalog는 거버넌스를 걸림돌에서 전략적 엔진으로 탈바꿈시킵니다. BigQuery 권한을 복제하는 동시에 자동화된 엔드투엔드 리니지를 추가하고 AI 모델을 일급 시민(first-class citizen)으로 취급하는 원활한 3계층 매핑(프로젝트 → 카탈로그, 데이터셋 → 스키마, 테이블 → 테이블)을 제공합니다.

매핑은 객체 계층 구조보다 더 깊이 들어갑니다. Unity Catalog는 기본적으로 동일한 세분화된 보호 기능을 제공합니다. 행 필터는 행별로 액세스를 제한하고, 열 마스크와 태그는 열 수준 보안을 처리하므로, 보호 기능이 처음부터 다시 구축되지 않고 데이터와 함께 이동합니다. 현장에서 얻은 하나의 시퀀싱 규칙은 데이터보다 권한을 먼저 마이그레이션하는 것입니다. 그래야 각 웨이브의 전환이 테이블이 어디에 살는지는 바꾸어도 누가 볼 수 있는지는 바꾸지 않습니다.

기술: 개방형 기반 구축

기술적 축은 Google Cloud Storage와 같은 서비스의 개방형 형식으로 데이터를 이동하고, 로직을 Databricks SQL 및 Spark로 마이그레이션하며, 결과를 검증하는 데 중점을 둡니다.

BigQuery에서 Databricks로의 마이그레이션은 데이터 마이그레이션, 로직 마이그레이션, 검증의 세 가지 워크스트림을 포함합니다.

데이터 마이그레이션

볼륨과 최신성에 따라 경로를 선택하세요. 대용량 히스토리는 Google Cloud Storage의 Parquet으로 BigQuery 내보내기를 통해 가장 빠르게 이동하며, 이는 대규모에서 대개 경제적인 경로이며 내보내기는 검증을 단순화하는 고정된 시점(point-in-time) 복사본 역할도 겸합니다. 지속적으로 업데이트되는 테이블은 Storage API 커넥터나 소스 리디렉션을 통해 읽으며, 작고 자주 변경되는 데이터셋은 웨이브가 도래할 때까지 페더레이션을 통해 쿼리 가능한 상태를 유지할 수 있습니다. 모든 데이터는 메달리온 계층을 위한 준비가 완료된 개방형 형식으로 안착됩니다.

로직 마이그레이션

자산을 수동으로 변환하지 마세요. 세 가지 계층이 이를 커버합니다. 루틴 SQL의 대부분을 위한 규칙 기반 변환(예: Lakebridge), 방언의 특이성을 위한 LLM 지원 변환, 그리고 진정으로 복잡한 테일 영역을 위해 남겨둔 엔지니어들입니다. 오케스트레이션도 동일한 패턴을 따릅니다. 스케줄된 쿼리 및 Composer DAG는 Lakeflow Jobs에 매핑됩니다.

검증

마이그레이션 자체만큼 심각하게 검증 예산을 책정하세요. 현장에서는 종종 이에 준하는 노력이 소모됩니다. 완전성(행 수), 일관성(스키마 및 타입), 정확성(집계 조율 및 행 수준 해싱)의 세 가지 수준에서 실행하며, BigQuery를 기본 소스로 지원하는 Lakebridge reconcile으로 자동화합니다. 현장의 교훈 하나: 두 SQL 방언 간의 작은 내장 함수 차이로 인해 해시 비교가 실패할 수 있습니다. 데이터 손실을 가정하기 전에 불일치 원인을 조사하세요. 여기서의 동등성이 프로세스 여정에서 폐기를 트리거하는 요인입니다.

개방형 테이블 형식

오픈 소스 기반이라는 점은 마이그레이션이 완료되기도 전에 효과를 발휘합니다. Delta Lake와 Apache Iceberg는 개방형 포맷이므로 Google Cloud Storage에 적재된 테이블은 Databricks 외의 도구에서도 읽을 수 있습니다. BigQuery는 BigLake 외부 테이블을 통해 Delta를 읽고, Iceberg 외부 테이블을 통해 Iceberg를 읽으며, Unity Catalog와 BigQuery 간의 카탈로그 연동(현재 미리보기 중)을 통해 두 플랫폼 모두 데이터를 복사하지 않고도 동일한 테이블을 관리하고 쿼리할 수 있습니다. 저장소는 엔진과 분리되어 있어 데이터는 한 번만 저장하고 여러 엔진에서 활용할 수 있습니다. 이러한 상호운용성은 부가적인 혜택이 아니라, 프로세스 섹션에서 설명한 저위험 전환 패턴을 가능하게 하는 핵심 역량입니다.

사람: 현대적인 Data + AI 팀 구성하기

세 번째 축은 마이그레이션의 궁극적인 ROI인 더 유능하고 통합된 인력 구축을 실현합니다.

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

새로운 기술 스택 구축하기. Genie는 SQL 중심 팀을 위한 다리 역할을 합니다. 분석가는 자연어를 사용하여 Python이나 Spark 코드를 생성할 수 있으므로, 가파른 학습 곡선 없이도 전통적인 분석가를 다재다능한 데이터 실무자로 전환할 수 있습니다. 이러한 일상적인 AI 지원과 함께 구조화된 교육, Databricks Academy 코스 및 역할 기반 인증을 결합하면, 일부 독학한 얼리어답터에게만 의존하지 않고 조직 전체에 새로운 기술이 뿌리내릴 수 있습니다.

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

현장의 교훈

성공적인 BigQuery 마이그레이션 프로젝트 경험을 바탕으로 도출된 6가지 반복 패턴은 다음과 같습니다.

• 계획 전에 프로파일링하기. 대부분의 환경에서 BigQuery 테이블의 상당 부분은 거의 또는 전혀 쿼리되지 않습니다. 쿼리 기록과 슬롯 사용량을 먼저 프로파일링하면 중요한 워크로드만 마이그레이션하고 나머지는 정리할 수 있습니다.
• 듀얼 런 시작 전에 동등성 기준 정의하기. 성공 임계값(예: 행 수, 집계, 해시 전반에 걸쳐 99.9% 일치)을 사전에 합의하세요. 이 기준이 없으면 섀도우 기간에 종료 조건을 설정할 수 없습니다.
• SQL을 수동으로 변환하지 마세요. 규칙 기반 트랜스파일레이션과 AI 지원 변환을 결합하여 대부분의 작업을 처리하고, 진정으로 복잡한 나머지 작업은 엔지니어에게 맡기세요.
• 거버넌스는 1대1로 먼저 매핑하고 현대화는 나중에 진행하기. 프로젝트 → 카탈로그, 데이터셋 → 스키마, 테이블 → 테이블을 Unity Catalog로 매핑하면 첫날부터 행 및 열 수준 정책을 포함한 기존 권한이 유지됩니다. 더 정교한 태깅, 속성 기반 제어, 리니지 기반 거버넌스는 컷오프 이후에 발전시킬 수 있습니다.

• BI 우선 접근 방식을 변경 관리 프로젝트로 다루기. 기술적인 부분은 상대적으로 쉬운 편입니다. 대시보드를 사용하는 분석가들에게는 교육, 챔피언 지정, 피드백 루프가 필요합니다.
• 플랫폼 규모 적정화하기. Databricks에서 워크로드가 검증되면 중복된 처리를 중단하여 동일한 작업에 대해 두 곳에서 비용이 발생하는 상황("더블 버블")을 방지하세요. 단순히 서비스 오픈뿐만 아니라 마이그레이션 완료를 축하하세요.

결론

Databricks로의 마이그레이션은 한 번에 이루어지는 도약이 아니라 계획할 수 있는 일련의 의사결정 과정입니다. 어떤 진입점이 팀에 적합한지, 다음 단계로 넘어가기 전에 각 단계에서 확실한 성과를 거두기 위해 물결 단계를 어떻게 구성할지, 마지막 대시보드가 전환될 때까지 BigQuery와 Databricks를 나란히 실행할 브리지는 무엇인지 결정해야 합니다. 이러한 순서를 잘 맞추면 프로세스, 기술, 사람이 서로를 뒷받침합니다. 데이터 마이그레이션, 로직 변환, 검증을 통해 한쪽의 기존 시스템을 퇴출하는 동시에, Genie를 사용하여 자연어로 쿼리하는 분석가와 거버넌스가 적용된 데이터 제품을 배포하는 엔지니어가 그 기반 위에서 성장하게 됩니다.

그 결과 개방형 레이크하우스, 조직이 단계마다 신뢰할 수 있는 마이그레이션, 그리고 새로 적재된 데이터를 기반으로 구축할 준비가 된 팀을 얻게 됩니다.

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

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