외주 개발을 의뢰해본 사람이라면 한 번쯤 이런 경험이 있을 것이다.
- 3개월 기다렸는데 나온 결과물이 기대와 완전히 다르다
- “추가 개발비”가 계속 붙어서 예산이 2배가 됐다
- 개발자가 중간에 연락이 끊겼다
반대로, 외주를 받아본 개발자라면:
- “이런 느낌으로 해주세요”라는 말을 들으며 기획서를 대신 써줬다
- 다 만들었는데 “이게 아닌데요”라는 피드백을 받았다
- 견적을 정직하게 냈더니 다른 업체에 뺏겼다
양쪽 다 억울하다. 그리고 양쪽 다 맞다.
”성공률 20%“는 무슨 뜻인가
외주 개발의 “성공”이란 기한 내 + 예산 내 + 기대한 품질을 동시에 달성하는 것이다. IT 프로젝트 통계에서 이 세 가지가 동시에 맞는 경우는 20% 남짓으로 반복 인용된다.
나머지 80%가 전부 폐기되는 건 아니다. 대부분은 부분 실패다.
- 완전한 실패 (프로젝트 폐기): ~20%
- 부분 실패 (늦거나, 비싸거나, 빠지거나): ~50%
- 성공: ~20%
“어떻게든 돌아가긴 하는데 아무도 만족하지 않는” 상태가 가장 흔한 결과다.
5가지 구조적 원인
1. 클라이언트가 뭘 원하는지 모른다
이건 비난이 아니다. 소프트웨어의 본질적인 특성이다.
외주의 전제는 “요구사항을 주면 만들어준다”인데, 요구사항 자체가 개발 과정에서 발견된다. 이게 소프트웨어와 건축의 결정적 차이다.
- 건축: 설계도 → 시공. 설계도가 바뀌면 비용이 명확하게 올라간다
- 소프트웨어: “이런 느낌으로” → 개발자가 해석 → 결과물을 보고 “이게 아닌데”
기획서가 없는 경우가 태반이고, 있어도 개발 언어로 번역이 안 되는 경우가 대부분이다. “메인 화면에 대시보드 넣어주세요”라는 말에 클라이언트가 상상하는 화면과 개발자가 만드는 화면은 거의 항상 다르다.
2. 견적이 구조적으로 틀려 있다
외주 시장의 인센티브 구조가 저가 입찰을 만든다.
- 클라이언트는 싸게 하고 싶다
- 개발사/프리랜서는 일단 따내고 싶다
- 결과: 실제 공수의 50~70%로 계약한다
- 중반부터 퀄리티를 타협하거나, “추가 개발” 명목으로 분쟁이 시작된다
여기에 역설이 있다. 정직하게 견적을 내면 비싸서 탈락하고, 싸게 내면 품질로 실패한다. 시장 자체가 정직한 견적을 벌하는 구조다.
위시캣이나 크몽에서 같은 프로젝트에 500만원과 2,000만원 견적이 동시에 들어오는 이유가 이것이다. 500만원이 사기인 게 아니라, 500만원짜리 범위와 2,000만원짜리 범위가 다른 것이다. 하지만 클라이언트 입장에서는 같은 프로젝트에 4배 차이가 나니 당연히 싼 쪽을 고른다.
3. 피드백 루프가 너무 늦다
외주의 전형적인 패턴:
계약 → (3개월 침묵) → "완성본입니다" → "이게 아닌데요"방향이 틀어진 걸 마지막에 발견한다.
소프트웨어는 중간에 계속 확인하고 교정해야 하는데, 외주 계약 구조가 “납품”이라는 단일 시점을 전제한다. 인테리어를 시키면서 완공 전에 한 번도 현장을 안 가는 사람은 없다. 그런데 외주 개발에서는 이게 흔하다.
2주마다 중간 결과물을 확인하는 것만으로도 실패 확률은 극적으로 줄어든다. 문제는 이런 구조를 제안하는 개발자도, 요구하는 클라이언트도 드물다는 것이다.
4. 커뮤니케이션 구조가 없다
- PM 없이 개발자와 클라이언트가 직접 소통 → 기술 용어 오해가 누적된다
- 의사결정권자가 분산되어 있다 (대표, PM, 기획자가 각각 다른 말을 한다)
- 카톡/전화 위주의 비공식 커뮤니케이션 → 기록이 없다 → 분쟁의 씨앗이 된다
“그때 통화로 얘기했잖아요”는 외주 분쟁에서 가장 많이 듣는 말이다. 서면 기록이 없으면 합의도 없다.
5. 공급 측 역량도 문제다
클라이언트만 탓할 수 없다. 외주 플랫폼의 스크리닝이 약하다.
- 포트폴리오 검증이 형식적이다
- 하청 → 재하청 구조 (계약한 사람과 실제 만드는 사람이 다르다)
- 1인 개발자가 5개 프로젝트를 동시에 진행한다
- 기술력이 아니라 가격으로 경쟁하는 시장이다
본질: 소프트웨어는 “주문 제작”이 아니다
위 5가지를 관통하는 하나의 본질이 있다.
외주 모델의 전제: “시키면 만들어주는 것” 소프트웨어의 현실: “만드는 과정에서 뭘 만들어야 하는지 알게 되는 것”
건축에서는 벽돌 쌓는 사람이 설계를 바꾸지 않는다. 하지만 소프트웨어에서는 코드 짜는 사람이 매일 설계 판단을 내린다. “이 버튼을 누르면 어떤 화면이 나와야 하지?” — 기획서에 안 적혀 있으면 개발자가 결정한다. 그리고 그 결정이 클라이언트의 기대와 다르면 “실패”가 된다.
이 갭을 메울 수 있는 건 중간에 계속 확인하는 구조뿐이다.
그러면 어떻게 해야 하는가
성공하는 20%에는 공통점이 있다.
클라이언트라면:
- 기획서를 먼저 만들어라. 화면 하나하나에 “이 버튼을 누르면 무슨 일이 일어나는지”가 적혀 있어야 한다. 기획 역량이 없다면, 기획 비용을 별도로 책정하라.
- 2주마다 중간 결과물을 확인하라. 3개월 뒤 완성본이 아니라, 2주마다 “지금까지 만든 것”을 보여달라고 요구하라.
- 의사결정자를 1명으로 정해라. 대표, PM, 기획자가 각각 다른 피드백을 주면 개발자는 혼란에 빠진다.
- 가장 싼 견적을 고르지 마라. 같은 프로젝트에 500만원과 2,000만원 견적이 왔다면, 500만원짜리가 뭘 빼고 있는지 물어봐라.
개발자/프리랜서라면:
- 범위를 서면으로 정의하라. 계약 전에 “이건 포함이고, 이건 불포함”을 문서로 만들어 서명 받아라.
- 정직한 견적을 내고, 근거를 보여줘라. “비쌉니다”가 아니라 “이 공수가 왜 이만큼 드는지”를 설명할 수 있어야 한다.
- 매주 진행 상황을 공유하라. 방향이 안 맞으면 즉시 조정할 수 있다. 3개월 뒤에 발견하면 3개월치 작업을 버리게 된다.
- 구두 합의는 합의가 아니다. 모든 변경사항은 서면으로 남겨라.
외주 개발이 실패하는 건 누군가의 잘못이 아니다. 외주라는 구조와 소프트웨어라는 매체가 근본적으로 맞지 않는 부분이 있기 때문이다. 그 갭을 인식하고, 중간 검증 루프를 짧게 유지하는 것만으로도 성공 확률은 극적으로 올라간다.
80%의 실패 속에서 20%에 들어가는 방법은 생각보다 단순하다. 중간에 자주 확인하고, 기록을 남기는 것. 그게 전부다.