이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 헬스케어 앱 기능 기획을 담당했는데, 팀원마다 원하는 기능이 달라서 목록이 12개로 늘어났습니다. 먼저 각 기능을 사용자 스토리 형식으로 적어서 팀 전체가 같은 방식으로 이해하게 만들었고, 사용자 가치와 구현 복잡도 두 축으로 2×2 매트릭스를 그려 우선순위를 나눴습니다. 1순위에 들어간 기능 4개를 기준으로 마일스톤을 나눴고, 각 마일스톤마다 구현 가능한 범위를 명확히 했습니다. 개발 중간에 교수님이 새 기능 추가 피드백을 주셨는데, 그 기능이 기존 1순위 중 어느 것보다 중요한지를 같은 기준으로 판단해 추가 여부를 결정했습니다. 로드맵은 한 번 만들어도 바뀌는 상황을 반영할 수 있는 구조를 처음부터 갖춰야 한다는 걸 그 경험에서 배웠습니다.
캡스톤에서 기능 우선순위를 정할 때 팀원들 사이에 이견이 생긴 것이 가장 기억에 남습니다. 각자 자신이 중요하다고 생각하는 기능을 주장했는데, 이야기가 길어질수록 합의보다 설득 경쟁이 됐습니다. 기준이 없으니 각자 자기 경험 기반으로 이야기하고, 의견이 모이지 않았습니다. 그때 먼저 '우리 서비스를 쓸 사용자가 가장 먼저 만나는 문제가 무엇인지'를 함께 정의하자고 제안했습니다. 그 질문을 기준으로 기능을 다시 보자 팀원들이 같은 방향으로 생각하게 됐고, 우선순위 논쟁이 빠르게 정리됐습니다.
이견은 의견이 달라서 생기는 게 아니라 기준이 달라서 생긴다는 것을 그때 이해했습니다. 기준을 먼저 정하는 것이 협업에서 시간을 가장 많이 줄이는 방법이라는 것을 캡스톤 과정에서 배웠습니다.
캡스톤 중반에 교수님이 새 기능 추가 피드백을 주셨을 때, 이것을 바로 넣어야 할지 판단하는 과정이 실제 제품 관리에서 자주 있는 상황이라는 것을 느꼈습니다. 처음에는 교수님 의견이니 넣어야 한다는 분위기였는데, 저는 이미 정한 우선순위 매트릭스로 그 기능을 한 번 평가해보자고 먼저 제안했습니다. 사용자 가치는 높지만 구현 복잡도도 높아서, 1순위보다 먼저 들어갈 기능은 아니라는 판단이 나왔습니다. 팀에게 그 판단 과정을 설명하면서 2순위로 추가하는 방향으로 정했습니다.
로드맵은 변경을 막는 것이 아니라 변경을 판단하는 기준을 갖추는 것이라는 것을 그때 이해했습니다. 변경 요청을 받을 때마다 처음부터 다시 시작하지 않고 기존 기준으로 판단하는 것이 로드맵의 역할이라는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.