PUE를 ‘보고용 숫자’에서 ‘운전 의사결정’으로 바꾼
다중 데이터센터 실시간 성능최적화

1. 여러 IDC를 관리하려면 PUE 한 숫자로는 부족했다

센터별 월간 PUE를 비교하면 어느 센터가 상대적으로 높은지, 계절에 따라 어떻게 변하는지는 알 수 있다. 그러나 운영자에게 더 중요한 질문은 “PUE가 목표를 벗어났을 때 무엇을 먼저 확인해야 하는가?”이다.

원 제안자료에는 3개 센터의 2016년 합산 전체 전력사용량 약 176,885 MWh/년, IT 전력 약 97,429 MWh/년, 평균 PUE 약 1.82가 제시되어 있다. 2017년 추정 평균 PUE는 약 1.77이었다. 규모가 큰 여러 센터를 지속적으로 관리하려면 월말 보고서보다 이상이 발생하는 시점에 하위 원인을 바로 추적할 수 있는 진단체계가 필요했다.

2. 실제 월별 PUE는 계절과 센터에 따라 움직였다

원자료의 최근 1년 월별 PUE를 보면 세 센터 모두 계절에 따른 변화가 나타난다. 예를 들어 2016년 9월에는 약 1.95, 1.93, 2.16 수준이었고 겨울철에는 1.5~1.6대로 낮아지는 구간이 있었다. 다시 여름으로 가면서 PUE가 상승하는 패턴도 확인된다.

이 패턴만으로 원인을 확정하지는 않는다. 다만 원 제안서는 타사 비교와 함께 외기냉방 활용수준이 상대적으로 높은 것으로 추정하면서도, 하절기에는 냉방효율과 냉방기효율을 더 높일 필요가 있다고 판단했다. 즉 계절별 PUE 변화가 다음 분석대상을 결정하는 단서가 된 것이다.

3. IPOS의 핵심 — PUE → 냉방효율 → 냉방기효율로 내려간다

실시간 진단체계는 세 단계로 설계되었다. 최상위에는 PUE, 그 아래에는 IT전력 대비 냉방전력을 보는 냉방효율, 다시 아래에는 냉방에너지 공급량과 냉방기 전력의 관계를 보는 개별 냉방기효율을 둔다.

원 제안서에서는 실시간 성능진단을 센터·층 수준으로 수행하고, 개별 냉방기까지 내려가도록 구성했다. 이렇게 하면 PUE가 나빠졌을 때 IT 부하 때문인지, 냉방시스템 때문인지, 특정 냉방기의 성능 때문인지 단계적으로 범위를 좁힐 수 있다.

4. 목표를 벗어나면 — 실제 제안서는 ‘조사내용 → 조치내용’까지 연결했다

원 제안서의 실시간 진단체계는 KPI를 세 단계로 정의했다. PUE는 전체전력소비량 / IT 서버 전력소비량, 냉방효율은 냉방전력소비 / IT 서버 전력소비량, 냉방기효율은 냉방에너지공급 / 냉방기전력소비로 두었다. PUE와 냉방효율은 낮을수록, 냉방기효율은 높을수록 유리한 지표로 설계했다.

실시간 PUE가 목표를 초과하면 먼저 냉방효율을 비교하고, 냉방효율이 목표에 미달하면 Zone별 과냉 여부와 설정온도 대비 실제 실내온도가 유지되는지를 조사하도록 했다. 여기서 문제가 확인되면 냉방기 설정온도를 조정하고, 온도센서의 위치와 정밀도를 조사·교정하며, 부분 과냉구역을 찾아 조치하고 냉방기 가동대수를 조정하는 Action으로 이어진다.

반대로 냉방기 자체의 효율이 목표에 미달하면 조사대상이 달라진다. 냉매 충진 및 Leak, 압축기의 운전압력, 냉각수 유량과 온도, 증발기 열교환 상태를 확인하고, 필요하면 냉매 충진·Leak 수리, 압축기 Leak 부위 수리, 냉각탑·냉각수 계통 확인 및 수리, 열교환기 청소를 수행하도록 제안했다.

5. 데이터 구조 — 기존 계측을 버리지 않고 DB-to-DB로 여러 센터를 연결했다

IPOS 구축을 위해 모든 센터의 계측시스템을 새로 만드는 방식은 아니었다. 원 제안서의 시스템 구성은 각 센터의 기존 Server와 신규 IPOS Server를 DB-to-DB 방식으로 연결하고, 이미 확보된 계측데이터를 통합하는 구조였다.

연계대상에는 항온항습기 출구온도, 전산실 온도, 항온항습기 전력량과 UPS 전력량이 포함되어 있었다. 필요한 경우 냉방기·냉동기별 전력량과 입·출구 온도를 추가 계측하고, 기존 온도센서는 교정하도록 제안했다. 냉방기 사양과 제어로직 조사도 데이터 기반 진단의 사전작업으로 포함했다.

IPOS의 실제 기능도 구체적이었다. 센터 전체 및 층별 PUE, IT장비와 냉방에너지의 전력소비량, 냉방효율, 개별 냉방기·냉동기 효율, 설정온도·전산실온도·공급온도를 실시간으로 표시하고, 임의 기간의 과거 실적을 다시 조회하도록 했다.

분석기능에는 IT 부하 vs PUE, 외기온도 vs PUE, 외기온도 vs 냉방효율, 설정온도 vs 냉방기 COP의 관계분석이 포함되었다. 또한 운전패턴 변경과 조치사항을 일지로 기록·공유하고, 냉방기·냉동기의 사양·성능·개보수 이력을 관리하도록 설계했다. 즉 Trend를 보는 시스템과 현장 조치의 이력을 연결하려는 구조였다.

6. 약 594대의 냉방설비 — 설치용량보다 실제 부하가 훨씬 작았다

원 제안자료를 기반으로 정리된 수치에서는 냉방설비 약 594대, 총 용량 약 14,890 RT/h, 평균 냉방부하 약 3,154 RT/h, 평균 부하율 약 21% 수준이 제시되어 있다.

이 수치는 곧바로 설비가 과다하다는 결론을 의미하지 않는다. 데이터센터는 Redundancy와 장애 대응을 위한 예비용량이 필요하다. 다만 실제 평균부하와 설치용량의 차이가 크기 때문에 필요대수와 실제 가동대수, 개별 냉방기의 부하율을 지속적으로 확인할 필요가 있다는 강한 분석동기가 된다.

7. 1차 목표와 중장기 목표를 단계화했다

2017년 추정 PUE 약 1.77을 출발점으로, IPOS 구축 후 24개월의 1차 성능개선 목표는 PUE 1.70으로 설정되었다. 이에 대응하는 제안단계 예상효과는 연간 약 6.5 GWh, 약 7.53억원이며 냉방에너지 절감률 약 8.81%가 제시되었다.

중장기 목표는 PUE 1.65로 단계화했고, 연간 약 11.3 GWh, 약 13.10억원, 냉방에너지 절감률 약 15.3%의 예상효과가 제시되었다.

8. 성능개선 항목 — 원 제안서는 ‘운전최적화’와 ‘설비성능’을 분리해 관리했다

원 제안자료는 개선항목을 두 축으로 명확히 나누었다. 첫 번째는 운전방법을 바꾸는 최적화이고, 두 번째는 설비 자체의 성능을 개선하는 활동이다. 이 구분은 투자 없이 또는 적은 비용으로 가능한 조치와 설비 보수·교체가 필요한 조치를 구별하는 데 유용하다.

예를 들어 냉방효율이 나쁘다고 해서 바로 냉방기를 교체하지 않는다. 먼저 설정온도, 과냉, 가동대수와 Fan 제어로직 같은 운전항목을 확인하고, 그래도 특정 설비의 COP가 지속적으로 낮다면 냉매·열교환기·냉각수계통과 같은 설비성능 문제로 내려간다. 운전문제와 설비문제를 분리해 진단하는 것이 불필요한 투자를 줄이는 방법이다.

원 제안서에는 IPOS 화면 예시로 필요대수 vs 실제 가동대수, 개별센터 실시간 진단과 복합 Trend 분석도 포함되어 있었다. 따라서 이 플랫폼은 단순 Monitoring Dashboard가 아니라 ‘현재 몇 대를 운전해야 하는가’, ‘어떤 설비가 성능열위인가’를 판단하는 운전지원 도구를 지향했다.

9. 분석에서 실행과 M&V까지 이어지는 절차

원 제안자료의 성능개선 절차는 IPOS 데이터 분석 → 문제점 확인 → 개선방안과 절감량 측정방법 결정 → 필요 시 투자경제성 분석과 투자결정 → 절감활동 실행 → 시스템을 통한 절감효과 분석으로 구성되었다. 이 구조에서 중요한 것은 개선안을 찾는 순간부터 “나중에 이 효과를 어떻게 측정할 것인가?”를 함께 결정한다는 점이다.

10. 이 사례에서 배울 수 있는 것

여러 데이터센터를 관리할 때 PUE를 하나의 순위표로만 사용하면 운영자가 무엇을 해야 하는지 알기 어렵다. PUE를 냉방효율과 개별 냉방기효율로 분해하고, 목표 이탈 시 조사항목과 조치항목을 연결하면 KPI가 실제 운전의사결정 체계로 바뀐다.

또한 데이터센터의 효율개선은 설비용량을 단순히 줄이는 문제가 아니다. Redundancy와 서비스 안정성을 유지하면서 실제 부하에 맞는 가동대수와 설정온도, Free Cooling, 냉각수계통과 개별 설비성능을 지속적으로 조정해야 한다.

11. Review 상태

Status: USER-REVIEW / NOT FINAL-LOCK