이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
프로젝트 관리에서 데이터 기반 의사결정이 중요한 이유를 저는 실패 경험으로 먼저 배웠습니다. 캡스톤 프로젝트에서 기능 개발 순서를 팀원들의 직관과 선호도로 정했는데, 결과적으로 가장 많이 쓰이지 않는 기능에 공수가 집중됐고 발표 전날 핵심 기능이 미완성인 상황이 됐습니다. 그 이후로는 의사결정을 내릴 때 '이 결정을 뒷받침할 데이터가 있는가'를 먼저 확인하는 습관이 생겼습니다. 사용자 인터뷰 결과, 이슈 빈도, 완료 예상 시간 같은 수치를 놓고 토론하면 팀원 간 의견 차이가 줄어들고 결정이 빠르게 내려집니다. 물론 데이터가 없거나 빠른 결정이 필요한 상황도 있습니다. 그럴 때는 판단 근거를 명시적으로 기록해두고 나중에 검증하는 방식을 씁니다. 데이터 기반 의사결정의 핵심은 틀릴 때 왜 틀렸는지를 알 수 있게 하는 것이라고 생각합니다.
프로젝트에서 데이터 기반 의사결정이 중요한 또 다른 이유는 팀 내 주관적 의견 충돌을 줄여주는 공통 언어가 되기 때문입니다. 여러 명이 함께 방향을 결정할 때 '내 생각엔'으로 시작하는 의견은 반론도 '내 생각엔'이 되어버려 합의가 어렵습니다. 실제로 팀 프로젝트에서 기능 우선순위를 투표로 결정하다 갈등이 생겼는데, 사용 로그 데이터를 꺼내서 어떤 기능이 실제로 쓰이는지를 같이 보자고 제안했을 때 논의가 빠르게 정리됐습니다.
데이터가 있으면 감정이 아닌 사실로 대화할 수 있습니다. 공통 언어가 갈등을 줄입니다. 데이터가 합의 도구입니다. 수치가 있으면 논의가 짧아집니다.
데이터 기반 의사결정이 중요하다는 건 동의하지만, 데이터가 없거나 측정이 어려운 상황에서도 결정해야 하는 경우가 많습니다. 프로젝트 초기에는 사용 데이터 자체가 없기 때문에 초기 방향 설정은 어쩔 수 없이 가설과 판단에 기댑니다. 이 경우 데이터가 쌓이면 검증 가능한 형태로 가설을 세우는 것, 그리고 어느 지표가 의사결정에 실제로 유효한지 사전에 합의하는 것이 더 중요합니다. 데이터가 있을 때만 결정하는 게 아니라, 없을 때 어떻게 가설을 세우고 수집할지를 아는 것이 프로젝트 관리 역량의 핵심이라고 생각합니다.
데이터가 없을 때 어떻게 하느냐가 더 중요합니다. 가설이 데이터를 부릅니다. 측정 설계가 의사결정의 시작입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.