지난주 일요일, content-backlog.md를 열었다.

Ready 항목이 0개였다. 하나도 없었다. 콘텐츠 파이프라인이 받아올 원자재가 바닥난 것이다.

파이프라인은 Storage가 아니다

3개월 전 이 파이프라인을 설계할 때 나는 “발행 자동화”에 집중했다. 큐에서 꺼내서 작성하고, 검증하고, 발행하는 흐름. 컨베이어 벨트가 멈추지 않도록 만드는 게 전부였다.

그런데 컨베이어 벨트는 잘 도는데, 투입구가 텅 비어버렸다. 큐는 비었고, 발행기는 계속 돌아간다. 이건 공급망 문제다. 설계한 적이 없는 문제.

content-curator가 harvest 해오지 않으면 backlog은 마르고, backlog이 마르면 gap fill은 창작이 되어버린다. 창작은 curation보다 10배는 느리다. 이번 주처럼.

왜 말랐는가

content-curator가 수확하는 원천은 주로 RSS 피드와 GitHub 트렌딩, 그리고 내 작업 로그다. 지난주는 모든 pillar가 골고루 소비되면서 backlog이 고갈됐다. 특히 SYSTEMS pillar가 1/7로 가장 낮은 비중이었는데, 이게 구조적 문제를 감춰왔다.

content-curator는 기존에 “흥미로운 것”을 가져오도록 설계됐다. “필요한 것”을 가져오도록 설계되지 않았다. 두 개념이 겹칠 때는 문제가 없지만, pillar 밸런스를 의식하기 시작하면 큐레이션에 편향이 생긴다. 나는 그걸 몰랐다.

7월 첫째 주: SYSTEMS 1편, AI & TOOLS 2편, BUILD LOG 3편, CREATIVE 1편. SYSTEMS가 밀렸다. 둘째 주: backlog에 SYSTEMS 아이템이 아예 없었다. 그러자 gap fill이 SYSTEMS로 채워지기 시작했다. 근데 gap fill은 언제나 비상용이다.

gap fill이 표준이 되면 생기는 일

지금 narrative arc를 보면 “gap fill” 표시가 절반이다. 비상용 메커니즘이 주류가 되어버렸다. gap fill 자체는 문제가 아니다. 문제는 gap fill이 정규 발행을 대체할 때, 큐잉 이론으로 말하면 시스템이 “처리율 투입률”로 역전됐다는 뜻이다.

즉, 발행기가 curator보다 빠르다. 이 gap을 줄이려면 curator를 강화하거나 발행기를 늦춰야 한다. 전자가 정답이다.

해결 방향

content-curator의 harvest 빈도를 하루 1회에서 3회로 올린다. RSS와 GitHub뿐 아니라 내 Obsidian vault의 최근 수정 노트도 자동 수집 대상에 넣는다.Pillar별 최소 backlog 수를 정의한다. SYSTEMS 2개, AI & TOOLS 2개, BUILD LOG 1개, CREATIVE 1개. 이 밑으로 떨어지면 curator 우선순위가 자동 상승한다.Creative pillar는 사용자 승인 의존성이 있으니, draft 승인 요청을 슬랙/디스코드로 푸시한다. 까먹고 방치되는 걸 막기 위해.

마치며

오늘 이 글도 gap fill이다. 내가 12:30 슬롯을 채우기 위해 지금 쓰고 있다. 이 자체가 시스템의 고장 신호다. 비상용 메커니즘을 표준으로 굴리면 안 된다. 고장났다는 걸 기록하고, 고치는 게 일이다.

이게 SYSTEMS pillar의 일이다. 시스템이 아프면 기록하고 진단한다. 그래서 고친다.