검색 엔지니어링 Q&A — 한글 검색부터 클러스터 운영까지 17문답

검색 시스템을 다루다 보면 같은 질문이 반복해서 돌아온다. "초성검색은 어떻게 만드나", "왜 이 문서가 위에 뜨나", "클러스터가 갑자기 쓰기를 거부하는데 어디부터 보나" 같은 것들이다. 이 글은 그 질문들을 한 곳에 모아 결론부터 답한다.

먼저 Elasticsearch의 뼈대를 세 줄로 요약해 두면 이후 답이 잘 붙는다.

• 분석기 3단계: char filter → tokenizer(1개만) → token filter.
• 색인 경로: 버퍼(+translog) → refresh(=Lucene flush, 이때부터 검색 가능) → flush(=Lucene commit, 디스크) → merge.
• 검색 2단계(Query then Fetch): ① 전 샤드에 broadcast해 docID+score만 취합 → ② 선별된 문서만 내용을 fetch.
• 역인덱스: 단어 → 문서. 정렬·집계 필드는 keyword(doc_values) 로 잡는다(text는 fielddata로 힙을 태운다).

각 주제의 전체 맥락은 Elasticsearch 아키텍처, 한글 검색 구현, 운영과 트러블슈팅에서 다룬다.

핵심 수치 정리

검색 설계에서 반복해 등장하는 숫자들이다. 값만 외우면 응용이 안 되므로 왜 그 값인지를 함께 둔다.

Elasticsearch가 기본 제공하지 않아 직접 구현해야 하는 것

한국어 검색에서 사용자가 당연하게 기대하는 기능 중 상당수는 Elasticsearch에 기본 기능이 없다. 상용 검색엔진에서는 규격서 한 줄로 주어지던 것들이라, 오픈소스로 넘어올 때 가장 먼저 부딪히는 벽이다.

무결과 폴백 순서: 정타 → fuzzy(오타) → 동의어 확장 → 초성/한영 변환 → 인기·추천. 여기에 significant_terms(연관어 제안)와 큐레이션을 얹는다.

Q. 왜 DB의 LIKE 검색이 아니라 검색엔진을 쓰나

LIKE '%키워드%'는 인덱스를 타지 못해 풀스캔이 되고, 오타·동의어·형태소·랭킹을 표현할 수단이 아예 없기 때문이다.

핵심은 세 가지를 역인덱스 + 분석기 + 랭킹으로 푼다는 점이다. DB는 "조건에 맞는 행"을 주지만 검색엔진은 "연관성 높은 순서"를 준다.

Q. 초성검색을 어떻게 구현하나

Elasticsearch에 초성 추출 기능이 없으므로, 유니코드 자소분해를 하는 커스텀 플러그인을 token filter 단계에 넣어 초성 필드를 따로 색인한다.

한글은 초성 19·중성 21·종성 28의 조합이라 음절 코드에서 초성을 역산할 수 있다.

음절코드 = (초성×21 + 중성)×28 + 종성 + 0xAC00

종성 = v % 28
중성 = ((v - 종성) / 28) % 21
초성 = (((v - 종성) / 28) - 중성) / 21

Q. 한영검색(자판 오타 교정)은 어떻게 처리하나

한/영 키맵 변환 필터로 만든 서브필드를 색인해 두고, 검색 시 원문 필드와 함께 multi_match로 질의한다. 자판 레이아웃 매핑 문제라 ES 기본 기능이 아니라 커스텀 필터 영역이다.

오타 대응 자체는 fuzzy·동의어·자소분해로 상당 부분 커버되지만, 자판 전환 실수는 편집거리로 잡히지 않는다. "dkssud"와 "안녕"은 문자열로는 완전히 다르기 때문에 별도 변환 경로가 필요하다.

Q. 자동완성에서 색인용과 검색용 분석기를 분리하는 이유

검색어까지 edge_ngram으로 쪼개면 다시 n-gram으로 분해되어 의도하지 않은 문서까지 매칭되기 때문이다. edge_ngram은 색인 분석기에만 적용한다.

"index_completion":  { "type":"custom", "tokenizer":"standard",
  "filter":["lowercase","trim","autocomplete_edge"] },   // edge_ngram 포함
"search_completion": { "type":"custom", "tokenizer":"standard",
  "filter":["lowercase","trim"] }                          // edge_ngram 제외

search_analyzer를 매핑에 명시하지 않으면 색인 분석기가 검색에도 그대로 쓰인다. 멀티필드를 쓸 때는 반드시 분리해서 지정한다.

Q. 자동완성 방식은 무엇을 기준으로 고르나

부분일치 범위·오타 허용·속도의 트레이드오프로 고른다. 앞부분만 매칭하면 되면 edge_ngram이 가장 가볍고, 중간 일치가 필요하면 색인 비용을 감수해야 한다.

한글은 여기에 더해 초성·자모·영타·한타 서브필드를 병렬 색인하고 multi_match(cross_fields)로 묶는 조합을 주로 쓴다. 다만 "아이폰" 한 단어에도 자소를 포함해 최대 7회 호출이 발생하므로, 클라이언트에서 debouncing·throttling으로 호출을 줄이는 것이 함께 가야 한다.

Q. Nori가 형태소를 이상하게 쪼갤 때 어디부터 보나

_analyze API로 실제 토큰을 먼저 확인하고, 원인에 따라 decompound_mode나 사용자사전을 조정한다. 추측으로 사전을 건드리면 부작용만 늘어난다.

근본 원인은 사전이다. Nori는 mecab-ko-dic(1998 세종 말뭉치) 기반이라 신조어·외래어에 취약하다. 사전을 지속 갱신하는 운영 프로세스가 설정 튜닝보다 중요하다.

Q. 동의어를 색인 시점과 검색 시점 중 언제 적용하나

사전이 안정적이면 색인 시(성능), 자주 바뀌면 검색 시(실시간) 로 나눈다.

검색 시 방식은 search_analyzer에 synonym(updateable: true, 파일 기반)을 두고 _reload_search_analyzers + _cache/clear?request=true를 호출하면 재색인 없이 반영된다. 동의어 표현은 동등관계 "A, B"(양방향)와 치환 "A => B"(단방향) 두 가지이며, synonym_graph가 권장된다.

Q. 검색 결과가 0건일 때 무엇을 보여주나

0건은 이탈로 직결되므로 단계적 폴백을 정책으로 설계해 "뭐라도" 보여준다. 엔진 기능이 아니라 정책 결정이라는 점이 핵심이다.

폴백 이전에 0건 자체를 줄이는 수단도 함께 쓴다. 동의어로 이표기를 정타에 매핑하고("횬대"→"현대"), significant_terms로 연관 검색어를 제안하고, 큐레이션으로 특정 결과를 노출한다. 다만 Promoted 큐레이션은 관련성 점수를 무시하므로 남용하면 검색 품질이 왜곡된다.

Q. 왜 이 문서가 검색 상위에 뜨는지 어떻게 설명하나

BM25 기본 점수 → function_score 가중 → explain으로 실측의 순서로 분해한다. 추정하지 않고 점수를 뜯어보는 것이 요령이다.

분산 환경에서는 점수가 로컬 샤드에서 계산된다는 점도 알아둘 만하다. IDF는 원래 전역 정보가 필요하지만 전역 계산은 비싸서 하지 않고, 데이터가 고르게 분산돼 있으면 로컬 IDF도 거의 같아 문제가 없다. 정확한 전역 점수가 필요하면 ?search_type=dfs_query_then_fetch를 쓴다.

Q. 클러스터가 갑자기 쓰기를 거부할 때 어디부터 보나

디스크 watermark의 flood_stage(95%)를 1순위로 의심한다. _cat/allocation으로 노드별 디스크 사용률부터 본다.

복구는 디스크를 확보한 뒤 index.blocks.read_only_allow_delete를 해제해야 풀린다. 자동으로 풀리지 않는다는 점이 함정이다. 근본 대책은 ILM으로 오래된 인덱스를 warm/cold로 내리거나 삭제해 hot 노드 용량을 관리하는 것이다.

Q. yellow와 red는 무엇이 다르고 어떻게 대응하나

yellow는 replica 문제라 서비스가 정상이고, red는 primary 손실이라 일부 데이터에 접근이 안 된다. 상태를 결정하는 것은 대부분 샤드다.

red 복구는 ① 문제 인덱스 확인 → ② 노드 종료가 원인이면 재시작 → ③ 스냅샷 복구 → ④ 재색인 순으로 접근한다. 애초에 red를 막는 선제 조치는 replica를 최소 1개 두고 SLM으로 스냅샷을 상시 걸어 두는 것이다.

Q. 마스터 후보 노드를 몇 대로 두나

홀수, 최소 3대다. quorum이 (후보수/2)+1이라 홀수여야 네트워크 분단 시 다수파만 생존하고 소수파는 스스로 멈춘다.

운영 중 원칙이 두 가지 더 있다. 한 번에 절반 이상 노드를 빼지 않는다(quorum이 깨지면 클러스터 전체가 unavailable). 그리고 최초 구성 시 cluster.initial_master_nodes에 후보를 모두 넣되 구성 완료 후에는 제거한다.

Q. 인덱스 샤드 개수는 어떻게 정하나

정답은 없고 샤드당 용량 상한 + 노드 수 균형으로 산정한다. 과소보다 과다 샤드가 더 위험하다는 것이 실무 감각이다.

primary 개수를 나중에 못 바꾸는 이유는 라우팅 규칙(hash(_id) % primary_shards) 때문이다. 개수가 바뀌면 전 문서의 위치가 어긋나므로 재색인해야 한다.

Q. 힙을 32GB 넘게 주면 안 되는 이유

32GB를 넘으면 JVM의 compressed ordinary object pointer가 꺼져 포인터가 커지고 오히려 효율이 떨어지기 때문이다. 메모리를 더 줬는데 성능이 나빠지는 구간이 생긴다.

ES 성능이 파일시스템 캐시에 크게 의존한다는 점이 세 번째 규칙의 근거다. 힙을 키우는 것이 곧 성능 향상이 아니다.

Q. 대량 색인에는 어떤 튜닝을 하나

색인 중에는 refresh를 늦추고 replica를 끄고, 끝나면 되돌린다. 색인 내부 동작(버퍼 → refresh → 세그먼트 → merge)을 이해하면 자연스럽게 나오는 처방이다.

refresh_interval: -1로 두면 색인해도 검색 결과가 0건이라는 점에 주의한다. 되돌리는 것을 잊으면 "데이터를 넣었는데 검색이 안 된다"는 장애로 나타난다.

Q. 롤링 배포와 블루그린 배포는 언제 무엇을 고르나

자원을 아끼며 무중단이면 롤링, 즉시 전환·빠른 롤백이 필요하고 자원이 2배 있으면 블루그린이다. 메이저 업그레이드는 하위호환이 없어 중단 배포와 짝이 된다.

롤링 시에는 index.unassigned.node_left.delayed_timeout(기본 1m)을 5m 정도로 늘린다. 그러지 않으면 노드가 잠깐 빠질 때마다 샤드가 대량으로 재할당되어 불필요한 부하가 생긴다.

Q. 상용 검색엔진에서 Elasticsearch로 넘어오면 운영상 무엇이 달라지나

벤더가 대신 지던 결정을 전부 직접 지게 된다. 기능 목록은 비슷해 보여도 의사결정의 양과 종류가 완전히 달라진다.

특히 OS 설정은 놓치면 노드가 아예 뜨지 않는 형태로 나타나므로, 운영 체크리스트를 문서로 남겨 두는 것이 전환 초기의 실질적인 대비책이다. 부담이 커지는 만큼 검색엔진을 블랙박스가 아니라 내부까지 이해하고 튜닝할 수 있게 된다는 것이 반대급부다.

용어 정리