앱 외주 개발 실패 사례와 피하는 법: 계약 전 체크리스트

앱 외주는 주로 어떻게 실패하나요?

IT 외주 분쟁을 다루는 변호사 칼럼은 분쟁 유형을 이렇게 나눠요 보도.

• 과업 범위가 흐릿한 경우: 기능 명세나 화면 설계 없이 채팅·전화로만 소통하다가, 개발자가 요청 기능이 원래 범위 밖이라고 주장해요.
• 미완성인데 "단순 버그"라고 하는 경우: 자주 멈추거나 핵심 기능이 안 되면 단순 하자를 넘어 계약 목적을 못 이룬 것으로 다툴 수 있다고 설명해요.
• 지연으로 손해가 커지는 경우: 출시가 밀리면서 이미 쓴 마케팅·인건비가 손해로 남아요.
• 잔금 다툼: 결과물이 부족한데 잔금을 요구하는 경우예요. 칼럼은 완성도를 코딩한 시간이 아니라 발주자가 받아서 원래 목적대로 쓸 수 있는지로 본다고 설명해요.
• 소스코드 문제: 품질이 나빠 새로 짜는 게 더 싸거나, 개발자가 코드를 지우거나 서버 접근을 끊기 전에 증거를 보존해야 하는 상황이에요.

업계 쪽 정리도 비슷해요. 한 AI 기업 블로그는 실패 원인으로 불명확한 요구사항, 소통 공백, 업체 검증 부족, 모호한 계약, 마일스톤 부재, QA 생략을 꼽아요 보도. 크몽 매거진 글은 개발 시작 전에 무엇을 만들지 정하지 못한 것을 가장 큰 원인으로 들어요 보도. 두 글 모두 "90%" 같은 수치를 쓰지만 출처가 없어서 이 글에서는 옮기지 않았어요.

왜 작게 시작해야 하나요?

규모 자체가 위험이에요. 스탠디시 그룹 CHAOS 2015 보고서에서 소규모 프로젝트는 61%가 성공, 7%가 실패했고, 대규모 프로젝트는 11%가 성공, 30%가 실패했어요 보도. 첫 외주는 핵심 기능 1–2개로 줄여서 끝까지 출시해 보는 게 실패 확률을 낮추는 가장 단순한 방법이에요. 범위 줄이는 법은 범위서 쓰는 법에 있어요.

계약 전에 무엇을 확인해야 하나요? (12가지 체크리스트)

1. 포함 기능과 미포함 기능이 모두 적힌 범위서가 있나요?
2. 범위서가 계약서에 첨부되나요?
3. 실제 개발자의 이름과 그 사람이 직접 만든 결과물 링크를 받았나요?
4. 사업자 상태(휴·폐업)와 업종을 홈택스에서 확인했나요?
5. 재하청하지 않는다는 조항이 있나요? (지원사업이면 필수 공고 확인 제38조⑨)
6. 주 1회 라이브 데모 요일이 정해졌나요?
7. 저장소를 대표님 계정 소유로 만들고 첫 주부터 초대받나요?
8. 앱스토어·플레이 콘솔·서버·결제 계정이 대표님 명의인가요?
9. 선금이 50% 이하인가요? (지원사업 상한 공고 확인 제38조⑤)
10. 잔금이 "배포 확인 후"로 적혀 있나요?
11. 검수 기준과 하자보수 기간이 숫자로 적혀 있나요?
12. 인도 목록(소스코드, 빌드 파일, 서명 키, 계정 정보, 문서)이 있나요?

12번은 크몽 매거진 글도 같은 항목을 권해요. 전체 소스코드, Git 접근권, 스토어용 빌드 파일, Android 키스토어 같은 서명 키, 최종 기획서예요 보도. 각 조항 문구는 계약서 필수 조항 10가지에서 다뤄요.

주 1회 데모는 무엇을 막아 주나요?

데모는 문제를 일찍 보이게 해요. 매주 실제 작동하는 화면을 보면 범위 오해는 1주 안에 드러나고, 진행이 멈추면 바로 알 수 있어요. 녹화본이 아니라 라이브로, 개발자 본인이 설명하게 하면 재하청 여부도 함께 확인돼요(재하청 확인법).

데모 날 체크할 건 세 가지면 충분해요.

1. 지난주 약속한 기능이 실제로 눌러지나요?
2. 저장소에 이번 주 커밋이 쌓였나요?
3. 다음 주 약속은 무엇인가요? (메신저에 글로 남기기)

CHAOS 2015 보고서에서 애자일 방식 성공률은 39%, 워터폴은 11%였어요 보도. 짧은 주기로 결과물을 확인하는 방식이 실패를 줄인다는 근거로 자주 인용돼요.

선금 50% · 잔금 배포 후는 왜 안전한가요?

돈이 나가는 시점을 결과물이 나오는 시점에 맞추는 구조예요.

• 선금 50%: 개발자가 일정을 비우고 시작할 수 있을 만큼이면서, 발주자가 잃을 수 있는 최대 금액을 절반으로 묶어요. 지원사업도 선금 합계를 50% 이하로 정하고, 500만원 이상이면 선금보증보험증권을 요구해요 공고 확인. 자세한 건 선금 보증보험 정리에 있어요.
• 잔금 배포 후: 스토어 출시나 실제 도메인 배포를 눈으로 확인한 뒤 나머지를 줘요. 앞서 본 "결과물이 부족한데 잔금 요구" 분쟁이 생길 틈이 줄어요.

모두의 MVP는 이 구조를 할인 없이 그대로 써요. 앱 MVP라면 이렇게 나뉘어요.

튜브링고를 iOS·Android에 출시하고 운영하면서 심사 대응, 결제 연동, 푸시 설정을 직접 겪었어요. 그래서 "출시까지"를 범위에 넣고, 출시가 끝나야 잔금을 받아요.

이미 문제가 생겼다면 무엇부터 하나요?

변호사 칼럼은 증거 보존을 먼저 권해요 보도. 오류 화면 녹화, 에러 로그, 이메일로 남긴 수정 요청을 모으고, 소송 전에는 내용증명을 보내라고 해요. 저장소와 서버 계정이 대표님 명의라면 이 단계가 훨씬 쉬워요. 실제 분쟁은 사안마다 달라서 변호사 상담을 받으세요. 이 글은 법률 자문이 아니에요.

---

모두의 MVP는 웹·앱 MVP를 외주로 개발하는 스튜디오예요. 실패를 줄이는 장치를 기본값으로 둬요. 범위서 1장(포함 5줄·미포함 3줄), 주 1회 데모, 대표님 명의 계정, 선금 50%·잔금 배포 후예요. 매출은 약속하지 않아요. 아이디어 한 줄만 보내 주세요.

출처 (2026-10-12 확인)

• 민경남 변호사, IT 외주 개발 분쟁 대응 및 승소 전략(로톡) — lawtalk.co.kr
• 알체라 블로그, 소프트웨어 외주 개발 성공하는 방법(2025.09.30) — alchera.ai
• 크몽 매거진, 앱 개발 의뢰 시 알아야 할 것(2025.11.17) — kmong.com
• The Standish Group, CHAOS Report 2015 — PDF
• 중소기업창업 지원사업 통합관리지침(2025.12.23 전부개정) 제38조 — 공고 별첨 PDF