SSD에 '제대로' 쓰는 법: 데이터베이스 엔지니어들이 다시 발견한 디스크의 진실

우리가 SSD를 너무 단순하게 봤다는 이야기

개발자들끼리 흔히 이런 농담을 해요. "이제 디스크는 빠르니까 신경 안 써도 돼". HDD 시절에는 디스크 I/O를 줄이려고 별의별 최적화를 다 했지만, SSD가 보편화되면서 그런 고민이 많이 사라졌거든요. 그런데 이번에 VLDB(데이터베이스 학계에서 가장 큰 학회 중 하나예요)에 발표된 한 논문이 이런 분위기에 제동을 걸었어요. 제목이 아예 "How to Write to SSDs"인데, 풀어서 말하면 "여러분, SSD에 쓰는 방법을 다시 배워야 합니다"라는 거예요.

왜 지금 이런 이야기가 나올까요? 클라우드 환경에서 NVMe SSD가 표준이 되면서, 데이터베이스나 스토리지 엔진이 SSD의 특성을 무시하면 성능과 수명 양쪽에서 손해를 본다는 게 점점 분명해졌거든요. 특히 RocksDB, PostgreSQL, MySQL 같은 시스템을 운영하는 회사들이 "왜 우리 SSD는 1년만에 닳지?" 하고 의문을 가지기 시작했어요.

SSD가 HDD와 정말 다른 점

이게 뭐냐면, SSD는 내부적으로 '페이지(page)'와 '블록(block)' 단위로 데이터를 다뤄요. 페이지는 보통 4KB~16KB 정도의 작은 단위이고, 블록은 그 페이지가 수백 개 모인 큰 덩어리예요. 핵심은 이거예요. SSD는 페이지 단위로 읽고 쓸 수 있지만, 지울 때는 반드시 블록 단위로만 지울 수 있어요. 그래서 "이 한 페이지만 수정할게" 같은 게 불가능해요. 새 위치에 쓰고, 옛날 위치는 "무효" 표시만 해두는 식으로 동작하거든요.

그러다 보면 무효 표시된 페이지가 블록 곳곳에 흩어지게 되는데, 이걸 정리하려면 "가비지 컬렉션"이라는 작업을 해요. 살아있는 페이지들을 다른 블록으로 옮기고 원래 블록을 통째로 지우는 거죠. 이때 발생하는 게 그 유명한 Write Amplification(쓰기 증폭)이에요. 우리가 1MB 쓰겠다고 했는데 SSD 내부에서는 실제로 3MB, 5MB가 쓰여지는 현상이요. 이게 심해지면 SSD 수명도 짧아지고 성능도 들쭉날쭉해져요.

논문이 제안하는 새로운 쓰기 전략

이 논문의 핵심은 "애플리케이션이 SSD에게 힌트를 주면 훨씬 효율적으로 쓸 수 있다"는 거예요. 최근 NVMe 표준에 추가된 FDP(Flexible Data Placement), 그리고 그 전에 등장했던 ZNS(Zoned Namespaces) 같은 기술들이 이런 힌트를 주고받는 통로 역할을 해요.

예를 들어 데이터베이스가 "이 데이터는 자주 바뀔 거야", "이 데이터는 한 번 쓰면 거의 안 바뀔 거야" 하고 SSD한테 알려주는 거예요. 그러면 SSD는 비슷한 수명을 가진 데이터끼리 같은 블록에 모아 두거든요. 그러면 가비지 컬렉션 때 "살아있는 페이지를 다른 데로 옮기는" 비용이 확 줄어들어요. 논문에서는 이런 접근으로 쓰기 증폭을 1에 가깝게(즉, 거의 증폭 없이) 만들 수 있다는 걸 실험으로 보여주고 있어요.

또 하나 흥미로운 포인트는 LSM 트리(RocksDB나 LevelDB가 쓰는 자료구조예요) 같은 구조와 SSD의 궁합 이야기예요. LSM 트리는 원래 "쓰기를 차곡차곡 모아서 큰 덩어리로 디스크에 내보내자"는 철학이라 SSD와 잘 맞을 것 같지만, Compaction 과정에서 의외로 쓰기 증폭이 심해요. 논문은 이걸 SSD 내부 구조와 어떻게 정렬시킬지에 대한 구체적인 방법론을 제시해요.

비슷한 흐름과 업계 위치

사실 이런 방향성은 새로운 건 아니에요. 몇 년 전부터 "호스트 관리형 SSD"라는 개념이 있었거든요. Western Digital이 ZNS를 밀었고, NVMe 컨소시엄은 FDP를 표준화했어요. Meta는 이미 자기네 캐시 시스템 CacheLib에서 FDP를 적용해 SSD 수명을 크게 늘렸다고 발표한 적이 있어요. Google도 비슷한 결의 논문을 여러 차례 내놨고요.

이번 VLDB 논문은 이런 개별 사례들을 묶어서 "데이터베이스 시스템 설계자라면 이렇게 접근해야 한다"는 가이드를 정리했다는 데 의미가 있어요. 단순히 "SSD 좋아요"가 아니라 "SSD를 진짜 잘 쓰려면 추상화 한 겹을 더 벗겨내야 한다"는 메시지인 셈이죠.

한국 개발자에게는 어떤 의미일까

당장 백엔드 엔지니어 대부분이 NVMe 명령어를 직접 다룰 일은 없을 거예요. 그건 RDS나 클라우드 스토리지 서비스가 알아서 해주거든요. 하지만 두 가지 측면에서 알아둘 가치가 있어요.

첫째, 자체 스토리지 인프라를 가진 회사라면 — 예를 들어 대규모 캐시, 검색 인덱스, 시계열 DB를 직접 운영하는 곳이라면 — FDP 지원 SSD를 도입했을 때 비용을 크게 줄일 수 있어요. 쿠팡, 네이버, 카카오처럼 데이터 규모가 큰 회사들의 인프라 팀에서는 이미 검토하고 있을 가능성이 높고요.

둘째, 데이터베이스 엔진을 깊이 이해하고 싶은 개발자에게는 정말 좋은 교재예요. "내가 짠 코드의 fwrite() 한 줄이 실제 디스크에서 어떻게 풀어지는가"를 따라가 보면, 운영체제와 하드웨어 사이의 추상화가 얼마나 두꺼운지 체감할 수 있거든요. 시니어로 성장하려면 이런 "한 층 더 내려가 보는 경험"이 결국 차이를 만들어요.

마무리

SSD는 더 이상 그냥 "빠른 디스크"가 아니에요. 잘 쓰면 수명도 늘고 비용도 줄지만, 모르고 쓰면 1년 만에 닳아버리는 까다로운 친구예요. 이번 논문은 그 사이의 간극을 메우려는 진지한 시도예요.

여러분 회사의 SSD는 지금 어떤 패턴으로 쓰이고 있나요? 혹시 "디스크는 어차피 빠르니까" 하면서 신경 안 쓰고 있던 부분은 없으셨나요?