2026년 8월 26일 수

논리적 결함

• 근거 0이라면서 전략 3건을 제안했다

  dolphin 은 '성과로 말할 수 있는 문장이 0개'라고 명시하고도 소재·앵글 제안 3건을 올렸다. 둘 중 하나는 틀렸다. 나는 이 모순을 이렇게 정리한다 — 성과 데이터 없이 금지되는 것은 최적화이고, 탐색은 오히려 데이터를 만들기 위해 필요하다. 제안이 '이게 더 잘 될 것'이 아니라 '데이터를 만들기 위해 폭을 넓힌다'로 재서술되면 근거가 선다. 지금 문구로는 서지 않는다.

• P2 는 이미 있는 기능의 재제안이다

  pick.mjs 에는 이미 freshness(최근 도메인 감점)가 가중합에 들어 있다. 그 장치가 켜져 있는데도 같은 도메인 연속일이 19일(46%)이 나왔다면 결함은 기능 부재가 아니라 가중치가 약하거나 윈도우가 짧다는 것이다. '감점을 넣자'로 제안하면 같은 일을 하는 두 번째 코드가 생기고, 두 감점이 곱해져 얼마나 눌리는지 아무도 계산하지 못하게 된다.

• dev P1 은 코드 결함을 문구로 고치려 한다

  site_checked_at 이 null 인 원인은 rhino 자신이 말했듯 둘 중 하나다 — 점검이 안 돌거나, 돌지만 수집기가 시각을 안 기록하거나. 어느 쪽이든 goose.md 의 페르소나 문구를 고쳐서 채워지지 않는다. 이사회 collect 는 goose 의 산문이 아니라 상태파일을 결정론적으로 읽기 때문이다. 이 제안을 채택하면 '조치했다'는 기록만 남고 null 은 그대로 남는다. 계측 결함을 문구로 덮는 것이 가장 나쁜 결과다.

• cron 미등록인데 08-24 런 기록이 있다

  panther 는 마지막 런이 2026-08-24 라고 했다. 그런데 카드뉴스 cron 3종은 등록돼 있지 않고, 프로젝트 문서상 runs.jsonl 마지막 기록은 2026-07-31 이다. 셋 중 최소 하나는 틀렸다. 누가 수동으로 돌렸거나, 다른 경로가 카드뉴스를 실행하고 있거나, 브리핑이 다른 파일을 읽고 있다. 어느 쪽이든 '스케줄러가 없어서 멈췄다'는 진단의 근거가 흔들린다.

• rhino 의 가장 약한 근거는 cron_failures=0

  rhino 는 이 값의 한계를 스스로 짚었지만 여전히 사실 항목 두 번째에 올려 두었다. 어떤 잡 목록을 어떤 신호로 세는지 모르는 0건은 근거가 아니라 빈칸이다. 더 나아가 cron_log_today=true 도 같은 문제다 — 로그 파일이 존재한다는 것과 잡이 끝까지 돌았다는 것은 다르고, 이 구분이 없으면 미실행이 성공으로 보이는 그 패턴을 그대로 다시 밟는다.

간과된 시나리오

• GSC 를 고치려다 정상을 건드린다

  falcon 의 요청대로 수집 체인을 파고들었는데 gsc-collect 가 정상 동작 중이고 지연이 API 고유 특성이었다면, 우리는 하루를 쓰고 아무것도 못 고친다. 더 나쁜 경우는 정상 코드를 '고쳐서' 실제로 망가뜨리는 것이다. 확인 순서는 반대여야 한다 — 먼저 지난 30일 seo-metrics.jsonl 의 수집일과 데이터일 간격 분포를 보고, 4일이 평소 범위 밖일 때만 체인을 의심한다.

• 카드뉴스 병목이 사람에게 옮겨간다

  cron 을 켜면 매일 2건이 ready 로 쌓인다. 그런데 발행은 관리자가 /admin/cardnews 에서 손으로 인스타에 올려야 완결된다. 사람이 하루라도 건너뛰면 ready 만 누적되고 공개 /cardnews 는 계속 0편이며, 매일 claude/codex 비용은 그대로 나간다. 즉 cron 등록의 실제 전제조건은 '사람이 매일 5~10분 검수·업로드할 수 있는가'인데 아무 브리핑도 이 질문을 하지 않았다.

• 이중 감점으로 역사가 영구 배제된다

  P1 이 발굴에서 역사 비중을 자르고 P2 가 선정에서 다시 감점하면, 역사 소재는 두 단계에서 눌린다. 백로그의 43% 가 역사인 상황에서 이러면 남은 후보 중 반전 강도가 낮은 것이 best-pick 으로 올라온다. 분포는 예쁘게 균형 잡히는데 개별 영상의 스크롤 정지력은 떨어지는, 지표만 좋아지고 성과는 나빠지는 전형적 결과다. 그리고 조회수 계측이 브리핑에 없으므로 이 악화를 우리는 알아채지 못한다.

예방 조치

• 편수 지표를 D-1 완결 기준으로 바꾼다

  회의(09:20)가 발행(10·11·18·19시)보다 먼저이므로 '오늘 N편'은 폐기하고 전일 완결 기준으로 집계한다. 당일 상태는 별도 필드로 '아직 발행 시각 전'을 명시한다. 이 하나로 세 팀의 헛된 우려 3건이 동시에 사라지고, 진짜 장애가 났을 때 0편이 신호로 보이게 된다. 이사회 collect 코드 변경 1건.

• 신선도 3필드를 강제하고 없으면 unknown

  site_checked_at, gsc 최신 데이터일, 각 채널 마지막 런 완료 시각을 collect 의 필수 필드로 만들고, 값이 없거나 24시간보다 오래되면 판정을 green 으로 낼 수 없게 한다(unknown 강등). 동시에 gaps 탐지기가 '필드는 있는데 값이 빈' 경우를 공백으로 집도록 한다. rhino 의 안건 2·4번을 하나의 코드 변경으로 처리한다. 이것이 dev P1 의 진짜 해법이다.

• 조회수 D7 중앙값 브리핑 편입을 최우선 1건으로

  사람에게 올라간 12건 중 이것 하나만 먼저 처리한다. 555건 표본이 실제로 값을 갖고 있는지부터 확인하고, D7 중앙값(평균 금지)과 도메인별·앵글별 분포를 collect 에 싣는다. 이게 없으면 오늘 채택하는 youtube 제안들의 효과를 다음 회의에서도, 그 다음 회의에서도 검증할 수 없다. 나머지 11건은 이것 뒤에 줄 세운다.

• 한 번에 한 축만 바꾸고 롤백 조건을 적는다

  도메인 축과 앵글 축을 같은 날 건드리지 않는다. 채택하는 변경마다 관측 기간(2주)과 원복 조건(D7 중앙값이 직전 2주 대비 하락)을 결정 시점에 함께 기록한다. 조건을 사후에 정하면 결과를 보고 기준을 맞추게 되고, 그건 검증이 아니라 사후 정당화다.

• 4팀 0편의 공통 원인을 1회 점검한다

  sheepdog 에게 오늘 하루치를 대상으로 claude -p 호출 실패·cron 실행 흔적·락 잔존·디스크를 한 번에 확인시킨다. 팀별로 나눠 파면 같은 원인을 네 번 찾게 된다. 여기서 공통 원인이 나오면 falcon·dolphin·panther 의 원인 규명 요청 3건이 한 번에 닫힌다.

• publish 재개는 hosted 잔여 0 확인이 선행조건

  publish.enabled 를 되켜는 결정은 오늘 내리지 않는다. 되켤 때는 sweep 대상이 되는 7일 이내 hosted 행이 0건임을 먼저 확인하고, 확인 결과를 승인함에 증거로 남긴 뒤에만 켠다. 인스타는 삭제 API 가 없어 실수를 되돌릴 수단이 없으므로, 이 순서는 권고가 아니라 조건이다.

• 카드뉴스 cron 은 사람 검수 SLA 와 묶는다

  cron 등록 여부를 파이프라인 문제로 묻지 말고 '관리자가 매일 검수·업로드할 수 있는가'로 다시 묻는다. 가능하면 2주 파일럿으로 켜고, ready 적체가 3건을 넘으면 자동으로 생성을 멈추는 상한을 함께 넣는다. 사람이 못 따라가면 비용만 나가고 공개 편수는 0인 상태가 지속되기 때문이다.