다시 켜봤어요? — 재부팅으로 안 잡히는 장애를 풀어내는 현장 엔지니어의 장애 대응 루틴

오늘 점심 쇼츠에서 메타송이가 밈으로 풀어낸 한마디, "다시 켜봤어요?" 사실 이건 농담이 아니라 현장의 공식 절차 1번입니다. 멈춘 로봇 앞에서도, 먹통이 된 HMI 앞에서도 제일 먼저 나오는 말이 "재부팅 한 번 해볼까요?"거든요. 7년차 현장 엔지니어로서 고백하자면, 저도 셀 수 없이 많이 눌렀습니다. 그런데 재부팅이 통할 때와 안 통할 때가 갈립니다. 그 경계를 아는 게 장애 대응의 시작입니다.

 

## 재부팅이 통하는 이유 — '상태'의 문제일 때

 

현장의 많은 장애는 고장이 아니라 '상태 꼬임'입니다. 누적된 카운터, 풀리지 않은 소켓, 메모리 누적으로 버벅이는 HMI, 한 번 어긋나서 돌아오지 않는 시퀀스 플래그. 전원을 껐다 켜면 이 임시 상태가 초기화되니까 당연히 잘 됩니다. 재부팅은 증상 치료제로서는 훌륭하고, 빨리 돌려야 하는 라인에서는 정답이기도 합니다.

 

## 재부팅으로 안 되는 장애 3가지

 

문제는 재부팅이 '증상'만 지운다는 겁니다. 제 경험상 재부팅 후에도 돌아오는 장애는 셋 중 하나였습니다.

 

첫째, 하드웨어 문제. 센서가 드리프트되면 아무리 껐다 켜도 같은 값으로 어긋납니다. 둘째, 통신 문제. 케이블 단선이나 노이즈로 끊긴 Modbus·OPC UA 세션은 재부팅 순간엔 붙었다가 부하가 오르면 또 끊깁니다. 셋째, 데이터·로직 문제. 래더에 숨어 있는 카운터 오버플로우나 조건 하나 빠진 인터락은 재부팅해도 같은 조건에서 정확히 재현됩니다. 실제로 협동로봇이 멈췄던 날, 디지털트윈의 부하 데이터를 보니 재부팅 후 같은 동작 구간에서 과부하가 반복되더군요. 껐다 켜는 건 답이 아니었습니다.

 

## 7년차의 장애 대응 루틴 4단계

 

그래서 저는 장애 앞에서 이 순서를 지킵니다. ① 증상 기록 — 몇 시에, 어떤 동작 중에, 어떤 에러 코드로 멈췄는지. 기억은 휘발되지만 메모는 남습니다. ② 로그 확인 — 알람 이력과 트렌드 데이터를 봅니다. ③ 재현 조건 좁히기 — 같은 동작에서 반복되는지, 특정 시간대에만 나오는지. ④ 원인 분류 — 기계·전기·통신·소프트웨어 중 어디인지 먼저 찍고 파고듭니다. 그리고 무엇보다, 손대기 전에 백업. 이건 철칙입니다.

 

관련 글: 디지털트윈이 '실시간'이 되는 조건 — 샘플링·지연시간·동기화 설계하기 (https://developer-archive.tistory.com/132)

 

---

 

재부팅은 응급처치이고, 진단은 습관입니다. 다음에 "다시 켜봤어요?"라는 말이 나올 때 한 번만 더 물어보세요. "그래서, 왜 멈췄는데요?" 그 질문에 답할 수 있는 로그와 기록이 쌓이면, 그게 바로 현장 엔지니어의 실력입니다. 그래서 뭘 하면 되나 — 오늘부터 장애 날 때마다 '시간·동작·에러코드' 세 줄만 메모해 보세요.