---
title: "NAND program 완료는 평균 셀이 아니라 마지막 셀이 결정한다"
author: "브레이브브라우저쓰자"
published_at: "2026-10-10T11:50:01.622Z"
updated_at: "2026-10-05T23:57:13.828Z"
tags: ["program verify"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/nand-program-%EC%99%84%EB%A3%8C%EB%8A%94-%ED%8F%89%EA%B7%A0-%EC%85%80%EC%9D%B4-%EC%95%84%EB%8B%88%EB%9D%BC-%EB%A7%88%EC%A7%80%EB%A7%89-%EC%85%80%EC%9D%B4-%EA%B2%B0%EC%A0%95%ED%95%9C%EB%8B%A4"
ai_assisted: true
---

# NAND program 완료는 평균 셀이 아니라 마지막 셀이 결정한다

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

[원문](https://ariser.io/@writer_a9817d5a8de0/nand-program-%EC%99%84%EB%A3%8C%EB%8A%94-%ED%8F%89%EA%B7%A0-%EC%85%80%EC%9D%B4-%EC%95%84%EB%8B%88%EB%9D%BC-%EB%A7%88%EC%A7%80%EB%A7%89-%EC%85%80%EC%9D%B4-%EA%B2%B0%EC%A0%95%ED%95%9C%EB%8B%A4)

NAND page의 대부분 셀은 이미 목표 state에 도착했다. program이 끝나도 될 것 같은데 busy 상태가 조금 더 이어진다. 평균 셀의 threshold만 보면 이 시간은 낭비처럼 보인다. Program Verify는 완료를 평균으로 판정하지 않고, 아직 조건을 만족하지 못한 셀을 구별하는 과정이다.

동일 wordline의 많은 셀에 program pulse를 전달해도 charge 주입 반응은 같지 않다. 일부는 목표에 빨리 도착하고 일부는 늦는다. verify는 각 목표 state의 기준으로 현재 상태를 확인한다. 완료된 셀은 inhibit하고 남은 셀에는 후속 pulse를 허용한다. 같은 wordline에 있다고 모두 같은 횟수의 유효 programming을 끝까지 받아야 하는 것은 아니다.

[Errors in Flash-Memory-Based Solid-State Drives 2.4절](https://arxiv.org/html/1711.11427)은 목표에 도달한 셀을 막고 다른 셀의 programming을 계속하는 절차를 설명한다. 이 글에서는 그 절차가 page latency와 distribution tail을 어떻게 연결하는지 작은 가상 집합으로 추적한다.

## 네 셀의 완료 시각을 평균 내면 사라지는 셀

네 셀이 목표에 도달하는 pulse 번호가 각각 3, 4, 4, 8이라고 하자. 평균은 4.75지만 모든 셀이 필요한 조건을 만족하는 시점은 8번째다. 5번째 뒤 평균을 근거로 종료하면 네 번째 셀은 아직 부족하다. 3번째에 완료한 첫 셀은 이후 pulse에서 inhibit돼야 목표를 지나쳐 올라가는 일을 줄일 수 있다.

| 가상 pulse 뒤 | 완료된 셀 수 | 아직 진행 중인 셀 수 |
|---|---:|---:|
| 3 | 1 | 3 |
| 4 | 3 | 1 |
| 5~7 | 3 | 1 |
| 8 | 4 | 0 |

가상 pulse가 10 μs, verify가 5 μs이며 다른 overhead가 없다고 놓으면 4번째에서 끝나는 경우 60 μs, 8번째에서 끝나는 경우 120 μs다. 실제 NAND의 pulse·verify timing이 아닌 bookkeeping이다. 셀 하나의 느린 반응이 단순 page 완료 시간을 두 배로 늘릴 수 있음을 보여 준다.

## 실제 완료 기준에는 오류 허용 정책도 들어갈 수 있다

모든 제품의 algorithm이 단 한 셀의 미완료 때문에 끝없이 기다리는 것은 아니다. 제조사는 fail-bit 허용량이나 최대 loop, bad block 판정 등 제품별 기준을 둘 수 있다. ECC와 연계된 허용 오류 정책이 있다면 몇 개의 tail을 남길지와 그 후 수명이 함께 설계된다. 특정 데이터시트 근거 없이 “반드시 모든 셀이 완벽히 통과한다”는 규칙을 일반화하면 안 된다.

그래도 평균 threshold만으로 완료를 판단할 수 없다는 결론은 유지된다. 정해진 fail-bit 수와 margin을 검사하는 과정이 필요하고, 허용량을 넘는 tail이 있으면 program fail이나 긴 latency가 생길 수 있다. 평균값이 같은 두 page도 threshold tail의 크기에 따라 다르게 끝난다.

## verify가 빠르기만 하면 좋은 것은 아니다

verify도 sensing이다. reference, settling과 noise 여유가 충분해야 완료 여부를 제대로 구별한다. 미완료 셀을 완료로 잘못 분류하면 추가 pulse가 중단돼 저장 state가 부족할 수 있다. 완료 셀을 미완료로 분류하면 더 많은 pulse를 받아 overshoot 또는 추가 stress가 생길 수 있다.

목표 state들이 좁아질수록 이 판단 여유도 중요해진다. 단순히 verify 시간을 줄여 loop 비용을 절약하는 변경은 false-pass와 false-fail의 영향을 함께 평가해야 한다. 기준이 얼마나 정밀한지와 그 기준을 얼마나 안정적으로 읽는지가 결합된다.

program latency를 분석할 때는 평균 완료 loop 외에 최대 loop와 허용 실패 수, state별 tail을 기록하면 좋다. 반복해서 늦는 page가 특정 layer나 wear 조건에 모이는지 확인하면 controller queue 지연과 내부 program tail을 구분할 수 있다. busy 시간을 host interface 문제로만 돌리지 않게 해 준다.

Program Verify는 시간을 소비하는 확인 단계이면서 서로 다른 셀을 한 page로 완성시키는 조건이다. 페이지가 끝나는 시점은 평균 셀의 성공보다 남은 tail과 제품의 완료 정책에 달려 있다. 늦게 끝나는 셀의 수와 상태를 보면 program 속도를 줄이지 않고도 없앨 수 있는 대기와 저장 여유를 지키기 위해 남겨야 할 대기를 나눌 수 있다.