328. 가비지 컬렉션 (Garbage Collection in SSD)

핵심 인사이트 (3줄 요약)

본질: 가비지 컬렉션 (Garbage Collection, GC)은 SSD (Solid State Drive)가 덮어쓰기 불가능한 낸드 플래시 (NAND Flash)에서 계속 쓸 수 있도록, 무효 페이지를 정리해 다시 쓸 수 있는 빈 블록을 만드는 내부 유지보수 절차다.

가치: SSD의 성능은 단순한 읽기 속도보다 얼마나 안정적으로 빈 블록 풀을 유지하느냐에 크게 좌우되며, GC 품질이 나쁘면 쓰기 지연 급등, 쓰기 증폭, 수명 저하가 한꺼번에 나타난다.

판단 포인트: GC는 많이 돌수록 좋은 것이 아니라, TRIM 명령·오버프로비저닝·마모 평준화와 함께 복사해야 할 유효 데이터의 양을 최소화하도록 설계될 때 성능과 수명이 동시에 좋아진다.

Ⅰ. 개요 및 필요성

가비지 컬렉션은 SSD 내부의 FTL (Flash Translation Layer)이 수행하는 공간 회수 메커니즘이다. HDD (Hard Disk Drive)는 같은 섹터에 덮어쓰면 끝나지만, 낸드 플래시는 먼저 지우기(Erase)를 해야만 다시 쓸 수 있다. 문제는 읽기와 쓰기는 페이지(Page) 단위로 가능하지만, 지우기는 그보다 훨씬 큰 블록(Block) 단위로만 가능하다는 점이다. 이 비대칭 때문에 SSD는 기존 위치를 바로 덮어쓰지 못하고, 새 위치에 기록한 뒤 이전 페이지를 무효(Invalid)로 표시하는 우회 전략을 쓴다.

이 방식은 처음에는 매우 효율적이지만, 시간이 지나면 블록 곳곳에 유효 페이지와 무효 페이지가 뒤섞인다. 블록 안에 무효 페이지가 많아도 유효 페이지가 하나라도 남아 있으면 블록 전체를 지울 수 없으므로, 결국 살아 있는 데이터만 다른 블록으로 옮긴 뒤에야 원래 블록을 지울 수 있다. 이 과정을 하지 않으면 SSD는 논리적으로는 여유 공간이 있어 보여도, 실제로는 즉시 쓸 수 있는 빈 블록이 부족해져 쓰기 지연이 급등한다. 즉 GC는 선택적 최적화가 아니라, SSD가 정상적으로 쓰기 동작을 유지하기 위한 필수 운영 절차다.

아래 그림은 왜 SSD가 '지우기 전 복사'를 해야 하는지를 보여준다.

┌──────────────────────────────────────────────────────────────────────┐
│                SSD의 공간 회수 문제: 페이지는 작고 블록은 크다      │
├──────────────────────────────────────────────────────────────────────┤
│ 쓰기 요청 발생                                                       │
│     │                                                                │
│     ▼                                                                │
│ 기존 LBA (Logical Block Address)의 예전 페이지는 무효화              │
│     │                                                                │
│     ▼                                                                │
│ 새 빈 페이지에 최신 데이터 기록                                      │
│     │                                                                │
│     ▼                                                                │
│ 블록 내부 상태: [Valid][Invalid][Invalid][Valid]                    │
│     │                                                                │
│     ├─ 유효 페이지가 남아 있음 ──▶ 블록 전체 Erase 불가              │
│     │                                                                │
│     └─ GC 수행 필요                                                  │
│             │                                                        │
│             ▼                                                        │
│     유효 페이지만 새 블록으로 복사 후 기존 블록 Erase                │
└──────────────────────────────────────────────────────────────────────┘

핵심은 SSD가 데이터를 지우기 위해 먼저 데이터를 옮겨야 한다는 역설이다. 운영체제는 단순히 파일을 수정했다고 생각하지만, 내부에서는 새 주소 기록·예전 주소 무효화·유효 데이터 이주·블록 소거가 연쇄적으로 일어난다. 그래서 SSD 성능은 칩 자체의 속도뿐 아니라, GC가 얼마나 질서 있게 공간을 정리하느냐에 크게 좌우된다.

📢 섹션 요약 비유: 연필로 쓴 공책이 아니라, 수정하려면 한 장 전체를 태워야 하는 노트라고 생각하면 된다. 한 문장만 고쳐도 남은 중요한 문장을 다른 종이에 옮겨 적고 나서야 헌 페이지를 버릴 수 있다.

Ⅱ. 아키텍처 및 핵심 원리

GC의 핵심 흐름은 희생 블록 선정 → 유효 페이지 복사 → 매핑 갱신 → 블록 소거 → 빈 블록 풀 복귀로 정리된다. 먼저 FTL은 무효 페이지 비율이 높은 블록을 후보로 고른다. 그런 다음 그 블록 안의 유효 페이지를 다른 빈 블록으로 이동시키고, LBA-PBA 매핑을 새 위치로 갱신한 뒤, 기존 블록을 Erase하여 다시 자유 블록(Free Block)으로 만든다. 이때 복사되는 데이터는 사용자가 새로 쓴 데이터가 아니라, 지우기 때문에 어쩔 수 없이 옮긴 기존 유효 데이터라는 점이 중요하다.

단계	수행 주체	핵심 동작	성능 영향
희생 블록 선정	FTL	무효 페이지가 많은 블록 탐색	메타데이터 조회 비용
유효 페이지 이주	컨트롤러 + NAND 채널	살아 있는 페이지 복사	내부 읽기/쓰기 증가
매핑 갱신	FTL	LBA ↔ PBA (Physical Block Address) 재연결	캐시/테이블 갱신 필요
블록 소거	NAND Flash	블록 단위 Erase	지연시간 큼
빈 블록 재활용	FTL	Free Block Pool에 반환	이후 쓰기 지연 완화

다음 그림은 GC가 성능에 영향을 주는 병목 위치를 한눈에 보여준다.

┌──────────────────────────────────────────────────────────────────────┐
│                   Garbage Collection 내부 데이터 경로               │
├──────────────────────────────────────────────────────────────────────┤
│ [Victim Block]                                                      │
│ [ V ][ I ][ I ][ V ][ I ][ V ]                                      │
│   │               │               │                                 │
│   └───── 유효 페이지만 선별 복사 ─┴─────┐                           │
│                                          ▼                           │
│                                [Destination Block]                  │
│                                [ V ][ V ][ V ][ F ][ F ][ F ]       │
│                                          │                           │
│                                          ▼                           │
│                          Mapping Table Update (LBA → new PBA)       │
│                                          │                           │
│                                          ▼                           │
│                              Erase old block at block granularity   │
│                                          │                           │
│                                          ▼                           │
│                           [Free Block Pool] 로 복귀                 │
├──────────────────────────────────────────────────────────────────────┤
│ 병목 포인트: 유효 페이지 복사량이 많을수록 내부 쓰기와 지연이 커짐     │
└──────────────────────────────────────────────────────────────────────┘

여기서 가장 중요한 지표가 WAF (Write Amplification Factor)다. 사용자가 4KB만 수정했는데 GC 때문에 기존 유효 데이터 수 MB가 함께 이동하면, 실제 낸드에 기록되는 총 쓰기량은 사용자 요청보다 훨씬 커진다. 일반적으로 빈 공간이 넉넉하고 TRIM이 잘 동작할수록 WAF는 낮아지고, SSD가 가득 찰수록 WAF는 높아진다. 즉 GC의 품질은 단순 청소 효율이 아니라, 성능·전력·발열·수명까지 연결되는 아키텍처 문제다.

GC는 실행 시점에 따라 백그라운드 GC와 포그라운드 GC로 나뉜다. 백그라운드 GC는 유휴 시간에 미리 빈 블록을 확보하므로 체감 지연이 작다. 반면 포그라운드 GC는 쓰기 요청이 들어온 순간 당장 여유 블록이 없어서 사용자 I/O 경로 위에서 직접 실행되므로, 이른바 write cliff 현상처럼 지연시간이 급증한다. 따라서 좋은 SSD는 채널 병렬성만 높은 제품이 아니라, 사용자가 바쁠 때 GC가 앞을 막지 않도록 설계된 제품이다.

📢 섹션 요약 비유: 창고 정리는 쓰레기만 버리는 일이 아니다. 아직 쓸 짐은 새 창고로 옮기고 주소표까지 다시 붙여야 한다. 짐이 많을수록 청소가 아니라 대이사가 된다.

Ⅲ. 비교 및 연결

GC를 제대로 이해하려면 HDD의 덮어쓰기 방식, SSD의 마모 평준화 (Wear Leveling), 그리고 TRIM 명령과 함께 봐야 한다. HDD는 같은 섹터에 직접 덮어쓸 수 있으므로 공간 회수를 위한 대규모 이주가 필요 없다. 반면 SSD는 out-of-place update를 전제로 하므로, GC가 없으면 정상 쓰기 자체가 지속되지 않는다. 즉 HDD의 삭제는 메타데이터 처리 중심이고, SSD의 삭제는 결국 미래의 GC 비용으로 이어지는 지연된 물리 작업이다.

비교 항목	HDD	SSD without GC tuning	SSD with efficient GC
덮어쓰기	직접 가능	직접 불가	직접 불가
공간 회수 방식	섹터 재사용	유효 페이지 복사 후 블록 소거	동일하지만 복사량 최소화
삭제 후 성능 영향	상대적으로 작음	장기 사용 시 급격한 저하	지속 성능 방어 가능
수명 영향	기계 마모 중심	내부 추가 쓰기 증가	WAF 억제로 수명 개선

TRIM은 운영체제가 더 이상 필요 없는 논리 블록 범위를 SSD에 미리 알려 주는 명령이다. TRIM이 없으면 FTL은 이미 삭제된 파일의 페이지도 여전히 유효할 수 있다고 가정해야 하므로, GC 때 쓸데없는 복사를 수행한다. 반대로 TRIM 정보가 충분하면 희생 블록 안의 무효 페이지 비율을 더 정확히 판단할 수 있고, 유효 페이지 이동량을 줄여 GC 비용을 낮출 수 있다. 그래서 GC와 TRIM의 관계는 '청소 담당자와 폐기 목록'의 관계에 가깝다.

마모 평준화와의 연결도 중요하다. GC는 빈 블록을 만들기 위해 데이터를 움직이고, 마모 평준화는 특정 블록에 지우기 횟수가 집중되지 않도록 데이터를 움직인다. 둘은 목적이 다르지만 실제 구현에서는 같은 데이터 이동 엔진을 공유하는 경우가 많다. 그래서 GC 정책을 잘못 잡으면 성능은 좋아 보여도 특정 블록만 빨리 닳을 수 있고, 반대로 마모를 지나치게 균등화하려 들면 불필요한 복사가 늘어 WAF가 증가할 수 있다. 결국 SSD 설계는 공간 회수와 수명 분산 사이의 균형 설계다.

📢 섹션 요약 비유: GC는 방을 비우기 위한 이사이고, 마모 평준화는 바닥이 한쪽만 닳지 않게 가구 배치를 바꾸는 일이다. 둘 다 짐을 옮기지만 목적이 다르며, 잘못하면 청소하려다 오히려 집안일만 늘어난다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 GC를 직접 호출하기보다, GC가 과도하게 비싸지지 않도록 환경을 설계하는 것이 핵심이다. 첫째, SSD를 장기간 90% 이상 채운 상태로 운영하면 자유 블록 풀이 줄어 희생 블록의 유효 페이지 밀도가 높아지고, 결국 매번 많은 데이터를 옮겨야 한다. 데이터베이스 로그나 가상화 스토리지처럼 지속 쓰기가 많은 환경에서는 이 현상이 지연시간 튐과 TBW (Terabytes Written) 소진으로 바로 드러난다. 따라서 쓰기 집약 워크로드일수록 여유 공간 확보와 오버프로비저닝이 사실상 필수다.

둘째, 파일 삭제가 잦은 환경에서는 운영체제와 파일시스템이 TRIM을 제대로 전달하는지 확인해야 한다. TRIM이 비활성화되면 사용자는 파일을 지웠다고 생각하지만 SSD는 여전히 살려야 할 데이터로 오인한다. 그 결과 GC는 가치 없는 페이지를 반복해서 복사하고, 성능 저하와 수명 감소가 동시에 발생한다. 특히 가상 디스크 이미지, 컨테이너 레이어, 데이터베이스 임시 파일처럼 생성과 삭제가 빈번한 계층에서는 TRIM 전달 경로가 끊기지 않도록 점검해야 한다.

셋째, 다음과 같은 판단 기준이 유효하다.

지속 쓰기 성능이 중요하면: 사용자 용량을 끝까지 쓰기보다 10~20% 여유 영역을 남겨 GC의 작업 공간을 확보한다.
지연시간 안정성이 중요하면: 유휴 시간에 백그라운드 GC가 충분히 돌 수 있는 워크로드 분산 전략을 함께 설계한다.
수명이 중요하면: 단순 순차 속도보다 WAF, DWPD (Drive Writes Per Day), 오버프로비저닝 정책을 함께 본다.
포렌식·보안이 중요하면: TRIM과 GC가 삭제 데이터를 실제로 빠르게 회수하므로, 삭제 후 복구 가능성을 HDD 기준으로 판단하면 안 된다.

대표적인 안티패턴은 SSD를 꽉 채운 뒤 조각 모음이나 대량 재기록 작업을 반복하는 것이다. HDD에서는 조각 모음이 탐색 시간을 줄였지만, SSD에서는 물리 이동 이점이 거의 없고 내부 쓰기만 늘린다. GC 관점에서 보면 이는 청소가 끝난 방에 일부러 짐을 다시 흩뿌려 더 큰 이사를 반복시키는 행위와 같다.

📢 섹션 요약 비유: 청소부가 일 잘하길 원한다면 집에 최소한의 빈방은 남겨 둬야 한다. 방이 하나도 없으면 정리는커녕 물건을 한 번 옮길 때마다 온 집을 뒤집어엎게 된다.

Ⅴ. 기대효과 및 결론

잘 설계된 GC는 SSD를 오랫동안 빠르게 보이게 만든다. 사용자는 단지 파일 저장과 삭제를 반복할 뿐이지만, 내부에서는 빈 블록 풀이 유지되고 쓰기 지연이 관리되며, 유효 데이터 이동량이 줄어든다. 그 결과 초기 벤치마크 수치뿐 아니라 장시간 운용 시의 지속 쓰기 성능, 평균 지연시간, 낸드 수명이 함께 개선된다. 특히 서버·클라우드 환경에서는 순간 최고 속도보다 장기적인 tail latency 억제가 더 중요하므로, GC 품질은 제품 급을 가르는 핵심 요소다.

물론 GC는 공짜가 아니다. 데이터를 한 번 더 읽고 쓰고 지우는 과정이므로, 성능 손실과 셀 마모를 완전히 없앨 수는 없다. 그래서 최신 SSD 아키텍처는 TRIM, 오버프로비저닝, 채널 병렬화, SLC (Single-Level Cell) 캐시, 정교한 희생 블록 선택 알고리즘을 조합해 GC의 부작용을 감춘다. 앞으로는 ZNS (Zoned Namespace) SSD처럼 호스트가 기록 위치를 더 직접 제어하여, SSD 내부 GC 부담 자체를 줄이는 방향도 중요해질 것이다.

결국 SSD의 가비지 컬렉션은 '삭제 기술'이 아니라 '지속 가능한 쓰기 기술'로 기억하는 것이 맞다. SSD가 빠르다는 평가는 낸드가 단순히 빨라서가 아니라, 보이지 않는 곳에서 GC가 빈 공간을 계속 재창출하고 있기 때문에 가능하다.

📢 섹션 요약 비유: 좋은 식당 주방은 손님이 몰려도 설거지가 밀리지 않는다. 새 접시를 계속 내놓을 수 있는 이유는 뒤에서 빈 그릇을 제때 비우고 다시 돌리는 흐름이 살아 있기 때문이다.

📌 관련 개념 맵

개념	연결 포인트
FTL (Flash Translation Layer)	GC를 실제로 수행하며 논리 주소와 물리 주소 매핑을 갱신하는 핵심 펌웨어
TRIM	더 이상 필요 없는 페이지 정보를 전달해 GC의 불필요한 복사를 줄임
마모 평준화 (Wear Leveling)	데이터 이동 메커니즘을 공유하며 블록 수명 편중을 완화
오버프로비저닝 (Over-Provisioning)	GC가 사용할 여유 블록 풀을 제공해 write cliff를 완화
WAF (Write Amplification Factor)	GC 효율이 좋고 나쁨을 정량적으로 보여 주는 대표 지표
ZNS (Zoned Namespace) SSD	호스트가 쓰기 순서를 더 제어해 SSD 내부 GC 부담을 줄이려는 확장 방향

📈 관련 키워드 및 발전 흐름도

낸드 플래시의 Erase-before-Write 제약
    │
    ▼
FTL (Flash Translation Layer)의 out-of-place update
    │
    ▼
Garbage Collection을 통한 Free Block 재확보
    │
    ├──────────────┐
    ▼              ▼
TRIM 기반 복사량 축소   Wear Leveling 기반 수명 균형
    │              │
    └──────┬───────┘
           ▼
낮은 WAF와 안정적 지속 쓰기 성능
           │
           ▼
ZNS SSD · 호스트 협력형 공간 관리

이 흐름은 낸드의 물리 제약에서 출발해, 주소 변환·공간 회수·수명 관리·호스트 협력형 최적화로 이어지는 발전 방향을 보여준다.

👶 어린이를 위한 3줄 비유 설명

SSD는 낡은 장난감 상자를 바로 덮어쓸 수 없어서, 새 장난감은 빈칸에 먼저 넣고 예전 자리는 '버릴 예정' 표시를 해 둬요.
그래서 가끔 로봇 청소부가 아직 쓸 장난감만 새 상자로 옮기고, 비어 버린 헌 상자를 통째로 깨끗하게 지워 다시 써요.
이 청소를 똑똑하게 해야 장난감 상자가 오래가고, 새 장난감도 기다리지 않고 빨리 넣을 수 있어요.