몇 달 전, 저는 주제 프롬프트를 전체 내레이션 다큐멘터리 영상으로 변환하는 파이프라인인 Crimetube를 구축하는 데 몰두하고 있었습니다. 이 모든 과정은 연구, 스크립트, 샷 계획, 이미지 생성, 비디오 생성, 보이스오버(voiceover) 등 모든 작업이 스스로 실행됩니다. 영상 하나에는 약 38개의 서로 다른 클러스터(cluster)에 걸쳐 200개 이상의 AI 생성 샷(shot)이 포함됩니다.

만약 여러분이 한 번에 여러 개의 AI 이미지나 비디오 클립을 생성해 본 적이 있다면, 제가 직면했던 문제를 이미 알고 계실 것입니다. 모델이 항상 말을 듣는 것은 아닙니다. 캐릭터의 의상이 중간에 바뀌기도 합니다. 특정 장소의 조명이 이전 샷과 갑자기 다르게 보이기도 합니다. 때로는 모델이 세 번이나 준 규칙을 그냥 무시해 버리기도 합니다.

초기에는 대략 10개 중 1개의 샷이 어떤 규칙을 위반하곤 했습니다. 잘못된 캐릭터 외형, 일관성 없는 색상, 유지되지 않는 연속성(continuity) 등 말이죠. 영상당 200개 이상의 샷이 들어간다는 점을 고려하면, 처리해야 할 오류 샷이 매우 많다는 뜻입니다.

게으른 해결책, 그리고 저의 첫 번째 해결책
저의 첫 번째 본능은 당연한 것이었습니다. 만약 한 클러스터의 샷에 문제가 있다면, 그냥 클러스터 전체를 다시 생성하는 것이었습니다. LLM에 다시 입력하여 다시 시도하게 만드는 방식이었죠.

기술적으로는 작동했습니다. 하지만 느리고 비용이 많이 들었습니다. 재생성할 때마다 또 다른 전체 LLM 호출(call)이 발생했고, 저는 단 한두 개의 잘못된 샷을 고치기 위해 실제로 괜찮은 샷들까지 다시 생성하는 경우가 많았습니다. 낭비적이었기 때문에 낭비처럼 느껴졌습니다.

저는 "AI에게 다시 던져주고 바라기"보다 더 스마트한 무언가가 필요했습니다.

대신 제가 구축한 것
결국 저는 모든 샷 배치가 생성된 후 실행되는 23개의 규칙을 가진 린트 패스(lint pass)를 구축하게 되었습니다. 코드의 린터(linter)와 비슷하다고 생각하면 됩니다. 다만 구문(syntax)을 확인하는 대신, 다음과 같은 사항들을 확인합니다: 이 샷이 고정된 캐릭터 설명과 일치하는가, 컬러 그레이딩(color grade)이 해당 장소의 스타일 락(style lock)과 일치하는가, 명백한 연속성 결함이 있는가 등입니다.

핵심 아이디어는 해결책을 두 개의 레이어(layer)로 나누는 것이었습니다.

첫 번째 레이어는 결정론적(deterministic)입니다. 23개 규칙 중 상당 부분은 일반적인 코드로 확인하고 수정할 수 있습니다. AI는 전혀 관여하지 않습니다.

단순한 정규 표현식 (regex) 수준의 수정, 직관적인 패턴 매칭 (pattern matching)입니다. 규칙 위반이 이 범주에 해당한다면, 즉시 비용 없이 수정됩니다.

두 번째 레이어는 남은 것들에 대해서만 작동합니다. 결정론적 (deterministic) 레이어가 제 역할을 다한 후에도 여전히 규칙을 위반하는 샷 (shot)들이 있다면, 이들은 타겟팅된 재생성 (regeneration)을 위해 다시 보내집니다. 클러스터 전체가 아니라, 특정 문제가 지적된 바로 그 샷 하나만 보내는 것입니다.

이 두 번째 부분이 제가 예상했던 것보다 더 중요했습니다. 이전에는 "문제를 해결하라"는 의미가 "모든 것을 다시 생성하고 운에 맡겨라"는 뜻이었습니다. 하지만 이제는 "고장 난 바로 그 부분만 정확히 다시 생성하고, 나머지는 건드리지 마라"는 의미가 되었습니다.

결과
위반 사항이 클러스터당 약 20개에서 8개 미만으로 감소했습니다. 이것만으로도 이미 상당한 개선입니다.

하지만 제가 실제로 더 신경 쓰는 부분은 비용 측면입니다. 대부분의 수정이 이제 코드 레이어에서 먼저 발생하기 때문에, 일반적인 경우 클러스터당 한 번의 전체 LLM 호출을 건너뛸 수 있습니다. 수십 개의 클러스터에 걸쳐 수백 개의 샷을 생성할 때, 불필요한 LLM 호출을 건너뛰는 것은 시간과 비용 모두에서 빠르게 누적됩니다.

이 패턴을 기억해야 하는 이유
LLM에 의존하여 많은 출력을 생성하는 무언가를 구축하고 있다면, 이 패턴을 반드시 기억해 둘 가치가 있다고 생각합니다. 무언가 잘못되었을 때의 본능은 모델에게 다시 던져버리는 것입니다. 하지만 모든 수정에 모델이 필요한 것은 아닙니다. 많은 문제들이 일반적인 코드로도 충분히 잡아내고 수정할 수 있을 만큼 단순하며, 값비싼 도구에 손을 뻗기 전에 코드가 이를 처리하도록 두어야 합니다.

실제로 판단 (judgment)이 필요한 부분에만 LLM을 아껴두세요. 저렴하고 결정론적인 (deterministic) 레이어가 나머지 모든 것을 처리하게 하십시오.

수정 작업을 "코드가 처리할 수 있는 것"과 "모델이 진정으로 필요한 것"으로 나누는 이 단 한 번의 전환이, 전체 파이프라인을 취약한 데모가 아닌 프로덕션 준비가 된 (production ready) 상태로 느끼게 만든 단 하나의 변화였을 것입니다.