외주 프로젝트가 산으로 가는 신호 6가지와 단계별 대처법
외주 프로젝트 가운데 기한·예산·범위를 모두 지키는 건 31% 수준이에요. 매주 확인할 수 있는 이탈 신호 6가지와 확인 회의→범위 재계획→계약 조치→중단·인수로 이어지는 4단계 대처법, 지체상금 1일 0.125% 계산 예시를 정리했어요.
핵심 요약 외주 프로젝트가 산으로 가는 건 어느 날 갑자기가 아니라 몇 주에 걸쳐 신호가 쌓인 결과예요. 동작하는 화면이 안 보이고, “90% 됐어요”가 몇 주째 그대로이고, 답이 늦어져요. 이 신호를 본 뒤 확인 회의 → 범위 재계획 → 계약상 조치 → 중단·인수 순서로 한 단계씩 올리면 대부분은 중간에서 수습돼요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.
“분명 지난달에도 거의 다 됐다고 했거든요. 근데 아직도 볼 수 있는 화면이 없어요.”
상담하다 보면 이 말로 시작하는 통화가 꽤 있어요. 대개 이 시점엔 이미 몇 주치 신호를 지나쳐 온 상태예요. 어떤 신호를 언제 봐야 하는지, 봤다면 무엇부터 해야 하는지 순서대로 짚어볼게요.
1. 프로젝트가 산으로 간다는 건 어떤 상태일까요
생각보다 흔한 일이에요. 스탠디시 그룹의 CHAOS 보고서 최근 집계를 보면 기한·예산·범위를 모두 지킨 IT 프로젝트는 31% 에 그쳤어요. 셋 중 하나 이상을 놓친 프로젝트가 50%, 아예 중단된 프로젝트가 19%였고요. 이 비율은 몇 년째 크게 바뀌지 않았어요.
그러니 “우리 프로젝트만 이상한가”라고 자책할 필요는 없어요. 문제는 흔들림 자체가 아니라 흔들리는 걸 늦게 알아채는 것이에요. 소프트웨어 외주 개발 업체와 일할 때 발주자가 볼 수 있는 창은 좁거든요. 주간 보고서와 회의가 거의 전부라서, 그 창에 무엇을 요구해 두느냐가 조기 발견을 가르는 경우가 많아요.
2. 매주 확인할 수 있는 신호 6가지
아래 표는 저희가 프로젝트를 진행하며 스스로 점검하는 기준이에요. 발주자 쪽에서도 그대로 확인할 수 있는 것만 골랐어요.
| 신호 | 정상 범위 | 경고로 보는 시점 |
|---|---|---|
| 동작하는 화면 시연 | 1～2주마다 새 기능을 직접 눌러봄 | 3주 넘게 캡처·문서로만 보고 |
| ”거의 다 됐어요” | 완료 기능 목록이 매주 늘어남 | 같은 기능이 2주 넘게 “90%“ |
| 버그 재발 | 고친 버그는 닫힘 | 고쳤다던 버그가 다시 열리는 일이 반복 |
| 질문 응답 | 영업일 기준 하루 안팎 | 사흘 넘게 답이 없거나 “확인해볼게요”만 반복 |
| 담당자 | 바뀌면 사전 공지와 인수인계 | 공지 없이 PM이나 핵심 개발자가 교체 |
| 테스트 서버 접근 | 발주자가 언제든 들어가 볼 수 있음 | 주소를 못 받았거나 “정리 후 드릴게요” |
자사 실무 기준 예시 — 위 기간은 저희가 쓰는 점검 기준이에요. 법이나 업계 공통 규칙이 아니라서 프로젝트 규모에 맞게 조정하시면 돼요.
하나만 걸리면 일시적일 수 있어요. 두 개 이상이 2주 넘게 겹치면 그때는 기다리지 말고 다음 단계로 넘어가세요. 특히 첫 줄과 마지막 줄이 함께 걸리면 진척을 확인할 방법이 사라진 상태예요.
3. 신호가 보이면 첫 주에 무엇을 확인할까요
첫 단계는 따지는 자리가 아니라 사실을 맞추는 자리예요. 확인 회의를 따로 잡고 세 가지를 문서로 받으세요.
- 남은 일 목록 — 기능 단위로, 완료·진행·미착수를 나눠서요. “80% 진행”같은 비율보다 목록이 정직해요.
- 막힌 이유 — 요구사항이 모호해서인지, 외부 연동이 늦어서인지, 인력이 빠져서인지요. 발주사 쪽 원인이 섞여 있는 경우도 꽤 있어요.
- 새 일정과 근거 — 날짜만이 아니라 그 날짜가 나온 계산이요.
이 세 장이 한 주 안에 나오면 대부분 조정 가능한 지연이에요. 반대로 목록을 요청했는데 또 말로만 설명이 돌아온다면, 그 자체가 다음 단계로 넘어갈 근거가 돼요. 일정이 왜 밀리는지 원리가 궁금하시면 개발 기간은 왜 자꾸 밀릴까요에 산정 방식부터 정리해뒀어요.
4. 범위를 줄여서 살릴 수 있을까요
살릴 수 있는 경우가 많아요. 두 번째 단계는 오픈 날짜를 지키고 범위를 줄이는 재계획이에요.
남은 기능을 세 칸으로 나눠 보세요. 오픈에 꼭 있어야 하는 것, 오픈 후 한 달 안에 붙여도 되는 것, 이번엔 빼도 되는 것이요. 실제로 해보면 세 번째 칸이 생각보다 커요. 처음 기획서에 들어갔지만 막상 사용자가 매일 쓰지 않을 기능들이 거기 모이거든요.
범위를 바꾸면 반드시 문서로 남겨요. 공공 소프트웨어 사업은 과업을 바꿀 때 사업자가 과업변경요청서를 내고 과업심의위원회가 계약금액·기간 조정까지 심의하도록 절차가 정해져 있어요. 민간은 이런 절차가 없으니 양쪽이 서명한 변경 합의서가 그 역할을 해요. 데이터 베이스 외주처럼 일부 작업을 다른 곳에 따로 맡긴 경우라면, 경계에 걸친 작업을 누가 맡는지도 이때 다시 적어두세요. 변경 요청을 다루는 절차는 요구사항이 자꾸 바뀔 때 대응법에 있어요.
5. 계약서로 할 수 있는 조치는 어디까지일까요
재계획으로도 안 되면 세 번째 단계, 계약상 조치예요. 여기서부터는 계약서에 적힌 만큼만 쓸 수 있어요.
| 조치 | 공식 외부 기준 | 민간 계약에서 확인할 점 |
|---|---|---|
| 지체상금 | 국가계약법 시행규칙 제75조: 용역 1일 1천분의 1.25(0.125%) | 요율과 기산일이 적혀 있는지 |
| 지체상금 한도 | 국가계약법 시행령 제74조: 계약금액의 100분의 30 | 한도와 기성 공제 방식 |
| 검수 보류 | 검사 후 인수한 부분은 지체상금 계산에서 공제 | 단계별 검수 기준이 합의돼 있는지 |
| 대금 지급 보류 | 단계별 지급이 기본 구조 | 중도금 조건이 산출물과 묶여 있는지 |
공식 외부 기준 — 위 요율·한도는 공공 계약에 적용되는 국가계약법 조문이에요. 민간 계약은 당사자가 자유롭게 정하지만, 이 기준을 참고해 정하는 경우가 많아요. 조문 원문은 국가법령정보센터에서 확인하실 수 있어요.
숫자로 한번 볼게요. 웹사이트 외주 비용이 1,000만 원인 프로젝트에 공공 요율을 그대로 적용하면 하루 1만 2,500원이에요. 한도인 30%(300만 원)에 닿으려면 240일이 걸려요. 그러니까 지체상금은 손해를 메우는 장치라기보다 “일정을 문서로 관리하자”는 신호에 가까워요. 실제 효과는 중도금 조건을 산출물과 묶어 두는 쪽이 더 커요. 대금 구조는 외주 계약서 조항 체크리스트에 따로 정리해뒀어요.
6. 멈추고 넘겨받아야 하는 때는 언제일까요
마지막 단계는 중단과 인수예요. 저희는 아래 셋 중 하나에 해당하면 멈추는 쪽을 검토하시라고 말씀드려요.
- 확인 회의 뒤에도 남은 일 목록이 끝내 문서로 안 나올 때
- 재계획한 일정도 다시 2주 넘게 밀리고 이유가 설명되지 않을 때
- 연락이 일주일 넘게 끊기거나 핵심 인력이 모두 빠졌을 때
멈추기로 했다면 말을 꺼내기 전에 받을 것부터 확보하세요. 소스코드 저장소 권한, 서버·도메인·앱스토어 계정, 요구사항과 설계 문서예요. 닷넷 외주 개발로 만든 사내 시스템처럼 이어받을 사람을 찾기 어려운 기술이라면 이 순서가 더 중요해요. 코드를 받아도 빌드가 안 되면 새 업체는 처음부터 다시 만드는 견적을 낼 수밖에 없거든요.
멈추기 전에 흔히 하는 실수도 있어요.
- 인력을 더 넣어 달라고 하기 — 늦은 프로젝트에 사람을 더하면 설명하는 시간 때문에 오히려 더 늦어지는 경우가 많아요.
- 잔금을 먼저 주고 마무리를 약속받기 — 남은 협상 수단이 사라져요.
- 말로만 합의하기 — 나중에 누가 무엇을 약속했는지 아무도 증명하지 못해요.
넘겨받는 절차는 외주 개발사를 도중에 바꿔야 한다면에 체크리스트로 정리해뒀어요.
용어 박스 지체상금: 약속한 날짜보다 늦어진 날수만큼 계약금액에 요율을 곱해 물리는 돈이에요. 실무에선 “지체상금 걸려 있어요”라고 말해요. 기성: 전체 중 이미 완료해 검사를 거친 부분이에요. 기성분은 지체상금 계산에서 빼요. 과업변경요청서: 공공 SW 사업에서 과업 범위를 바꿀 때 내는 문서예요. 민간에선 “변경 합의서”로 부르는 경우가 많아요.
7. 운영까지 보면 무엇이 달라질까요
산으로 간 프로젝트가 가장 비싸게 치르는 값은 사실 오픈 이후에 와요. 일정을 맞추려고 막판에 테스트를 줄이고, 예외 처리를 뒤로 미루고, 문서를 건너뛰거든요. 그 빈칸은 운영 첫 석 달 동안 장애와 수정 요청으로 돌아와요.
저희는 자체 SaaS 4종을 직접 운영하면서 이걸 여러 번 겪었어요. 납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다는 걸요. 그래서 일정이 흔들릴 때도 테스트와 문서는 마지막까지 범위에서 빼지 않아요. 기능 하나를 다음 달로 미루는 편이 오픈 뒤 장애를 막는 것보다 싸게 먹혀요.
지금 진행 중인 프로젝트에서 신호 몇 개가 겹쳐 보인다면, 어느 단계에 와 있는지부터 같이 짚어볼 수 있어요. 결론이 안 서 있어도 괜찮아요. 지금 상황을 편하게 들려주세요 →
저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 일정이 흔들릴 때 개발사 안에서 무슨 일이 벌어지는지 알아서, 발주자 쪽에서 무엇을 요구하면 되는지도 구체적으로 말씀드릴 수 있어요.
8. 자주 묻는 질문
개발 일정이 2주 밀렸는데, 벌써 문제 삼아도 되나요?
일정 자체보다 밀린 이유가 설명되는지를 먼저 보세요. 남은 일 목록과 막힌 원인, 새 일정이 문서로 나오면 조정 가능한 지연이에요. 이유 없이 ‘거의 다 됐다’는 답만 반복되면 2주라도 확인 회의를 요청할 때예요.
지체상금은 계약서에 없어도 청구할 수 있나요?
민간 계약은 계약서에 약정이 있어야 청구가 수월해요. 약정이 없으면 실제 손해를 따로 입증해야 해서 다툼이 길어져요. 공공 계약은 국가계약법 시행규칙이 용역 1일 1천분의 1.25, 시행령이 계약금액의 30% 한도를 정하고 있어요.
업체를 바꾸고 싶어요. 개발 외주 업체 추천해주세요.
새 업체를 고르기 전에 지금 업체에서 받을 것부터 확보하세요. 소스코드 저장소 권한, 서버·도메인·앱스토어 계정, 요구사항과 설계 문서예요. 이게 있어야 새 업체가 정확한 견적을 낼 수 있고, 없으면 처음부터 다시 만드는 견적이 나와요. 업체를 고르는 기준은 개발사 검증 체크리스트에 있어요.
인력을 더 넣으면 늦어진 일정을 따라잡을 수 있나요?
대부분 오히려 더 늦어져요. 새로 들어온 사람이 코드와 맥락을 익히는 동안 기존 인력이 설명에 시간을 쓰기 때문이에요. 인력 추가보다 범위를 줄여 핵심 기능부터 오픈하는 쪽이 일정을 지키기 쉬워요.
9. 마무리
프로젝트는 한 번에 무너지지 않아요. 시연이 한 번 빠지고, 답이 하루 늦어지고, 담당자가 슬쩍 바뀌면서 조금씩 기울어요. 그래서 대처도 한 번에 크게 하기보다 확인 → 재계획 → 계약 조치 → 중단 순서로 한 칸씩 올리는 게 서로에게 덜 아파요.
이번 주에 딱 두 가지만 해보세요. 테스트 서버 주소를 받아 직접 눌러보기, 그리고 남은 일 목록을 기능 단위로 요청하기. 이 두 가지로 지금 우리 프로젝트가 표의 어느 줄에 있는지 대부분 보여요.
함께 보면 좋은 글