백그라운드 루프 중단을 자동으로 감지하기

정기적으로 돌아야 하는 배경 작업이 조용히 멈추면 서비스는 수일간 대응 없이 데이터가 낡아간다. 이번에 학습/SEO 루프의 생사를 자동으로 감시하고 Discord와 Telegram으로 즉각 알람하는 health-monitor 기능을 추가했다. 팀이 야간이나 주말이라도 멈춤을 놓치지 않도록.

백그라운드 루프가 "살아있다"는 가정은 위험하다

초기에는 학습 배치와 트래픽 감시 루프가 도는지를 사람이 주기적으로 확인했다. 로그를 보거나, 데이터 테이블의 타임스탬프를 보고 "어제 갱신되긴 했구나" 식으로. 하지만 이런 방식은 몇 가지 문제가 있다.

첫째, 발견 지연이 크다. 루프가 월요일 새벽에 멈췄는데 수요일 오후에나 로그를 본다면 2일이 지난 후다. 그 사이 추천 서비스는 낡은 모델로 돈다. 둘째, 주말/야간에는 알 길이 없다. 누군가는 항상 깨어 있지 않으니까. 셋째, 스케일 문제다. 루프가 5개 → 15개로 늘면 사람이 하나하나 확인하는 건 비현실적이다.

그래서 자동화가 필수였다. 시스템이 스스로 "이 루프가 마지막으로 업데이트된 게 얼마나 됐나?" 을 주기적으로 물어보고, 의심스러우면 팀에 즉시 통보하는 방식.

learned json과 traffic-watcher의 freshness를 감시하다

health-monitor 스크립트가 일정 간격(보통 5-10분)으로 두 개의 핵심 데이터 소스를 확인한다:

• learned.json — 모델 학습/파이프라인이 최신 결과를 써내는 파일. 타임스탐프가 N시간 이상 없으면 학습 루프가 멈춘 신호.
• traffic-watcher 상태 — 트래픽 로그 수집 및 분석 프로세스의 마지막 갱신 시점.

각 데이터의 "staleness"(낡음 정도)를 계산한다. 예를 들어 learned.json이 2시간 갱신되지 않았다면, 임계값(예: 6시간)과 비교해서 "아직 OK"인지 "경고 수준"인지 판단한다.

# health-monitor.py 의 논리 예시 (실제 코드가 아님)
def check_staleness(last_update_time, threshold_hours=6):
    elapsed_hours = (now() - last_update_time) / 3600
    if elapsed_hours > threshold_hours:
        return True, elapsed_hours  # 타임을 넘김
    return False, elapsed_hours

# learned json 확인
is_stale, hours_old = check_staleness(learned_json_mtime, threshold=6)
if is_stale:
    alert(f"learned.json이 {hours_old}시간 갱신 안 됨", 
          channels=['discord', 'telegram'])

다중 채널 알람 — 팀의 반응 속도가 결국 MTT(Mean Time To Recovery)다

단일 채널(예: 이메일) 알람은 문제가 있다. 이메일은 묻힐 수 있고, 야간에는 놓치기 쉽다. Discord와 Telegram을 함께 쓰는 건 중요한 알람이 팀의 눈에 닿을 확률을 높이기 위함이다.

알람도 단순하지 않다. 처음 감지될 때 한 번, N분 뒤에도 여전히 스테일하면 재알람. 팀이 무감각해지지 않도록 반복은 최소화하되, 진짜 문제를 놓치지 않는 밸런스.

회고 — 모니터링은 "감지"에서 끝나지 않는다

이 작업을 하면서 깨달은 점들:

1. staleness 임계값은 트레이드오프다. 너무 짧으면 오탐이 많아져서 팀이 알람을 무시한다(알람 피로). 너무 길면 실제 문제가 발생해도 놓친다. 팀과 함께 "충돌이 얼마나 빨리 영향을 주는가"에 따라 정한다.

2. 알람도 숨겨진 비용이다. Discord/Telegram 통지를 추가할 때마다 어느 채널에서 받을지, 수신자는 누구인지 정해야 한다. 전체 팀이 받으면 노이즈, 일부만 받으면 누군가는 모르고 있다. 우리는 ops 채널에만 알리되, 심각도 높으면 대기 담당자에게도 핑하기로.

3. 자동 복구와 세트로 생각해야 한다. 감지만으로는 부족하다. 다음은 "자동으로 프로세스 재시작하기" 또는 "관리자 호출 없이 dequeue 정리하기" 같은 자가 치유(self-healing) 메커니즘. 지금은 감지 단계지만, 시스템이 성숙할수록 자동 대응도 늘어간다.

4. 로그만으로는 진짜 상태를 알 수 없다. 루프가 "실행"되고 있지만 실제로 일을 하지 않는 경우도 있다. 파일 쓰기는 되지만 내용이 이상한 경우도 있다. 단순히 타임스탐프 말고, 데이터의 유효성도 함께 체크하는 상급 health-check 가 필요할 수 있다. 예를 들어 traffic 수를 함께 보거나, learned 모델의 버전을 추적하는 식으로.

팀 관점에서 보면, 이런 자동화는 수동 모니터링의 인지 부담을 덜어주는 동시에, 팀이 정말 중요한 문제 해결에 집중하게 한다. 누군가 항상 로그를 들여다볼 필요가 없어진다.

🛒 이 글과 어울리는 추천 상품

• 모니터암 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →
• 책상조명 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.