개발 일정은 왜 항상 밀리나 — 뻥이 아니라 구조의 문제

"이번 주 안에 끝난다고 하셨잖아요."

18년 동안 이 말을 참 많이 들었습니다. 그리고 솔직히, 저도 그 말을 참 많이 못 지켰습니다.

게을러서가 아닙니다

개발 일정이 밀리면 사람들은 보통 두 가지로 생각합니다. 게으르거나, 처음부터 거짓말을 했거나.

둘 다 아닌 경우가 훨씬 많습니다. 진짜 이유는 구조에 있습니다.

일정을 세울 때 이미 모르는 게 있다

프로젝트 시작 시점에 견적을 냅니다. 이 견적은 그 시점에 아는 정보로만 계산된 겁니다.

문제는, 개발을 시작해야 비로소 보이는 것들이 있다는 겁니다.

• "여기 연동하려는 외부 API가 문서랑 다르게 동작하네요"
• "이 기능, 기존 로그인 구조랑 충돌하네요"
• "이 데이터 형식이 생각했던 거랑 다르네요"

이런 건 코드를 짜기 전엔 알 수가 없습니다. 알았다면 애초에 견적에 넣었을 겁니다.

요구사항은 고정되지 않는다

또 다른 이유는 요구사항이 프로젝트 중간에 바뀐다는 겁니다.

"이거 하나만 추가해주세요"가 쌓이면 일정이 밀립니다. 문제는 이게 누구 잘못도 아니라는 겁니다. 실제로 화면을 보고 나서야 "아, 이건 이렇게 하면 안 되겠다"는 걸 깨닫는 게 정상입니다. 프로토타입 없이는 판단하기 어려운 것들이 있으니까요.

다만 이 변경들이 하나씩 쌓이면, 처음 세운 일정은 더 이상 유효하지 않습니다.

마지막 10%가 90%의 시간을 먹는다

기능이 "작동하는 것처럼 보이는" 단계와 "실제로 쓸 수 있는" 단계 사이에는 큰 간격이 있습니다.

화면이 뜨고 클릭이 되는 건 빠릅니다. 그런데 에러 처리, 예외 상황, 실제 데이터로 테스트, 성능 확인 — 이 마지막 구간이 생각보다 훨씬 오래 걸립니다. 겉보기엔 "거의 다 된 것" 같지만 실제로는 절반도 안 끝난 경우가 많습니다.

그래서 어떻게 해야 하나

일정 지연 자체를 없앨 수는 없습니다. 다만 관리할 수는 있습니다.

여유를 처음부터 반영한다. 최선의 시나리오로 일정을 잡으면 무조건 늦습니다. 예상 못한 것들이 나올 여유를 처음부터 포함해야 합니다.

중간중간 실제로 보여준다. 완성될 때까지 기다렸다가 한 번에 보여주면, 문제도 한 번에 몰려서 나옵니다. 중간 산출물을 자주 확인하면 방향이 틀렸을 때 빨리 바로잡을 수 있습니다.

요구사항 변경은 일정에 반영한다. "이거 하나만 추가"가 생기면, 그만큼 일정도 같이 조정한다는 걸 미리 합의해두는 게 낫습니다. 안 그러면 나중에 "왜 늦어졌냐"는 이야기만 반복됩니다.

---

일정이 밀리는 게 정상이라는 뜻은 아닙니다. 다만 그 이유가 게으름이나 거짓말이 아니라 구조라는 걸 알면, 대응 방식이 달라집니다. 여유를 두고, 자주 확인하고, 변경을 미리 합의하는 것 — 이게 일정을 관리 가능하게 만드는 방법입니다.