분전반은 사실 건물의 서버랙이다 — IT 개발자가 전기 설비를 바라보는 방법

IT 하던 사람이 분전반 앞에 처음 서면 좀 낯섭니다.

철제 함을 열면 차단기가 줄지어 꽂혀 있고, 팔뚝만 한 전선이 아래로 빠집니다. 도면에는 MCCB, MCB, ELB 같은 약어가 나옵니다. 처음엔 무슨 소린지 모르겠더라고요.

그런데 구조를 몇 분 들여다보고 나면 이상하게 익숙합니다.

"이거 서버랙이랑 비슷한데?"

분전반과 서버랙은 물론 완전히 다른 장비입니다. 하나는 전력을 안전하게 나누고 보호하는 전기설비이고, 다른 하나는 서버와 네트워크 장비를 얹는 IT 인프라입니다. 같다고 우기면 양쪽 엔지니어 모두에게 혼납니다.

다만 시스템 아키텍처라는 자리에서 보면 둘 사이에 겹치는 지점이 있습니다.

전기공학 교과서가 아니라, 제가 익숙한 눈으로 분전반을 한 번 읽어보려고 합니다.

전기도 들어오고, 나뉘고, 쓰입니다

건물에 전기가 들어오는 과정을 거칠게 줄이면 이렇습니다.

전원 → 수배전 설비 → 분전반 → 개별 회로 → 부하

부하는 조명일 수도 있고 에어컨일 수도 있고, 공장이라면 모터나 기계입니다.

IT 인프라도 비슷하게 놓입니다.

외부 네트워크 → 코어 네트워크 → 스위치 → 서버/서비스

밖에서 들어온 자원을 여러 시스템이 쓰도록 나누어 보냅니다. 하는 일이 같습니다.

클라우드까지 한 칸 더 올리면 더 겹칩니다.

전력 공급 → 전력 분배 → 회로 → 부하

와

컴퓨팅 자원 → 클러스터 → 워커 노드 → 워크로드

한정된 자원을 필요한 곳으로 보내고, 사고가 났을 때 그 사고가 옆으로 위로 번지지 않도록 어딘가에서 끊어내는 것 — 두 그림이 붙잡고 있는 문제는 여기서 정확히 겹칩니다.

분전반이 진짜로 하는 일은 보호입니다

처음엔 분전반을 전기 분배기라고만 생각하기 쉽습니다. 저도 그랬습니다.

기능이 하나 더 있습니다. 보호입니다.

어떤 회로에서 과전류나 단락이 났다고 해보겠습니다. 보호장치가 없으면 그 사고가 상위 계통이나 옆 회로까지 올라탑니다. 그래서 차단기가 있습니다. 문제 난 회로를 끊어서 멀쩡한 회로를 살리는 겁니다.

IT 쪽 말로 옮기면 장애 격리입니다.

마이크로서비스에서도 서비스 하나가 넘어졌다고 시스템 전체를 같이 눕히지는 않습니다. Timeout, Retry, Bulkhead, Circuit Breaker 같은 패턴으로 전파를 끊습니다.

여기서 좀 웃긴 우연이 있습니다. IT에도 Circuit Breaker Pattern, 회로 차단기 패턴이라는 이름이 그대로 삽니다. 전기 차단기에서 가져온 이름입니다. 평소엔 요청을 흘려보내다가 실패가 반복되면 연결을 끊어 확산을 막습니다.

전기든 소프트웨어든 원칙은 같습니다. 장애는 납니다. 문제는 얼마나 빨리 알아채고 어디서 끊느냐입니다.

차단기는 네트워크 스위치가 아닙니다

여기서는 비유를 좀 조심해야 합니다. 분전반을 서버랙에 빗댄다고 차단기가 네트워크 스위치와 같은 역할을 하지는 않습니다.

스위치는 데이터를 목적지로 보내는 게 일이고, 차단기는 전력을 흘리면서 이상할 때 회로를 끊는 게 일입니다. 방향이 다릅니다.

기능을 짝지우지 말고 구조를 짝지우는 편이 정확합니다.

전기 설비	IT 인프라에서 생각해볼 수 있는 개념
전력 공급	컴퓨팅/네트워크 자원
배전	자원 분배
분전반	랙·분배 계층
분기 회로	서비스별 자원 경로
차단기	보호·장애 격리
부하	서버·애플리케이션·워크로드
전력 계측	Monitoring
보호 협조	장애 영향 범위 통제

같은 장비를 1:1로 대응시킨 표가 아닙니다. 산업이 달라도 시스템을 설계할 때 반복해서 나오는 원칙을 나란히 놓아본 것뿐입니다.

그런데 서버 쪽은 모니터링이 넘칩니다

서버 한 대만 굴려도 뽑아내는 데이터가 어마어마합니다.

CPU 사용률, Memory, Disk I/O, Network Traffic, Latency, Error Rate, Log를 계속 봅니다. Kubernetes 환경이면 Prometheus와 Grafana로 클러스터 상태를 실시간으로 띄워둡니다. 임계치를 넘으면 Alert가 옵니다. 새벽 3시에도 옵니다.

그럼 건물과 공장 전체에 에너지를 넣어주는 전기설비는 어떨까요.

산업 현장에도 전력감시시스템, 디지털 계전기, 스마트미터, SCADA, EMS 같은 기술이 이미 깔려 있습니다. 문제는 모든 분전반이 그 수준으로 연결돼 있지는 않다는 겁니다. 오래된 건물이나 소규모 사업장이라면 현장 점검과 계측기에 기대는 부분이 여전히 큽니다.

솔직히 저는 이 대목이 제일 흥미로웠습니다. IT에서는 깔려 있는 게 당연한 계층이 저쪽에는 아직 빈칸으로 남아 있는 셈이니까요.

분전반에 Observability를 붙인다면

분전반에서 전압과 전류, 전력, 역률, 주파수를 계속 읽고, 거기에 차단기 상태와 내부 온도, 회로별 사용량까지 같이 뽑는다고 해보겠습니다.

데이터를 IoT Gateway로 넘기고 중앙 플랫폼에서 받습니다. 줄이면 이렇습니다.

분전반 → Sensor/Smart Meter → Edge Gateway → Network → Data Platform → Dashboard

익숙합니다. 너무 익숙합니다. IT에서 매일 보는 Observability Architecture와 거의 같은 모양이거든요.

데이터가 몇 달 쌓이면 그때부터는 그림이 달라집니다.

고장 확인이 아니라 고장 예측

지금 방식은 대체로 사후 대응입니다.

이상 발생 → 차단 → 장애 확인 → 현장 출동 → 원인 파악

데이터가 쌓이면 순서를 앞으로 당길 여지가 생깁니다. 어떤 회로의 평소 전류가 30A였다고 해보겠습니다. 최근 몇 달 사이 이렇게 움직였습니다.

30A → 32A → 35A → 38A

같은 기간에 특정 접속부 주변 온도도 전보다 올라가 있습니다. 순간 임계치를 넘었는지만 보는 게 아니라

"평소와 다른 패턴이 만들어지고 있는가?"

를 보게 됩니다.

여기에 통계 분석이나 머신러닝을 얹으면 이상 징후 탐지와 예지보전(Predictive Maintenance)까지 이어집니다.

다만 AI를 만능으로 두면 곤란합니다. 전기설비에서 잘못된 판단 하나는 웹서비스 500 에러와 무게가 다릅니다. 저는 이 부분에서는 보수적인 편입니다. AI가 차단기를 직접 제어하는 그림보다는

AI 탐지 → 이상 알림 → 전문가 확인 → 조치

쪽이 현실적입니다. 재미없는 답이라는 건 압니다.

스마트 분전반은 작은 Edge 시스템에 가깝습니다

이렇게 보면 앞으로의 분전반은 차단기를 담아둔 철제 함에서 끝나지 않습니다. 전력을 나누고, 회로를 지키고, 상태를 재고, 데이터를 보내고, 이상을 잡아내는 전력 Edge Device 쪽으로 옮겨갑니다.

공장 단위로 키우면 그림이 커집니다. 각 분전반이 올린 데이터가 중앙 플랫폼에 모입니다. 그러면 공장 관리자는 생산량만이 아니라 설비별 전력 사용량과 이상 패턴을 같은 화면에서 봅니다.

MES가 생산을 띄우고 ERP가 기업의 자원을 다룬다면, 전력 데이터 플랫폼은 이 공장이 실제로 얼마만큼의 에너지를 태우며 돌아가고 있는지를 보여주는 자리입니다.

처음엔 분전반 안의 전선과 차단기가 복잡해 보입니다. 한 단계 위에서 보면 얘기가 달라집니다.

자원이 들어옵니다. 필요한 곳으로 나눕니다. 구역을 격리합니다. 상태를 봅니다. 사고가 나면 범위를 줄입니다. 그리고 쌓인 데이터로 다음 사고를 미리 잡습니다. IT 시스템을 설계하면서 매일 붙잡고 있는 목록과 거의 같습니다.

분전반을 처음 제대로 들여다본 날, 제 머리에 먼저 떠오른 건 이거였습니다. 저건 전기를 담아둔 철제 함이 아니라 건물이라는 큰 시스템에서 전력 자원을 나누고 장애를 격리하는 인프라 계층이구나.

서버랙과 분전반은 같지 않습니다. 그런데 바라보는 방식은 꽤 닮았습니다.

앞으로 분전반에 센서와 네트워크, 데이터 플랫폼, AI가 더 붙기 시작하면 두 세계의 거리는 지금보다 가까워집니다. 어쩌면 스마트 분전반은 전기공학만의 영역이 아니라

전기 × IoT × Edge Computing × Cloud × AI

가 겹치는 자리에서 새로 열리는 인프라 시장일지도 모릅니다. 이건 제 짐작입니다. 저는 전기 쪽 현장을 오래 겪어본 사람이 아니라서, 어디까지가 낭만이고 어디부터가 실제 수요인지는 아직 잘 모르겠습니다.