우선순위 질문은 급하고 중요한 일을 안다는 사실이 아니라 변화가 발생했을 때 혼자 판단하는 범위와 팀과 확인하는 범위를 어떻게 나누는지를 본다. 우선순위 프레임워크를 아는 것보다 그것을 실제 상황에서 왜 그렇게 적용했는지가 채점의 핵심이다.
면접관은 무엇을 보나
우선순위를 정하는 과정이 답에 있어야 합니다. 없으면 면접관이 '그 기준은 무엇이었나요?'를 추가로 묻는 경우가 자주 보입니다.
상황 변화에 대한 구체적인 대응 사례가 답에 포함된 흔적이 있어야 합니다. 없으면 면접관이 '그때 어떤 선택을 했나요?' 같은 질문을 던지는 자리가 자주 보입니다.
업무를 진행하는 방식이나 전략이 답에 나타나야 합니다. 없으면 면접관이 '어떤 도구나 방법을 사용했나요?'를 추가로 묻는 경우가 많습니다.
팀과의 협업 과정이 답에 있어야 합니다. 없으면 면접관이 '팀원들과 어떻게 소통했나요?'를 추가로 묻는 경우가 자주 보입니다.
읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?
모범 답변의 결
기준 명확화·긴급-중요 구분·팀 공유 경험 연결 중심으로 푸는 결
빠르게 바뀌는 상황에서는 무엇을 먼저 할지 기준을 빨리 잡는 것이 중요하다고 생각합니다. 저는 긴급도와 중요도를 두 축으로 나눠서, 둘 다 높은 것부터 처리하고 긴급하지 않지만 중요한 일은 시간을 따로 확보해두는 방식을 씁니다. 인턴 때 배포 직전에 요구사항이 바뀐 적이 있었는데, 모든 걸 다 바꾸려다가 핵심 기능 완성이 늦어진 경험을 했습니다. 그 이후로는 변경이 생기면 먼저 "이게 지금 바꿔야 하는 건가 아니면 다음으로 넘길 수 있는 건가"를 팀리드에게 먼저 확인하는 습관을 붙였습니다. 혼자서 판단하다 보면 우선순위를 잘못 잡을 때가 있어서, 팀과 현재 상황을 짧게 공유하고 정렬하는 시간을 먼저 갖는 것이 결국 속도를 높이는 방법이었습니다. 작업 중간에 새로운 요청이 들어오면 기존 목록에 추가만 해두고 현재 작업을 끝내는 것을 원칙으로 삼고 있는데, 컨텍스트 스위칭이 너무 잦으면 결국 다 늦어지는 패턴을 여러 번 경험했기 때문입니다. 불확실한 상황일수록 작은 단위로 끊어서 완료 기준을 명확히 하는 게 진행 상태를 가시화하는 데 도움이 됐습니다.
전문가의 심화 해설
기준 설정→실패 경험→습관화 순서로 신뢰를 쌓는다
좋은 답은 '긴급도와 중요도로 나눈다'는 기준을 먼저 제시하고, 그 기준이 무너졌던 실패 경험(모든 걸 바꾸려다 핵심 기능 완성이 늦어진 경우)을 붙인 뒤, 그 이후 바뀐 습관(변경 시 팀리드에게 먼저 확인하는 절차)으로 마무리하는 흐름을 따른다. 기준만 말하면 이론을 암송한 것처럼 들리지만, 실패를 거쳐 습관으로 굳어진 서사는 실제로 겪어본 사람의 논리로 읽힌다.
혼자 판단하는 범위와 팀에 확인하는 범위를 구분하는지가 갈림선
합격선은 우선순위를 잘 정했다는 결과가 아니라 어디까지는 혼자 판단하고 어디부터는 팀과 확인해야 하는지 경계를 아는지에서 갈린다. 모든 것을 혼자 판단하려는 태도는 독단으로 읽히고, 모든 것을 팀에 묻는 태도는 판단력 부재로 읽힌다. 컨텍스트 스위칭을 줄이기 위해 새 요청은 목록에 추가만 하고 현재 작업을 끝낸다는 원칙처럼, 판단의 경계를 스스로 세운 흔적이 있어야 한다.
'우선순위가 잘못됐던 경험'이 성찰의 깊이를 가른다
이 꼬리질문은 실패를 인정하는지 자체보다 왜 그 판단이 그 시점에는 합리적으로 보였는지를 설명할 수 있는지를 본다. 단순히 '틀렸다'로 끝내면 반성만 있고 개선이 안 보이지만, 그 판단의 전제(정보 부족, 우선순위 기준 미확립 등)를 짚고 이후 무엇을 바꿨는지 이어가면 성장 서사로 읽힌다. 실패를 숨기고 완벽한 판단만 했다고 답하면 오히려 경험의 진정성이 의심된다.
직무·역할 단계에 따라 우선순위 판단의 범위가 다르다
실무 담당자 수준이라면 본인 업무 범위 내에서의 우선순위 조정이 중심이지만, 리드나 매니저 역할이라면 여러 담당자의 우선순위를 조율하는 능력이 더 중요하게 읽힌다. 본인의 실제 역할 범위를 벗어난 권한을 과장하지 않는 것이 특히 주니어 지원자에게는 신뢰의 기준이 된다. 인턴이나 신입 경험이라면 개인 업무 단위의 우선순위 조정 경험이 오히려 더 진솔하게 읽힌다.
프레임워크 이름만 대고 적용 사례가 빈약한 함정
흔한 함정은 아이젠하워 매트릭스 같은 프레임워크 이름을 대는 데서 답이 끝나는 것이다. 프레임워크는 사고의 틀일 뿐이고, 그 틀을 실제 상황에 어떻게 적용했는지가 없으면 이론 암기로 읽힌다. 또 다른 함정은 우선순위를 정하는 과정에서 팀과의 소통을 전혀 언급하지 않는 것이다. 협업 없이 혼자 모든 판단을 내린 것처럼 답하면 팀에서 일하는 능력에 의문이 생긴다.
이어질 수 있는 꼬리질문
이런 상황에서 우선순위를 정할 때 가장 중요하게 생각하는 기준은 무엇인가요?
기준을 명확히 하면 판단력이 드러납니다. 그 기준이 어디서 나왔는지 설명하면 더 깊이가 살아납니다.
과거에 우선순위 설정 때문에 어려움을 겪었던 경험이 있나요?
어려운 경험을 공유하면 자기 이해도가 드러납니다. 그 경험에서 무엇을 배웠는지 짚으면 성장감이 살아납니다.
상황이 급변했을 때 결정한 우선순위가 잘못된 적은 없었나요?
잘못된 결정을 인정하고 반성하면 객관성이 드러납니다. 왜 그렇게 판단했는지까지 설명하면 깊이가 있습니다.
흔히 빠지는 실수
- 프레임워크 이름만 언급하고 실제 적용 사례나 판단 근거를 설명하지 않습니다.
- 혼자 판단하는 범위와 팀과 확인하는 범위를 구분하지 않고 모든 걸 독단적으로 처리한 것처럼 답합니다.
- 우선순위가 잘못됐던 경험을 숨기고 완벽한 판단만 했다고 말합니다.
- 실제 역할 범위를 넘어서는 조율 권한이 있었던 것처럼 과장합니다.
- 컨텍스트 스위칭이나 새 요청 처리 원칙 없이 즉흥적으로 대응했다는 인상을 남깁니다.
이 질문이 나온 회사
실제 면접에서 이 질문이 확인된 회사입니다.