Athena 핵심 정리 — SAA-C03 분석·ML 한 번에

이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 열 번째 편입니다. 분석·ML 단원을 처음 펼치면 — Athena·Redshift·EMR·Glue·Lake Formation·OpenSearch·Kinesis Data Analytics·MSK·QuickSight, 거기에 SageMaker와 Rekognition·Transcribe·Polly·Translate·Lex·Connect·Comprehend·Forecast·Personalize·Textract·Kendra까지 — 이름이 너무 많아 멘붕이 옵니다. "이걸 다 외워야 하나?" 싶은 마음이 들죠.

다행히 이 단원은 시험에서 점수 따기 가장 좋은 영역입니다. 이유는 간단해요. 각 서비스가 "딱 한 가지 일"만 합니다. Athena는 S3에 SQL을 그대로 던지는 일, Redshift는 페타바이트 분석, Polly는 글자→소리, Transcribe는 소리→글자 — 입력과 출력이 명확해서 시나리오의 한두 단어만 잡으면 정답이 떨어져요. 특히 Athena는 비용 절감 4총사 패턴이 거의 매번 출제되니 이번 편의 출발점으로 가장 적합합니다.

그러니 이번 글은 각 서비스가 어디에 앉아 있는지를 큰 그림으로 잡고 가는 게 목표입니다. 수집 → 저장 → 처리 → 분석 → 시각화 → ML 흐름을 따라 한 명씩 자리에 앉혀 보면, 뒤에 시나리오가 어떻게 꼬여 나와도 머리에 그림이 그려집니다. AWS 공식 Athena 사용자 가이드에서 최신 기능을 함께 확인해 두면 시험 막바지에 큰 힘이 됩니다.

왜 이 단원이 처음엔 어렵게 느껴질까요

처음 강의를 들을 때 이 단원이 어렵게 느껴지는 이유는 두 가지예요.

첫째, 이름이 너무 비슷비슷합니다. Kinesis Data Streams·Data Firehose·Data Analytics가 다 "Kinesis"고, OpenSearch는 옛날 Elasticsearch고, Managed Service for Apache Flink는 옛 Kinesis Data Analytics for Flink였고요. 이름 변천사만 따라가도 머리가 어지러워집니다.

둘째, "이게 왜 따로 있어야 하나" 가 안 보여요. Athena도 SQL 돌리고 Redshift도 SQL 돌리는데 왜 둘이 필요한지, EMR은 또 어디 끼어드는지 — 처음엔 다 거기서 거기 같죠.

해결법은 한 가지예요. 각 서비스를 "한 줄짜리 자기소개"로 줄이는 것. 이 글에서는 매 서비스마다 첫 문단에서 한 줄 자기소개를 먼저 박고, 그다음에 디테일을 풀어 갑니다. 외우려 하지 말고, 자기소개 한 줄과 자리만 머리에 들어와도 시험장에서 다 됩니다.

Athena — S3에 SQL 던지면 끝

가장 먼저 자리에 앉힐 도구는 Amazon Athena 예요. 한 줄 자기소개는 — "S3에 쌓여 있는 데이터에 SQL을 그대로 던지는 서버리스 쿼리 서비스". 이게 전부입니다.

회사 비유로 풀면 — 사무실 창고(S3)에 박스가 잔뜩 쌓여 있는데, 박스를 옮기지 않고 그 자리에서 "빨간색 박스만 꺼내 줘" 같은 질문을 던지면 답이 나오는 시스템이에요. 클러스터를 띄울 필요도 없고, 쿼리 던질 때마다 스캔한 데이터 양(TB) 으로 과금합니다. 내부 엔진은 Presto고요.

처음 사용할 때 단 하나 미리 해 둘 일 — 결과 저장용 S3 버킷 위치를 콘솔에 등록해 두는 것. 이걸 안 하면 쿼리 자체가 안 돌아가요.

Athena가 시험 단골인 이유는 비용 절감 4총사 때문입니다. 이건 거의 매번 한 문제씩 나와요.

1. 열 기반(Columnar) 포맷 사용 — Apache Parquet 또는 ORC. CSV로 두면 쿼리할 때마다 모든 컬럼을 다 스캔해야 하는데, Parquet은 필요한 컬럼만 읽어서 스캔량이 극적으로 줄어요. CSV → Parquet 변환은 AWS Glue가 가장 흔한 길입니다.
2. 데이터 압축 — 스캔할 바이트 자체를 줄이는 가장 직관적인 방법.
3. 파티셔닝(Partitioning) — s3://bucket/year=2026/month=05/day=01/ 식으로 폴더를 논리적으로 자르면, "2026년 5월 데이터만"이라는 쿼리가 다른 폴더는 아예 안 읽고 넘어갑니다.
4. 파일 크기 최적화 — 128MB 이상 큰 파일이 권장. 작은 파일이 많으면 메타데이터 오버헤드가 커집니다.

여기서 시험 함정이 하나 있어요. DDL의 LOCATION 절은 반드시 슬래시(/)로 끝나야 합니다. s3://bucket/data 가 아니라 s3://bucket/data/ 가 맞아요. 이걸 빼먹어서 "쿼리가 안 돌아간다"는 시나리오가 가끔 나옵니다.

Athena의 한 가지 확장 기능이 페더레이션 쿼리(Federated Queries) 예요. Lambda로 만든 데이터 소스 커넥터를 통해 S3 외 — CloudWatch Logs, DynamoDB, RDS, Aurora, Redshift, ElastiCache, DocumentDB, 온프레미스 DB — 까지 SQL을 그대로 던질 수 있습니다. 시험에서 "여러 소스를 SQL 하나로 묶어 분석" 키워드라면 이 답이에요.

대표 사용 사례는 거의 항상 AWS 서비스 로그 분석입니다. VPC Flow Logs, ALB 액세스 로그, CloudTrail 로그, S3 서버 액세스 로그 — 이런 걸 S3에 떨궈두고 Athena로 SQL 돌리는 게 표준 패턴이고, 결과를 QuickSight로 받아 대시보드를 만드는 조합이 거의 매번 보기에 등장해요.

Redshift — 대형 분석 창고

Amazon Redshift 의 한 줄 자기소개는 — "PostgreSQL 기반의 페타바이트급 데이터 웨어하우스". 회사 비유로 풀면 — Athena가 "창고에 SQL 던지는" 거라면, Redshift는 창고 옆에 따로 지은 분석 전용 대형 창고예요. 데이터를 이 창고로 옮겨 와서 본격적으로 분석합니다.

핵심 키워드 다섯 — OLAP(분석 처리, OLTP 아님), 페타바이트 규모, MPP(Massively Parallel Processing, 병렬 쿼리 엔진), 열(Column) 기반 스토리지, BI 도구 통합(QuickSight·Tableau).

여기서 시험 함정 하나 — "Redshift를 트랜잭션 처리에 쓰는 게 좋은가?" 답은 절대 아니오. Redshift는 OLAP, OLTP 아닙니다. 트랜잭션은 RDS·Aurora 자리예요.

노드 구성

Redshift 클러스터는 두 종류의 노드로 돌아갑니다.

• 리더 노드(Leader Node) — 클라이언트 통신, 쿼리 계획 수립, 결과 집계
• 컴퓨팅 노드(Compute Node) — 실제 쿼리를 병렬로 실행, 결과를 리더 노드로 반환

이 노드를 직접 골라 띄우는 게 프로비저닝(Provisioned) 클러스터, AWS가 알아서 확장·관리하는 게 Serverless 모드예요. 프로비저닝 모드에서는 Reserved Instance로 비용 절감이 가능합니다.

백업과 DR

여기가 시험에 자주 나와요. Redshift는 기본이 단일 AZ(일부 클러스터만 Multi-AZ)이고, 스냅샷이 S3에 증분 방식으로 저장됩니다.

• 자동 스냅샷 — 8시간마다 또는 5GB 변경마다
• 수동 스냅샷 — 삭제 전까지 보존
• 교차 리전 스냅샷 복사(Cross-Region Snapshot Copy) — 다른 리전에 자동 복사 → 리전 장애 시 복구

여기서 시험 함정이 하나 있어요. "Multi-AZ가 리전 장애를 막아주나?" — 아닙니다. Multi-AZ는 한 리전 안 AZ 장애만 커버해요. 리전 간 DR은 무조건 교차 리전 스냅샷 복사입니다.

데이터 수집 방식

방법	설명
Kinesis Data Firehose	데이터를 S3에 쓴 후 Redshift가 자동 COPY
S3 → COPY 명령 (권장)	S3에 데이터 올린 뒤 대량 복사. Enhanced VPC Routing 활성화 시 VPC 내부 경로 사용 → 퍼블릭 인터넷 우회
JDBC 드라이버	앱에서 직접 삽입. 반드시 Bulk Insert (단건 삽입은 매우 비효율)

Enhanced VPC Routing — 시험에서 "S3↔Redshift 데이터가 퍼블릭 인터넷을 거치면 안 됨" 같은 보안 요건이 나오면 떠올려야 할 키워드예요. 활성화하면 데이터 이동이 VPC 내부 프라이빗 네트워크로만 흘러갑니다.

Redshift Spectrum — Athena와 헷갈리는 단골

여기서 시험 함정이 하나 있어요. Redshift Spectrum과 Athena가 묘하게 비슷해 보이거든요. 차이를 한 줄로 정리하면 — 클러스터가 필요하냐 아니냐입니다.

• Athena — 클러스터 없이 완전 서버리스. S3 데이터에 즉시 SQL.
• Redshift Spectrum — 데이터를 Redshift로 로드하지 않고 S3 데이터를 직접 쿼리하지만, 그러려면 실행 중인 Redshift 클러스터가 있어야 함. 수천 개의 Spectrum 노드가 S3를 읽어 집계하고, 결과만 클러스터로 돌려주는 구조.

키워드로 정리 — "S3 데이터에 서버 없이 즉시 SQL" → Athena / "Redshift 안에서 S3 데이터까지 같이 쿼리" → Spectrum.

OpenSearch — 부분 일치 검색의 정석

Amazon OpenSearch Service 한 줄 자기소개는 — "모든 필드에 대한 검색과 부분 일치(Partial Match) 검색이 가능한 검색 엔진". 옛 이름은 Amazon Elasticsearch였는데 라이선스 문제로 OpenSearch로 바뀌었어요. 본질은 같습니다.

회사 비유로 — DynamoDB가 "사번 번호로 직원 정보 빠르게 꺼내는 시스템"이라면, OpenSearch는 "직원 이름 일부만 입력해도 비슷한 사람 다 찾아주는 검색대" 같은 거예요. 키 기반 정확 조회와 부분 일치 검색은 사실 다른 일이라, 메인 DB 옆에 OpenSearch를 보조 검색 인덱스로 붙이는 게 표준 패턴입니다.

자체 쿼리 언어를 쓰지만 플러그인으로 SQL 호환성도 켤 수 있고, Cognito·IAM 통합과 저장/전송 암호화가 모두 지원돼요. 시각화는 OpenSearch Dashboards(구 Kibana). 배포는 Managed Cluster 또는 Serverless 둘 중에 골라요.

아키텍처 패턴 5종 — 시험 출제 1순위

여기서 시험 출제 1순위는 OpenSearch와 다른 서비스가 만나는 아키텍처 패턴입니다. 이 표는 통째로 외워두면 한 문제는 무조건 풀려요.

패턴	흐름
DynamoDB 검색 보완	DynamoDB → DynamoDB Streams → Lambda → OpenSearch (실시간 인덱싱)
CloudWatch Logs 실시간	CloudWatch Logs 구독 필터 → 관리형 Lambda → OpenSearch
CloudWatch Logs 거의 실시간	CloudWatch Logs 구독 필터 → Kinesis Data Firehose → OpenSearch
Kinesis 거의 실시간	Kinesis Data Firehose → (선택: Lambda 변환) → OpenSearch
Kinesis 실시간	Kinesis Data Streams → 사용자 지정 Lambda → OpenSearch

대표 활용 — DynamoDB는 키 기반 빠른 조회는 잘하지만 부분 일치 검색은 약합니다. 그래서 OpenSearch에서 'Item ID'를 찾고, 그 ID로 DynamoDB에서 전체 데이터를 가져오는 분담 구조가 표준이에요. 이 시나리오가 시험에 나오면 답은 무조건 위 첫 번째 패턴입니다.

EMR — Hadoop·Spark 빅데이터 클러스터

Amazon EMR(Elastic MapReduce) 한 줄 자기소개는 — "Hadoop·Spark·HBase·Presto·Flink 같은 빅데이터 프레임워크를 EC2 위에 클러스터로 띄워주는 관리형 서비스". 수백 개 인스턴스로 확장하고 Auto Scaling도 지원합니다.

여기서 시험에 자주 묻는 게 노드 유형과 인스턴스 구매 옵션의 조합이에요. 표 한 번에 풀어 갑니다.

노드	역할	종료 가능?
마스터 노드(Master Node)	클러스터 관리·조정·모니터링	절대 종료 X (종료되면 클러스터 전체 영향)
코어 노드(Core Node)	작업 실행 + 데이터 저장	종료 X (데이터 유실 위험)
작업 노드(Task Node)	작업 실행만 (데이터 저장 없음, Optional)	종료 가능 (데이터 유실 없음)

여기서 구매 옵션이 자연스럽게 따라옵니다.

노드	권장 구매 옵션	이유
마스터 노드	온디맨드 / Reserved	종료되면 클러스터 전체 멈춤
코어 노드	온디맨드 / Reserved	데이터 저장하므로 중단 불가
작업 노드	스팟 인스턴스	데이터 미저장, 중단돼도 무방 → 비용 절감

여기서 시험 함정이 하나 있어요. "EMR 비용 절감 + 데이터 유실 없이"가 키워드면 답은 작업 노드만 스팟입니다. "마스터·코어도 스팟" 같은 보기는 무조건 오답이에요.

배포 모델도 둘로 갈리는데 — 항상 돌아가는 장기 실행(Long-running) 클러스터는 Reserved를, 분석 끝나면 즉시 해체하는 일시적(Transient) 클러스터는 주기 배치 작업에서 비용 절감용으로 씁니다.

Glue — 서버리스 ETL과 메타데이터 카탈로그

AWS Glue 한 줄 자기소개는 — "분석 전 단계에서 데이터를 정리·변환하는 완전 관리형 서버리스 ETL". ETL은 Extract(추출)·Transform(변환)·Load(적재)의 약자예요.

가장 흔한 사용 사례 셋:

• CSV → Parquet 변환 — Athena로 쿼리할 데이터를 Parquet으로 미리 바꿔두면 비용·성능 둘 다 잡힘
• Redshift 로드 — S3·RDS 데이터를 추출·변환해 Redshift로 적재
• 자동화 파이프라인 — S3에 파일이 들어오면 Lambda/EventBridge가 Glue ETL을 트리거

Glue Data Catalog와 Crawler

ETL 본체보다 시험에 자주 나오는 게 Data Catalog와 Crawler 입니다.

• Crawler — S3·RDS·DynamoDB·온프레미스 JDBC 등을 크롤링해 메타데이터 수집
• Data Catalog — 크롤러가 모은 테이블·컬럼·데이터 유형을 저장하는 중앙 집중식 메타데이터 저장소

이 카탈로그가 핵심인 이유 — Athena·Redshift Spectrum·EMR이 백그라운드에서 이 Data Catalog를 그대로 활용합니다. 한 번 만들어 두면 여러 분석 도구가 같은 메타데이터를 보게 되는 거예요. 회사로 치면 — 도서관 사서가 책 목록을 한 번 만들어 두면, 여러 부서에서 같은 목록으로 검색할 수 있는 식.

기능 키워드 4개

시험에 종종 등장하는 Glue 기능 4개:

기능	설명
Job Bookmarks	이전 ETL이 처리한 데이터를 추적해서 새 데이터만 처리 (중복 방지)
Glue DataBrew	코딩 없이 250+ 사전 변환으로 시각적으로 데이터 정리·정규화
Glue Studio	ETL 작업을 GUI로 만들고 모니터링
Glue Streaming ETL	Apache Spark Structured Streaming 기반, Kinesis Streams·Kafka·MSK에서 실시간 ETL

시험 키워드 — "새 데이터만, 중복 방지" → Job Bookmarks / "코딩 없이 데이터 정제" → DataBrew.

Lake Formation — 데이터 레이크 + 행/열 보안

AWS Lake Formation 한 줄 자기소개는 — "데이터 레이크를 며칠 만에 구축·관리·보호하는 완전 관리형 서비스". 내부적으로는 Glue 위에 얹혀 있어요(Glue Crawler·Catalog·ETL 활용).

Lake Formation만의 강점 두 가지:

• 중앙 집중식 보안 관리 — S3 정책·IAM·각 분석 도구(Athena·QuickSight 등)의 권한을 한 곳에서 통합
• 행·열 수준 세밀한 액세스 제어 — 사용자는 자기가 볼 권한이 있는 행/열만 접근

회사 비유로 — 부서별 자료 창고가 흩어져 있는데, "마케팅팀은 어느 행까지, 재무팀은 어느 열까지" 같은 권한을 한 곳에서 일괄 관리해 주는 시스템이에요.

기능 키워드:

• 블루프린트(Blueprints) — 내장 템플릿으로 S3·온프레 RDB·NoSQL → 중앙 S3 데이터 레이크 마이그레이션 자동화
• 연동 서비스 — Athena·Redshift·EMR·QuickSight·Apache Spark

> 시험 키워드 — "데이터 레이크 + 중앙 집중식 권한 + 행/열 수준 액세스 제어" → Lake Formation.

Kinesis Data Analytics — 실시간 스트림 처리

Amazon Managed Service for Apache Flink (구 Kinesis Data Analytics for Apache Flink) 한 줄 자기소개는 — "실시간 데이터 스트림을 처리·변환하는 관리형 Flink 서비스". 시험에 옛 이름으로도 나오니 둘 다 알아둡니다. Java·SQL·Scala를 지원해요.

AWS 관리형이라서 좋은 점은 — 기반 인프라 자동 프로비저닝, 병렬 컴퓨팅 + Auto Scaling, 체크포인트(Checkpoint)와 스냅샷(Snapshot) 으로 애플리케이션 상태 백업.

여기서 시험 함정이 하나 있어요. Apache Flink는 Kinesis Data Firehose에서 직접 못 읽습니다. Firehose는 "전달 전용" 서비스라 입력 소스로 못 써요. Flink가 직접 읽을 수 있는 건 Kinesis Data Streams와 MSK(Apache Kafka) 둘뿐입니다.

소스	Flink 직접 읽기
Kinesis Data Streams	가능
Amazon MSK (Apache Kafka)	가능
Kinesis Data Firehose	불가

세 가지 옵션이 있어요.

1. Apache Flink 스트리밍 애플리케이션 — Java/Scala 코드 업로드, 복잡한 윈도우·상태 저장 처리에 적합
2. Kinesis Data Analytics Studio — Zeppelin 노트북 기반 대화형 분석, 컴파일 없이 즉각 쿼리·시각화 (AWS 권장)
3. SQL 애플리케이션 (Legacy) — 표준 SQL 필터링, Firehose에서도 읽기 가능 (옵션 1·2와 다른 점이에요)

MSK — 관리형 Apache Kafka

Amazon MSK(Managed Streaming for Apache Kafka) 한 줄 자기소개는 — "AWS가 관리해 주는 Apache Kafka 클러스터". VPC 내 최대 3개 AZ 분산 + 장애 자동 복구 + EBS 볼륨에 데이터 저장(원하는 기간 보관, 1년 이상 무제한 가능)이에요. 인스턴스 관리 없이 자동 스케일링되는 MSK Serverless 옵션도 있고, Zookeeper도 자동 관리됩니다.

MSK 데이터를 소비하는 옵션도 다양해요 — Kinesis Data Analytics(Flink), AWS Glue 스트리밍 ETL, Lambda, 또는 EC2/ECS/EKS에 직접 배포한 Kafka Consumer.

Kinesis vs MSK — 시험 단골 비교

이 둘이 헷갈리지 않게 표로 한 번 정리합니다.

항목	Kinesis Data Streams	MSK (Apache Kafka)
메시지 크기	최대 1MB	기본 1MB, 10MB+ 구성 가능
데이터 구조	샤드(Shard)	토픽(Topic) + 파티션(Partition)
확장 방식	샤드 분할(Splitting) / 병합(Merging)	파티션 추가 (제거 X)
보관 기간	최대 365일	무제한 (EBS 용량)
전송 중 암호화	항상 TLS	Plaintext 또는 TLS 선택
오픈 소스 호환	없음	Apache Kafka 호환

시험 키워드 — "메시지 1MB 초과" 또는 "Kafka 호환·오픈 소스 도구" → MSK / 그 외 일반 실시간 스트리밍 → Kinesis.

QuickSight — BI 시각화의 정석

Amazon QuickSight 한 줄 자기소개는 — "서버리스 BI(Business Intelligence) 서비스". 대화형 대시보드, 데이터 시각화, 인사이트 도출 — 세션당 과금이고, 웹사이트·앱에 임베딩 가능합니다.

SPICE 엔진

핵심 단어가 SPICE 엔진이에요. 풀어 쓰면 Super-fast, Parallel, In-memory Calculation Engine — 초고속 병렬 인메모리 연산 엔진입니다.

여기서 시험 함정이 하나 있어요. SPICE는 데이터를 QuickSight로 직접 Import할 때만 작동합니다. 외부 DB에 Direct Query(직접 연결) 모드로 붙여 두면 SPICE 가속이 안 돼요. "QuickSight 성능이 안 나온다"는 시나리오의 답이 종종 "Direct Query 대신 Import로 바꿔라" 입니다.

데이터 소스와 단골 조합

데이터 소스는 광범위 — RDS·Aurora·Redshift·S3·Athena·OpenSearch·Timestream 같은 AWS 서비스 + Salesforce·Jira·Teradata·JDBC + Excel·CSV·JSON·로그 파일까지. 시험 단골 조합은 두 패턴이에요.

• S3 + Athena + QuickSight — 로그 분석 표준
• Redshift + QuickSight — 대규모 OLAP 시각화

보안 — Column-Level Security(CLS)

보안 면에서 짚을 게 두 가지:

• Column-Level Security (CLS) — 특정 열 접근 제한. Enterprise 에디션에서만 지원. 시험에 "QuickSight에서 특정 열만 차단"이 키워드면 무조건 Enterprise CLS.
• QuickSight 사용자·그룹은 IAM 사용자와 별개예요. Standard는 사용자 단위, Enterprise는 그룹 단위 관리 지원.

분석 vs 대시보드

• 분석(Analysis) — 데이터를 필터·정렬·시각화 만지는 작업 공간
• 대시보드(Dashboard) — 분석의 읽기 전용 스냅샷. 사용자/그룹과 공유하려면 게시(Publish) 필요

Athena vs Redshift vs EMR — 분석 도구 한 줄 비교

여기까지 본 세 도구가 헷갈리지 않게 표로 정리합니다. 시험에 거의 매번 한 번씩 나와요.

항목	Athena	Redshift	EMR
유형	서버리스 쿼리	데이터 웨어하우스	빅데이터 클러스터
인프라	서버리스	클러스터 (Serverless 모드 있음)	EC2 클러스터
데이터 위치	S3 직접 쿼리	Redshift 스토리지 (Spectrum으로 S3도)	S3, HDFS 등
쿼리 언어	표준 SQL (Presto)	SQL (PostgreSQL 호환)	Spark, HBase, Presto, Flink
최적 사용 사례	Ad-hoc, 로그 분석	페타바이트 OLAP, BI	Hadoop/Spark 빅데이터, ML
비용 모델	스캔 데이터량	클러스터 크기·시간	EC2 인스턴스

서버리스 빅데이터 파이프라인 — 표준 흐름

여기까지 본 도구들이 어떻게 한 파이프라인으로 묶이는지 큰 그림 한 번 잡고 갑니다. 이게 시험에 다이어그램이나 시나리오로 자주 나와요.

IoT 디바이스
  ↓
AWS IoT Core (디바이스 관리·데이터 수집)
  ↓
Kinesis Data Streams (실시간 스트리밍 수집)
  ↓
Kinesis Data Firehose (거의 실시간 전달) + Lambda (전송 중 정제·변환)
  ↓
S3 (Ingestion Bucket)  ──────  이벤트 알림 → SQS / SNS / Lambda
  ↓
Athena (서버리스 SQL)
  ↓
S3 (Reporting Bucket) → QuickSight (BI 대시보드)
  또는
Redshift (대규모 OLAP) → QuickSight

각 자리를 한 줄로 — 수집은 IoT Core + Kinesis, 전달·변환은 Firehose + Lambda, 저장은 S3, 디커플링은 SQS, 쿼리는 Athena, 대규모 분석은 Redshift, 시각화는 QuickSight. 이 흐름만 머리에 있으면 시나리오 절반은 풀려요.

ML 영역 — SageMaker는 "직접 만든다", 나머지는 "이미 만든 거 쓴다"

여기서 ML 영역으로 넘어갑니다. 처음 이 단원을 펼치면 12개 가까운 서비스가 한꺼번에 쏟아져서 멘붕이 오는데, 핵심 분기는 정말 단순해요.

> "내가 데이터 과학자처럼 모델을 직접 만들 것인가, 아니면 AWS가 미리 만들어둔 AI 서비스를 가져다 쓸 것인가."

전자가 SageMaker 하나, 후자가 사전 훈련된 AI 서비스 12종입니다. 이 분기 한 번만 머리에 들어와도 시험 보기에서 절반은 자동 소거돼요.

Amazon SageMaker — 모델을 처음부터 만드는 자리

SageMaker 한 줄 자기소개는 — "ML 모델을 구축(Build)→학습(Train)→튜닝(Tune)→배포(Deploy)까지 한 환경에서 처리하는 완전 관리형 플랫폼". 서버 프로비저닝 없고, 데이터 과학자가 처음부터 모델을 만드는 자리예요.

ML 워크플로우 4단계:

1. 데이터 수집·라벨링(Labeling) — 과거 데이터 + 정답 레이블 지정
2. 모델 구축(Building) — 예측 모델 생성
3. 학습·튜닝(Training & Tuning) — 지속적 최적화 (가장 어려운 단계)
4. 배포(Deployment) — 실제 환경 적용, 새 데이터 예측

다른 AI 서비스(Translate·Polly 등)와의 차이가 명확해요 — 이미 만들어진 특정 목적의 서비스는 ML 전문 지식 없이 가져다 쓰는 거고, SageMaker는 사용자가 직접 맞춤형 ML 모델을 처음부터 만들 때 씁니다.

시험 키워드 — "ML 모델 직접 구축", "데이터 과학자", "커스텀 모델", "처음부터" → SageMaker.

사전 훈련된 AI 서비스 12종 — 입력 → 출력 한 줄로 끝

이 영역은 외울 게 많아 보이지만, 결국 "입력이 뭐고 출력이 뭐냐" 한 줄로 풀면 끝나요. 한 명씩 입력→출력으로 정리해 봅니다.

• Rekognition — 이미지/비디오 → 객체·얼굴·텍스트(OCR)·콘텐츠 조정 결과
• Transcribe — 음성(Audio) → 텍스트 (ASR, Automatic Speech Recognition)
• Polly — 텍스트 → 음성 (TTS, Text-to-Speech)
• Translate — A 언어 텍스트 → B 언어 텍스트 (기계 번역)
• Lex — 사용자 발화 → Intent + 슬롯 (챗봇·음성봇, Alexa의 핵심 기술)
• Connect — 클라우드 콜센터 자체 (Contact Flow로 통화 흐름 설계)
• Comprehend — 텍스트 → 감성·개체·언어·주제 (NLP)
• Forecast — 과거 시계열 데이터 → 미래 값 (수요·재고·금융 예측)
• Personalize — 사용자 상호작용 이력 → 실시간 추천 (Amazon.com 추천 엔진과 같은 기술)
• Textract — 스캔 문서·PDF → 텍스트 + 양식(Form) + 테이블 (고급 OCR)
• Kendra — 자연어 질문 → 문서에서 추출한 답변 (엔터프라이즈 검색)
• Comprehend Medical — 의료 텍스트 → 진단·약물·PHI (의료 특화 NLP)

이 12개를 입력→출력 한 줄로만 외우면 시나리오 매칭의 90%가 풀립니다.

자주 헷갈리는 페어들

여기서 시험에 자주 헷갈리는 페어 셋만 따로 짚어 갑니다.

Polly Lexicon vs SSML — 둘 다 Polly 안에 있어서 혼동 1순위.

기능	목적	예시
Lexicons (사용자 지정 어휘)	특정 단어·약어의 발음 맞춤 설정	"AWS" → "Amazon Web Services"로 읽기, 고유명사 발음 교정
SSML	음성의 스타일·효과 세밀 제어	속삭임, 숨소리, 강조, 일시 정지(), 뉴스캐스터 스타일

한 줄 — 발음 교정은 Lexicon, 스타일·효과는 SSML.

Kendra vs OpenSearch — 둘 다 검색이라 헷갈려요.

• Kendra — 문서에서 답변을 추출. "IT 지원 데스크 어디?" → "1층" 같은 자연어 답변
• OpenSearch — 인덱스 기반 부분 일치 검색. 키워드 매칭 결과 리스트

Transcribe vs Polly — 입력·출력만 보면 한 번에 정리돼요.

• Transcribe — 소리가 들어가면 글자가 나옴 (ASR, 음성→텍스트)
• Polly — 글자가 들어가면 소리가 나옴 (TTS, 텍스트→음성)

방향이 정반대라는 것만 잡으면 헷갈릴 일이 없어요.

핵심 시나리오 정리

여기서 시험에 자주 나오는 시나리오 몇 개를 추가로 짚어 갑니다.

Rekognition 콘텐츠 조정 — 부적절한 이미지 자동 감지에서, 최소 신뢰 임계값(Minimum Confidence Threshold) 을 낮출수록 더 많은 이미지가 부적절로 플래그됩니다. 그리고 플래그된 민감 이미지를 사람이 마지막 검토할 때는 Amazon A2I(Augmented AI) 와 연동하는 게 표준이에요.

Transcribe PII 자동 제거(Redaction) — 이름·전화번호·사회보장번호 같은 개인정보를 코딩 없이 자동 마스킹. 콜센터 통화 기록에 자주 쓰여요.

Comprehend Medical + Transcribe Medical — 의사 음성 녹음 → 텍스트 변환(Transcribe Medical) → 의료 정보 추출(Comprehend Medical). DetectPHI API로 보호되는 건강 정보를 식별·비식별화하고, 약물 이름 ↔ 강도·용량·빈도 관계도 추출합니다.

스마트 콜센터 표준 조합 — 시험에 거의 매번 나와요.

고객 전화
  ↓
Amazon Connect (전화 수신, Contact Flow)
  ↓
Amazon Lex (ASR: 음성→텍스트, NLU: Intent 파악)
  ↓
AWS Lambda (백엔드 실행: DB 조회, 예약 등록 등)

Connect → Lex → Lambda — 이 순서를 통째로 외워두면 한 문제는 무조건 풀립니다.

데이터 레이크 아키텍처 — Lake Formation 한가운데

데이터 레이크 시나리오도 자주 나오는데, 그림은 단순해요.

다양한 소스 (S3, RDS, 온프레미스)
  ↓
AWS Glue Crawler → Glue Data Catalog (메타데이터)
  ↓
AWS Lake Formation (중앙 집중식 보안 + 행/열 수준 액세스 제어)
  ↓
Athena / Redshift Spectrum / EMR
  ↓
QuickSight (시각화)

Glue가 메타데이터를 만들고, Lake Formation이 그 위에서 보안을 잡고, Athena·Spectrum·EMR이 같은 카탈로그를 보며 분석하고, QuickSight로 시각화 — 이 흐름이 표준입니다.

시나리오 매칭 — 시험 직전 압축 노트

시험 직전에 한 번 눈으로 훑을 압축 매칭 표예요. 키워드만 잡으면 답이 자동으로 떨어집니다.

시나리오	정답
S3 데이터 서버 없이 SQL	Athena
Redshift 안에서 S3 데이터 같이 쿼리	Redshift Spectrum
페타바이트 OLAP·BI 통합	Redshift
Hadoop/Spark 빅데이터 클러스터	EMR
EMR 비용 절감 + 데이터 유실 없이	작업 노드 스팟
CSV → Parquet, ETL	AWS Glue
새 데이터만 처리, 중복 방지	Glue Job Bookmarks
코딩 없이 데이터 정제	Glue DataBrew
데이터 레이크 + 행/열 수준 보안	Lake Formation
부분 일치 검색, DynamoDB 보완	OpenSearch (Streams → Lambda 패턴)
메시지 1MB 초과 또는 Kafka 호환	MSK
실시간 Java/Scala 복잡 처리	Managed Service for Apache Flink
Firehose에서 SQL 필터링	Kinesis Data Analytics SQL (Legacy)
BI 대시보드 + SPICE 가속	QuickSight Import 모드
QuickSight 열 수준 보안	Enterprise 에디션 CLS
여러 소스 SQL로 묶어 분석	Athena 페더레이션 쿼리
Redshift 퍼블릭 인터넷 우회	Enhanced VPC Routing
Redshift 리전 장애 대비	교차 리전 스냅샷 복사
ML 모델 직접 구축	SageMaker
이미지 분석·얼굴·OCR	Rekognition
음성 → 텍스트 + PII 제거	Transcribe
텍스트 → 음성 + 발음 교정	Polly + Lexicon
텍스트 → 음성 + 속삭임/일시 정지	Polly + SSML
챗봇·Intent 파악	Lex
클라우드 콜센터 + Contact Flow	Connect
NLP 감성 분석	Comprehend
의료 텍스트·PHI	Comprehend Medical
시계열 예측	Forecast
ML 추천·개인화	Personalize
스캔 문서·양식·테이블 추출	Textract
자연어 문서 검색·답변 추출	Kendra
콜센터 표준 조합	Connect → Lex → Lambda
Rekognition + 사람 검토	Amazon A2I 연동

시험 직전 한 번 더 — Athena 함정 포함 압축 모음

여기까지가 분석·ML 영역의 핵심입니다. 시험 직전에 다시 펼쳐 볼 압축 노트를 마지막에 박아 둘게요.

• Athena 비용 절감 4총사 = Parquet/ORC + 압축 + 파티셔닝 + 128MB 이상 파일
• Athena DDL LOCATION은 반드시 슬래시(/)로 끝
• Athena 페더레이션 = Lambda 커넥터로 S3 외 소스에 SQL
• Redshift는 OLAP, OLTP 아님
• Redshift Multi-AZ로 리전 장애 못 막음 → 교차 리전 스냅샷 복사
• Redshift 퍼블릭 인터넷 우회 = Enhanced VPC Routing
• Redshift Spectrum = 클러스터 필요 / Athena = 서버리스
• EMR 작업 노드만 스팟, 마스터·코어는 온디맨드/Reserved
• 마스터 노드 종료 = 클러스터 전체 영향, 코어 노드 종료 = 데이터 유실
• Glue Job Bookmarks = 새 데이터만 / DataBrew = 코딩 없는 시각 정제
• Glue Data Catalog = Athena·Spectrum·EMR이 공유하는 중앙 메타데이터
• Lake Formation = 데이터 레이크 + 행/열 보안 + Glue 위
• Apache Flink는 Firehose에서 직접 못 읽음 (Streams·MSK만)
• Kinesis Data Analytics SQL(Legacy)는 Firehose 읽기 가능 (Flink 옵션과 다름)
• MSK는 메시지 10MB+, Kafka 호환, 보관 무제한
• Kinesis는 메시지 최대 1MB, 보관 최대 365일
• DynamoDB 검색 보완 = DynamoDB Streams → Lambda → OpenSearch
• QuickSight SPICE = Import 모드에서만 작동
• QuickSight CLS(열 수준 보안) = Enterprise 에디션만
• ML 직접 만들기 = SageMaker / 사전 훈련 = 12종 AI 서비스
• Polly Lexicon = 발음 / SSML = 스타일·효과
• Kendra = 답변 추출 / OpenSearch = 인덱스 검색
• Transcribe = 소리→글자 / Polly = 글자→소리 (방향 정반대)
• Rekognition 콘텐츠 조정 + 사람 검토 = A2I 연동
• Transcribe PII 자동 제거 = 코딩 없이 마스킹
• 의료 음성 → 텍스트 → 의료 정보 = Transcribe Medical → Comprehend Medical
• 콜센터 표준 = Connect → Lex → Lambda

여기까지가 SAA-C03 분석·ML 영역의 전부예요. 이름만 보면 12개 넘는 서비스에 멘붕이 오지만, 각 서비스의 입력→출력 한 줄과 자기 자리만 머리에 들어오면 시나리오 절반은 자동으로 풀립니다. 특히 Athena의 비용 절감 4총사·페더레이션·Spectrum과의 차이만 잘 잡아두면 분석 영역에서 1~2문제는 그냥 따라옵니다. 시험 전날 시나리오 매칭 표를 한 번 더 훑고 들어가시면 이 단원에서 점수 잃을 일이 거의 없어요.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — IAM
• 2편 — EC2 / Storage
• 3편 — ELB · ASG
• 4편 — S3 (스토리지)
• 5편 — Databases
• 6편 — Networking
• 7편 — Messaging
• 8편 — Containers · Serverless
• 9편 — Monitoring
• 10편 — Analytics · ML (현재 글)
• 11편 — Security
• 12편 — DR · Migration
• 13편 — Architectures
• 14편 — Exam Prep (완)