---
title: "NAND read retry는 같은 읽기를 단순 반복하는 기능이 아니다"
author: "브레이브브라우저쓰자"
published_at: "2026-10-11T02:36:00.505Z"
updated_at: "2026-10-06T00:00:37.805Z"
tags: ["read retry"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/nand-read-retry%EB%8A%94-%EA%B0%99%EC%9D%80-%EC%9D%BD%EA%B8%B0%EB%A5%BC-%EB%8B%A8%EC%88%9C-%EB%B0%98%EB%B3%B5%ED%95%98%EB%8A%94-%EA%B8%B0%EB%8A%A5%EC%9D%B4-%EC%95%84%EB%8B%88%EB%8B%A4"
ai_assisted: true
---

# NAND read retry는 같은 읽기를 단순 반복하는 기능이 아니다

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

[원문](https://ariser.io/@writer_a9817d5a8de0/nand-read-retry%EB%8A%94-%EA%B0%99%EC%9D%80-%EC%9D%BD%EA%B8%B0%EB%A5%BC-%EB%8B%A8%EC%88%9C-%EB%B0%98%EB%B3%B5%ED%95%98%EB%8A%94-%EA%B8%B0%EB%8A%A5%EC%9D%B4-%EC%95%84%EB%8B%88%EB%8B%A4)

NAND page를 읽고 ECC가 실패했다. 같은 page를 한 번 더 읽어서 성공하면 우연히 noise가 사라진 걸까? Read Retry에서는 읽는 주소는 같아도 비교 기준이 달라진다. threshold 분포가 처음의 위치에서 이동했을 때 다른 read reference로 원래 state를 더 잘 구분하려는 과정이다.

NAND는 cell threshold가 정해진 경계의 어느 쪽인지 sensing해 bit를 만든다. retention, wear와 interference는 저장 분포를 이동시키거나 넓힐 수 있다. 처음 사용한 reference가 현재 분포 사이의 좋은 경계가 아니라면 raw bit error가 증가한다. ECC가 correction 가능한 정보를 얻도록 경계를 바꿔 다시 관측하는 것이 retry의 역할이다.

[Errors in Flash-Memory-Based Solid-State Drives 4.4절](https://arxiv.org/html/1711.11427)은 default read 후 ECC가 실패하면 다른 reference로 반복하고 지원된 후보를 소진하면 실패하는 절차를 설명한다. [Reducing Solid-State Drive Read Latency by Optimizing Read-Retry, 2021](https://arxiv.org/html/2104.09611)은 retry 단계가 latency에 주는 영향을 실제 3D NAND에서 조사한다. 각각의 제품과 실험 조건을 넘어 고정 retry 횟수를 보증할 수는 없다.

## 경계 이동으로 bit 수가 바뀌는 작은 예

가상 두 state의 threshold sample을 L =[1.1, 1.2, 1.3, 1.6]V, H =[1.4, 1.8, 1.9, 2.0]V로 놓자. 경계보다 낮으면 L, 높으면 H로 읽는 단순 모델이다. 1.5V 경계에서는 L의 1.6V와 H의 1.4V가 서로 잘못 분류돼 오류가 두 개다. 1.7V로 옮기면 L은 모두 맞고 H의 1.4V만 틀려 하나로 줄어든다.

| 가상 reference | L을 H로 읽은 수 | H를 L로 읽은 수 | 합계 |
|---|---:|---:|---:|
| 1.5V | 1 | 1 | 2 |
| 1.7V | 0 | 1 | 1 |
| 1.95V | 0 | 3 | 3 |

1.95V까지 계속 올리면 H의 1.4, 1.8, 1.9V가 L로 읽혀 세 개가 틀린다. 경계 이동이 무조건 좋은 방향은 아니다. 두 분포가 겹쳤으므로 한 threshold로 모든 sample을 정확히 나누지도 못한다. retry는 현재 관측의 오류를 correction 가능한 수준으로 줄이는 도구다.

## 긴 tail latency가 생기는 이유

가상 page read·transfer·decode 한 번이 80 μs이고 추가 설정 비용이 없다고 단순화하면 첫 시도에서 성공할 때 80 μs, 첫 실패 뒤 세 번째까지 가면 240 μs다. 실제 제품은 단계 간 겹침, pipeline과 decode 방식에 따라 다르다. 횟수만 더한 이 예는 평균이 작아도 드문 retry가 긴 tail을 만드는 구조를 보여 준다.

모든 요청에 많은 reference를 적용하면 회복 가능성은 넓어지지만 정상 page의 비용도 올라간다. 보통 빠른 default path와 실패 시의 추가 작업을 구분하는 이유다. 자주 쓰는 reference를 age·wear에 맞게 선택해 초기 실패를 줄이는 정책은 retry 횟수를 줄이는 또 다른 방향이다.

## 실패의 의미와 다음 복구 수단

지원된 reference를 다 시험해도 성공하지 못할 수 있다. 분포 겹침이 너무 크거나 다른 원인의 오류가 있으면 hard read 결과만 바꾸는 방법이 부족하다. soft 정보 수집과 더 강한 decode, 다른 중복 data를 쓰는 recovery가 필요할 수 있다. 가능한 후속 기능은 controller와 제품에 따라 다르다.

retry 통계는 주소별 횟수만이 아니라 retention age, wear, 실패 pattern과 함께 보면 유용하다. 특정 block에서 시간이 흐른 뒤 횟수가 늘어나는 경우와 쓰기 직후부터 실패하는 경우는 같은 설명이 아니다. reference 조정이 성공했다는 결과도 어떤 drift를 추정하는 증거인지 구분해야 한다.

Read Retry는 같은 질문을 같은 조건으로 반복하는 대신 comparator의 경계를 바꾸어 저장 상태를 다시 묻는 과정이다. 그 과정이 줄인 raw error와 추가한 latency를 함께 기록하자. 성공하는 reference를 찾는 능력은 신뢰성에 필요하지만, 시도 횟수와 복구 한계를 알아야 실제 SSD의 긴 대기 시간까지 설명할 수 있다.