한글 형태소 분석 Nori 완벽 가이드

Elasticsearch에서 한글 검색을 제대로 구현하려면 Nori 플러그인이 필수입니다. 이 가이드에서는 Nori 설치부터 사용자 사전, 복합어 분해까지 한글 검색 최적화의 모든 것을 다룹니다.

---

목차

1. Nori 플러그인 설치
2. nori_tokenizer 설정
3. 품사 태깅 활용
4. 사용자 사전 추가
5. 복합어 분해 설정
6. 한글 검색 성능 최적화

---

1. Nori 플러그인 설치

김개발 씨는 새로운 프로젝트에서 상품 검색 기능을 맡게 되었습니다. "삼성전자"를 검색했는데 "삼성 전자"로 띄어쓰기한 상품이 안 나온다는 고객 불만이 쏟아졌습니다.

영어 검색은 잘 되는데 왜 한글만 이상하게 동작하는 걸까요?

Nori는 Elasticsearch 공식 한글 형태소 분석 플러그인입니다. 마치 한글을 모국어처럼 이해하는 통역사와 같습니다.

이 플러그인을 설치하면 "삼성전자", "삼성 전자", "삼성Electronics"를 모두 같은 검색 결과로 연결할 수 있습니다.

다음 코드를 살펴봅시다.

# Elasticsearch 플러그인 설치 명령어
bin/elasticsearch-plugin install analysis-nori

# 설치 확인
bin/elasticsearch-plugin list

# Docker 환경에서 설치
docker exec -it elasticsearch bin/elasticsearch-plugin install analysis-nori

# 설치 후 Elasticsearch 재시작 필수
systemctl restart elasticsearch

# 플러그인 동작 확인 API
curl -X GET "localhost:9200/_cat/plugins?v"

김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 오늘은 고객센터에서 긴급 요청이 들어왔습니다.

"검색이 이상해요. 삼성전자를 검색했는데 왜 삼성 TV는 안 나와요?" 로그를 확인해보니 영어 검색은 멀쩡했습니다.

"iPhone"을 검색하면 "iphone", "IPHONE" 모두 잘 찾았습니다. 하지만 한글은 달랐습니다.

"삼성전자"와 "삼성 전자"가 서로 다른 단어로 인식되고 있었습니다. 선배 개발자 박시니어 씨가 다가와 화면을 보더니 바로 원인을 짚었습니다.

"아, Nori 안 깔았구나. 한글 검색하려면 필수야." 그렇다면 Nori란 정확히 무엇일까요?

쉽게 비유하자면, Nori는 한글 전문 통역사입니다. 외국인이 한국어를 배울 때 "나는 밥을 먹는다"를 단어 단위로 이해하지 못하고 통째로 외우듯이, 기본 Elasticsearch도 한글을 덩어리째 인식합니다.

하지만 Nori가 있으면 "나는", "밥을", "먹는다"로 정확하게 분리해서 이해할 수 있습니다. Nori가 없던 시절에는 어땠을까요?

개발자들은 한글 검색을 위해 별도의 외부 라이브러리를 연동하거나, N-gram 방식으로 글자를 잘게 쪼개는 우회 방법을 썼습니다. N-gram은 "삼성"을 "삼", "삼성", "성"으로 쪼개는 방식인데, 인덱스 크기가 폭발적으로 커지고 검색 정확도도 떨어졌습니다.

Elasticsearch 6.4 버전부터 Nori가 공식 플러그인으로 등장했습니다. 설치는 놀랍도록 간단합니다.

Elasticsearch가 설치된 디렉토리에서 bin/elasticsearch-plugin install analysis-nori 명령 한 줄이면 끝입니다. Docker 환경이라면 컨테이너 안에서 같은 명령을 실행하면 됩니다.

다만 중요한 점이 있습니다. 플러그인 설치 후에는 반드시 Elasticsearch를 재시작해야 합니다.

이 과정을 빼먹으면 플러그인이 로드되지 않아서 "analyzer not found" 오류를 만나게 됩니다. 설치가 잘 되었는지 확인하려면 _cat/plugins API를 호출해보세요.

목록에 analysis-nori가 보이면 성공입니다. 클러스터 환경에서는 모든 노드에 플러그인을 설치해야 합니다.

한 노드라도 빠지면 해당 노드에서 인덱싱이나 검색 시 오류가 발생합니다. 김개발 씨는 명령어 한 줄을 입력하고 재시작을 했습니다.

5분 만에 설치가 완료되었습니다. 이제 본격적으로 한글 검색 설정을 시작할 차례입니다.

실전 팁

💡 - 프로덕션 환경에서는 롤링 업그레이드로 무중단 설치가 가능합니다

• Elasticsearch 버전과 Nori 플러그인 버전은 반드시 일치해야 합니다

---

2. nori tokenizer 설정

플러그인 설치를 마친 김개발 씨는 곧바로 검색을 테스트해봤습니다. 하지만 여전히 "삼성전자"와 "삼성 전자"는 다른 결과를 보여줬습니다.

알고 보니 플러그인만 설치하면 끝이 아니었습니다. 인덱스에 분석기를 직접 설정해줘야 했습니다.

nori_tokenizer는 한글 문장을 의미 있는 단어 단위로 쪼개는 토크나이저입니다. 마치 문장을 단어 카드로 분리하는 작업과 같습니다.

이 설정을 인덱스에 적용해야 비로소 한글 형태소 분석이 동작합니다.

다음 코드를 살펴봅시다.

PUT /products
{
  "settings": {
    "analysis": {
      "tokenizer": {
        "nori_user_dict": {
          "type": "nori_tokenizer",
          "decompound_mode": "mixed"
        }
      },
      "analyzer": {
        "korean_analyzer": {
          "type": "custom",
          "tokenizer": "nori_user_dict",
          "filter": ["lowercase", "nori_part_of_speech"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "text",
        "analyzer": "korean_analyzer"
      }
    }
  }
}

김개발 씨는 플러그인 설치 후 바로 테스트를 해봤습니다. 그런데 결과가 이상했습니다.

여전히 한글이 제대로 분석되지 않았습니다. 박시니어 씨가 설명을 이어갔습니다.

"플러그인은 도구 상자야. 상자만 가져다 놓으면 뭐해, 도구를 꺼내서 써야지." Elasticsearch에서 텍스트 분석은 세 단계로 이루어집니다.

먼저 Character Filter가 텍스트를 전처리합니다. 그 다음 Tokenizer가 텍스트를 토큰으로 쪼갭니다.

마지막으로 Token Filter가 토큰을 가공합니다. Nori의 핵심은 두 번째 단계인 Tokenizer입니다.

nori_tokenizer는 한글 문장을 의미 단위로 분리합니다. "삼성전자 갤럭시 스마트폰"이라는 문장이 들어오면 "삼성", "전자", "갤럭시", "스마트폰"으로 쪼개집니다.

영어 기본 토크나이저가 공백만 기준으로 자르는 것과는 차원이 다릅니다. 인덱스를 생성할 때 settings 안에 analysis 섹션을 정의해야 합니다.

여기서 커스텀 토크나이저와 분석기를 만듭니다. 위 코드에서 nori_user_dict라는 이름으로 nori_tokenizer를 등록했습니다.

그리고 korean_analyzer라는 분석기를 만들어서 이 토크나이저를 사용하도록 설정했습니다. 마지막으로 mappings에서 name 필드에 이 분석기를 적용했습니다.

decompound_mode는 복합어 처리 방식을 결정합니다. 나중에 자세히 다루겠지만, 지금은 "mixed"가 가장 범용적이라는 점만 기억해두세요.

분석기가 제대로 동작하는지 확인하려면 _analyze API를 사용합니다. 인덱스 이름과 분석기 이름, 그리고 테스트할 텍스트를 넣으면 토큰 목록이 반환됩니다.

한 가지 주의할 점이 있습니다. 분석기 설정은 인덱스 생성 시에만 가능합니다.

이미 생성된 인덱스의 분석기는 변경할 수 없습니다. 설정을 바꾸려면 인덱스를 삭제하고 다시 만들거나, 새 인덱스를 만들어서 데이터를 재색인해야 합니다.

김개발 씨는 인덱스를 다시 생성하고 데이터를 넣었습니다. 이번에는 "삼성"을 검색했더니 "삼성전자", "삼성 TV", "삼성물산" 모두 검색되었습니다.

드디어 한글 검색이 제대로 동작하기 시작했습니다.

실전 팁

💡 - 기존 인덱스에 적용하려면 reindex API로 데이터를 새 인덱스로 복사해야 합니다

• _analyze API로 토큰 분리 결과를 미리 테스트해보세요

---

3. 품사 태깅 활용

검색 품질이 좋아졌지만 새로운 문제가 생겼습니다. "아름다운 삼성전자 제품을"을 분석하니 "아름답", "ㄴ", "삼성", "전자", "제품", "을"이 모두 토큰으로 나왔습니다.

조사 "을"까지 검색어로 인식되면서 엉뚱한 결과가 섞여 나오기 시작했습니다.

nori_part_of_speech 필터는 특정 품사를 가진 토큰을 제거하는 기능입니다. 마치 편집자가 원고에서 불필요한 조사나 어미를 정리하는 것과 같습니다.

이 필터를 활용하면 검색에 의미 없는 토큰을 걸러내서 검색 정확도를 높일 수 있습니다.

다음 코드를 살펴봅시다.

PUT /products
{
  "settings": {
    "analysis": {
      "tokenizer": {
        "nori_tokenizer": {
          "type": "nori_tokenizer"
        }
      },
      "filter": {
        "nori_posfilter": {
          "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": "nori_tokenizer",
          "filter": ["nori_posfilter", "lowercase"]
        }
      }
    }
  }
}

김개발 씨는 검색 결과를 분석하다가 이상한 점을 발견했습니다. "책을 읽다"를 검색했는데 "가방을 메다", "밥을 먹다"가 상위에 노출되었습니다.

공통점은 조사 "을"이었습니다. 박시니어 씨가 _analyze API 결과를 보여주었습니다.

"책을 읽다"가 "책", "을", "읽", "다"로 분리되어 있었습니다. 문제는 "을"이었습니다.

한국어에서 조사는 어디에나 붙기 때문에, 조사까지 검색어로 쓰면 관련 없는 문서가 대량으로 매칭됩니다. 한국어 형태소에는 여러 품사가 있습니다.

명사, 동사, 형용사처럼 의미를 담은 품사가 있고, 조사, 어미, 접사처럼 문법적 역할만 하는 품사가 있습니다. 검색에서는 전자만 필요하고 후자는 오히려 노이즈입니다.

Nori는 각 토큰에 품사 태그를 붙입니다. 예를 들어 "NNG"는 일반 명사, "VV"는 동사, "J"는 조사를 의미합니다.

nori_part_of_speech 필터는 이 태그를 기준으로 특정 품사를 제거합니다. 위 코드에서 stoptags 배열에 제외할 품사 태그들을 나열했습니다.

"E"는 어미, "J"는 조사, "XS"로 시작하는 것들은 접사입니다. 이 필터를 거치면 "책을 읽다"는 "책", "읽"만 남습니다.

어떤 품사를 제거할지는 서비스 특성에 따라 다릅니다. 일반적인 검색에서는 위 예시의 태그들을 제거하면 됩니다.

하지만 맞춤법 검사나 문법 분석 서비스라면 조사와 어미도 중요하니 제거하면 안 됩니다. 품사 태그 목록은 Elasticsearch 공식 문서에서 확인할 수 있습니다.

한글 품사 체계를 완전히 이해할 필요는 없습니다. 자주 쓰는 태그 몇 개만 알아두면 충분합니다.

필터를 적용한 후 김개발 씨는 다시 검색을 테스트했습니다. "책을 읽다"를 검색하니 "책 읽기", "독서", "책 추천"이 상위에 나왔습니다.

조사 "을" 때문에 엉뚱한 결과가 나오던 문제가 해결되었습니다. 분석기에 필터를 추가할 때 순서도 중요합니다.

nori_part_of_speech를 먼저 적용해서 불필요한 토큰을 제거하고, 그 다음에 lowercase로 소문자 변환을 하는 것이 효율적입니다.

실전 팁

💡 - NNG(일반명사), NNP(고유명사), VV(동사), VA(형용사)는 보통 유지합니다

• 제거할 품사가 확실하지 않으면 기본값부터 시작해서 점진적으로 조정하세요

---

4. 사용자 사전 추가

검색이 잘 되나 싶었는데 또 문제가 생겼습니다. 신제품 "갤럭시Z플립"을 등록했는데 "갤럭시"로 검색하면 나오는데 "Z플립"으로는 검색이 안 됩니다.

알고 보니 Nori가 "갤럭시Z플립"을 "갤럭시", "Z", "플립"으로 잘못 분리하고 있었습니다.

사용자 사전은 Nori가 인식하지 못하는 신조어, 브랜드명, 전문 용어를 등록하는 기능입니다. 마치 외국어 사전에 새로운 단어를 추가하는 것과 같습니다.

사용자 사전을 활용하면 도메인 특화 검색 품질을 크게 높일 수 있습니다.

다음 코드를 살펴봅시다.

# config/userdict_ko.txt 파일 내용
갤럭시Z플립
아이폰프로맥스
넷플릭스
카카오페이
삼성페이 삼성 페이

# 인덱스 설정에 사용자 사전 적용
PUT /products
{
  "settings": {
    "analysis": {
      "tokenizer": {
        "nori_user_dict": {
          "type": "nori_tokenizer",
          "decompound_mode": "mixed",
          "user_dictionary": "userdict_ko.txt"
        }
      },
      "analyzer": {
        "korean_analyzer": {
          "type": "custom",
          "tokenizer": "nori_user_dict"
        }
      }
    }
  }
}

김개발 씨는 신제품이 검색되지 않는다는 고객 문의를 받았습니다. "갤럭시Z플립"을 등록했는데 "Z플립"으로 검색하면 결과가 없었습니다.

_analyze API로 확인해보니 원인이 명확했습니다. Nori는 "갤럭시Z플립"을 "갤럭시", "Z", "플립" 세 개로 분리했습니다.

"Z플립"이라는 토큰 자체가 없으니 검색될 리가 없었습니다. Nori의 기본 사전은 일반적인 한국어 어휘를 기반으로 합니다.

하지만 브랜드명, 신조어, 전문 용어는 포함되어 있지 않습니다. 이런 단어들을 제대로 처리하려면 사용자 사전이 필요합니다.

사용자 사전 파일은 단순한 텍스트 파일입니다. 한 줄에 하나의 단어를 적습니다.

이 파일을 Elasticsearch의 config 디렉토리에 넣고, 토크나이저 설정에서 파일명을 지정하면 됩니다. 사용자 사전에는 두 가지 형식이 있습니다.

첫 번째는 단어만 적는 것입니다. "갤럭시Z플립"이라고 적으면 이 단어를 하나의 토큰으로 인식합니다.

두 번째는 분해 방식을 지정하는 것입니다. "삼성페이 삼성 페이"라고 적으면 "삼성페이"를 "삼성"과 "페이"로 분해합니다.

두 번째 형식이 유용한 이유가 있습니다. "삼성페이"를 통째로 등록하면 "삼성페이"로만 검색됩니다.

하지만 분해 방식을 지정하면 "삼성", "페이", "삼성페이" 모두로 검색할 수 있습니다. 사용자 사전을 변경하면 인덱스를 다시 생성해야 합니다.

또한 클러스터의 모든 노드에 같은 사전 파일이 있어야 합니다. 이 점이 번거로워서 일부 팀은 user_dictionary_rules 옵션을 사용합니다.

이 옵션을 쓰면 파일 대신 인덱스 설정 안에 직접 단어를 나열할 수 있습니다. 실무에서 사용자 사전 관리는 생각보다 중요한 작업입니다.

신제품이 출시되거나 트렌드 용어가 생길 때마다 사전을 업데이트해야 합니다. 많은 팀에서 사전 관리 자동화 파이프라인을 구축합니다.

김개발 씨는 "갤럭시Z플립"을 사용자 사전에 추가하고 인덱스를 재생성했습니다. 이제 "Z플립", "갤럭시Z플립", "갤럭시" 모두로 검색이 되었습니다.

실전 팁

💡 - user_dictionary_rules 옵션을 쓰면 파일 없이 인덱스 설정에 직접 단어를 등록할 수 있습니다

• 사전 변경 후에는 반드시 reindex가 필요합니다

---

5. 복합어 분해 설정

박시니어 씨가 김개발 씨에게 물었습니다. "삼성전자를 검색하면 삼성전자만 나와?

아니면 삼성도 나오고 전자도 나와?" 김개발 씨는 어떤 게 맞는 건지 헷갈렸습니다. 복합어 처리는 서비스 특성에 따라 다르게 설정해야 한다는 것을 알게 되었습니다.

decompound_mode는 복합어를 어떻게 분해할지 결정하는 옵션입니다. 마치 "불고기버거"를 "불고기버거" 그대로 둘지, "불고기"와 "버거"로 쪼갤지, 아니면 셋 다 유지할지 정하는 것과 같습니다.

검색 서비스의 성격에 맞게 설정해야 합니다.

다음 코드를 살펴봅시다.

# none 모드: 복합어를 분해하지 않음
# "삼성전자" -> ["삼성전자"]

# discard 모드: 복합어를 버리고 분해된 토큰만 유지
# "삼성전자" -> ["삼성", "전자"]

# mixed 모드: 복합어와 분해된 토큰 모두 유지
# "삼성전자" -> ["삼성전자", "삼성", "전자"]

PUT /products
{
  "settings": {
    "analysis": {
      "tokenizer": {
        "nori_mixed": {
          "type": "nori_tokenizer",
          "decompound_mode": "mixed"
        }
      },
      "analyzer": {
        "korean_analyzer": {
          "type": "custom",
          "tokenizer": "nori_mixed"
        }
      }
    }
  }
}

복합어란 두 개 이상의 단어가 합쳐져서 만들어진 단어입니다. "삼성전자", "불고기버거", "대한민국" 같은 것들이 복합어입니다.

이런 복합어를 검색할 때 어떻게 처리할지가 중요한 문제입니다. Nori는 세 가지 복합어 분해 모드를 제공합니다.

첫 번째는 none 모드입니다. 복합어를 분해하지 않습니다.

"삼성전자"는 그대로 "삼성전자" 하나의 토큰이 됩니다. 이 모드에서는 "삼성"으로 검색해도 "삼성전자"가 나오지 않습니다.

두 번째는 discard 모드입니다. 복합어를 분해하고 원래 복합어는 버립니다.

"삼성전자"가 "삼성", "전자" 두 개의 토큰이 됩니다. 이 모드에서는 "삼성전자"로 정확히 검색하면 점수가 낮아질 수 있습니다.

세 번째는 mixed 모드입니다. 복합어와 분해된 토큰을 모두 유지합니다.

"삼성전자"가 "삼성전자", "삼성", "전자" 세 개의 토큰이 됩니다. 가장 유연한 검색이 가능하지만 인덱스 크기가 커집니다.

어떤 모드를 선택해야 할까요? 대부분의 경우 mixed가 정답입니다.

사용자가 "삼성"으로 검색해도, "전자"로 검색해도, "삼성전자"로 검색해도 결과를 찾을 수 있기 때문입니다. 하지만 예외도 있습니다.

법률 문서 검색처럼 정확한 용어 매칭이 중요한 경우에는 none이 적합할 수 있습니다. "대한민국"과 "대한", "민국"이 완전히 다른 의미인 상황에서는 분해가 오히려 혼란을 줍니다.

인덱스 크기도 고려해야 합니다. mixed 모드는 같은 문서에 대해 더 많은 토큰을 생성합니다.

대용량 데이터를 다룬다면 디스크 사용량과 메모리 사용량이 늘어납니다. 김개발 씨의 쇼핑몰 검색에서는 mixed가 최선이었습니다.

고객들은 "삼성", "삼성전자", "전자제품" 등 다양한 방식으로 검색하기 때문입니다. 박시니어 씨의 조언대로 mixed를 적용하니 검색 만족도가 눈에 띄게 올라갔습니다.

실전 팁

💡 - 쇼핑몰, 콘텐츠 검색에는 mixed가 적합합니다

• 법률, 의료 등 정확한 용어가 중요한 도메인에서는 none을 고려하세요

---

6. 한글 검색 성능 최적화

한글 검색이 잘 동작하게 되었지만, 김개발 씨는 새로운 고민에 빠졌습니다. 상품 데이터가 100만 건을 넘어가면서 검색 속도가 느려지기 시작했습니다.

형태소 분석 자체가 연산을 많이 쓰는 작업이라 최적화가 필요했습니다.

한글 검색 성능 최적화는 인덱싱 최적화와 쿼리 최적화 두 축으로 나뉩니다. 마치 도서관에서 책을 잘 정리해두는 것과 책을 빨리 찾는 기술을 모두 갖춰야 하는 것과 같습니다.

올바른 설정으로 검색 응답 시간을 수십 밀리초 단위로 줄일 수 있습니다.

다음 코드를 살펴봅시다.

PUT /products
{
  "settings": {
    "index": {
      "number_of_shards": 3,
      "number_of_replicas": 1,
      "refresh_interval": "5s"
    },
    "analysis": {
      "tokenizer": {
        "nori_tokenizer": {
          "type": "nori_tokenizer",
          "decompound_mode": "mixed"
        }
      },
      "analyzer": {
        "korean_search": {
          "type": "custom",
          "tokenizer": "nori_tokenizer",
          "filter": ["nori_readingform", "lowercase", "nori_part_of_speech"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "text",
        "analyzer": "korean_search",
        "search_analyzer": "korean_search"
      },
      "name_keyword": {
        "type": "keyword"
      }
    }
  }
}

검색 서비스가 커지면 성능 문제를 피할 수 없습니다. 형태소 분석은 CPU를 많이 사용하는 작업이라서, 데이터가 많아지면 병목이 발생하기 쉽습니다.

박시니어 씨가 김개발 씨에게 성능 최적화의 기본 원칙을 알려주었습니다. "인덱싱은 한 번, 검색은 수만 번.

인덱싱을 조금 무겁게 해도 검색을 가볍게 만들어야 해." 첫 번째 최적화 포인트는 refresh_interval입니다. Elasticsearch는 기본적으로 1초마다 인덱스를 갱신합니다.

실시간성이 중요하지 않다면 이 값을 5초나 30초로 늘려서 I/O 부하를 줄일 수 있습니다. 두 번째는 샤드 설계입니다.

샤드가 너무 많으면 오버헤드가 생기고, 너무 적으면 병렬 처리 효율이 떨어집니다. 일반적으로 샤드당 20GB~50GB를 권장합니다.

세 번째는 nori_readingform 필터입니다. 이 필터는 한자를 한글 독음으로 변환합니다.

"大韓民國"을 "대한민국"으로 바꿔줍니다. 한자가 포함된 데이터가 있다면 필수입니다.

네 번째는 필드 설계입니다. 정확한 매칭이 필요한 경우 text 타입 외에 keyword 타입 필드를 별도로 두는 것이 좋습니다.

keyword 필드는 분석 과정 없이 바로 매칭하기 때문에 빠릅니다. 다섯 번째는 검색 쿼리 최적화입니다.

match 쿼리 대신 multi_match를 쓰면 여러 필드를 한 번에 검색할 수 있습니다. bool 쿼리로 필터를 잘 구성하면 검색 대상을 줄여서 속도를 높일 수 있습니다.

캐싱도 중요합니다. Elasticsearch는 자주 사용되는 쿼리 결과를 캐시합니다.

filter 컨텍스트를 활용하면 캐시 효율이 올라갑니다. "카테고리가 전자제품인 것" 같은 조건은 filter로 처리하는 것이 좋습니다.

마지막으로 하드웨어 리소스입니다. 형태소 분석은 CPU 집약적입니다.

노드의 CPU 코어 수가 충분한지 확인하세요. 또한 힙 메모리는 전체 메모리의 50% 이하로 설정하고, 나머지는 파일 시스템 캐시에 남겨두는 것이 좋습니다.

김개발 씨는 이 최적화 기법들을 적용했습니다. refresh_interval을 5초로 늘리고, 샤드 수를 조정하고, 쿼리를 개선했습니다.

검색 응답 시간이 평균 200ms에서 50ms로 줄어들었습니다.

실전 팁

💡 - 프로덕션 환경에서는 검색 로그를 분석해서 느린 쿼리를 찾아 개선하세요

• 정기적으로 인덱스 상태를 모니터링하고 필요시 reindex를 수행하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!