[14편] 자동화 유지보수 전략 – 안 고치고 오래 쓰는 구조 만들기 (Make.com + DeepSeek)

자동화는 “만드는 순간”보다 “안 망가뜨리는 기간”이 더 중요합니다.
14편에서는 고장 감지·알림·재시도·비용 안전장치까지 포함해 운영자 관점의 유지보수 구조를 완성합니다.

---

✅ 이 편의 핵심 목적

**“고장나도 망하지 않는 자동화”**를 만듭니다.

• 고장 감지: 실패/지연/누락을 바로 알아챈다
• 고장 대응: 재시도·우회·대기열로 넘기기
• 고장 복구: 데이터 손실 없이 다시 돌릴 수 있게 만든다
• 비용 안전장치: 호출 폭주/무한 재시도/모델 비용 급증을 막는다

---

🧨 자동화가 망가지는 대표적인 순간들

1) 소스 변화(RSS/사이트 구조/필드명)

• RSS description이 갑자기 비거나
• published_at 포맷이 바뀌거나
• 링크가 리다이렉트로 바뀌면서 중복 체크가 깨집니다.

2) API 정책·레이트리밋·인증 오류

• 호출이 많아지면 레이트리밋 오류가 늘고
• 토큰 만료/권한 변경으로 “어제까지 되던 게 오늘 안 됨”이 발생합니다.

3) 조용한 실패(가장 위험)

• 시나리오가 실패해도 알림이 없어서 며칠을 놓칩니다.
• 결과적으로 “게시가 안 된 기간”이 생기고 신뢰가 깨집니다.

---

🚨 “망가졌는지” 자동으로 감지하는 방법

여기서부터는 감지 설계를 합니다. 감지는 크게 3종류가 좋습니다.

A) 실행 실패 감지(에러 기반)

• 특정 모듈에서 에러가 나면 에러 핸들러 루트로 보내 알림을 띄웁니다.
• 중요한 포인트: 에러 핸들링 루트는 “문제 발생 시 처리 흐름”을 분리해 운영 안정성을 올립니다. 

B) 결과 누락 감지(데이터 기반)

실행이 “성공”으로 끝나도 결과가 비면 사실상 실패입니다.

• 예: 오늘 뉴스 레코드 0건, 게시 큐 0건, 요약 필드가 빈 값
  이런 경우를 **조건 검사(필터)**로 잡아 “경고”를 보내야 합니다.

C) 지연 감지(시간 기반)

• “매일 9시에 돈다”가 전제인데 10시가 지나도 결과가 없으면 알림
• 이건 스케줄 운영과 세트입니다(뒤에서 다룹니다). 

---

🧯 에러 핸들러 설계: 운영자에게 중요한 최소 패턴 5개

Make의 에러 핸들링 개념을 “패턴”으로 고정하면 유지보수가 쉬워집니다. 

1) Notify 패턴(알림만 보내고 종료)

• 슬랙/이메일/문자 등으로 “어느 모듈에서 어떤 에러인지” 보내기
• 가장 기본이면서 효과가 큽니다.

2) Retry 패턴(일시적 장애는 자동 재시도)

• 레이트리밋/일시적 네트워크는 재시도로 해결되는 경우가 많습니다. 
• 단, “무한 재시도”는 비용 폭탄이므로 최대 횟수를 둡니다.

3) Degrade 패턴(대체 경로로 다운그레이드)

예: DeepSeek 호출 실패 시

• 대체: “요약만 저장”하고 인사이트는 빈 값 처리
• 또는 REVIEW 큐로 보내 수동 확인
  핵심은 “전체가 멈추지 않게” 만드는 것입니다.

4) Quarantine 패턴(문제 데이터 격리)

• 특정 기사/특정 출처만 계속 에러를 내는 경우
• 해당 레코드를 quarantine_log에 저장하고 본 흐름은 계속 진행

5) Incomplete Executions 패턴(수동/재개 가능한 형태로 남기기)

• 중요한 자동화라면 “실패한 상태”를 나중에 복구할 수 있어야 합니다.
• Make에는 incomplete executions(불완전 실행 저장) 같은 운영 옵션이 있어, 오류 시점의 상태를 남겨 조치 후 이어갈 수 있습니다. 

---

🧭 Router + Fallback으로 “예외 처리”를 안정화하기

뉴스 자동화는 분기가 많습니다. 그래서 Router 운영이 곧 유지보수입니다.

A) 라우트는 “순서가 있는 처리”라는 점을 전제로 설계

Router는 라우트를 순차 처리하고, 필요 시 fallback(기본) 라우트를 둘 수 있습니다. 

• 즉, “우선순위”가 설계의 핵심입니다.

B) Fallback 라우트는 “마지막 안전망”

• 어떤 조건에도 안 걸리는 데이터는 결국 생깁니다.
• 이걸 그냥 버리면 데이터 손실이고, 그냥 통과시키면 품질 붕괴입니다.
• 따라서 fallback은 보통 다음 중 하나로 보냅니다.
  • REVIEW 큐
  • unknown_bucket 로그
  • “기본 요약만 저장” 경로

---

💸 DeepSeek 비용 급증 막는 안전장치(운영에서 가장 체감 큼)

자동화가 커질수록 “비용은 사고처럼” 늘어납니다.
아래는 실제로 많이 쓰는 안전장치입니다.

1) 2단 필터: “AI 호출 전”에 최대한 거르기

• 11편에서 이미 했던 1차 프리필터를 더 강화합니다.
• AI는 “통과 후보”만 만지게 해야 합니다.

2) 호출 상한: 하루 처리량 제한

• 예: 하루 최대 30건만 AI 요약/인사이트 생성
• 나머지는 다음 배치로 넘기거나 REVIEW로 보냄

3) 점수 기반 단계화(비싼 작업은 상위 점수만)

• score 90+: 요약 + 인사이트 + 아카이브 리포트 후보 태그
• score 70~89: 요약 + 인사이트
• score 50~69: 요약만(또는 REVIEW)
• score < 50: DROP

4) “본문 추출/긴 입력”은 REVIEW만

• 본문 스크래핑/긴 텍스트는 비용과 실패율이 큽니다.
• 애매한 것만 추가로 처리하는 구조가 안전합니다.

---

📅 6개월 이상 쓰는 자동화 구조의 공통점(스케줄·레이트리밋·연속 오류)

1) 시나리오 스케줄을 “업무 리듬”에 맞춘다

Make는 다양한 스케줄 옵션(정기 간격, 매일, 요일, 특정 날짜, 온디맨드 등)을 지원합니다. 

• Daily ingest(뉴스 수집/선별/저장)는 짧은 주기
• Weekly/Monthly packager(묶음/리포트)는 긴 주기
  이렇게 분리하면 운영 비용과 고장 범위를 나눌 수 있습니다.

2) 시나리오 레이트 리밋(초당/분당 폭주 방지)

특히 웹훅 기반 트리거는 짧은 시간에 많이 들어오면 외부 서비스 레이트리밋을 넘기기 쉽고, 이를 막기 위한 시나리오 실행 제한(분당 최대 실행 수 같은 설정)이 안내되어 있습니다. 

3) 연속 오류에 대한 “자동 차단” 개념을 이해한다

운영에서는 “몇 번 연속으로 실패하면 멈추고 알림” 같은 정책이 중요합니다. Make의 에러 처리/시나리오 설정에는 이런 연속 오류와 관련된 운용 개념이 포함됩니다. 

• 요지는 하나입니다: 계속 실패하는데 계속 돈다 = 비용 누수 + 데이터 혼란

---

🧾 운영자 체크리스트(그대로 복사해서 쓰기)

A) 반드시 있어야 하는 로그 4종

• error_log (모듈/에러메시지/시간/입력 요약)
• drop_log (점수/사유/드롭 태그)
• review_queue (애매한 것 모음)
• run_health (오늘 처리건수/통과건수/0건 여부)

B) 알림 규칙 5개(최소)

• 시나리오 실패 시 즉시
• 오늘 처리건수 0건이면 경고
• REVIEW가 N개 이상 쌓이면 경고
• AI 호출이 일일 상한에 도달하면 안내
• 특정 출처에서 에러가 반복되면 격리 알림

C) “점검 루틴” 10분짜리

• 매주 1회: drop_log 상위 사유 3개 확인 → 프롬프트/필터 조정
• 매월 1회: topic 분류의 흔들림 점검 → 토픽 목록 정리

---

🔜 15편 예고글

유지보수까지 갖추면, 이제 이 시스템은 “돌아가는 자동화”가 아니라 운영 가능한 플랫폼이 됩니다.
다음 15편에서는 기술 설명을 넘어, 이 자동화로 어디까지 확장할 수 있는지(개인 기록 → 공개 전문 블로그, 신뢰 관리, 운영 원칙, 장기 성장 로드맵)를 운영자 관점에서 정리해 시리즈를 마무리합니다.