소프트웨어 개발에서 일정이 지연되는 것은 전 세계 공통 현상입니다. 업계에서 자주 인용되는 Standish Group의 CHAOS Report에서도 IT 프로젝트의 절반 이상이 원래 일정을 초과한다고 보고되어 왔습니다. "2개월이면 됩니다"로 시작한 프로젝트가 4개월이 되는 일이 비일비재합니다.

이건 개발팀의 무능이 아니라, 소프트웨어 개발이라는 작업의 본질적 특성에서 비롯됩니다. 구조적 원인을 이해하면 대응 방식도 달라집니다.

발주사와 개발사 간의 인식 갭

경험 있는 개발사는 로그인 기능 하나에도 비밀번호 암호화, 입력값 검증, 에러 메시지 처리, 세션 관리, JWT 토큰 갱신, 로그인 실패 횟수 제한, 비밀번호 찾기 연동, 소셜 로그인 연동 같은 작업이 따라온다는 걸 알고, 당연히 그 공수를 포함해 일정을 잡습니다.

문제는 발주사 입장에서 화면에 보이는 게 이메일 입력창, 비밀번호 입력창, 버튼 하나뿐이라는 점입니다. "이게 왜 2주나 걸리나"라는 질문이 자연스럽게 나오고, 일정을 압축해 달라는 요청이 따라옵니다. 개발사가 정확히 산정한 일정이 발주사에게는 과하게 느껴지는 갭이 구조적으로 존재합니다. 이 갭 자체가 지연의 직접 원인은 아니지만, 다음에 나올 범위 변경과 결합하면 실제 지연으로 이어집니다.

범위 변경(Scope Creep)의 빙산 효과

"이것 하나만 추가해 주세요"라는 요청이 오면 요청하는 쪽에서는 별거 아닌 것처럼 보입니다. 그런데 막상 열어보면 그 기능이 위에서 말한 빙산인 경우가 많습니다. 간단해 보이는 기능 하나가 기존 기능과의 연동, 회귀 테스트, UI 조정, DB 스키마 변경 같은 연쇄 작업을 유발합니다.

이런 작은 변경 요청이 쌓이면 사실상 새 프로젝트 하나를 추가한 것과 같은 공수가 되기도 합니다. 범위 변경이 일정 지연의 가장 큰 단일 원인이라는 건 여러 프로젝트 관리 연구가 반복해서 지적해 온 지점입니다. 요청 자체가 문제가 아니라, 그 요청의 실제 크기를 양측이 다르게 인식한다는 게 핵심입니다.

일정과 비용의 구조적 충돌

고객사 입장에서 일정은 곧 비용입니다. 일정이 줄면 비용이 줄어든다고 생각하기 때문에 업무 범위를 최대한 압축하려 합니다. 개발사는 세일즈 클로징을 위해 무리한 일정에도 어느 정도 오케이하는 경우가 많은데, 그 일정으로는 애초에 어려운 경우가 대부분입니다.

현실적으로는 "범위를 줄여서 비용을 낮추자"까지는 합의되어도, "일정은 기술적으로 필요한 만큼 확보한다"에는 합의가 어려운 케이스가 많습니다. 애초에 촉박한 일정으로 시작된 프로젝트가 대부분이기 때문입니다. 이렇게 출발선부터 무리한 일정이 깔리면, 이후 어떤 관리 방식을 써도 지연의 뿌리는 초기 계약 단계에 남아 있게 됩니다.

외부 의존성

PG사 연동이 예상보다 오래 걸리거나, 디자인 확정이 늦어지거나, 고객 피드백 대기가 길어지는 등 개발팀이 통제할 수 없는 요소가 많습니다. 외부 API 문서가 부실하거나 테스트 환경 제공이 지연되는 일도 빈번합니다. 문제는 이런 대기 시간이 초기 일정 산정 시 거의 반영되지 않는다는 점입니다.

호프스태터의 법칙

컴퓨터 과학자 더글러스 호프스태터는 이런 말을 남겼습니다. "호프스태터의 법칙: 일은 항상 예상보다 오래 걸린다. 호프스태터의 법칙을 고려했더라도 그렇다." 이 재귀적 법칙은 소프트웨어 개발에서 특히 잘 맞습니다.

20% 버퍼를 잡아도 그 버퍼마저 소진되는 게 현실입니다. 인간은 본능적으로 낙관적 편향을 가지고 있어서, 의식적으로 보정하지 않으면 항상 일정을 과소평가합니다. 개별 기능의 공수는 경험으로 꽤 정확히 산정할 수 있지만, 프로젝트 전체 일정은 위에서 언급한 범위 변경, 일정 압축, 외부 의존성이 복합적으로 작용하기 때문에 예측이 훨씬 어렵습니다.

일정을 지키는 현실적 방법

완벽한 일정 예측은 불가능하지만, 지연을 최소화하는 방법은 있습니다. 스프린트 시작 전에 범위를 확정하고, 도중에 추가되는 요청은 다음 스프린트로 미룹니다. 2주 단위 스프린트로 일하면 일정이 밀려도 최대 2주 이내에 인지하고 보정할 수 있습니다.

6개월짜리 프로젝트를 한 번에 진행하면 3개월 차에야 지연을 알게 되지만, 2주 스프린트에서는 누적되기 전에 대응할 수 있습니다. 그리고 전체 일정에는 20~30% 버퍼를 넣는 게 안전합니다. 버퍼 없는 일정은 계획이 아니라 희망사항에 가깝습니다.

프로덕트 메이커의 스프린트 방식

프로덕트 메이커는 모든 프로젝트를 2주 스프린트로 운영합니다. 각 스프린트 시작 시 범위를 명확히 정하고, 종료 시 고객에게 실제 동작하는 결과물을 시연합니다. 스프린트마다 진행 상황이 공유되기 때문에, 일정 위험이 감지되면 그 자리에서 범위를 조정하거나 우선순위를 재배치합니다.

일정이 틀리는 것을 완전히 막을 수는 없습니다. 하지만 빠르게 발견하고 빠르게 대응하는 것은 가능합니다. 최대 2주의 편차 안에서 프로젝트를 관리하는 것이 저희가 잡아 둔 현실적인 기준입니다. 고객에게도 스프린트 회고를 통해 진행 상황이 그때그때 공유되기 때문에, "갑자기 일정이 밀렸다"는 뒤늦은 놀라움 없이 함께 대응 방안을 논의할 수 있습니다.