데이터센터는 20년을 가동하지만 냉각 설비는 흔히 과거 30년의 기상 자료로 정합니다. 이제 두 기간이 같은 기후를 나타내지 않습니다. 2022년 영국 폭염 때 기온은 40°C에 도달했고, Google은 35시간 동안 서버 오류 증가와 성능 저하를 관측했습니다[1]. 표준 설계 기온 37.7°C는 과거 자료에서 약 200년에 한 번 일어날 사건이었습니다. 미래 전망에서는 약 50년에 한 번으로 가까워집니다.
Google과 University of Pennsylvania가 ISCA 2026에서 발표한 Prometheus는 이 차이를 시설 설계의 각주가 아니라 컴퓨터 시스템 문제로 다룹니다[1]. 25년의 관측값과 향후 20년의 기후 전망을 결합하고, 각 부지의 건구 또는 습구 한도를 넘을 가능성을 계산한 뒤 세 시간대에 대응 조치를 붙입니다. 20년 장기 설비 계획, 2년 단위 증설, 2주 단위 작업 대응입니다. 실제 데이터센터 30곳에 적용한 결과 평균 냉각 용량을 11% 늘려야 했습니다. 한 부지의 최대 요구량은 48%였습니다.
설계 기온은 확률
냉각 용량에는 서로 다른 두 종류의 온도가 관여합니다. 건구 온도는 일반적인 외기 온도이며 공기로 현열을 내보내는 시스템에 중요합니다. 습구 온도는 습도까지 반영하며 증발식 냉각이 도달할 수 있는 한계를 정합니다. 어떤 부지는 덥고 건조한 오후에, 다른 부지는 덜 덥지만 습한 날에 막힙니다. Prometheus는 모든 부지에 같은 여유값을 붙이지 않고 두 온도를 따로 모델링합니다.
예측 파이프라인은 서포트 벡터 머신(SVM)과 랜덤 포레스트를 기본 모델로 사용하고 신경망이 두 출력을 결합합니다. 부지 관측값은 CMIP6 기후 전망과 연결됩니다[3]. 학습 모델은 해석식 기반값보다 습구 온도 오차를 40~60% 줄였습니다. 대표적인 평균제곱근 오차는 1.7°C에서 0.7°C로 감소했고, 99.5백분위 오차는 60% 이상 줄었습니다. 냉각 설비는 평균값이 숨기는 몇 시간을 버텨야 하므로 꼬리 구간의 정확도가 중요합니다.
변화량은 지역마다 다릅니다. ASHRAE 기상 파일[2]과 비교하면 설계 조건의 평균 차이는 건구 4.4°C, 습구 1.4°C입니다. 고배출 SSP5-8.5 시나리오의 2044년 전망에서는 지역에 따라 건구 기준 온도가 2.0~10.7°C, 습구 기준 온도가 2.7~6.8°C 높아집니다. 런던은 시간 순서를 잘 보여 줍니다. 설계 파일은 37.7°C지만 2022년에 40.2°C를 관측했고, 2044년 전망은 41.2°C입니다. 기존 여유가 조금 줄어든 것이 아닙니다. 건물 수명의 절반이 지나기 전에 이미 소진됐습니다.
데이터센터 30곳에 같은 여유값을 붙이지 않는 이유
Google 장비군에 모델을 적용하면 하나의 사내 기준값이 아니라 분포가 나옵니다. 평균 부지는 냉각 용량을 11% 늘려야 합니다. 건구 조건에 가장 취약한 부지는 39%, 습구 조건에 가장 취약한 부지는 48%가 필요합니다. 현재도 부지의 12%는 설계 조건을 넘을 연간 확률이 2%보다 높습니다. 건축 표준에서 예외로 취급한 사건이 운영 시나리오가 된 셈입니다.
작업 이동성만으로 설비 부족을 없앨 수는 없습니다. 조사 대상 데이터센터의 30%는 폭염 때 줄이거나 옮길 수 있는 부하가 충분하지 않았습니다. 대부분의 부지가 옮길 수 있는 비율은 20% 미만이며, 연산을 10% 줄일 때마다 냉기 통로 요구 온도가 약 1°C 낮아집니다. 1~2°C의 여유는 동작 한계 부근에서 유용하지만, 전망값이 6°C나 10°C 움직인 부지를 지킬 수는 없습니다.
논문은 습구 온도에 따른 경계를 구체적으로 제시합니다. 30°C 아래에서는 제어값 조정과 3% 미만의 부하 감축으로 서비스를 유지할 수 있습니다. 32°C에서는 감축 요구량이 약 12%로 오릅니다. 35°C에서는 30%에 도달하며, 저자들은 이를 운영으로 감당하기 어려운 설비 증설 구간으로 봅니다. 냉각 장비는 보통 15 MW 정도의 단위로 추가되므로 실제 결정도 연속적인 백분율 조절이 아닙니다.
하나의 예측을 세 개의 시계에 연결하는 구조
Prometheus의 흥미로운 지점은 시설과 소프트웨어의 시간대를 잇는 데 있습니다. 20년 전망은 부지 선택과 냉각 설비 용량을 정합니다. 계속 갱신하는 2년 전망은 모듈형 냉각 장치, 펌프, 제어 장치의 증설 순서를 정합니다. 2주 예보는 폭염이 도착하기 전에 운영 절차를 시작합니다.
약 14일 전에는 위험 평가를 시작합니다. 8~10일 전에는 옮길 서비스와 감축 계획을 선택합니다. 4~7일 전에는 데이터 이동과 서비스 변경을 실행하고, 마지막 하루를 최종 조정에 남깁니다. 초대형 시설에서 2주는 긴 시간이 아닙니다. 10 MW 연산을 옮기려면 가상 머신 약 20만 개와 메모리 3.2 PB가 대상이 될 수 있습니다. 애플리케이션 의존성을 제외해도 50 Gb/s로 계속 전송하면 메모리만 옮기는 데 약 일주일이 걸립니다.
경제성 계산은 모든 부지를 과잉 설계하는 대신 선택적으로 증설할 근거를 줍니다. 초대형 시설 건설비는 W당 약 7~12달러이며 냉각이 15~25%를 차지합니다. 냉각 용량을 20% 늘리면 W당 약 0.20~0.60달러가 듭니다. 런던의 35시간 장애에 대해 논문이 계산한 서비스 영향의 하한은 W당 0.44달러입니다. 일반적인 10% 증설과 가용성이 보호하는 소프트웨어 가치를 함께 계산하면 증설 쪽이 약 네 배 유리할 수 있습니다. 모든 사업자에게 같은 값을 적용할 수는 없지만, 기후 위험과 시설 자본을 같은 단위로 비교하게 해 줍니다.
AI 용량 계획에서 빠진 입력값
AI 인프라 논의는 시설 수명 내내 같은 MW를 쓸 수 있는 것처럼 전력을 셉니다. Prometheus는 냉각 때문에 전력 용량이 지역 날씨, 습도, 이동 가능한 작업에 따라 달라진다는 점을 보여 줍니다. 방열 능력이 부족한 100 MW 캠퍼스는 설계 조건을 정한 폭염 시간에 100 MW를 보유한 것이 아닙니다.
실무에서는 분포를 보존해야 합니다. 장비군 평균으로 개별 부지를 정할 수 없고, 건구 여유가 습구 위험을 대신하지도 않습니다. 부지별 전망, 꼬리 오차를 보정한 모델, 제어값 조정과 작업 대응 및 물리적 증설의 경계가 필요합니다. 같은 예측이 장비를 주문할 시설팀에는 수년 전에, 상태를 옮길 스케줄러에는 수주 전에 도달해야 합니다.
한계도 있습니다. 기후 전망은 배출 시나리오에 따라 달라지며, 논문은 실제 장비군을 익명화해 부지별 상세 설계를 모두 공개하지 않습니다. 비용 모델도 장애 영향의 하한을 사용하므로 모든 서비스 계약을 반영하지 못합니다. 그래도 시스템 논점은 명확합니다. 기상 데이터에도 버전이 있습니다. 설계 입력값을 갱신하지 않는 데이터센터는 만료된 의존성 위에서 핵심 인프라를 운영하는 셈입니다.
예측값을 작업 승인 조건으로 바꾸는 방식
기후 전망은 작업 승인 결정이 달라져야 운영 정보가 됩니다. 시설팀은 부지별 안전한 IT 부하를 건구 온도, 습구 온도, 냉각 장비 상태에 따른 표로 표현할 수 있습니다. 스케줄러는 연간 명판 용량이 아니라 작업이 실행될 기간에 예상되는 최저 용량과 예약을 비교합니다. 장시간 학습을 시작하기 전에 날씨 위험을 용량 계획에 넣는 방식입니다.
이 표에는 신뢰 구간이 필요합니다. 동작 곡선이 급격히 꺾이는 구간에서 오차가 2°C인 32°C 예보를 확정된 32°C로 취급할 수 없습니다. 꼬리 오차를 보수적인 용량 범위로 변환하고 이동이 어려운 작업에는 하한만 배정할 수 있습니다. 중앙 예상값과 하한의 차이는 중단 가능한 작업에 제공합니다. 이렇게 하면 예측 불확실성이 가격 없이 남긴 시설 여유가 아니라 하나의 스케줄링 등급이 됩니다.
상태 이동 비용도 별도로 계산해야 합니다. 논문의 3.2 PB 사례는 이동 가능 여부가 예·아니요로 끝나는 작업 속성이 아님을 보여 줍니다. 다른 부지에서 재시작할 수 있어도 경보가 나온 뒤 메모리, 체크포인트, 캐시 상태를 모두 옮길 시간이 부족할 수 있습니다. 작업 유형마다 전송량, 필요한 최소 대역폭, 재시작 시간, 데이터 위치 제약, 마지막 안전 시작 시각을 기록해야 합니다. 이 의존성 그래프를 미리 준비해야 2주 예보가 실제 대응 시간을 만듭니다.
이동이 문제를 다른 부지로 옮길 수도 있습니다. 두 부지가 같은 기상권에 있거나, 받는 부지에 전력은 남아 있지만 냉각 여유가 없을 수 있습니다. 데이터 전송은 양쪽 부지의 전력을 더 쓰고 운영 트래픽과 경쟁합니다. 장비군 전체 제어기는 날씨의 상관관계, 받는 부지의 출력 제한, 전송 비용을 함께 계산해야 합니다. 물리 주소가 다른 것만으로는 충분하지 않고 열 위험이 독립적이어야 지역 분산의 가치가 생깁니다.
증설은 피한 연산 중단 시간으로 평가하는 편이 정확합니다. 15 MW 냉각 모듈이 모든 시간에 IT 전력 15 MW를 새로 만드는 것은 아닙니다. 기존 출력 제한 곡선이 병목이던 구간에서만 가용 용량을 높입니다. 예상 날씨 분포에서 기존 곡선과 증설 후 곡선 사이의 면적을 구하고, 보호한 작업의 가치와 곱하면 투자 효과를 계산할 수 있습니다. 이 방법은 발생 빈도를 무시한 극단 기온 하나로 설비를 과도하게 키우는 일을 막으면서도 서비스 영향이 큰 꼬리 사건에는 충분한 비용을 부여합니다.
물과 전력 제약에 따라 대응 순서도 달라집니다. 증발식 냉각은 건조한 폭염에서 IT 전력을 지키지만 물 사용량을 늘릴 수 있습니다. 기계식 냉각은 습한 날에 유용하지만 전력망이 긴장하는 시간에 전기 수요를 높일 수 있습니다. 작업 감축은 새 냉각 장비나 물을 쓰지 않지만 연산을 포기하고 서비스 약속을 어길 수 있습니다. Prometheus가 온도 확률을 제공하면 운영자는 지역의 자원 가격과 정책 한도를 붙여 수단을 골라야 합니다.
검증은 과거 극한 기상과 합성한 미래 조건을 전체 경로에 재생해야 합니다. 예보에서 시작해 부지 용량 곡선을 만들고, 이동이나 감축을 실행한 뒤 냉각 설비와 서비스 목표가 한도 안에 남는지 확인합니다. 구성요소 시험만으로는 부족합니다. 예측은 정확해도 이동이 늦게 끝날 수 있고, 냉각 모듈은 정격을 만족해도 제어 순서 때문에 필요한 출력에 도달하지 못할 수 있습니다.
마지막으로 세 시간대의 책임을 연결해야 합니다. 시설 계획 조직은 20년의 물리 범위를, 용량 엔지니어링 조직은 계속 갱신하는 증설 계획을, 서비스 운영 조직은 단기 대응을 맡습니다. 기후 시나리오, 예측 버전, 장비 상태, 이동 가능한 부하, 남은 위험을 하나의 공통 기록으로 이어야 합니다. 그렇지 않으면 각 조직이 자체 목표를 달성해도 부지 전체는 보호되지 않습니다. Prometheus는 예측 기법인 동시에 인터페이스 제안입니다. 기후 정보가 시설을 거쳐 클러스터 스케줄러까지 전달될 때 필요한 정보를 정의합니다.
냉각은 전력 용량을 출력 제한 곡선으로 바꾸는 방식
캠퍼스 사양은 보통 하나의 IT 전력값으로 표시됩니다. Prometheus가 제안하는 더 정직한 표현은 외기 건구·습구 온도, 장비 상태, 옮길 수 있는 작업부하에 따른 가용 IT 전력 곡선입니다. 냉각 여유가 있을 때는 평평하지만 제어 조정, 작업 이동, 부하 감축을 차례로 쓰면서 꺾입니다. 부지마다 정해지는 한계를 넘으면 전기 1MW가 더 있어도 열을 버릴 수 없어 연산 용량으로 바뀌지 않습니다.
이 곡선은 용량 판매와 스케줄러 정책에 모두 들어가야 합니다. 명판 전력을 기준으로 연간 GPU 가용성을 판매하면 기후 위험이 가장 큰 몇 시간에 과도하게 약속할 수 있습니다. 예약 조건에는 어떤 작업부하를 옮길 수 있는지, 이동할 상태가 얼마나 되는지, 예측이 며칠 전에 동작해야 하는지를 포함해야 합니다. 논문의 2주 예측 구간은 날씨 알림이 아니라 가용 용량의 일부입니다. 준비 시간이 부족하면 기술적으로 이동 가능한 연산도 운영상 고정 자원이 됩니다.
투자 선택도 분명해집니다. 물리 냉각 설비 증설은 수십 년 동안 더 높고 평평한 출력 제한 곡선을 삽니다. 소프트웨어 대응은 경계 구간의 유연성을 사지만 가속기 시간을 잃고 고객 데이터를 옮길 수 있습니다. 여러 부지를 운영하는 선택은 서로 다른 날씨 분포를 사는 것과 같지만 네트워크와 데이터 조건이 이동을 허용해야 합니다. 이를 냉각 와트가 아니라 보호한 유효 연산시간으로 비교해야 합니다. Prometheus의 더 큰 시스템 관점은 기후 회복탄력성이 시설 설계, 예측 오차, 데이터 이동, 작업부하 SLO가 함께 맺는 계약이라는 점입니다. 하나라도 모델 밖에 두면 부지가 가장 긴장한 순간에 보고된 MW가 실제보다 커집니다.
기후 불확실성은 운영 범위로 바뀌어야 할 이유
미래 기후 모델은 하나의 정확한 설계 기온이 아니라 배출 경로, 지역 모델, 관측, 상세화에 따른 분포를 냅니다. 건구와 습구 온도, 습도, 극한 지속 시간, 야간 회복, 필요한 경우 연기와 먼지, 전력망 상태를 함께 포함해야 합니다. 한 시간의 고온을 견뎌도 밤에 충분히 식지 않는 여러 날의 사건에서는 열이 누적될 수 있습니다.
설계 단계마다 사용한 가정을 남기면 새 관측과 전망이 들어왔을 때 어느 장비, 제어 설정, 증설 단계의 여유가 부족해졌는지 찾을 수 있습니다. 과거 날씨 파일이 낡았다는 선언보다 위험 분포와 남은 여유를 연결하는 편이 실제 조치에 유용합니다.
냉각도 전력처럼 시간 계층이 필요한 조건
장치와 랙 제어는 빠르게 반응하고 펌프, 팬, 냉각탑은 초와 분 단위로 움직이며, 작업 이동과 용량 계획은 더 느립니다. 스케줄러가 열 여유를 알면 냉각 한계에 가까운 랙에는 메모리 중심 작업을 넣고 고밀도 학습은 피할 수 있습니다. 폭염 예보 전에 유연 작업을 미루거나 새 수용을 옮길 수도 있습니다.
냉각수 온도를 올리면 외기 냉방 시간은 늘지만 부품 여유가 줄고, 팬 전력은 GPU에 공급할 전력을 사용하며, 출력 제한은 작업을 가장 더운 시간까지 늘릴 수 있습니다. 냉각 에너지만 따로 최적화하지 않고 성능과 완료 기한을 같은 모델에 넣어야 합니다.
이중화 수량보다 공급 가능한 냉각을 봐야 할 이유
N+1 장비도 높은 외기와 습구 온도에서는 출력이 줄 수 있습니다. 유지보수, 오염, 전력 제약을 함께 가정해 실제 공급 가능한 냉각을 계산해야 합니다. 커미셔닝에서는 장비를 끄고 설정값을 바꾸며 센서, 밸브, 펌프, 소프트웨어가 같은 상태를 보는지 확인합니다. 랙 입구나 냉각수 온도, 장치 출력 제한, 회복 시간, 냉각 전력을 추적해야 합니다.
연간 평균 물 사용량은 최대 냉각 수요와 지역 물 부족이 겹치는 상황을 숨깁니다. 물 사용을 줄여야 할 때의 운전 모드와 연산 제한도 계획에 포함해야 합니다.
증설 계획에 필요한 냉각 선택권
모든 단계를 가장 높은 전망치에 맞추면 설비가 과잉 투자되고, 과거 날씨에만 맞추면 다음 랙을 설치하지 못할 수 있습니다. 모듈형 장비, 향후 연결 공간, 높은 온도를 지원하는 배관, 임시 출력 제한을 통해 선택권을 남길 수 있습니다. 비용은 초기 설비뿐 아니라 냉각 에너지, 물, 제한 중 잃은 연산, 개조 가능성을 포함해야 합니다.
Prometheus의 핵심은 데이터센터 수명과 날씨 근거를 연결한 데 있습니다. 최종 산출물은 높은 기온 숫자가 아니라 미래 조건과 장비 장애, 자원 제약에서 스케줄러와 증설 계획이 공급 가능한 연산량을 알려 주는 사이트별 곡선입니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약입니다. 아래 논문의 주장과 결과를 우리 표현으로 다시 썼습니다. 논문의 문장, 표, 도판은 옮기지 않았으며, 본문 도판은 보고된 수치를 바탕으로 이 글을 위해 새로 만들었습니다. 정식 논문은 ISCA 2026 회의록에 IEEE가 출판했습니다. 저작권 (c) 2026 IEEE. 원문은 DOI 서지 페이지에서 확인할 수 있습니다.