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

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

본질: SSD의 가비지 컬렉션(GC)은 '덮어쓰기'가 안 되어 쓰레기(Invalid Page)로 가득 차버린 낸드 플래시 메모리 블록에서, 아직 살아있는 정상 데이터(Valid Page)들만 쏙쏙 뽑아 새 블록으로 이사(Copy)시킨 뒤, 옛날 블록 전체에 고압 전기를 쏴서 텅 빈 깨끗한 상태(Erase)로 초기화하는 내부 펌웨어의 대청소 작업이다.

가치: 이 끔찍한 쓰레기 수거 작업이 없으면 SSD는 한 바퀴 용량을 다 채우는 순간 더 이상 새로운 파일을 저장할 빈 공간(Free Block)을 잃고 컴퓨터가 뻗어버리는 일회용 저장소로 전락하기 때문에, SSD의 생명 연장과 재사용성을 보장하는 가장 필수적인 심장 박동이다.

융합(한계): 유저가 엑셀 저장을 누를 때 하필 이 대청소가 같이 터지면 쓰기 속도가 100배 느려지는 '쓰기 절벽(Write Cliff / 렉)'이 발생하므로, 컨트롤러는 이를 덮기 위해 오버 프로비저닝(OP) 여유 공간과 OS의 TRIM 명령어를 융합하여 백그라운드에서 유저 몰래 청소하는 극한의 눈치 게임을 펼친다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 자바나 파이썬에 있는 메모리 힙 청소부(GC)와 100% 동일한 철학이 SSD 쇳덩어리(펌웨어) 안에 들어있다. 낸드 플래시는 데이터를 지울 때 '4KB 페이지' 단위로 못 지우고 무조건 거대한 '2MB 블록' 단위로만 지워야 하는(Erase) 기형적 구조를 가졌다. 블록 안에 1장이라도 쓸모 있는 데이터가 있으면 그 블록을 통째로 날릴 수 없다. 그래서 펌웨어(FTL)가 블록 안의 진짜 쓸모 있는 놈들만 핀셋으로 뽑아 다른 새 방에 옮겨놓고 나서야 비로소 그 2MB 블록에 다이너마이트를 터뜨려(Erase) 텅 빈 새 공간을 창출하는 일련의 수거 연산을 SSD GC라고 부른다.
필요성: 만약 당신이 1TB짜리 SSD를 사서 게임을 깔았다 지웠다를 미친 듯이 반복했다 치자. 윈도우에서는 분명히 "여유 공간 500GB"라고 뜨지만, SSD 내부 물리적 셀 안에는 당신이 '지운' 게임 파일의 전자 찌꺼기들이 "나 유효하지 않음(Invalid)" 딱지만 붙인 채 2MB 블록 구석구석마다 알박기를 하고 있다. 덮어쓰기가 안 되니 이 찌꺼기 방에는 새 데이터를 넣을 수가 없다! 결국 "완전히 텅 빈 깨끗한 2MB 통짜 블록(Free Block)"이 단 1개도 안 남는 순간이 찾아온다. 이때 내가 1KB짜리 메모장 파일을 저장하려 하면? SSD 컨트롤러는 패닉에 빠져 컴퓨터를 멈춰 세운다. 이 파국을 막으려면 남는 시간에 미리미리 쓰레기 방을 털어서 깨끗한 통짜 방을 확보해 두는 대청소부(GC)가 무조건 필요했다.
💡 비유: SSD GC는 아파트 재건축과 세입자 이주와 같다. 100가구가 사는 아파트 단지(블록 2MB)가 있다. 그중 90가구가 이사를 나가서 빈집(Invalid Page, 쓰레기)이 되었다. 새로 이사 올 손님에게 이 빈집을 그냥 주면 안 되냐고? 절대 안 된다(덮어쓰기 불가). 새 손님은 무조건 '건물 전체가 텅 빈 완벽한 새 아파트(Erased Free Block)'에만 들어올 수 있다. 그렇다고 건물을 냅다 폭파(Erase)시킬 수도 없다. 아직 이사 안 간 **10가구의 정상 주민(Valid Page)**이 살고 있기 때문이다. 그래서 조합장(FTL)은 옆 동네 새 아파트 한 채를 통째로 비워두고, 남은 10가구 주민을 거기로 멱살 잡고 이주(Copy)시킨다. 주민이 다 빠져나가고 완벽한 빈 건물이 된 그 순간, 다이너마이트를 터뜨려 낡은 아파트를 철거(Erase)하고 완벽한 평지로 만들어 다음 손님을 맞이할 준비를 끝낸다.
등장 배경 및 낸드의 생리적 족쇄:
1. Out-of-Place Update: 덮어쓰기가 안 돼서 새 공간으로 도망치다 보니, 온 세상이 버려진 쓰레기장(Invalid)이 됨.
2. Erase 사이즈의 거대함: 1장만 지우면 되는데 무조건 512장(1블록)을 같이 묶어서 지워야 하는 병맛 같은 물리적 한계.
3. GC의 등장: 결국 쓰레기장에 남은 쓸만한 물건만 밖으로 건져내고 쓰레기장 전체를 불태우는 방식으로 공간 낭비를 돌파.

┌───────────────────────────────────────────────────────────────────────┐
│        SSD 가비지 컬렉션(GC)의 피눈물 나는 3단계 런타임 시각화        │
├───────────────────────────────────────────────────────────────────────┤
│                                                                       │
│ [ 상황: 낡은 블록 1번 안에 쓰레기 3개와 쓸만한 놈 1개가 섞여 있음 ]   │
│                                                                       │
│ ┌─── 블록 1 (낡음) ───┐     ┌─── 블록 2 (새 텅 빈 방) ───┐            │
│ │ [ 💀 쓰레기 (A) ] │     │ [           ]         │                   │
│ │ [ 💀 쓰레기 (B) ] │     │ [           ]         │                   │
│ │ [ 🟢 유효함 (C) ] │     │ [           ]         │                   │
│ │ [ 💀 쓰레기 (D) ] │     │ [           ]         │                   │
│ └───────────────────┘     └─────────────────────────┘                 │
│                                                                       │
│ ▶ 1단계: 유효 데이터 이주 (Read & Copy)                               │
│  - 컨트롤러: "어휴, 저 🟢 C 하나 때문에 블록 1번을 통째로 못 지우네!" │
│  - 블록 1의 🟢 C 를 복사해서 ──▶ 새 블록 2의 첫째 칸에 옮겨 씀!       │
│  - 이제 블록 1의 C도 [ 💀 쓰레기 ]로 마킹됨 (원본 역할 끝남).         │
│                                                                       │
│ ▶ 2단계: 다이너마이트 폭파 (Erase!)                                   │
│  - 컨트롤러: "좋아! 블록 1에 이제 쓰레기 4개뿐이지? 20V 전기 쏴!"     │
│  - 💥 블록 1 전체가 하얗게 불타며 완벽한 [ 텅 빈 프리 블록 ]으로 부활!│
│                                                                       │
│ ▶ 3단계: 장부(매핑 테이블) 갱신 (Update FTL)                          │
│  - OS야, 앞으론 데이터 C 부를 땐 블록 2번으로 와라. 화살표 쓱 수정~   │
└───────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 아름다운 복구 과정을 위해 하드웨어는 엄청난 '시간(Latency)'을 피눈물로 지불해야 한다. C를 복사하는 시간(Read+Write)에 블록을 폭파하는 시간(Erase 5ms)까지, 한낱 데이터 1개 살리자고 디스크가 몇 밀리초 동안 멈춰버리는 것이다. 유저가 게임을 다운받는 와중에 이 짓거리가 터지면 다운로드 속도가 1GB/s에서 50MB/s로 수직 낙하하는 '프리징(Freeze)'의 주범이 된다.

📢 섹션 요약 비유: 냉장고(SSD)가 김치통(블록)들로 꽉 차서 새 반찬을 넣을 곳이 없습니다. 통 안에는 쉰 김치(쓰레기)가 잔뜩 있고 멀쩡한 김치(유효 데이터)는 한 쪼가리뿐입니다. 쉰 김치만 쏙 빼서 버리면 좋겠지만 이 김치통은 무조건 통째로 비워야(Erase) 하는 마법의 통입니다. 그래서 새 김치통(프리 블록)을 하나 가져와서 멀쩡한 김치 한 쪼가리를 옮겨 담고, 기존 김치통은 통째로 쓰레기통에 쏟아버려 빈 통으로 부활시키는 설거지 노가다입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

Write Amplification (쓰기 증폭)의 끔찍한 나비효과

가비지 컬렉션의 가장 큰 죄악은 **"나는 쓰라고 명령하지 않은 데이터를 SSD가 혼자서 마음대로 썼다 지웠다 반복한다"**는 점이다.

OS(유저)가 SSD에 "4KB 써라!"라고 명령했다. (Host Write: 4KB).
SSD 내부는 꽉 차서 4KB를 쓸 빈방이 없었다. GC를 발동한다.
GC가 빈 블록을 만들기 위해, 낡은 블록 5개를 뒤져서 유효 데이터 1.9MB어치를 새 블록으로 이사시켰다(복사 쓰기 발생).
그리고 낡은 블록을 지운 뒤, 마침내 유저가 시킨 4KB를 그 빈 공간에 썼다.
물리적 결과 (NAND Write): 유저가 시킨 건 4KB인데, SSD 낸드 칩은 이사 가느라 1.9MB를 썼고, 거기에 4KB를 더 썼다. 총 약 2MB(2000KB)의 물리적 쓰기가 발생했다!
WA 계수 = 2000 / 4 = 500배 폭증. 이것을 **쓰기 증폭(Write Amplification, WA)**이라 부르며, 낸드 셀의 제한된 수명(TBW)을 빛의 속도로 갉아먹어 비싼 SSD를 1년 만에 사망하게 만드는 가장 무서운 암 덩어리다.

백그라운드 GC vs 포그라운드 GC (Direct GC)

언제 이 대청소를 할 것인가가 성능을 가르는 핵심이다.

Background GC (여유로운 청소):
- 유저가 마우스에서 손을 떼고 유튜브를 보거나 쉴 때 (Idle time).
- 컨트롤러가 몰래 깨어나 더러운 블록들을 싹 정리해 깨끗한 통짜 방(Free Block Pool)을 수천 개 쟁여둔다.
- 유저가 갑자기 10GB 파일을 저장하면, 쟁여둔 빈방에 딜레이 0초로 팍팍 꽂아버려 "와 이 SSD 미쳤네" 소리가 나오게 만든다.
Foreground GC / On-demand GC (지옥의 렉):
- 유저가 100GB짜리 영화를 한 방에 냅다 다운받는다.
- 쟁여둔 빈방이 순식간에 다 털렸다. 램 잔고가 0이 됐다.
- 당장 4KB를 더 받아야 하는데 빈방이 없다. 컨트롤러는 다운로드를 강제로 '일시 정지(Stall)'시키고, 다운받는 와중에 눈앞에서 쓰레기 블록을 털어 이사시키고 폭파(Erase)하는 대청소를 눈물을 흘리며 쌩으로 돌린다.
- 유저가 보는 다운로드 속도 막대기가 바닥으로 뚝 떨어지는 '쓰기 절벽(Write Cliff)' 현상이 바로 이 포그라운드 GC가 터졌다는 확실한 증거다.

📢 섹션 요약 비유: 손님이 식당에 안 올 때 알바생이 미리미리 빈 그릇을 다 씻어두면(백그라운드 GC) 단체 손님이 몰려와도 1초 만에 요리가 나갑니다. 하지만 알바생이 놀다가 단체 손님이 와서 그릇이 동났을 때(빈방 고갈), 손님을 카운터에 세워두고 그제야 허겁지겁 빈 그릇을 퐁퐁으로 씻고 있으면(포그라운드 GC) 손님은 빡쳐서 식당 리뷰에 별점 1점을 남깁니다(성능 폭락).

Ⅲ. 융합 비교 및 다각도 분석

비교 1: Over-Provisioning (OP) 여유 공간의 마법

GC의 속도와 쓰기 증폭(WA)을 줄이는 유일한 물리적 해결책은 **'빈 공간을 많이 남겨두는 것'**뿐이다. 공간이 빽빽할수록 이사 갈 빈집 찾기가 지옥이 되기 때문이다.

사용 상황	SSD 내 빈 공간 상태	GC의 이사(Copy) 난이도	쓰기 증폭(WA)	체감 수명과 속도
SSD 용량 99% 사용 중	꽉 차서 숨 막힘	낡은 블록에 유효 데이터(살릴 놈)가 99% 차 있음. 이놈들 다 옮기느라 토 나옴	☠️ 10배~100배 폭발	3달 안에 SSD 뻗고 속도 기어다님
SSD 용량 50% 사용 중	빈 공간 널널함	낡은 블록 까보면 50%가 이미 쓰레기임. 살릴 놈 절반만 쓱 옮기면 됨	🟢 2배 수준으로 양호	5년 쾌적하게 쌩쌩 돌아감
제조사 강제 OP 10%	유저 몰래 숨겨둔 10%	100% 꽉 채워도 숨겨진 10%의 도망갈 빈집이 무조건 보장됨	최소한 서버가 즉사하는 건 막음	벤치마크 속도를 보장하는 방파제

[핵심 교훈]: "SSD는 용량을 꽉 채워 쓰면 고장 난다"는 말이 미신이 아니라 100% 하드웨어 아키텍처(GC)에서 비롯된 진리다. 꽉 찬 SSD에서 GC를 돌리는 건, 만원 지하철에서 맨 안쪽 사람이 밖으로 빠져나가기 위해 100명의 사람을 이리저리 밀치고 자리를 바꾸는 끔찍한 오버헤드와 같다.

TRIM 명령어: 운영체제의 위대한 자백 (결정적 융합)

초기 SSD의 GC는 최악의 바보였다. OS에서 10GB 영화를 휴지통에 넣고 비워버렸다. OS 장부(NTFS)에선 파일이 날아갔지만, SSD 하드웨어는 OS의 장부를 못 읽는다. 그래서 그 10GB 공간을 "아직 유저가 소중히 아끼는 10GB 유효 데이터"로 착각하고, GC가 돌 때마다 그 10GB를 새 블록으로 낑낑대며 평생 이사(Copy)시켜주는 개삽질을 반복했다. 이를 타개하기 위해 OS가 SSD에게 **"야! 방금 나 10GB 파일 삭제했어! 너네 그 10GB LBA 주소에 있는 데이터들 싹 다 쓰레기(Invalid)로 마킹해! 이사시킬 때 버려도 돼!"**라고 귓속말을 날려주는 TRIM 명령어가 발명되었다. TRIM 덕분에 SSD는 무거운 이삿짐(삭제된 데이터)을 훌훌 버리고 홀가분하게 GC를 돌릴 수 있게 되어 SSD 역사상 가장 위대한 성능 구원자가 되었다.

📢 섹션 요약 비유: 옛날 이사업체(GC)는 집주인(OS)이 뭘 버렸는지 몰라서 방구석에 처박힌 낡은 곰 인형(삭제된 파일)까지 애지중지 새집으로 다 옮겨 담았습니다(삽질 낭비). TRIM은 집주인이 이사 전날 낡은 곰 인형에 "이거 쓰레기니까 버려!"라고 노란 딱지(TRIM)를 딱 붙여주는 겁니다. 이사업체는 딱지 붙은 건 쿨하게 놔두고 가벼운 짐만 새집에 옮기면 되니 이사 속도가 빛처럼 빨라집니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오: 빅데이터 하둡/카프카 환경의 Sequential Write (순차 쓰기) 강제

문제의 발단: 초당 수만 건의 로그가 쌓이는 백엔드 서버. 개발자가 DB 데이터를 1KB씩 무작위(Random)로 덮어쓰고 지우기를 반복했다.
GC의 파업:
- 무작위로 덮어쓰면, SSD 내부의 수만 개 블록이 벌집처럼 "쓰레기 조금, 멀쩡한 거 조금" 섞인 최악의 파편화 지옥이 된다.
- GC가 터질 때마다 파편을 주워 모으느라 서버 응답 시간이 1초씩 툭툭 끊긴다(Tail Latency 스파이크).
신의 아키텍처 (LSM Tree / Append-Only):
- 카프카나 최신 NoSQL DB 개발자들은 SSD의 이 GC 렉을 피하기 위해 덮어쓰기(Random Write) 자체를 코딩에서 완전히 금지시켜버렸다.
- 무조건 데이터의 끝에 덧붙여 쓰는 **순차 쓰기(Append-Only)**만 한다.
- 이렇게 하면 SSD 내부의 블록 1번, 2번, 3번이 순서대로 100% 꽉꽉 뭉쳐서 채워진다.
- 낡은 로그를 삭제할 때도 무작위로 안 지우고 "어제 자 로그 10GB 통째로 날려!"라고 뭉텅이로 지운다.
- 결과: SSD 블록 안에 쓰레기 100%만 존재하거나, 유효 100%만 존재하게 된다! GC가 이사(Copy)를 다닐 필요 없이 그냥 쓰레기 블록을 쿨하게 통째로 폭파(Erase)시켜버리면 끝이므로, 쓰기 증폭(WA)이 1에 수렴하며 SSD 성능이 영구기관처럼 100만 IOPS를 뿜어낸다.

📢 섹션 요약 비유: 문서 작업할 때 글자 하나 틀렸다고 그 부분만 화이트로 칠하고 다시 쓰면(랜덤 쓰기) 종이가 더러워지고 화이트 마르는 걸(GC) 기다려야 합니다. 고수들은 틀리든 말든 화이트를 안 쓰고 무조건 밑으로 죽죽 이어서 새로운 버전을 씁니다(순차 쓰기). 나중에 낡은 종이는 통째로 찢어서 휴지통에 버리면 끝이죠. SSD는 이 화이트(부분 삭제)를 극도로 혐오하는 기계입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

정량/정성 기대효과

구분	내용
Erase-before-write 한계 극복	덮어쓰기가 불가능한 플래시 메모리의 치명적 결함을, 무효화(Invalidate)와 후청소(GC)라는 백그라운드 꼼수로 가려내 유저에게 연속 쓰기의 환상 제공
SSD 수명(TBW)의 극적 보존	TRIM 명령어와 오버 프로비저닝을 결합하여 무의미한 데이터 이사(Write Amplification)를 억제, 수천 번의 낸드 수명으로 수년간 서버를 굴릴 수 있게 함
Storage 벤더의 기술 격차	이 쓰레기를 얼마나 스마트하게 묶어 버리느냐(Garbage Collection Algorithm)가 삼성, 마이크론 등 컨트롤러 칩셋 제조사의 기술력과 가격을 가르는 절대 지표

결론 및 미래 전망

가비지 컬렉션 (Garbage Collection in SSD)은 "지우는 덩치(2MB)가 쓰는 덩치(4KB)보다 비정상적으로 거대하다"는 플래시 메모리의 물리적 기형을 극복하기 위해, 컨트롤러 펌웨어가 벌이는 밤샘 노가다의 눈물겨운 현장이다. 속도라는 마약을 얻은 대가로 인류는 영원히 치워야 할 내부 쓰레기장(Invalid Page)이라는 빚을 안게 되었다. 이 빚이 쌓여 파산(쓰기 절벽)하는 것을 막기 위해 운영체제(TRIM)와 하드웨어(OP, GC)가 손을 맞잡고 빚 돌려막기의 정수를 보여준 것이 현대 스토리지의 민낯이다. 앞으로 ZNS (Zoned Namespace) SSD처럼 아예 SSD가 자체적인 GC 삽질을 포기하고, "OS 네가 직접 블록별로 순차 쓰기하고 통째로 지워라!"라며 통제권을 OS와 데이터베이스 엔진에게 직통으로 넘겨버리는 차세대 엔터프라이즈 아키텍처가 부상하면서, 이 수십 년 된 숨바꼭질 사기극(FTL GC)도 점차 투명한 최적화의 길로 그 짐을 내려놓게 될 것이다.

📢 섹션 요약 비유: 매일 밤 화려하게 쏟아지는 클럽(SSD)의 전단지(데이터) 속도에 감탄하지만, 새벽 3시가 되면 손님 모르게 클럽 구석에서 쓰레기 전단지를 줍고 테이블을 닦느라 허리가 휘는 청소부(GC)의 고통이 존재합니다. 쓰레기통(OP)을 크게 만들고, 손님들이 찢어진 전단지(TRIM)는 쓰레기라고 미리 알려준 덕분에 클럽이 내일도 미친 속도로 영업을 개시할 수 있는 보이지 않는 노동의 승리입니다.

📌 관련 개념 맵 (Knowledge Graph)

FTL (Flash Translation Layer) | GC를 진두지휘하는 SSD 내부의 대가리 펌웨어로, 가짜 주소와 진짜 주소를 연결하며 쓰레기장을 관리하는 사기꾼 칩셋
TRIM 명령어 | OS가 파일 삭제했을 때 SSD에게 "이 공간 진짜 안 쓰니까 GC 할 때 땀 흘리며 옮기지 말고 그냥 폭파시켜!"라고 알려주는 필수 소통 규약
Write Amplification (쓰기 증폭) | GC가 쓰레기 방을 치우기 위해 유효 데이터를 이리저리 이사(복사)시키느라, 1KB 쓰려다 1MB를 태워 먹으며 수명을 갉아먹는 환장할 현상
Over-Provisioning (OP) | GC가 꽉 찬 방에서 숨 막혀 죽는 걸 막기 위해, 유저 몰래 SSD 용량의 10%를 텅 빈 대피소로 짱박아두는 여유 공간
Wear Leveling (마모 평준화) | GC가 방을 지울 때, 1번 방만 불태우지 않고 골고루 100만 개 방을 돌아가며 불태워서 플래시 칩 전체 수명을 맞추는 짝꿍 기술

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

SSD 가비지 컬렉션이 뭔가요? 스케치북이 낙서(쓰레기 데이터)로 꽉 차서 더 이상 그림을 못 그릴 때, 스케치북 요정이 몰래 나타나서 대청소하는 거예요.
어떻게 대청소를 하나요? 낙서투성이인 페이지 중에 아주 조금 있는 '진짜 예쁜 그림(살아있는 데이터)'만 가위로 쏙 오려서 새 종이에 딱 붙여준 다음, 헌 종이는 통째로 불태워(Erase) 버린답니다.
언제 청소해요? 내가 잘 때(컴퓨터 안 쓸 때) 몰래 해두면 너무 좋지만, 내가 그림 그리느라 꽉 찼는데 종이가 없을 땐 어쩔 수 없이 내 눈앞에서 요정이 낑낑대며 가위질을 하느라(포그라운드 GC) 컴퓨터가 잠깐 엄청나게 느려져요!