외주 개발 실패 사례 7가지 — 수천만 원 날리기 전에 읽어야 할 글

작년 여름, 한 스타트업 대표에게서 전화가 왔다. 목소리가 떨리고 있었다. "3천만 원 들여서 앱 만들었는데, 출시를 못 하겠어요."

사연은 이랬다. 자신만의 커머스 앱을 만들고 싶었고, 지인 소개로 개발팀을 찾았다. 미팅 한 번 하고, 구두로 요구사항을 전달하고, 계약서에 도장 찍었다. 3개월 후 받아본 결과물은 상상과 완전히 달랐다. 결제 기능은 빠져 있었고, UI는 2010년대 감성이었으며, 관리자 페이지는 아예 없었다.

추가 개발? 별도 비용이라고 했다. 계약서에 명시 안 된 건 범위 밖이라는 거다. 법적으로도 할 말이 없었다. 기획서가 없으니 "원래 이게 맞다"는 주장에 반박할 수 없었던 것이다.

이 이야기가 특별한 건 아니다. 나는 PM으로 일하면서 비슷한 사례를 수십 건 봤다. 금액만 다르지 패턴은 동일하다. 그래서 정리했다. 실패에는 분명한 패턴이 있고, 같은 실수를 반복하지 않으려면 남의 실패를 공부해야 한다.

사례 1. 기획서 없이 시작한 쇼핑몰

"장바구니 있고, 결제되고, 상품 올릴 수 있으면 돼요." 이게 의뢰인이 전달한 요구사항 전부였다. 개발자는 나름 성실하게 만들었다. 문제는 '나름'이었다. 상품 옵션 선택 기능이 없었고, 배송지 관리도 빠졌고, 쿠폰 시스템은 존재하지 않았다. 의뢰인 입장에선 "당연히 있어야 하는 것"들이 전부 빠진 셈이다.

결국 추가 개발 비용만 원래 견적의 2배가 들었다. 처음부터 기획서 한 장이라도 있었으면 이런 일은 없었을 것이다.

사례 2. 끝나지 않는 기능 추가 — 스코프 크리프

한 교육 플랫폼 프로젝트였다. 초기엔 강의 목록과 결제만 있으면 됐다. 그런데 개발 중에 "채팅 기능도 넣자", "퀴즈 기능도 필요하다", "선생님 대시보드도 있으면 좋겠다"가 계속 추가됐다.

개발팀은 말 그대로 폭주했다. 일정은 2개월에서 6개월로 늘어났고, 예산은 당초의 3배를 넘겼다. 최악인 건 기능이 많아지면서 기존에 잘 작동하던 부분까지 불안정해졌다는 점이다. 마일스톤 없이 기능을 계속 추가하면 프로젝트는 반드시 무너진다.

사례 3. "깔끔하게 해주세요"의 비극

디자인 의뢰에서 가장 위험한 말이 뭔지 아는가? "깔끔하게 해주세요"다. 이 한마디로 디자인을 맡기면 수정만 10번은 각오해야 한다.

한 법률 서비스 앱 프로젝트에서 실제로 일어난 일이다. 대표는 미니멀한 느낌을 원했는데, 디자이너는 '전문적인' 느낌으로 해석했다. 결과물은 네이비 블루에 세리프 폰트, 딱딱한 법률 사무소 사이트 같았다. 대표가 원한 건 토스 같은 감성이었다.

레퍼런스 3개만 보여줬어도 이런 일은 없었을 것이다. 디자인은 언어가 아니라 이미지로 소통해야 한다.

사례 4. 최저가 견적의 함정

배달 앱을 만들고 싶은 예비 창업자가 있었다. 견적을 5곳에서 받았다. 3곳은 3000만~5000만 원 사이였고, 1곳은 2000만 원, 그리고 1곳이 500만 원이었다.

500만 원에 끌렸다. "기본 기능만 넣으면 된다"며 자기 합리화를 했다. 결과는 참혹했다. 앱이 수시로 크래시 났고, 지도 API 연동은 반만 작동했고, 주문 데이터가 가끔 유실됐다. 출시는커녕 테스트도 못 할 수준이었다.

결국 다른 개발사에 리팩토링을 맡겼는데, 코드 품질이 너무 낮아서 처음부터 다시 짜야 했다. 리팩토링 비용 2000만 원. 합하면 2500만 원을 쓰고도 원래 3000만 원짜리보다 못한 결과물을 갖게 된 것이다.

싼 데는 이유가 있다. 500만 원에 앱을 만들어준다는 건, 그만큼 어딘가에서 비용을 깎고 있다는 뜻이다. 대부분 테스트, 코드 리뷰, 문서화에서 깎는다. 가장 중요한 부분에서.

사례 5. 화려한 포트폴리오의 이면

한 헬스케어 스타트업이 개발사를 선정할 때 포트폴리오가 가장 화려한 곳을 골랐다. 유명 기업 로고가 줄줄이 걸려 있었고, 앱 스토어 스크린샷도 그럴듯했다.

문제는 그 개발사가 실제로 만든 게 아니었다는 점이다. 프로젝트 대부분을 하청으로 넘기고 있었고, 일부는 재하청까지 갔다. 실제로 코드를 짜는 사람은 경력 1~2년 차 주니어들이었다.

중간에 담당 개발자가 세 번이나 바뀌었고, 인수인계가 제대로 안 돼서 같은 버그가 반복됐다. 포트폴리오만 보고 결정하면 안 된다. 반드시 '이 프로젝트에 실제로 투입될 사람'이 누구인지 확인해야 한다. 가능하다면 그 사람의 GitHub이나 이전 작업 코드를 직접 보는 것이 좋다.

사례 6. 중간 점검 없는 3개월의 결말

한 B2B SaaS 프로젝트 이야기다. 계약을 하고 착수금을 보낸 뒤, 3개월간 진행 상황을 제대로 확인하지 않았다. 개발사 쪽에서 "순조롭게 진행 중입니다"라는 메시지가 가끔 오긴 했다.

3개월 후 완성본을 받아보니 기대와 완전히 달랐다. 데이터 구조부터 잘못 설계되어 있었고, 관리자 페이지의 UX는 실사용이 불가능한 수준이었다. 이미 개발이 끝나버린 상태라 수정은 사실상 재개발이었다.

2주에 한 번이라도 화면을 공유하며 점검했으면 초기에 방향을 잡을 수 있었을 것이다. 개발은 완성 후에 확인하는 게 아니라, 만드는 과정에서 계속 확인해야 한다.

사례 7. 선금 100%의 비극

이건 가장 극단적인 사례다. 한 의뢰인이 개인 개발자에게 1500만 원짜리 프로젝트를 맡기면서 선금 100%를 보냈다. 계약서에 에스크로 조항도 없었고, 마일스톤별 정산도 없었다.

초반 2주간은 연락이 잘 됐다. 그 이후 답장이 점점 늦어지더니, 한 달 후부터 연락이 두절됐다. 카카오톡 읽씩, 전화 부재중. 결국 1500만 원과 3개월이라는 시간을 동시에 잃었다.

물론 모든 개인 개발자가 이렇다는 건 아니다. 하지만 구조적으로 위험을 통제하지 않으면 이런 일이 발생할 수 있다. 에스크로를 쓰거나, 최소한 마일스톤별로 나눠서 정산하는 건 자신을 보호하는 가장 기본적인 장치다.

위 사례들에서 공통적으로 빠져 있던 것들을 체크리스트로 정리했다. 외주를 맡기기 전에 이것만 확인해도 실패 확률을 절반 이하로 줄일 수 있다.

1. 기획서 또는 와이어프레임을 먼저 만들어라. 완벽하지 않아도 된다. 화면 단위로 "이 화면에서 뭘 할 수 있는지"만 정리해도 충분하다. Figma 무료 버전이면 충분하다.

2. 마일스톤 단위로 계약하라. 전체 일정을 3~5개 구간으로 나누고, 각 구간이 끝날 때 결과물을 확인하고 정산한다. 중간에 방향이 틀어져도 손실을 최소화할 수 있다.

3. 에스크로는 선택이 아니라 필수다. 플랫폼 에스크로든, 계약서상 조건부 정산이든, 결과물 확인 전에 전액을 넘기지 않는 구조를 만들어야 한다.

4. 주 1회 이상 미팅하라. 짧은 화상 미팅이면 된다. 15분이면 충분하다. 화면 공유하면서 진행 상황을 눈으로 확인하는 것과 메시지로 "잘 되고 있어요"를 듣는 건 완전히 다른 차원이다.

5. 견적은 반드시 3곳 이상 비교하라. 최저가를 고르라는 게 아니다. 가격 범위를 파악하는 것이 중요하다. 상식적인 범위에서 크게 벗어나는 견적은 이유가 있다.

6. 포트폴리오와 함께 실제 코드를 확인하라. GitHub 링크를 요청하거나, 이전 프로젝트의 코드 일부를 볼 수 있는지 물어보라. 코드 품질은 포트폴리오 스크린샷만으론 절대 알 수 없다.

7. 하자보수 조항을 계약서에 넣어라. 납품 후 최소 1~3개월간의 버그 수정 의무를 명시하라. 이게 없으면 납품 직후 발견되는 버그조차 추가 비용으로 청구될 수 있다.

체크리스트도 중요하지만, 솔직히 말하면 결국 핵심은 하나다. 신뢰할 수 있는 파트너를 만나면 반은 해결된다.

좋은 개발 파트너는 기획서가 부족하면 먼저 질문한다. 스코프가 늘어나면 일정과 비용에 미치는 영향을 미리 알려준다. 중간 점검을 스스로 제안하고, 문제가 생기면 숨기지 않고 공유한다.

문제는 이런 파트너를 어떻게 찾느냐는 것이다.

럿지(LUDGI)를 만든 이유가 여기에 있다. 대표가 직접 프로젝트 상담을 하고, 요구사항에 맞는 프리랜서를 AI가 분석해서 매칭률과 함께 보여준다. 포트폴리오가 단순히 예쁜 스크린샷이 아니라, 실제 기술 스택과 프로젝트 복잡도까지 분석된 데이터다.

그리고 에스크로와 마일스톤 관리 시스템이 기본으로 내장되어 있다. 위에서 말한 "선금 100% 비극" 같은 일이 구조적으로 일어날 수 없다.

외주 개발이 도박이 되면 안 된다. 좋은 파트너, 좋은 프로세스, 좋은 도구가 만나면 외주도 충분히 성공할 수 있다. 남의 실패에서 배우고, 자신은 다른 선택을 하자.