면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
검색엔진 프로젝트에서 OpenSearch를 처음 사용해봤습니다. 종목 검색처럼 실시간성과 정확도가 동시에 중요한 경우, 일반 DB 조회보다 역색인 기반 검색이 유리하다는 것을 이해하고 선택했습니다. 설계 단계에서 가장 먼저 고려한 것은 어떤 필드를 검색 가능하게 할지였는데, 종목명, 코드, 산업군을 분리해 인덱스 매핑을 정의했습니다.
자동완성 기능을 위해 edge n-gram 분석기를 적용했고, 초성 검색처럼 한국어 특성을 고려한 분석기 설정이 까다로웠습니다. 쿼리 정확도와 성능을 함께 높이기 위해 정확 매칭과 퍼지 매칭을 점수 기반으로 조합했고, 관련도 높은 결과가 상위에 오도록 부스팅 설정을 조정했습니다. 결과적으로 응답 시간이 목표 기준 이하로 유지됐습니다. OpenSearch 설계는 인덱스 매핑이 검색 품질과 성능 모두를 결정한다는 결을 얻었습니다.
졸업 프로젝트에서 주식 종목 검색 기능을 만들 때 OpenSearch의 기본 분석기를 그대로 쓰자 종목명을 줄임말로 검색하면 결과가 안 나왔습니다. nori 형태소 분석기를 도입해 한국어 형태소 단위로 토큰화했더니 이 문제는 해결됐지만, 이번엔 비슷한 음절이 들어가는 다른 종목이 모두 함께 올라오는 노이즈가 생겼습니다. 을 직접 만들어 약어와 정식 명칭을 매핑했고, 부스팅 가중치를 조정해 정확히 일치하는 종목명을 상위에 올렸습니다. 처음에는 동의어 파일 형식이 맞지 않아 인덱스 생성이 실패하는 삽질을 반복했지만, 공식 문서를 꼼꼼히 읽으며 정리했습니다. 최종적으로 사내 테스트 50개 종목 기준 검색 정확도가 71%에서 89%로 올랐습니다.
인턴 기간에 검색 엔진 랭킹 개선을 맡았을 때, 처음에는 결과가 좋아 보이는지를 감으로만 판단하고 있었습니다. 팀장이 지표를 알려줬고, 쿼리 50개를 직접 정의해 랭킹 정확도를 수치로 추적하기 시작했습니다. BM25 가중치를 조정하거나 필드별 부스팅 값을 바꿀 때마다 이 지표로 전후를 비교했고, 수치가 오히려 떨어지면 바로 롤백했습니다.
세 번 방향을 되돌리면서 결국 공식 명칭에 높은 부스팅을 주고 설명 텍스트는 낮추는 설정이 가장 안정적이었습니다. 처음에는 실험을 너무 많이 한 번에 바꿔 어떤 변수가 영향을 줬는지 추적이 안 됐는데, 이후 변수 하나씩만 바꾸는 방식으로 전환했습니다. 이 경험으로 튜닝 작업에서 지표 없이 감으로만 판단하는 게 얼마나 비효율적인지 실감했습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.