이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 사용자 인터뷰로 피드백을 수집하는 과정을 처음 경험했습니다. 가장 어려웠던 건 같은 불만을 다르게 표현한 피드백들을 하나의 문제로 묶는 과정이었습니다. '버튼 찾기 어렵다'와 '어디서 해야 하는지 모르겠다'는 말이 사실 같은 UX 문제였는데, 그걸 파악하는 데 시간이 걸렸습니다. 이후엔 피드백을 수집할 때 사용자가 원하는 것보다 실제로 어디서 막히는지를 먼저 관찰하는 방식으로 바꿨습니다. 우선순위를 잡을 때는 영향받는 사용자 수와 문제의 심각도를 기준으로 매트릭스를 만들어 팀과 정했습니다. 빠르게 수정하고 다시 테스트하는 사이클을 짧게 유지했더니 방향이 틀렸을 때 되돌리는 비용이 줄었습니다.
무엇을 바꿀지 결정하는 것이 피드백 이터레이션에서 가장 어려운 부분이라는 걸 배웠습니다.
사용자 피드백을 받아 개선하는 사이클을 한 번 끝내고 나서, 다음 사이클에 무엇을 기준으로 개선 여부를 판단할지가 어려웠습니다. 개선 전과 후를 비교하기 위해 주요 사용자 행동 지표(태스크 완료율, 오류 발생 빈도)를 수치로 기록하기 시작했습니다. 변경 전 수치를 먼저 기록해두고, 개선 후 같은 지표를 다시 측정해 비교하는 방식이었습니다. 수치가 없으면 개선됐다는 느낌만 있고 실제로 달라졌는지 모르는 결이 있었습니다. 이 구조를 만들고 나서 팀 내에서 어떤 변경이 어떤 효과를 냈는지 공유하는 방식이 생겼습니다.
이터레이션은 한 번의 사이클이 아니라 측정을 기반으로 축적되는 과정이라는 것을 이 경험에서 배웠습니다.
사용자 피드백을 수집했더니 서로 상반된 요구가 들어오는 경우가 있었습니다. 어떤 사용자는 기능을 더 단순하게 만들어달라고 했고, 다른 사용자는 기능이 부족하다고 했습니다. 처음에는 두 요구를 모두 반영하려다가 방향이 없는 결이 됐습니다. 두 그룹 중 핵심 사용자가 누구인지를 먼저 정하는 것이 충돌하는 피드백을 해소하는 방법이라는 것을 배웠습니다. 타겟 사용자를 명확히 정하니 어떤 피드백을 따를지 기준이 생겼습니다.
피드백은 데이터지만, 무엇을 할지는 결국 제품 방향성에 대한 결정의 결이 있다는 것을 이 경험에서 배웠습니다. 모든 피드백을 반영하려 하면 아무것도 제대로 완성되지 않는 결이 있었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.