이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
명확한 답이 없는 문제에서 방향을 설정한 경험은 팀 프로젝트에서 타깃 사용자가 정해지지 않은 상태에서 서비스 방향을 결정해야 했을 때입니다. 데이터가 없는 상황에서 가장 많은 사람이 공감할 수 있는 페르소나를 설정하고, 그 관점에서 가설을 세우는 방식으로 방향을 잡았습니다. 결정이 어려울 때는 어떤 결정이든 빠르게 내리고 검증하는 것이 아무것도 하지 않는 것보다 낫다는 원칙을 적용했습니다. 가설로 시작해 프로토타입을 만들고, 실제 반응을 보고 수정하는 과정을 반복했습니다. 이 경험에서 불확실한 상황에서 완벽한 정보를 기다리는 것보다 가진 정보 안에서 최선의 방향을 잡는 것이 중요하다는 것을 배웠습니다.
명확성은 주어지는 것이 아니라 행동을 통해 만들어지는 것입니다.
명확한 답이 없는 문제에서 측정 가능한 결과로 닫는 자리가 있었습니다. 타깃 사용자가 정해지지 않은 상태에서 페르소나를 설정하고 프로토타입을 만들었는데, 그 결과를 어떻게 판단할지가 처음에는 불명확한 자리였습니다. 가설에서 시작했기 때문에, 가설이 맞는지 아닌지를 판단할 수 있는 기준을 처음부터 정해두는 것이 필요하다는 것을 배웠습니다.
'페르소나가 공감하면 성공'이라는 기준 대신 '5명 중 3명이 이 기능을 직접 사용하려는 의도를 보이면 유효한 가설'로 기준을 구체화했습니다. 이 기준이 있으면 결과를 평가할 때 의견이 아니라 관찰로 판단하는 자리가 생깁니다. 측정 기준을 먼저 정하는 것이 명확성 없는 상황에서 방향을 잡는 가장 실용적인 방법이었습니다.
명확한 답이 없는 문제에서 측정 가능한 결과는 완벽한 답을 찾는 것이 아니라 가설 검증 기준을 사전에 정하는 것이라는 것을 알고 있습니다.
명확한 답이 없는 문제에서 가설로 가르는 방식을 더 구체적으로 설명하면, 가설을 세울 때 '이것이 맞을 것이다'가 아니라 '이것이 맞다면 무엇이 달라져야 하는가'를 함께 정하는 방식이 효과적이었습니다. 타깃 사용자 페르소나를 설정한 이후, 그 페르소나가 맞다면 어떤 기능에 반응을 보여야 하는지를 미리 정해뒀습니다.
실제로 반응이 기대와 달랐을 때, 페르소나 설정이 잘못된 것인지 아니면 기능 구현이 의도와 달라진 것인지를 구분하는 기준이 있었습니다. 두 가지를 구분하지 못하면 가설 검증이 아니라 결과 해석이 되어버리는 자리가 있습니다. 가설로 가르는 것이 맞고 틀림을 결정하는 것이 아니라, 무엇이 달라지면 가설이 맞다고 볼 수 있는지를 먼저 정하는 것입니다.
불확실한 상황에서 가설로 가르기는 정답을 추측하는 것이 아니라 검증 기준을 먼저 세우는 것이라는 것을 알고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 경영기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.