헛경보를 내는 감시는 없느니만 못하다
자동 감시가 이미 가진 것을 '없다'고 계속 보고했습니다. 표기 차이 하나 때문이었고, 그걸 방치하면 진짜 경보도 같이 무시됩니다.
사이트에 다루는 항목이 늘어나면 "빠진 게 없는지" 확인하는 일이 생깁니다. 저는 외부 목록과 우리 데이터를 대조하는 감시를 만들어 뒀습니다. 새 항목이 나오면 알려 주는 것입니다.
어느 날 이렇게 보고했습니다.
🆕 우리에게 없는 모델 1종
- BMW 5 Series확인해 봤더니 이미 갖고 있었습니다. 우리 데이터에는 BMW 5시리즈로 들어 있었고, 외부 목록은 BMW 5 Series였습니다.
같은 차인데 표기가 달라서 "없다"고 판정한 것입니다.
왜 이게 위험한가
"별거 아니네" 싶지만 이런 경보는 조용히 망가집니다.
이 감시는 매일 돕니다. 매일 "BMW 5 Series가 없습니다"라고 보고합니다. 처음 며칠은 봅니다. 그다음엔 "아 그거 오탐이지" 하고 넘깁니다. 몇 주 지나면 이 감시의 출력을 아예 안 읽습니다.
그리고 그때 진짜 새 항목이 뜨면, 같은 자리에 같은 모양으로 찍히고 그것도 안 읽힙니다.
감시의 가치는 "울린다"가 아니라 "울리면 진짜다"에 있습니다. 헛경보가 섞이는 순간 그 가치가 0이 됩니다. 오히려 마이너스입니다 — 감시가 있으니 안심하는데 실제로는 아무도 안 보고 있으니까요.
고친 방법
원인은 단순했습니다. 이름을 비교하기 전에 정규화를 하는데, 그 규칙에 시리즈 ↔ Series가 없었습니다.
이미 비슷한 규칙이 있었습니다. 모델 ↔ model 같은 것들요. 예전에 같은 종류의 오탐을 겪고 넣어 둔 흔적입니다. 같은 실수를 이미 한 번 했고, 그때 넣은 규칙이 이번 경우를 못 덮은 것입니다.
한 줄 추가하고 다시 돌렸더니 조용해졌습니다.
[new-cars] 새로 나타난 모델 없음 ✓진짜 교훈은 다른 데 있었다
고치고 나서 생각해 보니, 더 중요한 건 왜 그동안 안 고쳤나였습니다.
이 오탐은 하루 이틀 된 게 아니었습니다. 매일 보고되고 있었고, 저는 그때마다 "아 저건 이미 있는 건데" 하고 넘겼습니다. 고치는 데 5분 걸리는 일을 몇 주 미룬 것입니다.
왜냐하면 오탐은 아프지 않기 때문입니다. 시스템이 멈추지도, 사용자가 항의하지도 않습니다. 그냥 알림 한 줄이 매일 더 올 뿐입니다. 그래서 우선순위가 영원히 밀립니다.
이게 감시 시스템이 죽는 전형적인 경로입니다. 한 번에 무너지지 않고, 오탐이 하나씩 쌓이면서 서서히 안 읽히게 됩니다.
그래서 정한 규칙
지금은 이렇게 하고 있습니다.
하나. 오탐은 버그로 취급합니다. "알고 있으니 괜찮다"가 아니라 고쳐야 할 것으로 봅니다. 안 고칠 거면 그 감시를 끄는 게 낫습니다. 읽히지 않는 알림은 없는 것과 같으면서 착각만 주니까요.
둘. 조용해야 할 때 조용한지 확인합니다. 새 감시를 만들면 "잡아야 할 때 잡는가"만 보는데, 그 반대도 봐야 합니다. 정상 상태에서 아무 말도 안 하는지요. 최근에 만든 감시 하나는 겹치는 항목이 없는 날에는 알림을 아예 보내지 않도록 했습니다. "오늘은 없음"을 매일 보내면 며칠 만에 안 보게 됩니다.
셋. 기준을 넉넉하게 잡습니다. 예약 작업이 안 돌았는지 보는 감시가 있는데, 주기를 빡빡하게 잡으면 정상적인 흔들림에도 울립니다. 하루 한 번 도는 작업이면 28시간, 주 1회면 200시간처럼 여유를 둡니다. 늦게 잡더라도 틀리게 잡지 않는 쪽을 택합니다.
넷. 자기 검사를 붙입니다. 데이터 검증기 하나에는 "정상적인 값 몇 개를 넣었을 때 통과하는가"를 스스로 확인하는 코드를 넣어 뒀습니다. 검증 규칙이 너무 엄격해지면 그 자체가 걸립니다. 실제로 한 번은 이름에 아포스트로피가 든 사람들을 걸러내는 규칙을 넣을 뻔했는데, 이 자기 검사가 막았습니다.
마지막으로
감시를 만들 때는 보통 "무엇을 잡을까"만 생각합니다. 그런데 오래 굴려 보면 "언제 조용할까"가 그만큼 중요합니다.
울리지 않아야 할 때 조용한 감시만이, 울렸을 때 읽힙니다.