"3개월이면 된다고 했는데, 6개월째입니다."

외주 개발을 경험해본 분이라면 한 번쯤 겪어봤을 상황입니다. 일정이 밀리는 것은 개발 프로젝트에서 예외가 아니라 일상입니다. 문제는 왜 밀리는지를 이해하고, 어떻게 대응하느냐입니다.

일정 지연의 구조적 원인

1. 범위 변경 (Scope Creep)

가장 흔한 원인입니다. 개발 중간에 "이것도 추가해주세요", "이 부분은 좀 다르게 해주세요"가 반복됩니다.

한 번의 변경은 작아 보입니다. 하지만 작은 변경이 10번 쌓이면, 기존 일정에 존재하지 않았던 한 달 분량의 작업이 됩니다. 그리고 기능 하나가 추가되면, 그 기능과 연결된 다른 기능도 수정해야 합니다. 파급 효과가 겉으로 보이는 것보다 큽니다.

2. 의사결정 지연

개발사가 작업을 진행하려면, 클라이언트의 확인과 결정이 필요한 지점들이 있습니다.

• 디자인 시안 컨펌
• 기능 우선순위 결정
• 기획 변경 사항 확정

이 결정이 3일 늦어지면, 개발 일정도 최소 3일 밀립니다. 개발자가 그 사이에 다른 작업을 하고 있었다면, 컨텍스트 전환 비용까지 더해져서 5일이 밀릴 수 있습니다.

3. 기술적 난이도 과소평가

"이건 간단하잖아요"라는 말이 가장 위험합니다.

• "소셜 로그인 붙이기": 카카오, 네이버, 구글, 애플 각각 연동 방식이 다르고, 예외 처리가 다름
• "지도에 마커 찍기": 마커 클러스터링, 실시간 위치 업데이트, 성능 최적화까지 가면 2~3주
• "엑셀 다운로드": 데이터 가공, 포맷팅, 대용량 처리까지 고려하면 생각보다 공수가 큼

겉보기에 간단한 기능이 실제로는 복잡한 경우가 많습니다. 경험 있는 개발사는 이걸 알고 버퍼를 잡지만, 견적 경쟁에서 버퍼를 줄이면 일정이 밀립니다.

개발사 귀책 vs 클라이언트 귀책

일정 지연이 발생하면 서로를 탓하기 쉽습니다. 냉정하게 구분하면 이렇습니다.

개발사 귀책:

• 기술적 난이도를 잘못 판단해서 견적/일정을 낮게 잡은 경우
• 내부 리소스 문제 (다른 프로젝트와 겹쳐서 인력이 부족)
• 코드 품질 문제로 재작업이 반복되는 경우

클라이언트 귀책:

• 기획 변경이 잦은 경우
• 확인/컨펌이 늦는 경우
• 처음에 없던 기능을 추가하면서 일정은 그대로 유지하길 원하는 경우

현실에서는 양쪽 모두의 원인이 섞여있는 경우가 대부분입니다.

솔직히 말하면, 개발사 문제인 경우가 더 많다

위에서 개발사 귀책과 클라이언트 귀책을 공정하게 나눴지만, 솔직히 말씀드리면 일정 지연의 원인은 개발사 쪽에 있는 경우가 더 많습니다. 다만 클라이언트가 그걸 판별하기 어려울 뿐입니다.

무리하게 프로젝트를 잡은 경우

영업이 급하면 동시에 프로젝트를 너무 많이 잡습니다. 개발자 3명이 프로젝트 5개를 동시에 돌리면, 각 프로젝트에 투입할 수 있는 시간이 쪼개집니다. 클라이언트에게는 "풀타임 투입"이라고 했지만, 실제로는 일주일에 이틀만 붙는 상황. 당연히 일정이 밀립니다. 그리고 그 이유를 클라이언트에게 솔직하게 말하지 않습니다.

역량이 부족한 경우

견적은 시니어급으로 받았는데, 실제 투입된 인력이 해당 기술을 처음 다뤄보는 경우. 학습하면서 개발하니까 시간이 두세 배로 걸립니다. 클라이언트 입장에서는 "왜 이렇게 오래 걸리지?"인데, 실제로는 개발자가 공부하고 있는 겁니다.

의도적으로 질질 끄는 경우

드물지만 있습니다. 월 단위 계약인 경우, 일정을 늘려야 매출이 늘어나는 구조. 또는 잔금을 못 받을 것 같으니까 일부러 천천히 하면서 추가 비용을 요구하는 경우. 이런 건 사기에 가깝지만, 현실에 존재합니다.

아예 만들 능력이 없는 경우

계약은 했는데 실제로 해당 기술을 구현할 능력이 없는 개발사도 있습니다. 선금을 받고 나서야 "이건 생각보다 어렵네요"가 시작됩니다. 처음부터 안 된다고 했어야 하는데, 일단 계약하고 보자는 식. 결국 프로젝트가 중간에 멈추거나, 품질이 심각하게 나쁜 결과물이 나옵니다.

어떻게 구별하나

안타깝지만 사전에 100% 구별하기는 어렵습니다. 다만 이런 신호가 보이면 주의하세요:

• 진행 상황을 물어봐야만 알려주는 경우 (선제적 공유가 없음)
• "거의 다 됐습니다"가 한 달째 반복되는 경우
• 동작하는 결과물을 보여주지 않고 말로만 설명하는 경우
• 일정 지연 원인을 항상 클라이언트 탓으로 돌리는 경우
• 중간 산출물 공유를 꺼리는 경우

프로덕트 메이커의 화이트박스 방식은 이런 문제를 구조적으로 방지합니다. 격주마다 동작하는 결과물을 보여드리기 때문에, 2주 이상 감출 수 있는 것이 없습니다.

일정을 지키기 위한 현실적인 방법

범위를 고정한다

개발 시작 전에 범위를 확정하고, 추가 요청은 다음 단계로 미룹니다. "이건 2차에서 합시다"라는 말이 프로젝트를 살립니다.

마일스톤을 설정한다

3개월짜리 프로젝트를 한 덩어리로 관리하면 안 됩니다. 2주 단위로 쪼개서, 각 구간별로 완료 기준을 명확히 합니다.

• 1~2주차: 회원가입, 로그인 완료
• 3~4주차: 메인 화면, 검색 기능 완료
• 5~6주차: 결제 연동 완료

이렇게 하면 2주차에 밀리고 있는지 아닌지가 바로 보입니다.

버퍼를 확보한다

모든 일정에 20~30%의 여유를 잡습니다. "3개월이면 됩니다"가 아니라 "3개월 + 버퍼 1개월, 총 4개월"로 계획합니다. 버퍼 없는 일정은 이미 지연이 확정된 일정입니다.

의사결정 속도를 높인다

클라이언트 측의 컨펌 담당자를 한 명으로 지정하고, 결정 기한을 정합니다. "이 시안에 대해 3일 내로 답변 주세요. 답변이 없으면 현재안으로 진행합니다."

일정이 밀렸을 때의 대응

일정이 밀리지 않는 프로젝트는 거의 없습니다. 중요한 건 밀렸을 때 어떻게 하느냐입니다.

• 투명하게 공유한다: "현재 1주일 지연되고 있고, 원인은 이것이고, 이렇게 만회하겠습니다"
• 범위를 조정한다: 일정이 밀렸으면, 남은 범위에서 우선순위가 낮은 기능을 빼는 결단
• 추가 투입은 신중하게: 사람을 더 넣는다고 빨라지지 않습니다. 오히려 소통 비용이 늘어남

프로젝트 관리의 본질은 "일정을 안 밀리게 하는 것"이 아니라, "밀렸을 때 빠르게 감지하고 대응하는 것"입니다.

*프로젝트 일정 관리가 걱정되신다면, 프로젝트 상담을 통해 문의해 주세요. 현실적인 일정과 마일스톤을 함께 설계합니다.*