50대의 AMR이 도는 창고에서는 RCS가 하루에 수천 개의 알림을 뱉어내는 게 예사다. 스마트폰에 앱 20개를 깔고, 각각이 한 시간에 10개씩 알림을 보내는 셈이다——일주일이면 관제실 오퍼레이터는 반사적으로 전부 닫는 법을 배운다. 그리고 진짜 고장이 노이즈에 묻혀 아무도 모른 채 지나간다.
이게 알림 피로다. 병원은 10년 전에 이 문제를 풀었다. 다음은 창고 자동화 차례다.
RCS 알림이 폭발하는 이유
RCS는 플릿의 교통경찰이자 디스패처다——경로, 작업, 충전을 맡는다. 이렇게 생각해보자: AMR 한 대마다 수십 개의 센서를 달고 있다——LiDAR, 안전 범퍼, 엔코더, 배터리 BMS, WiFi 무전기——각각 자체 임계값을 갖고 위로 이벤트를 쏘아 올린다. 로봇 50대 × 센서 수십 개 × 24시간: 이게 원재료다.
홍수는 대개 세 군데서 온다.
첫째, 로봇 층. AMR 스스로가 던지는 이벤트: 배터리 온도 출렁임, 일회성 장애물 감속, 재위치 파악, WiFi 로밍. 양은 많지만 대부분 자가 치유된다.
둘째, 플릿 층. RCS가 던지는 이벤트: 작업 타임아웃, 경로 데드락, 구역 혼잡, 충전 대기열. 양은 적지만 하나하나가 처리량에 직결된다.
셋째——단도직입적으로 말하겠다——통합업체의 자기방어 본능이다. 운영이 아니라 책임 회피용으로 설정된 알림 규칙을 달고 출고되는 프로젝트가 많다: "WiFi 신호가 -70dBm 아래로 떨어지면 팝업". 이 알림은 오퍼레이터를 무디게 훈련시키는 것 말고는 아무짝에도 쓸모없다. 가짜 요구사항에는 참을성이 없다: 알림이 많다고 근면한 게 아니다. 아무도 안 읽는 알림 천 개는 0개와 같다.
트리아지: AMR 알람은 3단계. 그 이상은 쇼다
3단계: P0, P1, P2. 나누는 건 하나의 엄격한 선이다: 이 알림을 아무도 안 보면, 라인이 30분 안에 멈추는가? 멈추면 P0. 안 멈추지만 처리량이 타격을 입으면 P1. 둘 다 아니면 P2, 로그로 직행. 거칠지만 먹힌다.
| 단계 | 대표적인 알람 | 전달 방식 | 대응 |
|---|---|---|---|
| P0 — 생사가 걸림 | 비상정지 버튼 눌림, 안전 범퍼 접촉, LiDAR 차단, 로봇 오프라인, 배터리 과열, 메인 통로 데드락 | 사이렌 + SMS/전화 | 몇 분 안에 대응 |
| P1 — 처리량 위험 | 충전 복귀 실패, 일회성 내비 실패(자동 복구됨), 충전기 대기열, 구역 혼잡 감속 | 관제실 목록 + 교대 요약, 팝업 없음 | 교대 안에 처리 |
| P2 — 로그만 | WiFi 로밍, 속도 저하, 하트비트 지터, 일회성 장애물 감속, 자가 치유 이벤트 | 로그만 | 트러블슈팅 때 뒤져보기 |
현장의 두 가지 이야기.
2024년 후반, 광군제 피크를 앞두고 중국 동부의 한 이커머스 창고는 RCS 알림 정책을 공장 출고 설정 그대로 60대의 AMR을 돌렸다: 전부 켜짐, 하루 4,000건이 넘는 알림. 오퍼레이터는 나중에 이렇게 말했다. "팝업을 눈 가장자리로 보고 닫는 법을 배웠다"고. 그러다 한 로봇의 BMS가 배터리 과열을 띄웠다——진짜 P0였다——"WiFi 로밍"과 "장애물 감속" 수천 개 항목 밑에 묻혔다. 40분이 넘게 지나서야 현장 순찰이 메인 통로에서 죽어 있는 로봇을 발견했고, 피킹 라인 절반이 멈춰 있었다. 사후 분석은 한 문장으로 끝났다: 알림이 없었던 게 아니다. 너무 많아서 없는 것과 같았던 것이다.
반대 사례는 남쪽에 있다: 40대의 AMR을 가진 3C 창고는 첫 한 달간 "재위치 파악 성공"——자가 치유 이벤트——팝업을 계속 띄웠다. 하루 800건 알림 중 700건이 좋은 소식이었다. 새 규칙: 자가 치유는 로그로. 실패한 복구만 에스컬레이션한다. 팝업은 하루 800건에서 약 60건으로 줄었고, 오퍼레이터는 다시 화면을 보기 시작했다. 문제는 "알림이 부족하다"는 게 아니었다.
음소거는 삭제가 아니다: 알림 튜닝의 세 가지 함정
단계는 정해졌다. 이제 규칙 음소거와 임계값 튜닝의 실무가 온다——그리고 내가 하나씩 최소 한 개 프로젝트는 삼키는 걸 목격한 세 가지 함정이 있다.
함정 1: 음소거하고 잊기. 음소거는 리스크 판단이다. 변경 기록이 필요하다: 누가 승인했는지, 왜인지, 언제 만료되는지. 건물 관리에 알리지도 않고 연기 감지기 배터리를 빼는 것과 같다——화재가 나면 첫 질문은 "배터리를 뺀 게 누구냐"가 된다. 내 규칙: 모든 음소거는 승인자와 검토일을 달고 대장에 등록한다. 만료된 음소거는 자동 복원되어 재평가를 강제한다.
함정 2: 남의 창고 임계값 베끼기. 바닥 평탄도, WiFi 커버리지, 랙 밀도——두 현장이 같은 경우는 없다. "장애물 감속이 분당 10회를 넘으면 알림"이 A 사이트에서는 완벽해도 B 사이트에서는 오경보 제조기가 된다. 올바른 순서: 처음 2주간은 전부 로그만 남기고 아무것도 푸시하지 않은 뒤, 자기 데이터로 임계값을 정한다. 먼저 관찰, 다음에 입법——반대가 아니다.
함정 3: 과도한 중복 제거. 건수를 줄이려고 "내비게이션 실패"와 "작업 타임아웃"을 "AMR 이상" 하나로 합치는 팀이 있는데, 트러블슈팅 때 운다. 중복 제거는 같은 로봇에서, 몇 분 이내의, 같은 원인의 반복에만 적용하라. 다른 원인은 절대 합치지 마라——노이즈를 중복 제거하는 것이지 정보를 합치는 게 아니다.
알림 하나를 음소거하기 전에, 이 의사결정 매트릭스에 통과시켜라:
| 경미한 결과 | 심각한 결과 | |
|---|---|---|
| 빈번 | 음소거, 로그만 | 그건 설계 결함이다——알림이 아니라 시스템을 고쳐라 |
| 드묾 | P2 로그 | 유지, P0 푸시 |
오른쪽 위 셀에 한마디: 빈번하면서 심각한 알림은 시스템 자체가 아프다는 뜻이다. 거기서 알림을 튜닝하는 건 중환자에게 진통제를 주는 것과 같다.
기술 파트를 닫는 역설적인 견해 하나: 사람들은 "음소거할수록 시스템이 위험해진다"고 생각한다. 반대다. 음소거는 위험하지 않다. 위험한 건 음소거된 걸 아무도 모르는 것이다. 전부 P0인 시스템과 알림이 없는 시스템은 똑같이 죽는다——아무도 안 보고 있으니까.
그래서 돈이 아깝지 않았나? 하나의 숫자가 말해준다: P0 알림이 발화되고 사람이 대응을 시작하기까지의 평균 시간이다. 이걸 40분에서 5분으로 낮추면 알림 거버넌스 노력이 본전을 뽑은 것이다. 안 움직이면 그 이전의 모든 것——트리아지도, 음소거도, 중복 제거도——쇼였던 셈이다.
Da Liu, 자동화 엔지니어 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
