이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 사내 문서 검색 기능 개선 프로젝트에서 기획 보조를 맡은 경험이 있습니다. 처음에 주어진 과제는 '검색이 불편하다는 피드백이 있으니 개선해달라'는 수준이었습니다. 저는 먼저 문제를 더 구체적으로 정의하기 위해 CS 티켓 중 검색 관련 불만을 분류하고 패턴을 찾았습니다. 분석 결과 '원하는 문서가 결과에 없다'는 유형과 '결과가 너무 많아 원하는 것을 고르기 어렵다'는 유형이 거의 반반이었습니다. 두 문제는 해결 방향이 달라서 전자는 색인 범위 확장, 후자는 필터링 기능 강화로 나눠 제안했습니다. 팀장님 리뷰에서 '문제를 두 가지로 나눈 점이 기획 방향을 명확하게 해줬다'는 피드백을 받았습니다. 문제를 정의하는 것이 해결책을 찾는 것보다 더 중요한 단계라는 점을 이 경험에서 배웠습니다.
이전 프로젝트에서 제가 맡은 역할에서 가장 중요하게 한 것은 막연한 문제를 구체적으로 쪼개는 것이었습니다. 인턴 때 '검색이 불편하다'는 수준의 과제를 받았는데, 그대로는 무엇을 고쳐야 할지 알 수 없었습니다. 그래서 저는 CS 티켓 중 검색 관련 불만을 분류해 패턴을 찾았습니다. 보니 '원하는 문서가 결과에 없다'는 유형과 '결과가 너무 많아 고르기 어렵다'는 유형이 거의 반반이었습니다. 두 문제는 해결 방향이 완전히 달라, 전자는 색인 범위 확장, 후자는 필터링 강화로 나눠 제안했습니다. 한 덩어리로 봤다면 엉뚱한 해결책을 냈을 것입니다. 문제를 정의하는 것이 해결책을 찾는 것보다 더 중요한 단계라는 것을 그때 배웠습니다. 그래서 저는 고치기 전에 문제부터 쪼갭니다.
이전 프로젝트에서 제가 배운 것은 해결안이 실제로 효과가 있었는지를 확인하는 것입니다. 문서 검색 개선을 제안한 뒤, 그것이 정말 불만을 줄였는지를 봐야 의미가 있다고 생각했습니다. 그래서 저는 개선 전후로 검색 관련 CS 문의가 줄었는지, 사용자가 원하는 문서에 더 빨리 닿는지를 비교해 봤습니다. 제안만 하고 결과를 안 보면, 그것이 맞았는지조차 모릅니다. 또 한 유형은 개선됐지만 다른 유형은 여전한지를 나눠 보니, 다음에 무엇을 더 손볼지가 보였습니다. 문제 해결은 안을 내는 데서 끝나는 것이 아니라, 그 안이 실제로 효과를 냈는지를 측정하고 다음으로 잇는 것이라고 생각합니다. 그래서 저는 해결안을 낼 때부터 무엇으로 효과를 확인할지를 함께 정합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 스마일게이트(사업부문) 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.