이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사용자 중심 제품 개발 경험은 학교 팀 프로젝트에서 앱 프로토타입을 제작했던 것이 있습니다. 개발 시작 전에 대상 사용자 5명을 인터뷰해 어떤 불편함이 있는지를 먼저 파악했습니다. 이 과정에서 저희가 예상한 문제와 실제 사용자 불편함이 달랐고, 가정보다 실제 사용자의 목소리가 더 정확한 문제를 가리킨다는 것을 배웠습니다. 프로토타입을 만든 후 사용성 테스트를 진행해 개선점을 반영했습니다. 완성된 화면보다 초기 와이어프레임 단계에서 피드백을 받는 것이 수정 비용이 낮다는 것도 알게 됐습니다.
좋은 제품은 사용자 관찰에서 시작된다는 원칙이 이 경험에서 확인됐습니다.
앱 기획 수업에서 팀 프로젝트를 할 때, 초반에는 팀원이 원하는 기능을 기준으로 설계했습니다. 완성하고 나서 주변 사람들에게 써보게 했더니, 우리가 중요하다고 생각한 기능을 거의 아무도 쓰지 않았습니다. 그 경험에서 사용자 중심 개발이 단순 슬로건이 아니라는 걸 실감했습니다. 이후 프로젝트에서는 기능을 추가하기 전에 5명 이상의 예상 사용자에게 직접 물어보는 단계를 넣었습니다. 인터뷰를 통해 사람들이 실제로 불편하게 여기는 지점과 우리가 예상한 불편 사이에 차이가 꽤 크다는 걸 반복적으로 확인했습니다. 사용자 관점을 유지하는 게 어려운 건, 자신이 만드는 사람이라는 시선에서 벗어나는 것 자체가 쉽지 않기 때문이었습니다. 아직 실무에서 프로덕트를 운영한 경험은 없지만, 사용자에게 직접 물어보는 단계를 넣는 습관이 생겼고, 그게 가장 중요하게 익힌 것입니다.
사용자 중심 개발에서 실제로 사용하는지를 수치로 확인하지 않으면 개선 방향을 잡기 어렵다는 걸 배웠습니다. 팀 프로젝트에서 만든 서비스에 구글 애널리틱스를 연동해서 어느 화면에서 사용자가 이탈하는지를 봤습니다. 예상과 달리 온보딩 두 번째 단계에서 이탈이 집중됐는데, 그 화면이 텍스트가 너무 많았다는 걸 데이터로 처음 인식했습니다. 감으로만 개선을 시도하다가 이탈률 데이터를 보고 나서야 원인을 좁힐 수 있었습니다. 그 이후로는 기능을 만들 때 어떤 지표로 성공을 판단할지를 먼저 정의하는 습관을 들였습니다. 아직 정교한 A/B 테스트나 코호트 분석 경험은 없습니다. 하지만 측정 기준 없이 만들면 개선의 근거가 없다는 감각은 그 경험에서 확실히 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.