자동 튜너는 매일 실행됩니다: scripts/yt-analytics/run.py는 YouTube Data API v3 videos.list 엔드포인트에서 최근 30개의 업로드 영상을 읽어와 아키타입 (archetype)별로 그룹화하고, 연령 정규화된 일일 조회수 (age-normalized views/day)를 계산하며 (24시간 미만 영상 제외), docs/yt-today-directive.md를 다시 작성합니다. 생성 루틴은 반드시 해당 파일을 먼저 읽어야 합니다 — 디렉티브 설계는 다른 곳에서 다룹니다. 이 글은 2주 후 실제 라이브 데이터가 무엇을 말해주었는지에 관한 것입니다.

신호 1: 아키타입 간의 격차가 예상보다 큼

현재 아키타입별 일일 조회수 중앙값:

• product_findindiegame (게임 대 게임 비교): 일일 11회 조회, n=19
• product_ossfind (OSS 대안 비교): 일일 2회 조회, n=1 — 신뢰하기에는 너무 작음
• build_in_public: 일일 1회 조회, n=2

product_findindiegame의 일일 11회 조회 중앙값은 아키타입 라벨 자체 때문이 아니라 기초 데이터의 특정 패턴에서 기인합니다. 인디 게임과 AAA 게임 모두 잘 알려진 고유명사인 '이름 대 이름' 방식의 게임 비교는 개별 Shorts 영상의 조회수를 162-373회까지 끌어올렸습니다. 동일한 템플릿에서 특정 이름들을 제거하면 (숫자 훅은 유지하고 게임 이름은 삭제), 유사한 Shorts의 조회수가 77회로 급감했습니다. 인식 가능한 게임 이름이 없는 Shorts는 5회에 그쳤습니다.

기존의 분석 분류기 (analytics classifier)는 아키타입 대 비아키타입의 성과를 추적했습니다. 2주간의 데이터가 추가로 보여준 것은 아키타입 내부의 무엇이 성과를 견인하는지에 대한 구체성입니다. 이제 자동 튜너는 사양 (spec)에 엄격한 게이트를 적용합니다: 사양이 YouTube 심사를 통과하기 전에 제목에 반드시 두 개의 실제적이고 인식 가능한 고유명사가 포함되어야 합니다.

신호 2: build_in_public은 단순히 성과가 저조한 것이 아니라, 퇴보했다

채널을 처음 시작했을 때, 매주 내가 작업한 결과물(shipped)을 게시하는 것은 자연스러워 보였습니다. 초기 영상 중 하나가 조회수 34회를 기록했는데, 당시에는 이것이 하나의 신호(signal)처럼 보였습니다.

해당 아키타입(archetype)의 연령 정규화 중앙값(age-normalized median)은 현재 하루 1회입니다. 34회 조회수를 기록한 영상은 첫 달의 이상치(outlier)였습니다. 최근 두 개의 build_in_public Shorts는 각각 평균 8회의 조회수를 기록했으며, 첫 2주 동안 성장 꼬리(growth tail)가 나타나지 않았습니다.

지침(directive)은 이를 강력하게 금지(hard-ban)합니다. 구체적인 우려는 단순히 성과가 저조하다는 점이 아닙니다. 승리하는 아키타입(winning archetype)에 대해 '3회 연속 방어 기제(3-in-a-row guard)'가 작동할 때(아래 참조), 생성 루틴(generation routine)에 폴백(fallback, 대체 수단)이 필요하다는 점입니다. 명시적인 금지가 없다면, 시스템은 저항이 적은 옵션으로서 build_in_public으로 폴백할 수 있습니다. 이를 방지하기 위해, Python 스크립트는 DEAD_ARCHETYPES = frozenset({"build_in_public", "meta", "curated", "technical"})를 유지하며, 지침 로직(directive logic) 내의 어떠한 폴백 경로에서도 해당 항목들을 명시적으로 제외합니다. 죽은 아키타입(dead archetype)으로의 폴백은 분석 엔진이 다음 주 조회수 분포를 왜곡하게 만드는, 즉 승리자의 큐 점유율(winner's share of the queue)을 깎아먹는 사양(spec)을 생성하게 될 것입니다.

신호 3: 3회 연속 방어 기제는 승리하는 아키타입에게도 중요하다

오늘의 지침은 product_findindiegame이 지난 두 번의 업로드에 나타났기 때문에 타겟을 product_ossfind로 전환했습니다. '3회 연속 방어 기제(3-in-a-row guard)'는 두 가지 현상이 충돌하는 것을 목격했을 때 제가 직접 하드코딩한 규칙입니다.

첫째는 사양 감사(spec audit)에서의 자카드 중복 탐지 (Jaccard duplicate detection)입니다. 동일한 아키타입이 3일 연속 실행되면, 연속된 사양 간의 첫 문장 유사도 점수(opening-line similarity score)가 0.82 임계값을 넘어서게 되고, 감사가 TTS 단계에 도달하기 전에 사양을 차단하기 시작합니다. 방어 기제는 감사가 거의 중복된 사양을 잡아내기 전에 강제로 로테이션을 유도하기 위해, 특히 '2회 연속' 시점에 작동합니다. 감사가 최후의 보루(last-resort gate)라면, 방어 기제는 상황이 그 단계에 도달하지 않도록 방지하는 역할을 합니다.

둘째, 방어 기제(guard)의 실질적인 결과는 다음과 같습니다. 오늘 영상은 동일한 날짜에 product_findindiegame 사양(spec)의 영상보다 성과가 낮을 가능성이 높습니다. 저는 두 가지 더 나쁜 결과, 즉 시청자의 다양성 체감을 저해하는 거의 중복된 업로드(near-duplicate upload)가 발생하거나, 감사(audit) 실패로 인해 파이프라인이 중단되는 상황을 피하기 위해 잠재적으로 더 약한 영상을 선택하는 것입니다.

이러한 트레이드오프(tradeoff)는 실재하며, 저는 아직 이를 깔끔하게 해결하지 못했습니다. 정답은 연속적인 동일 아키타입(archetype)에 의해 트리거되는 방식 대신, 5일간의 기간 동안 아키타입의 다양성을 강제하는 순환 일정(rotation schedule)을 구축하는 것일 수도 있습니다. 그렇게 하면 product_ossfind가 간격에 상관없이 연속된 이틀 후에 차단되는 대신, 방어 기제를 트리거하지 않고 월요일과 목요일에 나타날 수 있을 것입니다.

아직 알 수 없는 것들

product_ossfind는 영상이 하나뿐입니다. 일일 조회수 2회라는 수치는 실행 가능한 데이터(actionable data)가 아닙니다. 이는 두 번째 영상이 나오면 쉽게 뒤집힐 수 있는 사전 확률(prior)입니다. 자동 튜너(auto-tuner)는 아키타입이 순위 비교(ranked comparison)에 진입하기 전 n≥3의 조건이 필요합니다. 현재 product_ossfind는 "초기 데이터(early data)" 범주에 있으며, 방어 기제가 확실한 승자를 뒤로 미뤘기 때문에 오늘 타겟 슬롯을 차지하게 된 것입니다.

세 개의 AI 큐레이션 디렉토리 사이트를 운영하는 6개월간의 진행 중인 실험의 일부입니다. 여기에 언급된 기술적 주장들은 사실이며, 이 기사는 AI의 도움을 받았습니다.