설비 알람 1,000건이 쌓이기 전에 내가 먼저 본 것 — 7년차 현장 엔지니어의 로그 설계 습관

현장에 들어가면 가장 먼저 마주하는 풍경이 있습니다. 모니터 한쪽에 빨간 알람이 수백 건씩 쌓여 있고, 정작 "그래서 지금 뭐가 문제야?"라는 질문에는 아무도 답을 못 하는 장면이요.

 

7년차 현장 엔지니어로서 저는 이 장면을 수도 없이 봤습니다. 알람이 너무 많아서 알람이 무용지물이 되는 역설. 오늘은 현장에서 배운 '로그 설계' 습관 이야기를 해보려고 합니다. 기술을 자랑하려는 글이 아니라, 제가 실제로 써먹는 기준을 정리한 글입니

다.

 

알람은 '경보'가 아니라 '대화'다

 

처음 현장에 들어갔을 때 저는 설비가 고장 나면 로그를 "찾아보는" 사람이었다가, 어느 순간부터 로그가 "먼저 말을 걸어주는" 구조를 만들게 됐습니다.

 

현장 설비에서 나오는 데이터는 크게 세 종류입니다. 상태값(온도·진동·전류 같은 연속 데이터), 이벤트(기동·정지·모드 변경), 그리고 알람. 문제는 많은 공장이 이 세 가지를 같은 '알람 테이블'에 쏟아붓는다는 겁니다. 센서 통신 끊김 알림과 모터 과부하 정지가 같은 우선순위로 울리면, 작업자는 결국 둘 다 무시하게 됩니다.

 

제가 현장에서 적용하는 원칙은 단순합니다. "이 알람을 본 사람이 10분 안에 뭔가를 할 수 있는가?" 행동으로 이어지지 않는 알람은 로그로 격하합니다. 그리고 격하한 로그는 나중에 검색할 수 있게 태그만 정확히 붙여둡니다.

 

로그에 남겨야 할 '네 가지 필드'

 

현장에서 로그 테이블을 설계할 때, 저는 이 네 가지가 없으면 로그가 아니라 단순 기록이라고 봅니다.

 

1. 언제 — 밀리초 단위 타임스탬프 (설비끼리 시간이 어긋나면 상관 분석이 깨집니다)

2. 어디서 — 설비 ID + 센서 위치 + 공정 단계

3. 무엇이 — 알람 코드가 아니라 '측정값과 임계값'까지 함께 (예: 진동 4.2mm/s, 임계 3.5)

4. 그래서 어떻게 됐나 — 자동 정지했는지, 경고만 했는지, 무시됐는지

 

특히 네 번째를 빼먹는 현장이 많습니다. 알람이 울렸는데 아무 조치 없이 넘어간 기록이 쌓이면, 나중에 "예지정비를 하겠다"고 해도 학습 데이터가 쓰레기가 됩니다. 제조 AI를 하고 싶다면 로그 설계가 먼저입니다. AI는 좋은 데이터 위에서만 살아남습니다.

 

그래서 뭘 하면 되나 — 월요일 아침에 바로 할 수 있는 한 가지

 

당장 거창한 시스템 개편이 필요 없습니다. 지금 울리고 있는 알람 목록을 뽑아 "10분 안에 행동 가능한가?" 기준으로 한 번만 분류해 보세요. 아마 절반 이상이 격하 대상일 겁니다. 그걸 로그로 내리고, 남는 것만 진짜 알람으로 두는 것. 그게 현장 로그 설계의 시작입니다.

 

화려한 대시보드보다 먼저, 조용한 로그 테이블부터 손보는 게 제가 현장에서 배운 순서입니다.