이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 검색이 이상하다는 피드백이 왔는데, 처음엔 '이상하다'는 게 너무 모호했습니다. 사용자 3명에게 직접 어떤 경우에 이상하다고 느끼는지 물었더니, 입력한 것과 다른 카테고리 결과가 나온다는 게 공통점이었습니다. 문제를 '쿼리 의도를 잘못 분류하는 문제'로 정의했습니다. 쿼리 처리 레이어를 분리해서 어디서 의도가 틀리는지 확인했고, 전처리 단계에서 카테고리 매핑이 오래된 게 원인이었습니다. 복잡한 검색 문제는 막연한 이상함을 구체적 정의로 바꾸는 것부터 시작임을 배웠습니다.
문제 정의를 잘못하면 솔루션을 아무리 잘 만들어도 의미가 없다는 걸 그 프로젝트에서 직접 경험했습니다. 첫 단추를 제대로 꿰는 게 중요합니다.
학교 프로젝트에서 추천 기능을 만들었는데 전체 만족도는 괜찮은데 특정 사용자에게서만 불만이 나왔습니다. 전체 평균만 보면 문제가 안 보이는 상황이었는데, 사용자 그룹을 나눠서 보니 신규 가입자에게서 만족도가 절반이었습니다. 신규 사용자는 이력 데이터가 없어 추천이 제대로 작동 안 한다는 걸 발견했습니다. 신규 사용자 전용 로직을 추가했고, 신규 그룹 만족도가 40% 올랐습니다. 추천 문제는 평균이 아니라 그룹별로 나눠서 봐야 진짜 문제가 보인다는 걸 배웠습니다.
팀원들과 매주 짧은 동기화 미팅을 가지면서 방향이 틀어지는 걸 빠르게 잡을 수 있었습니다. 작은 정렬이 큰 낭비를 막습니다.
사이드 프로젝트에서 검색 로그를 보니 실패 유형이 10가지가 넘었습니다. 무엇부터 고쳐야 할지 막막했는데, 발생 빈도와 사용자 이탈률을 교차해서 보니 2가지 유형이 이탈의 70% 를 차지했습니다. 그 2가지를 먼저 정의하고 집중해서 해결했습니다. 10가지를 다 고치려 했으면 어느 것도 제대로 못 했을 것 같은데, 2가지에 집중하니 2주 만에 의미 있는 개선이 됐습니다.
이탈률이 18% 낮아졌습니다. 복잡한 문제 정의는 전체를 보다가 막히면 임팩트 기준으로 좁히는 것이 효과적임을 배웠습니다.
결과 발표 이후 사용자 인터뷰에서 예상과 다른 반응을 받았고 그게 다음 이터레이션의 출발점이 됐습니다. 데이터보다 직접 들은 말이 더 선명했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.