Datacenter & Cloud - 01. IDC 물리 시설

서버가 사는 건물 — IDC 물리 시설의 모든 것

2012년 10월 29일, 허리케인 샌디가 뉴욕을 강타했다. 맨해튼 남부의 해수면이 올라가 — 33 Whitehall Street에 있던 Datagram의 데이터센터 지하층이 침수됐다. 디젤 발전기가 물에 잠기고, 전력이 끊기고, HuffPo·Gawker·BuzzFeed 같은 주요 미디어 사이트가 줄줄이 다운됐다. 서버는 살아 있었지만 — 전력이 끊기니 서버가 죽었다. 이 사건이 보여주는 것은 — 인프라의 가장 밑바닥인 물리 시설(전력·냉각·건물)이 무너지면 — 그 위의 모든 소프트웨어·데이터·서비스가 무의미해진다는 점이다. foundations 01에서 "인프라는 도시의 도로망과 같다"고 했는데 — 이 글은 그 도로망이 놓이는 물리적 땅 자체를 다룬다.

이 글은 IDC(Internet Data Center)의 물리 시설을 다룬다 — 전력 공급(PDU·UPS·발전기), 냉각(HVAC·핫/콜드 애일), 랙과 케이블링(TIA-924), 등급(Tier I ~ IV), 그리고 PUE(전력 사용 효율). foundations 03에서 본 fault domain의 물리적 경계 — 랙·AZ·리전 — 가 어떻게 물리 시설에서 정의되는지를 본다. 사용자가 클라우드에서 "Launch Instance" 버튼을 누를 때 — 그 버튼 뒤에는 이 물리 시설이 있다.

데이터센터란 — 서버가 사는 건물

데이터센터(data center, IDC) 는 — 수백에서 수만 대의 서버를 수용하고, 그 서버에 전력·냉각·네트워크·보안을 제공하는 전용 건물이다. 비유하자면 — 서버들의 "아파트 단지"다. 각 서버(세대)는 전력(전기)·냉각(냉난방)·네트워크(인터넷)를 건물(데이터센터)에서 공급받는다. 건물 관리자(시설 운영팀)가 — 정전·화재·침수·온도 상승 같은 물리적 위협으로부터 서버를 보호한다.

데이터센터의 규모는 다양하다:

규모	서버 수	전력 용량	전형 사례
소규모 (서버실)	수십 대	수십 kW	사무실 서버실, 소기업
중규모 (코로케이션)	수천 대	수백 kW ~ 수 MW	Equinix, 국내 IDC
대규모 (하이퍼스케일)	수만 ~ 수십만 대	수십 ~ 수백 MW	Google, AWS, Meta
초대규모 (글로벌)	수백만 대 (다수 DC)	GW 단위	AWS 전체, Google 전체

하이퍼스케일 데이터센터 하나의 전력 소비는 — 중소도시 하나의 전력 소비와 맞먹는다. Google의 전체 데이터센터 전력 소비는 — 2024년 기준 약 24TWh로, 아이슬란드 전체 전력 소비의 약 2배다.

전력 — 서버의 생명줄

서버는 전기를 먹고 산다. 전기가 끊기면 — 서버가 꺼지고, 데이터가 날아갈 수 있고, 서비스가 중단된다. foundations 02에서 본 "가용성" 품질 속성이 — 이 전력 공급의 안정성에서 시작된다.

데이터센터의 전력 공급은 — 단일 경로가 아니다. 이중화(redundancy) 의 연속이다. foundations 04에서 본 "N+1" "2N" 패턴이 여기서 물리적으로 실천된다.

flowchart TD
    GRID["상용 전력망<br/>(주 전원)"] --> ATS["ATS<br/>(자동 전환 스위치)"]
    GEN["디젤 발전기<br/>(백업 전원)"] --> ATS
    ATS --> UPS["UPS<br/>(무정전 전원 장치)"]
    UPS --> PDU["PDU<br/>(전력 분배 장치)"]
    PDU --> RACK["랙<br/>(서버들)"]

상용 전력망(utility grid) — 전력회사에서 오는 주 전원. 데이터센터는 보통 두 개 이상의 독립된 전력망에서 전기를 공급받는다(이중화). 하나가 끊겨도 다른 하나로 버틴다.

ATS(Automatic Transfer Switch) — 주 전원이 끊기면 — 자동으로 백업 전원(발전기)으로 전환하는 스위치. 전환 시간은 수 초. 이 수 초 동안의 전력을 UPS가 메운다.

UPS(Uninterruptible Power Supply, 무정전 전원 장치) — 대용량 배터리. 상용 전력이 끊기고 발전기가 시작되는 수 초 동안 — 서버에 끊김 없이 전력을 공급한다. 비유하자면 — 자동차의 예비 배터리. 시동이 꺼질 뻔한 순간에 잠깐 버티는 것.

디젤 발전기(generator) — 상용 전력이 장기적으로 끊겼을 때의 백업. 디젤 연료를 태워 전기를 만든다. 보통 24 ~ 72시간분의 연료를 비축한다. 허리케인 샌디 때 Datagram의 발전기가 침수돼서 — 발전기가 있어도 못 썼다(물리적 위협의 현실).

PDU(Power Distribution Unit, 전력 분배 장치) — UPS에서 온 전력을 각 랙에 분배. 랙마다 PDU가 있고, 서버의 전원 코드가 PDU에 꽂힌다. PDU는 각 랙의 전력 사용량을 모니터링할 수 있다(smart PDU).

전력 계층	역할	이중화 수준
상용 전력망	주 전원	2개 이상의 독립 라인
ATS	주/백업 전환	자동 전환
UPS	순간 정전 방지	N+1 또는 2N
발전기	장기 정전 대비	N+1
PDU	랙별 전력 분배	랙마다 A/B 이중화

랙의 A/B 전원 이중화가 중요하다 — 서버는 보통 두 개의 전원 공급 장치(PSU)를 갖고, 하나는 PDU-A에, 다른 하나는 PDU-B에 꽂는다. PDU-A가 죽어도 PDU-B로 서버가 살아있는다. foundations 04의 active-active 패턴의 물리적 버전이다.

냉각 — 서버가 뿜는 열을 식힌다

서버는 전기를 쓰면서 열을 발생시킨다. CPU 350W + GPU 400W + 메모리 + 디스크 + NIC = 서버 한 대당 보통 500W ~ 1kW. 랙 하나(40대 서버)는 20 ~ 40kW. 이 열을 그대로 두면 — 서버 온도가 90도 이상 올라가고, CPU가 스로틀링하고, 결국 타버린다.

데이터센터 냉각의 기본 원리는 — 열을 서버에서 밖으로 옮기는 것. 여러 방식이 있다.

CRAC(Computer Room Air Conditioning) — 데이터센터용 대형 에어컨. 바닥 밑의 공기 공급 플레넘(supply plenum) 에서 찬 공기를 올려보내고, 천장 근처에서 따뜻한 공기를 빨아들인다. 가장 전통적인 방식.

핫/콜드 애일(hot aisle / cold aisle containment) — 서버 랙을 줄지어 세울 때, 서버 앞면(차가운 공기 흡입)이 서로 마주보게 하고(콜드 애일), 뒷면(따뜻한 공기 배출)이 서로 마주보게 한다(핫 애일). 찬 공기와 따뜻한 공기가 섞이지 않게 해 — 냉각 효율을 높인다. 비유하자면 — 에어컨 바람길과 난방기 열길을 분리하는 것.

           천장 (열 배출)
    ┌───┐ ← ┌───┐ ← ┌───┐
    │서버│   │서버│   │서버│    핫 애일 (따뜻한 공기)
    │서버│   │서버│   │서버│
    └───┐   └───┐   └───┐
        │       │       │
    ┌───┘   ┌───┘   ┌───┘
    │서버│   │서버│   │서버│    콜드 애일 (찬 공기)
    │서버│   │서버│   │서버│
    └───┘ → └───┘ → └───┘
           바닥 (찬 공기 공급)

액체 냉각(liquid cooling) — 공기 대신 액체(물·불활성 액체)로 서버를 식히는 방식. 공기보다 액체가 열을 훨씬 잘 흡수한다(비열이 4배). AI 서버(GPU 8개, 랙당 100kW+)는 공기 냉각으로 감당이 안 돼서 — 액체 냉각이 필수가 되고 있다. 두 가지 방식:

• Direct-to-chip — 서버 안에 물파이프를 직접 연결. CPU·GPU에 콜드 플레이트(냉각판)를 붙여 열을 물로 옮김.
• 침수형(immersion) — 서버 전체를 불활성 액체 통에 담근다. 가장 효율적이지만 — 설비 비용이 크다.

PUE — 데이터센터의 에너지 효율 지표

PUE(Power Usage Effectiveness) 는 — 데이터센터의 에너지 효율을 나타내는 대표 지표다. PUE = 총 전력 소비 / IT 장비 전력 소비.

• 총 전력 = IT 장비(서버·네트워크·스토리지) + 냉각 + 조명 + 기타
• IT 장비 전력 = 서버·스위치·라우터가 실제로 소비하는 전력

PUE가 1.0이면 — 모든 전력이 IT 장비에만 쓰인다는 뜻(이상적, 현실적으로 불가능). PUE가 2.0이면 — 서버에 1W를 쓰기 위해 냉각·기타에 추가로 1W를 쓴다는 뜻(비효율적).

PUE	등급	전형 데이터센터
1.0 ~ 1.2	매우 효율적	Google 최신 DC, Meta
1.2 ~ 1.5	효율적	최신 하이퍼스케일 DC
1.5 ~ 2.0	보통	일반 기업 DC
2.0+	비효율적	구형 DC, 소규모 서버실

Google의 평균 PUE는 1.1 ~ 1.12(전력의 90%+ 가 IT에 쓰임). 이는 — 바깥 공기가 차가운 지역(핀란드·아일랜드)에서 자연 냉각(free cooling) 을 쓰고, 핫/콜드 애일을 철저히 분리하고, AI로 냉각을 최적화한 결과다.

랙과 TIA-924 — 표준화된 물리 구조

서버는 랙(rack, 19인치 표준) 에 장착된다. 랙은 높이를 U(rack unit, 1U = 4.445cm) 로 잰다. 1U 서버는 얇고(4.4cm), 2U 서버는 두 배 두께(8.9cm). 랙 하나는 보통 42U ~ 52U 높이다. 1U 서버를 42대 꽂거나, 2U 서버를 21대 꽂을 수 있다.

TIA-924 는 — 미국 통신산업협회(TIA)의 데이터센터 설계 표준이다. 랙 배치·케이블 경로·전력·냉각 공조·보안 구역을 표준화한다. 주요 권장사항:

• 랙은 핫/콜드 애일 배치(앞면이 콜드 애일, 뒷면이 핫 애일)
• 케이블은 상부(오버헤드 케이블 트레이) 또는 하부(플로어 케이블 트레이)로 정리
• 전력 케이블과 데이터 케이블을 분리(간섭 방지)
• 랙당 전력 밀도를 설계 단계에서 계획(냉각 용량과 맞춤)

Tier 등급 — 데이터센터의 가용성 등급

Uptime Institute의 Tier 등급은 — 데이터센터의 가용성(전력·냉각의 이중화 수준)을 4단계로 분류한다. foundations 02에서 본 "9의 법칙"과 연결된다 — 높은 Tier가 더 높은 가용성을 보장하지만, 비용이 기하급수한다.

Tier	이름	이중화 수준	가용성 목표	연간 다운타임
I	Basic	없음 (단일 경로)	99.671%	~28.8시간
II	Redundant	N+1 (부분 이중화)	99.741%	~22.0시간
III	Concurrently Maintainable	N+1 (유지보수 중에도 운영)	99.982%	~1.6시간
IV	Fault Tolerant	2N (완전 이중화)	99.995%	~26분

• Tier I — 단일 전력 경로, 냉각 경로. 정전 시 데이터센터 전체가 다운. 소규모 서버실 수준.
• Tier II — 전력·냉각에 N+1 이중화. 하나가 죽어도 버티지만, 유지보수 시에는 다운.
• Tier III — 유지보수를 위해 한 경로를 빼도 — 서비스가 중단되지 않음(concurrently maintainable). 대부분의 상용 데이터센터가 이 등급.
• Tier IV — 완전 이중화(2N). 어떤 단일 장애(전력·냉각·화재)로도 서비스가 중단되지 않음(fault tolerant). 금융·의료·정부용.

리전과 AZ — 클라우드의 물리적 경계

클라우드(AWS·GCP·Azure)는 — 전 세계에 데이터센터를 두고, 그것을 리전(region) 과 가용 영역(AZ, Availability Zone) 으로 묶는다.

리전 — 지리적으로 분리된 데이터센터 클러스터. AWS의 us-east-1(버지니아)·ap-northeast-2(서울)·eu-west-1(아일랜드) 같은 단위. 리전 간에는 — 지연이 크고(수십 ~ 수백 ms), 전송 비용이 든다. 리전은 — 법적 규제(GDPR: "EU 데이터는 EU 리전에")·재해 복구(지진·홍수)·지연 최소화(사용자와 가까운 곳)를 위해 나뉜다.

가용 영역(AZ) — 한 리전 안의 독립된 데이터센터(또는 데이터센터 클러스터). 각 AZ는 — 별도의 전력·냉각·네트워크를 갖는다. 한 AZ에 정전·화재가 나도 — 다른 AZ는 영향을 받지 않는다. foundations 03에서 본 "fault domain"의 클라우드 버전이다. AWS 한 리전은 보통 3 ~ 6개의 AZ를 갖는다.

flowchart TD
    REGION["리전 (예: ap-northeast-2 서울)"] --> AZ_A["AZ-A<br/>(데이터센터 1)"]
    REGION --> AZ_B["AZ-B<br/>(데이터센터 2)"]
    REGION --> AZ_C["AZ-C<br/>(데이터센터 3)"]
    AZ_A --> RACK_A["랙들<br/>(독립 전력·냉각)"]
    AZ_B --> RACK_B["랙들<br/>(독립 전력·냉각)"]
    AZ_C --> RACK_C["랙들<br/>(독립 전력·냉각)"]

사용자가 "EC2 인스턴스를 3개 AZ에 분산 배포"하면 — foundations 04에서 본 redundancy의 물리적 실천이 일어난다. 한 AZ의 데이터센터가 불타도 — 다른 AZ의 인스턴스가 서비스를 유지한다.

물리 보안 — 데이터센터의 성벽

데이터센터는 — 물리적 침입으로부터도 보호돼야 한다. 서버에 물리적으로 접근하면 — 디스크를 빼가거나, 키보드를 꽂거나, 관리자 권한을 탈취할 수 있다. 클라우드 벤더의 물리 보안:

• 경계 울타리·감시 카메라·보안 요원 — 데이터센터 외곽
• 매트랩(mantrap) — 출입구의 이중문 시스템. 첫 번째 문이 닫혀야 두 번째 문이 열림. 뒤따라 들어오는 것(tailgating) 방지.
• 생체 인증 — 지문·홍채 인식. 카드만으로는 출입 불가.
• 24시간 보안 요원 — 현장 상주
• 서버 랙 잠금 — 랙마다 별도 잠금장치. colocation에서는 고객이 자물쇠를 씀

환경 영향 — 데이터센터의 탄소 발자국

데이터센터는 전기를 많이 쓴다. 전 세계 데이터센터 전력 소비는 — 2024년 기준 약 460TWh로, 전 세계 전력 소비의 약 2%. AI 붐으로 GPU 데이터센터가 늘면서 — 2030년에는 1000TWh 이상으로 예측된다. 이는 — 프랑스 전체 전력 소비에 맞먹는 양이다.

전기를 어떻게 만드느냐가 탄소 배출을 결정한다:

• 화력 발전(석탄·천연가스) — 탄소 배출 높음. 전력이 싸지만 환경 부담이 큼.
• 재생 에너지(태양·풍력·수력) — 탄소 배출 낮음. Google·Meta·Amazon이 — 재생 에너지 사용을 목표로 함(100% 재생 에너지, carbon-free energy).
• 원자력 — 탄소 배출이 낮지만 방사능 폐기물 문제. AWS가 원자력 SMR(Small Modular Reactor) 도입을 검토 중.

데이터센터 입지 선택이 에너지 비용·환경 영향에 큰 차이를 만든다. 아이슬란드·노르웨이·핀란드는 — 풍력·수력으로 만든 싸고 깨끗한 전기 + 자연 냉각(바깥 공기가 차가움)을 제공한다. Google이 핀란드 하미나에 데이터센터를 지은 이유가 — 발트해의 차가운 물로 냉각하고, 풍력으로 전기를 만들기 때문이다. Facebook(현 Meta)이 스웨덴 룰레오에 지은 이유도 같다 — 북극권 근처라 1년 중 반을 자연 냉각으로 버틴다. 이 입지 선택 하나로 — PUE가 1.1 이하가 된다.

물 사용도 환경 영향의 큰 부분이다. 증발식 냉각탑(evaporative cooling tower)은 — 막대한 물을 소비한다. 구글의 전체 데이터센터 연간 물 사용량은 — 수십억 갤런에 달한다. 가뭄이 심한 지역(캘리포니아·애리조나)에서 데이터센터를 짓는 건 — 지역 사회와의 물 분쟁을 만든다. 최근에는 — 공기 냉각(dry cooling)이나 해수 냉각(해안 데이터센터)으로 물 사용을 줄이는 추세다.

실습 — 데이터센터 관련 직접 확인

1. 클라우드 인스턴스의 AZ 확인

# AWS CLI로 인스턴스의 AZ 확인
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,Placement.AvailabilityZone]' --output table 2>/dev/null

확인할 것: 각 인스턴스의 AZ(ap-northeast-2a 등). 같은 리전의 서로 다른 AZ에 분산돼 있으면 — foundations 04의 multi-AZ redundancy가 실천되고 있는 것.

2. 서버의 온도 확인 (베어메탈 또는 센서가 있는 VM)

# CPU 온도 (lm-sensors 설치 시)
sensors 2>/dev/null | grep -i 'core\|temp' || echo "sensors 미설치 (apt install lm-sensors)"
# 또는 /sys에서
cat /sys/class/thermal/thermal_zone*/temp 2>/dev/null | awk '{print $1/1000 "°C"}'

확인할 것: CPU 온도가 40 ~ 70도면 정상. 80도 이상이면 — 냉각 문제(서버 팬 고장·랙 온도 상승).

3. UPS 상태 (UPS가 연결된 베어메탈)

# Network UPS Tools (nut)가 설치된 경우
upsc ups@localhost 2>/dev/null | grep -E 'battery\|input\|ups.status' || echo "UPS 모니터링 미설정"

확인할 것: ups.status: OL(온라인, 정상). OB(온 배터리, 정전). battery.charge: 100(배터리 100%).

4. 전력 사용량 확인 (IPMI/Redfish가 있는 베어메탈)

# IPMI로 전력 사용량 확인
sudo ipmitool dcmi power reading 2>/dev/null | head -5 || echo "IPMI 미지원"

확인할 것: Instantaneous power reading: 350 Watts 같은 현재 전력 소비. 서버가 얼마나 전기를 먹는지 직접 확인.

미검증: sensors·upsc·ipmitool은 별도 설치 필요. 클라우드 VM은 가상화돼 물리 센서에 접근이 제한됨. AWS/GCP의 물리 시설 정보는 콘솔이나 API로 확인(AZ 위치·리전별 서비스).

데이터센터는 클라우드의 "물리적 기반"이다

허리케인 샌디로 돌아가자. 2012년 그 사건 이후 — 클라우드 벤더와 데이터센터 운영자는 물리 시설의 이중화를 훨씬 심각하게 받아들였다. AWS·Google·Meta는 — 각 AZ의 전력·냉각이 완전히 독립되도록 설계하고, 재해 위험이 낮은 지리적 위치를 선정하고, 자연 냉각을 쓰기 위해 북유럽에 데이터센터를 짓는다. 사용자가 보는 "리전 선택" 드롭다운 메뉴 하나가 — 이 물리적 인프라의 차이를 반영한다.

데이터센터를 이해하면 — foundations 03에서 본 fault domain의 물리적 기반, foundations 04에서 본 redundancy의 물리적 실천, foundations 05에서 본 build-vs-buy(TCO의 전력·냉각 비용)이 — 모두 이 물리 시설에서 출발한다는 걸 알 수 있다. 클라우드의 EC2 인스턴스 가격이 리전마다 다른 이유도 — 각 리전의 전력 비용·부동산 비용·냉각 비용이 다르기 때문이다. "인프라는 결국 전기·냉각·건물"이라는 물리적 사실을 잊으면 — 클라우드의 가격·성능·한계를 이해할 수 없다.

클라우드는 결국 — 전 세계에 지은 데이터센터라는 건물과 그 안의 서버를 — API로 빌려주는 것이다. 그리고 그 API 뒤의 물리적 기반을 이해하는 엔지니어가 — 어느 리전을 선택할지, 어떤 인스턴스 타입을 쓸지, 비용을 어떻게 최적화할지를 더 잘 결정한다.

다음 글에서는 이 데이터센터 안의 네트워크 구조를 다룬다 — DC 네트워크 토폴로지. 3-tier(access·aggregation·core)에서 spine-leaf(Clos)로의 진화가 — 왜 일어났고 무엇을 바꿨는지.

Colocation vs 자체 데이터센터 vs 클라우드

데이터센터를 "갖는" 방법은 세 가지다. foundations 05에서 본 build-vs-buy가 물리 시설에 적용된다.

자체 데이터센터(owned) — 자기 땅에 데이터센터를 짓는다. 가장 높은 통제력, 하지만 초기 투자가 수백억 원 이상. Google·Meta·AWS 같은 하이퍼스케일 벤더만 현실적.

Colocation(코로케이션) — Equinix·Digital Realty 같은 전문 데이터센터 운영사의 건물에 자기 서버를 놓는 것. 전력·냉각·보안은 운영사가 제공, 서버와 네트워크는 자기가 관리. 랙당 월 비용을 낸다. 중간 규모 기업의 선택지.

클라우드(cloud) — 서버 자체도 빌린다. 데이터센터는 클라우드 벤더가 소유하고 운영. 가장 낮은 통제력이지만 가장 낮은 진입 장벽.

방식	초기 비용	통제력	확장성	적합 규모
자체 DC	수백억+	최고	제한적	하이퍼스케일 (Google, Meta)
Colocation	랙당 월 비용	중간	중간	중대형 기업
클라우드	사용량 기반	낮음	최고	모든 규모

---

참고

• TIA-924, "Telecommunications Infrastructure Standard for Data Centers", Telecommunications Industry Association, 2014 — 데이터센터 설계 표준. 접근 2026-07-21
• Uptime Institute, "Data Center Site Infrastructure Tier Standard: Topology", 2012 — Tier I ~ IV 등급 정의. 접근 2026-07-21
• Google, "Efficiency: How we do it" — Google 데이터센터 PUE 데이터. 접근 2026-07-21. URL: https://www.google.com/about/datacenters/efficiency/
• Shehabi, A. et al. "United States Data Center Energy Usage Report", LBNL, 2016/2024 — 데이터센터 에너지 소비 연구. 접근 2026-07-21
• AWS, "AWS Global Infrastructure" — 리전·AZ 구조. 접근 2026-07-21. URL: https://aws.amazon.com/about-aws/global-infrastructure/
• ASHRAE TC 9.9, "Thermal Guidelines for Data Processing Environments", 5th ed, 2021 — 데이터센터 온도·습도 가이드라인. 접근 2026-07-21
• Miller, R. "Data Center Knowledge" — 데이터센터 산업 뉴스·분석. 접근 2026-07-21
• McCarthy, N. "Hurricane Sandy and the Data Center Industry", Data Center Knowledge, 2012 — 허리케인 샌디 데이터센터 영향. 접근 2026-07-21