AI 리서치2026년 9월 7일5분 읽기

2편. RFP에 안쓰여져 있는 GPU 비용의 비밀

Jay

GPU 서버를 사기 전에 먼저 확인해야 할 것이 있습니다. 바로 전기와 냉방입니다. AI 인프라 구축에서 자주 놓치는 랙 전력, UPS, 냉방, 바닥 하중, 시설 공사 일정과 전력비까지 실제 프로젝트 관점에서 정리합니다.

2편. 전기와 열 — RFP에 안 적혀 있는 진짜 제약

1편에서 GPU 사이징 이야기를 했습니다.

사용자 수를 동시 세션으로 바꾸고, 필요한 처리량을 계산한 뒤, 그 결과를 GPU 수량으로 역산하는 이야기였습니다.

그런데 사실 그 계산보다 먼저 확인해야 할 것이 있습니다.

그 장비를 실제로 켤 수 있느냐입니다.

농담이 아닙니다.

AI 인프라 프로젝트에서는 장비 선정과 발주까지 끝났는데, 정작 설치하려는 전산실의 전력이나 냉방 조건이 맞지 않아 일정이 밀리는 일이 생깁니다.

서버는 도착했는데 분전반 공사가 안 끝났고, 전력은 확보했는데 냉방 여유가 없고, 냉방까지 해결했는데 랙이나 반입 동선이 맞지 않는 식입니다.

GPU 서버는 IT 장비지만, 전력과 열의 문제는 결국 시설의 문제이기 때문입니다.

GPU가 바꾼 것은 연산량만이 아닙니다

몇 년 전까지만 해도 데이터센터에서는 랙당 5~10kW 정도의 전력 밀도가 일반적인 수준으로 언급됐습니다.

하지만 GPU가 집약된 AI 환경에서는 이야기가 완전히 달라집니다.

Equinix는 AI 워크로드 확산으로 랙 전력 밀도가 기존 5~10kW 수준에서 100kW/rack 수준까지 올라가는 사례가 나타나고 있다고 설명합니다.

하나의 GPU 자체가 더 많은 전력을 쓰고, 여러 GPU를 하나의 랙에 고밀도로 집적하기 때문입니다.

실제 장비를 보면 더 직관적입니다.

NVIDIA DGX H100/H200은 8개의 GPU가 탑재된 하나의 시스템인데 최대 소비전력이 10.2kW, 최대 중량이 약 130kg입니다.

DGX B200은 최대 소비전력이 14.3kW, 최대 중량이 약 142kg까지 올라갑니다.

서버 한 대가 이미 기존 전산실 랙 하나의 전력 예산을 넘어설 수 있는 수준입니다.

서버 두 대만 설치해도 IT 부하가 20~30kW 수준으로 올라갈 수 있습니다.

여기에 네트워크 스위치, 스토리지, 관리 서버까지 같은 랙이나 같은 전산실에 들어가면 실제 필요한 전력은 더 커집니다.

문제는 많은 기존 기업 전산실이 이런 장비를 처음부터 상정하고 만들어진 공간이 아니라는 것입니다.

결국 AI 인프라의 병목은 GPU 확보만이 아닙니다.

전기를 어디에서 가져오고, 발생한 열을 어떻게 버릴 것인가가 같은 수준의 설계 문제입니다.

그런데 이상하게도 AI 사업 RFP에는 이 항목이 잘 없습니다.

모델 성능, 정확도, 응답속도, 동시사용자 수, 보안 요구사항은 빼곡하게 적혀 있는데 다음과 같은 질문은 빠져 있습니다.

설치 예정 전산실의 랙당 가용 전력은 몇 kW인가?

현재 UPS 부하율은 몇 퍼센트인가?

신규 GPU 서버가 들어왔을 때 냉방 여유는 얼마나 남는가?

전력 증설이 필요하다면 공사 완료 시점은 언제인가?

이 질문에 바로 답할 수 있는 경우는 생각보다 많지 않습니다.

AI 사업 담당 부서와 전산실·시설 담당 부서가 다른 경우가 많기 때문입니다.

제안서를 쓰기 전에 전산실부터 봐야 하는 이유

온프레미스 GPU 구축이라면 가능하면 제안 단계에서 전산실 조건을 확인해야 합니다.

예를 하나 들어보겠습니다.

가정

도입 장비: 8-GPU 서버 2대
서버당 최대 소비전력: 약 10kW
총 IT 부하: 약 20kW
기존 전산실에 신규 랙 또는 기존 랙 활용

NVIDIA DGX H100의 공식 최대 소비전력이 10.2kW이므로 크게 무리한 가정은 아닙니다.

전산실 실사표 예시

점검 항목현장 상태(가정)필요 조건판정랙당 가용 전력6kW서버 1대 약 10kW❌ 설치 불가분전반 여유 회선2회선이중화 구성 시 추가 회선 필요❌ 증설 필요UPS 백업기존 부하 기준 15분신규 20kW 반영 재산정⚠️ 재검토항온항습 냉방20RT / 현재 부하율 70%약 20kW 열부하 추가⚠️ 여유 확인바닥 하중500kg/㎡랙·서버·PDU 포함 검토⚠️ 구조 검토랙 깊이1,000mm장비 규격 및 케이블 공간 확인⚠️ 확인 필요반입 동선화물 E/V 폭 900mm포장 상태·랙 단위 반입 여부 확인⚠️ 현장 확인

여기서 가장 먼저 걸리는 것은 첫 번째 줄입니다.

랙 가용 전력 6kW인 곳에 최대 10kW급 서버는 정상적으로 설치할 수 없습니다.

서버 한 대를 두 개의 랙에 반씩 나눠 넣을 수도 없습니다.

결국 전력 증설이 선행 조건이 됩니다.

그리고 여기서부터 문제가 IT 프로젝트가 아니라 시설 공사 프로젝트로 넘어갑니다.

서버 견적을 받는 일과 분전반을 증설하는 일은 발주 주체도 다르고, 예산 항목도 다르고, 검토하는 담당자도 다를 수 있습니다.

그래서 온프레미스 AI 사업은 서버 BOM만 봐서는 안 됩니다.

시설 BOM과 시설 일정까지 함께 봐야 합니다.

전산실 실사에서는 누구를 만나야 하는가

전산실을 본다는 것도 단순히 서버실에 들어가 랙을 한 번 보는 것을 의미하지 않습니다.

실제로 필요한 정보는 여러 담당자에게 흩어져 있습니다.

AI 사업 담당자에게 랙당 가용 전력을 물어보면 모를 수 있습니다.

IT 인프라 담당자는 서버 사양은 알지만 건물 수전 용량이나 분전반 여유까지는 모를 수 있습니다.

시설 담당자는 분전반과 냉방은 알지만 GPU 서버의 부하 특성이나 PSU 이중화 구조는 모를 수 있습니다.

그래서 온프레미스 AI 프로젝트 초기에 가능하다면 다음 담당자들을 한 번에 모으는 것이 좋습니다.

담당 영역확인할 내용AI 사업 담당도입 목적, 예상 사용량, 일정, 예산IT 인프라 담당랙 위치, 네트워크, 스토리지, 운영 방식전산실 담당랙 전력, PDU, UPS, 현재 부하율시설 담당수전용량, 분전반, 냉방, 전력 증설 가능 여부보안 담당장비 반입, 외부망 연결, 유지보수 접근구매 담당장비 납기, 계약 조건, 시설공사 분리 발주 여부

이 미팅에서 저는 보통 장비 이야기를 먼저 하지 않습니다.

오히려 아래와 같은 질문부터 합니다.

현재 해당 전산실의 최대 사용 전력은 얼마인가?

랙별로 실제 사용할 수 있는 전력이 몇 kW인가?

신규 20kW 부하를 추가하면 UPS와 냉방에 얼마나 여유가 남는가?

전력 증설이 필요하면 승인부터 준공까지 얼마나 걸리는가?

시설 공사 예산은 이번 AI 사업 예산에 포함되어 있는가?

장비 입고 예정일 전에 시설 공사가 끝나는가?

이 질문 몇 개만으로도 프로젝트 일정의 현실성이 상당 부분 드러납니다.

특히 중요한 것은 증설 가능 여부보다 증설 완료 시점입니다.

시설팀이 "증설 가능합니다"라고 답했다고 해서 프로젝트 리스크가 사라진 것은 아닙니다.

3개월이 걸리는지 9개월이 걸리는지가 더 중요합니다.

냉방은 전기의 다른 이름입니다

GPU가 소비한 전력은 대부분 결국 열로 바뀝니다.

따라서 IT 장비에 20kW의 전력을 공급한다는 것은 전산실 입장에서는 거의 같은 규모의 열을 지속적으로 처리해야 한다는 뜻입니다.

20kW의 열부하는 약 5.7RT 수준입니다.

계산은 어렵지 않습니다.

1 RT ≈ 3.517 kW

20 kW ÷ 3.517
≈ 5.7 RT

다만 여기서 주의할 점이 있습니다.

"서버가 20kW니까 냉방도 5.7RT만 추가하면 된다"라고 단순하게 결론 내리면 안 됩니다.

실제 전산실에서는 서버뿐 아니라 UPS, PDU, 팬, 조명, 네트워크 장비, 냉각 장비 등 시설 전체가 전력을 사용합니다.

또 냉기의 공급 위치와 열기의 배출 경로가 좋지 않으면 총 냉방 용량이 충분해도 특정 랙에서 Hot Spot이 생길 수 있습니다.

이때 자주 사용하는 지표가 PUE(Power Usage Effectiveness) 입니다.

PUE = 데이터센터 전체 소비전력 ÷ IT 장비 소비전력

Uptime Institute의 2025년 조사에서 전 세계 조사 대상 데이터센터의 평균 PUE는 약 1.54였습니다.

예를 들어 PUE 1.5를 단순 가정하면 다음과 같습니다.

IT 장비 소비전력       20 kW
× PUE                  1.5
──────────────────────────
시설 전체 소비전력      30 kW

GPU 서버 20kW를 운영하기 위해 시설 전체에서는 약 30kW 수준의 전력을 소비할 수 있다는 의미입니다.

PUE를 이용한 계산은 TCO를 빠르게 추정하는 데는 유용하지만, 실제 설계 단계에서는 냉방 장비의 정격과 현재 부하율, 공기 흐름, 랙 배치까지 별도로 확인해야 합니다.

공랭으로 끝나는 시대가 계속될까

전력 밀도가 높아질수록 냉방 방식도 달라집니다.

기존 전산실은 대부분 공랭(Air Cooling)을 중심으로 설계되어 있습니다.

차가운 공기를 장비 전면으로 공급하고, 서버에서 발생한 뜨거운 공기를 후면으로 배출하는 방식입니다.

전통적인 서버 환경에서는 이 구조가 상당히 안정적으로 동작했습니다.

하지만 GPU가 집약되면서 랙당 전력 밀도가 올라가면 공기만으로 열을 빼는 것이 점점 어려워집니다.

예를 들어 하나의 랙에 10kW급 서버가 여러 대 들어가 랙 전체 부하가 30~40kW를 넘어가기 시작하면 단순히 항온항습기의 총 용량만 늘리는 것으로 해결되지 않을 수 있습니다.

문제는 냉방 장비의 총 용량뿐 아니라 열을 얼마나 효과적으로 서버에서 빼낼 수 있느냐이기 때문입니다.

이때 등장하는 방식이 Liquid Cooling입니다.

대표적으로 서버 내부의 CPU나 GPU에 냉각판을 붙이고 냉각수를 순환시키는 Direct-to-Chip 방식이 있습니다.

랙 후면에서 배출되는 열을 직접 처리하는 Rear Door Heat Exchanger 방식도 있습니다.

최근 고밀도 AI 인프라에서 액체냉각이 자주 언급되는 이유가 여기에 있습니다.

다만 여기서 오해하면 안 됩니다.

"GPU 서버니까 무조건 액체냉각이 필요하다"는 뜻은 아닙니다.

실제로 필요한 냉방 방식은 장비의 소비전력, 랙당 집적도, 기존 전산실의 공조 구조, 제조사 권고사항, 냉수 공급 가능 여부 등을 함께 봐야 합니다.

예를 들어 DGX H100 자체는 제조사 사양상 공랭 시스템입니다.

따라서 10kW급 서버 한 대가 있다고 무조건 액체냉각을 도입해야 하는 것은 아닙니다.

중요한 것은 서버 한 대의 방식보다 랙과 전산실 전체의 열밀도입니다.

그래서 액체냉각을 검토할 때는 다음 질문을 먼저 보는 것이 좋습니다.

랙당 예상 IT 부하는 몇 kW인가
서버 제조사가 요구하는 냉각 방식은 무엇인가
기존 전산실이 해당 열밀도를 감당할 수 있는가
Hot Aisle / Cold Aisle 구성이 적절한가
Rear Door Heat Exchanger 또는 CDU 설치 공간이 있는가
건물에 냉수 배관을 추가할 수 있는가
누수 감지와 유지보수 체계가 마련되어 있는가

특히 기존 건물을 활용하는 기업 전산실에서는 액체냉각 도입 자체가 또 하나의 시설 프로젝트가 됩니다.

냉수 배관, CDU(Coolant Distribution Unit), 누수 감지, 배수, 유지보수 체계까지 필요하기 때문입니다.

결국 고성능 GPU를 살 수 있는가와 그 GPU를 원하는 밀도로 배치할 수 있는가는 전혀 다른 문제입니다.

바닥 하중과 랙 크기도 생각보다 중요합니다

전력과 냉방만 확인하고 끝내면 또 다른 문제가 생길 수 있습니다.

무게입니다.

DGX H100/H200 한 대의 최대 중량은 약 130kg이고 DGX B200은 약 142kg입니다.

그런데 실제 전산실에서는 서버 한 대만 바닥에 놓는 것이 아닙니다.

랙 자체 무게가 있고, GPU 서버 여러 대와 네트워크 장비, 스토리지, PDU, 케이블이 함께 들어갑니다.

경우에 따라 랙 단위 무게는 생각보다 빠르게 증가합니다.

그래서 바닥 하중은 단순히 "서버가 130kg이니까 괜찮다"라고 볼 항목이 아닙니다.

랙 전체 중량과 랙의 실제 설치 면적, Raised Floor 구조, 하중 분산 방식까지 함께 봐야 합니다.

특히 일반 사무용 건물을 전산실로 개조한 공간이라면 더 주의가 필요합니다.

랙 깊이 역시 마찬가지입니다.

NVIDIA DGX H100/H200의 깊이는 공식 사양상 약 897mm입니다.

숫자만 보면 1,000mm 랙에 들어갈 것처럼 보일 수 있습니다.

하지만 서버 본체 뒤에는 전원 케이블, 네트워크 케이블, PDU, 케이블 굴곡 반경과 유지보수 공간이 필요합니다.

전면과 후면 도어를 닫은 상태에서 통풍도 확보되어야 합니다.

즉,

장비 크기 < 랙 크기

이것만 확인해서는 부족합니다.

그래서 저는 GPU 서버 사양서를 볼 때 GPU 메모리뿐 아니라 다음 세 가지를 먼저 봅니다.

Power / Weight / Dimension.

이 세 숫자가 실제 전산실에 들어갈 수 있는지를 먼저 봅니다.

반입 동선도 인프라입니다

사양서에는 잘 나오지 않지만 현장에서 의외로 자주 걸리는 항목이 하나 더 있습니다.

장비를 어떻게 전산실까지 가져갈 것인가입니다.

GPU 서버는 무겁습니다.

랙 단위로 납품되는 장비라면 더 큽니다.

그래서 장비 발주 전에 최소한 다음 정도는 확인해야 합니다.

건물 화물 엘리베이터 적재중량
엘리베이터 문 폭과 내부 깊이
전산실 출입문 폭
복도 폭과 회전 반경
계단 또는 문턱 존재 여부
포장 해체 장소
랙 단위 반입인지 서버 단위 반입인지
장비 반입 가능 시간
보안구역 출입 승인 절차

이 부분이 중요하지 않아 보이지만, 장비가 건물 1층에 도착한 순간부터는 물류 문제가 됩니다.

특히 보안이 강한 금융사, 공공기관, 제조 현장에서는 반입 승인과 작업시간 제약까지 일정에 영향을 줍니다.

GPU 납기만 확인하고 "8월 입고"라고 쓰는 것보다 실제로는 다음까지 봐야 합니다.

장비 입고
↓
반입 승인
↓
전산실 반입
↓
랙 마운트
↓
전원 연결
↓
Burn-in
↓
네트워크 연결
↓
GPU 및 Driver 검증
↓
서비스 통합 테스트

여기까지 끝나야 비로소 애플리케이션 개발팀이 안정적인 인프라를 사용할 수 있습니다.

"장비는 왔는데 못 켠다"는 어떻게 만들어지는가

이 문제가 반복되는 이유는 단순합니다.

GPU 장비와 시설 공사의 예산·발주 라인이 다르기 때문입니다.

가상의 프로젝트 일정을 보겠습니다.

AI 구축사업
3월 계약 ───────────────────────── 9월 준공

GPU 서버
          4월 발주 ─────────────── 8월 입고

전력 증설
                5월 예산 요청
                        ↓
                      7월 발주
                              ↓
                            11월 준공

GPU는 8월에 도착합니다.

AI 사업은 9월 준공입니다.

그런데 전기는 11월에 들어옵니다.

이 상황에서는 장비도 있고 개발도 끝났는데 통합테스트를 할 수 없습니다.

GPU 서버는 AI 사업 예산으로 구매했지만, 전력·분전반·UPS·항온항습기 증설은 시설관리 부서의 별도 예산일 수 있습니다.

두 부서의 예산 편성 시점도 다르고 발주 프로세스도 다릅니다.

그래서 온프레미스 AI 사업에서는 애플리케이션 일정과 인프라 일정을 하나의 간트차트에 올려봐야 합니다.

최소한 다음 네 개의 트랙은 같이 봐야 합니다.

① AI 애플리케이션 개발
② GPU 서버 구매·납품
③ 네트워크·보안 구성
④ 전력·냉방·시설 공사

이 네 줄 중 가장 늦게 끝나는 것이 사실상 서비스 오픈일입니다.

그렇지 않으면 "개발 일정은 정상"인데 전체 프로젝트는 지연되는 이상한 상황이 생깁니다.

제가 온프레미스 AI 프로젝트에서 시설 일정을 중요하게 보는 이유입니다.

전력비도 GPU의 가격입니다

또 하나 빠지기 쉬운 것이 운영비입니다.

GPU 서버를 구매할 때는 CAPEX를 열심히 비교합니다.

A제품이 몇 억이고 B제품이 몇 억인지, GPU 한 장당 단가가 얼마인지 비교합니다.

그런데 실제 TCO에서는 전력비도 무시할 수 없습니다.

다시 8-GPU 서버 두 대를 예로 들어보겠습니다.

단순 계산 예시

항목가정값서버 최대 소비전력10kW × 2대 = 20kWPUE1.5시설 전체 전력30kW연간 가동시간8,760시간연간 전력사용량262,800kWh계산용 전력단가180원/kWh연간 전력비약 4,730만원3년 단순 누계약 1.42억원

계산은 단순합니다.

20 kW × 1.5 × 8,760시간
= 262,800 kWh

262,800 kWh × 180원
= 47,304,000원

물론 실제 전기요금은 이렇게 단순하지 않습니다.

계약전력, 계약종별, 계절, 시간대, 기본요금, 최대수요전력 등에 따라 달라집니다.

한국전력공사가 공개한 최근 데이터에서 산업용 평균 전력판매 단가는 181.90원/kWh 수준입니다.

따라서 위의 180원/kWh는 견적값이 아니라 TCO의 크기를 가늠하기 위한 단순 가정으로 보면 됩니다.

실제 사업에서는 반드시 고객사의 계약종별과 요금 구조를 기준으로 다시 계산해야 합니다.

또 하나 중요한 점은 서버가 항상 최대 소비전력으로 동작하지는 않는다는 것입니다.

10kW 정격 장비라고 해서 1년 8,760시간 동안 항상 10kW를 사용하는 것은 아닙니다.

따라서 정교한 TCO를 계산하려면 예상 평균 이용률과 실제 측정 전력을 반영해야 합니다.

예를 들어 평균 소비전력이 최대치의 60%라면 실제 사용 전력량은 위 단순 계산보다 줄어듭니다.

반대로 냉방과 시설의 용량 설계는 평균보다 피크 부하를 중심으로 봐야 할 수 있습니다.

이 차이가 중요합니다.

비용 계산은 평균 부하를 보고, 시설 용량은 피크 부하를 본다.

두 계산에 무조건 같은 숫자를 사용하면 한쪽은 과대계상되거나 다른 한쪽은 위험하게 작아질 수 있습니다.

3년 또는 5년 TCO를 본다면 최소한 다음 항목은 함께 보는 것이 좋습니다.

GPU 서버 구매비
+ 네트워크 / 스토리지
+ 유지보수
+ 실제 IT 전력비
+ 냉방·UPS 등 Facility Overhead
+ IDC 사용 시 상면 비용
+ 시설 증설비
+ 향후 GPU 추가 증설 비용

여기서 PUE를 적용해 전체 전력비를 계산했다면 냉방 전력비는 이미 포함되어 있으므로 별도로 다시 더하면 안 됩니다.

장비 가격만 비교해서는 온프레미스와 GPUaaS의 경제성을 제대로 비교하기 어렵습니다.

그래서 제안 단계에서 무엇을 확인해야 하는가

제가 온프레미스 AI 인프라 제안에서 중요하게 보는 것은 세 가지입니다.

첫째, 전제조건을 문서에 남깁니다

예를 들면 이런 식입니다.

[제안서 문구 예시]
본 제안은 설치 대상 전산실의 랙당 가용 전력, 냉방 용량, 바닥 하중 및 반입 동선 등 GPU 서버 설치에 필요한 시설 조건이 충족되는 것을 전제로 합니다. 해당 조건이 충족되지 않을 경우 전력·공조·랙 등의 시설 개선이 선행되어야 하며, 별도 명시되지 않는 한 관련 공사 및 이에 따른 일정은 본 사업 범위에서 제외됩니다.

숫자를 확정할 수 있다면 더 좋습니다.

[조건이 확인된 경우의 예시]
본 제안은 랙당 가용 전력 12kW 이상, 추가 냉방 여유 6RT 이상, 제조사 권고 랙 규격 및 반입 동선 확보를 전제로 합니다.

이런 한 문단이 나중에 프로젝트를 지키는 경우가 많습니다.

제안서에서 기술 사양만큼 중요한 것이 전제조건과 책임경계입니다.

둘째, 시설 공사를 누가 책임지는지 정합니다

전력 증설이 필요하다면 선택지는 두 가지입니다.

수행 범위에 넣거나, 발주처 선행 조건으로 빼거나.

시설 공사를 사업 범위에 넣으면 견적이 올라갑니다.

경쟁 제안에서는 불리해 보일 수도 있습니다.

반대로 제외하면 발주처가 해당 일정과 예산을 책임져야 합니다.

둘 중 어느 쪽이든 괜찮습니다.

가장 위험한 것은 아무 말도 하지 않는 것입니다.

제안서에서 정의하지 않은 경계 업무는 프로젝트가 어려워졌을 때 수행사 업무로 돌아오는 경우가 많습니다.

특히 "필요 시 협의" 같은 문구는 편해 보이지만 책임을 모호하게 만들 수 있습니다.

가능하면 누가, 무엇을, 언제까지 준비해야 하는지를 명시하는 편이 낫습니다.

셋째, Plan B를 같이 설계합니다

현장 실사를 해봤는데 전력 증설에 6개월이 걸린다고 하면 어떻게 해야 할까요.

AI 사업 전체를 6개월 늦출 필요는 없습니다.

대안은 있습니다.

GPUaaS로 개발·검증을 먼저 시작
IDC/코로케이션에 GPU 설치
개발 환경은 클라우드, 운영 환경은 온프레미스로 분리
소규모 GPU로 먼저 운영 후 실제 사용량을 보고 증설
민감 데이터와 비민감 워크로드를 분리한 하이브리드 구성

특히 필요한 GPU 규모가 아직 불확실한 사업이라면,

처음부터 최대 규모 장비를 구매하는 것보다 실제 워크로드를 먼저 측정한 뒤 단계적으로 온프레미스로 전환하는 방식이 합리적일 때가 많습니다.

1편에서 이야기했던 GPU 사이징 문제까지 같이 해결할 수 있기 때문입니다.

클라우드가 항상 싸다는 뜻도 아니고 온프레미스가 항상 유리하다는 뜻도 아닙니다.

핵심은 시설 조건과 실제 사용량을 확인하기 전에 장비 수량부터 고정하지 않는 것입니다.

온프레미스가 막히면 무엇을 선택할까

전산실 조건이 안 맞는다고 해서 무조건 클라우드로 가야 하는 것은 아닙니다.

대안은 크게 세 가지입니다.

방식장점단점적합한 경우온프레미스데이터 통제, 장기 사용 시 비용 예측 용이초기 투자, 시설 제약, 증설 속도상시 사용량이 크고 보안 요구가 높은 경우IDC/코로케이션고밀도 전력·냉방 확보 용이상면비, 네트워크 연계 필요사내 전산실이 GPU를 수용하지 못하는 경우GPUaaS/Cloud빠른 도입, 탄력적 확장장기 상시 사용 시 비용 증가 가능PoC, 사용량 불확실, 빠른 착수가 필요한 경우

여기서 중요한 것은 기술적으로 무엇이 가장 좋은지가 아닙니다.

현재 프로젝트의 불확실성을 어떤 방식이 가장 잘 흡수하느냐입니다.

예를 들어 모델이 아직 확정되지 않았고 동시 사용량도 예측하기 어렵다면 처음부터 대규모 온프레미스 GPU를 구매하는 것은 위험할 수 있습니다.

반대로 하루 24시간 안정적으로 높은 사용률이 예상되고 데이터 반출이 어렵다면 클라우드를 장기간 사용하는 것이 비용이나 보안 측면에서 불리할 수 있습니다.

그래서 저는 초기 단계에서는 다음 순서로 보는 편입니다.

1. 워크로드가 확정됐는가
        ↓
2. 예상 GPU 사용률을 측정했는가
        ↓
3. 필요한 GPU와 서버 수량은 얼마인가
        ↓
4. 전산실이 해당 전력과 냉방을 수용할 수 있는가
        ↓
5. 시설 공사가 사업 일정 안에 끝나는가
        ↓
6. 그때 온프레미스 / IDC / GPUaaS를 비교

장비부터 정하고 인프라 방식을 결정하는 것이 아니라,

업무량과 시설 조건을 확인한 뒤 장비와 배치 방식을 결정하는 순서가 더 안전합니다.

RFP에 한 페이지를 추가한다면

제가 AI 인프라 RFP에 한 페이지를 추가할 수 있다면 다음 항목을 넣겠습니다.

구분확인 항목전력랙당 가용 kW, 입력전압, PDU, A/B 전원UPS정격 용량, 현재 부하율, 백업시간냉방총 냉방용량, 현재 부하율, 추가 가능 용량공간Rack Unit, Rack Depth, 케이블 공간구조바닥 허용 하중, Raised Floor 구조네트워크스위치 포트, 대역폭, 이중화반입화물 E/V, 출입문, 장비 반입 동선일정전력·공조 증설 필요 여부 및 준공일운영예상 평균 가동률, 최대 부하, PUE, 전기요금냉각공랭 가능 여부, 액체냉각 필요 여부대안IDC·GPUaaS·Cloud 사용 가능 여부

GPU 모델명보다 이 표가 먼저 채워져야 합니다.

이 정보가 없다면 제안사는 서버 수량은 계산할 수 있어도 그 서버가 실제로 들어갈 수 있는지는 계산할 수 없습니다.

GPU 사이징의 마지막 단위는 kW입니다

1편에서는 사용자 수와 동시 세션, 토큰 처리량을 이용해 GPU 수량을 역산했습니다.

그런데 그 계산은 사실 한 단계 더 내려가야 합니다.

사용자 수
↓
동시 세션
↓
필요 처리량
↓
GPU 수량
↓
서버 수량
↓
소비전력(kW)
↓
냉방용량
↓
시설 증설 여부
↓
전산실 수용 가능 여부

즉 GPU 수량은 끝이 아니라 중간 결과입니다.

최종적으로는 그 GPU가 몇 kW를 소비하고, 해당 전산실이 그 부하를 받을 수 있는지를 확인해야 합니다.

그래서 온프레미스 AI 인프라 사이징은 사실상 두 가지 작업이 함께 이루어져야 합니다.

Compute Sizing + Facility Sizing

컴퓨팅만 계산하고 시설을 보지 않으면 사이징이 절반밖에 끝나지 않은 셈입니다.

그리고 여기서 한 가지가 더 연결됩니다.

시설이 수용할 수 있는 전력이 제한되어 있다면 GPU 사이징 결과를 다시 역으로 조정해야 할 수도 있습니다.

예를 들어 계산상 GPU 서버 4대가 필요하지만 전산실에는 2대밖에 들어갈 수 없다면 선택지는 다시 나뉩니다.

모델을 경량화할 것인가
양자화를 적용할 것인가
동시 사용자 목표를 조정할 것인가
일부 워크로드를 Cloud로 보낼 것인가
IDC를 사용할 것인가
전산실을 증설할 것인가

즉 시설 조건은 단순한 구축 조건이 아니라 AI 아키텍처 자체를 바꾸는 입력값이 됩니다.

이 지점이 중요합니다.

전력과 냉방은 인프라팀만의 문제가 아닙니다.

필요한 연산량, 사용할 모델, 양자화 수준, 동시 사용자 수, 서비스 SLA까지 다시 영향을 받을 수 있습니다.

결국 AI 인프라 설계는 소프트웨어와 하드웨어, 시설을 따로 계산하는 것이 아니라 하나의 시스템으로 봐야 합니다.

결국 AI 인프라는 건물 위에서 돌아갑니다

AI 프로젝트를 하다 보면 자연스럽게 모델에 관심이 쏠립니다.

어떤 LLM을 쓸지,
GPU가 몇 장 필요한지,
동시 사용자를 몇 명까지 받을지,
초당 토큰을 얼마까지 처리할지 이야기합니다.

물론 중요합니다.

하지만 온프레미스 환경에서는 그 아래에 한 층이 더 있습니다.

전기와 열입니다.

모델은 소프트웨어 문제이고 GPU는 하드웨어 문제지만,

전력과 냉방은 건물의 문제입니다.

그리고 건물은 코드를 수정한다고 바뀌지 않습니다.

그래서 온프레미스 AI 인프라 프로젝트에서 제가 가장 먼저 확인하는 질문 중 하나는 이것입니다.

"GPU가 몇 장 필요한가?"가 아니라
"여기에 몇 kW까지 넣을 수 있는가?"

이 질문에 답하지 못하면 GPU 사이징은 아직 끝난 것이 아닙니다.

조금 더 압축해서 표현하면 이번 편의 결론은 이겁니다.

GPU 사이징의 마지막 단위는 GPU 장수가 아니라 kW입니다.

AI 인프라 구축에서 모델과 GPU만 보면 절반만 본 것입니다.

실제 프로젝트는 결국 전기, 열, 공간, 일정이라는 물리적인 제약 위에서 돌아갑니다.

그 제약을 초기에 확인한 프로젝트와 그렇지 않은 프로젝트의 차이는 구축 후반부에 크게 나타납니다.

장비가 왔는데 못 켜는 프로젝트와,

장비가 들어오는 날 바로 테스트를 시작하는 프로젝트의 차이입니다.

다음 편은 국내 엔터프라이즈 AI 프로젝트에서 거의 빠지지 않는 조건을 이야기해보겠습니다.

3편. 폐쇄망 — 인터넷이 끊기는 순간 달라지는 것들

참고자료

Equinix, AI’s Engine Room: Inside the High-Performance Data Centers Powering the Future, 2025
- 기존 5~10kW/rack 수준에서 고밀도 AI 환경의 100kW/rack 수준으로 변화하는 전력 밀도와 Liquid Cooling 필요성 참고
NVIDIA, DGX H100/H200 User Guide
- DGX H100/H200 최대 소비전력 10.2kW, 최대 중량 130.45kg, 장비 깊이 897.1mm 등 공식 사양 참고
NVIDIA, DGX B200 User Guide
- DGX B200 최대 소비전력 14.3kW, 최대 중량 142.4kg 등 공식 사양 참고
Uptime Institute, Global Data Center Survey 2025
- 2025년 조사 기준 글로벌 평균 PUE 1.54 참고
한국전력공사, ESG 데이터 — 계약종별 전력판매 단가
- 산업용 평균 전력판매 단가 181.90원/kWh 참고

주: 본문의 전산실 조건, 일정, 전력비 및 서버 2대 구성은 개념 설명을 위한 가정 예시입니다. 실제 구축 시에는 도입 장비의 제조사 공식 사양과 고객사의 전기·냉방·건축·요금 조건을 기준으로 별도 산정해야 합니다.

#AI인프라#GPU#온프레미스#데이터센터#전력#냉방#GPU사이징#RFP#TCO#AI아키텍처

Newsletter

이런 노트를 이메일로 받아보세요

새로운 리서치 노트가 발행되면 가장 먼저 알려드립니다.