---
type: research
tags: [research, rag, korean, mecab, pg_trgm, fts, postgresql, hybrid-search, reranking]
status: closed
closed_date: 2026-03-23
closed_reason: pg_trgm 1순위 결정 확정, 23서버 설치 완료, keyword 0건 해소 실측 확인. MeCab-ko 비권장 판단 유지.
research_target: 한국어 키워드 검색의 근본 해결책 재평가 — MeCab-ko의 2026년 현실, pg_trgm, 하이브리드+리랭킹 패러다임 전환
---

# 260323 한국어 키워드 검색 근본 해결 리서치 (2차)

## 목적

- keyword 단독 검색 0건의 근본 원인에 대한 해결책을 재평가한다.
- MeCab-ko의 2026년 현실(유지보수 중단, 사전 노후)을 반영한다.
- 현재 로빙이 **이미 pgvector + 하이브리드 검색을 운용 중**이라는 사실을 전제로, 키워드 축만 보완하는 방향을 정한다.

## 근본 원인 (확정, 변경 없음)

PostgreSQL `simple` 토크나이저의 한국어 구조적 한계. 공백 기준 토큰화로 조사 결합·복합명사가 하나의 lexeme이 되어 검색어와 불일치.

## MeCab-ko의 2026년 현실

- **사실상 유지보수 중단 상태**. 한국어 신조어, 복합 명사에 대한 사전 업데이트가 멈춤.
- Company X 고유명사(투자조합명, 기업명)를 사전에 추가하려면 직접 관리해야 함.
- PG14 EOL(2026-11) 이후 PG16 마이그레이션 시 `textsearch_ko` 빌드 호환성 미보장.
- 최신 Python 기반 토크나이저(Kiwi 등)나 Rust 기반 대안이 등장했으나, DB 엔진 레벨 통합은 별도 개발 필요.
- **결론: DB 엔진 레벨에서 MeCab-ko에 의존하는 것은 과거의 유산에 시스템의 운명을 맡기는 것.**

## 로빙의 현재 검색 구조 (이미 구현)

로빙은 이미 다음을 운용 중이다:

| 기술 | 역할 | 상태 |
|------|------|------|
| pgvector (768d, Gemini) | 벡터 의미 검색 | ✅ 운용 중 |
| tsvector (simple + prefix) | 키워드 검색 | ⚠️ 부분 동작 (한국어 한계) |
| Apache AGE | 그래프 관계 확장 | ✅ 운용 중 |
| RRF 합산 + 정규화 | 하이브리드 점수 통합 | ✅ 운용 중 |
| 파일명 보조 검색 | 이미지 PDF 보완 | ✅ 운용 중 |

**현재 hybrid 모드에서 17/17 통과(100%).**  벡터 검색이 키워드의 빈자리를 메우고 있음.

문제는 **keyword 단독 축이 죽어 있어 하이브리드의 한 축이 기여하지 못한다**는 것. 벡터가 못 잡는 고유명사·정확 매칭에서 keyword가 보완해야 하는데 그 역할을 못 함.

## 해결책 재평가

### ~~1순위: MeCab-ko~~ → 비권장

- 2026년 현실에서 MeCab-ko를 새로 도입하는 것은 시간 대비 효과가 낮음
- 사전 관리 부담, PG14 EOL, 유지보수 중단 상태
- 이미 벡터 검색이 의미론적 매칭을 담당하고 있어 형태소 분석의 가치가 상대적으로 하락

### 1순위: pg_trgm (키워드 축 복구)

- `CREATE EXTENSION pg_trgm` + `GIN(gin_trgm_ops)` 인덱스
- 형태소 분석 없이 3-gram 글자 단위 매칭으로 0건 방지
- 기존 RRF 합산에 trgm similarity를 추가 축으로 편입
- **이것은 "토크나이저를 교체"하는 것이 아니라 "키워드 매칭 경로를 추가"하는 것**
- simple 토크나이저의 한계를 우회하는 것이 아니라, **다른 매칭 엔진을 병렬로 붙이는 것**

| 항목 | 내용 |
|------|------|
| Recall | 높음 (글자 조각 매칭, 0건 방지) |
| Precision | 중간 (짧은 검색어에서 노이즈, 긴 검색어에서 정확) |
| 설치 비용 | 낮음 (`CREATE EXTENSION` 1줄) |
| PG14 호환 | 기본 내장 |

### 2순위: Cross-Encoder 리랭킹

- pgvector + pg_trgm이 후보를 뽑으면, LLM/Cross-Encoder가 최종 관련성을 재판정
- 현재 LLM이 `_call_llm_companyx_grounding()`에서 이미 하고 있음 (컨텍스트 보고 답변 가능 여부 판단)
- 검색 단계의 리랭킹(검색 결과 재정렬)은 아직 미구현

### 장기: 검색 패러다임

2026년 검색 표준은 **BM25(키워드) + Vector(의미) 하이브리드 + 리랭킹**이다. 로빙은 이미 Vector + 하이브리드 구조를 가지고 있고, 키워드 축만 pg_trgm으로 복구하면 이 표준에 근접한다.

## 최종 판단

| 기준 | MeCab-ko | pg_trgm | 현재 벡터(pgvector) |
|------|----------|---------|-------------------|
| 2026년 권장 | ❌ 비권장 | ✅ 키워드 축 복구 | ✅ 이미 운용 중 |
| 0건 방지 | ✅ | ✅ | ✅ (의미 매칭) |
| 고유명사 정확 매칭 | 사전 의존 | ✅ (글자 매칭) | ❌ (의미 유사도) |
| 설치/유지 | 높음/높음 | 낮음/낮음 | 완료 |

**결론: pg_trgm을 키워드 축으로 추가하고 기존 RRF에 편입. MeCab-ko는 도입하지 않는다.**

## pg_trgm의 2026년 위상 — LLM 시대에서의 생존 근거

LLM(벡터 검색)이 '의미'를 찾는 레이더라면, pg_trgm은 '철자'를 긁어모으는 저인망 그물이다.

### 왜 LLM에 잠식되지 않았나

1. **고유명사 실종 방지**: LLM은 "아크로셀"을 검색하면 "바이오 셀", "나노 셀" 등 의미 유사 결과를 가져올 수 있다. pg_trgm은 `[아크, 크로, 로셀]` 글자 조각만 보므로 정확한 그 단어를 물리적으로 매칭한다.
2. **결정론적 신뢰성**: AI는 확률로 답하지만 pg_trgm은 규칙으로 답한다. "왜 이 결과가 안 나오나?"에 인덱스 구조로 명확히 설명 가능.
3. **Edge Case 처리**: 일련번호("A-123-X"), 투자조합 번호, 코드 검색에서 LLM은 거의 무용지물. 23서버의 고유명사 0건 이슈를 해결할 유일한 열쇠.
4. **가성비**: 수만 건 데이터를 매번 임베딩하는 것보다 pg_trgm 인덱스 하나로 1차 필터링하는 것이 운영 비용 면에서 압도적 유리.

### 2026년 하이브리드 검색 표준에서의 역할

| 구분 | 벡터 검색 (pgvector) | Trigram 검색 (pg_trgm) |
|------|---------------------|----------------------|
| 핵심 가치 | 문맥·의미 파악 (Semantic) | 오타 교정·부분 일치 (Lexical) |
| 역할 | "주주총회 의제" 관련 내용 찾기 | "아크로셀" 고유명사 강제 매칭 |
| 비용/속도 | 높음 (임베딩 API 비용) | 매우 낮음 (로컬 CPU) |
| 결과 보장 | 유사도 낮으면 결과가 산으로 감 | 0건 사태를 방지하는 최후의 수단 |

**로빙에 대입하면**: pgvector는 검색의 '뇌', pg_trgm은 검색의 '눈'과 '귀'. 23서버의 0건 이슈는 뇌의 문제가 아니라 눈이 나빠서(토크나이저 한계) 단어를 못 본 것이다.

## Unresolved

- pg_trgm 인덱스 크기가 3,474 → 5만 청크 확장 시 어느 수준인지
- trgm similarity threshold 최적값 (0.1? 0.3?)
- Cross-Encoder 리랭킹 도입 시점과 모델 선택

## 관련 문서

- [260323 keyword 단독 검색 0건 트러블](../../troubleshooting/260323_companyx_rag_keyword_단독검색_전질의_0건.md)
- [260323 PostgreSQL simple FTS 한국어 한계 요약](./260323_PostgreSQL_simple_FTS_한국어_키워드검색_한계_및_대안_요약.md)
