기술 전략 보고서
“AI-Ready Infrastructure”
정의 · 시장 현황 · Bespin MSP 인프라 조직 준비 방안
작성일 2026년 7월 · 대상: Delivery Excellence Office / 인프라 엔지니어링
요약 (Executive Summary)
• “AI-Ready Infrastructure”는 글로벌 업계에서 확실히 통용되는 표현이다. Accenture·KPMG·McKinsey·Gartner·Cisco·Microsoft 등이 모두 표준 어휘로 사용한다. 다만 단일 정의가 아니라 층위가 다른 세 가지 논의를 묶는 우산형(umbrella) 용어다.
• 세 층위는 ① 물리 인프라(전력·냉각·GPU), ② 데이터(AI-ready data), ③ 조직 준비도(AI readiness framework)로 나뉜다. 이 구분을 명시하지 않으면 벤더 마케팅과 실제 전략 과제가 뒤섞인다.
• 국내 담론은 ①(데이터센터 건설·전력·냉각)에 심하게 쏠려 있고, ②·③ 층위는 상대적으로 비어 있다. 이 공백이 MSP의 차별화 지점이다.
• Bespin 인프라 엔지니어의 준비 핵심은 하드웨어 건설 경쟁이 아니라 GPUaaS 운영 역량이다: GPU 슬라이싱(MIG·time-slicing·MPS), GPU 관측성(DCGM), AI 전용 네트워킹(InfiniBand/RoCEv2·RDMA·GPUDirect·NCCL), 그리고 이를 묶는 스케줄링·FinOps.
1.1 용어는 실재하는가 — 그렇다
결론부터 말하면 이 표현은 글로벌 업계의 표준 어휘로 자리 잡았다. 주요 컨설팅·분석기관·벤더가 마케팅과 공식 프레임워크 양쪽에서 사용한다.
| 주체 | “AI-Ready”의 사용 맥락 |
|---|---|
| Accenture | 회복탄력적·적응형이면서 AI로 구동되는 “AI-ready 인프라”를 단순 업그레이드가 아닌 전략적 enabler로 규정 (HPC·엣지·현대 네트워크 통합) |
| Gartner | 2025 Hype Cycle의 데이터센터 “AI-ready infrastructure”와, 별도 개념인 “AI-ready data” 두 갈래로 사용 |
| Cisco | AI Readiness Index를 브랜드로 운영 — 전략·인프라·데이터·인재·거버넌스·문화 6개 축으로 조직 준비도 평가 (23개국 CEO 2,500명 조사) |
| Microsoft | AI Readiness Assessment 7개 축 (비즈니스 전략, 거버넌스·보안, 데이터 기반, AI 전략, 조직·문화, AI 인프라, 모델 관리) |
| KPMG | 진단 서비스 관점 — 현행 아키텍처 파악 → “AI-ready 인프라” 구현 요건 → 미래 로드맵 제시 |
| 핵심 관찰 이 용어는 buzzword이면서 동시에 분석기관의 공식 프레임워크 어휘라는 이중성을 갖는다. 여기저기 남발되는 유행어인 동시에, Cisco·Microsoft가 표준화한 진단 프레임워크의 정식 명칭이기도 하다. 이 이중성을 인지하고 써야 한다. |
|---|
1.2 같은 단어, 세 개의 층위
실무적으로 가장 중요한 포인트다. “AI-Ready”는 문맥에 따라 완전히 다른 대상을 가리킨다.
① 물리 인프라 층 — 전력·냉각·GPU
데이터센터 담당자들이 쓰는 의미다. 랙 전력 밀도, 액체냉각, GPU 클러스터가 핵심이다. 최근에는 “AI-ready”가 더 이상 단일 청사진이 아니라, 학습(training)용 ‘AI 팩토리’와 추론(inference)용 분산 인프라를 별개로 설계해야 한다는 방향으로 세분화되고 있다. 액체냉각 침투율은 2024년 11%에서 2025년 24%로 상승할 것으로 전망된다.
② 데이터 층 — AI-Ready Data
Gartner가 못 박은 개념으로, 통념과 반대되는 지점이 있다. 전통적 데이터 품질 기준으로 “고품질”인 데이터가 곧 AI-ready 데이터인 것은 아니며, AI-ready 여부는 데이터를 어떻게 쓸지에 달려 있어 사전에 일반적으로 준비해 둘 수 없다. 실무자들이 가장 뼈아파하는 층이다 — 기존 리포팅을 지원하니 데이터가 AI-ready라고 착각하지만, 머신러닝 워크로드의 요구는 훨씬 까다롭다.
③ 조직 준비도 층 — AI Readiness Framework
Cisco·Microsoft가 쓰는 넓은 의미로, 인프라는 6\~7개 축 중 하나에 불과하다. AI 준비도는 기술 구매 문제가 아니라 조직 학습 문제라는 프레이밍이 대표적이다.
| 정의 제안 (본 보고서의 작업 정의) “AI-Ready Infrastructure”란, AI 워크로드(학습·추론)를 안전하고 효율적이며 확장 가능하게 실행·운영하기 위해 필요한 컴퓨트(GPU)·네트워크·스토리지·데이터·운영체계 전반의 준비 상태를 말한다. 단, 논의 시점에는 반드시 ①물리 ②데이터 ③조직 중 어느 층을 가리키는지 명시해야 한다. Bespin의 MSP 관점에서 방어 가능한 차별화 지점은 ①의 하드웨어 건설이 아니라, ①을 운영 서비스화하고 ②·③으로 확장하는 영역이다. |
|---|
2.1 국외 — 프레임워크화 \+ 대규모 자본 투입
해외 시장은 두 방향으로 동시에 움직인다. 한편에서는 물리 인프라에 천문학적 자본이 투입되고, 다른 한편에서는 준비도가 진단 프레임워크로 표준화되고 있다.
• 자본 투입: 하이퍼스케일러·콜로케이션 사업자가 2,600개 이상 신규 데이터센터를 발표했고, 글로벌 규모는 2030년대 초 약 11,000개 시설에 근접할 전망이다. 전력·인허가 제약이 “확약된 전력을 가진 부지”의 가치를 끌어올리고 있다.
• 병목의 이동: 대부분의 AI 이니셔티브는 알고리즘이 아니라 레거시 인프라에서 좌초한다는 진단이 반복된다. IDC는 2028년까지 엔터프라이즈 AI 워크로드의 75%가 온프레미스를 포함한 목적 특화 하이브리드 인프라에서 구동될 것으로 전망한다 (private AI).
• 준비도의 계량화: Cisco Index에 따르면 네트워크가 AI에 완전히 준비된 조직은 전체의 15%에 불과한 반면 선도기업(Pacesetter)은 71%다. 데이터 중앙화, 종단 암호화, 변경관리 등 전 축에서 격차가 크다.
• MSP의 상품화: 해외 MSP 시장에서 “AI-ready”는 이미 서비스 상품으로 진화 중이다. 평가·최적화·모니터링·지속적 준비도 관리를 서비스화하는 것이 기회이며, 관리형 클라우드·AI 서비스 이용 시 미관리 대비 AI 인프라 비용을 20\~35% 절감한다는 벤치마크가 인용된다.
2.2 국내 — 물리 인프라(①)에 과포화
국내 논의는 압도적으로 데이터센터 건설·전력·냉각에 집중되어 있고, 데이터·거버넌스 준비도 층은 상대적으로 얕다.
| 구분 | 현황 (2025\~2026) |
|---|---|
| 정부 전략 | ‘AI 3대 강국 전략’ — AI 반도체·초대규모 클라우드·데이터 주권 3축 동시 추진. 국내 AI 연산 수용능력 30%+ 확장 목표 |
| 건설 붐 | 착공/예정 데이터센터 70여 개. 국내 시장 2025년 약 7.4조원 → 2031년 23.8조원 (CAGR 21.5%). 전남 3GW급, 울산 SK–AWS 등 |
| CSP 실적 | KT클라우드 2025년 매출 9,975억원(+27.4%), 국내 최초 액체냉각 가산 AI DC 개소, 2030년 320MW 확보 로드맵. NHN클라우드 4분기 첫 흑자 |
| 구조적 한계 | 국내 DC 평균 랙 밀도 3\~5kW. 반면 B200 8-GPU 서버 1대 ≈ 20kW, 랙 ≈ 80kW. H200·B200급부터 수냉 사실상 필수 |
| 역할 재정의 | KT cloud AI Foundry 등 — 단순 인프라 공급자에서 산업별 AI SaaS를 공동 기획하는 ‘서비스 오케스트레이터’로 전환 시도 |
| 시사점 국내 시장의 담론과 자본이 ①(물리)에 쏠려 있다는 것은, 역설적으로 ②(데이터)·③(조직 준비도) 및 ①의 ‘운영’ 영역이 상대적 공백이라는 의미다. 하드웨어 건설은 하이퍼스케일러·건설사·텔코가 압도적 자본으로 선점한 레드오션이다. MSP가 방어 가능한 마진은 GPU를 ‘깔아주는’ 데 있지 않고, GPU를 ‘운영·최적화·서비스화’하는 데 있다. |
|---|
기존 클라우드 인프라 엔지니어(네트워크·시스템·쿠버네티스 중심)가 AI-Ready/GPUaaS 운영자로 전환하려면, 다음 다섯 개 역량 축을 새로 확보해야 한다. 각 축은 ‘왜 필요한가 → 무엇을 다뤄야 하는가 → 어떤 실무 역량을 갖춰야 하는가’ 순으로 정리했다.
3.1 GPU-as-a-Service의 본질과 기존 인프라와의 차이
GPUaaS는 단순히 GPU가 꽂힌 VM을 임대하는 것이 아니다. MSP가 다수 테넌트에게 GPU 자원을 분할·격리·과금·관측하며 SLA를 보장하는 서비스다. 기존 CPU/스토리지 중심 MSP 운영과 근본적으로 다른 점은 세 가지다: (1) 자원 단위가 ‘코어·GB’가 아니라 ‘GPU·VRAM·인터커넥트 대역폭’이며, (2) 워크로드가 노드 내부가 아니라 노드 간 초저지연 통신에 성능이 좌우되고, (3) 활용률(utilization)이 곧 마진이라 GPU가 유휴로 도는 순간 수익이 증발한다. 따라서 인프라 엔지니어의 KPI가 ‘가용성’에서 ‘GPU 활용률 × 격리 품질 × 통신 효율’로 이동한다.
3.2 GPU 슬라이싱 — 자원 분할·격리 (Multi-Tenancy의 핵심)
하나의 물리 GPU를 여러 테넌트/워크로드가 나눠 쓰게 하는 기술이다. 방식에 따라 격리 수준과 밀도가 달라지며, MSP는 워크로드 민감도와 과금 모델에 맞춰 셋을 조합해야 한다.
| 방식 | 격리 수준 | 특징 / 적합 워크로드 |
|---|---|---|
| MIG (Multi-Instance GPU) | 하드웨어 격리 (메모리·연산 물리 분할) | GPU를 최대 7개 인스턴스로 분할, 각 인스턴스가 전용 메모리·SM 보유. A100/H100/L40 등 특정 GPU만 지원. 파티션을 사전 정의해야 하고 변경 시 GPU 리셋 필요(정적). 멀티테넌트 추론·보장형 SLA에 적합 |
| Time-Slicing (시분할) | 격리 없음 (순차 컨텍스트 스위칭) | 드라이버가 워크로드를 시간 단위로 번갈아 스케줄링. 거의 모든 NVIDIA GPU 지원, 사전 파티션 불필요(동적). 다수 사용자 고밀도 수용에 유리하나 성능 예측성·격리 약함. 개발·저민감 워크로드에 적합 |
| MPS (Multi-Process Service) | 소프트웨어 공간 분할 | SM(연산 유닛)을 스레드 비율로 분할해 여러 프로세스를 동시 실행. 개별 워크로드가 GPU를 완전히 못 채울 때 효율↑ |
MIG와 time-slicing은 독립적이며 조합 가능하다(먼저 MIG로 격리 인스턴스를 만들고 그 위에 time-slicing 적용). 쿠버네티스 환경에서는 NVIDIA GPU Operator가 두 방식을 모두 구성하며, 프로덕션급 강한 테넌트 격리를 위해서는 vCluster·Run:ai·Volcano 같은 오케스트레이션 계층을 더한다.
| 엔지니어가 실제로 갖춰야 할 역량 GPU Operator로 MIG 프로파일(예: 1g.5gb, 3g.20gb)을 설계·배포하고, 테넌트별로 어떤 슬라이싱 전략을 매핑할지 결정하는 능력. “격리(MIG) vs 밀도(time-slicing)”의 트레이드오프를 SLA·보안요건·과금정책과 연결해 판단하는 것이 핵심 판단 역량이다. 멀티테넌트 GPU는 일반 데이터센터 보안 관행으로 접근하면 안 되며(2025년 1월 NVIDIA Container Toolkit 관련 CVE 등), 격리 수준 선택이 곧 보안 결정이다. |
|---|
3.3 GPU 관측성(Observability) — DCGM 기반 모니터링
GPU 활용률이 곧 마진인 만큼, 관측성은 부가 기능이 아니라 수익 관리의 핵심이다. 기존 CPU/메모리 모니터링(Node Exporter 등)만으로는 GPU 내부가 전혀 보이지 않는다.
• NVIDIA DCGM (Data Center GPU Manager) 이 표준. \`dcgm-exporter\`가 GPU 텔레메트리를 Prometheus 메트릭으로 노출하고, Grafana로 시각화한다. MIG 인스턴스별로도 개별 모니터링이 가능하다.
• 핵심 메트릭 예시: \`DCGM\_FI\_DEV\_GPU\_UTIL\`(활용률), \`DCGM\_FI\_DEV\_FB\_USED\`(VRAM 사용), \`DCGM\_FI\_DEV\_RUNNING\_PROCESSES\`(인스턴스별 프로세스 수). 이를 기반으로 “활용률 20% 미만 30분 지속”, “VRAM 90% 초과” 같은 알림 규칙(PrometheusRule)을 운영한다.
• 주의점: NVIDIA Device Plugin으로 time-slicing을 켜면 dcgm-exporter가 메트릭을 컨테이너 단위로 귀속시키지 못한다. 즉 슬라이싱 전략과 과금·관측 정합성을 함께 설계해야 한다 — 이것이 MSP가 놓치기 쉬운 지점이다.
| 엔지니어가 실제로 갖춰야 할 역량 dcgm-exporter → Prometheus → Grafana 파이프라인 구축, MIG/테넌트 단위 활용률·VRAM·전력·온도 대시보드 설계, 활용률 기반 알림·오토스케일·재배치 정책 수립. 궁극적으로는 이 텔레메트리를 과금(showback/chargeback)과 FinOps로 연결하는 능력. |
|---|
3.4 AI 전용 네트워킹 — InfiniBand / RoCEv2 · RDMA · GPUDirect · NCCL
여기가 기존 인프라 엔지니어에게 가장 낯설고, 동시에 가장 차별화되는 영역이다. AI 클러스터의 성능은 노드 ‘내부’가 아니라 노드 ‘간’ GPU 통신에서 결정된다. 분산 학습에서 GPU들은 매 스텝마다 gradient를 교환하므로, 네트워크가 병목이면 값비싼 GPU가 통신을 기다리며 논다.
핵심 개념 체계
• RDMA (Remote Direct Memory Access): CPU·OS를 거치지 않고 노드 간 메모리를 직접 교환해 지연을 줄이고 CPU를 해방한다. AI 패브릭의 전제.
• GPUDirect RDMA: 한 서버의 GPU 메모리가 다른 서버의 GPU 메모리를 호스트 DRAM을 거치지 않고 직접 읽고 쓴다. GPU 스케일링 효율이 전통 네트워킹의 50\~70%에서 85\~95%로 올라간다.
• NCCL (NVIDIA Collective Communications Library): 멀티 GPU 집합통신(AllReduce, AllGather, ReduceScatter 등)의 사실상 표준 런타임. NVLink·PCIe·InfiniBand·RoCE를 토폴로지 인식으로 활용한다. 최신 버전(2.27+)은 SHARP(인네트워크 리덕션), 대칭 메모리 등으로 1,000 GPU 이상 규모까지 최적화한다.
• 패브릭 선택 — InfiniBand vs RoCEv2: 대규모 학습·초저지연에는 InfiniBand(HCA=ConnectX 시리즈, Subnet Manager가 경로 관리)가 유리하나 고가·복잡. RoCEv2는 이더넷 위에서 RDMA를 구현해 비용·상호운용성이 좋지만 PFC/ECN 무손실 튜닝이 까다롭다(스위치 하나만 잘못돼도 tail latency가 치명적).
| 패브릭 | 지연/성능 | 적합 상황 |
|---|---|---|
| InfiniBand | 최저 지연, GPUDirect RDMA 기본 제공, 내장 혼잡제어 | 대규모 분산 학습(NCCL/MPI), tail latency가 중요, 전용 AI/HPC 패브릭 |
| RoCEv2 | IB에 근접(튜닝 시), 비용·상호운용 우수 | 엔터프라이즈 통합, 이더넷 운영 역량 보유, PFC/ECN 튜닝 투자 가능 |
| 표준 Ethernet | 일반 수준 | 소규모 배포, 단일노드/경량 분산 추론 |
실무 구성 예시: 쿠버네티스에서 GPUDirect RDMA를 쓰려면 Mellanox OFED 드라이버 \+ NVIDIA Network Operator를 설치하고, Pod에 \`rdma/ib\` 리소스를 요청하며, \`NCCL\_IB\_HCA\`·\`NCCL\_SOCKET\_IFNAME\` 등 환경변수로 IB 인터페이스를 지정한다. NCCL 튜닝·검증에는 \`nccl-tests\`로 대역폭을 측정하고 \`NCCL\_DEBUG=INFO\`로 RDMA 경로를 진단한다.
| 엔지니어가 실제로 갖춰야 할 역량 800G/400G 광 인터커넥트 기반 AI 패브릭 토폴로지 이해, InfiniBand Subnet Manager 운영, RoCEv2의 PFC/ECN 무손실 튜닝, GPUDirect RDMA 드라이버 스택(OFED/nv\_peer\_mem) 구성, NCCL 환경변수 튜닝과 nccl-tests 벤치마킹. “네트워크가 AI 전략의 병목이 되지 않게 하는” 것이 이 역할의 본질이다. |
|---|
3.5 CUDA 소프트웨어 스택과 컨테이너 생태계
인프라 엔지니어가 CUDA로 커널을 직접 짜야 하는 것은 아니다. 다만 스택을 이해하고 버전 정합성을 관리하는 것은 필수다: GPU 드라이버 ↔ CUDA Toolkit ↔ cuDNN/NCCL ↔ 프레임워크(PyTorch/TF) ↔ 컨테이너의 호환성 매트릭스가 어긋나면 클러스터 전체가 멈춘다.
• 컨테이너 표준: NVIDIA Container Toolkit, NGC Catalog(검증된 프레임워크 컨테이너), 쿠버네티스 위의 NVIDIA GPU Operator / Network Operator가 배포·구성을 자동화한다.
• 스케줄링/오케스트레이션: 대규모 학습 잡은 Slurm 또는 Kubernetes(+Volcano/Run:ai/Kubeflow)로 큐잉·갱 스케줄링한다. ‘job scheduling vs container orchestration’의 구분과 갱 스케줄링(전체 GPU가 동시에 확보돼야 잡이 시작) 개념이 중요하다.
• 버전 거버넌스: GPUDirect Async/IBGDA 등 최신 기능은 특정 CUDA 12.x·ConnectX-6 Dx 이상·커널 모듈을 요구한다. MSP는 이 호환성 매트릭스를 표준 이미지로 관리해야 한다.
3.6 역량 로드맵 제안
기존 인프라 엔지니어를 3단계로 전환할 것을 제안한다. 이는 DEO의 12개월 AI 교육계획과 연결해 운영할 수 있다.
| 단계 | 목표 역량 | 대표 학습/인증 |
|---|---|---|
| Foundation (0\~3개월) | GPU 아키텍처(A100/H100/B200), CUDA·DCGM·NGC, NVLink·InfiniBand 개념, 학습 vs 추론 구분 | NVIDIA NCA-AIIO (AI Infrastructure & Operations Associate) |
| Operations (3\~6개월) | GPU Operator로 MIG/time-slicing 배포, dcgm-exporter 관측 파이프라인, Slurm/K8s GPU 스케줄링 | 실습 기반 — 사내 GPU 클러스터 PoC 운영 |
| Scale & Optimize (6\~12개월) | InfiniBand/RoCEv2 패브릭 튜닝, GPUDirect RDMA·NCCL 최적화, 멀티테넌트 격리·보안, FinOps/활용률 최적화 | NVIDIA 전문 트랙 \+ 벤더(NVIDIA/CoreWeave 류) 레퍼런스 아키텍처 |
3.7 전략적 제언 (평가)
이 보고서의 핵심 판단을 명확히 남긴다. Bespin이 인프라 엔지니어를 재교육하며 향할 방향은 ‘데이터센터를 짓는 팀’이 아니라 ‘GPU를 운영·최적화하는 팀’이어야 한다.
• 물리 인프라(①) 건설 경쟁에 뛰어드는 것은 권하지 않는다. 자본집약적이고 하이퍼스케일러·건설사·텔코가 선점했으며 MSP 마진이 얇다. 국내 담론도 여기 과포화되어 있어 어휘 자체가 묻힌다.
• 방어 가능한 포지션은 ‘운영 서비스화’다. GPUaaS의 슬라이싱·관측·네트워킹·스케줄링을 SLA·과금·보안과 묶어 서비스로 제공하고(관리형 GPU), 여기에 Bespin이 이미 언어화하고 있는 AI-Ready 데이터 파이프라인(②) 과 조직 준비도 진단(③) 을 결합하면, Cisco/Microsoft가 깔아놓은 글로벌 프레임워크 서사와 자연스럽게 접속된다.
• 인프라 엔지니어의 재정의가 이 전략의 실행 기반이다. “클라우드 리소스를 안정적으로 운영하는 사람”에서 “GPU 활용률·격리·통신 효율을 책임지는 AI 인프라 운영자”로. 이 인력 전환이 되지 않으면 위 서비스화는 슬로건에 그친다.
본 보고서는 공개된 업계 자료(Accenture·Gartner·Cisco·McKinsey·NVIDIA 문서 및 국내 CSP·언론 보도 등, 2025\~2026)를 근거로 작성되었으며, 수치·전망은 원출처 기준입니다.