6장. Text Analysis — Analyzer 파이프라인과 한국어 처리

"Quick"으로 검색했는데 "quick"이 담긴 문서가 나오는 이유. 문자열이 토큰으로 잘게 부서져 역색인의 키가 되는 과정 — 검색의 매칭 규칙은 전부 여기서 결정됩니다.

6.1 Analyzer 파이프라인 — 문자열이 토큰이 되기까지

text 필드에 넣은 문자열은 그대로 저장되지 않습니다. analyzer(분석기)라는 파이프라인을 거쳐 토큰(token)들로 분해되고, 각 토큰이 역색인(inverted index)의 키가 됩니다. 검색할 때 질의어도 같은 analyzer를 거치기 때문에, analyzer 설계는 곧 "무엇이 매칭되고 무엇이 매칭되지 않는지"를 결정합니다.

모든 analyzer는 정확히 3단계로 구성됩니다.

• Character filter (0개 이상) — 문자 단위 전처리. HTML 태그 제거, 문자 치환 등
• Tokenizer (정확히 1개) — 문자열을 토큰으로 쪼개는 핵심 단계
• Token filter (0개 이상) — 토큰 단위 변환. 소문자화, 불용어 제거, 동의어, 어간 추출 등

공식 문서의 유명한 예시 문자열로 전 과정을 따라가 봅시다.

6.2 내장 Analyzer — 조립 완제품들

ES는 자주 쓰는 조합을 미리 만들어 제공합니다. 어떤 analyzer가 어떤 결과를 내는지는 _analyze API로 언제든 직접 확인할 수 있습니다.

POST /_analyze
{
  "analyzer": "standard",
  "text": "The 2 Quick Brown-Foxes!"
}
// 결과 토큰: the, 2, quick, brown, foxes

6.3 Custom Analyzer — 부품을 직접 조립하기

내장 analyzer로 부족하면 char filter / tokenizer / token filter를 직접 조합합니다. "HTML을 벗기고, 표준 분할 후, 소문자화 + 영어 불용어 제거 + 어간 추출"을 하는 블로그용 analyzer는 이렇게 만듭니다.

PUT /blog
{
  "settings": {
    "analysis": {
      "char_filter": {
        "strip_html": { "type": "html_strip" }
      },
      "filter": {
        "english_stop":    { "type": "stop", "stopwords": "_english_" },
        "english_stemmer": { "type": "stemmer", "language": "english" }
      },
      "analyzer": {
        "blog_text": {
          "type":        "custom",
          "char_filter": ["strip_html"],
          "tokenizer":   "standard",
          "filter":      ["lowercase", "english_stop", "english_stemmer"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "body": { "type": "text", "analyzer": "blog_text" }
    }
  }
}

핵심 원칙: analyzer는 색인 시점과 검색 시점 모두에 적용됩니다. 의도적으로 다르게 하려면 search_analyzer를 별도로 지정합니다.

"body": {
  "type": "text",
  "analyzer":        "blog_text",    // 색인 시
  "search_analyzer": "blog_search"   // 검색 시
}

대표적인 비대칭 사용 사례가 자동완성(색인 시 edge_ngram, 검색 시 standard)입니다. 6.6에서 애니메이션으로 봅니다.

6.4 한국어 분석 — Nori 형태소 분석기

영어는 대체로 "공백 = 단어 경계"지만 한국어는 다릅니다. "검색엔진을"은 "검색엔진" + "을(조사)"로 분해되어야 "검색엔진"으로 검색했을 때 매칭됩니다. 이렇게 단어를 의미 단위(형태소)로 쪼개는 것이 형태소 분석(morphological analysis)이며, ES의 공식 한국어 플러그인이 Nori(mecab-ko-dic 기반)입니다.

# 모든 노드에 설치 후 재시작 필요
bin/elasticsearch-plugin install analysis-nori

nori analyzer는 세 부품의 조합입니다: nori_tokenizer(형태소 분해) + nori_part_of_speech(조사·어미 등 제거) + nori_readingform(한자→한글 변환). 문장이 어떻게 처리되는지 봅시다.

decompound_mode — 복합명사 처리 방식

nori_tokenizer의 가장 중요한 파라미터입니다. 복합명사를 어떻게 쪼갤지 결정합니다.

PUT /korean_news
{
  "settings": {
    "analysis": {
      "tokenizer": {
        "korean_nori_tokenizer": {
          "type": "nori_tokenizer",
          "decompound_mode": "mixed",
          "user_dictionary": "userdict_ko.txt"   // 신조어·고유명사 사전
        }
      },
      "filter": {
        "korean_pos_filter": {
          "type": "nori_part_of_speech",
          "stoptags": ["E", "IC", "J", "MAG", "MAJ", "MM",
                       "SP", "SSC", "SSO", "SC", "SE",
                       "XPN", "XSA", "XSN", "XSV", "UNA", "NA", "VSV"]
        }
      },
      "analyzer": {
        "korean_analyzer": {
          "type": "custom",
          "tokenizer": "korean_nori_tokenizer",
          "filter": ["korean_pos_filter", "nori_readingform", "lowercase"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "title": { "type": "text", "analyzer": "korean_analyzer" },
      "body":  { "type": "text", "analyzer": "korean_analyzer" }
    }
  }
}

6.5 동의어 — synonym_graph와 검색 시점 적용

"노트북"과 "랩탑"을 같은 것으로 취급하려면 synonym filter를 씁니다. 두 종류가 있는데, multi-word 동의어(new york 등)를 정확히 처리하는 synonym_graph를 권장합니다.

"filter": {
  "my_synonyms": {
    "type": "synonym_graph",
    "synonyms": [
      "노트북, 랩탑, laptop",
      "휴대폰, 핸드폰, 스마트폰",
      "ai => 인공지능"          // 단방향 매핑
    ]
  }
}

동의어를 어느 시점에 적용할지가 운영의 핵심 결정입니다.

8.x부터는 Synonyms API로 사전을 클러스터에 등록하고, updateable: true filter를 search_analyzer에만 사용하면 재색인 없이 POST /index/_reload_search_analyzers 한 번으로 사전 변경이 반영됩니다. 이것이 8.x 운영 표준입니다.

6.6 자동완성 — Edge N-gram과 비대칭 analyzer

자동완성은 "검"만 입력해도 "검색엔진"이 나와야 합니다. 비결은 색인 시점에 접두사(prefix) 토큰을 미리 만들어 두는 edge_ngram입니다.

• N-gram: "검색" → [검, 색, 검색] — 모든 위치의 조각. 강력하지만 색인 크기 폭증
• Edge N-gram: "검색엔진" → [검, 검색, 검색엔, 검색엔진] — 시작 부분의 prefix만. 자동완성에 최적

PUT /autocomplete
{
  "settings": {
    "analysis": {
      "tokenizer": {
        "edge_ngram_tokenizer": {
          "type": "edge_ngram",
          "min_gram": 1, "max_gram": 20,
          "token_chars": ["letter", "digit"]
        }
      },
      "analyzer": {
        "edge_ngram_index":  { "tokenizer": "edge_ngram_tokenizer", "filter": ["lowercase"] },
        "edge_ngram_search": { "tokenizer": "standard",              "filter": ["lowercase"] }
      }
    }
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "text",
        "analyzer":        "edge_ngram_index",
        "search_analyzer": "edge_ngram_search"
      }
    }
  }
}

6.7 _analyze API — 매칭이 안 될 때 첫 번째 디버깅 도구

"분명히 있는 문서인데 검색이 안 돼요"의 답은 거의 항상 토큰에 있습니다. 디버깅의 황금 패턴:

1. 검색어를 _analyze로 토큰화해 본다
2. 색인된 문서의 해당 필드도 _analyze로 토큰화해 본다
3. 두 토큰 집합의 교집합을 확인한다 — 교집합이 비어 있으면 매칭이 안 되는 게 당연

// 특정 필드에 지정된 analyzer로 테스트
POST /korean_news/_analyze
{
  "field": "title",
  "text":  "검색엔진을",
  "explain": true    // 단계별 토큰 변화·품사 태그까지 출력
}

explain: true를 붙이면 tokenizer → 각 filter 단계별 토큰 변화와 position, offset, 품사 태그까지 볼 수 있어 동의어·품사 필터 디버깅에 특히 유용합니다.

✍️ 이해도 체크