Infra Architecture/Compute Platforms

Compute Platforms - 01. 서버 하드웨어 기초

dongka dongka ·

서버 한 대 안에는 무엇이 들어 있나 — 하드웨어 기초

2018년 1월, Google Project Zero는 두 개의 CPU 보안 취약점을 공개했다. Spectre와 Meltdown이다. 거의 모든 Intel·ARM·AMD CPU에 영향을 미치는 이 취약점의 치명적인 점은 — 소프트웨어 패치로 막으려면 CPU 성능이 5 ~ 30% 떨어진다는 것이었다. 전 세계 데이터센터의 서버들이 한순간에 느려졌다. 클라우드 고객은 자기 서비스가 갑자기 느려진 이유를 몰랐고, AWS·GCP·Azure는 수주에 걸쳐 유지보수를 진행하며 커널을 패치했다. 이 사건이 보여주는 것은 단순하다 — "하드웨어는 신뢰할 수 있다"는 통념이 틀렸다는 것. 그리고 더 중요하게는 — 하드웨어를 모르면 왜 이런 일이 일어나는지, 우리 서비스에 왜 영향이 가는지를 이해할 수 없다는 것. 인프라 엔지니어가 CPU의 캐시 구조·명령어 파이프라인·speculative execution(투기적 실행)을 알아야 하는 이유가 거기에 있다.

이 글은 compute platforms의 첫 글로, 인프라의 가장 밑바닥 — 서버 하드웨어를 다룬다. foundations에서 세운 어휘(품질 속성·fault domain·redundancy·TCO·IaC)를 전제로, 이제 그 결정들이 내려지는 물리적 기반을 본다. CPU·메모리·디스크·NIC이 무엇이고, 어떻게 서로 연결되며(PCIe), 왜 그 연결 구조가 성능·비용·장애 도메인을 결정하는지. 클라우드 EC2·GCE 인스턴스를 고를 때 "m6i.large와 m7g.large 중 어느 쪽이 싸고 왜 빠른가"라는 질문에 답하려면 이 하드웨어 층을 이해해야 한다.

CPU — 서버의 두뇌

CPU(Central Processing Unit)는 서버에서 연산을 담당하는 칩이다. 2026년 현재 서버용 CPU는 주로 Intel Xeon·AMD EPYC·ARM 기반(AWS Graviton·Ampere Altra)이다. CPU를 논할 때 보는 기본 수치들이 있다.

클럭(clock) — CPU가 초당 실행하는 사이클 수. 단위는 GHz(기가헤르츠, 10억 회/초). 현대 서버 CPU는 기본 클럭 2 ~ 4GHz, 부스트 클럭(짧은 순간 더 빨리) 3 ~ 5GHz로 동작한다. 클럭이 높으면 단일 스레드 작업이 빠르지만 — 전력 소비와 발열이 비선형으로 증가한다. 클럭을 10% 올리면 발열은 30% 이상 늘어나는 게 일반적이라, 서버 냉각 비용까지 같이 계산해야 한다.

코어(core) — CPU 안의 물리적 연산 장치. 8코어 CPU는 8개의 독립된 연산 유닛을 갖는다. 각 코어는 자체 레지스터·L1/L2 캐시를 갖고, 병렬로 다른 작업을 수행한다. 서버 CPU는 보통 16 ~ 128코어. AWS Graviton4는 최대 96코어, AMD EPYC 9005 시리즈는 최대 192코어. 코어 수가 많을수록 동시에 처리할 수 있는 작업(스레드)이 많아지지만, 코어 간 통신 비용과 메모리 대역폭이 병목이 될 수 있다.

스레드(thread) — 여기엔 두 가지 의미가 있다. 소프트웨어 스레드(OS가 스케줄링하는 실행 단위)와 하드웨어 스레드(CPU의 SMT, Simultaneous Multi-Threading)다. Intel은 이를 hyper-threading이라 부르고, AMD는 SMT라 부른다. 한 물리 코어가 두 개의 하드웨어 스레드를 처리하는 구조(SMT2)가 일반적 — 한 코어가 메모리를 기다리는 동안 다른 스레드의 명령을 실행해 활용도를 높인다. 그래서 "8코어 16스레드"라는 표현이 나온다. 다만 한 물리 코어의 두 스레드는 자원을 공유하므로, 16물리코어와 8물리코어 16스레드는 같지 않다. 클라우드의 vCPU는 보통 하드웨어 스레드 하나를 의미한다.

캐시(cache) — CPU 안의 빠른 메모리. L1(코어 전용, 수 KB, 1ns)·L2(코어 전용, 수백 KB, 3 ~ 5ns)·L3(LLC, Last Level Cache, 모든 코어 공유, 수십 MB, 10 ~ 20ns)로 계층화된다. 메모리 접근은 100ns가 넘으므로, 캐시 적중률(hit rate)이 성능을 좌우한다. Spectre/Meltdown은 바로 이 캐시를 side-channel로 공격해 다른 프로세스의 데이터를 읽어내는 기법이었다 — 캐시가 빠르기 때문에 생긴 부작용이다.

flowchart TD
    CORE[CPU 코어] --> L1["L1 캐시<br/>(전용, 1ns)"]
    L1 --> L2["L2 캐시<br/>(전용, 3~5ns)"]
    L2 --> L3["L3 캐시 (LLC)<br/>(공유, 10~20ns)"]
    L3 --> DRAM["메인 메모리 (DRAM)<br/>(100ns)"]
    DRAM --> SSD["디스크 (NVMe)<br/>(100,000ns = 100μs)"]

명령어 세트(ISA, Instruction Set Architecture) — CPU가 이해하는 명령어 모음. x86_64(Intel·AMD, CISC 계열)와 ARM(Arm Ltd, RISC 계열)이 양대 산맥이다. 같은 프로그램이라도 ISA가 다르면 다시 컴파일해야 한다. AWS Graviton이 ARM 기반인데, EC2에서 Graviton 인스턴스를 쓰려면 애플리케이션을 ARM용으로 빌드해야 한다. 그게 번거로울 것 같지만 — 최근엔 대부분의 언어와 프레임워크가 ARM 빌드를 지원하고, Graviton은 x86 대비 20 ~ 40% 비용 절감 효과가 있다. RISC-V는 오픈 ISA로, 향후 서버 CPU 시장의 변인이다.

TDP(Thermal Design Power) — CPU가 정상 부하에서 방출하는 열의 양(와트). Xeon은 205 ~ 350W, EPYC는 200 ~ 400W, Graviton은 80 ~ 120W로 ARM이 더 효율적이다. TDP가 높으면 냉각 비용이 올라간다. foundations 02에서 본 "비용 품질 속성"에서 전력·냉각 비용이 TCO의 큰 항목이라는 걸 떠올리자 — 같은 성능이라면 TDP가 낮은 쪽이 데이터센터 운영 비용이 싸다. ARM이 클라우드에서 점유율을 늘리는 핵심 이유다.

가상화 지원 — 하이퍼바이저가 CPU를 효율적으로 나눠 쓰기 위한 하드웨어 기능. Intel VT-x·AMD-V(AMD)가 CPU 가상화 명령어고, Intel EPT·AMD NPT(AMD-Vi)가 메모리 가상화(Nested Page Table)를 가속한다. 이 기능들이 없으면 하이퍼바이저가 소프트웨어로 같은 일을 해야 해서 느리다. 클라우드 인프라의 기반 — 가상화와 하이퍼바이저 글에서 다룰 전제 조건이다.

메모리 — CPU의 작업대

메인 메모리(RAM, Random Access Memory)는 CPU가 당장 쓰는 데이터를 두는 곳이다. 프로그램이 실행되려면 디스크에서 메모리로 올라와야 하고, CPU는 메모리에서만 데이터를 읽고 쓴다(캐시는 그 사이의 빠른 버퍼).

서버 메모리의 기본 단위는 DIMM(Dual In-line Memory Module)이다. 서버 메인보드에는 보통 8 ~ 32개의 DIMM 슬롯이 있다. DIMM은 채널(channel)로 CPU에 연결된다. 단일 채널·듀얼 채널·쿼드 채널·옥타 채널 — 채널이 많을수록 CPU와 메모리 사이의 대역폭(GB/s)이 넓어진다. EPYC는 12채널, Xeon Scalable은 8채널을 지원한다. DIMM을 슬롯에 고르게 분산해 채널을 다 채워야 대역폭이 최대가 된다 — 한 채널에만 4개 꽂고 나머지를 비우면 병목.

DDR 세대 — 현재 DDR4·DDR5가 주력이다. DDR5는 DDR4 대비 대역폭이 두 배(4800 ~ 6400 MT/s vs 3200 MT/s)고, 전압이 낮다(1.1V vs 1.2V). 2026년 현재 새 서버는 대부분 DDR5를 쓴다. ECC(Error Correcting Code) 는 메모리 비트 오류를 자동 교정하는 기능이다 — 서버 필수. 우주선·방사선·열 노화로 메모리 비트가 뒤집히는 일(single-bit error)은 생각보다 자주 일어나고, ECC가 없으면 데이터가 조용히 손상된다. Google의 2009년 연구("DRAM Errors in the Wild")에 따르면 실제 데이터센터 메모리의 연간 오류율은 수 %에 달한다.

HBM(High Bandwidth Memory) — GPU·AI 가속기에 쓰이는 특수 메모리. DRAM 칩을 수직으로 적층해 CPU/GPU와 가깝게 두어 대역폭을 극대화한다. NVIDIA H100 GPU는 80GB HBM3를 쓰고, 대역폭이 3TB/s에 달한다 — 일반 DDR5의 수십 배. AI 워크로드에서 메모리 대역폭이 핵심 병목이기 때문이다.

메모리의 두 가지 수치가 성능을 결정한다 — 대역폭(GB/s) 은 초당 옮길 수 있는 데이터 양이고, 지연(ns) 은 한 번 접근에 걸리는 시간이다. 둘은 다르다. 대역폭이 중요한 워크로드(데이터베이스 풀 스캔·AI 학습)와 지연이 중요한 워크로드(온라인 트랜잭션·게임 서버)는 다른 메모리 구성이 필요하다.

디스크 — 영속성의 층

디스크는 전원이 꺼져도 데이터가 살아 있는 비휘발성 저장 장치다. foundations 02의 "내구성" 품질 속성이 바로 이 층에서 결정된다.

형태 분류:

  • HDD(Hard Disk Drive) — 자성 플래터를 회전시켜 데이터를 저장하는 기계식 장치. 7200RPM·10K RPM·15K RPM 등 회전 속도로 성능을 가른다. 2026년 현재는 대용량 콜드 스토리지·백업에 주로 쓰이고, 핫 데이터는 SSD로 이관됐다. 단위당 가격(GB당)은 가장 싸지만, IOPS가 100 ~ 200 수준이라 트랜잭션 워크로드엔 안 맞는다.
  • SATA SSD — 플래시 메모리(NAND)를 쓰지만 SATA 인터페이스(직렬 ATA)로 연결. SATA 3.0의 대역폭 한계(600MB/s) 때문에 SSD의 실제 성능이 제한된다. IOPS 50,000 ~ 100,000 정도. 현재는 보급형 서버에 주로 쓰인다.
  • SAS SSD — 서버용 인터페이스(SAS, Serial Attached SCSI). SATA보다 신뢰성 높고 이중 포트(dual-port)를 지원하지만, 가격이 비싸고 대역폭은 12Gbps(약 1.2GB/s)로 SATA와 큰 차이가 없다.
  • NVMe SSD — PCIe 버스에 직접 연결된 SSD. SATA/SAS의 인터페이스 병목 없이 PCIe의 대역폭을 그대로 쓴다. PCIe 4.0 x4 기준 약 7GB/s, PCIe 5.0 x4 기준 약 14GB/s. IOPS는 100만 ~ 700만. 현대 서버의 기본.

NAND 유형 — 플래시 메모리 셀당 비트 수에 따라 SLC(1비트)·MLC(2비트)·TLC(3비트)·QLC(4비트)로 나뉜다. 셀당 비트가 많을수록 용량 대비 가격이 싸지만 — 내구성(쓰기 횟수)이 떨어진다. SLC는 수십만 번 쓸 수 있지만, QLC는 수천 번. 데이터베이스·로그처럼 쓰기가 빈번한 워크로드는 TLC 이상이 안전하고, 콜드 저장은 QLC도 가능. enterprise SSD는 OP(Over-Provisioning)로 내구성을 보강한다.

디스크의 세 가지 수치 — IOPS(초당 I/O 작업 수), 처리량(MB/s 또는 GB/s), 지연(μs 또는 ms). 이 세 값은 독립적이다. IOPS가 높아도 처리량이 낮을 수 있고(작은 블록), 처리량이 높아도 IOPS가 낮을 수 있다(큰 블록). 워크로드에 맞는 디스크를 고르려면 세 수치를 모두 봐야 한다.

디스크 종류 인터페이스 순차 읽기 IOPS (4KB 랜덤) 지연 전형 용도
HDD 7200RPM SATA/SAS 200MB/s 100 ~ 200 5 ~ 10ms 콜드 저장, 백업
SATA SSD SATA 3.0 550MB/s 50,000 ~ 100,000 100μs 보급형 서버
NVMe SSD (PCIe 4.0) PCIe 4.0 x4 7GB/s 500,000 ~ 1,000,000 10 ~ 20μs 일반 서버
NVMe SSD (PCIe 5.0) PCIe 5.0 x4 14GB/s 1,000,000 ~ 1,500,000 10μs 고성능 DB
Optane/3D XPoint (단종) PCIe 2.5GB/s 500,000 <10μs 저지연 캐시 (역사적)

NIC — 네트워크 입출력

NIC(Network Interface Card)은 서버를 네트워크에 연결하는 장치다. network fundamentals 영역에서 다룰 패킷이 이 NIC을 통해 들어오고 나간다. 서버 NIC의 속도는 1Gbps·10Gbps·25Gbps·100Gbps·400Gbps로 발전해 왔다. 현대 데이터센터 서버는 보통 10G ~ 100G NIC을 장착하고, 고성능 워크로드(AI 클러스터·스토리지 백엔드)는 400G NIC을 쓴다.

NIC의 성능 수치 두 가지가 있다. 대역폭(bps, bits per second) 은 초당 보낼 수 있는 비트 수이고, pps(packets per second) 은 초당 처리할 수 있는 패킷 수다. 10Gbps NIC이라도 작은 패킷(64바이트)을 처리할 때는 pps가 병목이 되어 대역폭을 못 채운다. 64바이트 패킷으로 10Gbps를 채우려면 초당 약 1,488만 패킷이 필요한데, 일반 NIC은 그 pps를 못 버틴다. 이게 foundations 02에서 본 "대역폭 vs pps" 함정의 물리적 기반이다.

NIC 오프로드(offload) — CPU가 하던 네트워크 작업을 NIC이 대신하는 기능. TCP 체크섬 계산·TSO(TCP Segmentation Offload)·LRO(Large Receive Offload)가 대표적. 이 기능들이 있으면 CPU는 더 빠르고 NIC이 효율이 좋다.

고급 NIC 기능 — 데이터센터와 클라우드에서 더 중요해진 기능들:

  • SR-IOV(Single Root I/O Virtualization) — 한 NIC을 여러 가상 머신에 직접 할당. 하이퍼바이저를 거치지 않아 성능이 좋다. 클라우드의 "enhanced networking"이 이 기술.
  • DPDK(Data Plane Development Kit) — 사용자 공간에서 패킷을 처리해 커널 오버헤드를 없애는 프레임워크. 고성능 라우터·방화벽·LB 소프트웨어가 쓴다.
  • RDMA(Remote Direct Memory Access) — 한 서버의 메모리를 네트워크를 통해 다른 서버가 CPU 개입 없이 직접 읽고 쓰는 기술. InfiniBand·RoCE(RDMA over Converged Ethernet)가 이것. AI 클러스터·분산 데이터베이스에서 핵심.
  • SmartNIC / DPU(Data Processing Unit) — NIC 안에 자체 CPU·메모리가 있어 네트워크 처리를 완전히 오프로드. NVIDIA BlueField·Intel IPU·AWS Nitro가 사례. 클라우드 벤더가 자체 DPU를 만드는 이유 — 보안·네트워크 가상화 오버헤드를 호스트 CPU에서 떼어내려고.

PCIe — 부품들을 잇는 고속도로

지금까지 본 부품(CPU·메모리·디스크·NIC)을 잇는 것이 PCIe(Peripheral Component Interconnect Express) 버스다. 메인보드 위의 고속 데이터 통로. PCIe는 레인(lane) 단위로 대역폭을 확장한다. x1(1레인)·x4·x8·x16이 흔한 구성.

  • PCIe 3.0: 레인당 약 1GB/s. x16 = 16GB/s
  • PCIe 4.0: 레인당 약 2GB/s. x16 = 32GB/s
  • PCIe 5.0: 레인당 약 4GB/s. x16 = 64GB/s
  • PCIe 6.0: 레인당 약 8GB/s (2024년 샘플, 2025년 양산)

NVMe SSD는 보통 PCIe x4에 연결된다 — PCIe 4.0 x4 = 약 8GB/s, PCIe 5.0 x4 = 약 16GB/s. GPU(AI 가속기)는 보통 x16에 연결된다 — 대역폭이 커야 하니까. NIC은 10G/25G는 x4, 100G/400G는 x8 또는 x16.

CPU마다 가용한 PCIe 레인 수가 정해져 있다. Xeon Scalable은 보통 48 ~ 80레인, EPYC는 128 ~ 160레인. 레인이 부족하면 SSD·GPU·NIC을 다 못 꽂는다 — 서버 구성의 물리적 한계. 대형 AI 서버(H100 8개 장착)가 특수 메인보드와 여러 CPU를 요구하는 이유가 여기에 있다.

NUMA — 다소 CPU 소켓 시스템의 트레이드오프

마지막으로, NUMA(Non-Uniform Memory Access). 다중 CPU 소켓(2소켓·4소켓) 서버에서 메모리 접근 비용이 균일하지 않은 현상이다.

2소켓 서버를 상상하자. CPU 0에 연결된 DIMM 슬롯 12개, CPU 1에 연결된 DIMM 슬롯 12개. 각 CPU는 자기가 연결된 메모리(local memory)는 빨리 접근하지, 다른 CPU가 연결된 메모리(remote memory)는 느리게 접근한다 — 인터소켓 링크(Intel UPI·AMD Infinity Fabric)를 거쳐야 하니까. 이게 NUMA다. 메모리 접근이 "균일하지 않다(non-uniform)"는 뜻.

flowchart LR
    subgraph NUMA0["NUMA 노드 0"]
        CPU0[CPU 0] <---> MEM0["메모리 0<br/>(local, 100ns)"]
    end
    subgraph NUMA1["NUMA 노드 1"]
        CPU1[CPU 1] <---> MEM1["메모리 1<br/>(local, 100ns)"]
    end
    CPU0 -.-|원격 접근 200ns| MEM1
    CPU1 -.-|원격 접근 200ns| MEM0

NUMA를 모르면 — 스레드가 CPU 0에서 돌고 있는데 데이터가 CPU 1의 메모리에 있어서 접근이 2배 느려지는 일이 일어난다. 고성능 워크로드(DB·게임 서버·HPC)는 NUMA 인식(numa-aware)으로 최적화한다 — 스레드와 데이터를 같은 NUMA 노드에 묶는다. Linux는 numactl·libnuma로 이걸 제어한다. 데이터베이스 엔진(PostgreSQL·Oracle)은 NUMA 인식 배치를 기본으로 한다.

클라우드 인스턴스는 보통 vCPU 하나가 한 NUMA 노드에만 할당되도록 강제한다(pin) — 사용자가 NUMA를 신경 안 써도 되게. 다만 베어메탈 인스턴스나 자체 서버에서는 NUMA 튜닝이 여전히 중요하다. 10-performance-analysis 글에서 NUMA 지역성이 성능에 미치는 영향을 다시 다룬다.

실습 — 서버 하드웨어 직접 확인하기

이 글의 개념을 직접 확인하는 기본 명령들. 단일 리눅스 서버(또는 WSL2)에서 실행 가능하다.

1. CPU 정보 — lscpu

# CPU의 모든 것 — 코어 수, 스레드, 캐시, NUMA, 가상화 지원
lscpu

확인할 것: Model name(CPU 모델), CPU(s)(총 스레드 수), Core(s) per socket(물리 코어), Thread(s) per core(SMT 여부), L3 cache(LLC 크기), NUMA node(s)(소켓 수), Virtualization(가상화 지원).

# 예상 출력 (AWS EC2 m6i.large, KVM 가상화)
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              2              # 2 vCPU
On-line CPU(s) list: 0,1
Thread(s) per core:  2              # SMT2
Core(s) per socket:  1              # 물리 코어 1
Socket(s):           1
Vendor ID:           GenuineIntel
Model name:          Intel(R) Xeon(R) Platinum 8375C CPU @ 3.50GHz
Hypervisor vendor:   KVM            # 클라우드 VM
Virtualization type: full
L1d cache:           48 KiB
L1i cache:           32 KiB
L2 cache:            1.25 MiB
L3 cache:            54 MiB         # LLC
NUMA node(s):        1

2. 메모리 — free와 dmidecode

# 메모리 총량과 사용량
free -h
# 상세한 DIMM 정보 (root 권한)
sudo dmidecode -t memory | grep -E 'Size|Speed|Type|Locator' | head -20

확인할 것: free -h의 total·available. dmidecode로 DIMM별 용량·속도(MT/s)·타입(DDR4/DDR5)·ECC 여부. 가상 머신이면 dmidecode가 제한적일 수 있다.

# 예상 출력 (free -h)
              total        used        free      shared  buff/cache   available
Mem:           7.6Gi       1.2Gi       4.0Gi       12Mi       2.5Gi       6.2Gi
Swap:          2.0Gi          0B       2.0Gi

3. 블록 장치 — lsblk

# 블록 장치(디스크) 구조를 본다.
lsblk
# 디스크의 회전 여부(HDD vs SSD)까지
lsblk -d -o NAME,ROTA,SIZE,TYPE

확인할 것: ROTA(rotational) = 1이면 HDD, 0이면 SSD. NVMe SSD는 /dev/nvme0n1, SATA는 /dev/sda. 파티션 구조까지 같이 본다.

# 예상 출력
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0    0 953.9G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part /boot/efi
└─nvme0n1p2 259:2    0 953.4G  0 part /

4. PCIe 장치 — lspci

# 서버에 연결된 모든 PCIe 장치 — NIC, GPU, NVMe 컨트롤러
lspci | grep -iE 'ethernet|nvme|vga|infiniband'

확인할 것: NIC(Ethernet controller)의 모델·대역폭, NVMe 컨트롤러, GPU(있으면). 클라우드 VM은 NIC만 보일 수 있다 — GPU·NVMe 컨트롤러는 하이퍼바이저가 가상화해 숨길 수 있음.

# 예상 출력 (베어메탈)
00:1f.2 SATA controller: Intel Corporation ...   # SATA 컨트롤러
03:00.0 Ethernet controller: Mellanox ... MT27800  # 100G NIC
04:00.0 Non-Volatile memory controller: Samsung ... NVMe SSD
86:00.0 VGA compatible controller: NVIDIA ... A100 # GPU

5. NUMA 토폴로지 — numactl

# NUMA 노드와 CPU·메모리 할당 (root)
numactl --hardware
# 각 프로세스가 어느 NUMA 노드의 메모리를 쓰는지
numastat -p $(pgrep -o nginx)

확인할 것: NUMA 노드가 2개 이상이면 다소 소켓 시스템. 노드별 메모리 크기. 단소켓 시스템(클라우드 VM 대부분)은 NUMA 노드 1개.

# 예상 출력 (2소켓 서버)
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 64205 MB
node 0 free: 52340 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 64495 MB
node 1 free: 52890 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

node distances에서 0→0은 10(참조값), 0→1은 21 — 두 배 거리. NUMA 원격 접근이 두 배 느리다는 걸 수치로 보여준다.

미검증: 위 명령의 정확한 출력은 하드웨어·배포판·클라우드에 따라 다르다. 클라우드 VM은 dmidecode·lspci가 가상화된 결과를 보여주므로, 베어메탈과 출력이 다를 수 있다. man 페이지(man lscpu, man lspci)가 공식 필드 정의.

판단 표 — 워크로드별 하드웨어 선택

서버 하드웨어는 워크로드에 따라 최적이 다르다. 같은 "서버"라도 용도별로 구성이 갈린다.

워크로드 CPU 메모리 디스크 NIC 전형 인스턴스
웹 서버 (stateless) 보통 (8 ~ 16 vCPU) 보통 (16 ~ 32GB) 작은 NVMe (OS만) 10G m6i.xlarge, e2-standard-4
관계형 DB (OLTP) 빠른 클럭 큼 (128GB+) NVMe (PCIe 4.0+) 10 ~ 25G m6i.4xlarge, r6i.4xlarge
인메모리 DB (Redis) 보통 매우 큼 (256GB+) 작아도 됨 25G r6i.8xlarge, r7g.8xlarge
데이터 웨어하우스 많은 코어 큼 대용량 NVMe 25 ~ 100G x2gd, i4i
AI 학습 (GPU) 많은 코어 큼 (HBM이 핵심) 대용량 NVMe 100 ~ 400G + RDMA p5, a3-highgpu
스토리지 백엔드 (S3-like) 보통 보통 대용량 HDD + NVMe 캐시 25 ~ 100G i4i, 베어메탈
로깅/분석 (batch) 많은 코어 보통 대용량 (HDD 가능) 10G c6i, spot 인스턴스

이 표는 foundations 02의 품질 속성(지연·처리량·내구성·비용)에서 역산된다. OLTP DB는 지연이 핵심이니 NVMe + 빠른 클럭. AI 학습은 메모리 대역폭이 핵심이니 HBM GPU. 로깅은 비용이 핵심이니 HDD + spot 인스턴스. "최고의 서버"는 없고, "이 품질 속성을 위해 이 하드웨어"가 정답이다.

하드웨어는 소프트웨어보다 느리게 변한다

도입의 Spectre/Meltdown으로 돌아가자. 그 사건은 CPU 설계의 미세한 최적화(speculative execution)가 보안 취약점이 될 수 있다는 걸 보여줬다. 소프트웨어 버그는 패치로 하룻밤이면 고쳐지지만 — 하드웨어 버그는 그 CPU가 물리적으로 교체될 때까지 수년간 남는다. 데이터센터 전체의 CPU를 교체하는 건 foundations 01에서 본 "되돌리기 비용 매트릭스"의 가장 무거운 항목 중 하나다. 그래서 하드웨어 결정은 신중해야 하고, 하드웨어를 이해하는 엔지니어는 왜 어떤 인스턴스가 비싸고 왜 어떤 워크로드에 안 맞는지를 설명할 수 있다.

이제 다음 글에서는 이 하드웨어를 어떻게 켜는지를 본다 — 부팅 과정. 전원 버튼을 누른 뒤 UEFI·GRUB·커널·initramfs·systemd가 차례로 동작해 서버를 사용 가능한 상태로 만드는 그 복잡한 춤을. 그 과정을 이해하면 — 부팅이 안 되는 서버를 왜 복구하기 어려운지, 클라우드 인스턴스가 "만들어지는 데" 왜 수십 초가 걸리는지가 보인다.

참고

  • Project Zero, "Reading privileged memory with a side-channel", Google Project Zero Blog, 2018-01-03 — Spectre/Meltdown 공개. 접근 2026-07-21. URL: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
  • Schroeder, B., Pinheiro, E., Weber, W.-D. "DRAM Errors in the Wild: A Large-Scale Field Study", SIGMETRICS 2009 — Google 데이터센터 DRAM 오류율 실측. 접근 2026-07-21
  • Hennessy, J. L., Patterson, D. A. 6th ed, Morgan Kaufmann, 2017 — CPU 캐시·메모리 계층·NUMA의 정론. 접근 2026-07-21
  • Intel Corporation, "Intel Xeon Scalable Processors Technical Product Specification", 2024 — Xeon 아키텍처·PCIe 레인. 접근 2026-07-21
  • AMD, "AMD EPYC 9004 Processors Architecture" white paper, 2022 — EPYC 12채널 메모리·Infinity Fabric. 접근 2026-07-21
  • AWS, "AWS Graviton4 Performance" — ARM 기반 서버 CPU의 성능·전력 효율. 접근 2026-07-21. URL: https://aws.amazon.com/ec2/graviton/
  • NVM Express, Inc. "NVMe Specification 2.1", 2024 — NVMe 프로토콜 표준. 접근 2026-07-21. URL: https://nvmexpress.org/
  • PCI-SIG, "PCI Express Base Specification 6.0", 2022 — PCIe 표준. 접근 2026-07-21
  • Gregg, B. 2nd ed, Addison-Wesley, 2020 — USE method, NUMA 튜닝, 성능 분석 실천. 접근 2026-07-21
  • Linux kernel documentation, kernel.org — lscpu, numactl, NUMA 문서. 접근 2026-07-21

티스토리툴바