FTL로 이해하는 SSD 주소 변환과 수명 관리

운영체제가 기대하는 쓰기 모델과 Flash의 차이

운영체제는 섹터 단위 읽기·쓰기, 임의 위치 갱신, 투명한 저장장치 접근을 기대한다. 반면 Flash 메모리는 페이지 단위로 쓰고 블록 단위로 지워야 하며, 제자리 업데이트를 허용하지 않는다. P/E 사이클도 제한돼 있다.

FTL(Flash Translation Layer)은 이 간극을 펌웨어 수준에서 처리한다. SSD 컨트롤러 안에서 논리 주소(LBA)를 물리 블록과 페이지 주소로 바꾸고, 성능·수명·데이터 무결성을 함께 관리한다.

⤢✕

논리적 요청부터 하드웨어 제어까지

FTL은 STL, BML, LLD로 나뉜다. 각 계층은 주소 변환부터 불량 블록 처리, Flash 명령 실행까지 서로 다른 책임을 맡는다.

STL(Sector Translation Layer)은 LBA와 물리 주소의 매핑 테이블을 관리한다. Sector, Block, Hybrid 매핑을 선택하고, 무효 페이지 정리와 여유 블록 확보를 위한 Garbage Collection, 블록 사용을 분산하는 Wear Leveling, 예비 공간인 Over Provisioning도 이 계층에서 다룬다.

BML(Block Management Layer)은 불량 블록을 감지해 매핑 테이블에 반영하고 예비 블록으로 교체한다. ECC(Error Correction Code)를 적용하며 읽기·쓰기 실패 처리와 데이터 무결성도 담당한다.

LLD(Low Level Driver)는 Flash 하드웨어를 직접 제어한다. Read, Program, Erase 명령을 실행하고 타이밍, 상태, 인터럽트를 처리한다.

⤢✕

주소 매핑에서 선택하는 균형

매핑의 기본 흐름은 논리 섹터 주소를 테이블로 조회해 물리 블록·페이지 주소를 찾는 구조다.

LBA Space (Sector Address)
    ↓
Mapping Table
    ↓
Physical Address (Block, Page Address)

Sector Mapping은 섹터, 즉 페이지마다 독립적으로 매핑한다. 가장 세밀한 방식이라 쓰기 증폭과 단편화를 줄이고 유연한 주소 변환이 가능하다. 대신 DRAM에 큰 매핑 테이블이 필요하며 관리가 복잡하다. 매핑 테이블 크기는 (저장용량 / 페이지크기) × 주소크기로 계산한다. 1TB SSD와 4KB 페이지, 4B 주소를 기준으로 하면 (1TB / 4KB) × 4B = 1GB DRAM이 필요하다.

Block Mapping은 블록 단위로 주소를 연결하고 블록 내부 페이지 순서를 고정한다. 테이블이 작고 조회와 관리가 단순하지만, 페이지 하나를 갱신할 때도 전체 블록을 복사해야 한다. 그만큼 쓰기 증폭과 단편화가 커질 수 있다.

Hybrid Mapping은 데이터 블록에는 Block Mapping을, 로그 블록에는 Sector Mapping을 적용한다. 업데이트는 로그 블록에 기록하고 로그 블록이 차면 병합(Merge)해 데이터 블록에 통합한다. 메모리 오버헤드와 쓰기 증폭을 완화할 수 있지만 병합 비용과 알고리즘 복잡성이 따른다.

현대 SSD에서는 필요할 때 매핑 테이블을 불러오는 DFTL(Demand-based FTL), DRAM에 Hot 매핑을 캐시하는 Page Mapping + 캐싱 방식도 사용한다.

⤢✕

무효 페이지를 정리해 쓰기 공간을 되찾는 GC

Flash는 기존 페이지를 바로 덮어쓸 수 없다. 업데이트된 데이터는 새 페이지에 기록되고, 이전 페이지는 무효화된다. 이 무효 페이지가 쌓이면 여유 공간이 부족해진다.

Garbage Collection은 무효 페이지 비율이 높은 Victim Block을 고른 뒤, 남아 있는 유효 페이지를 새 블록으로 복사한다. 이어 매핑 테이블을 갱신하고 Victim Block을 소거해 여유 블록 풀로 돌려놓는다.

GC는 아이들 시간에 미리 실행하는 프로액티브 방식과, 여유 블록이 부족할 때 즉시 수행하는 리액티브 방식으로 구분할 수 있다. 전자는 성능 영향을 줄이는 데 목적이 있고, 후자는 공간 부족을 해소하지만 성능 저하가 발생할 수 있다.

쓰기 증폭(Write Amplification)은 호스트가 요청한 쓰기량보다 Flash에 실제 기록되는 양이 커지는 현상이다.

WA = (Flash 실제 쓰기량) / (호스트 쓰기량)

GC에서 유효 페이지를 복사하거나 Wear Leveling으로 데이터를 이동할 때 쓰기 증폭이 발생한다. Over Provisioning을 늘리고, GC 알고리즘을 효율화하며, TRIM 명령을 활용하는 방식으로 완화할 수 있다.

⤢✕

특정 블록의 조기 마모를 피하는 방식

Flash 셀의 P/E 사이클에는 한계가 있다. SLC는 100,000 사이클, MLC는 10,000 사이클, TLC는 3,000 사이클, QLC는 1,000 사이클로 제시된다.

자주 바뀌는 핫 데이터와 거의 갱신되지 않는 콜드 데이터가 섞이면 일부 블록만 빠르게 닳는다. Wear Leveling은 이 편차를 줄여 전체 수명을 늘리는 기능이다.

Dynamic Wear Leveling은 쓰기 요청이 들어올 때 P/E 카운트가 낮은 블록을 선택한다. 블록별 사용 횟수를 추적해 핫 데이터의 쓰기를 분산하지만, 콜드 데이터 자체는 이동하지 않는다.

Static Wear Leveling은 콜드 데이터를 포함한 모든 블록을 대상으로 한다. 콜드 데이터를 주기적으로 옮겨 블록 사용량을 균등화하므로 전체 수명을 극대화한다. 구현 시에는 P/E 카운트, 마지막 쓰기 시간, 유효·무효 페이지 수를 추적하고, 사용 횟수 또는 임계값을 기준으로 이동 대상을 정한다.

⤢✕

예비 공간이 성능과 수명에 미치는 영향

Over Provisioning은 사용자에게 보이지 않는 예비 공간으로, 전체 용량의 일부를 FTL이 내부 관리에 사용한다. 일반적으로 7-28%를 둔다.

이 공간은 여유 블록을 확보해 GC 빈도와 성능 저하를 줄이고, Wear Leveling에서 블록을 교체할 여지를 제공한다. 불량 블록을 대체하는 용도도 있다.

OP 크기를 늘리면 성능과 수명이 향상되지만 사용 가능한 용량은 줄어든다. 반대로 OP를 줄이면 용량은 확보할 수 있으나 성능 저하와 수명 단축이 뒤따른다. 일반 소비자 환경에는 7-10%, 엔터프라이즈 환경에는 20-28%가 권장된다.