이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
검색 기능이 필요한 사이드 프로젝트에서 Elasticsearch를 직접 구성해본 경험이 있습니다. 숙박 검색처럼 다양한 조건 조합이 필요한 경우, RDB의 LIKE 쿼리로는 성능 한계가 빠르게 드러납니다. 역색인 구조를 이해한 뒤에야 왜 전문 검색에서 ES가 유리한지 납득이 됐는데, 쿼리 DSL 문법이 처음에는 낯설어 기본 match/filter 조합부터 익혔습니다. 지역·날짜·가격 범위를 조합한 불리언 쿼리를 만들었고, 인덱스 매핑 설계 단계에서 필드별 타입을 잘못 지정하면 나중에 재색인해야 한다는 것을 경험했습니다. 실제 서비스라면 데이터 변경 시 ES와 원본 DB의 동기화 전략도 설계해야 한다는 점이 가장 고민스러웠습니다. 검색은 데이터를 잘 저장하는 것만큼 쿼리를 잘 설계하는 것이 중요하다는 결을 얻었습니다.
Elasticsearch 경험이 본인 사례로 닫힌 경험은 인덱스 구조를 설계하면서 검색 성능과 인덱싱 비용 사이의 균형을 경험한 케이스였습니다. 처음에는 모든 필드를 인덱싱했는데, 인덱싱 속도가 느려지는 문제가 생겼습니다.
자주 검색에 쓰이는 필드와 그렇지 않은 필드를 구분해서 인덱싱 전략을 조정했습니다. Elasticsearch에서 인덱스 설계는 검색 기능만큼 인덱싱 비용도 함께 고려해야 하는 설계 결정이라는 결이 생겼습니다.
Elasticsearch 경험에서 측정 가능한 결과로 닫힌 경험은 복합 쿼리 응답 시간을 비교한 케이스였습니다. 다양한 조건을 조합한 검색 쿼리를 만들고, 쿼리 최적화 전후 응답 시간을 측정했습니다.
Explain API로 쿼리 실행 계획을 확인하면서 어떤 부분에서 시간이 많이 걸리는지를 파악했습니다. 인덱스 설정을 바꾼 뒤 응답 시간이 줄어든 것을 수치로 확인했을 때, 설정 변경의 효과를 직접 측정하는 방식이 중요하다는 걸 이해했습니다. Elasticsearch 최적화는 감이 아니라 Explain으로 확인한 뒤 변경해야 의미 있는 개선이 된다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 트립비토즈 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.