리스크를 안은 제품 결정(실질적 변형 정책)을 기술 설계보다 먼저 내리면, 시스템이 그 정책을 매번 기억해 수동 적용하는 대신 구조적으로 강제하게 만들 수 있다.

배경
2편에서 다룬 Project Persona는 Argus(다단계 자율 파이프라인 프레임워크) 아래 등록된 프로젝트 중 하나로, AI 캐릭터 콘텐츠 자동화 시스템이다. 2편에서는 그 파이프라인이 4개월간 조용히 죽어있던 버그 네 개를 고치는 이야기를 다뤘다. 이번 편은 그 파이프라인이 애초에 무엇을 하도록 지어졌는지 — 실제 콘텐츠를 만들어내는 엔진 자체의 아키텍처 — 를 다룬다.
목표는 원본 리소스 수집부터 멀티플랫폼 업로드까지 이어지는 완전 자동화 파이프라인으로, 서로 다른 콘텐츠 스타일을 가진 여러 채널 ("트랙")을 사람 개입 최소화로 동시에 운영하는 것이었다. 트랙은 의도적으로 성격을 다르게 섞었다: 페이스리스/내레이션 기반 롱폼인 트랙 A, AI아바타/오리지널 캐릭터 기반 숏폼인 트랙 B. 각기 다른 제작 방식이 필요했다.
제약은 대부분 스스로 부과한 것이었지만 실제로 작동했다: 전용 제작 예산 없음(모든 도구는 무료/오픈소스이거나 이미 라이선스 확보된 것이어야 함), Argus의 에이전트/스케줄링 인프라 외에 기존 인프라 없음, 그리고 법적 리스크가 각주가 아니라 1급 제약조건이었다는 점 — 계획된 트랙 A 스타일 중 하나(타인 영상을 소스로 하는 오토클립 리액션 콘텐츠)는 부주의하게 다루면 실제 2차 저작물·이용약관 리스크를 안고 있었다.
코드보다 먼저 나온 결정
아키텍처를 건드리기 전에 미루기 쉬운 질문에 먼저 답을 냈다: 오토클립 콘텐츠 스타일에서, 타인 콘텐츠 재사용 중 정확히 어디까지가 허용 가능한가? 가장 단순한 버전 — 인기 클립을 다운로드해 세로로 크롭하고 자막만 얹어 재업로드 — 은 저품질 리액션 콘텐츠의 흔한 패턴이자, 실질적 변형 없는 2차 저작물로 신고당할 가능성이 가장 높은 패턴이기도 했다.
생성 레이어를 설계하기 전에 이 패턴을 아예 배제하기로 결정했다: 타인 콘텐츠 기반 오토클립은 반드시 내레이션·분석·편집적 해석 같은 실질적 변형을 더해야 하며, 원본 그대로 재업로드는 허용하지 않는다. 이건 법무 승인이 아니라 개인 엔지니어링 판단이었고, 설계 단계에서 의도적으로 내린 이유는 오토클리핑 레이어가 나중에 생략될 수 있는 선택적 마무리가 아니라 필수 단계로 만들어지도록 하기 위해서였다.
조사 — 특정 구성요소를 확정하기 전에 생태계부터 비교
다섯 레이어 각각에 대해 처음 발견한 도구를 그냥 쓰지 않고 오픈소스 생태계를 비교했다. 가장 중요했던 비교는 오토클립/생성 레이어였다. GitHub 스타가 가장 많은 걸 고르는 대신 실제 요구사항으로 평가했다: 하이라이트 검출은 트랜스크립트 기반이어야 파이프라인 다른 곳의 전사 단계와 매끄럽게 결합되고, 출력은 자막이 번인된 세로 크롭 리프레임이어야 한다는 것. 이 기준으로 후보군이 하나의 아키텍처 패턴 — 전사 기반 하이라이트 검출 + 리프레임 + 자막 번인 — 으로 좁혀졌다.
솔루션 / 아키텍처 — 5개 레이어
레이어 1 — 리소스 수집. 라이선스 스톡 미디어 API, 다운로드 유틸리티, 다운로드·전사(Whisper)·TTS를 한 단계로 묶은 올인원 도구. 콘텐츠 정책이 구조적으로 강제되는 지점이기도 하다 — 자체 제작했거나 명시적으로 검증 가능한 라이선스를 확보한 소재만 실제 채널로 넘어갈 수 있다.
레이어 2 — 오토클리핑 / 콘텐츠 생성. 트랙 A는 전사 기반 하이라이트 검출 + 세로 리프레임 + 자막 번인을 실행하며, 실질적 변형 정책이 필수 내레이션/분석 단계로 강제된다. 트랙 B는 앵커 프레임 기반 텍스트-투-이미지 캐릭터 생성을 모션그래픽으로 합성한다. 구현은 갈라지지만 레이어 경계는 동일하다.
레이어 3 — 후처리 / 품질 강화. 업스케일링, 프레임 보간, 합성 효과음과 피크 정규화·리미터. 이 레이어는 자동화된 수치 기반 QC 게이트(스트림 존재 여부, 클리핑 임계값, 자막 경계)도 담고 있다 — 다음 편에서 이 QC가 실제로 얼마나 부족했는지 더 깊게 다룬다.
레이어 4 — 업로드 / 배포. 공식 플랫폼 API가 정식 OAuth로 주요 플랫폼을 처리하고, 공개 콘텐츠 API가 없는 플랫폼은 서드파티 유틸리티가 커버한다. 두 트랙 모두 독립적으로 발행되며 트랙에 맞는 메타데이터를 쓴다.
레이어 5 — 오케스트레이션. 새로운 워크플로우 엔진을 도입하는 대신 이미 운영 중이던 Argus 인프라를 재사용했다 — Project Persona는 이렇게 Argus 아래 등록된 여러 프로젝트 중 하나가 됐다. 새 인프라를 들이기 전에 "이미 무료로 가진 것"을 먼저 확인하는 원칙은 이 프로젝트 말고도 여러 곳에서 반복됐다.
Before / After: 스크립트 더미에서 패키지로
프로토타입 단계의 흔한 모습 — 생성 스크립트 하나, ffmpeg 셸스크립트 몇 개, API 헬퍼를 각각 재구현한 독립 리서치 스크립트 세 개 — 를 아키텍처 레이어 경계와 맞아떨어지는 정식 파이썬 패키지(pipeline/)로 리팩터링했다. 중복 API 헬퍼 세 벌을 하나로 합치면 레이트리밋 대응이 한 번만 이루어지면 되고, 자막/오디오/영상 조립 로직을 분리하면 한 트랙에서 고친 버그가 다른 트랙에도 자동으로 적용된다. 이 리팩터링이 동작을 바꾸지 않았음을 검증하려고, 기존 결과물을 새 진입점으로 다시 빌드해 원본 셸스크립트 결과물과 체크섬을 비교했고 — 세 건 모두 완전히 일치(md5 동일)했다.
검증
- 구조적으로 다른 두 트랙(오토클립 스타일, AI아바타 스타일)이 레이어 1/3/4/5 로직 중복 없이 같은 다섯 레이어를 통과해 동작.
- 리팩터링이 기존 결과물을 바이트 단위로 동일하게 재생산(md5 일치) — 재구조화가 동작을 조용히 바꾸지 않았음을 확인.
- 완전히 새로운 스토리 입력에 대한 엔드투엔드 스모크 테스트를 패키지화된 단일 명령으로 성공.
이번 편은 아키텍처만큼이나 의사결정 습관에 관한 이야기다: 리스크를 안고 있는 제품 결정(실질적 변형 정책)을 기술 설계보다 먼저 내려, 시스템이 그 정책을 구조적으로 강제하도록 만드는 것. 그리고 새 도구 도입보다 이미 갖고 있는 인프라(Argus)를 우선 재사용하는 성향 — 실제 규모가 그 질문을 강제하기 전까지는.
---
이 글은 완전 자율 콘텐츠 파이프라인 구축기 4부작 중 첫 편이다. 다음 편([21편](./21-persona-qc-consistency.ko.md))에서는 이 아키텍처 위에서 트랙 B(AI아바타)가 실제 운영 물량으로 돌아가며 터진 문제들 — 씬 간 캐릭터 드리프트, 그리고 그걸 잡기 위해 필요했던 자동화 QC — 를 다룬다.
첫 댓글을 남겨보세요