분전반에 Prometheus를 붙인다면? — 전기설비에도 Observability가 필요하다

쿠버네티스를 운영하면서 장애가 발생했다고 생각해보겠습니다. 서비스가 느려졌습니다. 그런데 CPU 사용률도 모르고, 메모리 사용량도 모르고, 네트워크 상태도 모르고, 로그도 남아 있지 않습니다.

운영자가 손쓸 방법은 많지 않습니다. 서버 앞에 가서 상태를 확인하거나 일단 재부팅해 보는 정도일 겁니다. IT에서는 이런 시스템을 정상적인 운영 환경이라고 보기 어렵습니다. 그래서 우리는 Prometheus로 Metric을 수집하고 Grafana로 시각화하고 Alertmanager로 이상 상태를 알립니다.

어느 날 분전반을 보다가 이런 생각이 들었습니다. 전기설비는 왜 이렇게 운영하지 않을까?

물론 실제 분전반에 Prometheus를 직접 설치하자는 이야기는 아닙니다. 제가 말하고 싶은 것은 Prometheus의 철학을 전기설비와 제조업에 적용해보자는 겁니다.

전기설비도 사실 수많은 Metric을 만들고 있다

서버에는 우리가 관찰할 값이 많습니다.

CPU Usage
Memory Usage
Disk I/O
Network Traffic
Temperature
Request Count
Error Rate

우리는 서버의 상태를 숫자로 표현합니다. 그렇다면 분전반은 어떨까요? 분전반과 연결된 전기설비에도 이미 수많은 물리적인 값이 존재합니다.

전압
전류
전력
전력량
역률
주파수
온도
차단기 상태
회로별 부하

차이가 있다면 서버는 이런 데이터를 적극적으로 수집해왔지만 많은 전기설비에서는 그렇지 않았습니다. 전기는 계속 흐르고 있었습니다. 우리가 관찰하지 않았을 뿐입니다.

장애가 발생한 뒤 보는 것과 발생하기 전에 보는 것은 다르다

어떤 설비가 정상 상태에서 평균 20A 정도의 전류를 사용한다고 해보겠습니다. 어느 날 갑자기 고장 난 것이 아니라 조금씩 변합니다.

20.1A
20.3A
20.8A
21.5A
22.7A
24.1A

설비는 아직 돌아갑니다. 작업자 입장에서는 정상입니다. 차단기도 내려가지 않았습니다. 하지만 데이터 관점에서는 이야기가 다릅니다. 무언가 변하고 있습니다.

서버 운영에서도 비슷합니다. CPU가 평소 20%였는데

20%
25%
35%
50%
70%
85%

로 계속 올라가고 있다면 장애가 발생하지 않았더라도 확인해볼 겁니다. 이것이 Monitoring의 가치입니다.

하지만 Monitoring과 Observability는 조금 다르다

여기서 한 단계 더 생각해볼 필요가 있습니다. Monitoring은 보통 우리가 미리 정해놓은 값을 감시합니다. CPU가 90%를 넘었는가? 온도가 70도를 넘었는가? 전류가 설정값을 넘었는가?

Observability는 조금 더 넓은 개념입니다. 여러 데이터를 이용해서 시스템 내부에서 무슨 일이 일어나고 있는지 추론할 수 있는 능력에 가깝습니다. 예를 들어 서버에서 장애가 발생했다고 해보겠습니다. CPU만 보는 것이 아니라 CPU, Memory, Network, Log, Request Latency 등을 함께 보면서 원인을 찾아갑니다.

전기설비도 같은 방식으로 보면 됩니다.

전류 증가
+
온도 상승
+
전력 소비 패턴 변화
+
특정 시간대 반복 발생

이런 데이터가 동시에 나타난다면 단순히 "전류가 높다"보다 훨씬 많은 것이 보입니다.

분전반을 Prometheus Exporter처럼 생각해보자

여기서 IT 개발자에게 익숙한 방식으로 구조를 바꿔보겠습니다. Prometheus는 여러 시스템에서 Metric을 수집합니다. 전기설비도 이런 구조로 놓고 보겠습니다.

[전기 설비]
     │
     ▼
[CT / 전력계 / 온도센서]
     │
     ▼
[Gateway / Edge Device]
     │
     ▼
[Metric Collector]
     │
     ▼
[Time-Series DB]
     │
     ├── Dashboard
     ├── Alert
     └── Analytics

IT 식으로 표현하면 전기설비에 Exporter를 하나 붙이는 것과 비슷합니다. 실제 구현에서는 Modbus, MQTT, OPC UA 등 현장 환경에 맞는 기술을 씁니다. 수집한 데이터는 Prometheus 계열 시스템으로 보내도 되고 다른 시계열 데이터 플랫폼으로 보내도 됩니다.

중요한 것은 어떤 제품을 쓰느냐가 아닙니다. 설비의 상태를 Metric으로 바꾸는 것입니다.

그러면 Grafana에서는 무엇을 볼 수 있을까?

공장에 분전반이 30개 있다고 생각해보겠습니다. 각 분전반과 주요 설비에서 데이터를 수집한다면 하나의 화면에서 이런 것을 볼 수 있습니다.

공장 전체 전력 사용량
공정별 전력 사용량
설비별 부하
분전반별 온도
회로별 이상 상태
시간대별 Peak
전일 / 전주 / 전월 비교
비정상적인 소비 패턴

예전에는 문제가 발생하면 작업자가 현장으로 갔습니다. 분전반을 열어보고 계측기로 측정하고 담당자의 경험을 이용해 원인을 찾았습니다. 데이터가 있다면 순서가 달라집니다.

Dashboard → 이상 위치 확인 → 현장 점검

으로 바뀝니다. 현장 경험을 없애는 것이 아닙니다. 오히려 숙련자의 판단에 필요한 정보를 먼저 제공합니다.

Alertmanager를 붙이면 더 재미있어진다

사람이 하루 종일 Dashboard를 보고 있을 수는 없습니다. 이상 상태가 발생하면 시스템이 알려줘야 합니다. 이런 규칙을 만들면 됩니다.

분전반 온도 > 기준값
→ 관리자 알림

특정 설비 전류 > 정상 범위
→ 설비 담당자 알림

야간 전력 사용량 급증
→ 에너지 이상 알림

특정 회로 데이터 수집 중단
→ 센서 / 통신 상태 점검

IT 운영에서 이미 익숙한 방식입니다. 서버가 죽은 뒤 전화가 오는 것이 아니라 시스템이 먼저 이상을 감지합니다. 전기설비에도 같은 개념이 그대로 통합니다.

중요한 것은 임계값보다 'Baseline'이다

단순한 Threshold만으로는 한계가 있습니다. 예를 들어 전류가 30A를 넘으면 경고라고 설정했다고 생각해보겠습니다. 설비 A에서는 30A가 정상일 수 있고 설비 B에서는 이미 위험한 상태일 수 있습니다. 심지어 같은 설비라도 생산량이나 시간에 따라 정상 범위가 달라집니다.

그래서 데이터가 충분히 쌓이면 더 중요한 것이 생깁니다. Baseline입니다. 이 설비는 평소 어떤 패턴으로 움직이는가?

정상적인 월요일 오전
정상적인 야간
정상적인 최대 생산
정상적인 비가동 시간

이 기준을 알게 되면 단순한 절대값이 아니라 평소와 다른가를 판단하게 됩니다. 그리고 이 지점에서 통계 분석과 AI가 자연스럽게 연결됩니다.

제조업 AX에서 AI보다 먼저 필요한 것이 이것이다

요즘 제조업에서도 AI 이야기가 많습니다. Vision AI, 예지보전, Digital Twin, AI Agent 등 다양한 기술이 등장합니다. 그런데 저는 순서를 반대로 하면 안 된다고 생각합니다.

AI
↑
분석
↑
데이터
↑
수집
↑
센서
↑
현장

AI는 맨 위에 있습니다. 아래가 없으면 위도 없습니다. 센서가 없으면 AI도 설비 상태를 모릅니다. 데이터를 저장하지 않았는데 AI가 과거 패턴을 학습할 수도 없습니다. 설비와 생산 데이터가 연결되어 있지 않다면 AI가 원인을 추론하기도 어렵습니다.

그래서 제조업 AX의 시작은 의외로 화려하지 않습니다. 공장부터 관찰할 수 있게 만들어야 합니다. 이것이 먼저입니다.

Observability의 대상은 분전반에서 공장 전체로 확장된다

여기서부터 이야기가 재미있어집니다. 처음에는 분전반 하나였습니다. 같은 구조가 다른 설비에도 그대로 들어갑니다.

분전반
→ 전력

CNC
→ 가동시간 / 부하 / 알람

레이저 절단기
→ 가동률 / 작업시간

절곡기
→ 작업량 / 대기시간

컴프레서
→ 압력 / 전력 / 가동시간

공장
→ 온도 / 습도 / 에너지

그리고 여기에 생산 데이터를 연결합니다.

설비 데이터
+
전력 데이터
+
생산량
+
불량률
+
작업시간
+
주문정보

이 순간부터 단순한 '스마트 분전반' 이야기가 아닙니다. 공장 전체의 Observability 이야기가 됩니다.

예를 들어 철판 가공 공장을 본다면

철판이 입고됩니다. 레이저로 절단합니다. 절곡합니다. 필요하면 용접합니다. 도장합니다. 조립하고 검사해서 출하합니다.

겉으로 보면 각각 독립적인 제조 공정입니다. 하지만 IT 시스템처럼 보면 하나의 Pipeline입니다.

수주
 ↓
설계
 ↓
자재
 ↓
절단
 ↓
절곡
 ↓
용접
 ↓
도장
 ↓
조립
 ↓
검사
 ↓
출하

그렇다면 질문도 달라집니다. 어디에서 가장 오래 대기하는가? 어떤 설비가 Bottleneck인가? 제품 하나를 생산하는 데 실제 전력은 얼마나 사용되는가? 설비가 가동 중인데 생산량이 나오지 않는 시간은 얼마나 되는가? 불량이 증가하기 전에 어떤 데이터 변화가 있었는가?

이런 질문에 답할 수 있어야 합니다. IT에서 우리가 서비스의 Request Flow를 추적하는 것처럼 제조업에서는 제품이 만들어지는 Flow를 추적합니다.

결국 제조업의 AX는 공장을 '보이게' 만드는 일에서 시작한다

스마트팩토리라고 하면 로봇이 움직이고 AI가 자동으로 생산하는 공장을 떠올리기 쉽습니다. 하지만 그 전에 훨씬 기본적인 질문이 있습니다.

지금 우리 공장에서 무슨 일이 일어나고 있는지 데이터로 설명할 수 있는가?

설명할 수 없다면 자동화도 어렵습니다. 원인을 모르면 최적화할 수도 없습니다. 그래서 저는 제조업의 AX를 IT 시스템에 빗대어 이렇게 생각합니다.

Digitization
↓
Connectivity
↓
Observability
↓
Analytics
↓
AI
↓
Automation

먼저 디지털화하고 연결합니다. 그 위에서 관찰과 분석이 이어집니다. AI와 자동화는 마지막입니다.

분전반에 Prometheus를 붙인다는 말의 진짜 의미

다시 처음 질문으로 돌아가겠습니다. 분전반에 Prometheus를 붙일 수 있을까요? 기술적으로는 실제 Prometheus를 써도 되고 다른 산업용 플랫폼을 써도 됩니다. 이 질문에서 중요한 것은 제품명이 아닙니다.

제가 말하고 싶은 것은 하나입니다. 서버를 운영하면서 당연하게 생각했던 Observability를 왜 제조설비에는 적용하지 않는가?

전기설비의 상태를 Metric으로 만들고 시간에 따라 저장합니다. Dashboard로 관찰하고 이상을 탐지합니다. 생산 데이터와 연결하고 그 위에서 AI가 판단하게 만듭니다. 이렇게 보면 분전반은 단순한 전기 제품이 아닙니다. 공장의 상태를 읽어내는 수많은 데이터 Source 중 하나가 됩니다.

그리고 분전반에서 시작한 작은 Metric 하나가 결국 공장 전체를 관찰하는 시스템으로 확장됩니다. 어쩌면 제조업 AX의 시작은 거대한 AI 프로젝트가 아닐지도 모릅니다.

지금까지 보이지 않던 공장을 먼저 보이게 만드는 것. 저는 그게 시작이라고 생각합니다.