TIL_260130

n8n 자동화 알람 시스템 설계

should_alert 기준으로 IF 조건 통일하기

• n8n의 IF 노드에 복잡한 조건을 직접 넣기 시작하면
  • 조건이 늘어날수록 가독성이 급격히 떨어지고
  • 나중에 “왜 이 알람이 울렸지?”를 추적하기가 힘들어진다.
• 그래서 모든 판단은 Code(Set) 노드에서 should_alert: true / false 하나로 결정한다.
• IF 노드는 오직 이것만 본다.
•  
  IF $json.should_alert === true

이 구조의 장점:

• IF 노드가 언제나 동일해서 워크플로우가 읽기 쉬움
• 알람 조건이 바뀌어도 한 노드만 수정하면 됨
• 알람이 발생한 이유를 alert_reason 같은 필드로 같이 남길 수 있음

2️⃣ 알람은 “결과”, 판단은 “계산”

• HTTP Request / DB 조회 → 판단 로직(Code 노드) → IF → 알림(Slack/Email)
• 알림은 결과일 뿐이고, 핵심 로직은 should_alert를 만드는 단계에 집중한다.

 

 

MTBFA(Mean Time Between False Alerts) 개념

알람 시스템을 만들면서 MTBFA 개념도 같이 정리하게 됐다.

MTBFA란?

• Mean Time Between False Alerts
• “거짓 알람이 얼마나 자주 발생하는가”를 나타내는 지표
• 값이 클수록 → 알람 시스템의 신뢰도가 높다

왜 MTBFA가 중요한가?

• 알람이 너무 자주 울리면:
  • 사람은 알람을 무시하게 되고
  • 실제 장애가 와도 대응이 늦어진다 (알람 피로)
• 결국 중요한 건
• 알람을 많이 보내는 것보다, 꼭 필요한 알람만 보내는 것

n8n 설계와 MTBFA의 연결

• should_alert 패턴을 쓰면:
  • 중복 알람 방지
  • 상태 변화(UP → DOWN) 기준 알림
  • 쿨다운 시간 적용
    같은 로직을 한 곳에서 제어할 수 있다.
• 이는 곧 불필요한 알람을 줄이고 MTBFA를 늘리는 방향의 설계다.