이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 백로그 우선순위 관리에서 RICE 프레임워크(Reach·Impact·Confidence·Effort)를 즐겨 씁니다. 각 항목을 점수화해 비교하면 '느낌상 급해 보이는 것'과 실제 임팩트가 높은 것을 구분할 수 있었습니다. 인턴 프로젝트에서 팀원들이 각자 작업을 RICE로 평가해 상위 5개를 먼저 처리하는 방식으로 합의하니, 스프린트 중간에 우선순위 재협의가 줄었습니다. 단, 수치화하기 어려운 기술 부채나 긴급 장애 대응은 별도 트랙으로 관리해야 프레임워크가 방해가 되지 않는다는 점도 배웠습니다. 어떤 도구를 쓰든 팀 전체가 기준에 동의하는 과정이 선행돼야 실효성이 있다고 봅니다.
인턴 중에 기획팀과 개발팀이 서로 다른 작업을 '이번 주 안에 해야 한다'고 주장해서 제가 중간에서 정리해야 하는 상황이 생겼습니다. 각자 이유가 있었고, 둘 다 맞는 말이었습니다. 저는 먼저 각 작업이 어떤 목표와 연결되는지를 물어보고, 스프레드시트에 영향 범위와 지연 비용을 적어봤습니다. 수치로 펼쳐놓으니 기획팀도 개발팀도 같은 그림을 보고 대화할 수 있었습니다. 결국 개발 작업을 먼저 하고 기획 검토를 병행하기로 정리됐습니다. 처음에는 한쪽 의견을 따르면 된다고 생각했는데, 양쪽이 납득하는 기준을 만드는 게 더 중요하다는 걸 그때 배웠습니다. 지금도 우선순위가 충돌할 때는 공통 기준표 하나를 먼저 그려두는 방식을 씁니다.
프레임워크 없이 급하게 우선순위를 정해야 했던 순간이 있었습니다. 팀 행사 직전에 세 가지 이슈가 동시에 터졌고, 담당자가 저 하나였습니다. RICE 같은 도구를 꺼낼 시간이 없었고, 저는 일단 '지금 안 하면 행사 자체가 막히는 것'을 첫 번째로 잡았습니다. 나머지는 행사 뒤에 처리해도 되는 것과, 다른 사람이 병행할 수 있는 것으로 나눴습니다. 막상 해보니 기준 두 가지—막히는지 여부, 본인만 할 수 있는지 여부—만 있으면 급한 순서가 빠르게 정렬됐습니다. 그 경험 이후로 상황에 따라 프레임워크를 빼도 된다는 걸 알게 됐습니다. 체계가 없어도 막히는 것을 먼저라는 단순한 기준이 실제로 작동한다는 걸 몸으로 확인한 순간이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.