클라우드 Mac mini 영상 트랜스코딩 실전: FFmpeg + VideoToolbox 배치 파이프라인

지난주 영상 편집 외주 일을 하는 독자분이 티켓으로 이런 질문을 남겼습니다. 클라이언트가 4K ProRes 원본 200개를 던져주면서 H.264로 변환해서 납품해달라고 했는데, 노트북으로 한 편 트랜스코딩하는 데 18분이 걸려서 다 끝내려면 밤을 새워야 한다는 것이었습니다. 이런 작업의 병목은 알고리즘 선택이 아니라 항상 인코더의 처리량(throughput)입니다. 그리고 Apple Silicon의 VideoToolbox 하드웨어 인코더가 바로 대부분의 사람들이 과소평가하는 그 생산력입니다.

시나리오: 왜 트랜스코딩을 클라우드로 옮겨야 하는가

트랜스코딩은 전형적인 "간헐적 고부하" 작업입니다. 평소엔 거의 쓰지 않다가 납품 직전 며칠 동안 몰아서 터집니다. Mac Studio를 직접 구매해 상시 대기시켜 놓기엔 낭비이고, 클라우드 업체의 GPU 인스턴스는 대부분 CUDA 생태계에 최적화되어 있어 H.264/HEVC 하드웨어 인코딩은 오히려 소프트웨어 인코딩으로 우회해야 하는 경우가 많습니다. 독점형 Mac mini의 장점이 여기서 뚜렷하게 드러납니다. VideoToolbox는 시스템 레벨 API이기 때문에 가상화 계층을 가리지 않고, 하루 단위로 대여해서 작업이 끝나면 바로 반납할 수 있어 비용과 일정 모두 통제 가능합니다.

경험 법칙 하나: 한 편당 트랜스코딩 시간에 최대 동시 처리 개수를 곱하고, 다시 1.3배의 여유를 더한 값이 대여해야 할 일수입니다. "이론상 최대 속도"로 일정을 짜지 마세요 — 장비도 쉬어야 하고, 재시도가 필요하고, 버퍼가 필요합니다.

VideoToolbox는 정확히 무엇을 가속하는가

VideoToolbox는 H.264/HEVC의 움직임 추정(motion estimation), 변환·양자화 등 연산 집약적인 단계를 미디어 엔진(Media Engine)의 전용 하드웨어 모듈로 넘깁니다. CPU는 스케줄링과 컨테이너 처리만 담당합니다. 소프트웨어 인코딩인 libx264와 비교하면 다음과 같습니다.

이 차이의 대가는 화질입니다. 동일 비트레이트에서 VideoToolbox의 디테일 보존력은 x264 slow 설정보다 약간 떨어지지만, 일반적인 시청 거리에서는 눈에 띄지 않습니다. 배치 납품 용도로는 충분합니다.

환경 구축

설치 및 확인

클라우드 Mac mini를 받으면 먼저 하드웨어 인코더 사용 가능 여부를 확인합니다.

brew install ffmpeg
ffmpeg -encoders 2>/dev/null | grep videotoolbox

h264_videotoolbox와 hevc_videotoolbox 두 줄이 보이면 됩니다. 화질을 먼저 검증하고 싶다면 짧은 샘플 하나를 먼저 변환해 봅니다.

ffmpeg -i sample.mov \
  -c:v h264_videotoolbox -b:v 12M -tag:v avc1 \
  -c:a aac -b:a 192k \
  sample_out.mp4

인코딩 파라미터 비교표

배치 처리 전에 파라미터 템플릿을 미리 정해두세요. 원본마다 그때그때 파라미터를 바꾸면 출력 결과가 일관되지 않게 됩니다.

배치 파이프라인

명령어 한 줄 입력하는 건 누구나 할 수 있습니다. 진짜 시간을 아껴주는 건 "파일만 넣으면 결과가 자동으로 나오는" 프로세스를 파이프라인으로 만드는 것입니다.

디렉터리 모니터링 스크립트

폴링 스크립트로 입력 디렉터리를 감시하다가 새 파일이 발견되면 작업 큐에 넣습니다. 동시 실행 개수를 제한해서 하드웨어 인코딩 채널을 서로 뺏기지 않도록 합니다.

#!/bin/bash
WATCH_DIR="$HOME/incoming"
OUT_DIR="$HOME/transcoded"
MAX_JOBS=3

mkdir -p "$OUT_DIR"

while true; do
  for f in "$WATCH_DIR"/*.mov; do
    [ -e "$f" ] || continue
    base=$(basename "$f" .mov)
    lock="$OUT_DIR/${base}.lock"
    [ -e "$lock" ] && continue

    running=$(jobs -r | wc -l)
    if [ "$running" -ge "$MAX_JOBS" ]; then
      sleep 5
      continue
    fi

    touch "$lock"
    (
      ffmpeg -y -i "$f" \
        -c:v h264_videotoolbox -b:v 12M -tag:v avc1 \
        -c:a aac -b:a 192k \
        "$OUT_DIR/${base}.mp4" \
        && mv "$f" "$OUT_DIR/${base}.mov.done" \
        && rm -f "$lock"
    ) &
  done
  sleep 10
done

MAX_JOBS=3은 경험값일 뿐 만능 수치는 아닙니다. 기종마다 미디어 엔진의 인코딩 채널 수가 다르므로, 먼저 한 편만 처리해서 속도를 측정한 뒤 동시 실행 개수를 점진적으로 늘려보세요. 한 편당 소요 시간이 눈에 띄게 늘어나기 시작하면(보통 동시 처리 2~3개를 넘긴 시점) 그게 그 장비의 하드웨어 상한선입니다.

흔한 실수와 체크 항목

• 임시 파일은 로컬 SSD에 저장: 트랜스코딩 캐시를 네트워크 드라이브에 두지 마세요. I/O 지연이 발생하면 인코더가 대기 상태에 빠져 전체 처리량이 떨어집니다.
• 오디오 샘플링 레이트 불일치: 클라이언트 원본에 44.1kHz와 48kHz가 섞여 있는 경우가 있습니다. 배치 처리 전에 ffprobe로 한 번 스캔해서 통일하지 않으면, 합쳐진 완성본에서 음성과 영상이 어긋날 수 있습니다.
• 색공간 태그 누락: HDR 원본을 트랜스코딩할 때는 -colorspace bt2020nc -color_primaries bt2020 -color_trc smpte2084를 명시적으로 지정해야 합니다. 그러지 않으면 플레이어가 SDR로 해석해서 화면이 뿌옇게 나올 수 있습니다.
• 락 파일 잔류: 스크립트가 비정상 종료되면 .lock 파일이 남아 큐가 멈춥니다. 2시간 이상 지난 락 파일을 주기적으로 정리하는 로직을 추가하세요.
• 디스크 용량 계산: 트랜스코딩 전후로 파일이 동시에 존재하는 구간에서는 용량을 두 배로 차지합니다. 배치 작업 전에 전체 원본 용량이 기종 기본 스토리지의 70%를 넘지 않는지 미리 계산해두세요.

용량 계획: 어떤 등급을 대여해야 할까

영상 트랜스코딩은 메모리 대역폭과 스토리지 처리량에 더 민감하며, 칩 모델 자체는 결정적인 요인이 아닙니다. 일상적인 배치 납품(회당 수십 개의 4K 원본)이라면 M4R M(M4 / 24GB / 512GB SSD, $40.8/일, $203.9/월)로 기본적으로 충분합니다. 원본 용량이 크거나 여러 개의 HEVC 마스터를 동시에 처리하거나 멀티 트랙 합성 프리뷰를 해야 한다면, M4R L(M4 Pro / 64GB / 2TB SSD, $60.6/일, $302.8/월)의 넉넉한 메모리와 스토리지가 캐시 부족으로 인한 오류 중단을 피하는 데 더 여유롭습니다.

자주 묻는 질문