593. 존 스토리지 (Zoned Storage)

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

1. 본질: 존 스토리지 (Zoned Storage)는 주소 공간을 여러 존(Zone)으로 나누고, 각 존 안에서는 현재 쓰기 포인터 (Write Pointer) 뒤로만 기록하게 만들어 매체의 순차 쓰기 성향을 인터페이스 자체로 드러내는 스토리지 구조다.
2. 가치: 낸드 플래시와 기와식 자기 기록 (Shingled Magnetic Recording, SMR) 매체가 싫어하는 덮어쓰기를 줄여, 플래시 변환 계층 (Flash Translation Layer, FTL)의 숨은 데이터 이동과 쓰기 증폭 계수 (Write Amplification Factor, WAF)를 낮추고 지연 시간의 널뛰기를 완화한다.
3. 판단 포인트: 성능 이득은 장치 자체보다도 로그 구조 병합 트리 (Log-Structured Merge Tree, LSM-Tree), 객체 저장소, 순차 로그형 엔진처럼 존 규칙을 이해하는 소프트웨어가 함께 있을 때 커지며, 기존 랜덤 갱신 워크로드를 그대로 올리면 오히려 불편해질 수 있다.

Ⅰ. 개요 및 필요성

존 스토리지는 논리 주소 공간을 여러 존으로 나누고, 각 존 안에서는 순차 쓰기만 허용하는 저장장치 인터페이스다. 읽기는 대체로 자유롭지만, 쓰기는 반드시 현재 쓰기 포인터 위치에서만 가능하고, 다시 쓰려면 존 전체를 비우는 reset 절차를 거쳐야 한다. 한마디로 말해 블록 장치가 오랫동안 제공해 온 “마음대로 덮어쓰기”라는 환상을 걷어 내고, 매체의 실제 물리 제약을 호스트에게 정직하게 보여 주는 방식이다.

이 구조가 등장한 이유는 기존 블록 인터페이스가 편리한 대신 너무 많은 뒷정리를 장치 내부에 숨기기 때문이다. 낸드 플래시는 작은 단위 쓰기는 가능하지만 지우기는 큰 erase block 단위로 해야 하고, SMR 하드디스크는 인접 트랙을 겹쳐 쓰기 때문에 중간 덮어쓰기에 약하다. 그래서 일반 솔리드 스테이트 드라이브 (Solid-State Drive, SSD)나 SMR 장치는 내부에서 garbage collection, relocation, translation을 반복하며 무작위 갱신을 억지로 흉내 내는데, 이 비용이 바로 tail latency와 WAF로 되돌아온다.

아래 그림은 존 스토리지가 어떤 규칙을 노출하는지 보여 준다.

┌────────────────────────────────────────────────────────────────────────────┐
│ Zoned storage exposes the media rule: write forward, reclaim by reset     │
├────────────────────────────────────────────────────────────────────────────┤
│ Zone 0 : [data][data][data][WP.........................]                  │
│ Zone 1 : [data][data][WP..............................]                   │
│ Zone 2 : [empty......................................]                   │
│                                                                            │
│ Read  : random read is allowed                                             │
│ Write : only at the current Write Pointer (WP)                             │
│ Reuse : reset the whole zone, then WP returns to the start                 │
└────────────────────────────────────────────────────────────────────────────┘

핵심은 장치가 내부에서 몰래 정리하던 일을 소프트웨어가 더 잘 예측할 수 있는 규칙으로 바꿨다는 점이다. 이 덕분에 데이터베이스나 파일 시스템은 “장치가 언젠가 알아서 정리하겠지”를 기대하는 대신, 로그를 쌓고 세그먼트를 회수하는 식으로 저장 패턴을 명시적으로 설계할 수 있다.

• 📢 섹션 요약 비유: 존 스토리지는 노트를 아무 데나 고쳐 쓰는 방식이 아니라, 한 장을 끝까지 쓰고 필요 없으면 그 장을 통째로 뜯어내는 방식과 같다. 덜 자유롭지만, 지우개 찌꺼기 때문에 책상이 엉망이 되는 일은 훨씬 줄어든다.

Ⅱ. 아키텍처 및 핵심 원리

존은 독립적인 순차 로그 세그먼트처럼 동작한다. 호스트는 존의 크기, 상태, 쓰기 포인터를 보고 어떤 존에 기록할지 결정하고, 데이터가 더 이상 필요 없게 되면 다른 존으로 살아 있는 데이터만 옮긴 뒤 원래 존을 reset해서 재사용한다. 즉 장치 내부의 invisible garbage collection을 완전히 없앤다기보다, 정리의 주체와 시점을 호스트 쪽으로 끌어올린다고 이해하는 편이 정확하다.

아래 그림은 존의 생애주기를 단순화한 것이다.

┌────────────────────────────────────────────────────────────────────────────┐
│ Zone lifecycle: open -> append -> full -> reclaim -> reset                │
├────────────────────────────────────────────────────────────────────────────┤
│ Empty Zone                                                                 │
│     │ open                                                                  │
│     ▼                                                                       │
│ Open Zone -- append --> [WP moves forward] --> ... --> Full Zone           │
│     │                                                                       │
│     └──────── close / reopen as needed ───────────────────────────────┐     │
│                                                                        │     │
│ Reclaim path: migrate valid data to another zone -> reset -> Empty ----┘     │
└────────────────────────────────────────────────────────────────────────────┘

여기서 중요한 추가 조건이 열린 존(open zone) 수와 활성 존(active zone) 수 제한이다. 장치는 병렬성과 메타데이터 자원을 이유로 동시에 관리할 수 있는 존 수를 제한할 수 있으므로, 호스트는 무한정 많은 로그를 동시에 열어 둘 수 없다. 그래서 존 스토리지는 단순히 “순차 쓰기만 하면 된다”가 아니라, 세그먼트 수명주기와 동시성 예산을 함께 다루는 인터페이스다.

• 📢 섹션 요약 비유: 여러 줄의 계산대를 가진 마트라도 한꺼번에 열 수 있는 계산대 수에는 한계가 있다. 존 스토리지도 빈 줄을 마음껏 만들 수 있는 게 아니라, 열어 둔 줄 수를 관리하면서 손님 흐름을 조절해야 효율이 난다.

Ⅲ. 비교 및 연결

존 스토리지는 전통적인 블록 SSD와 오픈 채널 SSD 사이의 절충안으로 자주 이해된다. 일반 블록 SSD는 가장 쓰기 쉽지만 내부 동작이 불투명하고, 오픈 채널 SSD는 물리 지오메트리까지 호스트가 직접 다뤄야 해서 통제력은 크지만 부담도 크다. 존 스토리지는 이 둘 사이에서 플래시의 세부 배치까지 노출하지는 않되, 쓰기 순서라는 핵심 제약만은 호스트가 알게 만든다는 점이 특징이다.

또한 존 스토리지는 SMR 하드디스크와도 직접 연결된다. SMR이든 ZNS SSD든 본질은 “매체가 덮어쓰기에 약하니, 순차 로그형 쓰기를 소프트웨어가 이해해야 한다”는 동일한 철학이다. 이 때문에 LSM-Tree 계열 데이터베이스, 객체 저장소, 로그 세그먼트 기반 파일 시스템은 존 스토리지와 궁합이 좋고, 반대로 작은 랜덤 overwrite를 많이 하는 전통적 파일 시스템은 그대로 올리면 불편함이 커진다.

결국 존 스토리지는 저장장치가 더 똑똑해지는 방향이라기보다, 저장장치가 숨기던 진실을 인터페이스로 드러내는 방향이다. 이 관점을 잡아야 왜 592번 오픈 채널 SSD가 “호스트 직접 제어”의 급진형이라면, 593번 존 스토리지는 “현실적인 표준형 host-aware storage”로 이어지는지 자연스럽게 보인다.

• 📢 섹션 요약 비유: 블록 SSD가 호텔 직원이 방 배치를 전부 숨겨서 처리하는 방식이라면, 오픈 채널 SSD는 행사 주최자가 방 번호까지 직접 관리하는 방식이고, 존 스토리지는 층별 구역 규칙만 미리 알려 주고 세부 배치는 호텔이 계속 맡는 방식에 가깝다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 존 스토리지가 특히 잘 맞는 곳은 append-heavy 구조가 이미 존재하는 시스템이다. 예를 들어 LSM-Tree 기반 데이터베이스는 원래도 정렬 문자열 테이블 (Sorted String Table, SSTable)을 순차적으로 만들고, 객체 저장소는 immutable segment를 길게 쓰는 경우가 많다. 이런 시스템은 존 하나를 파일 하나, 세그먼트 하나, 또는 compaction output 하나와 맞추기 쉬워서 WAF와 tail latency를 동시에 낮출 수 있다.

반대로 기존 랜덤 overwrite 중심 응용을 거의 손대지 않고 올리는 것은 전형적인 실패 패턴이다. in-place update를 기대하는 파일 시스템이나 작은 hot object를 수시로 수정하는 워크로드는 존 회수와 데이터 이동이 잦아져, 장치 내부 GC를 없앤 대신 애플리케이션이 더 복잡한 cleaning 비용을 떠안게 된다. 즉 존 스토리지는 저장장치만의 기술이 아니라, 상위 소프트웨어가 로그 구조적으로 사고할 수 있는가를 묻는 아키텍처 선택이다.

적용 판단 체크리스트

1. 워크로드가 본질적으로 append, segment write, immutable file 생성에 가까운가?
2. 살아 있는 데이터를 다른 존으로 옮기는 cleaner 또는 compaction 정책을 설계할 수 있는가?
3. 열린 존 수 제한과 존 크기를 고려해 병렬 쓰기 전략을 짤 수 있는가?
4. 장애 복구 시 어떤 존의 어느 구간까지 유효한지 추적할 메타데이터가 있는가?
5. 도입 효과를 WAF, reset 빈도, full zone 비율, tail latency 같은 지표로 검증할 수 있는가?

피해야 할 안티패턴

• 기존 이식 가능 운영체제 인터페이스 (Portable Operating System Interface, POSIX) 파일 시스템과 랜덤 overwrite 애플리케이션을 거의 그대로 얹고 장치만 바꾸는 도입

• 존 크기와 open zone 제한을 무시해 지나치게 많은 작은 로그를 동시 유지하는 설계

• reset 전에 유효 데이터 이동 비용을 계산하지 않아 cleaner가 새 병목이 되는 구성

• “가비지 컬렉션 (Garbage Collection, GC)이 장치 밖으로 나갔으니 비용이 사라졌다”고 착각하고, 실제 소프트웨어 reclaim 비용을 측정하지 않는 운영

• 📢 섹션 요약 비유: 존 스토리지는 창고의 선반 규칙이 명확한 대신, 물건 정리 동선을 관리자가 직접 짜야 하는 시스템과 같다. 선반은 깔끔해지지만, 어떤 상자를 먼저 비우고 옮길지 계획이 없으면 창고는 금세 다시 막힌다.

Ⅴ. 기대효과 및 결론

존 스토리지를 제대로 활용하면 장치 내부의 예측 불가능한 relocation이 줄어들어 성능 안정성이 좋아지고, over-provisioning에 기대던 여유 공간도 덜 필요해진다. 플래시 관점에서는 WAF가 낮아져 수명이 늘고, 운영 관점에서는 tail latency가 덜 흔들리므로 서비스 품질을 예측하기 쉬워진다. 특히 대규모 데이터센터에서는 “최고 속도”보다 “항상 비슷한 속도”가 더 중요할 때가 많은데, 존 스토리지는 바로 그 지점을 노린다.

물론 대가도 분명하다. 장치가 숨기던 정리 책임이 소프트웨어 쪽으로 이동하므로, 파일 시스템·데이터베이스·복구 로직이 더 똑똑해져야 한다. 앞으로의 방향은 존 스토리지를 단독 기술로 보는 것이 아니라, zone-aware 파일 시스템, LSM-Tree 엔진, 계산형 스토리지 계층과 결합해 매체 규칙을 아는 저장 소프트웨어 스택으로 확장하는 쪽에 가깝다.

결론적으로 존 스토리지는 “스토리지를 더 복잡하게 만든 기술”이 아니라, 매체의 물리적 제약을 인터페이스에 정직하게 반영해 전체 시스템을 더 예측 가능하게 만든 기술로 기억하는 것이 맞다. 편리한 환상을 조금 버리는 대신, 성능과 수명에서 훨씬 통제 가능한 시스템을 얻는 선택이다.

• 📢 섹션 요약 비유: 좋은 주방은 아무 냄비나 아무 불에 올리는 곳이 아니라, 재료와 조리 순서를 알고 불을 맞추는 곳이다. 존 스토리지는 저장장치의 “불 조절 규칙”을 숨기지 않고 드러내어, 전체 요리를 더 안정적으로 만드는 방식이다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

블록 인터페이스의 overwrite 환상
            │
            ▼
Device FTL · SMR translation의 숨은 정리 비용
            │
            ▼
매체 규칙 노출: Zoned Storage
            │
            ▼
ZNS · Zone Append · Zone Reset
            │
            ▼
Zone-aware LSM-Tree · Object Storage
            │
            ▼
Low-WAF · 예측 가능한 대규모 저장 시스템

이 흐름은 저장장치가 “무작위 갱신을 몰래 흉내 내는 단계”에서 벗어나, 이제는 소프트웨어가 매체 제약을 알고 협력하는 방향으로 진화하고 있음을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

1. 존 스토리지는 색칠공부를 할 때 아무 데나 덧칠하는 대신, 한 줄씩 끝까지 칠하고 다음 줄로 넘어가는 약속과 같아요.
2. 다시 칠하고 싶으면 그 줄을 조금씩 지우는 게 아니라, 한 줄을 통째로 새로 시작해야 해요.
3. 조금 까다롭지만, 덕분에 종이가 덜 망가지고 색칠도 훨씬 깔끔하게 할 수 있답니다.