핵심 인사이트 (3줄 요약)

  1. 일반적인 SSD는 무작위 쓰기(Random Write)를 처리하기 위해 내부적으로 더미 공간(Over-Provisioning)을 20% 이상 남겨두고, 끊임없이 조각 모음(GC)을 수행하느라 **수명 저하(Write Amplification)와 지연 시간 튐(Latency Spike)**이 발생한다.
  2. **ZNS (Zoned Namespace)**는 NVMe 표준의 하나로, SSD의 공간을 수백 MB 단위의 구역(Zone)으로 쪼개고, OS에게 "이 구역 안에서는 반드시 앞에서부터 순서대로(Sequential) 써라. 수정은 불가하며 통째로 지울 때만 삭제가 가능하다"라고 강제하는 구조다.
  3. OS(또는 데이터베이스)가 이 까다로운 규칙에 맞춰 저장 방식을 바꾸면, SSD 내부에 빈 공간(OP)을 남겨둘 필요도 없고 GC도 사라져 칩의 수명이 극한으로 늘어나며 1TB를 샀을 때 온전히 1TB를 다 쓸 수 있다.

Ⅰ. 무작위 쓰기의 대가 (FTL의 비극)

우리가 워드 파일의 중간 1줄을 수정할 때, SSD는 그 자리에 덮어쓰지 못합니다.

  • 낸드 플래시의 물리적 한계 때문에 빈 블록에 '수정된 새 파일'을 적고, 옛날 파일은 '유효하지 않음(Invalid)' 처리를 해버립니다.
  • 이런 쓰레기(Invalid) 데이터가 SSD에 가득 차면, SSD의 두뇌(FTL)는 이 쓰레기들을 모아서 진짜 빈 공간으로 만드는 찌꺼기 청소(Garbage Collection)를 해야 합니다.
  • 청소를 하려면 멀쩡한 파일도 이리저리 옮겨야 하므로(Write Amplification), 내가 10GB를 썼는데 SSD 수명은 30GB 치가 깎여나가는 대참사가 벌어집니다.

📢 섹션 요약 비유: 이가 빠진 블록(쓰레기)을 버리려면, 그 블록이 속한 거대한 레고 판을 통째로 부숴야 합니다. 레고 판에 붙어있던 멀쩡한 레고 조각들을 옆 판으로 옮겨 심느라 쓸데없는 체력(수명)이 낭비됩니다.

Ⅱ. ZNS의 등장: 순차 쓰기 강제법

데이터센터(AWS, Meta 등)는 이 수명 낭비를 참을 수 없었습니다. 그래서 SSD에서 똑똑한 척하는 FTL 기능을 반쯤 꺼버리고, OS에게 책임과 규칙을 떠넘겼습니다. 그것이 ZNS 규격입니다.

ZNS의 3대 원칙

  1. 구역 분할: SSD 전체를 256MB 크기의 '존(Zone)' 수천 개로 나눕니다.
  2. 순차 쓰기만 허용 (Append-only): 1번 존에 글을 쓸 때는 반드시 맨 앞줄부터 차곡차곡 써야 합니다. 중간에 빈칸을 두거나, 뒤로 점프해서 쓰면 SSD 하드웨어가 즉시 에러(Error)를 뿜고 쓰기를 거부합니다.
  3. 통째로 지우기: 1번 존에 있는 특정 파일 하나만 지울 수 없습니다. 지우려면 "1번 존 전체 포맷(Reset Zone)!" 명령어를 날려 한 방에 백지화해야 합니다.

구조도 (ASCII)

 [ ZNS SSD 하드웨어 공간 ]
 ┌─ Zone 0 (꽉 참, 지우기 전엔 못 씀) ─────────────────┐
 │ [데이터A][데이터B][데이터C][데이터D]                │
 └─────────────────────────────────────────────────────┘
 ┌─ Zone 1 (현재 쓰는 중) ─────────────────────────────┐
 │ [데이터E][데이터F] ──(Write Pointer 위치)        │ ◀ 무조건 이 포인터 뒤로만 이어서(Append) 써야 함
 └─────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 카세트테이프 녹음기와 같습니다. 빈 공간을 찾아 중간에 녹음할 수 없습니다. 무조건 테이프가 끝날 때까지 순서대로만 녹음해야 하며, 지울 때는 테이프 전체를 한 번에 다 지워야 하는 엄격한 규칙입니다.

Ⅲ. ZNS를 누가 쓸 수 있는가? (LSM-Tree)

"이런 불편한 하드디스크를 누가 쓰나?" 싶지만, 현대 클라우드의 심장인 RocksDB, 카산드라(Cassandra) 같은 NoSQL 데이터베이스가 이 방식을 사랑합니다.

이 DB들은 애초에 데이터를 덮어쓰지 않고 로그 파일처럼 밑에 계속 이어붙이는 LSM-Tree(Log-Structured Merge-Tree) 구조로 코딩되어 있습니다. 즉, 소프트웨어(DB)가 원래 순차적으로 데이터를 쏟아내는 성격이라 ZNS의 물리적 규칙과 완벽한 찰떡궁합을 이룹니다. 결과적으로 ZNS를 도입한 클라우드 데이터센터는 SSD 수명을 2~3배 이상 뻥튀기하며 막대한 교체 비용(TCO)을 아끼고 있습니다.