LSM-Tree (Log-Structured Merge-Tree) 저장 엔진

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

본질: LSM-Tree (Log-Structured Merge-Tree)는 전통적인 관계형 DB의 B-Tree가 유발하는 디스크 무작위 쓰기(Random Write)의 치명적 병목을 극복하기 위해, 모든 데이터를 메모리(MemTable)에 정렬된 상태로 모아두었다가 디스크로 한 번에 순차적으로 밀어내는(Sequential Write) 쓰기 최적화 스토리지 엔진 아키텍처다.

가치: 초당 수만 건 이상의 로그, 센서 메트릭, 대용량 트랜잭션이 쏟아지는 빅데이터 및 NoSQL 환경에서 하드웨어의 I/O 대역폭 한계를 돌파하여 압도적인 쓰기 처리량(Write Throughput)을 보장하며, 데이터베이스 락(Lock) 경합을 극단적으로 줄인다.

융합: 읽기 속도가 저하되는 LSM-Tree의 태생적 단점을 상쇄하기 위해, 디스크 탐색 비용을 0으로 만들어주는 암호학적 확률 구조인 블룸 필터(Bloom Filter) 및 주기적인 백그라운드 파일 병합(Compaction) 알고리즘과 융합되어 Cassandra, RocksDB, InfluxDB 등 현대 분산 저장소의 표준 엔진으로 자리 잡았다.

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

개념: LSM-Tree는 데이터를 수정할 때 디스크의 원래 위치를 찾아가 덮어쓰는(In-place Update) 대신, 무조건 새로운 데이터를 로그처럼 파일의 맨 끝에 덧붙여 기록(Append-only)하는 자료 구조다. 메모리 상의 정렬된 버퍼인 MemTable과 디스크에 순차적으로 기록되는 불변 파일인 SSTable(Sorted String Table)로 이원화되어 작동한다.
필요성: 관계형 데이터베이스(MySQL, Oracle)의 뼈대인 B-Tree 인덱스는 읽기(Read)에는 매우 빠르지만 데이터의 삽입/수정 시 치명적인 약점을 지닌다. ID=5를 삽입했다가 ID=1을 삽입하면 디스크 헤더가 여기저기 널뛰기를 해야 하는 '무작위 쓰기(Random Write)'가 발생한다. 여기에 페이지 분할(Page Split) 오버헤드와 락(Lock) 경합까지 더해지면, IoT나 소셜 미디어처럼 1초에 수십만 건의 데이터를 쏟아내는 환경에서는 디스크 I/O가 버티지 못하고 시스템이 마비된다. 디스크라는 물리적 매체(심지어 SSD조차도)는 무작위로 쓸 때보다 순서대로 쭉 이어서 쓸 때(Sequential Write) 수십 배 이상 빠르다. 이 물리적 특성의 한계를 소프트웨어 아키텍처로 우회하기 위해 발명된 것이 바로 극단적 쓰기 중심형 엔진인 LSM-Tree다.
등장 배경 및 기술적 패러다임 전환: 1996년 논문으로 처음 제안된 LSM-Tree는 당시에는 큰 주목을 받지 못했다. 그러나 2000년대 후반 구글의 Bigtable 논문이 발표되고, 페이스북의 편지함 시스템 등에서 B-Tree의 한계가 명확해지면서 재조명받았다. 메모리는 저렴해졌고 데이터 유입량은 폭발하는 시대적 배경 속에서, 일단 메모리에 데이터를 다 쏟아붓고 꽉 차면 디스크에 순차적으로 덤프(Flush)해버리는 LSM-Tree의 철학은 Apache Cassandra, LevelDB, RocksDB 등 NoSQL 스토리지 엔진의 사실상 표준(De facto standard)이 되었다.

다음 다이어그램은 B-Tree의 무작위 쓰기 병목과 LSM-Tree의 순차 쓰기 메커니즘을 명확히 대조하여 패러다임의 차이를 시각화한다.

  ┌───────────────────────────────────────────────────────────────┐
  │         디스크 I/O 아키텍처 비교: B-Tree vs LSM-Tree            │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │  [A. B-Tree 엔진 (In-place Update)]                           │
  │   - 요청: ID=5 쓰기, ID=2 쓰기, ID=9 쓰기                        │
  │   - 디스크 물리 헤더 움직임:                                        │
  │     [디스크 블록] ──▶ (위치 탐색) ──▶ 블록 5에 덮어쓰기 (Random)    │
  │     [디스크 블록] ──▶ (위치 탐색) ──▶ 블록 2에 덮어쓰기 (Random) 💥 │
  │     [디스크 블록] ──▶ (위치 탐색) ──▶ 블록 9에 덮어쓰기 (Random)    │
  │   ★ 결과: 쓰기 증폭(Write Amplification)과 디스크 널뛰기로 속도 급감. │
  │                                                               │
  │  [B. LSM-Tree 엔진 (Append-only & Flush)]                     │
  │   - 요청: ID=5 쓰기, ID=2 쓰기, ID=9 쓰기                        │
  │   - 1단계 (메모리 로드):                                          │
  │     [🧠 MemTable (RAM)] ── 내부에서 자동 정렬 ──▶ [2, 5, 9]     │
  │                                                               │
  │   - 2단계 (디스크 플러시): MemTable 꽉 차면 그대로 통째로 쏟아냄        │
  │     [💾 SSTable (Disk)] ◀── [2, 5, 9] (Sequential Write) 🟢   │
  │                                                               │
  │   ★ 결과: 디스크 탐색 비용 ZERO. 로그파일 쓰듯 한 번에 쭉 밀어내어 압도적 속도. │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 도식의 핵심은 디스크가 데이터베이스의 가장 느린 병목이라는 사실을 소프트웨어가 어떻게 회피하는가에 있다. B-Tree 방식은 덮어쓰기(In-place Update)를 고집하므로 새로운 데이터가 들어오면 무조건 해당 키가 위치할 디스크 트리의 중간 가지를 찾아가야만 한다. 반면 LSM-Tree는 덮어쓰기를 혐오한다. 입력되는 데이터는 디스크를 아예 건드리지 않고, 초고속인 메모리 내의 트리(MemTable, 보통 Red-Black Tree나 Skip List 사용)에 즉각 삽입된다. 메모리 안에서는 정렬(Sorting)이 아주 값싼 연산이다. 메모리가 특정 용량(예: 64MB)에 도달하면, 내부적으로 예쁘게 정렬된 [2, 5, 9] 배열 덩어리를 디스크의 연속된 빈 공간에 단 한 번의 순차 I/O로 내려써서 SSTable (Sorted String Table)이라는 읽기 전용 파일을 만든다. 이 방식은 기존 RDBMS 대비 쓰기 성능을 최소 10배에서 많게는 100배 이상 증폭시키는 기적을 낳았다.

📢 섹션 요약 비유: 도서관에서 새로 들어온 책을 그때마다 십진분류법을 찾아 책장 중간에 끼워 넣느라 땀을 빼는 방식(B-Tree)을 버리고, 일단 오늘 들어온 책은 반납 카트(MemTable)에 막 던져두었다가 퇴근할 때 한 번에 창고(SSTable)에 순서대로 쌓아 올리는(LSM-Tree) 극강의 귀차니즘 최적화 전략과 같습니다.

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

LSM-Tree의 3대 핵심 구성 요소

LSM-Tree는 단순히 메모리에 버퍼링을 하는 것을 넘어, 유실 방지와 디스크 구조화를 위한 삼각 편대를 이룬다.

요소명 (Component)	물리적 위치	역할 및 동작 원리	비유
MemTable	RAM (인메모리)	실시간 들어오는 쓰기 요청을 키(Key) 기준으로 자동 정렬하여 임시 보관하는 레드-블랙 트리 자료구조. 읽기 요청 시 1순위로 탐색됨.	책상 위 포스트잇 메모장
SSTable	디스크 (영구 저장)	MemTable이 꽉 찼을 때 디스크로 플러시되어 생성되는 불변(Immutable) 파일. 내부 데이터가 정렬되어 있어 이진 탐색 가능.	꽉 차서 책꽂이에 꽂은 다이어리
WAL (Write-Ahead Log)	디스크 (순차 로그)	MemTable이 메모리 상에 있으므로 정전 시 날아가는 것을 방지하기 위해, 데이터 인입 즉시 디스크 맨 끝에 순차적으로 로그만 대충 갈겨써 두는 복구용 백업 파일.	비상용 임시 녹음기

쓰기(Write) 패스와 읽기(Read) 패스의 내부 실행 흐름

LSM-Tree의 생명은 쓰기의 단순함과, 그로 인해 복잡해져 버린 읽기의 과정을 어떻게 극복하는가에 있다.

  ┌──────────────────────────────────────────────────────────────────┐
  │           LSM-Tree의 Write / Read 패스 아키텍처 심층 해부           │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │  [ 쓰기 (Write Path) - 번개처럼 빠르다 ⚡ ]                        │
  │  1. 클라이언트 ──▶ (Write 요청: ID=7)                              │
  │  2. 디스크의 WAL(로그) 파일 끝에 "ID=7 추가됨" 한 줄 기록 (정전 대비용) │
  │  3. 메모리의 MemTable에 ID=7 삽입 (정렬 완료)                       │
  │  4. 클라이언트에게 "성공!" 반환 (디스크 헤더 탐색 전혀 안 함!)           │
  │     (나중에 백그라운드에서 MemTable 꽉 차면 SSTable 파일로 자동 강등 됨)│
  │                                                                  │
  │  [ 읽기 (Read Path) - 고통의 시작과 치트키 방어 🛡️ ]               │
  │  1. 클라이언트 ──▶ (Read 요청: ID=5)                               │
  │  2. 가장 먼저 메모리(MemTable) 탐색 ──▶ 없으면?                     │
  │  3. 디스크에 쌓여 있는 SSTable 파일들을 최신 것부터 과거순으로 다 뒤져야 함.│
  │     - SSTable #3 (최신) ──▶ 디스크 I/O 발생                         │
  │     - SSTable #2        ──▶ 디스크 I/O 발생                         │
  │     - SSTable #1 (과거) ──▶ 디스크 I/O 발생                         │
  │                                                                  │
  │  🚨 읽기 증폭(Read Amplification) 병목 발생! 어떻게 해결하는가?         │
  │  ✅ 치트키 1: Bloom Filter (블룸 필터)                             │
  │     "SSTable #2에 ID=5가 있어?" 묻자마자 메모리 필터가 "절대 없어!" 차단.│
  │     → 불필요한 디스크 읽기 90% 이상 스킵 (가지치기).                    │
  │                                                                  │
  │  ✅ 치트키 2: Compaction (콤팩션 - 378번 문서 참조)                 │
  │     파편화된 SSTable들을 주기적으로 뭉쳐서 하나의 큰 파일로 병합 정리.     │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 쓰기 패스(Write Path)는 로직이 매우 짧다. WAL에 로그를 떨구고(이 작업 역시 순차 쓰기라 디스크 오버헤드가 거의 0에 가깝다), 메모리의 트리에 값을 끼워 넣으면 끝난다. 클라이언트 응답 대기 시간이 1ms 언더로 떨어진다. 하지만 진짜 기술사적 고민은 읽기 패스(Read Path)에서 터진다. 데이터가 여러 개의 SSTable 파일로 나뉘어 저장되고 심지어 덮어쓰기가 안 되므로, 옛날에 지워진 값인지 최신에 업데이트된 값인지 확신할 수 없어 메모리부터 제일 오래된 디스크 파일까지 시계열 역순으로 무식하게 스캔(Read Amplification)해야 한다. 이 악몽을 구원하는 것이 **블룸 필터(Bloom Filter)**다. 블룸 필터는 해시 함수를 이용해 특정 키가 파일 내에 '존재하지 않음'을 100% 확률로 판별해 내는 인메모리 확률 구조다. 블룸 필터가 파일 접근을 쳐내주지 않았다면 LSM-Tree는 느려 터져서 상용화되지 못했을 것이다.

📢 섹션 요약 비유: 쓰기는 책상 위에 영수증을 마구 던져놓는 것처럼 빠릅니다. 하지만 옛날 영수증을 찾으려면 서랍 속에 처박힌 박스들을 다 뒤져야 하는 지옥(읽기 병목)이 열리는데, 이때 박스 겉면에 "이 박스엔 식비 영수증 없음!"이라고 적힌 강력한 해시태그(블룸 필터)가 있어서 뒤질 필요 없는 박스를 단숨에 걸러내는 원리입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

스토리지 엔진 양대 산맥: B+Tree vs LSM-Tree

데이터베이스 엔진 선택은 애플리케이션의 I/O 특성에 따라 완벽히 이분화되어야 한다.

비교 항목	B+Tree 계열 (MySQL, Oracle, PostgreSQL)	LSM-Tree 계열 (Cassandra, RocksDB, InfluxDB)
저장 철학	In-place Update (원래 자리에 덮어쓰기)	Append-only (끝에 계속 이어붙이고 병합하기)
최고 강점	빠른 읽기 (Read-optimized)	초고속 쓰기 (Write-optimized)
디스크 I/O 특성	Random Read / Random Write 발생	Sequential Write 특화 (디스크 수명 및 속도에 최적)
공간 낭비 비율	페이지 분할(Split) 시 50%의 빈 공간(Fragmentation) 발생	꽉 채워 파일로 내리므로 공간 활용도 높음 (단, 중복본 존재)
적합한 비즈니스	은행 잔고 업데이트, 소규모 다건 수정 트랜잭션, ERP	IoT 센서 로깅, 채팅 메시지 수신, 클릭 로그스트림 수집

[비교 심층 해석] B-Tree는 트리의 깊이(Depth)가 일정하게 유지되므로, 언제 어느 키를 검색하든 응답 속도가 예측 가능하고 균일하다는 장점이 있다. 즉, 전통적인 트랜잭션 워크로드(OLTP)의 제왕이다. 반면 LSM-Tree는 파일이 얼마나 파편화되어 있느냐(Compaction 상태)에 따라 1번 파일에서 찾을 수도, 10번 파일까지 뒤져야 할 수도 있어 쿼리의 상위 99% 응답 지연(Tail Latency)이 극심하게 요동친다. 대신 1초에 100만 건의 트래픽이 쏟아지는 이벤트 스트림 앞에서는 B-Tree가 데드락(Deadlock)과 디스크 큐 대기로 뻗어버리는 반면, LSM-Tree는 콧노래를 부르며 모든 데이터를 RAM으로 삼켜버린다. 현대 마이크로서비스 아키텍처(MSA)에서는 각 서비스의 성격에 맞게 두 엔진을 섞어 쓰는 폴리글랏 퍼시스턴스 (Polyglot Persistence)가 필수적인 이유다.

하드웨어 진화와의 시너지 (SSD/NVMe)

플래시 메모리 기반의 SSD는 자기 디스크(HDD)와 달리 덮어쓰기(Overwrite)를 할 때 기존 블록을 지우고(Erase) 다시 써야 하는 쓰기 증폭 페널티가 존재한다. LSM-Tree의 '절대 덮어쓰지 않고 파일 끝에 순차적으로 이어붙이는(Append-only)' 성질은 SSD의 마모도(Wear-leveling)를 줄이고 하드웨어 수명을 비약적으로 연장시키는 완벽한 하드웨어-소프트웨어 시너지를 발휘한다.
📢 섹션 요약 비유: B+Tree는 꼼꼼하게 정리되어 있어 언제든 1분 안에 책을 찾을 수 있는 정통 도서관이라면, LSM-Tree는 트럭으로 쏟아지는 책을 창고 빈 공간에 미친 듯이 쌓아 올리는 데 특화된 대형 물류 창고입니다. 물류 창고에서 책을 빨리 찾기 위해 필요한 것이 블룸 필터라는 재고 장부입니다.

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

실무 시나리오 및 의사결정

시나리오 — 피크 타임 쓰기 지연(Write Stall) 및 메모리 초과 장애: 대규모 광고 클릭 로깅 시스템(RocksDB 기반)에서 트래픽이 3배로 폭증하자, MemTable이 너무 빨리 가득 차버렸다. 디스크로 파일을 내리는 Flush 속도가 데이터를 받아내는 속도를 따라가지 못하자, DB 엔진이 자체 보호를 위해 클라이언트의 쓰기 요청을 멈춰버리는 끔찍한 쓰기 스톨(Write Stall) 현상이 발생해 메시지 큐(Kafka)까지 연쇄 장애가 터졌다.
- 의사결정: MemTable의 개수 한도(max_write_buffer_number)를 늘리고 버퍼 사이즈를 키워 메모리에서 버퍼링할 수 있는 여유 공간(댐)을 확장한다. 동시에 Flush를 담당하는 백그라운드 스레드 수(max_background_flushes)를 늘려 디스크로 물을 빼는 배수구의 크기를 넓혀주는 파라미터 튜닝을 통해 트래픽 스파이크를 흡수하는 아키텍처 조정을 수행해야 한다.
안티패턴 — 잦은 업데이트(Update) 워크로드에 LSM-Tree 도입: 회원 정보 테이블처럼 '최초 가입(Insert) 1번' 이후 비밀번호 변경, 포인트 변경 등 '업데이트(Update)가 100번' 일어나는 워크로드에 Cassandra를 고집하는 행위.
- 결과: LSM-Tree는 덮어쓰기가 안 되므로 업데이트 명령이 들어올 때마다 새로운 로우(Row)를 계속 추가한다. 한 회원의 정보가 디스크에 100줄로 중복 저장(Space Amplification)되고, 이를 찾기 위해 시스템 자원이 낭비된다. 업데이트가 잦은 원장성 도메인은 반드시 B-Tree 기반의 RDBMS를 선택하는 것이 올바른 기술사적 판단이다.

스토리지 엔진(B-Tree vs LSM-Tree) 선택 의사결정 트리

아키텍처 설계 초기에 비즈니스 트래픽 비율을 파악하지 못하면 돌이킬 수 없는 재앙을 낳는다.

  ┌───────────────────────────────────────────────────────────────────┐
  │           데이터베이스 스토리지 엔진 아키텍처 선택 의사결정 트리            │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [새로운 마이크로서비스용 DB 엔진 설계]                                 │
  │                │                                                  │
  │                ▼                                                  │
  │      워크로드의 I/O 특성: 읽기와 쓰기의 비율은 어떠한가?                 │
  │          ├─ 읽기(Read)가 압도적으로 많음 (80% 이상)                     │
  │          │      └──▶ [ B-Tree 기반 RDBMS (MySQL, PostgreSQL) 채택 ] │
  │          │                                                        │
  │          └─ 쓰기(Write)가 압도적으로 많음 (센서, 로그, 이벤트 등)          │
  │                │                                                  │
  │                ▼                                                  │
  │      데이터의 수정(Update) 패턴이 어떠한가?                            │
  │          ├─ 한 번 쓰이면 잦은 덮어쓰기(Update)가 일어난다.               │
  │          │      └──▶ [ B-Tree 계열 유지 (Update 페널티 회피) ]         │
  │          │                                                        │
  │          └─ 시계열처럼 한 번 쓰이면 과거 데이터는 수정될 일이 없다.        │
  │                │                                                  │
  │                ▼                                                  │
  │     [ LSM-Tree 기반 DB (Cassandra, RocksDB, TSDB) 전격 도입! ]    │
  │       (초당 수십만 건의 Insert 트래픽을 Lock 없이 완벽히 소화 가능)      │
  │                                                                   │
  │   판단 포인트: "LSM-Tree는 Append-only 워크로드에서 신이 내린 무기지만,  │
  │                Update 중심 워크로드에서는 저주받은 무덤이 된다."         │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 트리는 백엔드 엔지니어들이 유행(Hype)에 휩쓸려 NoSQL을 맹목적으로 도입하는 안티패턴을 경계하기 위해 존재한다. LSM-Tree의 우아함은 오직 데이터가 시계열 형태로 쏟아지거나 삽입 위주의 불변(Immutable) 이벤트 스트리밍일 때만 빛을 발한다. 만약 금융 계좌의 잔액 갱신처럼 읽고(Read) 검증한 뒤 수정(Update)하는 트랜잭션이 잦다면, 읽기 증폭으로 인한 레이턴시 지연과 수백 개의 중복 쓰레기 데이터를 양산하는 구조적 결함이 터져 나온다. 기술사적 관점에서 엔진의 선택은 '얼마나 빠른가'가 아니라 '데이터의 변이 성질(Mutation Nature)과 물리적 저장 철학이 일치하는가'를 따지는 것이다.

📢 섹션 요약 비유: 못을 박을 때는 망치(LSM-Tree)가 최고고 나사를 돌릴 때는 드라이버(B-Tree)가 최고입니다. 둘 다 공구함에 꼭 필요한 장비지만, 용도를 헷갈려 망치로 나사를 때려 박으려 하면 나무(시스템)만 부서지게 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	B-Tree (RDBMS) 단독 운영 시	LSM-Tree 엔진 도입 시	개선 효과
정량	고부하 쓰기 발생 시 IOPS 1만/초 한계 병목	메모리 플러시 기반 순차 쓰기로 병목 해소	쓰기 처리량(Write Throughput) 최대 10~50배 향상
정성	인덱스 B+Tree 재편성에 따른 Lock 대기 발생	MemTable 독립 추가로 인한 무잠금(Lock-free) 쓰기	트래픽 스파이크 시 앱 단의 타임아웃/스레드 고갈 방지
정성	빈번한 랜덤 쓰기로 인한 플래시 메모리 훼손	Append-only 기록으로 마모도 최소화	SSD/NVMe 스토리지의 하드웨어 수명 연장 및 호환

미래 전망

RocksDB의 사실상 천하통일: 독자적인 엔진을 개발하던 수많은 분산 데이터베이스(Kafka Streams, TiDB, CockroachDB 등)가 백엔드 스토리지 엔진으로 Meta(구 Facebook)에서 오픈소스로 공개한 고성능 LSM-Tree 구현체인 RocksDB를 플러그인 형태로 가져다 쓰는 표준화(Standardization)가 완전히 굳어지고 있다.
NVM / PMEM 등 차세대 비휘발성 메모리 융합: 전원이 꺼져도 데이터가 날아가지 않는 비휘발성 메모리(PMEM)가 발전하면서, WAL(로그 파일)을 디스크에 쓰는 마지막 한 줌의 오버헤드마저 생략하고 메모리에서 곧바로 영속성을 보장받아 레이턴시를 획기적으로 낮추는 차세대 LSM 아키텍처 연구가 활발히 진행 중이다.

참고 표준

Log-Structured Merge-Tree (O'Neil et al., 1996): LSM 트리의 학술적 근간이 된 오리지널 논문
Google Bigtable Paper (2006): SSTable과 MemTable 구조를 상용화하여 대규모 분산 데이터 저장의 표준을 제시한 아키텍처 규격

세상에 만능 데이터베이스는 없다. 오직 물리적 매체(디스크, SSD)가 가진 '순차 작업은 빠르고, 무작위 작업은 느리다'는 하드웨어의 불변하는 법칙을 소프트웨어적으로 얼마나 영리하게 우회했는가의 차이만 존재한다. LSM-Tree는 읽기의 고통과 콤팩션의 부하라는 대가를 과감히 지불하고 쓰기 속도의 극한을 추구한 트레이드오프의 예술 작품이다. 인스타그램의 쏟아지는 피드, 스마트 팩토리의 수십억 개 센서 데이터가 초당 지연 없이 데이터 레이크에 저장될 수 있는 기적의 이면에는 이 Append-only 구조의 묵묵한 순차 쓰기 노동이 숨어 있다.

📢 섹션 요약 비유: 물탱크에 쏟아지는 폭우(데이터)를 감당하기 위해 조그만 파이프로 물을 졸졸 빼내는 대신(랜덤 쓰기), 일단 거대한 수영장(메모리 버퍼)에 다 받아두고 수문이 꽉 차면 한 방에 바다로 폭포수처럼 쏟아버리는(LSM-Tree 플러시) 압도적 스케일의 배수 시스템과 같습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
MemTable / SSTable	LSM-Tree를 물리적으로 구성하는 심장으로, 실시간 메모리 버퍼와 디스크의 읽기 전용 스냅샷의 역할을 분담한다.
블룸 필터 (Bloom Filter)	데이터가 디스크(SSTable)에 '존재하지 않음'을 초고속으로 판별해 내어, LSM의 고질적 병목인 읽기 증폭(Read Amplification)을 방어하는 수학적 치트키다.
콤팩션 (Compaction)	끝없이 쌓이는 다수의 SSTable 파일을 백그라운드에서 주기적으로 병합(Merge)하고 중복/삭제 마크를 정리해 읽기 성능을 복구해 주는 짝꿍 기술이다.
WAL (Write-Ahead Log)	MemTable이 정전 시 증발하는 약점을 막기 위해, 데이터 인입 즉시 디스크 맨 끝에 대충 남겨두는 복구용(Recovery) 순차 로그 파일이다.
RocksDB	LSM-Tree 개념을 극한으로 최적화한 C++ 오픈소스 라이브러리로, 수많은 분산 스트리밍 시스템과 NewSQL의 하단 저장 엔진으로 통합되고 있다.

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

전통적인 방식(B-Tree)은 새 단어가 생길 때마다 두꺼운 사전의 가나다순 위치를 힘겹게 찾아서 억지로 끼워 넣고 고쳐 쓰는 방식이에요. 쓰다가 지치죠.
LSM-Tree는 새 단어가 생기면 순서 상관없이 일단 책상 위 연습장(메모리)에 막 적어둬요. 쓰기가 번개처럼 빠르죠!
연습장이 꽉 차면 그걸 통째로 예쁘게 정렬해서 커다란 공책(SSTable) 맨 뒷장에 한 번에 풀로 딱! 붙여버린답니다. 찾을 때 조금 뒤져야 하는 단점은 있지만 쓰는 속도는 세상에서 제일 빨라요!