이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개발 일정을 수립할 때 가장 먼저 하는 건 전체 과제를 실행 가능한 단위로 쪼개는 것이었습니다. 큰 과제 하나로 일정을 잡으면 진행 상황을 파악하기 어렵고 지연이 생겨도 늦게 알게 됩니다. 태스크를 분해한 다음에는 어떤 것이 앞서야 다른 것을 시작할 수 있는지 의존성을 파악했습니다.
병렬로 진행 가능한 작업과 순차적으로 처리해야 하는 작업을 구분하면 전체 일정이 실제로 얼마나 걸리는지 보이기 시작했습니다. 각 태스크에 걸리는 시간 추정은 항상 낙관적으로 잡히는 경향이 있어서, 의도적으로 완충 시간을 포함했습니다. 처음엔 버퍼를 넣으면 늦게 일하는 것처럼 보일까 봐 빡빡하게 잡았는데, 결국 추가 일정이 생기는 경우가 더 많았습니다. 일정 수립 이후 주기적으로 실제 진행 상황과 비교하는 것이 계획의 마지막 단계였습니다.
일정을 잡을 때 속도와 품질 중 어느 쪽을 더 중요하게 볼지 먼저 정하는 것이 실제로 일정 구조를 결정했습니다. 캡스톤 프로젝트에서 발표 일정이 고정돼 있었고, 모든 기능을 구현하면서 품질도 맞추는 건 불가능했습니다. 팀에서 핵심 기능 2개에 집중하고 나머지는 발표 이후로 미루는 결정을 했습니다. 처음엔 계획을 줄이는 게 아쉬웠지만, 그 결정 덕분에 선택한 기능은 완성도 있게 발표할 수 있었습니다. 모두 다 하려다가 전부 미완성으로 가는 것보다 낫다는 걸 그때 배웠습니다.
우선순위 결정은 줄이는 행위가 아니라 선택하는 행위라는 관점이 이후 과제에서도 이어졌습니다. 일정은 가능한 것의 목록이 아니라 해야 할 것의 순서입니다.
일정을 지킨 경험보다 못 지켰던 경험에서 더 많이 배웠습니다. 팀 프로젝트에서 처음 잡은 일정이 마지막 2주에 무너진 적이 있었습니다. 돌아보니 의존성 있는 작업을 동시에 잡아놓은 것이 문제였습니다. 한 파트가 늦어지자 연결된 파트들이 연쇄적으로 밀렸습니다.
버퍼를 넣지 않은 것도 있었지만, 더 큰 이유는 각 파트가 얼마나 걸릴지를 담당자가 아닌 제가 혼자 추정한 것이었습니다. 그 이후로는 각 태스크 담당자에게 직접 시간 추정을 받는 방식으로 바꿨습니다. 직접 하는 사람이 가장 정확하게 예측합니다. 일정 수립은 계획이 아니라 협의라는 걸 그때 경험했고, 이 교훈이 이후 과제에서도 이어졌습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 유영제약 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.