개발사가 중간에 못 하겠다고 하면

"죄송한데, 이 프로젝트를 더 이상 진행하기 어려울 것 같습니다."

이 말을 듣는 순간 클라이언트의 머릿속은 하얘집니다. 선금은 이미 지급했고, 일정은 절반이 지났고, 런칭일은 다가오고 있습니다. 드문 일이라고 생각할 수 있지만, 실제로 일어납니다.

개발사 쪽 원인

역량 부족

계약할 때는 "할 수 있습니다"라고 했지만, 실제로 만들어보니 기술적으로 감당이 안 되는 경우. 특히 3D, WebGL, 복잡한 결제 시스템 같은 전문 기술이 필요한 프로젝트에서 발생합니다. 경험이 없는 영역을 과소평가하고 수주한 결과입니다.

핵심 인력 이탈

소규모 개발사에서 핵심 개발자가 퇴사하면 프로젝트가 멈춥니다. 그 개발자만 이해하는 코드, 그 개발자만 알고 있는 비즈니스 로직. 한 사람에 대한 의존도가 높을수록 리스크가 큽니다.

자금 문제

개발사도 사업체입니다. 다른 프로젝트의 대금이 밀리거나, 예상보다 인건비가 많이 들면 자금이 부족해집니다. 선금만으로는 프로젝트를 끝까지 진행할 자금이 부족한 경우, 중단을 선언하거나 다른 프로젝트에 인력을 돌려 사실상 방치하는 상황이 생깁니다.

무리한 수주

영업이 급해서 감당이 안 되는 프로젝트를 수주한 경우. 동시에 프로젝트를 너무 많이 잡아서 인력이 분산되고, 각 프로젝트에 충분한 시간을 투입하지 못합니다. 결국 가장 관리가 어려운 프로젝트부터 방치되기 시작합니다.

클라이언트 쪽 원인 — 솔직히 이것도 많습니다

개발사만의 문제가 아닙니다. 솔직히 말하면, 클라이언트 때문에 프로젝트가 중단되거나 개발사가 손을 놓는 경우도 많습니다.

요구사항이 완전히 바뀜

"쇼핑몰 만들어주세요"로 시작했는데, 개발 중간에 "코인 거래 시스템도 넣어야 합니다"가 나오는 경우. 처음에 없던 이야기가 프로젝트 중반에 등장하면, 기존 설계로는 감당이 안 됩니다. 사실상 다른 프로젝트가 된 겁니다. 실제로 이런 경험이 있었습니다. 처음에는 없다고 했던 기능이 알고 보니 핵심 요구사항이었고, 그 규모가 기존 프로젝트와 맞먹는 수준이었습니다.

갑질

폭언, 과도한 압박, 비합리적인 일정 요구. 개발자도 사람입니다. "돈 주는 사람이 왕"이라는 태도로 일하면, 좋은 개발사일수록 먼저 손을 놓습니다. 돈보다 팀의 건강이 중요하니까요.

의사결정이 안 됨

컨펌을 요청하면 2주째 답이 없거나, 내부에서 의견이 안 모여서 방향이 매번 바뀌는 경우. 개발사는 기다리는 동안 인건비가 나갑니다. 결국 다른 프로젝트에 인력을 돌릴 수밖에 없고, 이 프로젝트는 사실상 멈춥니다.

대금 지연

중도금 시점이 왔는데 "다음 달에 줄게요"가 반복되면, 개발사도 생존의 문제입니다. 돈이 안 들어오면 인력을 유지할 수 없습니다.

프로젝트 중단은 한쪽만의 잘못인 경우보다, 양쪽의 문제가 누적되어 터지는 경우가 대부분입니다.

중단 시 클라이언트가 해야 할 것

당황하는 것은 당연하지만, 빠르게 실질적인 조치를 취해야 합니다.

1. 코드 확보

가장 먼저 할 일입니다. 소스코드를 넘겨받으세요. Git 저장소 접근 권한이 있다면 즉시 백업합니다. 코드가 없으면 새로운 개발사에게 넘길 것이 없습니다. 계약서에 소스코드 소유권이 명시되어 있으면 법적으로 요구할 수 있습니다.

2. 서버 접근 확보

서버, 데이터베이스, 도메인, 클라우드 서비스 계정의 접근 권한을 확보하세요. 이것들이 개발사 명의로 되어 있으면 이전이 복잡해집니다. 최악의 경우, 개발사가 협조하지 않으면 서버 데이터에 접근할 수 없습니다.

3. 현재 상태 문서화

지금까지 무엇이 완성되었고, 무엇이 안 되었는지를 기록합니다. 새로운 개발사가 이어받을 때 이 정보가 있으면 분석 시간을 줄일 수 있습니다.

4. 계약서 확인

중도 해지 조항, 기 지급 비용의 처리, 소스코드 소유권, 손해배상 조항을 확인합니다. 계약서에 없으면 협상으로 풀어야 하고, 협상이 안 되면 법적 절차를 검토해야 합니다.

예방이 최선이다

프로젝트 중단은 발생 후 수습하는 것보다 예방하는 것이 훨씬 효율적입니다.

화이트박스 방식으로 진행

프로젝트 시작부터 소스코드, 서버, 문서를 클라이언트가 접근 가능한 상태로 유지합니다. 중간 과정이 투명하면, 문제를 일찍 발견할 수 있고, 최악의 상황에서도 확보할 것이 있습니다.

마일스톤별 결제

선금을 한 번에 많이 주지 않고, 마일스톤을 달성할 때마다 결제합니다. 중간에 프로젝트가 멈추더라도 금전적 손실을 최소화할 수 있습니다.

정기적인 결과물 확인

격주마다 동작하는 결과물을 확인합니다. 3개월 동안 연락 없다가 "못 하겠습니다"를 듣는 것과, 2주마다 진행 상황을 확인하면서 문제 징후를 감지하는 것은 다릅니다.

포트폴리오와 레퍼런스 검증

계약 전에 개발사의 실제 완료 프로젝트를 확인하고, 가능하면 이전 클라이언트의 후기를 확인합니다.

프로덕트 메이커는 모든 프로젝트를 화이트박스 방식으로 진행합니다. 소스코드는 클라이언트가 접근할 수 있는 저장소에 관리하고, 서버는 클라이언트 명의로 구성합니다. 만약의 상황에서도 클라이언트가 아무것도 잃지 않는 구조입니다.


*프로젝트가 중단되어 이어받을 개발사를 찾고 계시거나, 안전한 개발 프로세스가 필요하시다면, 프로젝트 상담을 통해 문의해 주세요.*


프로젝트중단,리스크,외주개발
다른 포스팅

개발사가 중간에 못 하겠다고 하면

"죄송한데, 이 프로젝트를 더 이상 진행하기 어려울 것 같습니다."

이 말을 듣는 순간 클라이언트의 머릿속은 하얘집니다. 선금은 이미 지급했고, 일정은 절반이 지났고, 런칭일은 다가오고 있습니다. 드문 일이라고 생각할 수 있지만, 실제로 일어납니다.

개발사 쪽 원인

역량 부족

계약할 때는 "할 수 있습니다"라고 했지만, 실제로 만들어보니 기술적으로 감당이 안 되는 경우. 특히 3D, WebGL, 복잡한 결제 시스템 같은 전문 기술이 필요한 프로젝트에서 발생합니다. 경험이 없는 영역을 과소평가하고 수주한 결과입니다.

핵심 인력 이탈

소규모 개발사에서 핵심 개발자가 퇴사하면 프로젝트가 멈춥니다. 그 개발자만 이해하는 코드, 그 개발자만 알고 있는 비즈니스 로직. 한 사람에 대한 의존도가 높을수록 리스크가 큽니다.

자금 문제

개발사도 사업체입니다. 다른 프로젝트의 대금이 밀리거나, 예상보다 인건비가 많이 들면 자금이 부족해집니다. 선금만으로는 프로젝트를 끝까지 진행할 자금이 부족한 경우, 중단을 선언하거나 다른 프로젝트에 인력을 돌려 사실상 방치하는 상황이 생깁니다.

무리한 수주

영업이 급해서 감당이 안 되는 프로젝트를 수주한 경우. 동시에 프로젝트를 너무 많이 잡아서 인력이 분산되고, 각 프로젝트에 충분한 시간을 투입하지 못합니다. 결국 가장 관리가 어려운 프로젝트부터 방치되기 시작합니다.

클라이언트 쪽 원인 — 솔직히 이것도 많습니다

개발사만의 문제가 아닙니다. 솔직히 말하면, 클라이언트 때문에 프로젝트가 중단되거나 개발사가 손을 놓는 경우도 많습니다.

요구사항이 완전히 바뀜

"쇼핑몰 만들어주세요"로 시작했는데, 개발 중간에 "코인 거래 시스템도 넣어야 합니다"가 나오는 경우. 처음에 없던 이야기가 프로젝트 중반에 등장하면, 기존 설계로는 감당이 안 됩니다. 사실상 다른 프로젝트가 된 겁니다. 실제로 이런 경험이 있었습니다. 처음에는 없다고 했던 기능이 알고 보니 핵심 요구사항이었고, 그 규모가 기존 프로젝트와 맞먹는 수준이었습니다.

갑질

폭언, 과도한 압박, 비합리적인 일정 요구. 개발자도 사람입니다. "돈 주는 사람이 왕"이라는 태도로 일하면, 좋은 개발사일수록 먼저 손을 놓습니다. 돈보다 팀의 건강이 중요하니까요.

의사결정이 안 됨

컨펌을 요청하면 2주째 답이 없거나, 내부에서 의견이 안 모여서 방향이 매번 바뀌는 경우. 개발사는 기다리는 동안 인건비가 나갑니다. 결국 다른 프로젝트에 인력을 돌릴 수밖에 없고, 이 프로젝트는 사실상 멈춥니다.

대금 지연

중도금 시점이 왔는데 "다음 달에 줄게요"가 반복되면, 개발사도 생존의 문제입니다. 돈이 안 들어오면 인력을 유지할 수 없습니다.

프로젝트 중단은 한쪽만의 잘못인 경우보다, 양쪽의 문제가 누적되어 터지는 경우가 대부분입니다.

중단 시 클라이언트가 해야 할 것

당황하는 것은 당연하지만, 빠르게 실질적인 조치를 취해야 합니다.

1. 코드 확보

가장 먼저 할 일입니다. 소스코드를 넘겨받으세요. Git 저장소 접근 권한이 있다면 즉시 백업합니다. 코드가 없으면 새로운 개발사에게 넘길 것이 없습니다. 계약서에 소스코드 소유권이 명시되어 있으면 법적으로 요구할 수 있습니다.

2. 서버 접근 확보

서버, 데이터베이스, 도메인, 클라우드 서비스 계정의 접근 권한을 확보하세요. 이것들이 개발사 명의로 되어 있으면 이전이 복잡해집니다. 최악의 경우, 개발사가 협조하지 않으면 서버 데이터에 접근할 수 없습니다.

3. 현재 상태 문서화

지금까지 무엇이 완성되었고, 무엇이 안 되었는지를 기록합니다. 새로운 개발사가 이어받을 때 이 정보가 있으면 분석 시간을 줄일 수 있습니다.

4. 계약서 확인

중도 해지 조항, 기 지급 비용의 처리, 소스코드 소유권, 손해배상 조항을 확인합니다. 계약서에 없으면 협상으로 풀어야 하고, 협상이 안 되면 법적 절차를 검토해야 합니다.

예방이 최선이다

프로젝트 중단은 발생 후 수습하는 것보다 예방하는 것이 훨씬 효율적입니다.

화이트박스 방식으로 진행

프로젝트 시작부터 소스코드, 서버, 문서를 클라이언트가 접근 가능한 상태로 유지합니다. 중간 과정이 투명하면, 문제를 일찍 발견할 수 있고, 최악의 상황에서도 확보할 것이 있습니다.

마일스톤별 결제

선금을 한 번에 많이 주지 않고, 마일스톤을 달성할 때마다 결제합니다. 중간에 프로젝트가 멈추더라도 금전적 손실을 최소화할 수 있습니다.

정기적인 결과물 확인

격주마다 동작하는 결과물을 확인합니다. 3개월 동안 연락 없다가 "못 하겠습니다"를 듣는 것과, 2주마다 진행 상황을 확인하면서 문제 징후를 감지하는 것은 다릅니다.

포트폴리오와 레퍼런스 검증

계약 전에 개발사의 실제 완료 프로젝트를 확인하고, 가능하면 이전 클라이언트의 후기를 확인합니다.

프로덕트 메이커는 모든 프로젝트를 화이트박스 방식으로 진행합니다. 소스코드는 클라이언트가 접근할 수 있는 저장소에 관리하고, 서버는 클라이언트 명의로 구성합니다. 만약의 상황에서도 클라이언트가 아무것도 잃지 않는 구조입니다.


*프로젝트가 중단되어 이어받을 개발사를 찾고 계시거나, 안전한 개발 프로세스가 필요하시다면, 프로젝트 상담을 통해 문의해 주세요.*


프로젝트중단,리스크,외주개발
다른 포스팅