일정은 또 밀렸습니다. 그런데 개발사에서는 "조금만 더 기다려주시면 됩니다"라는 말만 합니다. 어제도 그 말을 들었고, 지난주에도 그 말이었습니다.
계약서에 사인했을 때는 몰랐습니다. 진행하다 보니 처음 약속한 것과 다른 게 하나씩 보이기 시작했습니다. 중간 결과물은 안 보이고, 소통은 점점 뜸해지고, 지금까지 낸 돈은 이미 상당합니다. 이 상황에서 많은 분들이 같은 질문에 도달합니다.
"지금이라도 다른 데로 가야 하나, 아니면 끝까지 믿고 가야 하나."
이 글은 그 판단을 내리는 기준을 다룹니다. 상황별 대응 전술보다 앞서는 질문, 즉 "이 프로젝트를 살릴 가치가 있는가"에 대한 프레임입니다.
멈춰서 판단해야 하는 시점
계속 끌려가다 보면 결정을 내려야 할 시점을 놓칩니다. 아래 항목 중 두 가지 이상이 해당된다면, 지금 멈추고 판단을 내려야 하는 시점입니다.
일정 관련
- "이번 주 안에요"라는 답변이 3주 이상 반복되고 있다
- 마일스톤 날짜가 이미 두 번 이상 조정됐다
- 실제 작업 결과물을 보여달라는 요청에 계속 "정리 중"이라는 답만 온다
소통 관련
- 이유 없이 연락 주기가 길어지고 있다 (이틀 → 사흘 → 일주일)
- 구체적인 질문을 해도 "확인해보겠습니다"로만 돌아온다
- 진척 보고가 "순조롭습니다" 한 줄로 끝나는 날이 많다
결과물 관련
- 개발 환경에 접근해보니 실제 진행률이 보고 내용과 크게 다르다
- 중간 데모를 요청할 때마다 이런저런 이유로 미뤄지고 있다
- 문제가 생기면 이유가 항상 "초반 요구사항 변경" 쪽으로 돌아온다
이런 신호들을 오래 방치할수록 선택지가 줄어듭니다. 지금 상황이 정리가 안 된다면 외주 진행 중 문제가 생겼을 때의 상황별 대응 매뉴얼을 먼저 확인하면 구체적인 점검 항목에 도움이 됩니다.
살릴까 엎을까: 판단 기준
"끊어야 하나"라는 생각이 처음 든 순간부터 많은 분들이 계속 망설입니다. 그 이유는 대부분 매몰 비용 때문입니다. 이미 낸 돈, 이미 지난 시간이 아깝다는 감각이 판단을 흐립니다.
하지만 의사결정의 기준은 "지금까지 얼마나 썼나"가 아니라 "지금부터 얼마가 더 필요한가, 그 결과가 나올 가능성이 있는가"여야 합니다.
아래 네 가지 축으로 현재 상황을 점검하면 판단이 조금 더 명확해집니다.
1. 코드 자산의 상태
지금까지 만들어진 코드가 실제로 쓸 수 있는 상태인지가 중요합니다. 소스코드에 직접 접근해서 확인해보는 것이 좋습니다. 접근 자체가 안 된다면 이미 구조적인 문제가 있습니다.
코드가 있더라도 품질을 판단하기 어렵다면 외부 개발자에게 짧은 기술 검토를 의뢰하는 것이 현실적입니다. 전혀 쓸 수 없는 상태라면 엎는 쪽이 훨씬 경제적입니다. 60~70%라도 재사용 가능한 구조라면 살리는 쪽이 낫습니다.
2. 데이터와 인프라
서비스가 이미 실사용자와 연결되어 있다면, 데이터 마이그레이션 비용과 서비스 중단 리스크가 판단에 들어와야 합니다. 아직 내부 테스트 단계라면 이 축은 상대적으로 가볍게 볼 수 있습니다.
3. 외주사와의 신뢰 관계
지금까지의 소통 이력을 돌아봤을 때, 이 개발사가 기술적인 어려움을 겪고 있는 것인지, 아니면 의지나 역량 자체의 문제인지를 구분하는 것이 중요합니다.
기술적 난관이라면 대화와 조율로 풀릴 여지가 있습니다. 반면 불성실한 소통, 고의적인 지연, 역량 부족이 원인이라면 신뢰 회복은 어렵습니다. 한번 무너진 신뢰를 붙잡고 프로젝트를 끝까지 가는 것은 양쪽 모두에게 소모적입니다.
4. 남은 비용과 기회비용
프로젝트를 살리기 위해 앞으로 얼마가 더 필요한지를 계산해보면, "그냥 끝까지 가는 게 낫겠다"는 생각이 맞는지 다시 보이게 됩니다. 엎고 새로 시작할 때 드는 비용, 교체 개발사를 찾아 인수인계하는 데 드는 시간도 함께 놓고 봐야 합니다.
완전히 처음부터 다시 시작하는 비용이 남은 프로젝트를 마무리하는 비용과 크게 다르지 않다면, 그때는 새 출발이 더 경제적입니다. 하지만 절반 이상의 작업이 재사용 가능하고 신뢰 문제가 기술적 협의로 풀릴 수준이라면, 구조적으로 바로잡는 것이 비용 면에서 더 합리적인 경우가 많습니다.
결론: 어느 쪽도 쉬운 선택은 아닙니다
판단 기준을 정리하면 이렇습니다. 코드 자산이 부분적으로라도 재사용 가능하고, 소통 단절이 의지가 아닌 구조의 문제이며, 기술적 협의로 풀릴 여지가 있다면 살리는 쪽을 우선 검토합니다. 반면 코드 자산이 없거나 신뢰 회복 가능성이 낮고, 앞으로 들어갈 비용이 재시작 비용과 비슷하다면 교체를 고려합니다.
살리기로 했다면: 복구 프레임
살리기로 했다면, 지금까지와 같은 방식으로 계속 가는 것은 의미가 없습니다. 구조를 바꾸지 않으면 같은 문제가 반복됩니다. 복구는 세 가지 축에서 동시에 이루어져야 합니다.
범위 재정의
지금 시점에서 "원래 계획했던 모든 것"을 유지하려는 것은 현실적이지 않습니다. 현재 완료된 기능과 진행 중인 기능을 서면으로 명확히 정리하고, 이번 버전에서 반드시 포함해야 하는 것과 다음 단계로 미룰 수 있는 것을 구분합니다.
범위를 좁히면 납기를 현실화할 수 있고, 품질 집중도 높아집니다. 처음 계획보다 적게 출시하는 것은 실패가 아닙니다. 출시 자체가 없는 것보다 훨씬 낫습니다.
검수 주기 재설정
복구 구조에서 가장 중요한 변화는 검수 주기를 짧게 가져가는 것입니다. 월 단위 마일스톤보다는 주 단위 중간 확인이 훨씬 실효성이 있습니다.
주간 체크인에서는 세 가지를 확인합니다. 이번 주에 완료된 것, 다음 주에 할 것, 현재 막혀 있는 것. 구두 보고가 아니라 실제 결과물(화면 캡처, 동작 영상, 코드 변경 내역)을 기준으로 진행 여부를 판단합니다.
"보고"가 아니라 "증거"를 보는 체계입니다.
커뮤니케이션 채널 정비
채널이 여러 곳에 분산되어 있으면 중요한 내용이 유실됩니다. 공식 소통 채널을 하나로 통일하고, 결정 사항은 이메일이나 서면으로 남기는 것이 기본입니다. 구두로 합의한 것도 반드시 텍스트로 정리해서 공유하는 루틴을 만들어야 합니다.
상황별 대응의 세부 전술(지연 시 어떤 순서로 요청하는지, 소통이 완전히 막혔을 때 어떻게 접근하는지)은 외주 진행 중 문제가 생겼을 때의 상황별 대응 매뉴얼에 정리되어 있습니다.
엎기로 했다면
엎는 결정을 내렸다면, 그다음은 소스코드와 문서를 최대한 확보하는 것이 먼저입니다. 지금까지 만들어진 것 중 재사용 가능한 부분이 있다면 인수인계를 제대로 받아야 하고, 새 개발사가 처음부터 짐작으로 시작하지 않도록 맥락을 넘겨야 합니다.
개발사 교체 절차와 인수인계 방법은 개발사를 바꿔야 할 때: 인수인계 없이 프로젝트를 이어가는 법에서 구체적으로 다루고 있습니다.
인테그래빗이 이 문제를 다루는 방식
외주 프로젝트에서 소통 단절과 진행률 불투명은 대부분 구조의 문제입니다. "더 자주 물어봐야겠다"는 방법으로는 근본적으로 해결되지 않습니다.
인테그래빗은 클라이언트에게 Integrabbit Insight 포털을 통해 프로젝트 현황을 직접 확인할 수 있는 접근권을 제공합니다. 진행 중인 작업 항목, 완료 여부, 현재 블로커가 무엇인지를 담당자에게 물어보지 않아도 포털에서 실시간으로 볼 수 있습니다.
보고서가 아니라 실제 작업 데이터가 직접 보이는 구조입니다. 문제가 생겼을 때 "왜 이렇게 됐나"를 사후에 파악하는 것이 아니라, 블로커가 발생하는 순간 포털에서 확인하고 대응할 수 있습니다.
처음 계약할 때 이런 구조를 갖추고 시작하면, 중간에 "살릴까 엎을까"를 고민하는 상황 자체가 줄어듭니다. 외주 프로젝트 전체를 어떻게 구조화하는지가 궁금하다면 스타트업 MVP 외주 완전 가이드도 함께 보시면 도움이 됩니다.
지금 진행 중인 외주 프로젝트가 흔들리고 있다면, 30분 무료 상담을 통해 현재 상황을 같이 점검해볼 수 있습니다. 살릴 수 있는지, 어디서부터 바로잡아야 하는지 함께 확인합니다.