이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 '고객 리텐션 관련 인사이트를 뽑아보라'는 목표만 있고 기준이 없는 과제를 받은 적이 있습니다. 처음에는 어떤 지표를 봐야 할지 막막했는데, 일단 사용 가능한 데이터 테이블을 먼저 목록화하고, 리텐션을 정의할 수 있는 기준 후보 3가지를 만들어 팀장님께 확인받았습니다. 주도적으로 실행한 부분은 확인 전에 '이 기준이 맞는지 모르겠지만 먼저 시안을 만들어 가져왔다'는 방식으로 접근한 것입니다. 기다리면서 방향이 생기길 바라는 대신 초안을 들고 가는 편이 실질적인 피드백을 빠르게 얻을 수 있었습니다. 해결 방안은 월 1회 이상 로그인한 사용자를 기준 리텐션 코호트로 정의하고 3개월치 추이를 시각화한 분석 보고서를 제출했습니다. 결과 공유 후 팀에서 해당 정의를 월간 리포트 기준으로 채택했습니다.
모호한 상황일수록 먼저 움직이고 나서 방향을 좁히는 것이 유효하다는 걸 배웠습니다.
모호한 상황에서 문제를 정의한 다른 경험은 팀 프로젝트에서 역할이 명확하게 나뉘지 않았을 때였습니다. 팀이 구성됐는데 '분석 담당'이라는 역할만 있고 구체적으로 무엇을 해야 하는지 정해지지 않은 상태였습니다. 회의에서 아무도 먼저 말하지 않으면 프로젝트 방향이 안 잡힌다고 판단해서 내가 생각하는 분석 담당 역할을 먼저 정의해서 공유했습니다. '데이터 수집, 전처리, 시각화는 분석 담당이 맡고, 해석과 발표는 팀 전체가 참여한다'는 형태로 제안했고, 팀원들이 동의해서 그것이 기준이 됐습니다.
역할 모호성이 해소되지 않으면 중간에 책임 소재가 불분명해진다는 것을 알고 있어서 먼저 정의한 것입니다. 모호한 상황에서 스스로 역할을 정의하는 것이 팀 전체의 시간을 절약하는 방법이라는 것이 이 경험의 핵심입니다.
모호한 과제에서 해결 방안을 만들 때 제가 중요하게 생각하는 것은 내가 세운 가정을 숨기지 않는 것입니다. 요건이 불명확한 상태에서 분석을 하면 내가 임의로 가정을 세우게 되는데, 그 가정이 틀렸을 때 결과 전체를 다시 해야 하는 문제가 생깁니다. 인턴 과제에서 리텐션 기준을 스스로 정의하고 분석했을 때, 결과를 제출하면서 '이 기준은 제가 설정한 것이고, 다른 기준이 맞는다면 수치가 달라집니다'라고 명시했습니다. 팀장님이 그 투명성을 오히려 긍정적으로 평가했고, 내가 설정한 기준이 실제 비즈니스 맥락과 맞는지를 같이 확인하는 과정이 됐습니다. 가정을 숨기면 결과가 맞아 보이지만 나중에 더 큰 수정이 필요해집니다.
가정을 명시하고 검증을 요청하는 것이 모호한 문제를 다루는 더 안전한 방식이라는 것이 이 경험에서 배운 핵심입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.