Elasticsearch 매핑과 분석기

매핑은 필드의 저장·색인 방식을 정하고, 분석기는 전문 검색에 사용할 토큰을 만듭니다.

매핑이 검색 품질을 먼저 정한다

Elasticsearch에서 매핑(Mapping)은 JSON 문서의 각 필드를 어떤 타입으로 저장하고 색인할지 정의하는 스키마입니다. 관계형 데이터베이스의 테이블 스키마와 비슷하지만, 내부의 Lucene 엔진이 각 필드를 어떻게 분석하고 색인할지까지 제어합니다. 같은 문자열이라도 매핑에 따라 전문 검색 대상이 되기도 하고, 정확 매칭 전용이 되기도 합니다.

필드 타입이 잘못되면 원하는 쿼리가 동작하지 않거나 불필요한 메모리를 사용합니다. 쿼리 조정만으로 매핑 오류를 해결하기는 어렵습니다. 따라서 설계 단계에서 예상 검색어 패턴을 먼저 정리합니다.

동적 매핑과 정적 매핑

매핑을 만드는 방법은 두 가지입니다. 동적 매핑(Dynamic Mapping)은 사전에 정의하지 않은 문서가 들어올 때, 값의 형태를 보고 타입을 자동으로 추론하는 방식입니다. 데이터 모델이 확정되지 않은 초기 단계에서 적재 속도를 높여 줍니다.

새 필드가 무제한으로 늘거나 날짜처럼 보이는 문자열이 날짜형으로 잡히면 운영 문제가 생길 수 있습니다. 숫자 문자열의 수치형 추론은 기본값이 false인 numeric_detection을 켰을 때만 일어납니다. 세부 규칙은 동적 매핑 문서를 따릅니다.

정적 매핑은 인덱스를 만들 때 필드 타입, 분석기, 멀티 필드 여부를 선언합니다. 표의 세 전략은 함께 사용할 수 있습니다. 예를 들어 핵심 필드는 정적으로 고정하고, 나머지 필드에는 동적 매핑을 제한적으로 허용합니다.

자주 쓰는 필드 타입

문자열 외에도 검색 의도에 맞춰 타입을 나눕니다.

• text: 전문 검색 대상입니다. 분석기를 거쳐 토큰으로 쪼개집니다.
• keyword: 정확한 매칭, 집계, 정렬에 씁니다. 값을 통째로 저장합니다.
• date: 시간 기반 필터와 분석에 씁니다.
• numeric(integer, long 등): 범위 필터와 수치 집계에 씁니다.
• dense_vector: 임베딩 기반 벡터 검색에 씁니다.

타입 선택의 핵심은 그 필드로 무엇을 할지입니다. 본문처럼 '안에 든 단어'를 찾아야 하면 text가 맞고, 상태값처럼 '값 자체'로 거르거나 묶어야 하면 keyword가 맞습니다.

text와 keyword, 그리고 멀티 필드

text와 keyword는 분석기를 사용하는지에 따라 다릅니다. text 필드는 분석기를 거쳐 여러 토큰으로 나뉘므로 문장 속 단어를 찾는 match 쿼리에 적합합니다. keyword 필드는 값을 나누지 않고 통째로 색인하므로 정확 매칭, 집계, 정렬에 적합합니다.

한 필드를 두 용도로 모두 써야 할 때 멀티 필드(Multi-field)를 씁니다. 같은 문자열을 text로도, 하위 필드 keyword로도 동시에 색인하는 패턴입니다.

아래는 Kibana Dev Tools Console에 입력하는 요청 예시입니다.

PUT /products
{
  "mappings": {
    "properties": {
      "name": {
        "type": "text",
        "fields": {
          "keyword": { "type": "keyword" }
        }
      },
      "price":      { "type": "integer" },
      "created_at": { "type": "date" }
    }
  }
}

이렇게 두면 name으로는 전문 검색을, name.keyword로는 정확 매칭과 집계를 합니다. 다만 같은 값을 두 번 색인하므로 저장 비용이 늘어, 두 용도가 모두 필요한 필드에만 적용합니다.

term은 검색어를 분석하지 않으므로, text 필드에 원문을 그대로 보내면 저장된 토큰과 맞지 않을 수 있습니다.

분석기 파이프라인

분석기(Analyzer)는 원문 텍스트를 검색 가능한 토큰으로 가공하는 단계입니다. 세 구성 요소를 순서대로 거칩니다.

flowchart LR
  A[원문 텍스트<br/>raw text] --> B[Character Filter<br/>문자 전처리]
  B --> C[Tokenizer<br/>토큰 분리]
  C --> D[Token Filter<br/>토큰 가공]
  D --> E[역색인<br/>Inverted Index 저장]

• Character Filter: 토크나이저에 닿기 전 문자열을 다듬습니다. HTML 태그 제거나 문자 치환 같은 작업을 합니다.
• Tokenizer: 문자열을 의미 단위인 토큰으로 분해합니다. 기본값 Standard Tokenizer는 Unicode 단어 경계 규칙을 따릅니다.
• Token Filter: 쪼개진 토큰을 가공합니다. 소문자 변환(Lowercase), 불용어 제거, 동의어 병합, 어근 추출(Stemming)이 여기서 일어납니다.

분석기 파이프라인을 통과한 토큰은 역색인(Inverted Index)에 등록됩니다. 역색인은 각 토큰과 그 토큰이 등장하는 문서 목록을 연결합니다. 따라서 전체 문서를 읽지 않고도 해당 문서 목록을 반환할 수 있습니다. 이 구조 덕분에 대용량에서도 전문 검색을 빠르게 수행합니다.

색인 토큰과 검색 토큰은 서로 매칭할 수 있어야 하지만 분석기가 같을 필요는 없습니다. 검색 시점 동의어나 자동 완성에는 별도의 search_analyzer를 쓸 수 있습니다. search_analyzer 문서처럼 대표 검색어의 토큰 결과를 비교해 설계합니다.

한국어 검색과 nori

Standard Tokenizer는 한국어 형태소 분석을 하지 않습니다. '삼성전자의'처럼 조사가 붙은 단어와 '삼성전자'가 다른 토큰이 될 수 있어, 한국어 검색에는 형태소 분석기를 검토합니다.

nori는 Elasticsearch 공식 한국어 형태소 분석 플러그인(analysis-nori)입니다. nori_tokenizer가 문장을 형태소 단위로 쪼개고, nori_part_of_speech 필터로 조사와 어미 같은 품사를 걸러냅니다. 직접 운영하는 클러스터에서는 모든 노드에 플러그인을 설치해야 합니다.

PUT /stocks
{
  "settings": {
    "analysis": {
      "analyzer": {
        "korean": {
          "type": "custom",
          "tokenizer": "nori_tokenizer",
          "filter": ["lowercase", "nori_part_of_speech"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "name": { "type": "text", "analyzer": "korean" }
    }
  }
}

자동 완성과 본문 검색은 토큰화 규칙이 다릅니다. 자동 완성은 입력 중간 글자로도 매칭해야 하므로 전용 필드와 분석기를 따로 설계합니다. 본문용 분석기로 두 기능을 모두 처리하면 각 기능에 맞는 토큰화를 하기 어렵습니다.

실무 설계 기준

예상 검색어와 검색 방식을 기준으로 필드 타입을 정합니다. 사용할 값과 수행할 작업을 먼저 결정합니다.

• 사용자 이름, 상태값, 태그: keyword
• 본문, 설명, 리뷰: text
• 검색과 집계를 둘 다 해야 하는 문자열: 멀티 필드
• 자동 완성: 전용 필드와 전용 분석기 분리

색인 시점 분석기를 바꿔도 기존 문서의 토큰은 자동으로 바뀌지 않습니다. 기존 문서에 새 토큰화를 적용하려면 재색인이 필요합니다. 검색 시점의 search_analyzer만 바꾸는 경우에는 재색인 없이 적용할 수 있지만 검색 결과는 다시 검증해야 합니다.

저장된 토큰을 바꾸는 작업인지 검색어 처리만 바꾸는 작업인지에 따라 운영 절차가 달라집니다.

정리

매핑은 필드의 저장·색인 방식을 정하고, 분석기는 전문 검색용 토큰을 만듭니다. 분석한 검색에는 text, 정확 매칭과 집계에는 keyword를 쓰며 두 용도가 필요하면 멀티 필드로 묶습니다.

한국어 형태소와 자동 완성은 각각의 질의에 맞는 토큰화가 필요합니다. 색인과 검색 토큰의 호환성을 확인하고, 기존 문서의 토큰을 바꿀 때는 재색인을 계획합니다.