이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
프로젝트 우선순위를 정할 때 저는 영향도 × 긴급도 × 실현 가능성 세 축을 기준으로 판단합니다. 영향도는 이것을 하면 목표에 얼마나 가까워지는가, 긴급도는 지금 안 하면 비용이 어떻게 되는가, 실현 가능성은 현재 리소스로 실제로 할 수 있는가입니다. 팀 프로젝트에서 이 기준을 표로 정리해 공유하자 팀원 간 우선순위에 대한 이견이 줄었습니다. 환경이 바뀌어 기존 우선순위가 맞지 않게 됐을 때는 기준 자체를 재정의하기보다 입력값만 업데이트하는 방식이 빠른 재조정을 가능하게 했습니다.
우선순위는 한 번 정하는 것이 아니라 조건이 바뀔 때마다 다시 점검하는 것이라고 생각합니다. 앞으로도 우선순위를 다룰 때 한 번 정하는 것이 아니라 조건이 바뀔 때마다 다시 점검하는 방식을 유지하겠습니다. 좋은 우선순위는 기준이 명확할 때 빠르게 재조정됩니다. 우선순위는 조건이 바뀔 때마다 점검하는 것이고, 기준이 명확할 때 재조정이 빠릅니다.
우선순위를 정할 때 가장 어렵게 느낀 것은 기준이 있어도 팀원마다 같은 항목에 다른 점수를 주는 상황이었습니다. 팀 프로젝트에서 기능 목록에 각자 우선순위를 매겼는데, 어떤 기준으로 점수를 줬는지가 다 달랐습니다. 그 이후로는 기준을 먼저 맞추고 점수를 매기는 순서를 따르게 됐습니다. 제가 쓰는 방식은 이해관계자별로 이 항목이 빠지면 어떤 손실이 생기는가를 역으로 묻는 방식입니다. 기능의 가치보다 빠졌을 때 누구에게 어떤 문제가 생기는지를 먼저 보면, 팀마다 다른 기준이 자연스럽게 정렬됩니다. 환경이 바뀌어 기존 우선순위를 다시 논의해야 할 때도, 기준이 문서화되어 있으면 재조정 논의가 신규 논의가 아닌 기준 업데이트로 좁아집니다. 우선순위 다툼의 상당수는 기준을 공유하지 않은 채 결론만 공유한 데서 생긴다는 걸 그 경험에서 배웠습니다.
우선순위 재조정이 가장 급박했던 경험은 발표 이틀 전에 핵심 데이터 소스가 갑작스럽게 차단된 상황이었습니다. API 제공 기관이 정책을 변경하면서 수집해두던 데이터 일부를 더 이상 쓸 수 없게 됐습니다. 재조정 기준은 단순하게 잡았습니다. 이 데이터 없이도 결론을 유지할 수 있는가, 그리고 대체 소스로 채울 수 있는가 두 가지였습니다. 이 기준으로 분석 항목을 세 그룹으로 나눴고, 유지 가능한 것만 남겨 발표 범위를 좁혔습니다. 처음 계획을 버리기 싫어하는 팀원도 있었지만, 기준이 먼저 있으니 설득이 빠르게 됐습니다. 그 발표에서 오히려 간결하다는 평가를 받았습니다. 변화에 대응할 때 필요한 것은 유연성보다 기준의 명확함이라는 걸 그 경험에서 배웠습니다. 조건이 바뀌어도 기준이 살아있으면 결정이 빠릅니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.