CS학습2026년 8월 31일

SSD/HDD: 저장 매체의 물리적 구조가 결정하는 접근 패턴과 성능 특성

SSD와 HDD는 데이터를 저장하는 물리적 방식이 근본적으로 다르며, 이 차이가 순차 접근과 임의 접근(random access) 성능 격차, 마모도, 파일시스템 설계 방식까지 영향을 준다. HDD는 회전하는 디스크와 헤드의 기계적 이동에 의존하고, SSD는 낸드 플래시(NAND flash)에 전기적으로 데이터를 기록한다. 이 글에서는 두 매체의 동작 원리

송민성7분 읽기

1. 개념

HDD(Hard Disk Drive)는 자성을 띤 원판(플래터, platter)을 고속으로 회전시키고, 그 위를 움직이는 헤드(head)가 자기장을 읽고 써서 데이터를 저장하는 기계식 저장 장치다.

SSD(Solid State Drive)는 낸드 플래시 메모리 셀에 전자를 가두거나 빼내는 방식으로 데이터를 저장하는 반도체 기반 저장 장치다. 움직이는 부품이 없다.

두 장치 모두 운영체제 입장에서는 블록 단위 저장 장치(block device)로 보이지만, 내부 동작 방식의 차이 때문에 접근 패턴에 따른 성능 편차가 크게 다르다.

2. 왜 사용하는가

HDD: 동일 비용 대비 대용량 저장이 가능하다. GB당 가격이 SSD보다 낮아 백업, 아카이브, 콜드 스토리지(cold storage) 용도에 여전히 쓰인다.
SSD: 임의 접근(random access) 성능이 HDD보다 수백 배 빠르고, 지연시간(latency)이 마이크로초(µs) 단위로 짧다. 데이터베이스, OS 부팅 디스크, 캐시 서버처럼 지연시간에 민감한 워크로드에 적합하다.

두 장치를 함께 쓰는 계층형 스토리지(tiered storage) 구성도 흔하다. 자주 접근하는 핫 데이터는 SSD에, 콜드 데이터는 HDD에 두는 식이다.

3. 동작 원리

HDD의 동작

플래터가 분당 5,400~15,000회전(RPM)으로 회전한다.
헤드가 액추에이터 암(actuator arm)에 의해 트랙(track) 위치로 이동한다. 이 과정을 탐색 시간(seek time)이라 하며 보통 4~10ms 소요된다.
원하는 섹터(sector)가 헤드 아래로 회전해 올 때까지 기다린다. 이를 회전 지연(rotational latency)이라 하며 평균적으로 회전 주기의 절반이다(7,200RPM 기준 약 4.2ms).
헤드가 자기장을 감지하거나 변화시켜 읽기/쓰기를 수행한다.

임의 접근 시 매번 탐색 시간과 회전 지연이 더해지므로, 순차 접근(sequential access)과 임의 접근의 성능 차이가 매우 크다.

SSD의 동작

데이터는 낸드 플래시 셀에 전하 형태로 저장된다. 셀은 페이지(page, 보통 4~16KB) 단위로 묶이고, 페이지는 다시 블록(block, 보통 128~256페이지)으로 묶인다.
읽기와 쓰기는 페이지 단위로 이루어지지만, 삭제(erase)는 반드시 블록 단위로만 가능하다.
이미 데이터가 있는 페이지에 새 값을 덮어쓸 수 없다. 새 데이터는 빈 페이지에 쓰고, 기존 페이지는 무효(invalid) 표시한다.
빈 블록이 부족해지면 가비지 컬렉션(garbage collection)이 동작해 유효한 페이지만 새 블록으로 옮기고 기존 블록을 통째로 지운다. 이 과정에서 실제 쓴 데이터보다 더 많은 내부 쓰기가 발생하는데 이를 쓰기 증폭(write amplification)이라 한다.
컨트롤러가 마모도 평준화(wear leveling)를 수행해 특정 블록에 쓰기가 집중되지 않도록 분산시킨다. 낸드 셀은 삭제-쓰기 사이클 횟수에 수명 제한이 있기 때문이다.

4. 코드 예제

순차 접근과 임의 접근의 성능 차이를 직접 측정하는 Python 스크립트다. 같은 파일에 대해 순차적으로 읽는 경우와 무작위 오프셋으로 읽는 경우를 비교한다.

python

import os
import time
import random

FILE_PATH = "test_10gb.bin"
FILE_SIZE = 1024 * 1024 * 1024  # 1GB로 테스트 (환경에 맞게 조정)
BLOCK_SIZE = 4096  # 4KB 블록
NUM_READS = 2000

def prepare_test_file():
    if not os.path.exists(FILE_PATH):
        with open(FILE_PATH, "wb") as f:
            f.seek(FILE_SIZE - 1)
            f.write(b"\0")

def sequential_read_test():
    with open(FILE_PATH, "rb") as f:
        start = time.perf_counter()
        for _ in range(NUM_READS):
            f.read(BLOCK_SIZE)
        elapsed = time.perf_counter() - start
    return elapsed

def random_read_test():
    max_offset = FILE_SIZE - BLOCK_SIZE
    offsets = [random.randint(0, max_offset) for _ in range(NUM_READS)]
    with open(FILE_PATH, "rb") as f:
        start = time.perf_counter()
        for offset in offsets:
            f.seek(offset)
            f.read(BLOCK_SIZE)
        elapsed = time.perf_counter() - start
    return elapsed

if __name__ == "__main__":
    prepare_test_file()

    seq_time = sequential_read_test()
    rand_time = random_read_test()

    print(f"순차 읽기 {NUM_READS}회: {seq_time:.4f}초")
    print(f"임의 읽기 {NUM_READS}회: {rand_time:.4f}초")
    print(f"임의/순차 비율: {rand_time / seq_time:.2f}배")

    os.remove(FILE_PATH)

HDD에서 실행하면 임의 읽기가 순차 읽기보다 수십~수백 배 느리게 나오고, SSD에서는 그 차이가 훨씬 작게 나온다. OS 페이지 캐시(page cache)의 영향을 배제하려면 리눅스에서는 O_DIRECT 플래그나 posix_fadvise로 캐시 우회를 고려해야 한다.

리눅스에서 디스크 I/O 통계를 실시간으로 확인하는 방법:

shell

# 1초 간격으로 디스크별 I/O 통계 출력
iostat -x 1

# 특정 디바이스의 순차/임의 성능을 fio로 벤치마크
fio --name=seqread --filename=/dev/sdX --rw=read --bs=1M --size=1G --direct=1
fio --name=randread --filename=/dev/sdX --rw=randread --bs=4k --size=1G --direct=1

5. 시간 복잡도 또는 성능 특성

정확한 수치는 제품과 세대에 따라 다르지만, 일반적인 특성은 다음과 같다.

| 항목 | HDD (7,200RPM 기준) | SSD (SATA/NVMe) | |---|---|---| | 탐색/지연시간 | 평균 8~10ms | 수십~수백 µs | | 순차 읽기 속도 | 100~200MB/s | SATA: 500MB/s대, NVMe: 3,000~7,000MB/s | | 임의 읽기 IOPS (4KB) | 수십~수백 IOPS | SATA: 수만 IOPS, NVMe: 수십만~백만 IOPS | | 쓰기 방식 | 덮어쓰기(overwrite) 가능 | 소거 후 쓰기(erase-before-write), 쓰기 증폭 발생 |

HDD는 임의 접근 시 기계적 지연이 절대적 병목이라 데이터 크기와 무관하게 접근 패턴 자체가 성능을 좌우한다. SSD는 병렬 채널 구조 덕분에 여러 요청을 동시에 처리할 수 있어 큐 깊이(queue depth)가 높을수록 IOPS가 증가하는 특성을 보인다.

6. 실무 사용 사례

데이터베이스 스토리지: PostgreSQL, MySQL 같은 RDBMS는 랜덤 I/O가 빈번한 인덱스 조회, WAL(Write-Ahead Log) 기록에서 SSD 사용 시 성능 이득이 크다. 특히 NVMe SSD는 트랜잭션 처리량(TPS)을 크게 끌어올린다.
로그/아카이브 스토리지: 순차 쓰기 위주이고 접근 빈도가 낮은 로그 저장소나 백업 시스템은 GB당 비용이 낮은 HDD를 여전히 활용한다.
파일시스템 설계: SSD를 겨냥한 파일시스템(F2FS 등)은 로그 구조(log-structured) 방식을 채택해 쓰기 증폭을 줄이도록 설계된다.
클라우드 스토리지 티어링: AWS EBS의 gp3(SSD 기반)와 st1(HDD 기반 처리량 최적화)처럼, 워크로드 특성에 따라 스토리지 타입을 선택하는 것이 비용과 성능 최적화의 핵심이다.

7. 주의할 점

SSD는 TRIM 명령을 지원해야 삭제된 블록을 미리 정리해 가비지 컬렉션 부담을 줄일 수 있다. 파일시스템과 OS 양쪽에서 TRIM이 활성화되어 있는지 확인해야 한다(fstrim, discard 마운트 옵션 등).
SSD는 쓰기 횟수에 수명 제한이 있으므로, 로그가 과도하게 쌓이는 애플리케이션은 총 바이트 쓰기(TBW, Total Bytes Written) 스펙을 고려해야 한다.
HDD는 물리적 충격에 약하고 다중 사용자 임의 접근 워크로드에서 성능 저하가 심하므로, 다중 스핀들 RAID 구성으로 보완하는 경우가 많다.
벤치마크 시 OS 페이지 캐시나 SSD 자체 캐시(DRAM 캐시) 때문에 실제 매체 성능이 아닌 캐시 성능을 측정하는 실수를 주의해야 한다.

8. 핵심 정리

HDD는 기계적 회전과 헤드 이동에 의존하기 때문에 임의 접근에서 탐색 시간과 회전 지연이라는 물리적 한계를 가지며, 순차 접근에 최적화된 워크로드에 적합하다. SSD는 낸드 플래시의 페이지/블록 구조와 소거 후 쓰기 방식 때문에 쓰기 증폭이라는 고유한 문제를 안고 있지만, 임의 접근 성능과 지연시간에서 HDD를 압도적으로 앞선다. 실무에서는 접근 패턴(순차 vs 임의), 비용, 내구성 요구사항을 기준으로 두 매체를 적절히 조합해 사용하는 것이 스토리지 설계의 핵심이다.