화면은 빨리 만들었는데, 오픈 일정은 왜 줄지 않았을까

개발 일정을 산정하면서 AI로 빠르게 만든 프로젝트의 실적을 참고했다. 화면과 API를 짧은 기간에 많이 만들었다면, 비슷한 규모의 다음 프로젝트에도 그 속도를 적용할 수 있을 것 같았다. 하지만 이번에 필요한 것은 화면을 만드는 기간이 아니라 실제 운영으로 전환하기까지의 일정이었다.

나는 빠른 제작 실적과 운영 전환을 거친 프로젝트의 이력을 함께 확인했다. 같은 화면 수라도 어디까지 끝난 작업인지에 따라 일정에 쓸 수 있는 범위가 달랐다.

빠른 제작 실적을 어디까지 적용할 수 있을까

먼저 Git 이력에서 활동 날짜와 화면, API, 테이블 수를 정리했다. 기능을 만드는 속도를 확인할 수는 있었지만, 활동 날짜를 그대로 투입 일수로 볼 수는 없었다. 커밋이 남은 날에도 다른 업무를 병행했고, 하루 전체를 이 프로젝트에 썼는지는 알 수 없었다.

화면과 API, 테이블의 생산량 역시 같은 활동 날짜를 기준으로 계산한 값이었다. 각각을 독립적인 작업 속도로 보고 합치면 같은 시간을 여러 번 계산하게 된다. 이 실적을 쓰려면 숫자가 무엇을 세고 있는지부터 구분해야 했다.

더 큰 제약은 완료 범위였다. 외부 연동에 착수한 기록은 있었지만 실제 완료가 확인된 항목은 없었다. 화면과 서버 코드가 빠르게 늘어났다는 사실만으로 인증이나 결제까지 동작한다고 볼 근거는 부족했다.

운영 전환을 거친 프로젝트와 비교했다

비교를 위해 다른 프로젝트의 개발 이력도 확인했다. 이 프로젝트는 운영 전환을 마쳤고, 고객 화면을 연 뒤 수정한 작업까지 기록에 포함돼 있었다. 새 기능을 쌓는 속도와 운영 중인 서비스를 바꾸는 속도를 같은 기준으로 비교하고 있었던 셈이다.

두 프로젝트의 차이를 AI 도구나 개발자의 생산성 차이로 해석하지 않았다. 빠르게 만든 관리 화면의 실적은 관리 화면을 산정하는 데 쓰고, 고객 흐름을 바꾸는 작업은 운영 전환을 거친 이력을 따로 참고하기로 했다.

외부 연동은 별도로 봤다. 화면 제작이 빨랐던 프로젝트에서도 연동 완료는 확인되지 않았으므로, 화면 수를 기준으로 연동 기간까지 줄여 잡을 수는 없었다. 해당 연동의 기존 구축 실적과 외부 절차를 근거로 산정해야 했다.

전체 일정의 산정 근거를 바꿨다

처음에는 화면 수 중심의 산정에 빠른 제작 실적을 대입했다. 이후 관리 화면과 고객 화면의 기준을 나누고, 연동과 기반 작업, 시험과 이관에 필요한 작업량을 더해 다시 계산했다. 운영 전환을 거친 실적까지 반영하자 빠른 제작 속도만 적용했을 때보다 필요한 작업량이 커졌다.

이번에 정리한 것은 전체 일정을 설명할 근거다. 화면을 얼마나 빨리 만들 수 있는지와 실제 전환까지 무엇이 남아 있는지를 나눠 계산할 수 있게 됐다. 최종 일정 합의와 외부 연동 조건 확인은 남아 있다.