아키텍처 썸네일형 리스트형 여러 채널을 함께 운영할 때, 합쳐야 할 것과 끝까지 분리해야 할 것 문제: 채널을 늘리면 소재 리서치가 병목이 된다블로그를 자동화로 굴리다가 쇼츠 채널을 추가하려 할 때 가장 먼저 마주치는 벽은 편집이 아니라 매일의 소재 리서치다. 채널이 하나 늘 때마다 '오늘 무엇을 다룰까'를 처음부터 다시 찾아야 하면, 채널 수에 비례해 번아웃이 커진다.실제 개발에서 이 문제를 만났을 때 상황은 이랬다. 블로그 에이전트(ai-blog-agent)는 이미 각 저장소의 DEVLOG와 커밋을 긁어와 글감으로 만드는 harvest 파이프라인을 갖고 있었다. 즉 소재를 길어 올리는 '우물'은 이미 파여 있었다. 쇼츠에도 같은 우물을 쓰게 하면 추가 리서치 비용이 0에 수렴한다는 발상이 여기서 나왔다.여기서 중요한 결정이 갈린다. 두 채널이 우물을 공유한다면 어디까지 공유하고 어디부터 분리할 .. 더보기 EP.21 1소재로 블로그·쇼츠 동시 생산하는 파이프라인 들어가며: 쇼츠 채널의 최대 리스크는 '매일의 소재'쇼츠 채널을 운영할 때 가장 큰 리스크로 본 건 매일 새 소재를 찾는 리서치 번아웃이었습니다. 소재를 계속 길어 올려야 한다는 부담은 채널 운영에서 무시하기 어려운 리스크입니다.그런데 저에게는 이미 각 repo의 DEVLOG와 커밋을 블로그 소재로 harvest하는 파이프라인(ai-blog-agent)이 있었습니다. 이번 기록은 이 '같은 우물'을 쇼츠에서도 길어 쓰도록 배선을 깐 과정입니다. 목표는 단순합니다 — 1소재 → 블로그 1편 + 쇼츠 1편.문제: 소재 파이프라인을 한 채널만 쓰고 있었다블로그 harvest 파이프라인이 이미 DEVLOG·커밋에서 소재를 모으고 있었습니다. 이 결과를 쇼츠에서도 재사용하면 쇼츠를 위한 별도의 소재 리서치 비용을.. 더보기 이전 1 다음
