[데이터플랫폼] 필요성과 대표 제품 5개의 선택 기준 - 2편

1편에서는 주문상품 한 항목당 한 행을 가진 fact_order_item을 만들고, 날짜·상품 분류별로 집계한 mart_product_daily_sales를 상품팀에 제공했다. 그런데 이 마트를 한 번 만들었다고 일이 끝나지는 않는다. 다음 날에도 갱신해야 하고 뒤늦게 들어온 환불을 반영해야 하며, 작업이 중간에 실패해도 같은 주문을 중복 집계하지 않고 복구해야 한다.

데이터 플랫폼은 데이터를 수집하고 저장·처리해 사용하는 과정과, 그 과정을 지속적으로 운영하는 공통 기반이다. 이 글에서는 분석용 데이터 플랫폼을 중심으로 설명한다. 저장소나 쿼리 엔진 하나보다 넓은 범위이며, 하나의 통합 제품으로 구성할 수도 있고 여러 서비스를 연결해 만들 수도 있다.

데이터가 많아지기 전에도 플랫폼이 필요한 순간이 온다

작은 쇼핑몰에서 담당자 한 명이 주문 파일을 내려받아 매출을 계산한다고 가정해 보자. 데이터가 적고 보고가 가끔 필요하다면 이 방식으로도 충분할 수 있다.

그런데 마케팅팀은 광고별 매출, 운영팀은 취소율, 재무팀은 환불을 반영한 금액을 매일 요청하기 시작한다. 각 팀이 파일을 따로 가져가면 같은 주문을 여러 번 정제하고, 집계 기준도 달라지기 쉽다. 담당자가 자리를 비운 날에는 보고 자체가 멈출 수 있다.

이때 필요한 것은 더 큰 저장소만이 아니다. 같은 원천을 반복해서 수집하는 일, 정제 기준을 공유하는 일, 실패를 복구하는 일을 공통으로 처리해야 한다. 플랫폼의 필요성은 데이터 용량뿐 아니라 반복되는 작업과 협업·운영의 복잡도에서도 생긴다.

그렇다고 모든 팀이 처음부터 대형 통합 제품을 도입해야 하는 것은 아니다. 관리형 데이터베이스, 예약 작업, BI 도구만으로 요구를 충족한다면 그 구성으로 시작할 수 있다. 공통 기반을 만드는 데 드는 비용이 지금 해결하려는 문제보다 커지지 않도록 범위를 정해야 한다.

저장소 밖에서 필요한 기능들

쇼핑몰의 일별 매출 보고를 계속 운영하려면 다음 질문에 답할 수 있어야 한다.

실행 관리는 흔히 오케스트레이션이라고 부른다. 거버넌스는 권한 설정에 더해 데이터의 소유자, 의미, 사용 규칙을 관리하는 일까지 포함한다. 데이터 계보(lineage)는 어떤 원천과 변환을 거쳐 결과가 만들어졌는지의 관계다.

이 기능을 작업마다 따로 구현하면 수집 스크립트에는 재시도 코드를, 집계 스크립트에는 실행 순서와 알림 코드를, 보고서마다 별도의 권한 처리를 붙이게 된다. 마트와 사용자가 늘어날수록 비슷한 운영 코드를 반복해서 만들고 관리해야 한다. 데이터 플랫폼은 여러 데이터 작업이 이 기능을 공통으로 사용하도록 연결한 기반이다.

상품팀 마트에서 플랫폼이 맡는 일

1편의 상품팀 마트를 매일 오전 9시까지 갱신한다고 하자. 담당자가 주문·환불 수집 스크립트를 실행하고, 성공 여부를 확인한 뒤 집계 SQL을 실행해 결과를 전달할 수도 있다. 작업이 하나일 때는 가능하지만 마케팅·재무팀의 마트까지 늘어나면 수집 완료 확인, 실행 순서 관리, 오류 확인을 매번 반복해야 한다.

앞의 기능 표를 이 작업에 적용하면 플랫폼의 역할이 구체적으로 드러난다. 주문·환불 수집, 상세 테이블 갱신, 마트 집계, 품질 검사를 실행 순서와 의존 관계가 있는 파이프라인으로 등록한다. 플랫폼의 실행 관리 기능이 정해진 시각에 이를 시작하고, 앞 단계의 성공을 확인해 다음 단계를 실행하며, 각 단계의 결과를 기록하도록 구성하는 것이다.

화살표는 데이터가 처리·제공되는 흐름이고, 하단은 전체 작업이 함께 사용하는 운영 기능이다. 이 글의 쇼핑몰 구성을 단순화한 도식으로, 각 마트의 계산 규칙은 따로 정하되 실행·관측·권한 관리 기반을 공유한다.

실행 관리와 관측: 담당자가 매번 확인하던 일을 공통으로 처리한다

환불 수집이 실패했다면 해당 수집에 의존하는 마트 갱신을 진행하지 않고 담당자에게 알리도록 설정한다. 담당자는 작업별 로그를 따로 뒤지는 대신 파이프라인의 실행 이력에서 실패한 단계와 입력 범위를 확인하고, 복구에 필요한 단계부터 다시 실행할 수 있다. 같은 실행 관리와 알림 체계를 상품팀·마케팅팀 마트가 함께 사용한다.

뒤늦게 환불이 들어와 과거 주문일의 마트를 고쳐야 할 때도 이 기반을 활용한다. 처리 대상 날짜를 입력으로 받도록 작업을 만들면, 평소의 갱신과 과거 날짜 재처리를 같은 파이프라인에서 수행하고 실행 이력을 남길 수 있다. 앞에서 말한 실행 관리·품질·관측이 마트를 계속 제공하는 운영 수단으로 연결되는 지점이다.

다만 어떤 날짜를 다시 계산할지, 같은 환불을 다시 읽어도 중복 반영하지 않으려면 어떤 키로 갱신할지는 개발자가 정해야 한다. 플랫폼은 재실행 수단과 기록을 제공하고, 작업 코드는 같은 입력을 다시 처리해도 결과가 달라지지 않도록 작성한다. 이를 멱등성이라고 한다.

거버넌스와 활용: 팀마다 데이터 전달 방식을 새로 만들지 않는다

완성된 마트는 카탈로그에 의미·소유자·갱신 기준을 등록하고, 상품팀 그룹에 조회 권한을 부여해 제공할 수 있다. 상품팀은 담당자에게 파일을 요청하는 대신 마트를 찾아 SQL이나 BI 도구로 조회한다. 새 사용자가 들어와도 보고서마다 파일을 복사하는 대신 정해진 그룹과 권한 체계로 접근을 관리한다. 원본 파일을 직접 읽는 경로가 있다면 그 권한도 함께 맞춰야 한다.

이때 데이터 계보가 연결되어 있으면 마트가 어떤 상세 테이블과 원천에서 만들어졌는지 추적할 수 있다. 갱신 상태를 함께 제공하면 사용자는 지금 보는 데이터가 어느 시점까지 반영됐는지도 알 수 있다. 앞의 거버넌스와 활용은 데이터를 찾고, 이해하고, 허용된 범위에서 사용하는 공통 절차가 된다.

결국 플랫폼이 필요한 이유는 마트 하나에서 오류가 생길 수 있기 때문만이 아니다. 마트와 사용자가 늘어날 때마다 실행·복구·권한·데이터 전달 체계를 따로 만들지 않고 재사용하기 위해서다. 저장·연산 자원 위에 이 공통 기능들을 구성하면, 팀은 작업마다 다른 주문·환불 규칙과 분석 모델에 집중할 수 있다. 작은 규모에서는 예약 작업과 데이터베이스 권한만으로 시작할 수도 있으며, 필요한 기능을 직접 연결할지 통합 제품을 사용할지는 운영 범위에 따라 달라진다.

비교할 제품과 기준

이제 비교할 것은 이 공통 기반을 어떤 제품과 서비스로 구성할 것인가다. Databricks, Snowflake, Google BigQuery, Amazon Redshift, Microsoft Fabric이 저장·처리와 운영 기능을 어떻게 제공하고, 어디에 추가 연결이 필요한지 살펴본다. 시장 순위나 성능 순위가 아니라, 서로 다른 구성 방식을 이해하기 위한 다섯 가지 사례다.

이 제품들의 범위가 완전히 같지는 않다. 여러 작업 환경을 한 제품으로 제공하는 경우도 있고, 분석 서비스를 중심으로 주변 서비스를 연결하는 경우도 있다. Snowflake와 BigQuery도 SQL 조회 외의 처리·개발 기능을 제공하므로, 통합 제품과 단일 쿼리 엔진으로 단순히 양분하기는 어렵다. 제품 이름이 아니라 앞의 수집·갱신·검증·제공 흐름을 어디까지 담당하는지를 비교해야 한다.

제품 설명은 2026년 9월 30일 확인한 공식 문서를 기준으로 한다. 아래의 검토 상황과 주의점은 해당 구조를 바탕으로 한 선택 기준이며, 실제 성능을 측정한 결과는 아니다. 기능의 사용 가능 여부는 클라우드·리전·계약·실행 방식에 따라 추가 확인이 필요하다.

Databricks: 데이터 처리와 활용을 같은 기반에 두기

Databricks는 데이터 엔지니어링, SQL 분석, 데이터 과학·ML 작업을 통합하는 플랫폼이다. Spark 기반 처리와 Delta Lake 테이블, Unity Catalog의 거버넌스가 구조를 이해하는 주요 요소다. SQL 사용자를 위한 Databricks SQL도 제공하므로 Spark 코드를 작성하는 사람만을 위한 제품으로 보면 범위를 놓친다. Databricks 개요

쇼핑몰 사례라면 주문·환불을 정제해 상세 테이블을 갱신하는 작업과 상품팀 마트를 계산하는 작업을 Lakeflow Jobs로 순서대로 실행할 수 있다. Unity Catalog에서는 테이블의 권한과 계보를 관리하고, 상품팀은 Databricks SQL로 마트를 조회한다. 여기서 SQL warehouse는 SQL을 실행하는 연산 자원이다. 1편에서 설명한 데이터 웨어하우스 전체와 같은 뜻은 아니다. Lakeflow Jobs, Unity Catalog, SQL 분석 환경

같은 상세 데이터로 클릭 분석이나 추천 모델 개발도 수행한다면, 처리 결과를 작업별 시스템으로 다시 옮기는 수고를 얼마나 줄일 수 있는지가 평가 지점이다.

확인할 것은 운영할 구성의 크기다. 다양한 작업을 지원하는 만큼 테이블 구조, 작업 실행, 접근 권한, 연산 자원을 함께 이해해야 한다. AWS 기준으로 classic compute는 고객 AWS 계정에서, serverless compute는 Databricks가 관리하는 컴퓨팅 영역에서 실행된다. Databricks의 모든 연산이 항상 고객 계정 안에서 일어난다고 가정해서는 안 된다. Databricks의 실행 구조

이미 SQL 보고만으로 요구를 만족시키는 팀이라면, 더 넓은 기능 범위가 실제 이익으로 이어지는지부터 확인하는 편이 좋다.

Snowflake: SQL 분석과 연산 자원의 분리

Snowflake는 저장, 연산, 클라우드 서비스 계층을 분리한다. 쿼리를 처리하는 virtual warehouse는 연산 자원의 묶음이며, 서로 다른 warehouse는 연산 자원을 공유하지 않는다. 적재 작업과 분석팀의 쿼리를 별도 warehouse에 배치하는 구성을 검토할 수 있다. Snowflake 아키텍처

쇼핑몰의 상세·마트 테이블은 데이터베이스와 스키마에 두고, 새벽 갱신 SQL은 처리용 warehouse에서, 상품팀 조회는 분석용 warehouse에서 실행하는 구성을 생각할 수 있다. virtual warehouse는 데이터를 보관하는 논리적 영역이 아니라 연산 자원이다. 같은 마트를 읽기 위해 팀마다 테이블 복사본을 만들 필요는 없다.

SQL 분석을 제공하면서 갱신 작업과 사용자 조회의 연산 자원·사용량을 나누고 싶을 때 비교할 만하다. 다만 연산 분리만으로 모든 병목과 데이터 변경 충돌이 사라지는 것은 아니다. 새벽 작업과 대시보드가 읽는 데이터의 시점은 별도로 관리해야 한다.

Snowflake를 SQL 전용 제품으로 한정하는 것도 정확하지 않다. Snowpark를 통한 Python 등의 처리와 AI·ML 기능을 제공하며, 자체 테이블뿐 아니라 Apache Iceberg 테이블도 지원한다. Snowflake의 처리·테이블 지원

비용을 비교할 때는 warehouse 크기만 보지 말고 실행 시간과 사용 패턴을 함께 봐야 한다. 전체 비용에는 연산 외에 저장과 데이터 전송 등이 포함될 수 있다. Snowflake 비용 구성

BigQuery: 서버 관리를 줄인 분석 환경

BigQuery는 Google Cloud의 완전 관리형 서버리스 데이터 플랫폼이다. 저장과 연산을 분리하며 SQL과 Python 등을 활용한 분석 환경을 제공한다. 사용자가 분석용 서버를 직접 설치하고 유지하는 부담을 줄이는 방향으로 설계되어 있다. BigQuery 개요

쇼핑몰 데이터라면 데이터셋에 주문·환불 테이블을 적재하고, SQL 변환으로 상세 테이블과 상품팀 마트를 만든 뒤 BI 도구에서 조회하는 구성을 생각할 수 있다. 여기서 데이터셋은 테이블·뷰 등을 묶는 논리적 영역이다. 수집 완료를 기다리는 일과 실패한 작업을 재실행하는 일은 선택한 수집·실행 관리 도구와 함께 연결해야 한다.

Google Cloud에 데이터와 운영 기반이 있고 SQL 분석을 중심으로 서비스를 구성한다면 비교 후보다. 서버리스는 분석 서버를 직접 설치·운영하는 부담을 줄여 주지만, 쿼리와 사용량 관리는 여전히 필요하다. 예를 들어 환불이 영향을 준 날짜만 다시 집계하도록 쿼리와 테이블 배치를 설계하면, 매번 전체 이력을 읽는 범위를 줄일 수 있다.

쿼리 연산은 슬롯(slot)이라는 처리 용량 단위로 실행된다. 쿼리 과금에는 처리한 데이터량을 기준으로 하는 온디맨드 방식과, 할당한 슬롯 용량과 시간을 기준으로 하는 용량 기반 방식이 있다. 실제 배치와 대시보드의 처리량·동시 실행·완료 시간을 보고 선택해야 한다. 저장 등 다른 비용도 있으므로 “서버리스이므로 항상 저렴하다”고 결론 낼 수는 없다. BigQuery 슬롯과 과금 모델

Amazon Redshift: AWS 안의 분석 구성을 살피기

Redshift는 AWS의 완전 관리형 데이터 웨어하우스다. 자원을 구성하는 프로비저닝 클러스터와, 자원 준비·확장을 자동화하는 Redshift Serverless를 제공한다. SQL과 BI 도구로 데이터를 분석하는 환경을 구성할 수 있다. Amazon Redshift 개요

쇼핑몰에서는 S3에 수집한 주문·환불 파일을 Redshift 테이블로 적재하고 SQL로 상세 모델과 마트를 구성할 수 있다. 클릭 원본은 S3에 남겨 두고 필요할 때 외부 테이블로 조회하는 구성도 가능하다. Redshift Spectrum은 S3의 파일을 Redshift 테이블로 적재하지 않고 조회하는 기능이다. 이는 1편의 레이크와 웨어하우스를 함께 활용하는 사례이며, 모든 데이터를 한쪽으로 옮겨야 한다는 뜻은 아니다. S3 데이터 조회

이미 AWS에서 원천 데이터와 계정·네트워크를 운영한다면 기존 환경과의 연결까지 포함해 비교할 만하다. 다만 Redshift 도입만으로 수집·의존 관계·재처리 설계가 끝나지는 않는다. 각 작업을 Redshift 기능과 주변 서비스 중 어디에서 담당할지 정해야 한다.

선택의 핵심은 “AWS를 쓰니까 Redshift”에서 한 단계 더 들어가는 데 있다. 분석 부하가 일정한지, 간헐적으로 몰리는지, 운영팀이 어떤 자원 설정을 관리할 수 있는지를 보고 실행 방식을 비교한다. 기존 AWS 환경도 후보를 좁히는 조건이지 최종 답은 아니다.

Microsoft Fabric: 데이터 준비와 Power BI 보고를 연결하기

Microsoft Fabric은 수집·변환·분석·보고 등의 작업을 통합하는 SaaS 플랫폼이다. OneLake라는 공통의 논리적 데이터 레이크를 기반으로 여러 워크로드가 데이터를 사용하며, Data Factory, Data Engineering, Data Warehouse, Power BI 등의 경험을 연결한다. Microsoft Fabric 개요

쇼핑몰 사례라면 Data Factory로 주문·환불을 수집하고, SQL 중심으로 처리할 때는 Warehouse에서 상세 모델과 상품팀 마트를 만드는 구성을 생각할 수 있다. 파일과 Spark 처리를 중심으로 구성한다면 Lakehouse를 활용하는 경로도 있다. 결과는 Power BI의 데이터 모델과 보고서로 연결한다. 같은 플랫폼 안에서도 Warehouse와 Lakehouse 중 어디에 어떤 데이터를 둘지 정하는 설계는 필요하다. Fabric의 Warehouse·Lakehouse 선택 기준

이미 Power BI를 사용하는 조직이라면 보고서뿐 아니라 그 앞의 데이터 준비 과정까지 함께 검토하기 좋다. 데이터 엔지니어가 갱신한 마트를 보고서 작성자가 어떻게 찾고 연결하는지, 집계 기준이 보고서마다 중복 구현되지는 않는지 확인한다.

한 제품 안에 들어 있다고 자원과 라이선스 고민이 없어지지는 않는다. Fabric에는 용량(capacity)과 사용자별 라이선스 구분이 있으며, 콘텐츠를 만들고 공유하고 보는 조건을 함께 확인해야 한다. Fabric 용량과 라이선스

도입 전에는 데이터 처리 작업과 보고서 사용이 겹치는 시간대의 요구를 살펴보는 편이 좋다. 사용자를 초대할 수 있다는 사실만으로 모든 사용자가 추가 조건 없이 모든 콘텐츠를 볼 수 있다고 가정하지 않는다.

제품 이름보다 먼저 정할 다섯 가지

위 제품들은 지원하는 영역이 상당히 겹친다. “SQL은 Snowflake, AI는 Databricks”처럼 한 줄로 나누면 실제 선택에 필요한 조건이 빠진다. 다음 항목을 먼저 구체화하면 비교 범위를 줄일 수 있다.

1. 데이터의 위치와 이동 조건: 원천이 어디에 있고, 다른 리전·클라우드로 복사할 수 있는가? 복사본이 생기면 동기화와 전송 비용도 평가한다.
2. 주요 작업과 사용자: SQL 보고, 대규모 변환, 스트리밍, 모델 학습 중 무엇이 주력인가? 기능 지원뿐 아니라 팀이 익숙한 언어와 도구를 본다.
3. 필요한 갱신·응답 시간: 하루 한 번 갱신이면 되는지, 수분 내 반영해야 하는지, 여러 사용자의 동시 조회를 얼마나 지원해야 하는지 정한다.
4. 운영과 거버넌스: 실패를 복구할 사람, 데이터 품질 기준, 접근 권한, 계보와 감사 요구를 정한다. 도입 후 누가 관리할 수 있는지도 포함한다.
5. 전체 비용과 이전 가능성: 연산·저장·전송·라이선스·운영 공수를 함께 계산한다. 테이블을 내보낼 수 있어도 작업 정의와 권한 정책까지 그대로 이전되는지는 별개다.

비용은 서비스의 시간당 단가만으로 비교하기 어렵다. 같은 입력을 같은 품질과 갱신 주기로 제공하는 데 드는 전체 비용을 비교해야 한다. 초기 적재뿐 아니라 반복 실행, 늦게 도착한 데이터의 재처리, 동시 조회도 평가에 넣는다.

후보를 좁혔다면 같은 입력으로 다음 동작을 확인해 볼 수 있다. 아래는 제품에서 실행한 결과가 아니라, 앞의 쇼핑몰 사례에 적용할 검증 기준이다.

성공한 쿼리의 속도뿐 아니라, 이 흐름을 만드는 데 필요한 서비스 연결과 복구 절차까지 비교해야 운영할 구성을 판단할 수 있다.

1편에서 정한 저장 구조와 마트의 목적은 제품을 골라도 사라지지 않는다. 같은 주문일 기준 매출을 정확히 갱신하고, 실패한 작업을 복구하며, 필요한 사람에게 제때 제공할 수 있는지가 선택의 기준이다.