새벽 2시 14분, 중계 펌프장의 펌프 두 대가 모두 정지했다. SCADA는 critical 알람을 올렸고, 통보 서비스는 당직 기사에게 SMS를 보냈고, 습정은 4시 50분에 넘쳤다. 다들 기사가 자느라 못 봤다고 생각했다.
아니었다. 문자는 4시 31분에 도착했다. 발송 후 2시간 17분 동안 통신사 큐에 들어가 있었는데, 그 현장의 콜아웃이 email-to-SMS 게이트웨이를 거치고 있었기 때문이다. 알람 시스템은 완벽하게 동작했다. 전달 경로가 수신 확인도, 타임아웃도, 감시자도 없는 best-effort 메일 경로였을 뿐이다.
대부분의 콜아웃 설계가 거꾸로 가는 지점이 여기다. 어떤 알람을 보낼지에는 공을 들이면서, 도착했는지, 누가 받았는지를 증명하는 일에는 거의 손을 대지 않는다. 현장에서는 둘 다 실패하는데, 두 번째는 조용히 실패한다.
전화로 나가는 것은 전부 알람 시스템의 일부다
ISA-18.2는 원격 통보를 알람 시스템 라이프사이클 안에 넣는다. 형식적인 얘기가 아니다. 콜아웃 목록에 올라간 알람은 합리화(rationalization), 운전원 대응 절차 문서화, 시험, 성능 모니터링을 그대로 상속한다는 뜻이다. 설정 화면에서 "Priority 1" 필터를 그대로 복사해 만든 통보 목록은, 사람이 앉아 있는 제어실 기준으로 합리화된 것이지 머리맡에 놓인 전화기 기준이 아니다.
둘은 다른 질문이다. 제어실은 이게 운전원을 방해할 만큼 중요한가를 묻는다. 콜아웃은 이게 사람을 침대에서 끌어내 차에 태울 만큼 중요한가를 묻는다. 압축기 토출 온도 고온 알람은 낮이라면 진짜 Priority 1이다. 누군가 걸어가서 부하를 뺄 수 있으니까. 새벽 2시, 플랜트가 멈춰 있고 압축기가 이미 트립된 상태라면 그건 아침에 커피 마시며 읽을 내용이다.
호출 목록에 넣을지 판단하는 기준은 세 가지고, 셋 다 예여야 한다.
- 다음 근무조가 올 때까지 아무도 손대지 않으면 상황이 더 나빠지는가?
- 현장에 조치할 수 있는 사람이 정말로 없는가?
- 호출받는 사람이 원격으로든 이동 시간 안에든 실제로 뭔가 할 수 있는가?
세 번째가 나머지 둘을 합친 것보다 많은 항목을 걸러낸다. 90분 동안 손쓸 수 없는 상황을 알리는 호출은, 문자를 읽고 다시 잠드는 습관을 만든다. 그리고 그 습관은 무시해도 되는 알람과 절대 무시하면 안 되는 알람을 구분해주지 않는다.
알람이 아니라 호출 횟수에 예산을 잡아라
EEMUA 191의 정상 상태 목표인 운전원 1인당 10분에 알람 1건은 제어실 숫자이고, 실무에서는 그마저 후한 편이다. 콜아웃은 더 빡빡해야 한다. 야간 호출에는 "확인하고 넘어감" 상태가 없기 때문이다. 사람이 깨는 것 말고는 없다.
나는 평범한 밤에 호출 0건을 목표로 잡고, 일주일에 2건이 나오면 뭔가를 다시 합리화하라는 신호로 본다. 밤마다 서너 번 울리는 게 당연해지면 한 달 안에 당직 전화는 무음이 되고, 그 뒤로는 어떤 에스컬레이션 로직도 이를 되돌리지 못한다. 해법은 상류에 있다. 채터링하는 레벨 스위치를 고치고, 디바운스를 넣고, 시운전 때 낙관적으로 잡아둔 트립 포인트를 올리는 것이다. "벨소리를 더 크게"는 절대 답이 아니다.
보기보다 중요한 설정 하나. 정상 복귀(RTN)는 실제로 호출을 보낸 알람에 대해서만, 짧은 별도 메시지로 보내라. RTN을 아예 막으면 기사가 이미 자연 해소된 상황을 보러 차를 몰고 온다. 전부 보내면 아무 이득 없이 메시지 양만 두 배가 된다.
에스컬레이션 시간은 사람의 시간이다
흔한 실수는 에스컬레이션 타이머를 알람 발생 시점부터 재는 것이다. 전달 시도 시점부터 재야 하고, 실제 사람이 깨서 전화기를 찾아 문자를 읽고 뭔가를 누를 만큼 길어야 한다.
무인 현장에서 오래 버틴 단계 구성은 이렇다.
- T+0 — 1차 당직. 문자 1건, "당장 나와야 하는" 등급이면 음성 통화 1건.
- T+10분, 미확인 — 1차에게 재발송 후 2차 당직으로 확대.
- T+20분 — 감독자 또는 당직 관리자.
- T+40분 — 그 현장의 진짜 최후 수단. 상수도라면 대개 통합 운영센터고, 플랜트라면 대개 아무도 없다. 2023년에 퇴사한 사람 번호를 4단계에 남겨두는 것보다는 없다는 걸 아는 편이 낫다.
5분 에스컬레이션은 성실해 보이지만 대개 틀렸다. 1차가 안경을 쓰기도 전에 명단 전체를 훑고, 알람 하나에 세 명이 차를 몰고 나온다. 프로세스가 정말로 사람을 10분 기다릴 수 없다면 답은 더 짧은 타이머가 아니라 PLC의 자동 동작이다. 어떤 통보 경로도 보호 계층이 될 만큼 결정론적이지 않다.
그리고 에스컬레이션은 알람 해소가 아니라 *확인(acknowledge)*에서 멈춰야 한다. 이 둘은 수시로 갈라진다. 2시 20분에 차 안에서 확인하고 3시 5분에 도착한 기사 때문에, 습정 수위가 아직 높다는 이유로 2시 35분에 감독자를 깨워서는 안 된다.
전달 경로는 자기가 보고할 사고에서 살아남아야 한다
민망한 실패는 이렇게 생긴다. 통보 서비스가 SCADA 서버 위에, 같은 VM의 서비스로 돌면서, 현장 인터넷 회선으로 나간다. 이제 이 구성이 알릴 수 없는 사건을 세어 보자. 서버 다운, VM 호스트 다운, 현장 회선 단절, 랙 전체 정전. 하필 가장 연락받고 싶은 사건들이다.
두 가지 원칙이면 정직해진다.
시스템 밖의 무언가가 시스템을 지켜봐야 한다. SCADA가 몇 분마다 외부로 내보내는 heartbeat와, 그 heartbeat가 끊기면 호출하는 워치독이 필요하다. 침묵 자체가 알람 조건이어야 한다. "SCADA가 죽었다"를 감지하는 유일한 수단이 SCADA라면 감지 수단이 없는 것이다.
통보 경로는 현장 회선과 고장 원인을 공유하면 안 된다. 현장 백업 LTE와 같은 통신사를 쓰는 셀룰러 모뎀은 기지국 하나 차이로 같은 경로다. 소규모 원격지에서는 지금도 UPS나 PLC 워치독 릴레이의 하드 접점에 물린 독립형 셀룰러 오토다이얼러를 선호한다. 투박하고 알려주는 정보도 거의 없지만, 나머지가 전부 꺼졌을 때 동작한다.
이왕이면 정전 시 동작도 확인하라. 서버는 15분 버티는데 네트워크 스위치와 모뎀은 못 버티는 UPS는, 살아서 알람을 올리면서 아무 말도 못 하는 SCADA를 만든다.
로그 파일이 아니라 휴대폰용으로 문구를 써라
잠긴 화면에서, 반쯤 깬 사람이, 다른 메시지와 순서가 뒤바뀐 채로 읽는다고 가정하라.
현장과 상태를 먼저, 값과 시각을 그다음에 둔다. PS4 습정 HIGH-HIGH 4.82m 02:14 - 펌프 2대 고장. ALM: TAG PS4_LT101_HH ACT PRI 1이 아니라. 태그 이름은 넣더라도 맨 뒤다. 그 사람은 옷을 입을지 말지를 정해야지 뭔가를 조회할 상황이 아니다.
SMS 한 세그먼트 안에 넣어라. GSM-7 기준 160자, 분할 메시지는 파트당 153자로 줄고 쪼개지거나 순서가 바뀌어 도착할 수 있다. 한글은 UCS-2로 인코딩되어 70자에서 잘리므로 더 짧게 잡아야 한다. 그리고 알람 자체의 타임스탬프를 본문에 반드시 넣어라. 휴대폰의 수신 시각은 몇 시간씩 어긋날 수 있다. 앞의 펌프장이 그렇게 배웠다.
전달 상태는 데이터로 다뤄라. 전달 확인(delivery receipt)을 돌려주는 사업자를 쓰면 발송, 전달, 확인을 서로 다른 이벤트로 기록할 수 있다. 수신 확인이 없으면 자느라 놓친 알람과 아예 전달되지 않은 알람을 구분할 수 없는데, 이 둘은 시정 조치가 완전히 다르다.
휴대폰에서의 확인은 보안 결정이다
수신 측 확인(inbound acknowledge)은 모두가 요구하고 내가 가장 강하게 되묻는 기능이다. 제어 네트워크로 들어오는 트래픽의 방향을 바꾸기 때문이다.
정말 필요하다면 SCADA 서버가 아니라 DMZ에 두어야 한다. 설계 검토에서 꺼낼 근거는 IEC 62443의 zone/conduit 모델이다. 콜아웃 서비스는 DMZ zone에 있고, 유일한 인바운드 conduit를 가지며, 이미 경계를 넘나드는 broker나 historian 인터페이스를 통해 확인 신호를 쓴다. 인증된 사용자당 알람 하나에 비트 하나. 절대 하면 안 되는 것은 고속도로에서 모바일 클라이언트가 접속하도록 SCADA 서버로 포트를 포워딩하는 것이다.
휴대폰에서의 확인은 사람들이 생각하는 의미도 아니다. "봤다"이지 "처리했다"가 아니다. 이벤트 로그에서 둘을 별도 상태로 유지하지 않으면, 알람 성능 보고서에는 반응은 훌륭했지만 실제로는 아무것도 하지 않은 야간조가 남는다.
콜아웃이 안 됐다는 얘기를 들으면 확인하는 순서는 이렇다. SCADA에서 알람이 실제로 올라왔는가, 통보 서비스가 그걸 집어갔는가, 사업자가 접수했는가, 사업자가 전달을 보고했는가, 그리고 그날 밤 당직 명단이 맞는 사람을 가리키고 있었는가. 다섯 중 넷은 마지막이다. 통보 설정에 반영되지 않은 근무 교대. 욕은 에스컬레이션 로직이 먹고 버그는 전화번호 목록에 있다.