미니 데이터센터 구축 — 10인치 랙에 짓는 AI 팩토리

왜 짓는가 — 계산이 손에 닿는 크기로

이 과목의 모든 장은 계산으로 끝났다. 랙이 190 kW 를 먹는다, 링크가 2,048개 필요하다, 토큰 100만 개에 600원이다 — 다 맞는 말이지만 손으로 만져 본 적이 없다. 미니 데이터센터는 그 계산을 만질 수 있는 크기로 줄인 것이다.

축척 — 무엇이 몇 배 차이인가

배수가 항목마다 다르다는 것 자체가 교보재다. 전력은 330배인데 메모리는 78배다. 이 어긋남이 곧 「랙 밀도가 왜 전력 문제로 귀결되는가」의 답이다 — 11장에서 계산한 그대로다.

자재 명세 — 무엇을 왜 골랐는가

부품 목록은 결론이 아니라 논증의 요약이다. 아래 표의 「고른 이유」 칸이 이 절의 본체다.

공간 — 12U 를 어떻게 나눌 것인가

공간 설계는 아래에서 위로 한다. 무겁고 뜨겁고 위험한 것이 아래다. 이 원칙은 190 kW 랙이든 0.8 kW 랙이든 같다.

전력 — 0.81 kW 의 계통을 설계한다

전력은 더하기부터 한다. 11장에서 랙 전력을 계산한 것과 완전히 같은 순서다.

「피크」와 「실사용」은 다르다. 위 표는 전부 최대치를 더한 값이라 실제로는 절반쯤인 0.4 kW 근처에서 돈다. 그런데 회로는 피크로 잡아야 한다 — 15장에서 가동률을 다룰 때와 정반대의 방향이다. 용량 산정은 피크로, 원가 계산은 평균으로 한다.

회로 — 콘센트 하나로 되는가

설계 부하        0.81 kW
콘센트 회로      220 V x 16 A = 3.52 kW  (국내 일반 분기회로)
연속부하 규정    정격의 80% 까지 = 2.82 kW

    0.81 / 2.82 = 29%   →  콘센트 하나로 충분하다.

그런데 「충분하다」의 뜻을 확인해 둔다:
    - 같은 회로에 전기포트(2 kW)를 꽂으면 2.81 kW → 한계선이다
    - 강의실 배선은 여러 콘센트가 한 분기회로를 공유하는 경우가 많다
    → 두꺼비집에서 이 랙이 어느 차단기에 물려 있는지 확인하고 표시해 둔다

UPS — 무엇을 사는 물건인가

UPS 는 정전을 버티는 장비가 아니다. 0.8 kW 를 몇 시간 버티려면 자동차 배터리만 한 것이 필요하고, 그건 이 랙의 목적이 아니다. UPS 가 사 주는 것은 정상 종료할 시간이다.

보호할 부하를 먼저 정한다 (전부 보호하지 않는다)
    미니 PC 4대           120 W   ← 상태를 가진 기계. 갑자기 끊기면 DB가 깨진다
    스위치 2대 + 방화벽    44 W   ← 이게 죽으면 종료 명령도 못 보낸다
    스토리지               32 W   ← 쓰기 도중 정전이 가장 위험하다
    ------------------------------
    보호 부하             196 W
    DGX Spark 2대       (480 W)   ← 보호하지 않는다. 상태가 없고, 용량이 안 나온다

UPS 용량 (여기서 학생 절반이 틀린다)
    600 VA UPS 의 유효 출력 = 600 VA x 역률 0.6 = 360 W
    ※ VA 와 W 는 같지 않다. 카탈로그 앞 숫자는 VA 다.
    196 W / 360 W = 54%  →  용량은 충분

런타임
    배터리 12 V x 7 Ah = 84 Wh
    실사용 가능분 (방전 심도 50%, 인버터 효율 85%)
        84 x 0.5 x 0.85 = 35.7 Wh
    35.7 Wh / 196 W = 0.18 h = 약 11분

    → 11분 안에 순서대로 끄면 된다. 그 순서가 19장의 런북이다.

측정 — 계측하지 않는 것은 운영할 수 없다

18장에서 붙인 센서가 19장 시나리오의 입력 전부다. 전력계 하나, 온습도 4점, 도어 센서 하나. 그것으로 충분하고, 그것 없이는 아무것도 안 된다.

센서를 고르는 기준은 정확도가 아니라 「내가 잡으려는 변화보다 오차가 작은가」다. 15장에서 관측을 다룰 때 「무엇을 재는지 정하고 나서 도구를 고른다」고 한 것의 가장 작은 실례가 이 두 모듈의 차이다.

냉각 — 왜 우리는 팬만으로 되는가

11장에서 랙 190 kW 는 공랭이 불가능하다고 했다. 그러면 어디까지가 공랭인가? 그 경계를 계산으로 확인한다.

강의실이 완전히 밀폐돼 있다고 가정하고, 우리 랙이 방을 얼마나 데우는지 본다.

    발열       0.81 kW = 0.81 kJ/s   (전기는 결국 전부 열이 된다)
    방 부피    60 m2 x 2.7 m = 162 m3
    공기 질량  162 m3 x 1.2 kg/m3 = 194 kg
    공기 비열  1.005 kJ/(kg K)

    시간당 온도 상승 = 0.81 x 3600 / (194 x 1.005)
                     = 2916 / 195
                     = 약 15 C/h

같은 방에 190 kW 랙을 넣으면
    190 x 3600 / 195 = 약 3,500 C/h  →  1분에 58 C

    → 공조가 멈춘 순간부터 몇 분 안에 장비가 죽는다.
      13장 시나리오 ENV-01(CRAC 정지)이 「90초 후 GPU 스로틀」인 이유가 이 숫자다.

네트워크 — 존을 물리로 강제한다

9장에서 「모든 트래픽은 검사 지점을 지난다」고 했고, 19장의 보안 시나리오 전부가 그 성질에 기대고 있다. 그러니 우회로가 없도록 물리적으로 만들어야 한다.

두 스위치와 트렁크

물리 배선

    [스위치 A] ── VLAN 50 (app) 만 다룬다
       ├ DGX Spark 01     10.20.50.10
       ├ DGX Spark 02     10.20.50.11
       ├ Pi 5 x4          10.20.50.21~24
       └ 트렁크 ─────────────┐
                             │  Cat6 2가닥 (이중화)
    [스위치 B] ── 나머지 전부 ┘
       ├ VLAN 30/31/32/40/60
       ├ 미니 PC x4
       ├ 방화벽 (VLAN 30,31 양다리)
       └ IPS     (VLAN 31 ↔ 32/50/60)

존을 건너는 길은 이것뿐이다:

    ext --fw--> pipe --ips--> dmz --web(WAF)--> int
                  |
                  +--ips--> app     (연산 트래픽도 여기를 지난다)
                  +--ips--> ot      (tcp/8000, ICMP 만)

배선 규칙 — 색과 라벨이 문서다

DGX Spark 두 대를 묶으면 무엇이 되는가

이 절이 18장에서 가장 중요하다. 8장과 12장에서 세운 규칙이 실제 장비 두 대에서 그대로 성립하는지 확인하는 자리이기 때문이다.

토큰 하나를 만들려면 어차피 전체 레이어를 통과해야 한다.

    1대:  70 GB / 273 GB/s = 0.256 s   →  3.9 tok/s
    2대(PP):  Spark1 이 35 GB 읽고(0.128 s)
              → 활성화를 넘기고(수 ms)
              → Spark2 가 35 GB 읽는다(0.128 s)
              합계 0.256 s + 통신  →  3.9 tok/s 보다 오히려 조금 느리다

    파이프라인 병렬은 「한 요청을 빠르게」가 아니라
    「마이크로배치를 흘려 넣어 처리량을 올리는」 방법이다.
    12장의 버블 그림이 말하던 것이 정확히 이것이다.

그래서 무엇을 올릴 수 있나 (14장 적재 판정의 실제 적용)

맨 아래 줄이 중요하다. 405 B 가 「올라간다」는 것과 「서비스할 수 있다」는 것은 다르다. 1.3 tok/s 는 한 문장을 만드는 데 1분이 걸린다는 뜻이다. 3장에서 DGX Spark 를 처음 소개할 때 한 말이 여기서 실물로 확인된다 — 이 장비는 기능 검증용이지 서빙용이 아니다.

라즈베리파이 4대 — 클라우드를 흉내내는 최소 단위

Pi 5 네 대로 성능을 얻으려는 것이 아니다. 대수를 얻으려는 것이다. 「노드가 죽으면 파드가 다른 노드로 옮겨간다」는 것을 눈으로 보려면 노드가 여럿이어야 한다.

노드 구성 (4대)

    pi-01   control-plane + etcd + worker    10.20.50.21
    pi-02   control-plane + etcd + worker    10.20.50.22    ← HA 는 홀수여야 한다
    pi-03   control-plane + etcd + worker    10.20.50.23
    pi-04   worker                           10.20.50.24

    etcd 쿼럼 = 3대 중 2대.  한 대가 죽어도 클러스터가 산다.
    → 19장 FLT 시나리오에서 pi-01 을 죽여도 서비스가 유지되는 근거가 이 구성이다.

무엇을 올리나

    관측 스택        Prometheus · Grafana · Loki      (19장의 화면 전부)
    레지스트리       Harbor 또는 registry:2           (모델·이미지 보관)
    잡 큐            Redis + 워커                      (추론 요청 큐)
    데모 서비스      의도적으로 취약한 웹앱             (보안 실습 대상)

    ※ 추론 자체는 여기서 하지 않는다. DGX Spark 가 한다.
      Pi 는 「그 앞뒤를 다루는 층」이다 — 라우팅·큐·관측·저장.

이 구성이 13장의 P/D 분리와 닮은 것은 우연이 아니다. 무거운 연산은 전용 하드웨어에, 그 앞뒤의 조율은 값싼 범용 노드에 — 분리 서빙의 발상이 그대로 하드웨어 배치가 된 것이다.

외장 SSD 를 서버 스토리지처럼 쓰기

10장에서 스토리지를 네 계층으로 나눴다. 이 랙에서는 그 계층이 핫(NVMe)과 콜드(외장 SSD) 둘로 압축된다. 줄인 이유와 남긴 이유를 분명히 해 둔다.

무엇으로 공유할 것인가

3-2-1 을 이 랙에서 성립시키기

3 벌   원본(NVMe) + 백업(외장 SSD) + 원격(학교 스토리지 또는 클라우드)
2 매체 NVMe 와 USB SSD — 컨트롤러도 인터페이스도 다르다
1 벌   랙 밖에 — 랙이 통째로 없어지는 경우를 상정한다

지키지 못하면 무엇이 무너지는가:
    - 2매체를 안 지키면 → 같은 펌웨어 버그로 두 벌이 동시에 죽는다
    - 1벌을 랙 밖에 안 두면 → 화재·도난·침수에서 전부 잃는다
      (2022년 판교 화재가 정확히 이 항목이었다 — 16장 참조)

19장 INC-08(백업 실패 3일간 미탐지)이 검증하는 것은
「백업을 하는가」가 아니라 「백업이 되고 있음을 아는가」다.

소프트웨어 배치 — 어느 기계에 무엇을 올리나

미니 PC 네 대는 역할이 다르다. 한 대에 몰지 않는 이유는 성능이 아니라 고장을 구분하기 위해서다. 계통이 섞이면 「무엇이 죽었는가」를 물을 수 없다.

두 저장소가 겹치는 곳과 갈라지는 곳

배치 요약

  랙 A (app 존)
    DGX Spark 01/02   추론 서빙 (Ollama / vLLM), 파인튜닝
    Pi 5 x4 (k3s)     관측 스택 · 레지스트리 · 큐 · 데모 서비스
    NVMe x4           모델 · 이미지 · KV 오프로드

  랙 B (mgmt / ot 존)
    미니PC 1  SOC       kt66 보안 스택        (fw, ips, web, vuln x6, wazuh)
    미니PC 2  DC-OPS    kt66 시설·관제 스택   (envsim, noc, injector, portal)
    미니PC 3  AGENT     dawnofagi 에이전트     (harness, aoc, gate compiler)
    미니PC 4  COMPANY   dawnofagi 가상회사     (pixel-office, portal, biz)
    방화벽              OPNsense — 존 사이의 유일한 길
    외장 SSD x4         백업 · 증적

  랙을 건너는 연결
    DGX Spark 는 app 존의 정식 구성원이다 (10.20.50.10/11).
    그 트래픽도 ips 를 지난다 — 우회로를 만들지 않는다.

구축 절차 — 순서가 곧 설계다

순서를 지키는 이유는 되돌리기 위해서다. 전원부터 넣고 나중에 배선을 정리하려 하면, 문제가 났을 때 어느 단계에서 생겼는지 알 수 없다.

1. D-3 · 검수와 채번. 도착한 물건을 개봉해 수량·외관을 확인하고 모든 장비에 자산번호와 라벨을 붙인다. 이때 붙이지 않으면 영원히 안 붙인다.
2. D-2 · 사전 구성. 랙에 넣기 전에 책상에서 OS·펌웨어·SSH 키를 끝낸다. 랙 안에서는 화면도 키보드도 붙이기 어렵다.
3. D-1 · 공간 배치. 선반과 레일부터 다 조립한 뒤 장비를 올린다. 아래에서 위로 — 위쪽 장비를 먼저 달면 아래를 조일 수 없다.
4. D-day 오전 · 전력. PDU → UPS → 각 장비 순으로 결선하고, 전원을 넣기 전에 전류계로 무부하 상태를 확인한다. 그다음 한 채널씩 켜면서 소비 전력을 기록한다 — 이 표가 나중에 기준선이 된다.
5. D-day 오후 · 네트워크. 패치 패널부터 배선하고 색·라벨 규칙을 지킨다. VLAN 을 올린 뒤 존 사이가 실제로 막혀 있는지 먼저 확인한다 — 통하는 것을 확인하기 전에 막힌 것을 확인한다.
6. D+1 · 소프트웨어. kt66 → dawnofagi 순. kt66 이 먼저인 것은 dawnofagi 가 그 위에서 관측되어야 하기 때문이다.
7. D+2 · 기준선 측정. 무부하·평시·최대부하 세 상태에서 전력·온도·대역폭·응답시간을 잰다. 19장의 모든 「이상」은 이 기준선과의 차이로 정의된다.

검수 체크리스트 — 이것이 통과해야 「구축 완료」다

참고 자료

• DeskPi RackMate T2 제품 사양 — 10인치 12U, 280x260x590 mm
• NVIDIA DGX Spark 사양 — GB10, 128 GB, 150x150x50.5 mm, 240 W
• Raspberry Pi 5 제품 문서 — PCIe 2.0 x1, M.2 HAT
• k3s 문서 — 경량 쿠버네티스, HA 구성
• mrgrit/kt66 — 4층 모델 · 존 체계 · envsim · injector · 시나리오 34종
• mrgrit/dawnofagi — L1~L4 제어 평면 · AOC · Experience Graph
• MinIO 문서 — S3 호환 오브젝트 스토리지
• 이 과목 11장(전력·냉각) · 8장(scale-up) · 12장(병렬화 배치) · 14장(용량 산정) — 이 장의 모든 계산이 그 장들에서 나왔다