읽히는 알림의 조건

생산 현장에 품질 모니터링 알림 시스템을 붙인 지 7년이 됐다. cron으로 품질 데이터를 주기적으로 읽고, 문제 가능성이 보이면 텔레그램으로 알려주는 구조다. 처음 도입했을 때 반응은 나쁘지 않았다. 그런데 시간이 지날수록 현장 담당자들은 텔레그램 방 알림을 꺼버렸다. 알림이 온 지도 모르는 상태가 되어갔다.

문제는 알림이 너무 많다는 게 아니었다

알림이 무시당하는 이유를 처음엔 '빈도'로 봤다. 알림이 너무 자주 오니까 무감각해진 거라고 생각했다. 그래서 임계값을 높였다. 알림 수는 줄었다. 그래도 읽히지 않았다.

더 들여다보니 문제는 다른 데 있었다. 알림이 와도 실제 조치가 필요한 상황이 아닌 경우가 많았다. 알림을 받고 확인해 봤더니 아무 일도 없는 경우, 그게 반복되면 사람은 알림 자체를 믿지 않게 된다. 믿지 않으니 읽지 않는다. 읽지 않으니 진짜 문제가 생겨도 놓친다.

알림 시스템이 갖춰야 할 조건을 처음부터 다시 정리했다. 두 가지였다. 적시성과 정확도.

두 조건은 상반적이다

적시성은 문제가 생기면 최대한 빨리 알려줘야 한다는 것이. 현장 책임자가 교대 시작 시점에 알림을 확인하고, 추가 확인 없이 조치 여부를 결정할 수 있어야 한다. 스프레드시트 여러 개를 열 필요도 없고, 품질 엔지니어의 판단을 기다릴 필요도 없이 바로 확인할 수 있어야 한다.

정확도는 알림이 울리면 실제로 문제가 있어야 한다. 신뢰도는 95% 이상이어야 한다. 즉, 알림이 100번 오면 95번은 맞아야 한다. 그 아래로 내려가면 시스템이 아니라 소음이 된다.

문제는 이 둘이 같은 방향을 가리키지 않는다는 점이다.

빨리 알리려면 데이터가 적은 상황에 판단해야 한다. 데이터가 적으면 노이즈에 영향받을 가능성이 높다. 정확하게 판단하려면 추세가 충분히 확인될 때까지 기다려야 한다. 데이터가 충분히 확보되기를 기다리면 반응이 늦어진다. 임계값을 낮추면 빠르지만 알림 오류가 늘어난다. 임계값을 높이면 정확하지만 탐지가 늦어진다. 수집 주기를 짧게 하면 민감하게 반응하지만 역시 노이즈가 늘어난다. 이 긴장은 수식으로 풀 수 없다.

둘 중 하나에 우선순위를 두어야 한다면, 정확도 쪽이다. 잘못된 알림이 오면 현장에서는 상황을 직접 확인하러 가야 한다. 확인 결과 아무 문제가 없으면 그 시간은 그냥 낭비된 것이다. 더 나쁜 경우엔 확인이 끝날 때까지 생산 라인을 세워야 한다. 그리고 이런 일이 반복되면 시스템에 대한 신뢰가 무너진다. 양치기 소년이 된 알림은, 늦지만 정확한 알림보다 훨씬 나쁘다.

최적점은 실제 환경에서만 찾을 수 있다

두 조건 사이의 적절한 지점은 시뮬레이션으로 나오지 않는다. 실제 생산 데이터로, 실제 현장 운영 패턴으로 검증해야 한다. 교대 주기가 어떻게 되는지, 실제 불량이 발생하는 패턴이 어떤지, 현장이 감당할 수 있는 알림 빈도가 어느 정도인지—이런 것들은 공장마다, 제품마다 다르다.

7년 동안 이 시스템을 다듬으면서 배운 건 하나다. 두 조건 중 하나만 잡으려 하면 시스템이 살아남지 못한다는 것. 정확도를 포기하고 빠르게만 가면 아무도 읽지 않는 알림이 된다. 적시성을 포기하고 느리게만 가면 알림이 와도 이미 조치 타이밍을 놓친다.

현장 리더가 교대 시작 시 알림을 열어보고, 열어볼 이유가 있다고 느끼는 것. 그게 알림 시스템이 살아있다는 증거다.

요즘 많은 사람들이 OpenClaw로 이런저런 에이전트를 만들고 여러 가지 정보를 수집하게 하고, 여러 가지 알림을 설정하는 것 같다. 하지만, 많은 알람이 오게 할 수도록 사람은 금방 지치고 결국 관심을 잃게 된다. 얼마나 효용이 있는 알람을 사용할지는 차분하게 자신의 활용 방식을 살펴보아야 알 수 있다.