Compute Platforms - 06. HCI (Hyper-Converged Infrastructure)

주방·거실·침실을 한 방에 — HCI의 탄생과 3-tier의 종말

2009년, Nutanix라는 스타트업이 "SAN 없는 데이터센터"라는 슬로건을 내걸었다. 당시 데이터센터의 표준은 3-tier 아키텍처였다 — 컴퓨트 서버(VM을 돌리는 서버), SAN(Storage Area Network, 데이터를 저장하는 전용 스토리지), 그리고 이 둘을 잇는 고속 네트워크. 세 층이 각각 별도의 하드웨어·별도의 벤더·별도의 관리 도구를 가졌다. SAN 하나에 수억 원이 들었고, 확장하려면 또 SAN을 사야 했다. 관리자는 3개의 벤더 기술지원에 전화를 걸어야 했고, 문제가 생기면 어느 층 때문인지 찾는 데만 며칠이 걸렸다. Nutanix의 도발은 — 이 세 층을 하나의 서버 안에 합치자는 것이었다.

이 글은 HCI(Hyper-Converged Infrastructure, 하이퍼컨버지드 인프라)를 다룬다. 한 서버(노드) 안에 컴퓨트(CPU·메모리)와 스토리지(디스크)와 네트워크(NIC)가 다 들어있고, 이런 노드 여러 대를 묶어 클러스터를 만드는 구조. foundations 01에서 "원룸 아파트" 비유로 맛보기로 소개했고, foundations 04의 내구성(복제·erasure coding)과 직결된다. 이전 글에서 본 가상화·VM 라이프사이클이 "한 서버 안에서"의 이야기였다면, HCI는 "여러 서버를 묶어 하나의 논리적 풀로 만드는" 이야기다.

3-tier 아키텍처 — 기존 방식과 그 문제점

HCI를 이해하려면 먼저 HCI가 대체한 3-tier 아키텍처를 봐야 한다. 2000년대 데이터센터의 표준 구조였다.

flowchart TD
    subgraph COMPUTE["컴퓨트 층<br/>(서버 100대)"]
        SVR["서버<br/>(CPU, 메모리, 하이퍼바이저)"]
    end
    subgraph NETWORK["네트워크 층"]
        SW["FC 스위치<br/>(Fibre Channel)"]
    end
    subgraph STORAGE["스토리지 층<br/>(SAN)"]
        SAN["SAN 어레이<br/>(EMC, NetApp, HPE)"]
    end
    SVR -->|"FC 프로토콜"| SW
    SW --> SAN

이 구조에서 각 층은 물리적으로 분리된다. 컴퓨트 서버는 CPU·메모리만 갖고 디스크는 없고(디스크는 SAN에 있음), SAN은 디스크만 갖고 CPU는 없다. 둘 사이를 FC(Fibre Channel) 라는 전용 스토리지 네트워크가 잇는다. 컴퓨트 서버가 디스크에 접근하려면 — FC 스위치를 거쳐 SAN까지 왕복해야 한다.

3-tier의 장점은 — 각 층을 독립적으로 확장할 수 있다는 것이었다. 컴퓨트가 부족하면 서버만 사고, 스토리지가 부족하면 SAN만 사면 됐다. 2000년대에는 이게 합리적이었다 — 하드웨어가 비싸고, 각 층의 확장 주기가 달랐으니까.

하지만 문제가 있었다. 첫째, 비용. SAN은 엔터프라이즈급 전용 장비라 매우 비쌌다 — 보통 수억 원에서 수십억 원. FC 스위치도 비싸고, FC 케이블·FC HBA(Host Bus Adapter) 카드도 다 별도 구매. 둘째, 복잡도. 컴퓨트 관리(vSphere), 스토리지 관리(SAN 관리 콘솔), 네트워크 관리(FC 스위치 관리)가 각각 다른 도구. 셋째, 확장 단위가 큼. SAN은 용량을 늘리려면 디스크 쉘프(수십 TB 단위)를 통째로 사야 했다 — 5TB만 더 필요해도 50TB 쉘프를 사야 하는 비효율. 넷째, 벤더 종속. 한 번 EMC SAN을 사면 거기에 맞춰 컴퓨트·네트워크도 EMC 호환으로 맞춰야 했다.

이 문제들에서 HCI가 출발한다.

HCI의 본질 — 한 노드에 다 통합

HCI(Hyper-Converged Infrastructure)의 정의는 단순하다 — 컴퓨트(CPU·메모리), 스토리지(디스크), 네트워크(NIC)를 한 서버(노드) 안에 통합하고, 소프트웨어가 관리하는 구조. "Hyper-Converged"의 "Converged"는 "합쳐졌다"는 뜻이고, "Hyper-"는 "가상화(hypervisor) 기반으로"라는 의미. 즉 "하이퍼바이저 위에서 컴퓨트+스토리지+네트워크를 통합 관리한다"는 뜻이다.

flowchart TD
    subgraph NODE1["HCI 노드 1"]
        C1["CPU·메모리<br/>(컴퓨트)"]
        D1["디스크<br/>(스토리지)"]
        N1["NIC<br/>(네트워크)"]
        HV1["하이퍼바이저<br/>(ESXi/KVM)"]
    end
    subgraph NODE2["HCI 노드 2"]
        C2["CPU·메모리"]
        D2["디스크"]
        N2["NIC"]
        HV2["하이퍼바이저"]
    end
    subgraph NODE3["HCI 노드 3"]
        C3["CPU·메모리"]
        D3["디스크"]
        N3["NIC"]
        HV3["하이퍼바이저"]
    end
    NODE1 <--->|"일반 이더넷<br/>(10/25/100G)"| NODE2
    NODE2 <--->|"일반 이더넷"| NODE3
    NODE1 <---> NODE3

비유하자면 — 3-tier는 주방·거실·침실이 각각 다른 건물에 있는 주택이었다(이동이 번거롭고, 각 건물을 따로 관리해야 했다). HCI는 원룸 아파트다 — 모든 게 한 공간에 들어있고, 한 관리자(소프트웨어)가 전부 관리한다. 원룸이 더 작고 효율적이지만, 주방만 늘리거나 침실만 늘릴 수는 없다 — 원룸 전체를 늘려야 한다(스케일아웃).

분산 스토리지 — 각 노드의 로컬 디스크를 클러스터 전체에 분산

HCI의 핵심 기술은 분산 스토리지(distributed storage)다. 각 노드는 자체 로컬 디스크(NVMe·SATA SSD·HDD)를 갖고 있다. 하이퍼바이저(ESXi·KVM) 위에 돌아가는 스토리지 소프트웨어(vSAN·Ceph·Nutanix DSF)가 이 로컬 디스크들을 논리적으로 묶어 클러스터 전체의 단일 스토리지 풀을 만든다.

이게 왜 혁신적인가. 3-tier에서는 SAN이 별도 하드웨어로 있었지만 — HCI에서는 SAN의 역할을 소프트웨어가 대신한다. 비싼 SAN 하드웨어 없이, 일반 서버의 로컬 디스크 + 소프트웨어로 같은 일을 하는 것이다. foundations 06의 IaC 원칙("인프라를 소프트웨어로")이 스토리지에 적용된 사례다.

분산 스토리지가 작동하는 방식을 구체적으로 보자. VM이 디스크에 데이터를 쓰면:

1. 하이퍼바이저의 스토리지 소프트웨어가 데이터를 받는다.
2. 데이터를 로컬 디스크에 쓰는 동시에, 네트워크를 통해 다른 노드의 디스크에도 복사한다(복제, replication).
3. 데이터의 복사본이 어디에 있는지를 메타데이터로 추적한다.

VM이 데이터를 읽을 때는:

1. 스토리지 소프트웨어가 메타데이터를 보고 데이터가 어디에 있는지 찾는다.
2. 로컬 디스크에 있으면 즉시 읽는다(빠름). 다른 노드에 있으면 네트워크를 통해 가져온다(느림).

여기서 데이터 로컬리티(data locality) 라는 개념이 등장한다. VM이 실행 중인 노드에 데이터 복사본이 있으면 — 네트워크를 거치지 않고 로컬 디스크에서 바로 읽는다. 비유하자면 — 같은 원룸 안의 냉장고에서 재료를 꺼내 요리하는 것(빠름) vs 다른 건물의 냉장고에서 재료를 배달시키는 것(느림). HCI 소프트웨어는 VM과 데이터를 같은 노드에 두려고 시도하지만 — VM이 라이브 마이그레이션(05 글에서 본 것)으로 다른 노드로 옮겨가면, 데이터 로컬리티가 깨진다. 그래서 일부 HCI(vSAN의 "스토리지 정책 기반 관리")는 VM이 이동하면 데이터도 따라서 이동시킨다.

내구성 — foundations 04에서 본 복제가 여기서 실천

HCI의 분산 스토리지에서 데이터는 보통 2 ~ 3개 노드에 복제된다. 한 노드가 고장 나도 다른 노드의 복사본이 살아 있으니까 — foundations 04에서 본 "3-way 복제"가 소프트웨어로 구현되는 것이다. 또 erasure coding도 지원한다 — vSAN의 "RAID-5/6" 모드, Ceph의 erasure coded pool. 복제보다 저장 효율이 좋지만 CPU 연산이 더 든다. 이 trade-off는 foundations 04의 내구성 비교 표에서 다뤘다.

내구성 방식	HCI에서의 구현	저장 효율	장애 허용	비고
2-way 복제	데이터 2개 노드에 복사	0.5x	1 노드	기본, 빠름
3-way 복제	데이터 3개 노드에 복사	0.33x	2 노드	높은 내구성, 많은 용량 소비
Erasure coding (RAID-5)	데이터 + 패리티 분산	0.75x	1 노드	용량 효율, CPU 비용
Erasure coding (RAID-6)	데이터 + 2개 패리티	0.67x	2 노드	용량 + 내구성, 더 큰 CPU 비용

스케일아웃 — 노드를 추가하면 컴퓨트+스토리지가 같이 늘어난다

3-tier에서 스토리지를 늘리려면 SAN에 디스크 쉘프를 추가해야 했다 — 컴퓨트는 안 늘어난다. HCI에서는 — 노드(서버 한 대)를 추가하면 컴퓨트(CPU·메모리)와 스토리지(디스크)가 같이 늘어난다. 이걸 스케일아웃(scale-out)이라 부른다.

비유하자면 — 3-tier는 "주방이 좁으면 주방만 늘린다"는 유연성이 있었다. HCI는 "원룸을 늘리면 주방과 침실이 같이 늘어난다" — 유연성은 떨어지지만, 원룸 하나 추가하는 게 주방만 짓는 것보다 간단하다.

스케일아웃의 장점은 — 확장 단위가 작고 예측 가능하다는 것. 노드 한 대(CPU 32코어, 메모리 256GB, 디스크 20TB)를 추가하면 — 컴퓨트 32코어 + 스토리지 20TB가 같이 늘어난다. SAN처럼 50TB 쉘프를 통째로 살 필요가 없다. 단점은 — 컴퓨트만 늘리고 싶거나 스토리지만 늘리고 싶을 때 불편하다. 이걸 HCI 업계는 "하이퍼컨버지드의 딜레마"라 부르며, 일부 제품(vSAN의 "스토리지 전용 노드", Nutanix의 "컴퓨트 전용 노드")으로 부분 해결한다 — 전용 노드를 두고 한 종류의 자원만 확장하는 것. 하지만 이건 어디까지나 예외적 구성이고, HCI의 기본 철학은 "통합 확장"이다.

확장 방식	3-tier	HCI	비고
컴퓨트만 늘리기	서버 추가	전용 노드(제한적)	3-tier 유리
스토리지만 늘리기	SAN 디스크 쉘프 추가	전용 노드(제한적)	3-tier 유리
둘 다 늘리기	서버 + SAN 따로	노드 한 대 추가	HCI 압도적 유리
확장 단위	큼(SAN 쉘프 50TB 등)	작음(노드 1대)	HCI 유리
확장 복잡도	높음(각 층별 설정)	낮음(노드 추가만)	HCI 유리
예산 단위	큼(SAN 가격)	작음(서버 가격)	HCI 유리

주요 HCI 솔루션 — 각자의 자리

VMware vSAN — 2014년 vSphere 5.5와 함께 발표. ESXi 하이퍼바이저에 통합된 분산 스토리지. 기존 vSphere 고객이 "vSAN 켜기"만 하면 SAN 없이 HCI 구축 가능. vSphere의 vMotion·DRS 같은 관리 기능과 자연스럽게 연동. 엔터프라이즈 점유율 1위. 단, VMware는 Broadcom에 인수(2023년)된 뒤 라이선스 정책이 바뀌어 비용 구조가 요동치고 있다 — 기존 고객의 불만이 커지는 추세.

Nutanix — 2009년 창업. "SAN 없는 데이터센터"를 슬로건으로 내걸며 3-tier를 공격. 자체 하이퍼바이저 AHV(Acropolis Hypervisor, KVM 기반)를 기본 제공하면서 ESXi 라이선스 비용을 절감. 관리 도구 Prism이 한 콘솔에서 컴퓨트·스토리지·네트워크를 전부 관리. 엔터프라이즈 HCI 시장에서 VMware의 주요 경쟁자.

Proxmox VE(Virtual Environment) — 2008년 발표. 오픈소스(GPL), 무료. KVM(VM) + LXC(컨테이너)를 동시에 지원하고, ZFS를 스토리지 백엔드로 써서 데이터 무결성·스냅샷·압축을 기본 제공. 중소기업·소호·개인 사용자에게 인기. 기업 지원(Proxmox VE Server Subscriptions)은 별도 비용. vSAN·Nutanix 대비 기능은 제한적이지만, 비용이 0에 가까워 가성비 최강.

Microsoft Azure Stack HCI — 2020년 발표. Hyper-V 기반. Windows Server의 Storage Spaces Direct(소프트웨어 정의 스토리지)를 HCI 형태로 패키지. Azure와의 하이브리드 연결(Arc)이 강점. Windows 환경의 자연스러운 확장.

기타 — HPE SimpliVity(2017년 HPE 인수), Cisco HyperFlex(2016년), Dell VxRail(VMware vSAN + Dell 하드웨어). 대형 벤더가 HCI 시장에 들어온 사례들.

솔루션	라이선스	하이퍼바이저	전형 환경	강점
vSAN	상용(Broadcom)	ESXi	엔터프라이즈	vSphere 통합, 점유율 1위
Nutanix	상용	AHV(KVM) 또는 ESXi	엔터프라이즈	Prism 관리, 독자 스택
Proxmox VE	오픈소스(GPL)	KVM + LXC	중소기업·개인	무료, ZFS 통합
Azure Stack HCI	상용(Microsoft)	Hyper-V	Windows 환경	Azure 연동
Ceph(스토리지만)	오픈소스(LGPL)	독립	OpenStack, 자체 구축	순수 분산 스토리지

Ceph은 HCI "솔루션"이라기보다 분산 스토리지 소프트웨어다. 하지만 OpenStack과 KVM을 조합하면 HCI와 동일한 구조를 만들 수 있다. AWS·GCP 같은 클라우드 벤더도 자체 분산 스토리지(EBS·Persistent Disk)를 Ceph과 비슷한 원리로 구축해 쓴다.

HCI의 이점과 단점

HCI가 3-tier를 대체하면서 가져온 이점을 정리한다.

이점:

• 단순성 — 한 노드에 다 들어있고, 한 소프트웨어가 관리한다. 벤더 기술지원에 전화 하나면 끝.
• 비용 절감 — SAN·FC 스위치·FC HBA가 불필요. 일반 서버 + 일반 이더넷으로 충분.
• 세밀한 확장 — 노드 한 대 단위로 확장. 50TB 쉘프가 아니라 20TB 노드로.
• 빠른 배포 — 노드를 랙에 꽂고 클러스터에 추가하면 끝. SAN 설정·FC 케이블링이 필요 없다.
• 소프트웨어 정의 — 스토리지 정책(복제 수·압축·중복 제거)을 소프트웨어로 설정. 하드웨어를 안 바꿔도 정책을 바꿀 수 있다.

단점:

• 벤더 종속 — 한 번 vSAN을 선택하면 vSAN 호환 하드웨어·소프트웨어만 써야 한다. 다른 HCI로 옮기는 건 거의 재구축.
• 확장 유연성 제한 — 컴퓨트만 늘리거나 스토리지만 늘리기 어렵다. 노드를 추가하면 둘이 같이 늘어난다.
• 노드 고장의 영향 — 한 노드가 고장 나면 컴퓨트(그 노드의 VM)와 스토리지(그 노드의 디스크 데이터)가 같이 영향을 받는다. 물론 복제로 데이터는 살아있지만, 일시적으로 다른 노드에 부하가 몰린다.
• 네트워크 의존도 — 분산 스토리지가 노드 간 통신에 의존하므로, 네트워크가 느리면 스토리지도 느려진다. 3-tier의 FC(저지런 전용 네트워크) 대신 일반 이더넷을 쓰기 때문에 — 네트워크 설계가 더 중요하다.
• 소프트웨어 복잡도 — 분산 스토리지 소프트웨어 자체가 복잡하다. 버그·설정 오류·업그레이드 문제가 발생하면 — 전체 스토리지 풀에 영향을 준다.

HCI와 클라우드 — 같은 원리, 다른 규모

클라우드(AWS·GCP·Azure)의 인프라는 본질적으로 HCI 구조다. 각 물리 서버에 컴퓨트(VM을 돌림)와 스토리지(EBS·Persistent Disk의 일부)가 같이 있고, 소프트웨어가 분산 관리한다. 다만 — 클라우드는 규모가 다르다. AWS는 전 세계에 수백만 대의 서버를 두고, 그 위의 분산 스토리지가 하나의 거대한 논리적 풀을 만든다. vSAN·Nutanix 클러스터는 보통 수십 ~ 수백 노드 규모인데 비해 — 클라우드는 수만 ~ 수십만 노드 규모다.

고객이 EC2 인스턴스를 만들면 — AWS의 소프트웨어가 물리 서버를 할당하고, EBS 볼륨을 분산 스토리지에서 잘라 주고, 네트워크를 설정한다. 이 과정이 HCI 관리 소프트웨어가 하는 일과 본질적으로 같다. 차이는 — 고객은 그 뒤를 못 본다는 것. 클라우드가 "인스턴스 만들기" 버튼 하나로 끝나는 이유가 — HCI의 원리를 대규모로 자동화해 놨기 때문이다.

실습 — 분산 스토리지 상태 직접 확인

1. Proxmox VE 클러스터 상태 (Proxmox 환경)

# Proxmox 클러스터 노드 목록
pvecm status
# 스토리지 풀 상태 (ZFS)
zpool status
# VM 목록과 어느 노드에서 실행 중인지
qm list

확인할 것: pvecm status의 노드 수·쿼럼 상태(과반수 이상 살아있는지). zpool status의 디스크 건강 상태(ONLINE이어야 정상). qm list의 VM 노드 분포.

2. Ceph 클러스터 상태 (OpenStack/Ceph 환경)

# Ceph 클러스터 전체 상태
ceph status
# 또는 짧게
ceph -s
# OSD(스토리지 데몬) 목록
ceph osd tree

확인할 것: ceph -s의 health: HEALTH_OK(정상). degraded나 degraded objects가 있으면 일부 복제본이 부족하다는 뜻. OSD가 어느 호스트에 있는지, up/down 여부.

# 예상 출력 (ceph -s, 정상)
  cluster:
    id:     a1b2c3d4-...
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    mgr: mon1(active)
    osd: 12 osds: 12 up, 12 in
  data:
    pools:   3 pools, 1024 pgs
    objects: 45.2M objects, 180 GiB
    usage:   540 GiB used, 1.2 TiB / 1.7 TiB avail
    pgs:     1024 active+clean

3. vSAN 상태 (VMware 환경)

# vSAN 클러스터 디스크 그룹 상태 (ESXi Shell에서)
esxcli vsan storage list
# vSAN 클러스터 상태 (PowerCLI에서)
Get-VsanClusterHealth -Cluster "MyCluster" | Select-Object OverallHealth

확인할 것: 각 디스크의 상태(Healthy). OverallHealth가 green이어야 정상. yellow나 red면 문제가 있는 것.

4. 로컬 디스크의 ZFS 상태 (Proxmox 또는 ZFS 단독 환경)

# ZFS 풀 상태 (복제·체크섬·압축 확인)
zpool list -v
zpool status -v
# 데이터셋(파일시스템)별 사용량
zfs list

확인할 것: 풀의 HEALTH가 ONLINE. CKSUM 에러가 0이어야(체크섬 오류 = 디스크 문제 신호). zfs list에서 압축률(RATIO)이 높으면 중복 제거·압축 효과가 큰 것.

미검증: 위 명령은 각 환경(Proxmox·Ceph·VMware vSAN)에 설치돼 있어야 동작. 단일 Linux VM에서는 분산 스토리지 명령이 안 됨 — HCI는 클러스터 환경에서만 의미 있음. ZFS는 단일 노드에서도 사용 가능(Proxmox 단일 노드 등).

판단 표 — 3-tier vs HCI, 언제 무엇을 선택하나

기준	3-tier가 유리	HCI가 유리
규모	매우 큰 규모(수천 노드 이상)	중소규모(3 ~ 수백 노드)
확장 패턴	컴퓨트와 스토리지가 다른 속도로 성장	둘이 비슷한 속도로 성장
관리 인력	스토리지 전담 팀이 있음	일반 엔지니어가 전부 관리
예산	SAN 투자가 이미 있음	새 구축, 예산 제한
벤더 선호도	특정 SAN 벤더(EMC·NetApp) 선호	벤더 중립적, 오픈소스 선호
성능 요구	극단적 IOPS(수백만), 저지연	일반 엔터프라이즈 워크로드
클라우드와의 관계	이미 클라우드 사용 중	하이브리드(온프레 HCI + 클라우드)

이 표의 핵심은 — "HCI가 항상 이긴다"가 아니라 — 맥락에 따라 다르다는 것이다. 매우 큰 규모의 데이터센터(AWS·Google·Facebook 수준)에서는 여전히 3-tier(또는 그 변형)를 쓴다. 컴퓨트와 스토리지가 다른 속도로 성장하고, 각각 독립적으로 최적화해야 하니까. 하지만 중소규모 엔터프라이즈에서는 HCI가 단순성·비용·관리 편의성으로 압도적 우위다. foundations 05의 build vs buy 질문과 연결된다 — HCI 소프트웨어를 자체 구축(Ceph+KVM)할지, 상용 솔루션(vSAN·Nutanix)을 살지, 아니면 클라우드에 맡길지.

HCI는 인프라의 "원룸화"다

도입의 Nutanix 사건으로 돌아가자. "SAN 없는 데이터센터"는 2009년엔 도발적이었지만, 2026년엔 업계 표준이 됐다. HCI가 3-tier를 완전히 대체한 건 아니다 — 매우 큰 규모나 특수 요구사항에서는 3-tier가 여전히 살아있다. 하지만 대부분의 엔터프라이즈 데이터센터에서, 새 구축 시 HCI가 기본 선택지가 됐다. 이유는 단순하다 — 관리가 쉽고, 비용이 싸고, 확장이 유연하다. 3-tier가 "주방·거실·침실이 각각 다른 건물"이라면, HCI는 "한 공간에 다 있는 원룸"이다. 원룸이 항상 최선은 아니지만, 대부분의 상황에서 가장 실용적이다.

HCI를 이해하면 다른 질문에도 답이 보인다. "왜 vSAN·Nutanix가 인기인가" → SAN 비용·복잡도 제거. "왜 클라우드 EBS가 저렴하면서도 내구성이 높은가" → 분산 스토리지의 복제·erasure coding. "왜 Proxmox가 중소기업에 인기인가" → 무료이면서도 ZFS 기반 HCI 구축 가능. HCI는 인프라의 "원룸화" — 비싸고 복잡했던 것을 단순하고 효율적으로 만든 기술이다.

다음 글에서는 HCI의 컴퓨트 위에서 도는 또 다른 추상화를 다룬다 — 컨테이너 런타임. VM이 "한 서버를 여러 서버로 쪼개는" 기술이라면, 컨테이너는 "한 OS 커널을 여러 프로세스가 공유하면서 격리하는" 더 가벼운 기술. containerd·OCI· namespaces·cgroups가 어떻게 VM보다 가볍게 격리를 만드는지를 본다.

---

참고

• Nutanix, "Web-Scale IT with Nutanix Xtreme Computing Platform" white paper, 2012 — HCI 개념 원전. 접근 2026-07-21
• VMware, "VMware vSAN Architecture" documentation, 2014 — vSAN 설계 원리. 접근 2026-07-21. URL: https://docs.vmware.com/en/VMware-vSAN/index.html
• Weil, S. et al. "Ceph: A Scalable, High-Performance Distributed File System", OSDI 2006 — Ceph 분산 스토리지 원논문. 접근 2026-07-21
• Proxmox Server Solutions, "Proxmox VE Administration Guide" — Proxmox VE/ZFS 문서. 접근 2026-07-21. URL: https://pve.proxmox.com/pve-docs/
• Microsoft, "Azure Stack HCI documentation" — Storage Spaces Direct 기반 HCI. 접근 2026-07-21
• Turner, D. "Hyper-Converged Infrastructure For Dummies", Wiley, 2017 — HCI 개념 입문. 접근 2026-07-21
• Kleppmann, M. , O'Reilly, 2017, Ch.5·Ch.6 — 분산 스토리지 복제·파티셔닝. 접근 2026-07-21
• Gartner, "Magic Quadrant for Hyperconverged Infrastructure Software", 2024 — HCI 시장 분석. 접근 2026-07-21