AWS S3/EMR, BigQuery, Synapse로 설계하는 대규모 데이터 분석 아키텍처

분석 플랫폼의 차이는 저장소보다 실행과 운영 방식에서 드러난다

AWS S3/EMR, Google BigQuery, Azure Synapse Analytics는 클라우드 기반 데이터 분석 플랫폼의 대표적인 선택지다. 데이터 레이크와 웨어하우스를 통합하려는 흐름, 서버리스와 저장·컴퓨트 분리형 아키텍처의 확산, 비용 최적화와 거버넌스 강화 요구가 이들 플랫폼의 설계를 관통한다.

AWS에서 S3는 객체 스토리지를 이용해 데이터 레이크를 구현하는 수단이다. 높은 내구성과 저비용 저장소 특성을 갖고, EMR은 Hadoop과 Spark 기반의 배치·머신러닝·ETL 워크로드를 실행하는 관리형 플랫폼으로 동작한다.

BigQuery는 컬럼형 저장과 분산 쿼리 엔진의 MPP 처리를 기반으로 하는 서버리스 엔터프라이즈 데이터 웨어하우스다. 저장소와 컴퓨트가 분리되어 있으며, 쿼리 스캔 바이트를 기준으로 과금한다.

Synapse Analytics는 Dedicated SQL, Serverless SQL, Spark를 함께 제공하는 통합 분석 서비스다. ADLS Gen2 기반 데이터 레이크와 밀접하게 연계되고, Azure AD와 Purview 중심의 거버넌스 체계를 연결할 수 있다.

저장은 객체 스토리지에 두고 계산을 독립적으로 확장한다

세 플랫폼은 객체 스토리지에 데이터를 저장하고, 탄력적으로 확장되는 엔진에서 계산을 수행하는 방향을 공유한다. 이 구조에서는 저장 용량과 계산 자원을 각각 확장할 수 있다.

분석용 데이터는 Parquet, ORC 같은 컬럼형 포맷을 채택하고 Glue, BigQuery Catalog, Purview 같은 카탈로그 또는 메타스토어와 연결한다. ACID 테이블의 선택지는 플랫폼별로 다르다. EMR에서는 Hudi, Delta, Iceberg를 선택할 수 있고, BigQuery는 기본 테이블 MVCC를 제공한다. Synapse에서는 Lakehouse 패턴과 메타데이터 관리가 필요하다.

성능을 다루는 방식도 다르다. EMR은 클러스터 기반으로 실행하며, 오토스케일과 스팟 활용, 캐시, 파일 컴팩션, 파티션 전략이 비용과 성능에 영향을 준다. BigQuery는 서버리스 실행 환경에서 파티션·클러스터링, 저장된 쿼리 결과 재사용, BI Engine 캐시를 활용한다. Synapse는 Spark와 SQL을 함께 쓰며 물리적 분할(Distribution), 결과 캐시, Materialized View를 적용한다.

보안 경계와 데이터 계약을 운영 기준으로 둔다

IAM·KMS 또는 CMEK, VPC·Private Service Connect·프라이빗 엔드포인트는 데이터 암호화와 네트워크 경계를 강화하는 구성 요소다. 데이터 분류와 민감정보 마스킹, 행·열 수준 보안, 감사 로깅, 액세스 가드레일도 함께 적용한다.

플랫폼별 기능만으로 운영 기준이 완성되지는 않는다. 스키마 진화 정책, 프로듀서와 컨슈머의 계약, SLO 기반 데이터 품질 관리가 조직 차원의 표준으로 필요하다.

비용 구조 역시 실행 모델에 따라 달라진다. EMR은 인스턴스 시간 과금이므로 스팟 인스턴스, 세이빙 플랜, 오토스케일을 조합하고 S3 스토리지를 분리해 용량을 유연하게 관리한다. BigQuery는 스토리지와 쿼리를 분리 과금하며 온디맨드(스캔 바이트)와 예약 슬롯 모델 중에서 선택한다. 비용 가시화와 쿼리 거버넌스가 필요하다. Synapse는 전용 SQL DWU와 서버리스 SQL·스파크 Pay-as-you-go를 혼용하며 파이프라인과 엔지니어링을 통합 운영한다.

각 플랫폼에서 구성하는 분석 경로

S3와 EMR로 구성하는 데이터 레이크하우스

원천 데이터는 S3 Landing에 적재하고, EMR Spark와 Hudi 또는 Delta에서 정제·표준화한 뒤 Athena나 Redshift Spectrum으로 조회 레이어를 구성한다. 이 흐름은 스키마 진화, 업서트, 타임트래블을 지원한다.

파일 컴팩션으로 소형 파일 문제를 해소하고 파티션을 조정해야 한다. 스팟 중단에 대비해서는 체크포인트와 idempotent 잡을 설계하고, 데이터 품질 게이트 및 실패 재처리 큐를 마련한다.

BigQuery에서 운영하는 서버리스 웨어하우스

원천 데이터를 스트리밍 또는 배치로 받아 BigQuery 스테이징에 두고, 파티션과 클러스터링 테이블을 모델링한 뒤 BI와 ML에 제공한다. 파티션 프루닝, 머티리얼라이즈드 뷰, 결과 캐시는 스캔 바이트를 줄이는 데 쓰인다.

운영 측면에서는 쿼리 한도와 budget alert로 비용을 제어하고, 데이터 정책 태깅과 DLP를 적용한다.

Synapse의 Spark·SQL 통합 경로

ADLS Gen2에 레이크를 구성하고 Synapse Spark에서 변환한 데이터를 Serverless SQL 또는 Dedicated SQL로 서빙하며 Power BI와 연동한다. 데이터베이스와 테이블 분산 전략, 폴리베이스, 외부 테이블 최적화가 이 경로의 성능 요소다.

Azure AD RBAC와 Private Link로 접근 경계를 구성하고, Purview 카탈로그와 라인리지 관리로 거버넌스를 연결한다.

비용과 지연을 줄이는 설계 조건

파티셔닝과 클러스터링은 데이터 스캔을 7095% 절감할 가능성이 있으며, 스캔 바이트 기반 과금에서는 비용을 선형으로 줄이는 효과가 있다. EMR에서 스팟 인스턴스를 활용하면 컴퓨팅 비용을 4070% 절감할 가능성이 있지만, 스팟 중단 리스크에 대비한 체크포인트가 필수다.

컬럼형 포맷, 압축, 프루닝을 함께 적용하면 쿼리 지연을 30~80% 단축할 가능성이 있다. 머티리얼라이즈드 뷰와 결과 캐시는 반복 조회의 TPS와 동시성을 높인다.

정량 예시는 가정이며 최신 가격 단가 확인이 필요하다. BigQuery 온디맨드에서 원본 1TB를 파티셔닝·필터링 후 150GB만 스캔한다고 가정하면 비용과 시간을 약 85% 절감한다. EMR은 50노드 대신 오토스케일로 피크 80노드, 평시 20노드를 탄력 운영할 경우 월 총 인스턴스 시간을 약 35~50% 절감한다.

플랫폼별 특성 비교

플랫폼	성능	확장성	일관성	안정성	운영 편의
AWS S3/EMR	Spark/Hadoop 기반 대규모 배치·ML 처리 강점. 파일 컴팩션·파티션 최적화 필요.	클러스터·워크로드 단위 탄력 확장. 스팟 활용으로 탄력성 증대.	Hudi/Delta/Iceberg로 ACID 보장. S3 최종 일관성 고려.	멀티 AZ·세이프가드 구성. 스팟 중단 리스크 관리 필요.	높은 유연성 대비 운영 복잡도 존재. IaC·자동화 필수.
Google BigQuery	서버리스 MPP, 컬럼형 저장 최적화. 캐시·MV·BI Engine 가속.	저장/계산 분리형 무제한에 가까운 확장.	MVCC 기반 트랜잭션 일관성. 강한 읽기 일관성 제공.	관리형 서비스로 높은 가용성. 리전·프로젝트 격리 용이.	운영 단순성 높음. 쿼리 거버넌스·코스트 가드레일 필요.
Azure Synapse	Spark+SQL 하이브리드. 분산/인덱스·MV 최적화.	Dedicated/Serverless 혼용 확장. ADLS와 통합 확장성.	외부 테이블+Lakehouse 패턴, ACID는 포맷·엔진 조합에 의존.	Azure AD·네트워크 보안 통합. 파이프라인 내장 안정성.	Azure 생태계 일원화 편의. 리소스/워크스페이스 관리 일관성.

멀티클라우드 경로에 두는 검증과 가드레일

⤢✕

입력에서 처리와 출력으로 이어지는 경로에는 스키마 검증과 재처리 흐름이 필요하다. EMR은 ACID 테이블 포맷으로 스냅샷 격리를 보장하고, BigQuery는 MVCC 기반으로 파티션 스캔을 최소화하며, Synapse는 커밋 실패 시 롤백과 재시도 정책을 적용한다.

쿼리 한도, 예산 알림, idempotent 잡 설계, 사전 검증, 카탈로그 기반 스키마 계약은 플랫폼과 무관하게 적용할 가드레일이다. 제어와 유연성이 우선이면 S3/EMR, 운영 단순성과 서버리스가 우선이면 BigQuery, Azure 생태계 통합이 우선이면 Synapse를 선택할 수 있다. ACID 테이블과 파티션 설계, 코스트 가드레일, 네트워크 프라이빗 경로, 데이터 품질 게이트를 우선 적용하고 단가·서비스 한도·리전 가용성은 공식 문서의 최신 정보를 확인한다.