← 학습 카테고리

Learn

Elasticsearch

50개 모듈 · 현재 8번째

Elasticsearch 모듈 8/50 elasticsearch-learn-08

Elasticsearch 면접 단골 질문 모음

Elasticsearch 공식 문서(elastic.co/docs) 및 기술 블로그 종합 — 아키텍처부터 운영까지 (웹 리서치, 2026) — Elastic 공식 문서 + 여러 기술 블로그(Opster, Baeldung 등) 교차 확인

이 모듈을 다 읽으면

  • 면접에서 반복적으로 나오는 Elasticsearch 핵심 질문에 짧고 정확하게 답할 수 있다
  • 각 질문의 답이 이 카테고리의 어느 심화 모듈과 연결되는지 알아 필요하면 더 깊이 파고들 수 있다

이 카테고리의 1~7번 모듈에서 다룬 내용을 전제로, 실제 면접에서 반복적으로 나오는 질문만 뽑아 짧고 정확한 모범답안 형태로 재구성했다.

Q. Elasticsearch와 RDB의 근본적인 차이는 무엇인가?

RDB는 정확한 매칭·조인·트랜잭션에 최적화된 행 지향 저장 구조다. Elasticsearch는 역인덱스 기반으로 전문 검색과 관련도 랭킹(BM25)에 최적화됐고, 조인 대신 비정규화된 문서 저장을 전제로 하며, 강한 트랜잭션 보장보다 준실시간(NRT) 검색과 수평 확장성(샤딩)을 우선한다(elasticsearch-learn-01, 02, 04 참고).

핵심 포인트

  • RDB=정확 매칭/조인/트랜잭션 최적화, ES=전문검색/관련도랭킹/수평확장 최적화

Q. 문서를 색인했는데 왜 바로 검색이 안 되는가?

색인된 문서는 먼저 메모리 버퍼에만 있고, refresh_interval(기본 1초)마다 실제 검색 가능한 Lucene 세그먼트로 구체화되기 때문이다. 이래서 Elasticsearch를 완전한 실시간이 아니라 '준실시간(NRT)'이라 부른다(elasticsearch-learn-04 참고).

핵심 포인트

  • refresh_interval(기본 1초) 주기로 메모리 버퍼가 검색 가능한 세그먼트로 구체화되기 전까지는 안 보인다

Q. bool 쿼리에서 must 대신 filter를 쓰면 뭐가 좋은가?

filter는 관련도 점수 계산을 생략하고(참/거짓만 판단), 그 결과가 캐시돼 반복 사용 시 재사용된다 — 정확 매칭·범위·존재 여부처럼 점수가 필요 없는 조건은 must에서 filter로 옮기는 게 표준적인 성능 최적화다(elasticsearch-learn-05 참고).

핵심 포인트

  • filter는 스코어링 생략 + 캐시 가능 — 점수가 필요 없는 조건은 must 대신 filter로

Q. text 필드로 집계했더니 'Fielddata is disabled' 에러가 난다. 왜, 어떻게 고치는가?

text 필드는 analyzer로 토큰화돼 저장되어 '원래 값' 자체가 없어서 기본적으로 집계(fielddata)가 비활성화되어 있다. fielddata:true로 강제 활성화하면 메모리 부담이 크므로, 정석 해법은 같은 필드를 keyword 타입 서브필드로도 매핑(multi-field)해 그 keyword 서브필드에 집계를 거는 것이다(elasticsearch-learn-03, 06 참고).

핵심 포인트

  • text는 원래 값이 없어 집계 기본 비활성화 — keyword 서브필드(multi-field)에 집계하는 게 정석

Q. 샤드는 몇 개로 나눠야 하는가?

정답이 하나로 정해진 공식은 없지만, 실무 경험칙은 샤드 하나의 크기가 수십GB 안팎이 되도록 예상 데이터量을 기준으로 프라이머리 샤드 수를 정하는 것이다. 무조건 많이 쪼개면(oversharding) 클러스터 상태 관리 부담과 마스터 노드 부하가 커져 오히려 클러스터 안정성이 떨어진다(elasticsearch-learn-01, 07 참고).

핵심 포인트

  • 샤드 하나 크기를 수십GB 안팎으로 — 무조건 잘게 쪼개는(oversharding) 건 오히려 해롭다

Q. ILM과 데이터 스트림은 왜 함께 쓰는가?

데이터 스트림은 계속 쌓이는 시계열 데이터를 하나의 논리적 이름으로 쓰기하면서 내부적으로 백킹 인덱스를 자동 롤오버해준다. ILM은 그 백킹 인덱스들을 Hot→Warm→Cold→Frozen→Delete로 자동 이동시킨다. 둘을 결합하면 '오늘 로그는 빠른 디스크, 6개월 지난 로그는 저비용 스토리지, 1년 지나면 삭제' 같은 정책 전체가 수동 개입 없이 자동으로 유지된다(elasticsearch-learn-07 참고).

핵심 포인트

  • 데이터 스트림(자동 롤오버) + ILM(자동 계층 이동/삭제) = 로그 운영 전체 자동화