MLA-C01 문제은행에서 Kinesis, Lambda, EventBridge, Step Functions가 핵심 개념으로 나오는 문제는 약 46문항입니다. 시험 안내서도 과제 1.1에서 Kinesis, Apache Flink, Apache Kafka로 스트리밍 데이터를 수집하는 법을, 과제 1.2에서 Lambda와 Spark로 스트리밍 데이터를 변환하는 법을, 과제 3.1에서 Apache Airflow와 SageMaker Pipelines 중 오케스트레이터를 고르는 법을, 과제 3.3에서 EventBridge 규칙으로 학습·추론 작업을 구성하는 법을 묻습니다. 실시간으로 들어오는 데이터를 어떻게 받아서, 어디서 처리하고, 무엇으로 다음 단계를 깨우는지가 핵심입니다.
이 글은 배치와 스트리밍의 차이에서 시작해 스트리밍 서비스 4종, Firehose의 세부 기능, 스트림에서 실시간 추론하는 구조, S3 이벤트와 EventBridge로 파이프라인을 깨우는 방법, 오케스트레이터 3종, 그리고 이름이 바뀌거나 종료된 서비스 순서로 정리합니다. S3 중심의 데이터 레이크와 데이터 포맷은 데이터 수집과 저장 전략에서 먼저 다뤘습니다.
---
배치와 스트리밍, 무엇이 다른가
택배는 물건을 모아 두었다가 정해진 시간에 한꺼번에 보냅니다. 수도는 꼭지를 틀면 물이 계속 흐릅니다. 배치 처리가 택배라면 스트리밍은 수도입니다.
| 구분 | 배치 | 스트리밍 | |------|------|------| | 처리 시점 | 일정 시간마다 모아서 한 번에 | 데이터가 들어오는 즉시 계속 | | 지연 시간 | 분 ~ 시간 | 밀리초 ~ 초 | | 대표 도구 | Glue ETL, EMR, SageMaker Processing, Batch Transform | Kinesis, Firehose, Managed Service for Apache Flink, MSK | | ML 예 | 매주 재학습, 매일 밤 전체 고객 점수 계산 | 결제 순간의 사기 탐지, 클릭 즉시 추천 갱신 |
실제 시스템은 둘을 함께 씁니다. 스트림으로 실시간 판단을 하면서, 같은 데이터를 S3에 쌓아 두었다가 배치로 재학습하는 구조가 가장 흔합니다.
---
스트리밍 서비스 4종
| 서비스 | 역할 | 핵심 특징 | 문제 속 단서 | |------|------|------|------| | Kinesis Data Streams | 실시간 수집과 일시 보관 | 샤드 단위 처리량, 여러 소비자가 같은 데이터를 각자 읽고 다시 읽기 가능 | "여러 애플리케이션이 같은 스트림을 실시간으로 처리" | | Amazon Data Firehose | 목적지까지 자동 전달 | 서버 · 샤드 관리 없음, 버퍼링 후 S3 · Redshift · OpenSearch로 적재 | "코드 없이 스트리밍 데이터를 S3에 저장" | | Managed Service for Apache Flink | 상태 기반 스트림 처리 | 시간 창(window) 집계, 스트림 조인, 실시간 이상 탐지 | "최근 5분 이동 평균", "스트림에서 실시간 집계" | | Amazon MSK | 관리형 Apache Kafka | 기존 Kafka 애플리케이션과 도구를 그대로 사용 | "이미 Kafka를 쓰고 있다" |
Kinesis Data Streams의 샤드 하나는 초당 1MB 또는 1,000개 레코드를 받고, 초당 2MB를 내보냅니다. 처리량이 부족하면 샤드를 늘리거나, 용량 관리를 자동으로 하는 온디맨드 모드를 씁니다. 데이터는 기본 24시간, 최대 365일까지 보관되어 장애 후 다시 읽을 수 있습니다. 영상 데이터라면 Kinesis Video Streams로 받아 Rekognition이나 SageMaker AI 모델로 분석합니다.
시험 팁: "데이터를 받아서 바로 S3에 쌓기만" 하면 Firehose, "받은 데이터를 여러 소비자가 실시간으로 처리"하면 Kinesis Data Streams, "스트림 위에서 시간 창 집계와 상태 유지"가 필요하면 Managed Service for Apache Flink입니다.
!Kinesis Data Streams로 받은 이벤트를 Lambda와 SageMaker 엔드포인트로 실시간 추론하고, Firehose로 S3에 쌓아 재학습하는 스트리밍 ML 파이프라인
---
Firehose 자세히 보기: 버퍼, 변환, 포맷
Firehose는 시험에서 세부 기능을 자주 묻습니다.
| 기능 | 하는 일 | 문제 속 단서 | |------|------|------| | 버퍼링 | 버퍼 크기(1~128MiB)나 버퍼 간격(최대 900초) 중 먼저 찬 조건에서 전달 | "거의 실시간(near real-time)이면 충분" | | Lambda 변환 | 전달 전에 레코드를 정제하거나 필드를 추가 | "적재 전에 개인정보 필드를 제거" | | 원본 백업 | 변환 전 원본 레코드를 별도 S3 경로에 보관 | "변환 결과와 원본을 모두 보관" | | 형식 변환 | JSON을 Parquet이나 ORC로 바꿔 저장 (Glue 데이터 카탈로그의 스키마 사용) | "Athena 쿼리 비용을 줄이도록 열 형식으로" | | 동적 파티셔닝 | 레코드 안의 값(예: 날짜, 고객 ID)으로 S3 경로를 나눔 | "고객별 폴더로 자동 분리" |
형식 변환은 JSON 입력을 기준으로 합니다. CSV 같은 다른 형식은 먼저 Lambda 변환으로 JSON으로 바꿉니다. Redshift로 보낼 때는 Firehose가 데이터를 S3에 먼저 쓰고 Redshift로 불러옵니다(COPY).
시험 팁: "실시간이 아니라 1분 정도 지연은 괜찮고, 운영 부담 없이 S3에 Parquet로 쌓아야 한다"는 Firehose + 형식 변환입니다. Firehose는 버퍼링 때문에 밀리초 단위의 실시간 처리에는 맞지 않습니다.
---
스트림에서 실시간 추론하기
결제가 일어나는 순간 사기 여부를 판단하려면, 스트림의 이벤트마다 모델을 호출해야 합니다.
| 단계 | 서비스 | 하는 일 | |------|------|------| | 수집 | Kinesis Data Streams | 결제 이벤트를 실시간으로 받음 | | 처리 · 호출 | Lambda (또는 Managed Service for Apache Flink) | 이벤트를 묶어 읽고, 전처리 후 SageMaker 엔드포인트 호출 | | 추론 | SageMaker AI 실시간 엔드포인트 | 사기 점수 반환 | | 결과 저장 · 알림 | DynamoDB, SNS | 점수 저장, 임계값을 넘으면 알림 | | 재학습 데이터 | Firehose → S3 | 원본 이벤트를 쌓아 두었다가 배치 재학습 |
Lambda는 Kinesis 스트림을 이벤트 소스로 연결하면 레코드를 묶음(배치)으로 받아 처리합니다. 최근 10분 동안의 거래 횟수처럼 시간 창이 필요한 특징은 Flink에서 계산하는 편이 낫습니다. 실시간으로 계산한 특징을 SageMaker Feature Store 온라인 스토어에 기록해 두면, 추론할 때 같은 값을 읽어 학습과 서빙의 특징을 일치시킬 수 있습니다.
시험 팁: "스트림의 각 거래에 실시간으로 점수를 매기고, 원본은 재학습용으로 보관"은 Kinesis Data Streams + Lambda + SageMaker 엔드포인트, 그리고 Firehose → S3의 조합입니다.
---
이벤트로 파이프라인 깨우기: S3 이벤트와 EventBridge
사람이 매번 버튼을 누르지 않아도, 어떤 일이 생기면 다음 단계가 자동으로 시작되게 만드는 것이 이벤트 기반 자동화입니다.
| 트리거 | 예 | 연결하는 대상 | |------|------|------| | S3 이벤트 알림 | 새 학습 데이터 파일이 업로드됨 | Lambda, SQS, SNS, 또는 EventBridge | | EventBridge 일정 규칙 | 매주 일요일 새벽 2시 | SageMaker 파이프라인 실행 | | SageMaker 상태 변경 이벤트 | 학습 작업 완료 · 실패, 엔드포인트 상태 변경 | Lambda 알림, 다음 단계 시작 | | Model Package State Change | 모델 레지스트리에서 모델 승인 | 배포 파이프라인(CodePipeline 등) 시작 | | CloudWatch 경보 | Model Monitor가 드리프트 위반을 감지 | 재학습 파이프라인 실행 |
EventBridge는 SageMaker Pipelines를 직접 대상으로 지원해서, 규칙에 맞는 이벤트가 오면 Lambda를 거치지 않고 파이프라인 실행(StartPipelineExecution)을 시작할 수 있습니다. S3 이벤트를 EventBridge로 보내면 같은 이벤트를 여러 대상에 나눠 보내거나 조건을 세밀하게 걸 수 있습니다.
시험 팁: "새 데이터가 S3에 올라오면 재학습 파이프라인을 자동으로 실행"은 S3 이벤트 → EventBridge → SageMaker Pipelines입니다. "모델이 승인되면 자동 배포"는 Model Package State Change 이벤트를 받는 EventBridge 규칙입니다.
---
오케스트레이터 고르기: SageMaker Pipelines, Step Functions, MWAA
| 오케스트레이터 | 강점 | 적합한 상황 | |------|------|------| | SageMaker Pipelines | 처리 · 학습 · 튜닝 · 평가 · 조건 · 모델 등록 같은 ML 전용 단계, 단계 캐싱, 계보 추적, 모델 레지스트리 통합 | ML 워크플로 자체를 최소 운영으로 자동화 | | AWS Step Functions | 범용 상태 머신, 많은 AWS 서비스와 직접 통합, 오류 재시도 · 분기, Map 상태로 병렬 처리, 사람 승인 대기 | Lambda · Glue · SageMaker · 번역 같은 여러 서비스를 한 흐름으로 | | Amazon MWAA | 관리형 Apache Airflow, Python DAG, SageMaker 오퍼레이터 | 이미 Airflow DAG로 데이터 파이프라인을 운영하는 팀 |
Step Functions는 SageMaker 학습 작업 같은 장시간 작업을 시작한 뒤 끝날 때까지 기다리는 통합(.sync)을 지원합니다. Map 상태는 S3의 파일 수천 개를 나눠 동시에 처리할 때 씁니다(예: 문서 수천 개를 병렬로 번역).
시험 팁: "회사가 이미 수백 개의 Airflow DAG를 운영 중"이면 MWAA, "ML 단계만으로 이뤄진 파이프라인을 가장 적은 운영 부담으로"면 SageMaker Pipelines, "Lambda와 Glue, SageMaker, 사람 승인이 섞인 흐름"이면 Step Functions입니다.
---
이름이 바뀌었거나 종료된 서비스
예전 자료와 문제은행에는 옛 이름이 자주 나옵니다.
| 예전 이름 | 지금 | 비고 | |------|------|------| | Kinesis Data Firehose | Amazon Data Firehose | 2024년에 이름 변경, 기능은 같음 | | Kinesis Data Analytics (Apache Flink용) | Amazon Managed Service for Apache Flink | 2023년에 이름 변경 | | Kinesis Data Analytics for SQL | 종료 | 2025년 10월 15일부터 새로 만들 수 없고, 2026년 1월 27일부터 애플리케이션 삭제 · 지원 종료 |
시험 안내서(Version 1.0)의 서비스 목록도 새 이름(Amazon Data Firehose, Amazon Managed Service for Apache Flink)으로 적혀 있습니다. 문제에 "Kinesis Data Analytics로 스트림을 SQL로 실시간 집계"가 나오면 지금 기준으로는 Managed Service for Apache Flink(Flink SQL 포함)로 읽으면 됩니다.
---
시나리오로 연습하기
| 상황 | 정답 | 이유 | |------|------|------| | IoT 센서 데이터를 서버 관리 없이 S3에 Parquet로 적재 | Amazon Data Firehose + 형식 변환 | 자동 전달과 열 형식 변환 | | 같은 클릭 스트림을 추천 앱과 분석 앱이 각자 실시간 처리 | Kinesis Data Streams | 여러 소비자, 재처리 가능 | | 스트림에서 최근 5분 이동 평균으로 이상 탐지 | Managed Service for Apache Flink | 상태 기반 시간 창 집계 | | 이미 Kafka로 이벤트를 주고받는 시스템을 AWS로 이전 | Amazon MSK | 기존 Kafka 그대로 | | 결제마다 실시간 사기 점수를 매기고 원본은 보관 | Kinesis Data Streams + Lambda + SageMaker 엔드포인트, Firehose → S3 | 실시간 추론과 재학습 데이터 확보 | | 새 데이터가 S3에 올라오면 재학습 자동 시작 | S3 이벤트 → EventBridge → SageMaker Pipelines | 파이프라인을 직접 대상으로 | | 기존 Airflow DAG에 SageMaker 학습 단계 추가 | Amazon MWAA | Airflow 그대로 운영 | | 문서 수천 개를 병렬로 번역하고 실패한 것만 재시도 | Step Functions Map 상태 + Translate | 병렬 처리와 오류 재시도 |
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | 배치 vs 스트리밍 | 모아서 한 번에 vs 들어오는 즉시, 실제로는 둘을 함께 | | Kinesis Data Streams | 샤드 처리량, 여러 소비자, 기본 24시간 ~ 최대 365일 보관 | | Amazon Data Firehose | 관리 없는 자동 전달, 버퍼링이라 거의 실시간 | | Firehose 세부 | Lambda 변환, 원본 백업, Parquet · ORC 변환, 동적 파티셔닝 | | Managed Service for Apache Flink | 시간 창 집계, 상태 유지, 실시간 이상 탐지 | | Amazon MSK | 기존 Kafka 애플리케이션 이전 | | 실시간 추론 | Kinesis → Lambda → SageMaker 엔드포인트 → DynamoDB · SNS | | 학습 · 서빙 일관성 | 실시간 특징은 Feature Store 온라인 스토어에 | | 이벤트 트리거 | S3 이벤트, EventBridge 일정 · 상태 변경 · 모델 승인 | | EventBridge 대상 | SageMaker Pipelines 실행을 직접 시작 가능 | | 오케스트레이터 | ML 전용은 Pipelines, 여러 서비스는 Step Functions, 기존 Airflow는 MWAA | | 옛 이름 | Kinesis Data Firehose → Data Firehose, Kinesis Data Analytics → Managed Flink |
---
다음 단계