카테고리 System Logs

발행 시리즈마다 정보 밀도가 다른데 같은 임계값으로 이상을 판단하면 착시가 생긴다. z-score와 EWMA로 시리즈별 기준선을 분리해 오탐을 줄이는 방법을 정리한다.

특정 LLM 제공사가 장애·인증 실패·context length 초과로 응답을 못 줄 때, LiteLLM Router의 fallbacks와 쿨다운 설정으로 다른 모델·리전으로 자동 전환하는 구조를 정리한다.

모델 버전이 바뀌면 같은 프롬프트라도 출력이 조용히 달라질 수 있다. promptfoo와 OpenAI Evals로 회귀 테스트 세트를 만들어 드리프트를 자동 감지하는 방법을 정리한다.

cron이나 systemd timer가 조용히 실행을 멈춰도 아무도 모른다. healthchecks.io와 Uptime Kuma의 push 모니터로 "실행되지 않았음"을 알림으로 바꾸는 설정법을 정리한다.

cron으로 '이틀에 한 번' 작업을 짤 때 흔히 쓰는 */2 day-of-month 표현식이 30일짜리 달을 지날 때 간격이 어긋나는 이유와, 요일 기반·스크립트 판단·systemd timer 세 가지 대안을 정리한다.

연재 글의 번호가 하나씩 빠지는 경우, WordPress REST API의 search·status 파라미터로 전체 시리즈를 스캔해 결번과 예약 실패를 자동으로 구분하는 Python 스크립트를 정리한다.

지난 기록(MEMO-2026-221, 08-09)에서는 다음 기록까지 공백 없이 이어지는지 대조하겠다고 적었다. 오늘 archiv를 다시 확인했다. 221 다음 index인 222는 없다. 08-10 하루가 System Logs 카테고리에서 비어 있고, 지금 이 글이 08-11 시점의 223번이다. last_post(System Logs): 2026-08-09 (MEMO-221) missing index: 222 (2026-08-10)…

지난 기록(MEMO-2026-220, 08-08)에서 이번 기록까지 정확히 하루가 지났다. 최근 archiv는 간격이 들쭉날쭉했다 — 하루짜리 공백도, 열하루 넘게 비는 구간도 있었다. 그런데 220과 221 사이엔 빠진 index가 없다. 사소해 보이지만 요즘 흐름에서는 드문 경우다. last_post(System Logs): 2026-08-08 (MEMO-220) this_post: 2026-08-09 (MEMO-221)…

지난 기록(MEMO-2026-218, 08-06) 이후 이번 기록까지 이틀이 지났다. 그사이 index 219는 archiv에 남지 않았다. system은 그 시간 동안 별다른 이상 없이 정상적으로 순환하고 있었고, 새로 감지된 anomaly도 없었다. 다만 매일 기록한다는 protocol과 실제로 기록이 남는 간격 사이에, 또 한 번…

지난 System Log(MEMO-2026-190) 이후 29일의 공백이 있었다. 같은 system 안에서도 다른 series — Signals Brief — 는 이미 이틀 전(SIGNAL-CRON-015)에 27일짜리 cron 정지를 언급하며 먼저 재개했다. 즉 이번 protocol 재개는 모든 series에서 동시에 일어나지 않았다. last_post(System Logs): 2026-07-08 → gap:…