내 잘못입니다 — Dark Hours — AI 사고 후 솔직한 회고와 자동화 시스템 회복 절차

내 잘못입니다 — Dark Hours — AI 사고 후 솔직한 회고와 자동화 시스템 회복 절차

들어가며 — 솔직한 회고의 시간

자동화 시스템을 운영하다 보면 한 번쯤은 마주치는 순간이 있습니다. "어제까지 잘 됐는데, 오늘 아침에 왜 이렇게 됐지?" 이번 글은 긱뉴스에 공유된 "내 잘못입니다 — Dark Hours" 글에서 영감을 받아, AI 자동화 파이프라인 운영자가 사고 후에 어떻게 솔직하게 회고하고 시스템을 회복해야 하는지를 정리합니다. 특히 cron 기반 콘텐츠 발행, 자동 트레이드, LLM 평가 같은 시스템에서 "다크아워"를 어떻게 정의하고, 무엇을 점검하고, 어떤 절차로 복구해야 하는지가 핵심입니다.

Dark Hours라는 표현은 단순한 야간 작업 시간대를 뜻하지 않습니다. 시스템이 "한계 밖에서" 작동하던 시간, 모니터링이 잠들어 있던 시간, 또는 사람의 판단 없이 LLM이 자율적으로 행동한 시간대를 통칭합니다. 이 시간대에 어떤 일이 일어났는지를 사후에 재구성하는 일 자체가 운영자의 핵심 역량입니다.

Dark Hours가 발생하는 전형적 패턴

실무에서 자주 마주치는 Dark Hours 패턴은 크게 네 가지로 분류할 수 있습니다. 첫째, 시간대 기반 야간 실행 — 새벽 시간에 cron이 돌면서 사람의 개입 없이 LLM이 후보를 선정하고 발행을 결정합니다. 둘째, 외부 서비스 응답 지연 — Notion API나 Tistory API가 timeout 직전까지 버티면서 부분적 응답을 돌려주는 경우입니다. 셋째, 세션 만료 후의 백필 — 브라우저 쿠키가 만료됐는데 cron이 retry하면서 stale URL을 발행하는 경우입니다. 넷째, 중복 가드 회피 — 한 사이클 안에서 동일 후보가 두 번 선정되어 publish 단계가 중복으로 실행되는 경우입니다.

이 네 패턴 모두 공통점이 있습니다. "사람이 보지 못한 상태에서 시스템이 자율적으로 행동했다"는 점입니다. 그래서 사고 후의 회고는 단순 로그 확인이 아니라, "그 시간 동안 시스템이 어떤 결정을 내렸는가"를 다시 역추적하는 작업이 됩니다.

1) 시간대 기반 야간 실행

새벽 2시~5시 사이는 트래픽이 적고 cron이 동시에 여러 개 돌면서 레이스 컨디션이 발생하기 쉽습니다. LLM 기반 후보 선정 파이프라인은 특히 취약합니다. 같은 후보가 두 개의 cron 인스턴스에 의해 동시에 선정되면, 두 번 publish 직전까지 가는 경우가 있습니다. 이때 guard가 둘 중 하나를 막아주지 않으면 가짜 발행이 누적됩니다.

2) 외부 서비스 응답 지연

Notion API나 Tistory API가 timeout 직전까지 버티면서 부분 응답을 돌려주는 경우가 있습니다. 이때 파이프라인은 "정상 응답"으로 오인하고 다음 단계로 진행하지만, 실제론 일부 데이터가 누락된 상태입니다. 사후에 보면 daily_counts는 +1 됐는데 실제 글은 없거나, 글이 있는데 태그가 누락된 상태입니다.

사고 직후 24시간 체크리스트

Dark Hours 사고가 감지되면 다음 24시간 안에 아래 항목을 점검합니다. 각 항목은 "측정 가능한 신호"를 기준으로 작성됐습니다.

• state.details[-1] URL vs last_published_url — 두 값이 같은데 오늘 발행이라고 보고된 슬롯이 어제 stale 슬롯과 동일하다면 진짜 가짜 발행입니다.
• daily_counts 합계 vs 실제 Tistory 글 수 — admin API의 posts.json 최상단 id와 비교합니다. mismatch면 즉시 publish skip + 사용자 게이트.
• 세션 만료 여부 — 302 → /auth/login이면 §3.8.1 가드 적용, 가짜 발행 누적 추정 시간 = 마지막 정상 발행 시각.
• build_post 스크립트 lint — sibling write warning이 떴다면 parts.append() 라인 수 vs 본문 라인 수 비교, U+FFFD grep, 한자/CJK grep으로 자동 치환 검출.
• proxy check 200 + og:title 매칭 — 실제 글이 살아있는지 직접 GET. 캐시/스킨 영향 분리 위해 admin API 교차 검증 추가 권장.

회고 글에 담아야 할 솔직함

Dark Hours 회고 글은 단순 변명이 아니라 시스템 개선의 trigger여야 합니다. 솔직한 회고 글에는 보통 다음 네 가지가 들어갑니다. 첫째, "무엇이 일어났는가" — 시간순 타임라인. 둘째, "왜 일어났는가" — 직접 원인과 시스템 원인. 셋째, "내가 놓친 신호" — 사후에 보면 명확했지만 그때는 못 봤던 신호. 넷째, "앞으로 무엇을 바꿀 것인가" — 구체적 액션 아이템과 그 검증 방법.

# 회고 글 템플릿 예시
timeline:
  - t: "00:01"
    event: "cron 진입, 가드 VALID"
  - t: "00:03"
    event: "후보 선정, status=ready"
  - t: "00:04"
    event: "publish 성공, #NNN"
  - t: "00:05"
    event: "state 동기화 중 누락 발견"
root_cause:
  - "build_post 스크립트 lint 단계에서 multiline HTML literal 미검출"
action_items:
  - "parts.append() 안 multiline은 code_lines 리스트로 분리"
  - "sibling write warning 시 4종 grep (U+FFFD, CJK, parts.append count, line read)"
verification:
  - "다음 차 cron에서 동일 패턴 0건 재발 확인"

자동화 시스템 회복 절차 — 5단계

Dark Hours 사고 후 자동화 시스템을 회복할 때는 다음 5단계를 권장합니다.

1. 즉시 중단 — 새 cron 진입을 막고, 현재 진행 중인 파이프라인은 완료까지 두되 신규 publish는 금지.
2. 상태 SSOT 점검 — state.json + published_topics.json + Tistory admin API 3-way 교차 검증. 어느 하나만 어긋나도 가짜 발행 의심.
3. 원인 재구성 — 로그, sibling write warning, lint 결과, publish 응답을 모두 모아 "왜" 발생했는지 재구성.
4. 보정 + 회고 글 작성 — stats 보정은 사용자 게이트 후 1회만, 회고 글은 사고 패턴 + 액션 아이템 포함.
5. 재발 방지 검증 — 다음 차 cron에서 동일 패턴 0건 확인, 3회 연속 무사시 안정 운영 재개.

요약

Dark Hours 회고는 단순 변명이 아니라 시스템의 투명성을 높이는 작업입니다. "내 잘못입니다"로 시작하는 솔직함, 측정 가능한 신호 기반 점검, 5단계 회복 절차, 그리고 재발 방지 검증까지 — 이 네 가지가 갖춰질 때 비로소 자동화 시스템은 한 단계 더 성숙해집니다. 다음 cron이 새벽 2시에 다시 돌 때, 우리는 더 이상 어두운 시간대에 무서워하지 않아도 됩니다.

원문: 내 잘못입니다 — Dark Hours

---

📰 원본 출처 · https://news.hada.io/topic?id=32306 (#N=32306)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.