평범한 분전반은 어떻게 스마트 분전반이 되는가? — 센서 하나에서 클라우드까지, 전기·전자·IT가 만나는 지점

|Convergence|19분 읽기

앞선 글에서 전자와 IT, 전기는 생각보다 시스템 구조가 닮았다고 썼습니다.

전자는 신호를 다루고 IT는 정보를 다룹니다. 전기는 에너지를 다룹니다.

다루는 대상은 다릅니다. 그런데 시스템이 하는 일은 비슷합니다. 자원을 전달하고 나누고 제어하고 보호하고 들여다봅니다.

그러면 조금 더 현실적인 질문을 해봅니다.

집이나 건물, 공장 벽에 붙어 있는 평범한 분전반을 '스마트 분전반'으로 만들려면 무엇이 필요할까요?

처음에는 거창하게 생각했습니다.

분전반을 새로 설계해야 하나. 전용 차단기를 개발해야 하나. 센서부터 통신 모듈까지 직접 만들어야 하나.

그런데 IT 하던 눈으로 다시 보니 질문 자체가 틀렸을지도 모르겠더라고요.

이미 만들어져서 잘 돌아가는 전기설비를 왜 처음부터 다시 만들어야 할까요.

필요한 건 새 분전반이 아닐지도 모릅니다. 지금 벽에 붙어 있는 분전반이 자기 상태를 말하게 만드는 일일 수도 있습니다.

기존 분전반은 이미 자기 일을 하고 있습니다

먼저 오해하면 안 되는 게 있습니다.

기존 분전반이 '스마트하지 않다'고 해서 모자란 장비라는 뜻이 아닙니다.

분전반의 목적은 분명합니다. 전력을 여러 회로로 나누고 과전류나 단락 같은 이상 상황에서 회로를 보호합니다. 필요하면 문제가 생긴 회로를 끊습니다.

이 역할은 지금의 전기기술로 이미 잘 하고 있습니다.

그래서 스마트 분전반을 만든다며 기존 보호체계를 소프트웨어로 갈아치우려는 접근은 위험합니다.

AI가 차단기를 대신한다? Cloud가 연결되지 않으면 보호 기능이 멈춘다? 서버가 죽으면 분전반을 못 쓴다?

이런 구조면 원래 시스템보다 나빠집니다.

전력 보호는 기존 전기설비가 맡습니다.

그 위에 계층을 하나 얹는 겁니다.

데이터 계층입니다.

스마트의 시작은 '제어'가 아니라 '측정'입니다

스마트 분전반이라고 하면 스마트폰으로 차단기를 켜고 끄는 그림을 먼저 떠올리기 쉽습니다.

저는 그보다 먼저 할 일이 있다고 봅니다.

측정입니다.

지금 무슨 일이 벌어지는지 모르는 시스템을 제대로 제어하기는 어렵습니다.

IT에서도 똑같습니다. CPU 사용률도 메모리 사용량도 응답시간도 Error Rate도 모르는 상태에서 자동화부터 붙이지는 않습니다. 붙였다가 새벽에 불려 나가 본 사람은 압니다.

먼저 관측합니다.

분전반도 같은 순서로 접근합니다.

모을 데이터를 떠올려 보면 전압과 전류, 유효전력, 전력량, 역률, 주파수가 있습니다. 여기에 분전반 내부 온도와 회로별 사용량, 차단기 상태까지 더합니다. 이 정도면 시작하기에 부족하지 않습니다.

측정을 시작하면 기존 분전반이 조금씩 달라집니다.

전기가 지나가기만 하던 설비에서, 데이터를 만들어내는 설비가 됩니다.

전류는 어떻게 측정할까요?

대표적인 방법 하나가 CT(Current Transformer), 변류기입니다.

거칠게 말하면 큰 전류를 계측장치에 그대로 밀어 넣는 대신, 잴 수 있는 크기의 신호로 바꿔주는 장치입니다.

제품과 구성에 따라 분할형 CT처럼 기존 배선을 크게 건드리지 않고 도체에 물리는 방식도 있습니다.

이 방식이 중요합니다.

스마트 분전반 시장이 반드시 "기존 분전반 철거 → 스마트 분전반 신규 설치"로만 열릴 이유가 없기 때문입니다.

경우에 따라 기존 설비에 계측 기능만 얹는 Retrofit 방식도 있습니다.

IT로 옮기면 쓰던 서버에 Monitoring Agent를 까는 쪽에 가깝습니다.

온도 데이터도 꽤 중요합니다

전기설비에서 열은 신호입니다.

접속 상태, 부하, 주변 환경. 여러 이유로 특정 지점 온도가 비정상적으로 올라갑니다.

그런데 사람이 분전반 앞에 붙어 서서 계속 온도를 잴 수는 없습니다.

온도센서로 데이터를 계속 모으면 이야기가 달라집니다.

평소 어떤 지점이 35℃ 근처에서 오르내렸다고 해봅니다.

그러다 어느 시점부터 35 → 38 → 42 → 47℃ 식으로 긴 흐름의 변화가 나타납니다.

"50℃를 넘으면 경고"라는 임계치 방식과, "이 설비가 평소 패턴에서 벗어나기 시작했다"를 판단하는 건 완전히 다른 문제입니다.

패턴 이탈을 판단하는 쪽이 나중에 AI와 붙는 자리입니다.

다만 아직 AI까지 갈 필요는 없습니다.

데이터를 얻는 게 먼저입니다.

광고

센서를 달았다고 스마트 분전반이 되지는 않습니다

여기서부터 전자와 IT가 들어옵니다.

센서는 데이터를 만듭니다. 그런데 그 데이터가 센서 안에만 머물면 쓸 데가 없습니다. 어딘가에서 읽어야 합니다.

그래서 MCU나 계측장치, Controller 같은 장치가 필요해집니다.

구조는 이렇습니다.

전력 → CT / 전력계측 / 온도센서 → MCU 또는 Controller

여기까지는 전자와 임베디드 쪽 영역에 가깝습니다.

그런데 데이터는 스마트폰이나 관제센터에서 보고 싶습니다.

그러려면 밖으로 내보내야 합니다.

여기서 Gateway가 등장합니다

산업 현장에서는 Modbus 같은 통신방식을 쓰는 장비를 흔하게 만납니다.

계측장치에 데이터가 있고 Gateway가 그걸 읽어 상위 시스템으로 넘기는 구조를 만듭니다.

개념만 놓고 그려 봅니다.

분전반 → Smart Meter / Sensor → RS-485 / Modbus → Edge Gateway → Ethernet / LTE / Wi-Fi → Server / Cloud

이 순간부터 제가 아는 IT 시스템이 됩니다.

Gateway가 하는 일은 데이터를 읽어 서버로 보내는 것입니다.

HTTP API를 쓸 수도 있고 MQTT 같은 메시징을 얹을 수도 있습니다.

현장 요구에 따라 프로토콜과 네트워크 구조는 달라집니다. 그래도 하는 일은 같습니다.

전기설비의 물리적 상태가 디지털 데이터로 바뀌어 IT 시스템 안으로 들어옵니다.

스마트 분전반에서 실제로 달라지는 지점입니다.

아키텍처는 이렇게 됩니다

전체를 아주 단순하게 그리면 이렇습니다.

[전기]   전원 → 차단기 → 부하

[전자]   CT / 전력계측 / 온도센서 → Controller

[Edge]   Gateway → 데이터 전처리 / 통신

[IT]     Network → API / MQTT → Data Platform → Database → Dashboard / Alert

[AI]     이상탐지 → 패턴분석 → 예지보전

이렇게 놓고 보면 스마트 분전반은 전기제품 한 대가 아닙니다.

전기에서 시작해 전자와 Edge를 거쳐 Network와 Cloud를 지나 Data와 AI까지 이어지는 작은 Cyber-Physical System에 가깝습니다.

광고
광고

그런데 전부 직접 만들어야 할까요?

사업 쪽 질문이 하나 남습니다.

스마트 분전반을 하겠다고 CT부터 개발하고 전력계측기를 개발하고 통신모듈을 개발하고 Gateway를 개발하고 Cloud까지 직접 만드는 게 좋은 선택일까요.

저는 꼭 그렇지는 않다고 봅니다.

시장에는 이미 센서와 전력계측기, 통신장치, Gateway가 널려 있습니다. 검증된 물건이 있으면 그걸 씁니다.

IT 업계에서는 익숙한 방식입니다.

웹서비스를 만든다고 Database를 직접 개발하지 않습니다. Kubernetes를 쓴다고 Container Runtime부터 짜지도 않습니다. 필요한 컴포넌트를 고르고 붙여서 새 가치를 만듭니다.

스마트 분전반도 같은 길이 있습니다.

전기설비 제조 역량 + 기존 계측·센서 제품 + 기존 Gateway + 자체 데이터 플랫폼 + Dashboard / App

이렇게 시작합니다.

경쟁력이 반드시 센서 자체에 있을 필요는 없습니다.

어떤 데이터를 모으고 어떻게 잇고, 사용자에게 어떤 의미로 보여주며 그 데이터로 무슨 문제를 푸는가. 저는 이쪽이 더 오래 가는 경쟁력이라고 봅니다.

클라우드가 끊기면 분전반도 멈춰야 할까요?

IT 하던 사람이라면 반드시 걸리는 게 있습니다.

장애입니다.

스마트 분전반이 Cloud에 붙었다고 해봅니다. 그런데 인터넷이 끊깁니다. Cloud Server가 죽습니다. Gateway가 고장 납니다.

그렇다고 전력 보호까지 같이 멈추면 안 됩니다.

그래서 저라면 이런 시스템을 설계할 때 원칙 하나를 먼저 못 박아 둡니다.

전력 보호는 Local에서 독립적으로 동작하고 IT 시스템은 그 위에서 관측과 분석만 맡습니다.

Safety Layer와 Intelligence Layer를 분리하는 겁니다.

차단기와 보호장치는 네트워크가 없어도 그대로 동작합니다. 센서와 Gateway가 죽어도 전력 공급과 보호의 기본 기능은 유지됩니다.

IT 시스템이 없어도 전기는 씁니다. IT 시스템이 있으면 전기설비의 상태를 더 잘 이해합니다. 이 순서가 뒤집히면 안 됩니다.

처음부터 원격제어를 넣지 않아도 됩니다

제품을 만들다 보면 기능을 자꾸 넣고 싶어집니다.

스마트폰으로 차단기를 끄고 AI가 알아서 판단하고 Cloud에서 원격제어하고 목소리로 전원을 켜고 싶어집니다.

솔직히 저도 그 욕심 쪽에 가까운 사람입니다. 기능 목록을 먼저 그려놓고 시작하는 버릇이 있습니다. 지금 봐도 그 순서는 별로였습니다.

전기는 안전과 바로 붙어 있는 영역입니다.

초기 제품이라면 오히려 기능을 덜어내는 쪽이 낫습니다.

첫 단계는 이것만으로도 됩니다.

측정 → 저장 → 시각화 → 알림

사용자는 앱을 열고 확인합니다.

지금 전력 사용량은 얼마인가. 어느 회로가 많이 쓰는가. 평소보다 늘었는가. 분전반 내부 온도가 올라가고 있는가. 특정 시간대에 이상한 패턴이 있는가.

여기까지만 제대로 해도 기존 분전반에 없던 가치가 생깁니다.

데이터와 운영 경험이 쌓인 다음에 제어와 AI를 고민해도 늦지 않습니다.

스마트 분전반의 진짜 제품은 '철제 함'이 아닐지도 모릅니다

여기까지 오면 좀 재미있는 자리에 도착합니다.

기존 분전반 제조업에서는 제품이 눈에 보입니다.

철판을 가공해 함을 만들고 차단기와 부품을 조립합니다. 배선하고 납품합니다.

한 번 팔면 거래가 끝나는 경우가 많습니다.

스마트 분전반에서는 납품 이후에도 관계가 이어집니다.

센서가 계속 데이터를 만들고 서버가 저장합니다. Dashboard가 상태를 보여주고 이상이 생기면 알림이 갑니다. 긴 기간의 데이터를 분석합니다.

그러면 파는 물건이 분전반 한 대로 끝나지 않습니다.

분전반 + 계측 + 연결 + 데이터 + 소프트웨어가 하나의 제품이 됩니다.

월 단위 모니터링이나 유지관리 서비스 같은 사업모델도 여기서 나옵니다.

Hardware 판매가 Software와 Service로 넓어집니다.

광고

전기·전자·IT가 실제로 만나는 지점

처음 질문으로 돌아갑니다.

평범한 분전반은 어떻게 스마트 분전반이 되는가.

분전반 전체를 새로 만들 필요는 없습니다.

기존 분전반은 하던 일을 계속합니다. 전력을 나누고 회로를 보호합니다.

그 위에 센서를 붙입니다. 전자기술이 물리적 상태를 데이터로 바꿉니다. Edge Gateway가 데이터를 나릅니다. IT 플랫폼이 저장하고 보여줍니다.

데이터가 충분히 쌓이면 그때 AI가 패턴을 봅니다.

달라진 것을 한 줄로 줄여 봅니다.

기존 분전반이 전기를 나누는 장비였다면, 스마트 분전반은 전기를 나누면서 자기 상태를 데이터로 말하는 장비입니다.

저는 이 지점이 재미있습니다.

전기만으로 완성되지 않습니다. 전자만으로도 안 됩니다. IT만 들고 만들 수도 없습니다.

전기가 에너지를 맡고 전자가 현실을 잽니다. IT가 데이터를 잇고 그 안에서 패턴을 찾는 건 AI입니다.

서로 다른 분야라고 생각했던 기술들이 분전반이라는 작은 철제 함 안에서 만나기 시작합니다.

어쩌면 스마트 분전반의 경쟁력은 더 좋은 철제 함이 아니라, 그 안에서 나오는 전력 데이터를 무엇으로 바꿔 놓는가에서 갈릴지도 모릅니다. 아직은 저도 확신이 없습니다.

다음 이야기

그러면 다음 질문이 따라옵니다.

서버에서는 CPU, Memory, Network를 실시간으로 봅니다. Kubernetes에서는 수많은 Metric을 모아 Dashboard로 보고 이상이 생기면 Alert를 받습니다.

전기설비는 왜 그렇게 보면 안 될까요.

다음 글에서는 조금 엉뚱한 상상을 해보려고 합니다.

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

이 글이 도움이 되셨나요?

버튼 하나가 다음 글을 쓰는 힘이 됩니다

광고
#스마트분전반#전기설비#IoT#Edge Gateway#Observability#융합