이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 5명 팀의 PM을 맡아 중소기업 재고 관리 시스템을 만들었습니다. 처음 요구사항을 받았을 때 범위가 너무 넓어서 어디서 시작할지 막막했습니다. 그래서 먼저 클라이언트 인터뷰를 3회 진행해 "지금 가장 아픈 지점이 뭔지"를 추려냈고, 전체 기능을 코어·확장·보류 3단계로 나눴습니다. 코어만 먼저 만들고 2주마다 클라이언트에게 데모를 보여주는 방식으로 진행했는데, 처음에 팀원 중 한 명이 "기능을 왜 이렇게 줄이냐"고 반발했습니다.
그때 설득하지 못하고 넘어갔다가, 3주 뒤 그 팀원이 만든 확장 기능이 코어와 충돌하는 문제가 생겼습니다. 이후로는 기능 범위 결정 때 팀 전체가 동의하는 과정을 한 번 더 넣었습니다. 결과적으로 12주 안에 코어를 완성해 클라이언트로부터 긍정적인 피드백을 받았고, 지금도 프로젝트를 시작할 때 범위를 줄이는 게 먼저라고 생각합니다.
재고 관리 시스템 프로젝트에서 기능 범위를 좁히는 결정을 했을 때, 한 팀원이 처음에는 동의하지 않았습니다. 그때 저는 설득 대신 근거를 공유하는 방식을 택했습니다. 클라이언트 인터뷰에서 나온 '지금 가장 아픈 지점'을 정리한 자료를 팀 전체가 같이 보게 하자, 코어 기능의 우선순위가 자연스럽게 설명됐습니다. 제가 설득한 것이 아니라 데이터가 설득한 것이었습니다. 그 이후 같은 팀원이 오히려 코어 범위 안에서 기능을 더 깊이 만드는 방향으로 기여했고, 결과가 더 좋아졌습니다.
리더 역할에서 설득보다 공유가 먼저라는 것을 그 프로젝트에서 배웠습니다. 팀이 같은 맥락을 보고 있을 때 방향 결정이 훨씬 빠르게 됩니다.
12주 프로젝트를 마친 뒤 클라이언트로부터 실제 운영에 도입하고 싶다는 긍정적인 반응을 받았습니다. 그것도 의미 있었지만 저에게 더 남은 것은 팀이 함께 결정한 방향이 끝까지 유지됐다는 사실이었습니다. 팀원 반발이 있었던 시점에서 범위를 끝까지 유지한 것은 쉽지 않은 결정이었습니다.
결과가 나쁘면 그 결정이 틀린 것처럼 보이고, 좋으면 옳았다고 보이는 구조인데, 프로세스가 맞았다는 확신이 있었기 때문에 흔들리지 않을 수 있었습니다. 클라이언트 인터뷰에서 시작해서 범위 결정, 주기적 데모, 충돌 조율까지 매 단계에서 팀과 근거를 공유하는 방식을 유지한 것이 좋은 결과를 만든 이유라고 생각합니다. 그 경험이 복잡한 프로젝트를 시작할 때 먼저 하는 것들에 대한 기준이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.