Day 3 - AWS 데이터 서비스 조감도

AWS의 데이터 관련 서비스는 수십 개다. 처음 콘솔을 열면 Kinesis, Glue, EMR, Redshift, Athena, Lake Formation… 비슷해 보이는 이름들이 쏟아져 막막하다. 하지만 이들을 데이터가 흐르는 순서대로 줄 세우면 지도가 그려진다. 데이터는 항상 수집 → 저장 → 처리 → 분석의 흐름을 따르고, 그 전체를 가로질러 **거버넌스(보안·카탈로그)**가 감싼다.

오늘은 이 5개 카테고리에 어떤 서비스가 어디에 속하는지 지도를 그린다. 개별 서비스의 깊은 디테일은 이후 주차에서 다루고, 오늘은 "이 서비스가 파이프라인의 어느 단계에 있는가"를 머릿속에 배치하는 것이 목표다. 시험 문제의 절반은 "이 시나리오에 맞는 서비스는?"이고, 그 답은 이 지도에서 나온다.

데이터 흐름이 곧 서비스 지도

[수집]      [저장]        [처리]          [분석]
 Kinesis  →  S3       →   Glue        →  Athena
 MSK         Redshift     EMR            Redshift
 DMS         DynamoDB     Lambda         QuickSight
 DataSync                 EMR Serverless OpenSearch
   │            │            │               │
   └────────────┴────────────┴───────────────┘
         [거버넌스] Lake Formation · Glue Catalog · IAM · KMS

이 한 장이 DEA-C01 서비스 지식의 뼈대다. 데이터는 왼쪽(수집)에서 오른쪽(분석)으로 흐르고, 아래의 거버넌스 계층이 전 구간의 권한·카탈로그·암호화를 관장한다.

💡 관련 이론: 이 흐름을 산업 표준 용어로 "데이터 파이프라인의 단계"라 한다. 각 단계는 느슨하게 결합(loosely coupled)되어야 한다. 예를 들어 수집(Kinesis)과 처리(Lambda) 사이에 S3나 스트림 버퍼를 두면, 처리 단계가 느려도 수집이 막히지 않는다. 이 "버퍼로 단계를 분리"하는 패턴이 견고한 파이프라인 설계의 핵심이다.

수집(Ingestion): 데이터를 들여오기

원천에서 AWS로 데이터를 가져오는 입구다. 원천의 성격에 따라 도구가 갈린다.

핵심 구분: 실시간 이벤트 스트림은 Kinesis/MSK, 기존 데이터베이스의 변경을 가져오려면 DMS(CDC 포함), 온프렘 파일 덩어리는 DataSync다.

💡 관련 이론: DMS의 진가는 CDC(Change Data Capture)에 있다. 운영 DB의 트랜잭션 로그를 읽어 "변경분만" 지속적으로 복제하므로, 전체를 매번 덤프하지 않고도 분석 환경을 최신으로 유지한다. OLTP에 부하를 거의 주지 않으면서 OLAP로 데이터를 흘려보내는 표준 방식이다.

저장(Storage): 데이터를 담기

수집한 데이터가 머무는 곳. Day 1의 OLTP/OLAP, 레이크/웨어하우스 구분이 그대로 적용된다.

S3가 모든 것의 중심이다. 데이터레이크의 토대이자, 거의 모든 처리·분석 서비스의 입출력 지점이다. "어디에 저장할까"가 막연하면 일단 S3가 기본값이다.

# S3는 데이터레이크의 토대 — 파티션 구조로 저장
aws s3 cp orders.parquet \
  s3://datalake/raw/orders/year=2026/month=06/day=25/
 
# Athena가 이 S3 위에서 바로 SQL 조회 (별도 적재 불필요)
# Glue Catalog가 스키마를 알고 있으면 즉시 쿼리 가능

💡 관련 이론: S3 스토리지 클래스(Standard, Intelligent-Tiering, Glacier 등)와 수명주기 정책은 비용 최적화의 핵심이다. 자주 안 쓰는 과거 데이터를 자동으로 저렴한 계층으로 옮기는 것이 데이터 엔지니어의 일상 업무이며, 시험에서도 비중 있게 다뤄진다.

처리(Processing): 데이터를 변환하기

원시 데이터를 분석 가능한 형태로 정제·변환하는 엔진들이다. 데이터 양과 작업 성격으로 고른다.

**Glue는 "관리형 ETL의 기본값"**이다. 서버 관리 없이 Spark 기반 변환을 돌리고, 데이터 카탈로그·크롤러·스케줄러가 통합돼 있다. EMR은 더 큰 제어와 규모가 필요하거나 기존 Hadoop/Spark 코드를 그대로 옮길 때 쓴다. Lambda는 작은 단위의 이벤트 기반 변환(파일 하나 도착 시 가공 등)에 적합하다.

💡 관련 이론: Glue Crawler는 S3 데이터를 스캔해 스키마를 자동 추론하고 Glue Data Catalog에 테이블로 등록한다. 이 카탈로그가 Athena·Redshift Spectrum·EMR이 공유하는 "공통 메타데이터 사전"이 된다. 즉 한 번 카탈로그에 등록하면 여러 분석 엔진이 같은 정의로 같은 데이터를 본다.

분석(Analytics): 데이터에서 답 얻기

정제된 데이터에 질문을 던지는 소비 계층이다.

Athena는 S3에 적재된 데이터를 옮기지 않고 그 자리에서 SQL로 조회하는 서버리스 도구다. 인프라가 없고 스캔한 데이터량만큼 과금돼, 가끔 하는 애드혹 분석에 이상적이다. 자주·빠르게 대규모로 조회한다면 데이터를 Redshift에 적재한다. 최종 결과를 사람이 보는 대시보드로 만들려면 QuickSight다.

거버넌스(Governance): 전 구간을 통제하기

수집부터 분석까지 모든 단계를 가로지르는 보안·카탈로그·권한 계층이다.

Lake Formation은 S3 데이터레이크에 "테이블·컬럼·행 단위"의 세밀한 권한을 부여한다. IAM이 "이 사람이 이 S3 버킷에 접근 가능한가"라면, Lake Formation은 "이 사람이 이 테이블의 이 컬럼까지 볼 수 있는가"를 통제한다.

💡 관련 이론: 거버넌스가 별도 카테고리인 이유는, 데이터 파이프라인에서 보안·권한·계보(lineage)는 한 단계의 문제가 아니라 전 구간을 관통하는 횡단 관심사(cross-cutting concern)이기 때문이다. 누가 어떤 데이터에 접근했고, 그 데이터가 어디서 와서 어디로 갔는지(data lineage)를 추적하는 것이 거버넌스의 본질이다.

정리하며

오늘 그린 지도의 핵심은 하나다. AWS 데이터 서비스는 수집 → 저장 → 처리 → 분석의 흐름에 배치되고, 거버넌스가 그 전체를 감싼다. 막연한 시나리오 문제를 만나면 "이건 흐름의 어느 단계인가"를 먼저 묻고, 그 단계의 후보 서비스 중에서 "실시간이냐 배치냐, 관리형이냐 제어냐, 양이 얼마냐"로 좁히면 된다.

다음 글에서는 이 파이프라인을 흐르는 데이터가 어떤 "형태"로 저장되는지 — CSV·JSON·Parquet·ORC·Avro와 컬럼형 vs 행형, 스키마 진화 — 를 본다.