이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 신규 기능 개발 중에 기존 기능에서 버그 리포트가 들어왔습니다. 일정이 있는 기능과 사용자가 발견한 버그 중 무엇을 먼저 할지 물어봤는데, 멘토가 직접 판단해보라고 했습니다. 버그 영향 범위를 먼저 확인했더니 특정 기기에서만 재현되고 핵심 기능은 아니었습니다. 기능 개발을 유지하면서 다음 스프린트에 버그를 넣기로 했습니다. 결과적으로 맞는 판단이었다는 피드백을 받았습니다. 이 경험으로 우선순위 결정은 영향 범위, 사용자 수, 긴급도 세 가지를 같이 봐야 한다는 것을 배웠습니다.
단순히 들어온 순서로 처리하면 중요한 것을 놓친다는 것을 느꼈습니다. 그 과정이 값진 배움이었습니다.
사이드 프로젝트를 시작할 때 기능 목록을 30개 넘게 써놓고 다 구현하려 했어요. 결국 2달 동안 아무것도 배포 못 한 채로 계속 기능을 만들기만 했어요. 그때 MVP 개념을 다시 읽고, 사용자가 서비스를 쓰는 핵심 경로 1개만 먼저 만들기로 했어요. 나머지는 일단 백로그에 넣고 핵심 기능만 3주 만에 배포했어요. 배포 후에 실제 사용 패턴을 보니 30개 중 실제로 필요한 건 5개 정도였어요. 미리 다 만들었다면 25개는 버려질 기능이었던 거예요. 우선순위는 내가 중요하다고 생각하는 것보다 실제로 쓰이는 것 기준으로 잡아야 한다는 걸 배웠어요.
그 과정이 값진 배움이었습니다.
졸업 프로젝트 팀에서 기능 추가를 원하는 팀원과 안정성 개선을 원하는 팀원 사이의 의견 충돌이 있었어요. 저는 중간에서 각자 이유를 물어봤는데, 기능 추가를 원하는 팀원은 발표용이 걱정됐고, 안정성 개선을 원하는 팀원은 데모 중 오류가 무서웠던 거예요.
사실 목표는 같았고 접근 방법이 달랐던 거예요. 결국 이틀 안에 고칠 수 있는 버그만 먼저 잡고, 나머지 시간에 기능 1개를 추가하는 방식으로 합의했어요. 우선순위 갈등은 대부분 목표가 아닌 방법 차이라는 걸 느꼈어요. 목표를 먼저 맞추면 방법은 쉽게 합의됐어요.
경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 Tmap Mobility 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.