BigQuery란, PayPal 사례로 보는 Managed Service for Apache Spark 활용법

데이터 인프라2026년 10월 2일

한마디로

PayPal이 온프레미스 Hadoop을 버리고 BigQuery 연동 기반 Managed Spark로 옮겨서 처리 속도와 SLA를 동시에 끌어올린 사례예요

한눈에

BigQuery는 Google Cloud의 완전관리형 데이터 웨어하우스로, 대용량 데이터를 빠르게 분석하는 데 쓰이는 도구예요. 이번 사례는 BigQuery 자체 업데이트가 아니라, PayPal이 레거시 Hadoop 분석 인프라를 Google의 Managed Service for Apache Spark로 옮기면서 BigQuery, Google Cloud Storage와 네이티브로 연동해 처리 시간 25% 개선, SLA 준수율 30% 상승이라는 성과를 낸 이야기입니다. 온프레미스 분석 인프라의 운영 부담을 클라우드 네이티브 전환으로 해결한 실제 구조를 보여줍니다.

AS-IS: 온프레미스 분석 인프라의 한계

PayPal은 사기 탐지부터 사용자 경험 개선까지 데이터로 거의 모든 걸 움직이는 회사예요. 문제는 인프라 쪽이었습니다. 빠른 성장과 인수합병을 거치면서 데이터 분석 플랫폼이 여러 기술과 솔루션이 온프레미스에 뒤섞인 복잡한 생태계가 돼버렸고, 각 플랫폼이나 통합은 개별 비즈니스 요구는 해결했지만 전체적으로는 운영 부담을 키우고 성능 병목을 만들었습니다. 레거시 Hadoop 플랫폼은 하루 페타바이트 단위 데이터를 처리할 만큼 강력했지만, 피크 시즌 리테일 이벤트나 글로벌 런칭 때 스케일업하려면 몇 달의 계획과 느린 수동 하드웨어 프로비저닝이 필요했고, 속도와 비용 사이에서 타협해야 하는 경우가 잦았다고 합니다.

이번 전환: Managed Service for Apache Spark로 이동

PayPal은 레거시 Hadoop 온프레미스 플랫폼의 워크로드를 Google의 Managed Service for Apache Spark로 옮겼습니다. 선택 이유는 세 가지였어요. 첫째, 클러스터를 몇 분 만에 배포하고 처리량에 따라 탄력적으로 확장할 수 있어서 긴 셋업 시간과 유휴 리소스 비용을 없앴습니다. 둘째, Apache Spark로 표준화하면서 팀 간 일관성을 확보하고 관리형 서비스 활용으로 운영 복잡도를 줄였습니다. 셋째, Google Cloud Storage와 BigQuery 같은 Google Cloud 서비스와 네이티브로 연동돼 데이터 이동이 단순해졌습니다. 여러 플랫폼에 흩어져 있던 워크플로와 배치 작업을 하나의 클라우드 기반 분석 플랫폼으로 통합하면서 데이터 사일로를 줄이고 더 빠르고 풍부한 인사이트를 내는 통합 데이터 기반을 만들었다고 해요.

실무 적용 포인트

성과는 구체적입니다. 핵심 분석 워크로드 처리 시간이 25% 개선됐고 거의 실시간에 가까운 인사이트가 가능해졌어요. 시즌 세일 이벤트 같은 트래픽 급증 상황에서도 SLA 준수율이 30% 상승했고, 툴 통합과 수동 유지보수 감소로 운영 비용도 줄었습니다. 엔지니어들이 장애 대응에 쓰던 시간을 신규 분석 기능 프로토타이핑에 더 쓸 수 있게 된 것도 변화 중 하나예요. 레거시 온프레미스 분석 인프라를 쓰고 있다면 체크해볼 만한 포인트는 이렇습니다.

클러스터 배포와 확장에 몇 달의 수동 프로비저닝이 들어가고 있는지
여러 플랫폼이 뒤섞여 운영 복잡도가 성능 병목으로 이어지고 있는지
데이터 웨어하우스(BigQuery)나 스토리지와의 네이티브 연동이 끊겨 있어 데이터 이동에 공수가 드는지
엔지니어 시간이 장애 대응에 소모되고 신규 기능 개발에 못 쓰이고 있는지

자주 묻는 질문

bigquery 란 무엇인가요

BigQuery는 Google Cloud의 완전관리형 서버리스 데이터 웨어하우스로, 대용량 데이터를 SQL로 빠르게 분석하는 도구예요. 이번 사례에서는 PayPal이 Managed Service for Apache Spark와 네이티브로 연동해 쓰는 핵심 데이터 저장소 역할로 등장합니다.

마케팅 데이터 분석 툴로 BigQuery를 쓰는 이유가 뭔가요

데이터를 한곳에 모아 빠르게 쿼리하고, 다른 Google Cloud 서비스와 연동이 쉬워서 데이터 이동 공수를 줄일 수 있기 때문이에요. PayPal 사례처럼 분석 워크로드를 Spark 같은 처리 엔진과 묶으면 실시간에 가까운 인사이트를 뽑아내는 구조를 만들 수 있습니다.

온프레미스에서 클라우드 분석 인프라로 전환하면 뭐가 좋아지나요

클러스터 배포 시간이 몇 달에서 몇 분으로 줄고 처리량에 따라 탄력적으로 확장할 수 있어요. PayPal은 이 전환으로 처리 시간 25% 개선, SLA 준수율 30% 상승, 운영 비용 절감을 함께 얻었습니다.

Managed Service for Apache Spark와 BigQuery를 같이 쓰면 어떤 점이 다른가요

두 서비스가 네이티브로 연동돼 있어 Google Cloud Storage, BigQuery 사이의 데이터 이동이 별도 파이프라인 없이 단순해진다는 점이 핵심입니다. PayPal은 이 구조로 여러 플랫폼에 흩어져 있던 배치 작업을 하나의 플랫폼으로 통합했어요.

에디터 노트

기술 재플랫폼 자체보다 실험 문화를 같이 바꿨다는 대목이 눈에 띄는데요, 인프라만 바꾼다고 성과가 나오는 게 아니라 팀이 빠르게 테스트하고 튜닝하는 운영 방식까지 바뀌어야 수치로 이어진다는 점을 보여줍니다. 다만 이 글은 Google Cloud가 자사 고객 사례를 소개하는 포스트라, 전환 비용이나 마이그레이션 난이도 같은 반대급부는 다뤄지지 않은 점은 감안해서 봐야 해요.

참고 출처 | 원문 보기

Google Cloud 데이터분석(BigQuery) - PayPal, Managed Service for Apache Spark로 분석 인프라 전환한 이유