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

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

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

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

이 한 장이 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)를 추적하는 것이 거버넌스의 본질이다.

지도에 아직 없는 조각들

위 표는 뼈대만 담았다. DEA-C01 범위에는 단계 사이를 잇거나 틈을 메우는 서비스가 더 있다. 이름을 봤을 때 "어느 칸의 무엇"인지 바로 떠올라야 한다.

• 오케스트레이션은 수집·처리 단계 자체가 아니라 그 단계들을 언제 어떤 순서로 돌릴지 정하는 층이다. Glue 워크플로·트리거도 여기에 속하지만 Glue 작업끼리만 엮을 때 쓴다.
• 본문 표의 Kinesis Data Firehose 는 현재 이름이 Amazon Data Firehose 다. 시험 지문에는 두 표기가 모두 나온다.

닮은 서비스 판별표

이 트랙에서 오답이 되기 쉬운 것은 "둘 다 될 것 같은" 보기다. 갈리는 축을 하나씩만 기억한다.

수집: 원천이 무엇인가

• DMS 는 행을 옮기고 DataSync 는 파일을 옮긴다. "데이터베이스 백업 파일을 S3 로 복사"는 파일 전송이라 DataSync 쪽이고, "데이터베이스의 테이블을 계속 동기화"는 DMS 다.

처리: 얼마나 크고 얼마나 제어해야 하나

분석: 데이터가 어디에 있고 얼마나 자주 묻는가

거버넌스: 무엇을 통제하나

⚠️ 함정: "컬럼 수준 접근 제어"를 S3 버킷 정책이나 IAM 정책만으로 풀려는 보기는 오답이다. S3 는 객체 단위까지만 안다. 객체 안의 컬럼·행을 가려 주는 것은 카탈로그 테이블에 권한을 거는 Lake Formation 이다.

Glue Data Catalog 가 실제로 하는 일

카탈로그는 데이터를 담지 않는다. "이 테이블의 데이터는 S3 의 어느 경로에 있고, 컬럼과 타입은 무엇이며, 어떤 포맷으로 읽어야 하는가"라는 설명서만 가진다.

-- Athena DDL: 데이터는 S3 에 그대로, 카탈로그에 설명서만 등록된다
CREATE EXTERNAL TABLE orders (
  order_id   string,
  amount     double,
  region     string
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://datalake/processed/orders/';
 
-- 새 날짜 폴더가 생기면 파티션을 카탈로그에 알려야 조회된다
ALTER TABLE orders ADD IF NOT EXISTS
  PARTITION (dt = '2026-06-25')
  LOCATION 's3://datalake/processed/orders/dt=2026-06-25/';

• 계층은 데이터베이스 → 테이블 → 파티션이다. 테이블은 S3 경로·포맷(SerDe)·컬럼을, 파티션은 하위 경로를 가리킨다.
• DROP TABLE 로 외부 테이블을 지워도 S3 의 파일은 남는다. 반대로 S3 파일을 지워도 카탈로그 항목은 남아 빈 결과가 나온다.
• 카탈로그를 채우는 방법은 세 가지다.

• 크롤러는 실행할 때마다 비용과 시간이 든다. "새 파일이 들어왔는데 Athena 에서 안 보인다"의 원인은 대개 파티션이 등록되지 않은 것이다.
• MSCK REPAIR TABLE 은 새 파티션을 추가만 하고 오래 걸리며 지워진 파티션을 정리하지 못한다. 파티션 관리는 ALTER TABLE ADD PARTITION·크롤러·파티션 프로젝션이 낫다.

카탈로그 하나를 여러 엔진이 공유한다는 것은 장점이자 책임이다. 누군가 테이블의 컬럼 타입을 바꾸면 Athena 쿼리뿐 아니라 그 테이블을 읽는 Glue 잡·EMR 잡·Redshift Spectrum 외부 스키마가 한꺼번에 영향을 받는다. 그래서 Lake Formation 권한은 데이터 조회 권한뿐 아니라 카탈로그 메타데이터를 고칠 권한도 따로 관리한다.

과금 방식이 서비스 성격을 말해준다

시험은 금액을 묻지 않고 구조를 묻는다. "무엇에 비례해 돈이 나가는가"를 알면 "가장 비용 효율적인" 보기가 가려진다.

• 가끔 쓰면 사용량 과금(Athena, Lambda, 온디맨드/서버리스)이 유리하고, 계속 꽉 채워 쓰면 용량 과금(프로비저닝 클러스터·샤드)이 유리하다. 이 한 줄이 "서버리스 vs 프로비저닝" 문제의 기준이다.

시나리오 → 서비스 판별표

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

📖 용어

• 수집(ingestion) : 원천 시스템의 데이터를 AWS 안으로 들여오는 단계. 원천 종류에 따라 도구가 달라진다.
• CDC(Change Data Capture) : 데이터베이스의 변경 로그를 읽어 바뀐 행만 계속 복제하는 방식.
• 데이터 카탈로그 : 데이터가 어디에 있고 어떤 컬럼·포맷인지 적어 둔 설명서. 데이터 자체는 담지 않는다.
• 크롤러 : 저장소를 훑어 스키마와 파티션을 추론하고 카탈로그에 테이블로 등록해 주는 Glue 기능.
• 외부 테이블 : 데이터는 S3 에 두고 정의만 등록한 테이블. 테이블을 지워도 파일은 남는다.
• 파티션 : S3 경로를 날짜 같은 값으로 나눈 단위. 조건에 맞는 폴더만 읽게 해 스캔량을 줄인다.
• 서버리스 : 서버나 클러스터를 직접 띄우지 않고 쓴 만큼만 내는 방식. Athena·Glue·Lambda 가 해당한다.
• 오케스트레이션 : 여러 작업을 순서·조건·재시도 규칙에 맞춰 자동으로 이어 실행하는 것.
• 데이터 계보(lineage) : 데이터가 어디서 와서 어떤 가공을 거쳐 어디로 갔는지의 이력.
• 애드혹(ad hoc) 쿼리 : 미리 정해 두지 않고 필요할 때 즉석에서 던지는 조회.