기준: SAP-C02 시험 가이드오류 제보
Week 9는 "데이터를 어디에 저장하고, 어떻게 처리하고, 누가 무엇을 볼 수 있게 하고, 실시간으로 어떻게 흘려보내는가"를 다뤘다. 개별 서비스를 외우는 것만으로는 SAP 시험을 풀 수 없다. 시험은 항상 "이 제약 조건들(비용·실시간성·운영 부담·이식성·권한 입도) 아래에서 무엇이 최적인가"를 묻고, 비슷해 보이는 두 서비스 중 하나만 모든 조건을 만족시킨다. 오늘은 한 주의 조각들을 하나의 아키텍처 그림으로 꿰고, 헷갈리기 쉬운 경계들을 시나리오로 단련한다.
[수집] Kinesis(KDS/Firehose) / MSK / DMS
↓
[저장] S3 Raw → Curated → Trusted (Parquet + 파티션 + 압축)
↓ │
[카탈로그] Glue Data Catalog (Hive Metastore 호환 — 모든 엔진의 허브)
↓
[처리] Glue(서버리스 ETL) / EMR(풀 Spark·Hadoop) / Athena(SQL CTAS)
↓
[적재] Redshift(RA3·Serverless) / OpenSearch / S3 Curated
↓
[분석] Athena / Redshift(Spectrum·Federated·Sharing·Zero-ETL) / QuickSight / SageMaker
│
[권한] Lake Formation (행·열·셀, LF Tag ABAC, RAM cross-account)
[오케스트] MWAA(Airflow DAG) / Step Functions
[거버넌스] DataZone(마켓플레이스) / Glue Data Quality(DQDL)
이 그림의 핵심은 Glue Data Catalog가 중앙 허브라는 것이다. S3의 같은 Parquet 파일을 Athena가 SQL로, EMR Spark가 변환으로, Redshift Spectrum이 조인으로 모두 "같은 테이블"로 본다. 메타데이터를 한 곳에 통합하고 처리 엔진을 갈아끼우는 이 분리가 레이크하우스의 본질이다.
| 구분 | A | B | 가르는 질문 |
|---|---|---|---|
| 처리 엔진 | Glue(서버리스 ETL) | EMR(풀 클러스터) | 클러스터 운영을 직접 할 것인가, 풀 Hadoop 스택이 필요한가 |
| 질의 위치 | Athena(S3 SQL) | Redshift(DW) | 애드혹 S3 질의인가, 정형 반복 분석·고성능 DW인가 |
| Redshift 외부조회 | Spectrum(S3) | Federated Query(RDS/Aurora) | 데이터가 S3에 있나, 운영 DB에 있나 |
| 운영DB→DW | Federated Query(실시간 직접조회) | Zero-ETL(CDC 자동복제) | 운영 DB에 부하를 줘도 되나(전자는 부하 O) |
| 스트림 | MSK(Kafka 표준) | Kinesis(AWS 독자) | 이식성·기존 Kafka인가, 단순·AWS 네이티브인가 |
| 권한 | Lake Formation(행·열·셀, Tag) | IAM(객체 수준) | 테이블 내부 입도가 필요한가 |
| 오케스트레이션 | MWAA(Airflow DAG, 이식성) | Step Functions(ASL, 서버리스·AWS통합) | 이식성·복잡 로직인가, 운영 0·상시비용 회피인가 |
이 표의 각 행이 시험 한 문제씩이라고 봐도 된다. 두 선택지가 둘 다 "맞아 보이는데" 단 하나의 조건(부하 회피? 이식성? 상시 비용?)이 정답을 가른다.
비용 축: 간헐적·가변 워크로드는 항상 서버리스/탄력 쪽(Glue, Athena, EMR Serverless, Redshift Serverless, MSK Serverless, Step Functions)이고, 꾸준한 대량은 예약·프로비저닝 쪽(RA3 예약, EMR EC2 Spot Fleet)이 싸다. "안 쓸 때 비용 0"이 키워드면 서버리스, "24시간 빽빽한 정상 부하"면 예약.
실시간성 축: 배치(Glue·EMR·Athena CTAS, 분~시간) → 마이크로배치(Glue Streaming·Firehose, 초~분) → 실시간(KDS·MSK, 밀리초~초). 운영 DB의 실시간 분석은 Zero-ETL(수 초~수십 초 CDC)이 ETL 없이 가장 신선하다.
이식성 축: 오픈소스 표준 기반(MSK=Kafka, MWAA=Airflow, EMR=Spark/Hadoop, Iceberg/Hudi/Delta)은 타클라우드·온프렘 이전이 쉽고, AWS 독자(Kinesis, Step Functions, Redshift)는 통합이 깊은 대신 종속된다. 멀티클라우드 전략이 조건이면 표준 쪽으로 기운다.
이 세 축의 트레이드오프는 분산 시스템의 CAP/PACELC와도 닿는다. PACELC는 "파티션(P) 상황에선 가용성(A)과 일관성(C)을, 정상(E) 상황에선 지연(L)과 일관성(C)을 저울질한다"는 확장 정리다. Zero-ETL·CDC 복제는 운영 DB와 분석 DW 사이에 의도적 지연(eventual consistency)을 두어 가용성·격리를 얻는 선택이고, Federated Query는 일관성(최신성)을 위해 운영 DB 부하라는 비용을 치른다. "신선도 vs 부하 격리"가 곧 일관성 vs 가용성 트레이드오프의 데이터 파이프라인 버전이다.
SAP 시험은 데이터 영역을 종종 멀티 계정·멀티 리전 맥락에 얹어 출제한다. 중앙 데이터 레이크를 별도 데이터 계정에 두고 부서 계정이 RAM+Lake Formation으로 공유받는 구조(데이터 메시), Redshift Data Sharing으로 리전·계정을 넘어 데이터를 복제 없이 공유하는 구조, Glue Catalog를 cross-account로 참조하는 구조가 나온다. 여기에 Organizations(계정 그룹)·SCP(가드레일)·Control Tower(계정 프로비저닝)가 거버넌스 골격을 이룬다. 데이터 서비스 하나만 보지 말고 "이게 멀티 계정 조직에서 어떻게 공유·격리·통제되는가"를 함께 떠올리는 습관이 Pro 등급 시나리오를 푸는 열쇠다.
🎯 시나리오: "글로벌 기업이 미국·유럽·아시아 리전에 각각 Redshift를 운영한다. 본사 BI팀이 세 리전의 매출을 복제·이동 없이 통합 분석하고 싶고, 각 리전 클러스터 성능에 영향을 주면 안 된다. 최적은?" — 답은 Redshift Data Sharing(cross-Region/cross-Account). RMS(S3 기반) 덕분에 프로듀서(각 리전)의 데이터를 본사 컨슈머 클러스터가 복사 없이 읽고, 독립 컴퓨팅이라 워크로드가 격리된다. 데이터를 한곳으로 ETL/복제하는 안은 비용·지연·동기화 부담이 크고, Spectrum은 S3 외부 데이터용이라 내부 테이블 공유 메커니즘이 아니다.
⚠️ 함정: "Serverless가 항상 싸다" — Redshift Serverless·EMR Serverless·MSK Serverless 모두 가변 워크로드에선 싸지만, 꾸준한 대량 부하에선 예약/프로비저닝이 더 저렴하다. 강점은 절대 단가가 아니라 "안 쓸 때 0"이라는 탄력성이다.
⚠️ 함정: "Federated Query = Zero-ETL" — 둘 다 "ETL 없이 운영 DB 데이터를 Redshift 분석에". 하지만 Federated Query는 운영 DB에 직접 쿼리해 부하를 주고, Zero-ETL은 CDC로 복제해 부하가 없다. "운영 DB 부하 회피" 한 단어가 정답을 가른다.
"Spectrum이면 Athena도 되는 거 아닌가" — 둘 다 S3를 SQL로 직접 질의하고 Glue Catalog를 공유한다. 하지만 Redshift 내부 테이블과 조인해야 하면 Spectrum, 순수 S3만이면 Athena가 단순하다. "이미 Redshift 사용 중 + S3와 조인"이 Spectrum의 자리다.
"Master/Core도 Spot으로 하면 더 싸다" — EMR에서 Master를 Spot으로 돌리면 중단 시 클러스터 전체가 죽고, Core를 Spot으로 돌리면 HDFS 데이터가 사라진다. Spot은 Task 노드만. 비용 최적은 Task=Spot + Instance Fleets 다중 타입.
Week 9의 한 줄 요약: 데이터를 S3에 표준 포맷(Parquet+파티션)으로 모으고, Glue Catalog로 메타데이터를 통합하고, 워크로드 특성(비용·실시간성·이식성·권한)에 맞는 엔진을 선택한다. 시험은 서비스 이름이 아니라 "이 제약 아래 무엇이 최적인가"를 묻는다. 아래 12개 시나리오로 경계선을 손에 익힌다. 다음 주(Week 10)는 ML/AI 아키텍처 — SageMaker·Bedrock·MLOps로 넘어간다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
Athena 쿼리 비용(S3 스캔량 과금)이 너무 높다. 데이터는 현재 압축 안 된 CSV로 단일 경로에 쌓여 있다. 스캔 비용을 가장 크게 줄이려면?
문제 2
이미 Redshift RA3를 운영 중이고, S3 데이터 레이크의 5년치 과거 주문(Parquet)을 Redshift의 최근 주문 테이블과 한 쿼리에서 조인해야 한다. 과거 데이터를 Redshift로 적재하고 싶지 않다.
문제 3
Aurora PostgreSQL OLTP 데이터를 거의 실시간으로 Redshift에서 분석해야 한다. ETL 파이프라인을 직접 만들고 싶지 않고, 운영 DB에 분석 쿼리 부하를 주고 싶지도 않다.
문제 4
S3 데이터 레이크의 한 테이블에서 분석가 그룹에게 PII 컬럼(주민번호)을 제외한 나머지 컬럼만 노출하고, 동시에 한국 지사 사용자에게는 region='KR' 행만 보여줘야 한다.
문제 5
매일 페타바이트급 로그를 Spark 배치로 2~3시간 처리한다. 데이터는 S3에 영구 보관돼 있다. 비용을 최소화하면서 Spot 중단에도 잡이 안전하려면?
문제 6
하루 몇 번 불규칙하게 도는 Spark 잡이 있다. 클러스터 사이징·노드 관리를 하기 싫고, 안 돌 때 비용을 0에 가깝게 하려면?
문제 7
온프레미스 자체 운영 Kafka를 AWS로 옮긴다. 기존 프로듀서·컨슈머 코드와 Debezium 커넥터를 거의 그대로 쓰고, 추후 다른 클라우드 이전 가능성도 고려한다.
문제 8
ACID 트랜잭션, 스키마 진화, 시간여행(특정 과거 시점 조회)이 필요한 S3 데이터 레이크를 구축한다. 일반 Parquet로는 동시 쓰기·업데이트·삭제 일관성이 보장되지 않는다.
문제 9
수십 개 단계가 의존성을 갖는 데이터 파이프라인을 오케스트레이션한다. 팀은 이미 Airflow를 쓰고, 멀티클라우드 이식성과 복잡한 Python 분기 로직이 필요하다.
문제 10
순수 AWS 환경에서 이벤트 기반·간헐적 워크플로우를 만든다. 워크플로우가 안 돌 때 상시 비용이 발생하지 않기를 원하고, 다수 AWS 서비스를 세밀하게 통합해야 한다.
문제 11
데이터 레이크에 매주 새 테이블이 수십 개 추가된다. 추가될 때마다 수동 권한 부여가 부담이다. 새 테이블에 자동으로 권한이 적용되게 하려면?
문제 12
두 개의 분리된 RA3 클러스터(BI팀·데이터 과학팀)가 같은 매출 데이터를 읽어야 한다. 데이터 복제·동기화 비용을 피하면서 각 팀 쿼리가 서로의 성능에 영향을 주지 않게 격리하려면?
저장 ──► S3 Raw/Curated/Trusted (Parquet + 파티션 + 압축)
테이블포맷 ──► Iceberg/Hudi/Delta (ACID·시간여행·upsert)
카탈로그 ──► Glue Data Catalog (Hive Metastore 호환, 전 엔진 허브)
처리 ──► Glue(서버리스 ETL) / EMR(풀, Task=Spot Fleet) / Athena CTAS
DW ──► Redshift RA3·Serverless (Spectrum·Federated·Sharing·Zero-ETL)
스트림 ──► Kinesis(KDS/Firehose) / MSK(Kafka 표준)·Serverless·Connect
권한 ──► Lake Formation (행·열·셀, LF Tag ABAC, RAM cross-account)
오케스트 ──► MWAA(Airflow DAG, 이식성) / Step Functions(ASL, 서버리스·AWS통합)
거버넌스 ──► DataZone(마켓플레이스) / Glue Data Quality(DQDL)
핵심 가르는 조건 한 줄씩: Glue vs EMR=클러스터 운영, Athena vs Redshift=애드혹 vs DW, Spectrum vs Federated=S3 vs 운영DB, Federated vs Zero-ETL=운영DB 부하, MSK vs Kinesis=이식성 vs 단순, LF vs IAM=행·열 입도, MWAA vs Step Functions=이식성 vs 서버리스.
다음 주(Week 10): ML/AI 아키텍처 — SageMaker·Bedrock·MLOps.