쉽게 이해하기

큰 텍스트 컬럼을 행마다 훑으면 느립니다. 역색인은 방향을 뒤집어 용어→문서 목록을 저장해, 사전에서 용어를 찾고 바로 해당 포스팅 리스트로 점프합니다. 많은 질의가 원문을 읽지 않고도 사전+포스팅만으로 처리됩니다.

비유와 예시

• 책의 찾아보기: 단어(예: wind)를 찾으면 그 단어가 있는 페이지 목록이 나옵니다. DB에서는 용어→문서 ID 목록이 같습니다.
• 운영 로그 필터: "timeout AND 500"이면 두 용어의 포스팅 리스트를 교집합합니다. 예: timeout=[12,15,99], 500=[15,50,99] → [15,99].
• 빠른 단일 용어 응답: 일부 구현은 단일 용어의 상위 N 후보를 별도 표로 보관해 전체 리스트 스캔을 피합니다.

한눈에 비교

	Inverted Index	Bloom Filter Index	Full Scan
결과	정확한 문서 ID(옵션: TF/오프셋)	존재 가능성(가양성)	전 행 평가
질의	AND/OR/구문/NEAR	제한적	임의 조건(느림)
저장	사전+포스팅(인덱스만으로 답 가능)	비트셋/해시 요약	인덱스 없음
튜닝	사전/블록/압축, 스킵·스코어	해시 수/크기	거의 없음

어디서 왜 중요한가

• 원격 오브젝트 스토리지: 작은 임의 읽기가 비싸므로 사전 블록화+순차 읽기, 포스팅 연속 저장으로 왕복을 줄입니다.
• 검색 엔진/인메모리 모듈: docID를 delta+varint로 압축해 메모리·대역폭을 절감하고, 스킵/스코어 보조 색인으로 교집합·상위 N을 가속합니다.
• 정보검색(IR) 실무: 포스팅은 docID 정렬·연속 저장, 사전은 토큰→오프셋 매핑과 빈도 통계를 유지합니다.

자주 하는 오해

• ❌ 본문을 항상 읽어야 한다 → ✅ 많은 질의가 사전+포스팅만으로 해결됩니다.
• ❌ 블룸 필터면 충분하다 → ✅ 블룸 필터는 가양성이 있어 추가 확인 스캔이 필요합니다.
• ❌ 사전은 해시맵이면 끝 → ✅ FST나 블록+front‑coding 등 레이아웃 선택이 I/O 패턴을 좌우합니다.

대화에서는 이렇게

• "텍스트 컬럼을 역색인으로 바꿔 후보 읽기를 줄이죠. 사전 블록 크기도 튜닝해야 해요."
• "이건 AND 교집합만 계산하면 돼서 원문은 안 열어도 됩니다."
• "docID는 delta+varint로, 길게 늘어선 리스트엔 스킵 테이블을 둡니다."
• "구문 검색이 느린 건 위치 오프셋을 안 저장해서예요."

함께 읽으면 좋은 용어

• 유사
  Bloom Filter — 가양성을 허용하는 존재 판정용.
• 기초
  Forward Index — 문서→용어 관점.
• 심화
  Trie/FST — 사전 압축·탐색 구조.
• 심화
  Skip List(포스팅) — 교집합 가속용 점프 포인터.
• 심화
  TF‑IDF — 역색인 위 랭킹에 흔히 사용.