1. 왜 "실시간"이 중요해졌는가

친구야, 솔직히 말해볼게. 예전 오피스 빌딩 에너지 관리는 이랬어.
매달 한전 고지서가 날아오면, 관리소장님이 엑셀 열고 "어? 지난달보다 300만 원 늘었네?" 하고 한숨 쉬는 거.
그리고 끝. 원인은 아무도 모름.

이게 왜 문제냐면, 고지서는 이미 지나간 과거라서 그래.
7월 전기요금을 8월에 알게 되면, 7월에 냉동기가 이상하게 돌았던 그 3일은 이미 복구 불가능한 손실이야.
게다가 국내 상업·업무건축은 건물 전체 에너지 소비의 상당 부분을 공조(HVAC)와 조명이 차지하는데, 이 둘은 제어 여지가 굉장히 큰 항목이거든.

1-1. 실시간 모니터링이 만들어내는 실제 효과

미국 에너지부(DOE)와 로렌스 버클리 국립연구소(LBNL) 계열 연구들이 반복적으로 보고하는 내용은 꽤 일관돼.
상세 계측 + 지속적 커미셔닝(Ongoing Commissioning)을 적용하면 기존 건물에서 대략 5~15% 수준의 에너지 절감이 설비 교체 없이도 나온다는 거야.
왜? 대부분의 낭비는 고장이 아니라 오작동에서 오기 때문이지.

대표적인 낭비 패턴들을 볼까.

이 다섯 가지는 고지서로는 절대 안 보이고, 실시간 트렌드 그래프로는 30초 만에 보이는 것들이야.
특히 ⑤번, 기저부하(Base Load) 분석은 초보자도 바로 성과 내는 꿀팁이니까 기억해둬.

2. 시스템 아키텍처 — 4계층 구조로 이해하기

실시간 에너지 모니터링 시스템(EMS)은 대체로 4개 계층으로 설계돼.
이걸 머릿속에 박아두면 어떤 벤더의 제안서를 봐도 구조가 딱 보여.

2-1. L1 계측 계층 — 여기서 90%가 결정된다

진짜 솔직하게 말할게. 대시보드가 아무리 예뻐도 계측기가 엉터리면 전부 쓰레기야.
Garbage In, Garbage Out. 이건 에너지 데이터에서 특히 잔혹하게 작동해.

상업·업무건축에서 필수적으로 봐야 할 계측 항목을 정리하면 이래.

2-2. 계측 정확도 등급, 대충 넘기면 안 되는 이유

전력량계 정확도는 IEC 62053 계열 표준으로 등급이 나뉘어.
Class 0.2S / 0.5S / 1 / 2 이런 식이고, 숫자가 작을수록 정확해.

그럼 다 0.2S 쓰면 되지 않나? 하겠지만 가격이 몇 배 차이나.
그래서 실무에서는 계층별 차등 적용을 해.

여기서 중요한 팁. IPMVP(국제 성능검증 프로토콜) 기준으로 절감량을 정산해야 하는 프로젝트(ESCO 사업, 온실가스 배출권 등)라면, 계측 불확도(uncertainty)가 계약서 숫자를 좌우해.
그럴 땐 계측기 등급 + 설치 방법까지 문서화해두는 게 안전해.

3. 통신 프로토콜 — 건물 데이터의 언어들

자, 이제 센서가 읽은 값을 서버까지 가져와야 해.
문제는 건물 설비들이 서로 다른 언어를 쓴다는 거야. 진짜 바벨탑이야.

3-1. Modbus — 단순하지만 여전히 왕좌

1979년 Modicon(현 슈나이더)이 만든 프로토콜인데, 아직도 전력량계 시장의 사실상 표준이야.
이유는 간단해. 미친 듯이 단순해서 고장날 여지가 적어.

# Modbus RTU 요청 프레임 구조
[슬레이브 주소 1B][기능코드 1B][데이터 N B][CRC16 2B]

# 예: 슬레이브 3번의 홀딩 레지스터 0x0000 부터 2개 읽기
03 03 00 00 00 02 C4 xx
 |  |  |     |     └ CRC
 |  |  |     └ 레지스터 개수 (2 = 32bit float 1개)
 |  |  └ 시작 주소
 |  └ 기능코드 03 (Read Holding Registers)
 └ 슬레이브 ID

RS-485 기반의 Modbus RTU는 데이지체인으로 한 루프에 수십 대를 물릴 수 있어.
근데 설계할 때 반드시 지켜야 하는 규칙이 있어.

여기서 계산 감각 하나 알려줄게.
슬레이브 한 대 폴링에 대략 100~200ms 걸린다고 보면, 30대면 3~6초가 한 바퀴야.
근데 각 미터에서 전압·전류·전력·역률·kWh 등 20개 포인트를 읽으면 시간이 더 늘어나.
그래서 "1분 주기 수집"을 원하면 루프당 슬레이브 수를 보수적으로 잡아야 해. 이거 설계 단계에서 안 따져보면 현장에서 통신 타임아웃 지옥을 맛봐.

3-2. BACnet — 빌딩 자동화의 공용어

ASHRAE가 만들고 ISO 16484-5로 국제표준화된 프로토콜이야.
Modbus가 "숫자 주소로 값 읽기"라면, BACnet은 객체(Object) 지향이야.

BACnet의 장점은 객체마다 이름·단위·설명이 붙어 있다는 거야.
Modbus는 "레지스터 40001이 뭔지" 매뉴얼 보고 사람이 매핑해야 하는데, BACnet은 Device Discovery로 스캔하면 목록이 쫙 나와.

대신 단점도 있어. MS/TP는 느려. 보통 38.4~76.8kbps 정도라서 대량 데이터 수집엔 부적합해.
그래서 최근 신축 오피스는 주요 제어기는 BACnet/IP, 말단 소형 제어기는 MS/TP로 혼합 설계하는 게 일반적이야.

3-3. MQTT — 클라우드로 올릴 때의 정답

게이트웨이에서 서버로 데이터를 올리는 구간은 요즘 거의 MQTT야.
Publish/Subscribe 모델이고, 헤더가 2바이트부터 시작하는 초경량 프로토콜이지.

</pre>

<div class="tx-box">
<p><strong>MQTT 설계 시 꼭 챙길 것</strong><br><br>
• <strong>QoS 레벨</strong>: 에너지 계측값은 보통 QoS 1(최소 1회 전달)이 적정. QoS 2는 오버헤드가 커.<br><br>
• <strong>Retained 메시지</strong>: 대시보드가 재접속했을 때 "마지막 값"을 바로 보여주려면 필수.<br><br>
• <strong>Last Will & Testament(LWT)</strong>: 게이트웨이가 죽으면 자동으로 "offline" 메시지 발행. 통신 단절 감지에 최고.<br><br>
• <strong>TLS 암호화 + 클라이언트 인증서</strong>: 건물 데이터도 엄연히 보안 대상. 8883 포트 쓰자.<br><br>
• <strong>Store & Forward</strong>: 인터넷이 끊겼을 때 게이트웨이 로컬에 버퍼링. 이게 없으면 통신 장애 구간이 데이터 구멍(hole)으로 영구히 남아.</p>
</div>
</section>

<section class="tx-sec">
<h2 class="tx-h2">4. 데이터 계층 설계 — 시계열 DB의 세계</h2>

<p>여기서 초보자들이 제일 많이 하는 실수. <strong>MySQL에 그냥 다 쑤셔넣기.</strong></p>

<p>왜 안 되는지 계산해볼게.<br>
중형 오피스 빌딩에 계측 포인트 <strong>500개</strong>, 수집 주기 <strong>1분</strong>이라고 하면?</p>

<div class="tx-box">
<p>500 포인트 × 60분 × 24시간 = <strong>일 72만 레코드</strong><br>
× 365일 = <strong>연 2억 6천만 레코드</strong><br><br>
포인트를 2,000개로 늘리고 10초 주기로 하면 → <strong>연 63억 레코드</strong> 😵</p>
</div>

<p>일반 RDB로 이걸 처리하면 인덱스가 터지고 집계 쿼리가 몇 분씩 걸려.<br>
그래서 <strong>시계열 데이터베이스(TSDB)</strong>를 써야 해.</p>

<table class="tx-tb">
<tr><th>TSDB</th><th>특징</th><th>적합한 경우</th></tr>
<tr><td>InfluxDB</td><td>전용 TSDB, 태그 기반 인덱싱, 다운샘플링 내장</td><td>포인트 많고 쓰기 부하 큰 대형 건물군</td></tr>
<tr><td>TimescaleDB</td><td>PostgreSQL 확장, 표준 SQL 사용 가능</td><td>기존 SQL 자산·조인 쿼리가 많은 경우</td></tr>
<tr><td>Prometheus</td><td>Pull 방식, 메트릭/모니터링 특화</td><td>설비 상태 감시 중심, 장기보관은 별도</td></tr>
<tr><td>Apache IoTDB</td><td>산업 IoT 특화, 고압축률</td><td>초고빈도(초 단위) 대량 수집</td></tr>
</table>

<h3 class="tx-h3">4-1. 보존 정책(Retention Policy) 설계</h3>

<p>모든 데이터를 원본 해상도로 영구 보관할 필요는 없어.<br>
<strong>계단식 다운샘플링</strong>이 정석이야.</p>

<svg class="tx-svg" width="1050" height="480" viewBox="0 0 1050 480" xmlns="http://www.w3.org/2000/svg">
<rect x="0" y="0" width="1050" height="480" fill="#ffffff" stroke="#e3eaf5" stroke-width="2"/>
<text x="525" y="45" text-anchor="middle" font-size="27" font-weight="700" fill="#2b3a67">계단식 데이터 보존 정책</text>

<rect x="60" y="90" width="180" height="300" rx="12" fill="#fff0f0" stroke="#ff9b9b" stroke-width="2"/>
<text x="150" y="130" text-anchor="middle" font-size="20" font-weight="700" fill="#d64545">RAW</text>
<text x="150" y="165" text-anchor="middle" font-size="17" fill="#666">1분 해상도</text>
<text x="150" y="200" text-anchor="middle" font-size="17" fill="#666">보존 30일</text>
<text x="150" y="245" text-anchor="middle" font-size="16" fill="#999">실시간 감시</text>
<text x="150" y="272" text-anchor="middle" font-size="16" fill="#999">알람 판정</text>
<rect x="90" y="300" width="120" height="60" rx="8" fill="#ffd6d6"/>
<text x="150" y="338" text-anchor="middle" font-size="18" fill="#a83232">100%</text>

<rect x="290" y="130" width="180" height="220" rx="12" fill="#f0f7ff" stroke="#9cc3ff" stroke-width="2"/>
<text x="380" y="170" text-anchor="middle" font-size="20" font-weight="700" fill="#2f6fd0">15분 집계</text>
<text x="380" y="205" text-anchor="middle" font-size="17" fill="#666">보존 3년</text>
<text x="380" y="245" text-anchor="middle" font-size="16" fill="#999">요금 분석</text>
<text x="380" y="272" text-anchor="middle" font-size="16" fill="#999">피크 관리</text>
<rect x="320" y="290" width="120" height="45" rx="8" fill="#d6e8ff"/>
<text x="380" y="320" text-anchor="middle" font-size="18" fill="#2f6fd0">약 7%</text>

<rect x="520" y="160" width="180" height="160" rx="12" fill="#f2fff8" stroke="#8fe0b8" stroke-width="2"/>
<text x="610" y="200" text-anchor="middle" font-size="20" font-weight="700" fill="#1e9e6a">시간 집계</text>
<text x="610" y="235" text-anchor="middle" font-size="17" fill="#666">보존 10년</text>
<text x="610" y="272" text-anchor="middle" font-size="16" fill="#999">연간 벤치마킹</text>
<rect x="550" y="288" width="120" height="25" rx="6" fill="#d6f7e6"/>
<text x="610" y="307" text-anchor="middle" font-size="16" fill="#1e9e6a">약 1.7%</text>

<rect x="750" y="190" width="180" height="100" rx="12" fill="#f8f4ff" stroke="#c9b6f0" stroke-width="2"/>
<text x="840" y="228" text-anchor="middle" font-size="20" font-weight="700" fill="#6a4fc1">일/월 집계</text>
<text x="840" y="262" text-anchor="middle" font-size="17" fill="#666">영구 보존</text>

<path d="M240 240 L290 240" stroke="#9aa5b8" stroke-width="3"/>
<path d="M470 240 L520 240" stroke="#9aa5b8" stroke-width="3"/>
<path d="M700 240 L750 240" stroke="#9aa5b8" stroke-width="3"/>

<text x="525" y="435" text-anchor="middle" font-size="18" fill="#777">※ 집계 시 평균값만 저장하면 피크를 놓친다 → min / max / avg / sum 을 함께 저장</text>
</svg>

<div class="tx-warn">
<p><strong>⚠️ 집계할 때 절대 놓치면 안 되는 것</strong><br>
15분으로 다운샘플링할 때 <em>평균만</em> 저장하면, 수요전력(Demand) 피크가 뭉개져서 사라져.<br>
한국전력 요금제에서 <strong>기본요금은 최대수요전력 기준</strong>으로 산정되거든.<br>
그래서 반드시 <u>max 값을 별도 필드로 함께 저장</u>해야 해. 이거 놓치면 피크 분석이 전부 무의미해져.</p>
</div>

<h3 class="tx-h3">4-2. 태그 기반 데이터 모델 — Haystack & Brick</h3>

<p>포인트가 500개 넘어가면 이름만으로 관리가 불가능해져.<br>
"AHU_12F_03_SA_TEMP" 이런 이름을 사람이 다 기억할 수 있겠어? 못 해.</p>

<p>그래서 나온 게 <strong>의미론적 태깅(Semantic Tagging)</strong>이야.</p>

<pre><code>// Project Haystack 스타일 태깅
{
  id: "p:bldgA:ahu12-sa-temp",
  dis: "12F AHU-03 급기온도",
  point: true,
  sensor: true,
  temp: true,
  air: true,
  discharge: true,
  unit: "°C",
  equipRef: "@ahu12",
  siteRef: "@bldgA",
  floorRef: "@12F"
}

이렇게 해두면 "이 건물 모든 AHU의 급기온도 센서를 가져와" 같은 쿼리가 한 줄로 끝나.
신규 건물을 추가할 때도 태그 규칙만 맞추면 대시보드가 자동 생성돼.
Brick Schema는 이걸 좀 더 학술적·온톨로지 기반으로 정리한 표준이고, 최근엔 ASHRAE 223P 표준화 작업도 진행 중이야.

5. FDD — 고장을 스스로 찾아내는 두뇌

여기가 진짜 재밌는 파트야.
FDD(Fault Detection & Diagnostics), 즉 고장 검출 및 진단.
데이터만 쌓아놓고 사람이 보는 건 한계가 있어. 룰이 알아서 잡아줘야 해.

5-1. 룰 기반 FDD 실전 예제

# 룰 1: 동시 냉·난방 감지
IF cooling_valve_position > 10%
   AND reheat_valve_position > 10%
   AND duration > 15min
THEN alert("동시 냉난방 — 에너지 이중 소비", severity=HIGH)

# 룰 2: 스케줄 외 가동
IF ahu_status == ON
   AND is_occupied_schedule == False
   AND duration > 30min
THEN alert("비점유 시간 공조 가동", severity=MEDIUM)

# 룰 3: 이상 기저부하
IF hour BETWEEN 02:00 AND 04:00
   AND base_load_kw > (peak_load_kw * 0.30)
THEN alert("야간 기저부하 과다 — 미차단 부하 점검", severity=MEDIUM)

# 룰 4: 냉동기 효율 저하
IF chiller_load_ratio > 40%
   AND chiller_kW_per_RT > (baseline_kW_per_RT * 1.15)
THEN alert("냉동기 효율 15% 이상 저하 — 응축기 스케일/냉매 점검")

# 룰 5: 센서 고착(Stuck) 감지
IF stddev(sensor_value, window=2h) < 0.01
   AND sensor_type == "analog"
THEN alert("센서 값 고착 의심 — 데이터 신뢰도 이상")

특히 5번 룰은 꼭 넣어. 센서가 고장나도 값이 계속 나오면 아무도 모르거든.
"어? 저 층 온도가 3개월째 정확히 23.0℃네?" 하는 순간 소름 돋을 거야.

5-2. 베이스라인 모델 — 절감을 "증명"하는 방법

실시간 모니터링의 궁극적 목적은 성과 검증이야.
"우리 조명 LED로 바꿨는데 진짜 줄었나요?"에 답해야 하잖아.

이때 쓰는 표준 방법이 기상 보정 회귀 모델이야.
가장 널리 쓰이는 건 ASHRAE Guideline 14의 Change-Point 모델(3P/4P/5P)이지.

이 모델이 있으면 "만약 개선을 안 했다면 이만큼 썼을 것"이라는 가상 기준선을 계산할 수 있어.
그리고 실제 사용량과의 차이가 곧 절감량이지. 이게 IPMVP Option C(전체 시설 계측) 방식의 핵심이야.

6. 대시보드 설계 — 보여주는 것도 기술이다

여기서 많이들 망해. 데이터 다 모았는데 대시보드에 그래프 40개를 한 화면에 꽂아버리는 거지.
그럼 아무도 안 봐. 진짜로. 3일 보고 안 봐.

6-1. 사용자별 역할 기반 화면 분리

6-2. 반드시 넣어야 할 4대 시각화

참고로 이런 시각화 설계 감각은 재능넷 같은 재능 공유 플랫폼에서 데이터 시각화·BEMS 실무 경험자에게 직접 피드백을 받아보면 훨씬 빠르게 늘어.
혼자 벤더 매뉴얼만 파는 것보다 실제로 그 화면을 운영해본 사람의 한마디가 몇 주를 줄여주거든.

7. 상업·업무건축 특수 요구사항

7-1. 테넌트 서브미터링과 요금 배분

오피스 빌딩의 진짜 골치 아픈 문제야.
임차인별로 전기요금을 어떻게 나눌까?

7-2. 피크 수요 관리 (Demand Response)

국내 산업·일반용 전력 요금은 기본요금(최대수요전력 기반) + 사용량요금(계절·시간대별) 구조야.
그래서 15분 평균 수요전력의 연중 최댓값 하나가 1년 기본요금을 결정해 버려. 무섭지?

그래서 실시간 시스템에 반드시 들어가는 기능이 수요 예측 및 경보야.

# 15분 수요 예측 알고리즘 (단순 선형 외삽)
elapsed = 현재 경과시간(분)          # 예: 9분
remaining = 15 - elapsed             # 6분
current_kWh = 해당 구간 누적 사용량   # 예: 120 kWh
current_rate = 순간 전력             # 예: 820 kW

predicted_demand = (current_kWh + current_rate * remaining/60) * (60/15)

IF predicted_demand > target_demand * 0.95:
    → 1단계 경보 + 비필수 부하 차단 준비
IF predicted_demand > target_demand:
    → 즉시 부하 차단 (Load Shedding) 실행

여기서 핵심 개념은 열관성(Thermal Inertia)이야.
콘크리트 구조체는 열을 품고 있어서, 공조를 15~30분 정도 완화해도 실내온도는 서서히 변해.
이 "버틸 수 있는 시간"을 활용해서 피크만 살짝 깎는 게 세련된 방식이지.
반대로 프리쿨링(Pre-cooling)은 값싼 심야에 미리 식혀두는 전략이고.

7-3. 국내 규제 환경과의 연계

특히 요즘은 ESG 공시 때문에 관심이 폭증했어.
예전엔 "전기요금 아끼자"였는데, 이제는 "우리 건물 시간당 탄소배출량을 증빙하라"는 요구가 들어오는 거지.
시간대별 계통 배출계수와 매칭하려면 최소 시간 단위 데이터가 필수야. 실시간 시스템 없으면 불가능해.

8. 구축 프로세스와 예산 감각

8-1. 단계별 로드맵

8-2. 4단계 포인트 검증, 이렇게 한다

8-3. 투자 회수 감각

정확한 금액은 규모·사양·시장 상황에 따라 크게 달라서 단언하기 어려워.
대신 의사결정 구조를 알려줄게.

실무에서는 ①번과 ②번만으로도 상당수 프로젝트의 회수 근거가 만들어진다는 게 반복적으로 확인돼.
특히 ①번은 돈 안 쓰고 사람이 조작만 바꾸는 영역인데, 이걸 발견하게 해주는 게 모니터링 시스템이지.

9. 흔한 실패 패턴과 회피법

10. 앞으로의 방향 — 디지털 트윈과 AI

마지막으로 요즘 뜨거운 얘기 살짝.

재밌는 건, 이 화려한 기술들 전부가 "정확한 계측 데이터"라는 가장 지루한 기초 위에 서 있다는 거야.
CT 방향 하나 거꾸로 달면 AI도 헛소리를 해. 진짜로.

마무리 — 핵심만 다시

솔직히 이 분야 매력은 "보이지 않던 걸 보이게 만드는 순간"에 있어.
처음 카펫 플롯을 켰을 때 주말마다 빨간 줄이 쫙 그어져 있는 걸 발견하는 기분, 그거 진짜 짜릿해.
그리고 설정 하나 바꿔서 다음 주 그래프가 깨끗해지는 걸 보면... 뭐, 중독이야.

혹시 실제 프로젝트에 적용하려는데 포인트 리스트 작성이나 프로토콜 매핑에서 막힌다면,
재능넷의 지식인의 숲과 전문가 매칭을 활용해서 실무자 검토를 한 번 받아보는 것도 좋은 선택이야.
설계 도면 단계에서 잡는 실수 하나가, 준공 후에는 열 배의 비용으로 돌아오니까.

그럼 오늘은 여기까지! 다음엔 냉동기 최적 대수제어나 AHU 경제운전 쪽으로 더 파볼까? 🙂