이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
수업에서 앱 기획 과제를 진행하면서 기능과 화면 우선순위를 어떻게 정할지가 가장 어려운 결정이었습니다. 저는 사용자가 가장 자주 겪는 불편과 가장 많이 수행하는 핵심 작업을 기준으로 우선순위를 잡는 방식을 씁니다. 인터뷰나 설문에서 반복적으로 등장하는 불편 1~2개를 먼저 해결하는 화면을 우선 설계합니다. 또한 개발 복잡도 대비 사용자 영향도를 함께 고려합니다.
낮은 복잡도 + 높은 영향인 기능을 먼저 구현하면 빠른 피드백을 받을 수 있습니다. 모든 기능을 동시에 완성하려다 아무것도 제대로 못 내는 경험을 했기 때문에, 핵심 1~2개를 잘 만드는 것이 전체를 잘 만드는 것보다 낫다는 생각을 갖고 있습니다.
수업 앱 기획 과제에서 기능과 화면 우선순위를 정하는 게 가장 어려운 결정이었습니다. 처음엔 떠오르는 기능을 다 넣으려다, 아무것도 제대로 못 내는 경험을 했습니다. 그래서 저는 사용자가 가장 자주 하는 핵심 작업과 가장 자주 겪는 불편을 기준으로 우선순위를 잡았습니다. 인터뷰와 설문에서 반복해 나온 불편 한두 개를 먼저 푸는 화면부터 설계한 셈입니다. 거기에 개발 복잡도 대비 사용자 영향을 함께 봐서, 낮은 복잡도에 높은 영향인 기능을 먼저 만들어 빠른 피드백을 받았습니다. 핵심 한두 개를 잘 만드는 게 전체를 어설프게 만드는 것보다 낫다는 걸 그때 배웠습니다. 다만 제 한계도 인정합니다. 무엇이 핵심 작업인지는 작은 인터뷰로 짐작한 거라, 표본이 적어 빗나갈 위험이 있었습니다. 또 당장 자주 쓰는 것만 좇다 중장기로 중요한 기능을 미룰 수도 있습니다. 그래서 핵심부터 만들되, 단기 빈도와 중장기 가치 사이의 거래를 의식하려 합니다.
기능과 화면의 우선순위를 정할 때 제가 쓰는 기준은, 개발 복잡도 대비 사용자 영향입니다. 모든 기능을 동시에 완성하려다 다 어설퍼지는 걸 겪고 나서, 빨리 되면서 효과가 큰 것부터 만드는 게 빠른 피드백을 부른다는 걸 배웠습니다. 그래서 낮은 복잡도에 높은 영향인 기능을 먼저 출시하고, 반응을 보며 다음을 정합니다. 다만 제 한계도 인정합니다. 복잡도와 영향을 가늠하는 게 제 짐작이라, 막상 만들어 보면 예상보다 복잡하거나 반응이 약한 적이 있었습니다. 또 빠른 효과만 좇으면 지금은 어렵지만 길게 중요한 기능이 계속 밀리는 함정이 있어, 단기와 중장기 사이의 거래를 의식해야 했습니다. 저는 과제 수준이라 이 추정의 정확도는 더 키워야 합니다. 그래서 우선순위를 복잡도 대비 영향으로 보되, 그 추정을 데이터로 받치고 장기 가치도 함께 보는 일로 보려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 크라우드웍스 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.