개발 견적의 공수와 실제 일정은 왜 다를까요?

오늘의 인사이트 요약

• 공수는 작업에 들어갈 사람의 노력량이고, 기간은 시작부터 끝까지 걸리는 시간입니다.

• 인원 수뿐 아니라 실제 투입 시간, 작업 순서, 외부 대기를 알아야 일정을 잡을 수 있습니다.

• 견적서의 포함 범위와 일정표의 검수·출시 조건을 연결해 확인합니다.

개발 견적서에 공수는 적혀 있는데 언제 출시할 수 있는지는 바로 알기 어려우실 텐데요. 공수와 기간은 서로 다른 값입니다. 공수는 필요한 사람의 작업량을, 기간은 그 작업을 실제로 끝내는 데 걸리는 시간을 뜻합니다. 오늘은 개발 견적에서 쓰는 공수 단위와 기간의 차이, 일정표와 함께 확인할 조건을 알아보겠습니다.

1. 개발 공수는 어떤 단위일까?

공수는 작업에 들어가는 노력량을 사람과 시간의 조합으로 나타낸 값입니다. 견적서에서 M/D는 Man-Day, M/M은 Man-Month를 뜻하는 표기로 쓰입니다. 각각 한 사람이 하루 또는 한 달 일하는 양을 기준으로 하지만, 문서에 따라 사람일·인일·인월 등으로 적기도 합니다. 표기만 보고 계산하기보다 해당 견적서의 단위 정의를 확인하는 편이 정확합니다.

특히 하루의 작업 시간과 월 환산 기준을 확인합니다. 월을 며칠로 계산하는지 정하지 않으면 같은 숫자를 서로 다르게 해석할 수 있습니다. 기획, 디자인, 개발, 검수 중 어떤 역할과 작업이 공수에 들어 있는지도 함께 살펴봅니다. 공수는 기능 개수나 완성된 화면 수와 일대일로 대응하는 값이 아닙니다.

공수와 경과 시간의 차이

가정상 한 사람이 온전히 맡아 이틀 일할 작업이라면 노력량은 2인일입니다. 그 사람이 하루 중 절반만 투입할 수 있다면 작업을 끝내는 데 더 많은 근무일이 필요할 수 있습니다. 이 예시는 단위의 차이를 설명하기 위한 단순 계산이며, 실제 개발 속도가 투입 비율대로 정확히 변한다는 뜻은 아닙니다.

사람이 일한 양과 달력상 흐른 시간을 구분하는 개념은 PMI의 애자일 프로젝트 관리 자료에서 더 자세히 보실 수 있습니다. 예상 작업량을 정하는 일과 그 일을 언제 수행할지 정하는 일이 나뉜다는 점을 이해하면 견적서와 일정표를 함께 읽기 쉬워집니다.

2. 인원이 늘어도 기간이 그대로인 이유

모든 작업을 동시에 진행할 수는 없습니다. 예를 들어 결제 내역 화면을 만들려면 저장할 데이터와 응답 규칙을 먼저 정해야 할 수 있습니다. 앞 작업의 결정이나 결과가 있어야 시작하는 관계를 의존 관계라고 합니다. 공수를 전부 더한 뒤 인원 수로 나누면 이런 순서가 사라집니다.

함께 진행할 수 있는 작업도 같은 담당자의 시간을 쓸 수 있습니다. 두 업무가 각자 짧더라도 한 사람이 동시에 전부 맡을 수 없다면 시작과 완료 시점을 조정합니다. 담당자가 다른 프로젝트에 참여하는지, 특정 기간에 검토 가능한지에 따라서도 일정은 달라집니다. 몇 명이 참여하는지와 함께 실제로 배정할 시간을 확인하는 이유입니다.

출시일을 좌우하는 작업의 연결

일정에서는 뒤 작업으로 이어져 전체 완료일을 좌우하는 경로를 살펴봅니다. 여유 없이 이어진 작업이 늦어지면 뒤의 검수나 출시도 영향을 받습니다. 이처럼 일정의 여유를 고려했을 때 프로젝트 기간을 결정하는 작업 경로를 임계 경로라고 부릅니다. 관련 없는 작업에 인원을 더 배치해도 이 경로의 대기를 줄이지 못하면 출시일이 그대로일 수 있습니다.

작업 순서와 자원, 기간을 연결해 일정의 타당성을 확인하는 방법은 미국 GAO의 일정 평가 가이드를 참고해 보세요. 개발 견적을 검토할 때도 어떤 작업이 무엇을 기다리는지를 일정표에 드러내면, 막연히 인원을 늘리는 제안보다 지연 원인에 맞는 대안을 논의하기 쉽습니다.

3. 견적서와 일정표를 연결하는 질문

작업에 사람이 붙지 않는 시간도 출시 전에 남을 수 있습니다. 가상의 외부 결제 연동 프로젝트라면 계정 발급과 외부 승인 대기가 그 예입니다. 개발자가 일하는 공수와 승인기관의 처리 기간은 별도로 볼 수 있습니다. 착수 전에 필요한 계정과 자료, 검토 담당자를 정하면 어떤 조건으로 일정을 잡았는지 더 분명하게 설명할 수 있습니다.

검수도 마지막 날짜 하나로 끝나는지 확인합니다. 기능 확인 뒤 수정하고 다시 시험할 과정이 있다면 검수와 재확인을 일정에 넣습니다. 실제 운영 환경으로 옮기기 위한 설정, 배포 후 확인을 누가 맡는지도 정합니다. 코드 작성 완료, 검수 승인, 공개 출시를 같은 완료 시점으로 적으면 서로 다른 기대가 생길 수 있습니다.

미확정 조건과 변경의 영향

외부 API 제공 방식이나 데이터 상태가 아직 확인되지 않았다면 견적의 전제로 남깁니다. 확인할 담당자와 시점, 예상과 다를 때 다시 검토할 범위를 적습니다. 정해지지 않은 조건이 있는데도 공수 숫자만 확정값처럼 전달하면 이후 일정 변경의 이유를 설명하기 어려워집니다.

개발사와는 총공수 외에 역할별 작업량·투입 가능 시기·선행 조건을 함께 확인해 보세요. 기능을 추가할 때도 늘어난 작업량과 출시일에 미치는 영향을 나눠 묻습니다. 다른 작업과 나란히 진행할 수 있는지, 기존 검수를 다시 해야 하는지에 따라 달라지기 때문입니다. 공수와 일정의 전제를 같이 남기면 다음 변경도 같은 조건에서 비교할 수 있습니다.

개발 범위를 구현·검수까지 연결하기

똑똑한개발자는 기획·디자인·개발·운영 경험을 바탕으로 서비스 구축을 돕습니다. 개발 범위를 정할 때는 만들 기능과 함께 확인할 조건을 구체화하고, 구현 이후 검수할 작업을 연결해 살펴볼 수 있습니다. 아래 장표는 AI를 활용한 개발 과정의 검증 체계를 설명합니다. 모든 프로젝트의 동일한 납기나 결함 없는 결과를 약속하는 자료는 아닙니다.

필요한 기능과 검수 범위를 구체화해 개발 계획을 세우고 싶다면 아래 똑똑한개발자 링크로 이야기 나눠주세요! 감사합니다.