# MoviePy vs Remotion 영상 렌더링 비교 분석

**일시**: 2026-03-13
**안건**: MoviePy vs Remotion — 품질/토큰효율/비용 종합 평가 및 벤치마크 설계
**미팅 모드**: hybrid
**토론 깊이**: thorough
**소집 페르소나**: 불칸(백엔드), 이리스(프론트), 야누스(DevOps), 아르고스(테스터), 로키(레드팀/DA)

---

## Cycle 1 — Independent Round

### 아누 분석

제이회장님이 MoviePy 영상의 "끊기는 느낌"을 지적. Remotion으로 전환 검토.
핵심 판단 포인트: 끊기는 원인이 엔진 한계인가, 구현 미흡인가?

근거:
- MoviePy animations.py에 5종 애니메이션 존재하나, easing 함수(cubic-bezier, spring) 적용 여부 미확인
- Remotion은 `spring()` 물리 기반 애니메이션 기본 제공 → 부드러움 구조적 보장
- 서버 7.7GB RAM → Remotion Chromium 추가 시 OOM 리스크

### 페르소나 의견

**불칸(백엔드)**: 진단 먼저. ffprobe로 프레임 타임스탬프 확인 → easing 교체 시도(2~4시간). 해결 안 되면 Remotion. 토큰 효율은 MoviePy가 2~3배 유리 (단일 언어 스택). 비관습적 대안: FFmpeg 직접, Playwright+Python, Manim.

**이리스(프론트)**: Remotion 전환 권고. spring 물리 애니메이션, CSS 레이아웃, HMR 프리뷰 — 에반 6원칙 중 4개가 Remotion에서 현저히 쉬움. 한글 word-break: keep-all, 서브픽셀 안티앨리어싱 등 타이포그래피 품질 우위. 디자인 반복 속도 10배 향상.

**야누스(DevOps)**: MoviePy easing 개선 1순위. 7.7GB에서 Remotion 운영은 OOM 리스크 중~고 (렌더링 피크 시 5.5~6.5GB 사용). Remotion 도입 시 16GB 업그레이드 사실상 필수(월 $10~$50). 운영 복잡도: 장애 포인트 1개→4개. 대안: 별도 렌더링 VPS($12/월).

**아르고스(테스터)**: 3-way 벤치마크 설계 제안. (A) MoviePy 현재, (B) MoviePy 최적화, (C) Remotion. Optical Flow로 끊김 객관화. MoviePy도 easing 적용 후 비교해야 공정. 판정 기준 사전 합의 필수. 11시간/2~3일 소요.

**로키(레드팀/DA)**: 엔진 전환 = "문제 이동" 가능성. Chromium 공격 면적 5레이어 증가. inputProps 주입 → XSS/RCE 경로. OOM killer가 봇 프로세스를 죽일 위험. npm 공급망 공격 리스크. 라이선스 lock-in. easing 3줄 수정으로 해결 가능한 문제에 마이그레이션은 낭비.

### Devil's Advocate (Cycle 1)

**지정**: 로키 (필수 참석)

1. **실패 시나리오**: easing이 원인이 아닌 경우에도 Remotion이 해결책이 아닐 수 있음. Chromium 스크린샷 방식도 프레임 불균일 가능.
   - **반박**: Remotion은 프레임 번호 기반 결정론적 렌더링. useCurrentFrame()은 순수 함수로 동작하므로 프레임 불균일 문제 구조적으로 없음. (근거: remotion-deep-dive.md 1.1절)
   - **판정**: 반박 수용. 단, 진단 먼저 접근 자체는 유효.

2. **후회 이유**: Remotion 라이선스 변경 시 전체 재작성 필요. 성장할수록 비용 증가.
   - **반박**: 현재 3인 이하 무료 충족. 유료 전환해도 $25/시트/월. 완전 대체재(Manim, FFmpeg)가 존재하므로 lock-in 정도는 관리 가능.
   - **판정**: 일부 수용. 라이선스 모니터링 필요하나 즉각적 리스크는 낮음.

3. **더 단순한 대안**: MoviePy easing 교체(cubic-bezier) + fps 30 확인.
   - **평가**: 가장 합리적. 비용 0, 리스크 0, 시간 2~4시간.
   - **판정**: 수용. 이것을 Step 1으로 실행.

### 비관습적 대안 (Cycle 1)

**제시자**: 불칸

**대안: Playwright + Python 직접 브라우저 렌더링**
- Remotion 없이 Python에서 HTML/CSS를 Chromium으로 렌더링
- 최강 지지: Python 단일 스택 유지 + 브라우저 렌더링 품질
- 최강 반론: Remotion의 Composition/Sequence/spring 추상화 없이 직접 구현 = 바퀴 재발명
- 이상적 시나리오: Remotion 라이선스가 문제될 때
- 노력: 높음 (프레임 관리, 타이밍, 인코딩 직접 구현)
- 리스크: 높음 (커뮤니티 없음, 검증 안 됨)
- **판정**: 기각. 참고용으로 보존.

---

## 최종 합의

### 핵심 결론: "진단 → 최적화 → 벤치마크 → 결정" 4단계 접근

**Step 1 (즉시, 2~4시간)**: MoviePy 진단 + 최적화
- `ffprobe`로 현재 영상 fps, 프레임 타임스탬프 확인
- `animations.py` easing 함수 확인 → cubic-bezier 또는 ease_in_out_cubic 적용
- fps 30 확인 (24fps면 즉시 수정)
- 최적화 영상 생성

**Step 2 (Step 1 결과에 따라 분기)**:
- **끊김 해소됨**: MoviePy 유지. Remotion 전환 불필요. 종료.
- **개선되었으나 부족**: Step 3(벤치마크)으로 진행
- **거의 차이 없음**: Remotion이 구조적으로 필요한 것일 수 있음 → Step 3

**Step 3 (필요시, 2~3일)**: 3-way 벤치마크
- 동일 콘텐츠(보험 팁 5슬라이드, 30초)로 3개 영상 생성
  - A: MoviePy 현재
  - B: MoviePy 최적화(easing + fps 30)
  - C: Remotion 구현
- 측정: Optical Flow(부드러움), 렌더링 시간/메모리, side-by-side 비교 영상
- 제이회장님 블라인드 시청 평가

**Step 4**: 벤치마크 결과 + 제이회장님 판단 → 최종 결정

### 인프라 조건 (Remotion 선택 시)
- 현재 7.7GB → 16GB 업그레이드 필요 (월 $10~$50 추가)
- 또는 별도 렌더링 VPS 분리 ($12/월)
- concurrency=1 고정, systemd MemoryMax 설정

### 토큰 효율 참고
- MoviePy: 수정당 ~300~500 토큰 (Python 단일 스택)
- Remotion: 수정당 ~800~1,200 토큰 (React + 브릿지 양쪽)
- 장기 누적 시 MoviePy가 토큰 효율 2~3배 유리

---

## 미해결 항목
- 벤치마크 "합격 기준" 사전 합의 (Optical Flow 점수 몇 % 개선이면 Remotion?)
- MoviePy 최적화로 충분한 경우 Remotion 검토 완전 종료 여부
- task-519(Remotion Phase 0+1) 방향 수정: 카드뉴스 POC → 영상 POC + 벤치마크용

---

## 참고 자료
- `memory/research/remotion-deep-dive.md` (task-434.1, dev1)
- `memory/research/remotion-video-automation.md` (task-342.1, dev2)
- `memory/tasks/dispatch-threads-video-evan-style.md`
- `memory/meetings/2026-03-07-dialogue-video-quality.md`