---
title: "NAND 여러 plane을 함께 써도 마음대로 주소를 섞지 못한다"
author: "브레이브브라우저쓰자"
published_at: "2026-10-12T11:06:04.987Z"
updated_at: "2026-10-06T00:12:50.322Z"
tags: ["multi-plane operation"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/nand-%EC%97%AC%EB%9F%AC-plane%EC%9D%84-%ED%95%A8%EA%BB%98-%EC%8D%A8%EB%8F%84-%EB%A7%88%EC%9D%8C%EB%8C%80%EB%A1%9C-%EC%A3%BC%EC%86%8C%EB%A5%BC-%EC%84%9E%EC%A7%80-%EB%AA%BB%ED%95%9C%EB%8B%A4"
ai_assisted: true
---

# NAND 여러 plane을 함께 써도 마음대로 주소를 섞지 못한다

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/nand-%EC%97%AC%EB%9F%AC-plane%EC%9D%84-%ED%95%A8%EA%BB%98-%EC%8D%A8%EB%8F%84-%EB%A7%88%EC%9D%8C%EB%8C%80%EB%A1%9C-%EC%A3%BC%EC%86%8C%EB%A5%BC-%EC%84%9E%EC%A7%80-%EB%AA%BB%ED%95%9C%EB%8B%A4)

NAND die에 plane이 두 개 있으니 아무 page 두 개나 동시에 program할 수 있을까. plane은 병렬로 작업할 자원이지만, multi-plane command는 두 개의 완전히 독립된 command stream을 제공하는 것과 다르다. 같은 die의 주소·명령 규칙에 맞는 작업을 묶어야 병렬 array 동작을 시작할 수 있다.

Multi-Plane Operation을 활용하려면 plane 수를 세기 전에 **어떤 주소 조합이 하나의 묶음으로 허용되는지**부터 확인해야 한다.

## plane이 달라도 주소 제약은 남는다

[ONFI 4.2의 3.1.1절 Multi-plane Addressing](https://onfi.org/files/onfi_4_2-gold.pdf)은 한 multi-plane sequence에서 plane 주소들이 서로 달라야 한다고 정의한다. 일부 장치나 operation은 page 주소도 같아야 하므로 vendor datasheet를 확인하도록 명시한다. block 주소에는 무제약, full restriction, lower-bit XNOR restriction 같은 경우가 있다.

따라서 “다른 plane이면 된다”도, “모든 NAND는 같은 block 번호만 된다”도 충분한 설명이 아니다. page 제약과 block 제약을 대상 장치의 지원 조건에 따라 적용해야 한다. 오래된 규격과 최신 제품의 조건이 같다고 가정하기도 어렵다.

plane bits는 block address의 하위 부분에 들어갈 수 있다. 문서에서 말하는 block address와 사람이 편의상 부르는 plane 내부 block 번호를 구분하지 않으면, full restriction을 해석하다가 실제로 서로 다른 plane을 선택하지 못할 수 있다.

## 두 후보 묶음을 직접 검사하기

설명용으로 한 LUN, 두 plane, block당 64page를 가정한다. row의 하위 6bit는 page이고 그 위 block address의 최하위 bit가 plane이다. 이 가상 장치는 page가 같고 plane bit 이외의 block bits가 같은 full-restriction program을 지원한다고 하자. erase 완료와 page 순서 등 다른 조건도 만족했다고 전제한다.

block address 10은 이진수 1010이므로 plane 0이고, 11은 1011이므로 plane 1이다. 두 주소는 plane bit를 제외하면 같아 한 쌍이 된다.

| 후보 | row 주소 | 이 가상 조건의 결과 |
|---|---|---|
| block 10/page 5 + block 11/page 5 | 645 + 709 | 주소 조합 허용 |
| block 10/page 5 + block 11/page 6 | 645 + 710 | page가 달라 허용 안 됨 |
| block 10/page 5 + block 13/page 5 | 645 + 837 | plane 외 block bits가 달라 허용 안 됨 |

row는 block×64+page로 계산했다. 13은 plane 1이지만 11과 같은 짝이 아니다. 단지 plane 0·1에 각각 하나씩 배치됐다는 조건으로는 부족하다. 이 주소 format과 제약은 원리를 고정한 가상 구성이며 실제 부품의 주소표를 대신하지 않는다.

## 데이터 버스가 둘로 늘어나는 것은 아니다

[Errors in Flash-Memory-Based Solid-State Drives 1.1절](https://arxiv.org/html/1711.11427)은 die 내부 plane들이 data·control bus를 공유하는 구조를 설명한다. plane별로 data를 준비하고 묶어서 array program을 시작할 수 있어도, 같은 die의 외부 data path를 공유하면 두 page 입력은 직렬로 들어온다. 병렬화하는 부분과 공유하는 부분을 나눠야 실제 시간을 계산할 수 있다.

page당 입력 100µs, array program 500µs인 가상 두-page 작업을 보자. 일반적인 순차 처리라면 2×(100+500)=1200µs다. 적합한 multi-plane program에서 두 data 입력 후 두 array 작업이 같은 500µs 구간에 끝난다고 가정하면 100+100+500=700µs다. command overhead는 생략했다.

이상적인 예에서도 속도 비는 1200/700≈1.71이다. plane 두 개가 있다고 2배가 되지 않는 것은 200µs의 입력이 공유 버스를 사용하기 때문이다. 실제 operation에는 중간 busy와 program 분포, 상태 확인이 추가된다. cache나 다른 die 작업까지 함께 쓰는 경우는 별도의 시간선으로 계산해야 한다.

## 완료한 묶음에서 실패한 plane을 찾기

여러 plane을 한 번에 시작했다는 사실이 성공도 하나의 bit로 충분하다는 뜻은 아니다. [ONFI 5.0의 6.2절 Status Register Behavior](https://onfi.org/files/onfi_5_0_gold.pdf)은 multi-plane program·erase의 FAIL/FAILC 상태가 plane별로 독립적임을 설명한다. ready 관련 bits의 동작은 vendor 조건도 확인해야 한다.

묶음이 끝난 뒤 각 plane 결과를 확인하지 않으면 한쪽 program 실패를 놓칠 수 있다. 두 page의 논리 mapping을 함께 갱신하는 상위 동작이라면 일부 성공을 어떻게 보존하고 실패 page를 어디로 재기록할지도 필요하다. 물리적으로 함께 실행한 것이 상위 transaction의 원자적 성공을 의미하지는 않는다.

## 주소 배치가 병렬 기회를 만든다

들어온 임의 read·write가 항상 적합한 쌍을 이룰 수는 없다. controller가 처음 저장 위치를 배치할 때 함께 처리할 data를 조건에 맞게 놓으면 묶을 기회가 늘어난다. 반대로 무조건 쌍을 기다리면 단독 요청의 지연이 커질 수 있다.

사용하지 않는 plane이 있어도 적합한 주소가 없으면 해당 command로 채우지 못한다. 지원 plane 수, 주소 적합성, 공유 입력 시간과 요청 대기 시간을 함께 보아야 workload에서의 병렬도를 설명할 수 있다.

Multi-Plane Operation은 plane 자원을 주소 규칙에 맞춰 함께 쓰는 동작이다. 자원이 둘이라는 사실보다 **묶을 수 있는 주소를 고르고, 공유 bus의 시간을 남기며, 각 결과를 확인하는 과정**이 성능을 결정한다. 이 세 조건이 있어야 nominal plane 수를 실제 처리량으로 연결할 수 있다.