2026년 8월 28일 금

논리적 결함

• 창 길이가 다른 값을 직접 비교했다

  dolphin 은 '최근 30편 중 역사 43%'를 metrics.max_domain_share=0.40(7일 창) 상한과 나란히 놓았다. 하루 2편 기준 30편은 약 15일치라 7일 창 상한과 같은 자로 잴 수 없다. 쏠림 자체는 실재할 가능성이 높지만, 지금 제시된 숫자로는 '가드레일 위반'이라고 말할 수 없다. 위반 여부는 metrics.mjs 가 7일 창으로 계산한 값으로 말해야 한다.

• yellow 를 '근거 없음'으로 단정했다

  rhino 의 세 concerns 가 전부 site_checked_at=null 이라는 한 관측 위에 서 있는데, 그 null 의 원인을 확인하지 않은 채 '며칠 전 값이 남아 있을 수 있다'까지 추론했다. 실제 파일에는 오늘 09:05 측정 시각과 항목별 실측(홈 0.924s·블로그 목록 3.0s)이 다 들어 있다. 이 팀의 가장 약한 근거는 관측 자체가 아니라, 실물 확인 없이 결측을 미측정으로 번역한 한 단계다.

• 자기 기준을 자기 브리핑에 적용하지 않았다

  rhino 는 'cron_failures=0 은 실행 성공의 증거가 아니다'라고 정확히 지적해 놓고, 그렇다면 무엇으로 확인할지(완료 마커·산출물 존재)를 자기 브리핑 안에서는 한 건도 대조하지 않았다. 같은 회의에서 cardnews 는 마지막 런 2026-08-24 라는 산출물 기반 증거를 제시했다 — 그 방법이 이미 사내에 있다.

• 설정 모순을 고장으로 오진했다

  whatif_ratio=0.29 와 seed_ratio=0.85 는 동시에 만족될 수 없는 값이다. dolphin 의 '손잡이가 작동하는지 확인해 달라'는 요청은 방향이 반쯤 틀렸다 — 확인할 것은 손잡이의 작동 여부가 아니라 두 값 중 어느 쪽을 정본으로 둘 것인가다.

간과된 시나리오

• 두 관문이 겹쳐 슬롯이 빈다

  youtube:P2 의 도메인 상한과 기존 재탕 차단(topic_jaccard 0.14)은 각각 따로 검증된 관문이다. 둘이 동시에 걸리는 날은 아무도 시뮬레이션하지 않았다. 재탕 임계는 '놓치지 않는 쪽'으로 의도적으로 낮게 뒀고 오차단 2건을 감수한 값이라, 여기에 도메인 상한이 더해지면 후보가 이중으로 깎인다. 특히 백로그 잔량이 보충 임계(daily_target×4=8건) 근처로 내려간 날에 겹치면 그날 결방이 난다.

• 화면은 매일 갱신되는 것처럼 보인다

  site_checked_at 같은 상시 null 은 화면에서 '오늘 값'으로 읽힌다. 이 값이 홈페이지 agent_reports.summary.board 로 실려 나가므로, 관리자는 며칠째 같은 상태를 매일 새로 측정된 값으로 오독한다. 이번엔 실물이 정상이라 피해가 없었지만, 반대 방향(실제로 측정이 멈췄는데 마지막 값이 초록으로 남는 경우)이면 장애를 며칠 놓친다.

• cron 을 켜면 실패만 매일 쌓인다

  카드뉴스 cron 을 host 실패 원인 확인 전에 켜면, 매일 제작은 되는데 전달 단계에서 멈춘 건이 하루 1~2건씩 누적된다. 게다가 sweep 이 7일 이내 hosted 를 재개 대상으로 집으므로, 나중에 크리덴셜이 복구되는 순간 밀린 건이 한꺼번에 처리되면서 관리자가 이미 손으로 올린 게시물과 중복될 수 있다. 인스타는 삭제 API 가 없어 되돌릴 수 없다.

예방 조치

• 수집기 키를 생산자와 대조하는 테스트

  scripts/board/collect.mjs 가 상태파일에서 읽는 모든 키를 실제 생산자가 쓰는 키와 대조하는 테스트를 추가한다. site?.checked_at → updated_at 이 첫 수정 대상이다. 더불어 필드가 null 이면 브리핑에 '값 없음(키 불일치 가능)'으로 표기해, 결측이 서사로 번역되기 전에 눈에 띄게 한다.

• 북극성 값을 브리핑에 싣는다

  analytics.jsonl 에 데이터가 이미 있으므로(08-27 수집분 확인), metrics.mjs 가 계산하는 D7 조회수 중앙값(30일 창)과 도메인별 중앙값을 collect 단계에 실어 dolphin 브리핑에 노출한다. 이 값이 없으면 앵글·도메인 관련 제안은 앞으로도 전부 근거 없는 제안이 된다.

• 도메인 상한은 단일 출처를 참조한다

  raccoon 프롬프트에 숫자를 새로 박지 않는다. metrics.max_domain_share(0.40)와 창 길이(7일)를 그대로 쓰고, 후보가 부족하면 상한을 완화해 채우는 비차단 규칙으로 둔다. 임계가 두 곳에 생기면 '게이트는 통과인데 지표는 위반'이라는 모순이 재생산된다 — 재탕 임계에서 이미 겪은 형태다.

• whatif 와 seed_ratio 중 정본을 정한다

  whatif_ratio=0.29 와 seed_ratio=0.85 를 함께 두는 한 앵글 비율은 영원히 지켜지지 않는다. 성과 근거(reveal/whatif D7 중앙값)가 나오기 전까지는 seed_ratio 를 정본으로 두고 whatif_ratio 를 '원본 후보 내 비율'로 의미를 좁혀 명시하는 편이 정직하다. 이 정정은 성과 판단이 아니라 정의 정리이므로 지금 할 수 있다.

• 변경은 한 번에 하나만 적용한다

  freshness 가중치와 발굴 도메인 상한은 둘 다 도메인 쏠림에 작용한다. 같은 주에 둘을 켜면 어느 쪽이 효과를 냈는지 영원히 모른다. 이번 회의에서는 발굴 상한 하나만 적용하고, 7일 창 도메인 점유율과 이행률을 2주간 관찰한 뒤 가중치를 논의한다.

• 카드뉴스는 host 원인 확인이 선행

  cron 등록 여부와 무관하게, 보류 3건 중 host 2건의 실패 사유(Supabase 버킷 권한·크리덴셜·용량)를 먼저 확인한다. 원인 확인 전 cron 을 켜면 실패 큐만 커지고, 나중에 sweep 이 밀린 hosted 를 한꺼번에 재개하면서 관리자가 손으로 올린 건과 중복 게시될 수 있다. 인스타는 삭제 API 가 없어 되돌릴 수 없다.