데이터의 미래: 통합, 유연성, 접근성

기술 기업과 스타트업은 다음과 같은 조건을 충족해야 성공할 수 있다는 점에 주목하고 있습니다.

- 전사적으로는 물론 공급업체 및 파트너 전반에 걸쳐 데이터가 통합되어야 합니다. 이를 위해서는 비정형 데이터를 활용하고 조직과 기술의 사일로를 허물어야 합니다.

- 기술 스택은 오프라인 데이터 분석부터 실시간 머신러닝에 이르는 다양한 사용 사례를 지원할 수 있을 만큼 유연해야 합니다.

- 기술 스택은 어디에서나 액세스할 수 있어야 합니다. 또한 다양한 플랫폼, 프로그래밍 언어, 도구, 개방형 표준을 지원해야 합니다.

데이터를 최대한 활용함으로써 경쟁 우위를 확보할 수 있는 이유

데이터가 중요하다는 것은 누구나 알고 있지만 데이터에서 혁신적인 비즈니스 및 고객 인사이트를 도출할 수 있는 기업은 거의 없습니다. 데이터를 최대한 활용한다는 것은 무엇을 의미할까요? 그리고 그것은 왜 어려울까요?

데이터를 최대한 활용한다는 것은 데이터를 사용하여 제품 및 운영과 관련된 의사결정을 내릴 수 있음을 의미합니다. 스스로에게 질문을 던져 보세요. 고객의 기대가 어떻게 변화하고 있는지 알고 있나요? 고객 경험을 개선하기 위해 데이터를 사용하고 있나요? 이러한 관점에서 우리 회사의 데이터 엔지니어와 데이터 과학자가 오늘 어떤 일에 가장 시간을 많이 사용하였는지 자문해 보세요.

데이터는 광범위한 시장 진출 관련 결정은 물론 혁신적인 제품 및 사용자 환경을 조성하는 데 필수적입니다. 데이터를 성공적으로 활용하면 경쟁 우위를 점할 수 있습니다. 대부분의 기술 기업과 스타트업이 더 큰 규모로 운영을 현대화하고, 현재와 미래의 데이터 비용을 최대한 활용하며, 조직 차원의 완성도와 의사 결정을 한 차원 끌어올려야 한다는 압박을 받고 있는 것은 바로 이 때문입니다.

그러나 액세스, 스토리지, 일관되지 않은 도구, 규정 준수, 보안과 관련된 여러 문제로 인해 데이터에서 진정한 가치를 찾고 이를 활용하는 것은 쉬운 일이 아닙니다.

기존 시스템과 새로운 시스템을 통합하는 상황을 가정해 보세요. 모든 데이터를 하나의 클라우드에 보관해야 할까요? 아니면 여러 클라우드에 분산해야 할까요? 전통적으로 수직 통합되어 있는 분석 스택을 수평적으로 확장할 수 있는 플랫폼과 호환되도록 하려면 어떻게 현대화해야 할까요?

또는 현재 실시간으로 데이터를 처리하는 대신 일괄 처리하거나 마이크로 배치 처리를 하고 있을 수도 있습니다. 그 결과 조정 시스템 및 예약으로 인해 아키텍처가 더 복잡해지고 경합 및 복원력과 관련해 유지보수가 필요해지게 됩니다. 일괄 아키텍처를 관리하고 유지보수하는 데 따르는 운영 오버헤드가 높은 데도 불구하고 데이터 지연 시간 측면에서도 손해를 피할 수 없습니다.

모든 데이터에 쉽게 액세스할 수 없고 데이터를 실시간 처리하고 분석하는 기능을 확보하지 못하면 불리한 상황에 놓입니다. 최신 기술 스택은 데이터의 규모에 발맞춰 대응하고, 사용 가능한 최신 데이터를 사용하며, 구조화되지 않은 데이터를 통합하고 이해하는 스트리밍 스택이어야 합니다. 이에 따라 업계의 가장 뛰어난 분석팀은 AI 및 ML을 사용해 프로세스를 실험 및 운영함으로써 운영에서 실행으로 초점을 전환하고 있습니다.

혁신에 집중할 수 있도록 데이터를 유용하게 활용하는 방법

데이터를 유용하게 활용한다는 것은 어떤 의미일까요? 고객 경험을 개선하고, 새로운 고객에게 도달하며, 매출을 끌어올리는 데에 활용한다는 의미입니다. 즉 혁신에 활용한다는 뜻입니다. 이러한 결과를 달성하는 데 도움이 되는 데이터 플랫폼을 선택하기 위해서는 두 가지 원칙을 따르는 것이 좋습니다.

원칙 1: 단순성과 확장성

기업은 현재 많은 양의 데이터를 보유하고 있을 것입니다. 데이터가 기하급수적으로 증가하는 가운데 기업은 이 추세에 보조를 맞추면서도 ROI를 유지하거나 개선하고자 합니다. 미래에 보유하게 될 데이터의 양(예: 테라바이트)을 예측하고 그 정도의 양을 처리하도록 시스템을 설계하고 있겠지만, 증가 속도가 예상을 초과하는 경우 전면적인 시스템 마이그레이션을 고려할 수밖에 없습니다. 또는 예상되는 성장에 맞게 확장할 수 있는 데이터 웨어하우스를 선택했지만 처리 요구사항이 증가하여 관리하기가 어려워지고 있을 수 있습니다.

소규모 시스템은 문제가 그보다는 간단하겠지만, 이제는 더 이상 사용하기 쉬운 시스템과 확장성이 높은 시스템 중에서 양자택일을 할 필요가 없습니다. 서버리스 아키텍처를 사용하면 클러스터 관리가 필요 없으며 엄청난 규모의 컴퓨팅과 스토리지 둘 다 처리할 수 있으므로 기술적 역량을 초과하는 규모의 데이터에 대해 걱정할 필요가 없습니다.

단순성과 확장성을 위해서는 서버리스 데이터 플랫폼을 사용하는 것이 좋습니다. 소프트웨어 설치, 클러스터 관리, 쿼리 미세 조정이 필요한 옵션은 고려하지 않는 것이 좋습니다.

원칙 2: 민첩성 및 비용 절감

컴퓨팅과 스토리지를 결합하는 데이터 관리 시스템을 사용하면 컴퓨팅이 필요하지 않은 경우에도 증가하는 데이터 볼륨을 처리하기 위해 컴퓨팅을 확장할 수밖에 없습니다. 이로 인해 비용이 많이 들 수 있으며, 이를 피하기 위해 분석 웨어하우스에 지난 12개월분의 데이터만 저장하는 등 절충을 하게 될 수 있습니다. 당장 필요하지 않아 일부 데이터를 포함하지 않기로 결정했지만, 나중에 데이터가 없어 가설을 테스트할 수 없게 되어 새로운 파이프라인 필요하게 될 수도 있습니다.

또는 여기서 조금 더 나아가 컴퓨팅과 스토리지를 서로 독립적으로 확장하고 비용을 청구하지만, 여전히 직접 클러스터를 설정, 확장, 최적화해야 하는 시스템도 있습니다. 인프라 관리를 최대한 줄이기 위해서는 향상된 안정성, 성능, 기본 제공 데이터 보호 기능이 있는 서버리스, 멀티 클라우드 데이터 웨어하우스(예: BigQuery)가 효과적입니다.

비용 및 관리 외에 민첩성에 대해서도 생각해야 합니다. 데이터가 변경되면 확인하고 대응하는 데 시간이 얼마나 걸리나요? 사용하는 소프트웨어나 도구의 새 버전이 나올 경우 새로운 기능을 수용하는 데 시간이 얼마나 걸리나요? 민첩성을 높이는 방법 중 하나는 손을 댈 필요가 적고 다양한 워크로드에 적용할 수 있는 유연한 도구를 선택하는 것입니다.

Redshift와 같은 시스템에서 쿼리는 효율성을 위해 최적화해야 합니다. 즉, 실험의 여지가 제한되므로 문제가 있을 것으로 예상되는 경우에만 데이터를 추출하고 가져오게 됩니다. 컴퓨팅과 스토리지가 분리되지 않는다는 점과 데이터 웨어하우스를 최적화해야 할 필요성에서 비롯되는 타협은 한 손을 등 뒤로 묶는 것과 다름이 없습니다.

BigQuery와 같은 솔루션을 사용하면 쿼리를 미리 계획하거나 데이터 세트의 색인을 생성할 필요가 없습니다. 분리된 스토리지와 컴퓨팅을 사용하면 쿼리 비용 증가를 염려하지 않고 데이터를 배치할 수 있으며, 데이터 과학자가 클러스터 또는 데이터 웨어하우스의 크기를 걱정할 필요 없이 임시 쿼리를 통해 새로운 아이디어를 실험할 수 있습니다.

단순하고 확장 가능하고 유연하며 비용 효율적인 플랫폼으로 어떻게 혁신을 이룰 수 있는지 살펴보았습니다. 이번에는 이를 달성하는 데 있어 데이터가 어떻게 도움이 되는지 살펴보겠습니다.

실시간으로 데이터 기반 의사 결정

비즈니스 운영 속도는 지속적으로 가속화되고 있습니다. 고객의 기대치도 바뀌었습니다. 과거에는 거래 문제를 조정하거나 반품을 승인하는 데 3일 정도가 걸려도 괜찮았지만 이제는 즉시 답변을 제공해야 합니다. 시의적절하고 더 빠른 의사결정에 대한 필요는 스트리밍에 대한 요구의 증대로 이어지고 있습니다.

실시간으로 데이터를 캡처하고, 비즈니스팀이 지연 시간이 짧은 쿼리를 통해 이 데이터를 사용할 수 있도록 해야 합니다. 또한 낮은 관리 오버헤드로 운영되는 스트리밍 파이프라인이 확장성과 복원력을 갖추도록 해야 합니다. 이것이 비즈니스 속도에 맞춰 실시간으로 대응할 수 있는 유일한 방법입니다. 물론 BigQuery는 스트리밍 데이터 수집을 기본적으로 지원하며, SQL을 사용한 분석을 통해 즉시 이러한 데이터를 사용할 수 있습니다. BigQuery의 사용하기 쉬운 스트리밍 API와 함께 Dataflow를 사용하면 과도한 지출 없이 계절성 워크로드와 급증하는 워크로드를 관리할 수 있습니다.

데이터 사일로 허물기

많은 조직에서 각 팀이 자체 데이터를 소유하면서 여러 부서와 사업부의 데이터를 따로 저장하고, 이로 인해 결국 사일로가 형성됩니다. 즉, 여러 부서에 걸친 분석이 필요한 경우 추출(ETL) 파이프라인을 실행하여 데이터를 가져와 데이터 웨어하우스에 배치하는 등의 방식으로 사일로를 해체할 방법을 찾아야 합니다. 하지만 데이터를 소유한 부서 관점에서는 파이프라인을 유지보수할 인센티브가 거의 없는 경우가 많습니다. 시간이 지나면서 오래된 데이터와 배치된 데이터는 시의성을 잃고 쓸모가 없어지게 됩니다.

오늘날 많은 기업은 조직적 사일로를 넘어 부서별 선호, 기능, 규제 관련 필요에 기반한 멀티 클라우드 전략을 채택했습니다. 이러한 기업은 또한 온프레미스에 존재하는 레거시 데이터 레이크 및 데이터 웨어하우스 투자의 현실에 대처하는 경우가 많습니다. 오늘날의 멀티 클라우드, 하이브리드 클라우드 환경에서는 사일로화된 데이터를 관리하고 액세스하기 위해 새로운 차원의 정교한 기술이 필요합니다.

공용 제어판(데이터 패브릭 또는 데이터 메시라고도 함)이 있는 분산 웨어하우스로 이동하면 여러 부서, 클라우드, 온프레미스 시스템에서 고품질 데이터에 액세스할 수 있는 기능이 향상됩니다. 이렇게 하면 제품 실적 또는 고객 행동과 같은 비즈니스 문제를 해결하고 데이터를 즉석에서 쿼리할 수 있습니다.

BigQuery는 이러한 데이터 메시의 기술적 토대를 제공합니다. 조직 전체에 걸쳐 사용자가 데이터의 소유자에 관계없이 데이터 애셋과 유용한 정보를 관리, 보호, 액세스, 공유할 수 있습니다. 예를 들어 모든 데이터를 BigQuery에 배치할 수 있고 재사용 가능한 함수, 구체화된 뷰를 제공하고 데이터 이동 없이 ML 모델을 학습시킬 수도 있습니다. 즉, 기술과 무관한 영역별 전문가(및 권한을 가진 파트너 및 공급업체)도 스프레드시트, 대시보드와 같은 익숙한 도구를 사용하여 쉽게 SQL에 액세스하고 사용하여 데이터를 쿼리할 수 있습니다.

여기에서 '허브 및 스포크'에 대한 비유가 적절합니다. BigQuery는 데이터가 포함된 허브입니다. 스포크는 보고 도구, 대시보드, ML 모델, 웹 애플리케이션, 추천 시스템 등으로, 모두 데이터를 복사하지 않고도 BigQuery에서 실시간으로 데이터를 읽습니다. 예를 들어 Looker를 통해 데이터를 시각화하고 사용자의 일일 워크플로에 통합할 수 있습니다. 이러한 접근 방식을 통해 데이터의 사용성, 보안, 품질을 동시에 개선할 수 있습니다.

모든 데이터에 대한 액세스 간소화

전통적으로 구조화되지 않은 데이터와 부분적으로 구조화된 데이터는 데이터 레이크에 가장 적합했던 반면, 구조화된 데이터는 데이터 웨어하우스에 가장 적합했습니다. 이 같은 분리로 인해 기술적 사일로가 만들어졌고 형식을 넘나드는 것이 어려워졌습니다. 비용이 절감되고 관리하기가 쉬우므로 모든 데이터를 데이터 레이크에 저장하는 한편, 분석 도구로 유용한 정보를 추출하기 위해 다시 데이터를 웨어하우스로 옮겨야 했습니다.

점점 더 보편화되고 있는 '레이크 하우스'는 이러한 두 환경을 모든 유형의 데이터를 위한 통합 환경으로 결합합니다. BigQuery를 데이터 웨어하우스와 데이터 레이크 모두로 사용할 수 있습니다. BigQuery의 Storage API를 사용하면 스토리지에 직접 액세스하여 일반적으로 데이터 레이크와 관련된 워크로드를 처리할 수 있습니다. 데이터는 BigQuery에 단일 정보 소스로 저장될 수 있으므로 만들고 유지관리해야 하는 사본 수가 줄어듭니다. 이와 함께 데이터를 이동하지 않고도 논리적 뷰에 저장된 SQL 변환을 통해 다운스트림 처리를 수행할 수 있습니다.

사용 편의성이 중요합니다. 30분이나 3시간이 아닌 30초 만에 쿼리 결과를 얻을 수 있다면 의사 결정 시 데이터를 더 많이 활용할 가능성이 높습니다.

AI/ML을 사용하여 더 빠르게 실험하고 워크로드 운영

우리 회사의 데이터 과학자는 실험을 얼마나 빠르게 수행할 수 있나요? 대부분의 경우 실제 사용자를 대상으로 실험을 평가하기 위해서는 개발을 중지하고 모델을 운영해야 합니다. 데이터 과학자들은 이전 데이터를 사용하여 모델을 개발하고 반복 작업한 이후에 모델을 엔지니어에게 전달하고, 엔지니어는 많은 경우 이 모델을 완전히 다시 작성해서 프로덕션 시스템에 통합하고 A/B 테스트를 수행하는 경우가 많습니다. 그런 다음 기다렸다가 모델에 대한 반복 작업을 수행한 후 다시 프로덕션화합니다. 이 사이클 동안 작업은 여러 번 중단되었다가 재개되고 코드는 재작성되며, 이 과정에서 팀 간에 많은 조율이 필요하고 오류가 발생합니다. 이 방식으로 실험하는 데는 오랜 시간이 걸릴 수 있기 때문에 데이터 과학자는 원하는 만큼 많은 실험을 할 수 없습니다. 따라서 프로젝트가 일상적으로 활용될 때까지 걸리는 시간은 고사하고 프로젝트의 소요 시간과 성공 여부조차 예측하기 어렵습니다. 이 한계를 극복하려면 데이터 과학자에게 강력하면서도 익숙한 도구를 제공해야 합니다. Vertex AI Workbench를 사용하면 데이터 과학자가 Jupyter 노트북에서 효과적으로 작업할 수 있지만 학습 속도 향상, 빠른 실험, 빠른 배포를 수행할 수 있습니다.

데이터를 기반으로 한 차별화를 중시한다면 수집 중인 데이터에서 가능한 최대한의 가치를 끌어내야 합니다. 이를 위해서는 데이터 과학팀의 생산성을 최대화하는 한편, 간단한 작업이 너무 오래 걸리거나 어려워 모델을 빌드할 기회를 놓치는 일이 없도록 해야 합니다.

사전 빌드 모델과 로우 코드 모델의 품질은 매우 중요합니다. Vertex AIAutoML은 코드 없는 환경에서 동급 최고의 AI 모델로, 신속한 벤치마킹 및 우선순위 지정이 가능합니다. 자체 데이터에 항목 추출 또는 Vertex AI Matching Engine과 같은 사전 빌드된 모델을 사용하면 데이터로부터의 가치 창출이 크게 가속화됩니다. 더 이상 분류 또는 회귀로 제한되지 않습니다.

데이터 민첩성을 유지하기 위한 핵심은 조기에, 자주 엔드 투 엔드 실험을 수행하는 것입니다. Vertex AI 파이프라인을 통해 이전 정보를 확인하고, 벤치마크 및 엔드포인트와 비교하고 섀도 모델을 통해 A/B 테스트를 진행할 수 있는 실험 기록을 얻을 수 있습니다. 코드가 컨테이너화되므로 개발 시스템과 프로덕션 시스템 간에 동일한 코드를 사용할 수 있습니다. Python을 사용하는 데이터 과학자와 프로덕션 엔지니어는 완전히 캡슐화된 컨테이너를 얻게 됩니다. 두 팀 모두 Vertex AI Prediction로 모델을 운영하여 표준화할 수 있기 때문에 빠르게 진행할 수 있습니다.

도메인 전문가는 BigQuery ML을 사용하여 기존 데이터 과학 도구에 대한 추가 경험 없이 SQL만 사용하는 커스텀 모델을 학습시켜 아이디어의 타당성을 테스트할 수 있습니다. 즉, 프로덕션과 유사한 시스템에서 실험하고 타당성 연구를 몇 달이 아닌 며칠 만에 완료할 수 있습니다. BigQuery ML 모델을 Vertex AI에 배포하여 앞서 살펴본 모든 이점을 얻을 수 있습니다. Looker를 사용하여 모든 데이터 위에 일관된 데이터 모델을 만들고LookML을 사용하여 데이터를 쿼리함으로써 조직 내 모든 사용자가 읽기 쉬운 보고서와 대시보드를 만들어 데이터 패턴을 탐색할 수 있습니다.

프로덕션에서 실질적인 가치를 창출하려면 시스템에서 데이터를 수집, 처리, 제공할 수 있어야 하며 머신러닝이 고객의 상황에 따라 실시간으로 맞춤형 서비스를 제공해야 합니다. 그러나 지속적으로 실행되는 프로덕션 애플리케이션을 위해서는 모델을 지속적으로 재학습시키고, 배포하고, 보안을 확인해야 합니다. 수신되는 데이터에 품질 문제가 없는지 확인하려면 전처리와 검증이 필요하며, 그 다음에는 초매개변수 미세 조정을 동반한 모델 학습 및 특성 추출이 필요합니다.

이와 같은 다단계 ML 워크플로를 손쉽게 조정 및 관리하고 안정적이고 반복적으로 실행하기 위해서는 통합 데이터 과학 및 머신러닝이 필수적입니다. MLOps 도구 및 자동화된 워크플로는 신속한 지속적 배포를 지원하고 프로덕션에 대한 모델의 관리를 간소화합니다. 추상화 레이어와 관계없이 모든 Google AI 제품에 대한 하나의 워크플로 및 어휘가 있으며, 커스텀 모델과 AutoML 모델은 동일한 형식 및 기술 토대를 활용하므로 손쉽게 상호 교환할 수 있습니다.

예를 들어 제한되지 않은 실시간 데이터 스트림에 사기 방지를 위한 이상 감지를 적용하려면 어떻게 해야 할까요? 올바른 접근 방식을 사용하여 샘플 데이터 스트림을 생성하여 일반적인 네트워크 트래픽을 시뮬레이션하고 Pub/Sub로 수집한 다음 DLP를 사용하여 개인 식별 정보(PII)를 마스킹한 후 BigQuery ML K-평균 클러스터링을 사용하는 BigQuery의 이상 감지 모델을 만들고 학습시킵니다. 그런 다음 Dataflow를 사용하여 실시간 감지를 위해 모델을 실시간 데이터에 적용하고 Looker를 사용하여 대시보드, 알림, 작업을 만들어 식별된 이벤트를 처리할 수 있습니다.

다재다능한 데이터 웨어하우스 옵션을 선택하는 것이 중요한 이유

지금까지 BigQuery와 Redshift를 언급하였지만, 그 외에도 데이터 웨어하우스 솔루션은 많이 있습니다. 3가지 주요 클라우드에서 모두 작동하는 다른 데이터 분석 제품(예: Snowflake와 Databricks)도 있습니다. BigQuery를 선택하면 클라우드 종속이 문제가 될까요?

가장 먼저 주목할 것은 BigQuery를 사용하더라도 Google Cloud에 저장된 데이터만 분석할 수 있는 것이 아니라는 점입니다. BigQuery Omni는 Google Cloud Console에서 Amazon S3 및 Azure Blob Storage의 데이터를 원활하게 쿼리할 수 있는 기능을 제공합니다.

하지만 실제로 Snowflake 또는 Databricks를 사용하는 경우 AWS에서 Google Cloud로 또는 그 반대로 전환하는 데 드는 비용은 더 낮습니다. 하지만 다른 데이터 웨어하우스로 이전하는 비용은 어떨까요? Snowflake에서 BigQuery로 전환하거나 Databricks에서 EMR로 전환하는 경우는 어떨까요? 마찬가지로 전환 비용이 있습니다. 시나리오가 다를 뿐입니다.

어느 시나리오에서나 전환 비용은 발생하므로 장기적으로 사용할 수 있는 도구 또는 플랫폼을 선택하는 것이 좋습니다. 특정 플랫폼의 차별화된 기능, 현재 비용, 향후 혁신을 얼마나 앞당길지를 기준으로 선택해야 합니다. Snowflake를 선택한다면 데이터 웨어하우징에 집중하는 기업이 이 부문에서 더 빠른 혁신을 제공할 것이라는 데 베팅하는 것입니다. BigQuery를 선택한다면 다양한 데이터 및 AI 기술을 발명한 것으로 잘 알려진 기업이 앞으로도 플랫폼 전체에서 혁신을 지속할 것이라는 점을 신뢰하는 것입니다.

Google은 혁신적이고 잘 통합된 플랫폼이 혁신의 플라이휠 효과를 더 강화한다고 믿습니다. Google Kubernetes Engine(GKE)과 같은 관리형 서비스 제품을 통해 컨테이너 이미지가 더 빠르게 로드되므로 서버리스 Spark 성능이 향상되고 서버리스 Spark는 BigQuery에서 데이터 작업을 처리할 수 있기 때문에 BigQuery의 성능이 향상됩니다. 개별 제품이 아닌 플랫폼에 투자할 때 플라이휠의 회전 속도는 더 빨라집니다.

확신을 갖고 데이터 마이그레이션 여정을 시작할 수 있는 방법

데이터 마이그레이션에는 얼마나 걸릴까요? 6개월? 2년? 어느 정도의 노력이 필요할까요? 그럴 만한 가치가 있을까요?

보통 온프레미스의 기술 수준이 훨씬 더 높기 때문에 한 클라우드에서 다른 클라우드로 마이그레이션하는 것이 온프레미스에서 클라우드로 마이그레이션하는 것보다 쉬울 수 있지만 이에 상관없이 '얼마나 빠르게 혁신할 수 있는지'와 같은 목표에 집중하세요.

수행하기를 원하지만 지금 하고 있지는 않은 모든 혁신을 검토한 다음 새 프로젝트를 설정하고 그 프로젝트를 수행하는 데 필요한 데이터를 이전하세요. Google Cloud는 이러한 새로운 사용 사례를 구축하고 필요한 데이터 소스를 미러링할 수 있도록 지원합니다. 많은 사용 사례가 온프레미스에서 실행되는 하이브리드 환경이 한동안 유지될 것입니다. 그러나 이러한 사용 사례를 이끄는 것은 온프레미스 환경 또는 다른 클라우드 제공업체로부터 실시간으로 또는 일괄적으로 미러링되는 데이터입니다.

두 번째 고려사항은 비용입니다. 현재 실행 중인 값비싼 Teradata 인스턴스에 대해 생각해 보세요. 많은 고객이 BigQuery로 전환하여 비용을 절반으로 절감하고 있으며 자동화된 평가 도구와 대부분의 스크립트를 변환하는 자동화된 SQL 트랜스파일러 덕분에 마이그레이션이 이전보다 훨씬 쉬워졌습니다. Google은 고객이 실제로는 BigQuery를 다루면서 Teradata를 사용하는 것처럼 만드는 가상화를 제공합니다. 모든 시스템을 내리지 않고도 마이그레이션할 수 있는 방법은 다양합니다. 이러한 마이그레이션 도구를 사용하여 비용이 많이 드는 Teradata 및 Hadoop 워크로드에서 이전할 수 있습니다.

세 번째 고려사항은 SAP, Salesforce 시스템, Oracle과 같은 ERP 시스템을 살펴보는 것입니다. 공급망을 최적화하거나, 리드 스코어링을 수행하거나, 사기를 감지하려는 경우 분석 워크로드를 ERP 시스템에 연결할 수 있는지가 중요합니다. 이러한 시스템에서 데이터를 가져오는 데 사용할 수 있는 서드 파티 커넥터가 있으며, 이를 활용해 클라우드의 데이터를 기반으로 최신 AI 기반 사용 사례를 구축할 수 있습니다.

이러한 작업을 실행하는 순서는 상황에 따라 다릅니다. 스타트업의 경우 혁신을 시작하고 비용 최적화를 수행한 후 마지막으로 기존 파이프라인 및 커넥터를 활용할 수 있습니다. 공급망에 대한 의존도가 큰 비즈니스라면 ERP 커넥터로 시작할 수 있습니다. 세 가지 작업을 수행하는 순서에 상관없이 상당히 많은 양의 중요한 데이터 자산이 클라우드로 이전됩니다. 이제 남은 항목을 살펴보고 이전할 가치가 있는지 여부를 생각해 보세요. 이전할 가치가 없는 경우가 많습니다. 꼭 필요한 워크로드의 70~80%를 이전하고 나면 어려운 결정을 내려야 합니다. 나머지 20~30%를 마이그레이션할 가치가 있을까요? 아니면 다시 만들거나 작업을 다른 방식으로 수행하는 것이 좋을까요? 모든 것을 있는 그대로 클라우드로 옮기는 것은 바람직하지 않습니다. 그렇게 할 경우 데이터 가치에 초점을 맞추기보다는 온프레미스에 존재하는 모든 기술적 부채를 새로운 클라우드에 그대로 복제하게 됩니다.

추가 자료

지금까지 데이터 활용과 그 의미, 그리고 클라우드의 데이터 웨어하우스로 마이그레이션할 때 직면할 수 있는 몇 가지 고려사항에 대해 여러 측면을 알아봤습니다.

Google Cloud를 통해 유용한 정보를 사용하여 중대한 경쟁 우위를 얻고, 비용을 절감하고, 데이터와 AI 사용을 최적화하여 생산성을 높이는 방법을 알아보려면 문의하세요.

추가 리소스

다음 단계로 나아갈 준비가 되셨나요?

Google Cloud가 데이터 및 AI 사용을 최적화하는 데 어떤 도움을 주는지 자세히 알아보세요.
Google Cloud Next '21: 데이터 클라우드: 범용 데이터 플랫폼을 통한 혁신

양식을 작성하시면 연락드리겠습니다. 양식 보기

Google Cloud