데이터센터 PUE 이상분석을 통한
냉방기 Fan 단독운전 문제 진단

1. PUE가 높다는 사실은 출발점이지 원인진단의 끝이 아니다

PUE는 데이터센터 전체 전력사용량을 IT Equipment 전력으로 나눈 대표 KPI다. 하지만 PUE가 높다는 숫자만으로 어느 설비가 문제인지 알 수는 없다.

2. 실제 자료에서 센터 평균 PUE는 1.576이었다

다중 IDC 분석자료에서는 센터·층·전산실별 계측데이터와 PUE를 비교했다. 전체적인 PUE 수준을 Benchmark로 두고 상대적으로 높은 전산실을 찾아 세부 냉방설비의 운전상태를 확인하는 방식이었다.

3. 특정 전산실에서 PUE 1.848이라는 이상값이 발견되었다

이 차이를 곧바로 절감률이라고 해석하지 않고, 왜 특정 전산실의 Facility Overhead가 상대적으로 큰지 하위 설비를 추적했다.

4. PUE를 IT Load와 Facility Load로 다시 분해한다

같은 Facility Load라도 IT Load가 작아지면 PUE가 상승할 수 있으므로 PUE 차이를 곧바로 냉방비효율로 단정하지 않는다. IT 부하와 냉방·전력지원 부하를 함께 확인한다.

5. PUE의 이론적 한계 — 같은 PUE라도 원인은 전혀 다를 수 있다

PUE는 Facility Energy를 IT Equipment Energy로 나눈 비율이므로 데이터센터 전체 Overhead를 빠르게 비교하는 데 유용하지만, 그 자체가 냉방효율이나 설비고장의 원인을 직접 설명하지는 않는다. IT Load가 감소하면 Facility Load가 크게 변하지 않아도 분모효과로 PUE가 상승할 수 있고, 기후·부하·전력계통·냉방방식이 다른 센터의 PUE를 단순 비교하는 것도 주의해야 한다.

따라서 PUE는 상위 Screening KPI로 사용하고, 원인분석에서는 IT Load, Cooling Power, Power-distribution Loss와 설비운전상태로 분해한다.

6. ASHRAE Thermal Guidelines — 냉방 최적화의 목표는 ‘가장 차갑게’가 아니다

ASHRAE TC 9.9의 Data Center Thermal Guidelines에서 일반적인 A1~A4 장비의 권장 Air Inlet Dry-bulb Temperature 범위는 18~27°C다. Allowable 범위는 장비 Class에 따라 더 넓을 수 있지만, 권장범위와 허용범위는 같은 의미가 아니다.

따라서 냉방에너지를 줄인다고 단순히 Room Set Point를 올리는 것이 아니라 실제 IT Equipment Inlet Condition이 장비 요구범위에 있는지 Rack-level Sensor로 확인하면서 조정해야 한다.

7. Room 평균온도보다 Rack Inlet Temperature가 중요하다

데이터센터 Room 평균온도가 정상이어도 일부 Rack에서 Hot-air Recirculation이 발생하면 국부 Hot Spot이 생길 수 있다. 반대로 Room Set Point를 과도하게 낮추면 모든 Rack을 필요 이상으로 냉각하면서 Cooling Energy를 낭비할 수 있다.

8. Hot/Cold Aisle은 차가운 공기와 뜨거운 공기의 혼합을 줄이는 기본기다

미국 LBNL의 Energy-efficient Data Center Design Guide는 Rack을 Cold Aisle과 Hot Aisle이 교대로 형성되도록 배치하고, 서버가 Front-to-back Airflow를 유지하도록 구성하는 것을 기본적인 Air Management 방법으로 제시한다. 빈 Rack Slot의 Blanking Panel과 Cable Opening Seal도 Bypass와 Recirculation을 줄이는 데 중요하다.

즉 Cooling Capacity를 늘리기 전에 이미 공급한 차가운 공기가 서버 Intake까지 제대로 도달하는가부터 확인한다.

9. Containment는 Supply Air와 Return Air의 Short-circuit를 줄인다

Cold Aisle 또는 Hot Aisle Containment를 적용하면 Supply와 Exhaust Air의 혼합을 줄이고 Return-air Temperature를 높여 Cooling Coil의 ΔT를 확보할 수 있다. ASHRAE의 AI Data Center Framework도 Hot/Cold Aisle, Containment, Bypass/Recirculation 최소화를 Cooling Optimization의 기초로 제시한다.

Containment 이후에는 Rack Inlet Condition을 확인하면서 Supply Temperature와 Fan Airflow를 재조정해야 실제 Energy Saving으로 연결된다.

10. Fan Affinity Laws — 속도를 조금 낮추면 Fan Power는 크게 감소할 수 있다

동일 Fan과 유사한 System 조건에서 Affinity Law의 기본관계는 Flow가 회전수에 비례하고, Pressure가 회전수의 제곱, Power가 회전수의 세제곱에 비례하는 것이다.

예를 들어 이론적으로 회전수를 100%에서 80%로 낮추면 Fan Power는 약 0.8³ = 0.512 수준이 될 가능성이 있다. 다만 실제 System Curve, Motor/Drive Efficiency, Minimum Airflow와 Control Limit 때문에 실제 절감률은 현장 측정으로 검증해야 한다.

11. EC Fan과 VFD의 공통목표는 ‘필요한 Airflow만 공급’하는 것이다

기존 정속 Fan을 EC Fan으로 교체하거나 AC Motor에 VFD를 적용하면 IT Load와 Thermal Demand에 따라 Fan Speed를 조절할 수 있다. 중요한 것은 기술명 자체가 아니라 Over-airflow를 줄이고 필요한 Airflow를 효율적으로 공급하는 Control Strategy다.

Fan Speed Reset은 Rack Inlet Temperature, Differential Pressure 또는 가장 불리한 Zone의 Cooling Demand와 연계할 수 있다.

12. ASHRAE의 최근 방향도 Air Management를 Advanced Control보다 먼저 둔다

ASHRAE의 AI Data Center Energy Performance Framework는 Hot/Cold Aisle과 Containment, Bypass/Recirculation 최소화, 실제 IT Load에 맞춘 CRAH/CRAC Fan Speed, Rack Inlet Monitoring을 기초적인 권장사항으로 제시한다.

즉 AI를 적용하기 전에 Airflow Mixing과 Sensor Placement 같은 물리적 기본문제를 먼저 해결해야 한다.

13. 분석범위를 센터 → 전산실 → 냉방설비 순으로 좁혔다

이 Top-down 방식은 수많은 냉방설비를 처음부터 모두 점검하는 것보다 에너지 이상이 발생한 위치를 먼저 좁혀 점검 우선순위를 만드는 데 유리하다.

14. 실제 원인은 일부 냉방기의 Fan 단독운전이었다

세부 운전상태를 확인한 결과 일부 냉방기에서 냉각 없이 Fan만 운전되는 상태가 확인되었다. IT 공간에 유효한 냉방을 제공하지 않으면서 Fan 전력은 계속 소비하는 운전상태가 PUE 열위의 한 원인으로 파악된 것이다.

15. Fan이 돈다고 항상 ‘쓸모없는 운전’은 아니다

데이터센터 냉방기는 온도·습도·공기혼합·Pressurization과 Air Distribution을 위해 Fan 운전이 필요할 수 있다. 따라서 Compressor나 Cooling Valve가 Off인데 Fan이 On이라는 조건만으로 비효율이라고 단정해서는 안 된다.

실제 판단에서는 IT Room Temperature, Return/Supply Air Condition, Cooling Demand와 Control Sequence를 함께 확인해야 한다.

16. Fan-only 상태가 비정상인지 Control Sequence를 확인한다

17. Fan 전력은 속도제어 방식에 따라 크게 달라질 수 있다

정풍량 Fan을 항상 정격에 가깝게 운전하면 IT Load가 낮은 시간에도 Fan Power가 지속된다. EC Fan이나 VFD를 적용하여 Airflow Demand에 맞춰 속도를 조절하면 불필요한 Fan Power를 줄일 가능성이 있다.

18. 하지만 Fan 속도는 Rack Inlet Condition을 기준으로 결정해야 한다

Fan Energy를 줄이기 위해 Airflow를 과도하게 낮추면 Hot Spot과 Recirculation이 발생할 수 있다. 따라서 Server Rack Inlet Temperature와 Airflow Distribution을 제약조건으로 두고 Fan Speed를 조정해야 한다.

19. 문제를 찾은 뒤에는 ‘왜 Fan-only가 발생했는가’를 다시 추적한다

Schedule 오류, Manual Override, Sensor Error, Control Logic, Minimum Fan Speed, Cooling Valve Interlock 또는 장비고장 등 여러 원인이 있을 수 있다.

즉 Fan-only Operation은 Root Cause의 최종 이름이라기보다 추가 점검이 필요한 운전상태 이상으로 보는 것이 안전하다.

20. 개선 전후는 PUE 하나만으로 평가하지 않는다

Fan 운전로직을 수정한 뒤 IT Load가 달라지면 PUE도 자연스럽게 변할 수 있다. 따라서 Fan kWh, Cooling kWh, IT kWh, Room Condition과 PUE를 함께 비교해야 한다.

21. 18단계 Data Center Root-cause Process

① Total Power → ② IT Power → ③ PUE → ④ Center Benchmark → ⑤ Room/Floor PUE → ⑥ IT Load 확인 → ⑦ Cooling Power → ⑧ Unit Status → ⑨ Fan Power → ⑩ Cooling Call → ⑪ Supply/Return Air → ⑫ Room Condition → ⑬ Schedule/Override → ⑭ Control Logic → ⑮ Root Cause → ⑯ Corrective Action → ⑰ Before/After M&V → ⑱ 지속 Monitoring

22. FDD는 ‘PUE가 높다’를 ‘어떤 Fault가 발생했는가’로 바꾼다

Fault Detection & Diagnostics(FDD)는 Fan Command와 Feedback, Cooling Valve, Supply/Return Temperature, Room/Rack Temperature, Differential Pressure와 Power 데이터를 조합해 정상 Sequence와 다른 운전상태를 자동 탐지하는 접근이다.

CASE70의 Fan-only 상태도 이러한 Rule Set의 하나로 발전시킬 수 있으며, 향후에는 Sensor Fault, Stuck Valve, Simultaneous Heating/Cooling, Excess Airflow와 Cooling Unit Short Cycling까지 확장할 수 있다.

23. 해외 AI 사례 — Google은 센서데이터로 냉방에너지를 최대 40% 줄였다고 보고했다

Google DeepMind는 2016년 자사 Data Center에서 Temperature, Power, Pump Speed, Set Point 등 수천 개 Sensor의 Historical Data를 이용해 Neural Network Model을 구축하고 미래 PUE와 Temperature/Pressure를 예측했다. Google은 이 시스템의 Live Test에서 Cooling Energy를 최대 40% 줄였으며, 기타 비냉방 손실까지 포함하면 PUE Overhead가 약 15% 감소했다고 보고했다.

이는 CASE70의 성과가 아니라 해외 별도 사례다. CASE70에서는 ‘많은 Sensor Data에서 Cooling Operation과 Energy Performance의 관계를 학습할 수 있다’는 기술동향의 근거로만 사용한다.

24. Recommendation에서 Safety-constrained Autonomous Control로 발전했다

Google DeepMind는 2018년 기존 Operator Recommendation 방식에서 직접 Cooling Control로 확대했다. 시스템은 약 5분마다 Sensor Snapshot을 받아 여러 Action의 미래 Energy Consumption을 예측하고, Safety Constraint를 만족하는 Action만 선택해 Local Control System의 검증을 거쳐 실행하도록 구성되었다.

해당 공개사례에서는 Autonomous Control이 당시 평균 약 30%의 Cooling Energy Saving을 지속적으로 제공했다고 보고했다. 중요한 점은 AI가 자유롭게 모든 Set Point를 바꾸는 것이 아니라 운영자가 정의한 안전경계 안에서만 최적화했다는 것이다.

25. CASE70의 AI 확장도 Advisory → Supervised Control 순서가 현실적이다

먼저 Fan-only, Excess Airflow와 Thermal Anomaly를 자동 탐지하여 운영자에게 권고하는 Advisory Mode를 적용한다. 충분한 검증이 쌓이면 Rack Inlet Temperature, Humidity, Equipment Alarm과 Minimum Airflow를 Hard Constraint로 두고 Fan Speed·Supply Temperature 등의 Set Point를 제한적으로 자동조정할 수 있다.

26. 확대응용 — Rule-based Fault Detection으로 발전시킬 수 있다

Cooling Demand가 없는데 Fan Power가 일정시간 이상 지속되거나, Fan Power는 높은데 Supply/Return Air Temperature Difference가 거의 없는 상태를 Rule로 정의하면 자동으로 이상운전을 탐지할 수 있다.

27. AI 기반 정상운전 모델로 확장할 수 있다

IT Load, 외기조건, Room Temperature와 정상 Fan/Cooling Power 관계를 학습하면 현재 조건에서 예상되는 Cooling Power를 계산하고 실제값과의 Residual을 이용해 비정상운전을 찾을 수 있다.

28. 이 사례의 가치는 ‘PUE → 설비상태’로 연결한 데 있다

PUE는 경영·운영 수준에서 데이터센터 효율을 한 숫자로 보여주지만 개선행동은 냉방기, Fan, 냉동기, 펌프와 Control Sequence에서 일어난다. 따라서 상위 KPI를 하위 설비 데이터와 연결하는 Drill-down 구조가 중요하다.

29. Evidence & Measurement Boundary

1.576과 1.848의 차이를 절감률로 해석하지 않는다. 또한 Fan-only 상태를 제거했을 때의 독립적인 최종 절감률·절감금액은 현재 확보자료에서 확인되지 않으므로 임의로 제시하지 않는다.

Rule-based FDD, 정상운전 모델, Residual 기반 AI Anomaly Detection은 실제 문제발견 사례를 다른 데이터센터에 적용하기 위한 기술적 확장이다.

30. Review 상태

Status: APPROVED / FINAL-LOCK