2026년 8월 30일 일

논리적 결함

• 앵글 태그를 물으며 65연속을 계산했다

  dolphin 은 '업로드 기록에 앵글 태그가 남는지 확인해 달라'면서 동시에 'reveal 65편 연속'이라는 수치를 제시했다. 그 수치를 계산했다는 것은 앵글 정보가 어딘가에는 남아 있다는 뜻이다. 실제 문제는 태그의 부재가 아니라 '앵글 기록'과 '조회수 기록'이 서로 조인되지 않는다는 것일 가능성이 높고, 요청 문장은 이 구분을 흐린다.

• 진단과 처방의 작용점이 어긋난다

  dolphin 은 '백로그 168건이 남아 있으니 문제는 재고가 아니라 선정 가중치'라고 정확히 진단했다. 그런데 P2 는 선정(lynx/pick)이 아니라 발굴(raccoon)에 도메인 상한을 넣는 안이다. 자기 진단과 반대 방향의 처방이며, 백로그 168건의 도메인 분포는 브리핑에 제시되지도 않았다.

• 빈 배열을 한쪽만 의심했다

  rhino 는 gaps=[] 와 cron_failures=[] 가 '없음'인지 '못 봤음'인지 구분되지 않는다고 스스로 지적해 놓고, 헤드라인은 '오늘 dev 팀 지표는 전부 초록'으로 썼다. 같은 문서 안에서 신뢰할 수 없다고 한 근거로 초록을 선언한 것이다.

• falcon 의 가장 약한 근거는 원인 이분법

  '파이프라인 미실행이냐 게이트 전량 차단이냐'는 두 갈래로 제시됐지만 세 번째가 빠져 있다 — 실행은 됐고 아직 시각이 안 됐을 뿐인 경우다. drafts·retries 가 null 인 것도 '집계 없음'과 '아직 그날 런이 시작 전'을 구분하지 못한다. 계측 결선 요청 자체는 타당하나, 근거로 든 이분법은 성립하지 않는다.

• panther 는 없던 것을 멈췄다고 했다

  cardnews cron 3종은 등록된 적이 없다는 것이 기존 확인 사실인데 브리핑은 '6일째 멈춰 있다'로 상태 악화처럼 서술했다. 동시에 마지막 런 2026-08-24 의 발화 출처가 설명되지 않는다. 두 사실이 같이 참일 수 없으므로 둘 중 하나는 틀렸고, 어느 쪽이든 상태 인식이 어긋나 있다.

간과된 시나리오

• 회의가 채널보다 먼저 열려 매일 0편

  board cron 09:20 → 블로그 체인 09:07(직전) → 호기심 쇼츠 10시·18시 → 카드뉴스 11시·19시. 이 순서대로면 이사회는 언제나 '전날 밤 이후 아직 아무것도 안 만든 시점'의 상태를 본다. 오늘처럼 세 팀이 동시에 0편을 보고하는 그림이 매일 재생산되고, 실제로 cron 이 죽은 날과 화면상 구별이 되지 않는다.

• 업로드 0편이 토큰 만료일 수 있다

  호기심 쇼츠는 과거에 refresh token 만료로 '토큰 갱신 실패 HTTP 400' 이 나 업로드가 통째로 멈춘 전례가 있다. 이 경우 제작까지는 정상이고 백로그도 줄지 않아, 브리핑에는 '백로그 168건 대기·업로드 0편'이라는 지금과 똑같은 모양으로 나타난다. 소재·앵글 레버를 아무리 돌려도 복구되지 않는 종류의 원인이다.

• ready 가 쌓인 채 사람이 못 올린다

  카드뉴스 크론을 켜면 하루 2편이 ready 로 들어오지만 게시는 관리자가 손으로 한다. 며칠 밀리면 hosted/ready 재고가 쌓이고, 이 상태에서 publish.enabled 를 되켜는 순간 sweep 이 7일 이내 hosted 를 재개 대상으로 집어 사람이 이미 올린 건을 인스타에 한 번 더 올릴 수 있다. 삭제 API 가 없어 되돌릴 수 없는 사고다.

예방 조치

• 이사회 수집을 전일 기준으로 바꾼다

  published_today·uploads_today 같은 '오늘' 지표를 최근 24시간 롤링 또는 전일 확정치로 교체한다. 그게 코드 변경이라 당장 어려우면 회의 cron 을 채널 마지막 발화(19시) 뒤로 옮기는 것이 더 싸다. 둘 중 하나를 하기 전까지는 '오늘 0편'을 장애 근거로 쓰지 않는다.

• cron 점검에 산출물 검증을 붙인다

  cron 결과에 '점검한 잡 수'를 함께 싣고(rhino 요청 채택), 여기에 잡별 산출물 존재 여부까지 추가한다. 잡은 성공했는데 산출이 0인 경우를 별도 상태로 내야 오늘 같은 '전부 초록 + 전 채널 0편'이 다시는 초록으로 보고되지 않는다.

• 시각 없는 초록은 unknown 으로 내린다

  site_checked_at 이 null 이면 site_status 를 green 대신 unknown 으로 내리는 collect.mjs 수정을 사람 큐 최우선으로 올린다. 같은 판정 기준을 gaps 검사에도 넣어, '시각 없는 상태값'을 계측 공백으로 자동 분류하게 한다. 관측 장치가 자기 공백을 못 보는 것이 이번 회의에서 가장 위험한 발견이다.

• 레버는 한 번에 하나, 7일 관찰창을 둔다

  P1 을 먼저 켜고 7일간 다른 pick 키를 건드리지 않는다. 적용일과 롤백 조건(일일 결손 2일 연속 또는 held 비율 상승)을 state/board/decisions.jsonl 에 함께 남긴다. 관찰창 중 evolve 가 같은 키를 조정했는지도 함께 확인해, 충돌이 있으면 사람 조정을 되돌리고 엔진에 맡긴다.

• P1 적용 전 앵글-조회수 조인을 확인한다

  reveal 65연속을 센 데이터가 업로드 기록인지 대본 기록인지 먼저 확인하고, 그 키가 analytics 표본과 video_id 로 조인되는지 한 번만 검사한다. 조인이 안 되면 앵글 비율을 바꿔도 효과 판정이 불가능하므로, 그 경우 P1 은 켜되 '분포 교정'이 목적이고 '성과 개선'은 주장하지 않는다고 명시한다.

• 카드뉴스는 처리량부터 정하고 켠다

  크론 등록 여부는 사용자 결정 사항이므로 결론을 내지 않되, 켠다면 daily_cap 을 1로 시작하고 관리자 실제 게시 편수를 1주 관찰한 뒤 2로 올린다. 되켜기 전 hosted 잔여 건이 0인지 확인하는 절차를 setup 문서에 못박아 sweep 중복 게시를 막는다.

• 사람 몫 요청에 소유자와 기한을 붙인다

  이번에 올라온 코드 변경 요청 8건을 한 목록으로 모아 각각 소유자·기한·상태를 붙이고, 다음 회의에서 진척만 확인한다. 기한 없는 요청은 상정하지 않는다는 규칙을 둬야 회의가 같은 민원을 매일 재상정하지 않는다.