이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제가 직접 검색 시스템을 구축한 경험은 없지만, 사이드 프로젝트로 공연 리뷰 검색 기능을 만들면서 이 구조를 처음 의식하게 됐습니다. 쿼리 이해 단계에선 '뮤지컬'이라는 단어가 장르를 뜻하는지 제목을 뜻하는지 구분하는 게 어려웠고, 형태소 분석기만 쓰니 엉뚱한 결과가 많이 나왔습니다. 그때 의도 분류를 먼저 하고 이후에 검색 범위를 좁히는 식으로 바꾸니 결과가 훨씬 좋아졌습니다. 리트리벌에선 키워드 매칭과 벡터 유사도를 같이 쓰는 게 단일 방법보다 나았고, 랭킹에선 클릭 데이터를 피드백으로 넣는 구조가 유의미하다고 논문에서 읽었습니다. 각 레이어가 독립적으로 보이지만 앞 단계 품질이 뒤를 결정하는 구조라는 게 인상적이었습니다.
제 경험상 검색이 잘 안 된다는 느낌은 대부분 어느 레이어에서 터지는지 모를 때 가장 막막했습니다. 사이드 프로젝트에서 검색 실패 쿼리를 수집했더니, 쿼리 이해 실패가 60% 이상이었습니다. 사용자가 오타 섞인 단어를 쓰거나 줄임말을 썼을 때 아예 후보가 안 나오는 거였습니다. 그래서 쿼리 전처리와 동의어 사전 작업을 먼저 집중했고, 리트리벌 단계는 나중으로 미뤘습니다.
처음엔 랭킹부터 고치려다 헛수고를 했는데, 앞 단계 문제를 먼저 잡는 게 맞다는 걸 직접 삽질하고 나서야 알았습니다. 레이어 순서대로 디버깅하는 습관이 그때 생겼습니다. 그 삽질이 지금도 기억에 남고, 레이어 순서대로 접근하는 게 제 습관이 됐습니다.
학교 수업 프로젝트로 영화 추천 검색 기능을 만들었는데, 처음엔 단순 키워드 매칭만 썼습니다. '무서운 영화'를 치면 제목에 '무서운'이 들어간 것만 나와서 사용자 불만이 컸습니다. 쿼리 이해 단계에서 감성 키워드를 의미 단위로 바꾸는 전처리를 추가했고, 리트리벌엔 간단한 벡터 검색을 넣었습니다. 랭킹은 별점과 리뷰 수를 가중치로 넣는 정도였는데, 그 단순한 구조만으로도 체감 품질이 달라졌습니다. 각 레이어를 독립적으로 테스트할 수 있도록 설계하지 않아서 어디서 문제가 생기는지 알기 어려웠던 점이 가장 아팠습니다. 레이어 분리와 개별 평가가 왜 중요한지 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.