📁 File7. 파이프라인 이론📖 개요

07. Pipeline Theory — 미디어 변환 파이프라인의 일반론

이 챕터가 답하는 질문: 변환 파이프라인은 어떤 패턴으로 만드는가? 작성: 2026-05-10 / 선행: 06-streaming

한 문장 답 (Pyramid Top)

미디어 변환 파이프라인은 **“단계별로 분리된 작업자 + 큐로 디커플링 + 멱등성으로 중복 방어 + DLQ로 실패 회수 + 관측으로 진실 확보”**의 5축으로 만든다. 이 챕터는 그 5축을 7개 문서로 분해해 왜·어떻게·무엇을 정리한다 — 사례(08)는 이 이론의 한 가지 구현체일 뿐이다.

Why — 왜 “이론”부터 정리하는가

미디어 파이프라인을 처음 만들면 거의 모두 모놀리식 람다 하나로 시작한다.

[업로드] → [Lambda 하나에서 probe + transcode + sprite + waveform + DB 갱신] → [완료]

이 구조는 토이 단계에서는 잘 굴러간다. 그러나 다음 4가지 압력이 들어오는 순간 무너진다.

압력모놀리식이 무너지는 방식
긴 영상람다 timeout(15분) 초과 → 전체 실패 → 부분 산출물 누락
부분 실패sprite 단계만 실패해도 transcode 결과 전체 폐기
재시도한 영상이 실패하면 무거운 전체 작업이 재실행되어 비용 폭주
관측”어디서 실패했나?” — 한 람다 안에서는 단계가 안 보인다

해결은 한 줄로 요약된다 — 단계로 쪼개고, 큐로 잇고, 각자 retry시켜라.

이 챕터의 7개 문서는 그 한 줄을 푸는 5축의 디테일이다.

How — 어떻게 정리했는가

1) 7개 문서의 의존 관계

01 → 02 → 03이 구조의 골격이고, 04 → 05가 안전성, 06 → 07이 운영 관점이다.

2) 모든 문서의 형식 (7-블록)

각 문서는 루트 README와 같은 /explain + Minto 형식을 따른다.

1. 한 줄 답
2. Why  — 왜 이 패턴이 필요한가
3. How  — 어떻게 동작하는가
4. What — 구체 사양·옵션
5. What-if — 잘못 쓰면 어떻게 깨지는가
6. Insight — 흥미로운 이야기 / 비유
7. 요약 + Mermaid

3) 강조 포인트

  • “왜 모놀리식 변환 람다 하나가 망하는가” → 단계 분리의 필연성 (01)
  • “SQS visibility timeout이 작업 시간보다 짧으면 죽음의 루프가 만들어진다” (02)
  • “exactly-once는 환상이다” — 멱등 키 설계 (04)
  • “DLQ를 단순 보관소가 아니라 회수 자산으로” — funnel Lambda 패턴 (05)

What — 7개 문서 인덱스

#문서핵심 질문키워드
101-pipeline-pattern.md어떤 패턴으로 단계를 잇는가?파이프&필터, batch vs stream, orchestration vs choreography
202-queue-decoupling.md단계 사이에 무엇을 끼우는가?SQS·Kafka·Pub/Sub, backpressure, visibility timeout, in-flight
303-fan-out-fan-in.md분기와 병합은 어떻게 하는가?Step Functions Map, EventBridge fan-out, join-sync
404-idempotency.md중복 메시지를 어떻게 견디는가?idempotency key, dedupe window, exactly-once의 환상
505-error-classification-and-dlq.md실패를 어떻게 분류·회수하는가?transient vs permanent, retry policy, poison message, DLQ funnel
606-observability.md진실을 어떻게 보는가?OpenTelemetry, correlation ID, SLI/SLO, alarm threshold
707-cost-and-scaling.md어떤 컴퓨트를 고르는가?Lambda·Fargate·EC2·MediaConvert, GPU encoding, spot

What-if — 잘못 읽으면 어떻게 망가지는가

함정설명대응
이론 → 그대로 구현”Step Functions Map으로 fan-out하면 됨” 식의 단순 적용은 비용·디버깅에서 실패비용·복잡도·디버깅 가능성을 같이 평가
AWS 외 환경 무시이 챕터는 AWS 예시가 풍부하지만 GCP/Azure도 동등한 매핑 존재각 문서의 “타 클라우드 매핑” 섹션 참조
단일 큐 만능론”큐 하나로 다 받으면 됨” — schema 다른 메시지 섞이면 장애02의 “큐를 언제 분리하나”

Insight — 흥미로운 이야기

“Unix 파이프(1973)와 미디어 파이프라인의 거리”

Doug McIlroy의 Unix 파이프는 50년 전에 이미 정답을 보였다 — cat foo | grep bar | sort | uniq. 작은 도구를 작은 입출력 계약으로 잇는다. 차이는 단 하나 — Unix 파이프는 in-memory + synchronous, 클라우드 파이프라인은 persistent + asynchronous. 그래서 큐(02), 멱등(04), 회수(05)가 추가로 필요하다. 본질은 같다.

“파이프라인의 진짜 비용은 컴퓨트가 아니다”

AWS 청구서를 까보면 Lambda 비용은 전체의 30%를 넘기 어렵다. 진짜 비용은 (a) 데이터 전송(S3 cross-region, NAT), (b) 저장(미사용 S3, EBS), (c) MediaConvert minute 같은 종량제 매니지드. 이 챕터의 07은 그래서 컴퓨트 선택이 아니라 데이터 흐름 비용부터 본다.

한 화면 사용 가이드

  1. 새로 설계 시작 → 01 (패턴 골격) → 02 (큐 분리) → 04 (멱등 설계) 순으로 읽고 노트.
  2. 운영 중 장애 → 05 (에러 분류) + 06 (어디를 봐야 하나) 읽기.
  3. 비용 최적화 → 07 단독으로 읽기 가능. 02에 의존.
  4. 사례가 어떻게 풀었나 → 각 문서 끝에 추상화된 일반 패턴 메모 (구체 구현은 다루지 않는다 — 본 챕터는 이론 전용).

한 단락 요약

변환 파이프라인은 7가지 결정의 합이다 — 패턴(01), 큐(02), 토폴로지(03), 멱등(04), 에러(05), 관측(06), 비용(07). 각 결정은 독립이 아니다 — 큐를 어떻게 분리하느냐가 멱등 설계를 결정하고, 에러 분류 방식이 관측 대시보드를 결정한다. 이 챕터는 그 결정의 격자(grid)를 보여주고, 다음 챕터(08)는 한 가지 격자가 실제 코드로 어떻게 굳어지는지 보여준다.

08 — Player Engines (hls.js / Shaka / Video.js / ExoPlayer / AVPlayer)01. Pipeline Pattern — 파이프 & 필터, batch vs stream, 오케스트레이션 vs 코레오그래피