콘텐츠파이프라인 썸네일형 리스트형 여러 채널을 함께 운영할 때, 합쳐야 할 것과 끝까지 분리해야 할 것 문제: 채널을 늘리면 소재 리서치가 병목이 된다블로그를 자동화로 굴리다가 쇼츠 채널을 추가하려 할 때 가장 먼저 마주치는 벽은 편집이 아니라 매일의 소재 리서치다. 채널이 하나 늘 때마다 '오늘 무엇을 다룰까'를 처음부터 다시 찾아야 하면, 채널 수에 비례해 번아웃이 커진다.실제 개발에서 이 문제를 만났을 때 상황은 이랬다. 블로그 에이전트(ai-blog-agent)는 이미 각 저장소의 DEVLOG와 커밋을 긁어와 글감으로 만드는 harvest 파이프라인을 갖고 있었다. 즉 소재를 길어 올리는 '우물'은 이미 파여 있었다. 쇼츠에도 같은 우물을 쓰게 하면 추가 리서치 비용이 0에 수렴한다는 발상이 여기서 나왔다.여기서 중요한 결정이 갈린다. 두 채널이 우물을 공유한다면 어디까지 공유하고 어디부터 분리할 .. 더보기 AI가 검사자 역할을 할 때 절대 시키면 안 되는 네 가지 문제: 검사자가 작가로 변하는 순간AI로 글을 만드는 흔한 구조는 두 단계다. 한 모델이 초안을 쓰고, 다른 모델이 그 초안을 검사한다. 필자가 운영하는 콘텐츠 파이프라인도 이 형태다. 초안은 한 모델이 쓰고 검사는 다른 모델이 맡는, 초안자 ≠ 검사자라는 규칙을 지킨다.이 구조에서 가장 흔히 예상되는 실패는 검사자가 조용히 작가로 변하는 것이다. "이 문장이 어색하니 이렇게 고치는 게 낫다"며 통째로 다시 써서 돌려주는 경우다. 얼핏 친절해 보이지만 이건 검사가 아니라 재작성이다. 검사자가 재작성을 하면 그 결과물은 아무도 검사하지 않은 새 글이 되어버린다. 검사 단계 자체가 무력화된다.이 글은 필자가 docs/content-generation-contract.md라는 문서에 명문화한 "검사자가 절대 .. 더보기 AI 티 안 나는 글은 문체가 아니라 소재 관리에서 나온다 문제: 문체를 아무리 다듬어도 AI 티가 남는 이유AI로 글을 자동 생성하면 가장 먼저 손대게 되는 것이 문체다. 어미를 바꾸고, 접속사를 줄이고, '~합니다'를 '~한다'로 통일한다. 그런데 이렇게 표면을 다듬어도 여러 글을 나란히 놓고 보면 여전히 인공적인 느낌이 남는다. 원인은 문장이 아니라 소재에 있다.일반 AI 주제 생성에 의존하면 글은 '한국 주식 자동화의 5가지 장점' 같은 어디서 본 듯한 일반론으로 수렴한다. 실제로 어느 레포에서, 어떤 기록을 근거로 나온 이야기인지 추적할 수 있는 출처가 없다. 사람이 쓴 글과 갈리는 지점은 바로 이 검증 가능한 구체성인데, 주제부터 추상적이면 문체를 어떻게 손봐도 채울 재료가 없다.실제 개발 파이프라인(EP.19)에서 내린 결론도 같았다. AI 티를 줄.. 더보기 EP.21 1소재로 블로그·쇼츠 동시 생산하는 파이프라인 들어가며: 쇼츠 채널의 최대 리스크는 '매일의 소재'쇼츠 채널을 운영할 때 가장 큰 리스크로 본 건 매일 새 소재를 찾는 리서치 번아웃이었습니다. 소재를 계속 길어 올려야 한다는 부담은 채널 운영에서 무시하기 어려운 리스크입니다.그런데 저에게는 이미 각 repo의 DEVLOG와 커밋을 블로그 소재로 harvest하는 파이프라인(ai-blog-agent)이 있었습니다. 이번 기록은 이 '같은 우물'을 쇼츠에서도 길어 쓰도록 배선을 깐 과정입니다. 목표는 단순합니다 — 1소재 → 블로그 1편 + 쇼츠 1편.문제: 소재 파이프라인을 한 채널만 쓰고 있었다블로그 harvest 파이프라인이 이미 DEVLOG·커밋에서 소재를 모으고 있었습니다. 이 결과를 쇼츠에서도 재사용하면 쇼츠를 위한 별도의 소재 리서치 비용을.. 더보기 EP.20 콘텐츠 생성 계약: 초안 Claude, 검사 GPT 2단계 이번에 한 일: 2단계 생성 계약을 정본으로 만들다블로그(ai-blog-agent)와 쇼츠(coupang-shorts-agent)가 공통으로 참조할 '콘텐츠 생성 계약'을 docs/content-generation-contract.md에 정본으로 신설했다.핵심 구조는 단순하다. 초안은 Claude가 쓰고, 검사는 GPT가 하는 2단계 파이프라인이며, 여기에 하나의 불변식을 못 박았다. 바로 초안자 ≠ 검사자다.왜 계약이 필요했나: 멀티모델의 두 가지 위험멀티모델 파이프라인을 굴리면서 정리하게 된 위험은 크게 둘이었다.초안자의 할루시네이션 — 원문(실제 기록)에 없는 사실·수치·경험을 만들어내는 문제.검사자의 월권 — 검사자가 판정만 하지 않고 글을 재작성하거나 새로운 사실을 덧붙이는 문제.이 둘을 문장으.. 더보기 EP.19 AI 주제 생성 대신 개발 기록으로 소재 큐 만들기 왜 AI 주제 생성을 버렸나블로그 자동화를 하다 보면 흔히 'AI에게 오늘의 주제를 뽑아 달라'고 시키게 된다. 하지만 이 방식은 실제 경험과 무관한 일반론을 양산하기 쉽고, 결과물에서 이른바 'AI 티'가 강하게 남는다.이번 작업의 출발점은 여기였다. 문체를 다듬어 AI 티를 지우는 대신, 애초에 글의 재료를 실제 개발 기록으로 바꾸기로 했다. 각 레포의 DEVLOG 항목과 커밋을 작은 단위로 쪼개 소재로 삼는 구조다.영구 source_id로 소재를 관리하기핵심은 모든 소재에 영구적인 식별자를 부여하는 것이다. DEVLOG 항목과 커밋마다 다음 정보를 저장하도록 했다.source_id: 소재를 영구적으로 식별하는 값출처: 어느 레포, 어느 기록에서 왔는지카테고리: 발행 시 분류에 사용원문: 실제 기록 .. 더보기 이전 1 다음
