EP.21 1소재로 블로그·쇼츠 동시 생산하는 파이프라인

들어가며: 쇼츠 채널의 최대 리스크는 '매일의 소재'

쇼츠 채널을 운영할 때 가장 큰 리스크로 본 건 매일 새 소재를 찾는 리서치 번아웃이었습니다. 소재를 계속 길어 올려야 한다는 부담은 채널 운영에서 무시하기 어려운 리스크입니다.
그런데 저에게는 이미 각 repo의 DEVLOG와 커밋을 블로그 소재로 harvest하는 파이프라인(ai-blog-agent)이 있었습니다. 이번 기록은 이 '같은 우물'을 쇼츠에서도 길어 쓰도록 배선을 깐 과정입니다. 목표는 단순합니다 — 1소재 → 블로그 1편 + 쇼츠 1편.

---

문제: 소재 파이프라인을 한 채널만 쓰고 있었다

블로그 harvest 파이프라인이 이미 DEVLOG·커밋에서 소재를 모으고 있었습니다. 이 결과를 쇼츠에서도 재사용하면 쇼츠를 위한 별도의 소재 리서치 비용을 크게 줄일 수 있다고 봤습니다.
핵심 아이디어는 이것이었습니다: 이미 소재를 뽑는 파이프라인이 있다면, 그 결과를 재사용하면 추가 리서치 비용이 사실상 0에 가까워진다.

---

시도: 소재층을 JSON으로 내보내고 쇼츠가 읽게 하기

구현은 두 조각으로 나눴습니다.

• blog-agent 쪽: collect_source_topics()가 소재를 구조화된 JSON(outputs/ideas/source-topics.json)으로도 내보내게 했습니다.
• coupang-shorts 쪽: app/source/build_log.py를 추가해 그 JSON을 읽어 쇼츠 소재 후보로 쓰게 했습니다.

여기서 중요한 설계 원칙 하나 — 소비 이력은 각자 관리합니다. '쇼츠로 이미 쓴 source_id'는 블로그와 독립적으로 관리해서, 블로그가 어떤 소재를 썼다고 해서 쇼츠가 그 소재를 못 쓰게 막히지 않도록 했습니다.

---

노이즈 줄이기: DEVLOG만 후보, 레포 순환

커밋 로그는 정보량 대비 노이즈가 많아, 기본 후보는 DEVLOG만 잡았습니다. 또 특정 레포에 소재가 쏠리지 않도록 레포를 순환시켜 후보를 뽑습니다.
실데이터로 검증했을 때, 전체 822개 항목에서 DEVLOG 후보로 19개가 선별되는 것을 확인했습니다.

---

배운 점: 합칠 것은 '소재'뿐, '생산'은 분리한다

가장 크게 배운 건 블로그와 쇼츠는 성공 공식이 반대라는 점입니다. 블로그는 검색, 쇼츠는 피드에 최적화됩니다. 그래서 '주제'까지 합치면 한쪽이 죽습니다.
합쳐야 할 것은 소재(출처)뿐이고, 생산(대본·글)은 반드시 분리해야 합니다. 정리하면:

• 소재층 = 포맷 중립(어느 채널이든 쓸 수 있게)
• 소비 이력 = 채널별로 각자 관리

이렇게 해야 소재 선정이 쇼츠 쪽으로 편향되지 않고, 블로그도 자기 리듬을 유지합니다.