이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학교 팀 프로젝트에서 5개 기능을 4명이 나눠 개발했는데, 처음엔 누가 어떤 걸 하는지 모호해서 중복 작업이 생겼습니다. 저는 태스크를 기능 구현, 연동, 테스트 세 유형으로 나누고, 각 항목에 담당자를 붙이는 표를 만들어서 팀원들과 합의했습니다. 처음엔 번거롭다는 말이 있었는데, 표가 생기고 나서 같은 코드를 두 명이 짜는 일이 없어졌습니다.
4주 만에 기능 전체를 배포했고, 발표 때 완성도가 좋다는 피드백을 받았습니다. 태스크 관리는 도구보다 담당자가 명확한 게 먼저라는 걸 배웠습니다. 담당자가 명확한 게 도구보다 먼저라는 걸 배웠고, 이후에도 태스크 시작 전에 담당자를 먼저 정합니다.
인턴 프로젝트에서 3주 기한의 기능 개발 중에 중반까지 진행률이 30%밖에 안 됐습니다. 주 단위 계획이 너무 크게 잡혀 있어서, 하루 단위로 쪼개서 아침에 오늘 할 것 하나를 정하고 저녁에 확인하는 방식으로 바꿨습니다. 처음 며칠은 계획보다 절반밖에 못 했는데, 그게 보이니까 다음 날 범위를 줄일 수 있었습니다.
마지막 주엔 예정보다 하루 일찍 완성했습니다. 태스크 관리의 핵심은 큰 계획보다 오늘 하나를 완료하는 주기라는 걸 배웠습니다. 큰 계획보다 오늘 하나를 완료하는 주기가 핵심이라는 걸 배웠고, 이후에도 하루 단위 계획을 먼저 잡습니다. 하루 완료 주기가 쌓이면 일정이 저절로 잡힌다는 걸 배웠습니다.
사이드 프로젝트에서 개발 중간에 새 기능 요청이 3개나 추가됐습니다. 처음엔 다 넣으려다 마감을 못 지킬 것 같았고, 그때 팀원들에게 새 것 하나 추가하면 기존 것 하나를 빼야 한다고 제안했습니다. 협상 끝에 2개는 다음 버전으로 미뤘고, 1개만 추가했습니다. 마감을 지키며 배포했고, 미뤄둔 기능은 다음 스프린트에 들어갔습니다. 태스크 관리는 추가만 하는 게 아니라 무엇을 안 할지 결정하는 것이라는 걸 그때 배웠고, 이후에도 같은 방식을 씁니다.
추가만 하는 게 아니라 무엇을 안 할지 결정하는 것이 태스크 관리라는 걸 배웠고, 이후에도 같은 방식을 씁니다. 범위 협상이 팀 신뢰를 오히려 높인다는 걸 그때 경험했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.