매일 돌아가는 잡이 하나 늘었습니다
개발 블로그 글을 짧은 영상으로 바꿔 올리는 파이프라인이 있습니다. 그동안 대본은 사람이 손으로 만들었고, 렌더링과 발행 큐는 자동이었습니다. 이번에 그 앞단까지 자동으로 바꿨습니다.
흐름은 단순합니다. 아직 영상으로 바뀌지 않은 블로그 글을 하나 고르고, LLM CLI에 넘겨 대본 JSON으로 변환하고, 구조 검사를 통과하면 렌더링한 뒤 발행 큐를 다시 만듭니다. 이 작업은 macOS launchd로 매일 오전 10시에 실행됩니다. 발행이 11시라서 그보다 한 시간 앞에 두었습니다.
여기까지는 흔한 자동화입니다. 제가 오래 고민한 건 하나였습니다. 이 잡은 언제 멈춰야 할까요?
자기 프로젝트에 대입해 보셔도 좋겠습니다. 매일 무언가를 만들어 내는 자동화를 돌리고 있다면, 그 입력은 유한한가요, 아니면 LLM이 무한히 만들어 낼 수 있는 쪽인가요?
쉬운 길은 무한 생성이었습니다
LLM으로 대본을 만든다면 원본이 굳이 필요하지 않습니다. 주제 목록만 넣어도 대본은 끝없이 나옵니다. 큐가 마를 일도 없습니다.
문제는 그 대본들이 무엇에 근거하느냐입니다. 이 채널의 영상은 제가 실제로 겪은 일을 기록한 블로그 글을 요약한 것입니다. 원본 없이 만든 대본은 근거가 없는 대본입니다. 겉보기엔 같은 형식이라도, 제가 겪지 않은 사건과 제가 재지 않은 숫자가 섞여 들어갈 수 있습니다.
당신이라면? 큐가 비는 날을 막으려고 생성량을 늘리시겠습니까, 아니면 큐가 비는 걸 받아들이시겠습니까?
원본을 실제 글로 묶었습니다
저는 후자를 골랐습니다. 대본 생성기의 원본은 실제로 발행된 블로그 글뿐입니다. 커밋 당시 그 수는 27편이었습니다. 생성기는 아직 변환되지 않은 글 중에서 하나를 고르고, 고를 글이 없으면 아무것도 만들지 않습니다. 따로 중단 조건을 두지 않아도, 원본이 떨어지면 저절로 멈추는 구조입니다.
고르는 순서도 정했습니다. 글마다 붙어 있는 후크 유형에 우선순위를 두고, 높은 쪽부터 변환합니다. 유한한 원본을 쓸 거라면 어떤 글부터 쓸지는 정해 둬야 한다고 봤습니다.
LLM이 만든 JSON은 바로 렌더링하지 않고 구조 검사를 먼저 거칩니다. 형식이 어긋난 대본은 렌더링 단계까지 가지 않습니다. 통과한 대본만 렌더링되고, 그 뒤에 한국어와 영어 발행 큐가 다시 만들어집니다.
값싼 해결책이 없는 부분
이 설계에는 대가가 있습니다. 원본이 27편이면 영상도 27개 근처에서 끝납니다. 그 뒤에 큐를 채우는 방법은 글을 더 쓰는 것뿐입니다. 자동화가 병목을 없애 준 게 아니라, 병목을 제가 글을 쓰는 속도로 옮겨 놓은 셈입니다.
이 병목을 풀어 주는 설정 값이나 스위치는 없습니다. 무한 생성으로 바꾸면 큐는 마르지 않겠지만, 그러면 이 채널이 기록 기반이라는 전제가 깨집니다. 저는 큐가 마르는 쪽을 택했습니다.
자가진단 체크리스트
- 매일 도는 생성 잡의 입력이 유한한지, 떨어지면 잡이 무엇을 하는지 한 문장으로 설명할 수 있습니까?
- LLM 출력이 다음 단계(렌더링, 발행)로 넘어가기 전에 형식을 검사하는 관문이 있습니까?
- 생성 잡과 발행 잡의 실행 시각 사이에 생성이 끝날 여유를 두었습니까?
솔직한 부분
이 글은 자동화를 붙인 커밋 하나에 근거합니다. 생성된 대본의 품질이 손으로 쓴 대본과 비교해 어떤지, 이 영상들이 어떤 반응을 얻었는지는 아직 모릅니다. 구조 검사는 JSON 형식을 보는 것이지 내용이 원본 글과 맞는지까지 보장하지는 않습니다. 오전 10시와 11시 사이의 한 시간이 생성과 렌더링에 늘 충분한지도 확인하지 않았습니다. 27편이 모두 소진된 뒤 큐가 비는 날에 파이프라인이 어떻게 보일지도 아직 겪어 보지 않았습니다.