---
title: "ECC로 읽힌 NAND 데이터를 왜 다시 옮겨 쓰는가"
author: "브레이브브라우저쓰자"
published_at: "2026-10-12T03:30:01.322Z"
updated_at: "2026-10-06T00:07:29.168Z"
tags: ["read reclaim"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/ecc%EB%A1%9C-%EC%9D%BD%ED%9E%8C-nand-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A5%BC-%EC%99%9C-%EB%8B%A4%EC%8B%9C-%EC%98%AE%EA%B2%A8-%EC%93%B0%EB%8A%94%EA%B0%80"
ai_assisted: true
---

# ECC로 읽힌 NAND 데이터를 왜 다시 옮겨 쓰는가

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

[원문](https://ariser.io/@writer_a9817d5a8de0/ecc%EB%A1%9C-%EC%9D%BD%ED%9E%8C-nand-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A5%BC-%EC%99%9C-%EB%8B%A4%EC%8B%9C-%EC%98%AE%EA%B2%A8-%EC%93%B0%EB%8A%94%EA%B0%80)

ECC가 오류를 고쳐 정상 데이터를 돌려줬는데 SSD가 그 데이터를 다른 block으로 옮긴다. 당장 읽기에 성공했으니 불필요한 쓰기처럼 보일 수 있다. 그러나 correction 성공은 저장된 셀의 오류가 사라졌다는 뜻이 아니다. 다음 읽기에도 decoder가 같은 손상을 다시 고쳐야 한다.

Read Reclaim은 많이 읽은 block의 유효 데이터를 읽고 수정해 새 block에 기록하는 동작이다. 읽기 횟수가 쌓여 read disturb 오류가 correction 한계에 가까워지기 전에 물리적 저장 상태를 새로 만드는 것이 목적이다.

## 읽기를 반복하면 읽지 않은 셀도 영향을 받는다

NAND string에서 선택하지 않은 wordline은 전류가 통과하도록 pass voltage를 받는다. 같은 block을 계속 읽으면 이 전압의 반복 stress가 다른 셀의 threshold 분포도 바꿀 수 있다. host가 자주 요청한 page만 관리하면 block 안의 다른 유효 page를 놓칠 수 있는 이유다.

[Errors in Flash-Memory-Based Solid-State Drives, 4.3절의 Read Reclaim](https://arxiv.org/html/1711.11427)은 block의 read count가 커졌을 때 데이터를 새 block으로 remap하는 방식을 설명한다. 같은 절의 adaptive 정책은 P/E cycle이 증가한 block에서 허용 read count를 더 낮추는 방향을 다룬다. read count 하나만으로 모든 block에 같은 안전 수명을 부여하기는 어렵다.

이것은 DRAM처럼 읽기 직후 같은 셀의 전하를 복원하는 동작이 아니다. NAND controller는 오류를 수정한 data를 다른 물리 위치에 program하고, 논리 주소가 새 위치를 가리키도록 바꾼다.

## correction 성공과 충분한 여유는 다른 상태다

한 codeword에서 최대 40개 bit error를 정정하는 가상의 bounded-distance code를 생각하자. 현재 28개를 수정했다면 수치상 남은 여유는 12개다. 다음 관리 시점까지 오류가 8개 늘고 예상보다 5개 더 늘 수 있다고 보수적으로 잡으면 28+8+5=41개가 된다. 지금 읽기가 성공했다는 사실만으로 다음 시점도 성공한다고 결론낼 수 없다.

이 예의 40·28·8·5는 실제 제품의 ECC specification이나 예측값이 아니다. 특히 LDPC decoder의 성공은 이런 단순한 bit 개수 경계로만 정해지지 않을 수 있다. 실제 firmware는 corrected error 정보, read count, wear, retry 이력 등 자신이 얻을 수 있는 신호로 정책을 구성해야 한다.

중요한 것은 현재 오류를 세는 일과 앞으로의 증가를 대비하는 일을 구분하는 것이다. 읽기 직전 이미 correction 한계를 넘었다면 일반적인 reclaim만으로 원본을 복원할 수 없다. 충분한 여유가 있을 때 시작해야 한다.

## 옮기려면 수정한 데이터가 들어가야 한다

새 block에 옮기면서 raw bit를 그대로 복사하면 기존 오류까지 새로 program할 수 있다. controller의 ECC 경로를 거쳐 원래 data를 복원하고, 새 위치에서의 기록 성공을 확인해야 이동이 의미를 갖는다. 내부 copy 동작을 쓴다면 correction이 어느 단계에 실제로 적용되는지 별도로 확인해야 한다.

새 저장 위치도 완벽한 셀이라는 뜻은 아니다. program 과정의 오류와 이후 retention·read disturb가 다시 발생할 수 있다. reclaim은 지금까지 쌓인 손상을 읽기 가능한 내용으로 되돌려 새 상태로 기록하는 관리 동작이지, 앞으로의 오류를 영구히 없애는 처리가 아니다.

주소 변경도 중요하다. 새 사본을 충분히 검증하기 전에 기존 사본을 지우거나 mapping을 먼저 바꾸면, 유지보수 도중 문제가 생겼을 때 선택할 정상 버전을 잃을 수 있다. 실제 장치는 자신의 전원 차단 복구 방식과 함께 이 순서를 설계한다.

## 이득만큼 추가 쓰기도 남는다

가상 관찰 구간에서 host가 1MiB를 썼고 reclaim이 유효 데이터 64KiB를 추가로 program했다고 하자. 다른 내부 쓰기를 생략하면 NAND program량은 1088KiB이고 host 대비 비율은 1088/1024=1.0625다. 6.25%의 추가 program량이 데이터 보호를 위한 비용으로 생겼다.

이는 실제 SSD 전체 write amplification의 측정값이 아니다. mapping 기록, 다른 garbage collection, block erase와 읽기 대역폭 비용은 계산에서 빠졌다. 모든 read 뒤에 데이터를 옮기면 오류를 줄이려는 관리가 오히려 wear와 지연을 빠르게 늘릴 수 있다.

그래서 background 시간과 남은 correction 여유를 함께 보며 시점을 잡는다. 한 page가 뜨겁게 읽히더라도 block의 유효 data가 많으면 이동 비용이 커지고, wear가 높은 block은 같은 read count에서도 더 이른 관리가 필요할 수 있다.

ECC 성공은 지금의 구조가 아직 원본을 설명할 수 있다는 기회다. Read Reclaim은 그 기회를 이용해 오류가 더 쌓이기 전에 저장 위치를 갱신한다. **정정 가능한 동안 옮기되, 옮기는 비용과 다음 관리 시점까지의 여유를 함께 계산하는 것**이 정상적으로 읽힌 데이터를 다시 쓰는 이유다.