영상 검색이나 장면 임베딩 얘기를 하면 대부분 모델 이름부터 본다.
근데 실제 구축은 모델보다 파이프라인이 먼저 삐끗한다.
어디서 트리거할지, 어디서 배치 돌릴지, 실패를 누가 다시 잡을지, 결과를 어디에 쌓을지, 여기서 체력이 갈린다.
2026년 4월 14일 기준 AWS 기술 블로그의 TwelveLabs Marengo VoD 파이프라인 글을 다시 읽어보면 좋은 힌트가 있다.
핵심은 서비스가 많다는 사실보다 어디까지 단순하게 갈 수 있느냐 를 먼저 결정하라는 쪽이다.
공식 예시만 봐도 선택지는 꽤 많다.
- S3 Event Notification + Lambda
- EventBridge 기반 fan-out
- EventBridge Scheduler + Lambda
- EventBridge Scheduler + Step Functions
- MWAA
- AWS Batch
여기서 흔한 실수는 이거다.
AWS 서비스가 많으니 처음부터 제일 큰 그림으로 가는 것.
실무는 대개 반대다.
처음엔 가장 단순한 흐름으로 시작하고, 실패 처리나 병렬 처리 요구가 커질 때만 다음 계층으로 올라가는 편이 낫다.
먼저 한 줄 판단
VoD 영상이 S3에 쌓이고 TwelveLabs Marengo로 임베딩만 만들고 싶다면 초기 선택은 대체로 S3 Event Notification + Lambda 또는 EventBridge Scheduler + Lambda 면 충분하다.
아래 조건이 붙을 때만 Step Functions, MWAA, AWS Batch를 진지하게 본다.
- 영상 수가 빠르게 늘어난다
- 개별 실패를 자동 재시도해야 한다
- 임베딩 외에 썸네일, 메타데이터, 후속 저장 단계를 같이 묶어야 한다
- 운영자와 워크플로우 가시성이 중요하다
즉, 먼저 고를 질문은 무슨 AWS 서비스를 배우고 싶나 가 아니라 실패와 병렬 처리 요구가 이미 여기까지 왔나 다.
누가 지금 이 글부터 보면 좋은가
이 글은 이런 상황에 맞다.
- VOD 파일은 이미 S3에 쌓이고 있다
- Marengo 임베딩이나 분석 결과를 붙이고 싶다
- 이벤트 기반 처리와 배치 처리 중 어디서 시작할지 고민이다
- Lambda로 충분한지, Step Functions까지 가야 하는지 판단이 안 선다
- 팀 안에서 AWS 서비스가 너무 많아 보여 오히려 출발이 늦어지고 있다
반대로 아직 영상이 거의 없고, 분석 요구도 자주 바뀌며, 프로토타입을 하루 안에 지워도 되는 단계라면 이 글보다 먼저 로컬 테스트나 샘플 SDK 확인이 더 낫다.
이 글에서 먼저 잡아야 할 전제
AWS 공식 글을 그대로 따라 읽으면 서비스가 많아 보여서 선택지가 과하게 느껴질 수 있다.
그래서 전제를 먼저 고정해두는 편이 좋다.
이번 글은 아래 상황을 가정한다.
- 원본 혹은 프록시 영상은 S3에 올라온다
- 목적은 VoD 분석 또는 임베딩 생성이다
- 결과는 JSON, 벡터, 메타데이터 형태로 저장한다
- 팀은 무한한 운영 인력을 갖고 있지 않다
이 조건이면 AWS 서비스는 많아도 실제 첫 선택지는 좁아진다.
제일 단순한 출발은 S3 Event Notification + Lambda다
AWS 공식 글은 방법 A: S3 Event Notification + Lambda 를 저장된 영상 후처리를 위한 가장 단순한 구성으로 설명한다.
2026-04-14 기준 본문에는 영상이 S3 버킷에 업로드되면 Event Notification이 Lambda를 직접 호출하고, Lambda가 Bedrock의 Marengo API를 호출해 임베딩을 생성한다고 적혀 있다.
이건 진짜로 단순하다.
장점도 분명하다.
- 새 파일 업로드 직후 반응한다
- 별도 스케줄이 없어도 된다
- 운영 지점이 적다
- 소규모 트래픽에선 비용도 낮다
초기 실험에서는 이 단순함이 엄청난 장점이다.
이 구성이 잘 맞는 상황
- 업로드 빈도가 아주 높지 않다
- 영상이 들어오면 바로 처리해도 된다
- 후속 단계가 많지 않다
- 실패 케이스를 코드 레벨에서 직접 다뤄도 괜찮다
쉽게 말하면 영상 올라오면 바로 임베딩 한 번 이 핵심이면 여기서 시작해도 된다.
이 구성이 금방 답답해지는 상황
반대로 아래 상황이면 이벤트 직결 구조가 빨리 무거워진다.
- 영상마다 여러 파생 작업이 동시에 붙는다
- 재처리 대상만 골라 다시 돌려야 한다
- 작업 실패와 완료 상태를 별도로 관리해야 한다
- 하루에 몰아서 처리하는 배치가 더 자연스럽다
이때는 바로 다음 층을 봐야 한다.
fan-out이 필요하면 EventBridge를 중간에 둬도 된다
AWS 글은 S3 이벤트를 EventBridge로 라우팅하면 이벤트 생산자와 소비자를 느슨하게 분리할 수 있다고 설명한다.
본문 예시도 하나의 영상 업로드 이벤트에 대해 여러 rule을 두고 임베딩 생성, 썸네일 추출, 메타데이터 저장을 병렬 트리거할 수 있다고 적는다.
이 구조의 장점은 S3가 모든 후속 책임을 직접 지지 않게 된다 는 데 있다.
즉, 영상 업로드 자체는 그대로 두고 후속 로직을 계속 추가할 수 있다.
EventBridge가 필요한 순간
- 업로드 이벤트 하나에 타겟이 여러 개 붙는다
- 후속 작업을 각기 다른 팀이 관리한다
- 새 파이프라인을 붙일 때 원본 트리거를 건드리고 싶지 않다
- 느슨한 결합이 중요하다
반대로 타겟이 사실상 하나뿐이고 운영자가 한 팀이면 굳이 EventBridge까지 끼우지 않아도 된다.
서비스를 하나 더 넣는 건 확장성만 늘리는 게 아니라 이해해야 할 표면적도 늘리는 일이기 때문이다.
배치 처리는 EventBridge Scheduler + Lambda가 제일 먼저다
AWS 공식 글에서 내가 제일 실전적으로 본 부분은 옵션 1: EventBridge Scheduler + Lambda 다.
본문은 이 조합을 가장 단순하고 빠르게 구성할 수 있는 배치 처리 선택으로 설명한다.
흐름도 단순하다.
- Scheduler가 크론에 따라 Lambda를 호출한다
- Lambda가 S3에서 미처리 영상을 조회한다
StartAsyncInvoke로 임베딩 작업을 시작한다
여기서 아주 중요한 제약도 같이 적혀 있다.
2026-04-14 기준 AWS 글은 TwelveLabs Marengo의 비디오 임베딩은 비동기 추론만 지원하며, 비디오 입력에는 InvokeModel이 아니라 반드시 StartAsyncInvoke를 써야 한다고 적는다.
그리고 더 중요하다.
StartAsyncInvoke는 inference profile을 지원하지 않고, 반드시 base model ID를 사용해야 한다고 명시한다.
이건 진짜 자주 놓치는 포인트다.
왜 이 조합이 좋은가
- 하루 한 번, 매시간 같은 배치 작업에 맞다
- 트리거가 단순하다
- 구성 요소가 적다
- 결과를 바로 기다리지 않고 작업 제출만 하면 된다
영상 길이가 길어도 Lambda는 일을 끝내는 게 아니라 비동기 작업을 시작만 하고 빠질 수 있다.
그래서 생각보다 오래 버틴다.
어디서 한계가 오나
공식 글도 제약을 꽤 솔직하게 적는다.
- 실행 시점에 결과를 바로 받지 못한다
- 완료 여부는
GetAsyncInvoke폴링이나 EventBridge 완료 이벤트로 받아야 한다 - 개별 영상 실패를 코드에서 잘 잡아야 한다
즉, Scheduler + Lambda는 작업 제출기 로는 매우 좋지만, 복잡한 재시도와 분기 처리까지 맡기면 코드가 빨리 커진다.
Step Functions는 복잡도가 아니라 실패 비용 때문에 간다
많은 팀이 Step Functions를 멋진 오케스트레이션 도구로 먼저 본다.
나는 약간 다르게 본다.
이건 실패를 코드에서 다 감당하기 싫어졌을 때 가는 도구다.
AWS 공식 글도 EventBridge Scheduler + Step Functions 조합을 영상 수가 많거나, 여러 단계 분석이 붙을 때 적합하다고 설명한다.
본문에는 Distributed Map 상태를 활용하면 S3의 영상 목록을 읽어 최대 10,000개의 병렬 자식 워크플로우를 실행할 수 있다고 적혀 있다.
그리고 장점도 선명하다.
- 대규모 병렬 처리
- 내장 Retry/Catch
- 시각적 모니터링
- 후속 단계를 워크플로우에 추가하기 쉬움
이 네 가지는 실무에서 꽤 큰 차이다.
Step Functions가 맞는 순간
아래 셋 중 둘 이상이면 거의 후보가 된다.
- 임베딩 외에 메타데이터 저장이나 후속 가공이 붙는다
- 개별 실패를 자동 재시도하고 싶다
- 병렬 처리 가시성이 필요하다
- 영상 수가 매일 수십 건 이상으로 커진다
AWS 글도 영상 수가 적으면 Lambda 단독 구성이 더 비용 효율적일 수 있다고 적는다.
이 말이 중요하다.
Step Functions는 항상 더 좋은 구조가 아니라 복잡도를 감당할 만큼 실패 비용이 커졌을 때 값을 한다.
Step Functions를 너무 일찍 쓰면 생기는 일
- 상태 머신 정의를 팀원이 어려워한다
- 소규모 배치에는 과한 구조가 된다
- 디버깅보다 설계 문서가 더 커진다
- 작은 작업에도 상태 전환 비용을 신경 쓰게 된다
즉, 예쁜 다이어그램이 나온다고 곧바로 정답은 아니다.
MWAA는 Airflow 경험이 이미 있을 때만 자연스럽다
AWS 공식 글의 MWAA 섹션은 대상 독자가 꽤 명확하다.
Airflow에 익숙한 엔지니어가 DAG로 비디오 분석 워크플로우를 정의하고 웹 UI에서 실행 상태를 모니터링하는 상황에 적합하다고 적는다.
이 말 그대로다.
MWAA는 Airflow 조직 경험이 있을 때 강하다.
없으면 갑자기 도입 난도가 올라간다.
MWAA가 맞는 상황
- 팀이 원래 Airflow를 쓰고 있다
- DAG 중심 운영이 이미 익숙하다
- 스케줄과 의존관계 관리가 핵심이다
- 데이터 플랫폼팀이 따로 있다
MWAA가 과한 상황
- 영상 임베딩 배치 하나가 거의 전부다
- AWS에 익숙하지만 Airflow 운영 인력이 없다
- 빠른 PoC가 목적이다
이 경우 Scheduler + Lambda나 Step Functions가 훨씬 가볍다.
AWS Batch는 처리 시간이 길고 컨테이너 작업이 클 때 본다
AWS 공식 글은 AWS Batch를 실시간 응답이 필요 없는 대용량 영상 분석 워크로드에 적합하다고 설명한다.
특히 TwelveLabs 호출만이 아니라 OCR, 텍스트 추출, 오디오 추출 같은 여러 분석을 병렬 또는 순차로 묶을 때 강하다고 적는다.
이건 꽤 중요한 차이다.
Batch는 영상 한 건당 여러 무거운 작업이 붙는 컨테이너형 처리 에 잘 맞는다.
AWS Batch가 맞는 순간
- 분석 시간이 길다
- 컨테이너 환경이 필요하다
- 실시간 응답이 전혀 중요하지 않다
- 스팟 기반 대용량 처리 최적화가 필요하다
AWS Batch가 아직 이른 순간
- 임베딩 제출만 하면 된다
- 운영 복잡도를 낮추는 게 더 중요하다
- 컨테이너와 큐 설계까지 지금 당장 필요 없다
이 경우엔 Batch가 멋져 보여도 실제론 너무 이르다.
Marengo에서 제일 자주 놓치는 API 제약
이 글에서 가장 중요한 팩트 하나를 다시 적는다.
AWS 공식 글 기준으로 TwelveLabs Marengo의 비디오 임베딩은 비동기 추론만 지원한다.
즉, InvokeModel로 밀면 안 된다.
반드시 StartAsyncInvoke 를 써야 한다.
그리고 inference profile이 아니라 base model ID를 써야 한다.
이건 구조 전체에 영향을 준다.
왜냐면 이 제약을 모르면 파이프라인 초반 가정부터 틀어지기 때문이다.
- 동기 응답을 기대한다
- Lambda 안에서 결과까지 기다리려 한다
- profile ID로 붙였다가 원인 모를 실패를 본다
그래서 AWS 구성 선택보다 먼저 API 제약을 정확히 읽는 게 중요하다.
내 기준 선택표
| 상황 | 먼저 볼 선택 | 이유 |
|---|---|---|
| 영상 업로드 직후 바로 처리 | S3 Event Notification + Lambda | 가장 단순하고 반응이 빠르다 |
| 매시간/매일 미처리 영상 배치 | EventBridge Scheduler + Lambda | 배치 출발점으로 가장 가볍다 |
| 영상 수가 많고 실패 재시도가 중요 | EventBridge Scheduler + Step Functions | 내장 재시도와 병렬성이 강하다 |
| Airflow 조직 경험이 이미 있음 | MWAA | DAG 운영에 익숙하면 자연스럽다 |
| 무거운 컨테이너 분석이 길게 돈다 | AWS Batch | 장시간 대용량 배치에 적합하다 |
이 표에서 중요한 건 서비스 이름보다 운영 문제를 무엇으로 정의하느냐 다.
처음부터 서비스 카탈로그를 고르지 말고 문제를 먼저 좁히는 편이 낫다.
실수 TOP 5
1. Lambda로 충분한데 Step Functions부터 간다
작업 규모보다 구조가 먼저 커진다.
2. 비디오 임베딩도 InvokeModel로 될 거라 생각한다
AWS 공식 글 기준으로 Marengo 비디오 임베딩은 StartAsyncInvoke가 필요하다.
3. inference profile을 그냥 넣는다
본문은 StartAsyncInvoke에 inference profile이 아니라 base model ID를 써야 한다고 적는다.
이걸 놓치면 초반부터 삐끗한다.
4. fan-out이 없는데 EventBridge를 습관처럼 넣는다
확장성은 얻을 수 있지만 구성 복잡도도 같이 오른다.
5. 실패 비용이 작은데 운영 가시성부터 과하게 산다
워크플로우 콘솔이 멋져도 실패 비용이 작으면 과할 수 있다.
언제 이 선택이 맞고 언제 아닌가
Lambda 중심 구성이 맞는 경우
- 영상 수가 소규모다
- 처리 단계가 단순하다
- 코드에서 실패 처리해도 된다
- 빠른 구축이 중요하다
Step Functions가 맞는 경우
- 영상 수가 커졌다
- 개별 실패 재시도가 중요하다
- 단계가 여러 개다
- 시각적 모니터링이 필요하다
MWAA가 맞는 경우
- Airflow 운영 경험이 이미 있다
- DAG 기반 스케줄링 문화가 있다
AWS Batch가 맞는 경우
- 장시간 무거운 컨테이너 작업이다
- 실시간성이 중요하지 않다
FAQ
VoD 분석이면 무조건 Step Functions가 낫나
아니다.
영상 수가 크지 않고 임베딩 제출 정도가 핵심이면 Lambda 기반이 더 단순하고 빠를 수 있다.
S3 업로드 이벤트와 배치 스케줄 중 무엇이 먼저인가
업로드 즉시 처리면 S3 Event Notification,
주기적으로 모아서 처리면 EventBridge Scheduler가 더 자연스럽다.
EventBridge는 꼭 필요한가
아니다.
fan-out과 느슨한 결합이 필요할 때 값이 크다.
타겟이 사실상 하나면 굳이 안 넣어도 된다.
Marengo 비디오 임베딩은 동기 호출이 안 되나
AWS 공식 글 기준으로 비디오 임베딩은 비동기 추론만 지원한다.
그래서 StartAsyncInvoke가 필요하다.
inference profile을 쓰면 더 편하지 않나
그럴 것 같지만, AWS 글은 StartAsyncInvoke가 inference profile을 지원하지 않고 base model ID를 써야 한다고 적고 있다.
Airflow를 안 써봤는데 MWAA부터 가도 되나
가능은 하지만 대개는 과하다.
조직 경험이 없다면 더 가벼운 서버리스 경로부터 보는 편이 낫다.
AWS Batch는 언제 제일 빛나나
하나의 영상에서 여러 무거운 분석 작업을 컨테이너로 길게 돌릴 때다.
공식 출처
- AWS 기술 블로그
- Amazon S3 Event Notifications
- AWS Lambda
- AWS Step Functions
- AWS Batch
- 로컬 참고 노트:
00.Inbox/260414_[요약] 클라우드 환경에서의 비디오 인텔리전스 구현 TwelveLabs로 시작하는 AI 영상 분석 1부 – VoD환경에서의 비디오 분석 파이프라인 구축하기 AWS 기술 블.md