여러 채널을 함께 운영할 때, 합쳐야 할 것과 끝까지 분리해야 할 것

문제: 채널을 늘리면 소재 리서치가 병목이 된다

블로그를 자동화로 굴리다가 쇼츠 채널을 추가하려 할 때 가장 먼저 마주치는 벽은 편집이 아니라 매일의 소재 리서치다. 채널이 하나 늘 때마다 '오늘 무엇을 다룰까'를 처음부터 다시 찾아야 하면, 채널 수에 비례해 번아웃이 커진다.
실제 개발에서 이 문제를 만났을 때 상황은 이랬다. 블로그 에이전트(ai-blog-agent)는 이미 각 저장소의 DEVLOG와 커밋을 긁어와 글감으로 만드는 harvest 파이프라인을 갖고 있었다. 즉 소재를 길어 올리는 '우물'은 이미 파여 있었다. 쇼츠에도 같은 우물을 쓰게 하면 추가 리서치 비용이 0에 수렴한다는 발상이 여기서 나왔다.
여기서 중요한 결정이 갈린다. 두 채널이 우물을 공유한다면 어디까지 공유하고 어디부터 분리할 것인가. 이 선을 잘못 그으면 한쪽 채널이 다른 쪽에 끌려가 죽는다.

---

왜 위험한가: 블로그와 쇼츠는 성공 공식이 반대다

블로그는 검색으로 산다. 특정 질문을 가진 사람이 검색해서 들어오고, 길고 구체적인 답이 있을수록 오래 머문다. 쇼츠는 피드로 산다. 아무 의도 없이 흘러가던 사람의 손가락을 몇 초 안에 멈춰 세워야 하고, 짧은 시간 안의 강한 후킹이 특히 중요하다.
이 둘은 지향이 반대다. 그래서 '소재'가 아니라 '주제 선정 로직'까지 합치면 문제가 생긴다. 소재 선정이 쇼츠에 유리한 쪽(짧고 자극적인 것)으로 편향되면 블로그의 검색 소재가 마르고, 반대로 블로그에 맞추면 쇼츠가 밋밋해진다. 합칠 수 있는 건 출처(소재)뿐이고, 그것을 어떻게 요리하느냐(생산)는 각자 달라야 한다는 원칙이 여기서 나온다.
또 하나의 함정은 '소비 이력'이다. 블로그가 어떤 소재를 이미 글로 썼다고 해서 쇼츠까지 그 소재를 못 쓰게 막으면, 한 채널의 진행 상황이 다른 채널을 방해한다. 우물은 같이 쓰되, 각자 어디까지 길어 썼는지는 따로 기록해야 한다.

---

합칠 것과 분리할 것을 나누는 기준

실제로 배선한 구조는 세 층으로 나뉜다. 이 표가 판단 기준이 된다.

소재(출처)	공유	같은 우물을 쓰면 추가 리서치가 0. DEVLOG·커밋이라는 출처는 포맷과 무관하다
소비 이력(어디까지 썼나)	분리	블로그가 쓴 소재를 쇼츠가 못 쓰면 한쪽이 다른 쪽을 막는다
생산(대본/글 만들기)	분리	검색용 긴 글과 피드용 짧은 후킹은 성공 공식이 반대다

핵심 표현으로 정리하면 '소재층은 포맷 중립, 소비 이력만 각자'다. 소재를 담는 그릇은 특정 채널의 색을 띠지 않아야 한다. 그래야 소재 선정이 어느 한쪽으로 기울지 않는다.

---

어떻게 배선하는가: 실제 구현 절차

블로그와 쇼츠를 예로 든 실제 순서는 다음과 같다. 자기 환경의 채널 두 개로 바꿔 읽으면 된다.

1. 소재를 구조화 파일로 내보낸다. blog-agent의 harvest가 소재를 모으는 collect_source_topics()가, 사람이 읽는 글감 외에 기계가 읽을 JSON을 별도로 내보내게 했다. 경로는 outputs/ideas/source-topics.json. 이 파일이 두 채널의 공용 우물이다.
2. 다른 채널은 그 JSON을 읽기만 한다. 쇼츠 쪽(coupang-shorts)에 app/source/build_log.py를 새로 만들어 위 JSON을 읽게 했다. 소재를 다시 리서치하지 않고 이미 파인 우물을 그대로 쓴다.
3. 소비 이력은 각 채널이 따로 관리한다. '쇼츠로 이미 쓴 source_id'를 쇼츠가 독립적으로 기록한다. 블로그가 썼는지 여부는 쇼츠의 후보 선정에 영향을 주지 않는다.
4. 후보를 걸러 노이즈를 줄인다. 기본값은 DEVLOG만 후보로 삼았다. 커밋 메시지는 노이즈가 많아 소재로 부적절한 경우가 많기 때문이다.
5. 쏠림을 막는다. 여러 저장소를 순환하며 소재를 뽑아, 특정 저장소에만 소재가 몰리지 않게 했다.

검증은 실데이터로 했다. 원천 822개 항목에서 DEVLOG만 걸러 후보 19개로 선별되는 것을 확인했다. 숫자가 이렇게 줄어드는 것 자체가 필터가 작동한다는 증거다.

---

잘못 배선하면 어떻게 되는가

주의해야 할 실수 중 하나는 소비 이력을 공유하는 것이다. '이미 쓴 소재는 두 번 안 쓴다'는 규칙이 합리적으로 보여서 두 채널이 하나의 '사용 완료' 목록을 공유하게 만드는데, 이렇게 하면 블로그가 좋은 소재를 먼저 소진하는 순간 쇼츠는 그 소재를 영영 못 쓴다. 채널마다 소재를 다루는 각도가 다른데도 말이다.
반대로 생산 로직을 공유하면, 소재 선정이 한쪽 채널의 취향으로 편향된다. 쇼츠에 맞춰 '짧고 자극적인' 소재만 우선순위가 높아지면 블로그의 검색 소재가 마른다. 이 경우 두 채널을 합친 이점(리서치 절감)은 얻지만, 한 채널의 품질을 잃는다. 그래서 합치는 것은 이득이 명확한 소재층 하나로 제한하는 것이 안전하다.

---

체크리스트와 한계

여러 채널을 동시에 운영하며 자원을 공유할 때 다음을 확인한다.

• 공유하려는 것이 '출처(소재)'인가, 아니면 '주제 선정 로직'이나 '소비 이력'까지 넘어가는가?
• 소재를 담는 형식이 특정 채널 색을 띠지 않는 포맷 중립인가?
• 각 채널이 '어디까지 썼는지'를 독립적으로 기록하는가?
• 노이즈가 많은 출처를 기본 후보에서 제외했는가?
• 특정 출처에 소재가 쏠리지 않게 순환 로직이 있는가?

한계도 분명하다. 이 구조는 두 채널의 소재 우물이 실제로 겹칠 때만 이득이 있다. 개발 기록처럼 공통 원천(DEVLOG)이 있는 경우가 그렇다. 성격이 완전히 다른 채널이라면 우물부터 다를 수 있어 억지로 합칠 이유가 없다. 또 여기 적은 숫자(822→19)는 특정 시점의 특정 저장소 데이터일 뿐, 다른 환경에서 같은 비율이 나온다는 보장은 없다. 원칙만 가져가고 값은 각자 측정하는 것이 맞다.