외주·프리랜서 개발이 실패하는 가장 큰 이유 — 실력보다 '소통'과 '기획'의 부재

요약: 외주 개발이 틀어졌다는 이야기를 들으면 흔히 "개발자 실력이 부족했나 보다"라고 생각합니다. 하지만 해외 프로젝트관리 조사와 국내 공공SW 정책을 보면 실패 원인으로 계속 꼽히는 것은 코딩 실력이 아니라, 무엇을 만들지 정하는 기획(요구사항)과 그것을 주고받는 소통입니다. 만드는 사람이 의뢰자의 서비스를 이해하지 못한 채 화면만 찍어 내면, 결과물이 아무리 잘 돌아가도 "우리가 원한 게 아니다"라는 말이 나옵니다.

숫자로 보는 실패 원인

1. 요구사항(기획)이 불명확해서

• 국제 프로젝트관리협회(PMI)의 2014년 조사에서, 목표를 달성하지 못한 프로젝트의 47%가 부실한 요구사항 관리 때문이었습니다. 프로젝트 비용 1달러당 약 5.1센트가 이 문제로 낭비된다고 추산했습니다.
• PMI의 2017년 조사에서는 실패 원인으로 "부정확한 요구사항 수집"이 39%로 2위(1위는 조직 우선순위 변경)였고, 2018년 조사에서도 35%로 상위권이었습니다.
• 미국 Standish Group의 CHAOS 보고서는 성공 요인 상위에 사용자 참여, 명확한 요구사항, 적절한 계획을, 지연·취소 요인 상위에 사용자 의견 부족, 불완전한 요구사항, 요구사항 변경을 꼽았습니다.
• IAG Consulting은 요구사항 관리가 부실한 기업이 프로젝트에 시간과 예산을 최대 60% 더 쓴다고 분석했습니다.

2. 소통이 끊겨서

• PMI의 2013년 조사에서, 비효율적인 소통은 3번 중 1번꼴로 프로젝트 실패의 주된 원인이었고, 위험에 처한 프로젝트 예산의 56%가 소통 문제와 관련됐습니다.
• 2018년 조사에서도 "부적절하거나 부실한 소통"이 실패 원인으로 29%를 차지했습니다.

3. 서로 다른 그림을 보고 있어서

• 2011년 Geneca 설문(596명)에서 78%가 비즈니스 쪽과 개발 쪽의 요구사항이 늘 또는 대개 어긋나 있다고 답했습니다.
• 프로젝트가 언제 "완료"된 것인지 항상 합의한다는 응답은 23% 에 그쳤고, 80%는 시간의 절반 이상을 재작업에 쓴다고 답했습니다.

4. 외주에서는 '범위'로 터진다

• Deloitte의 2012년 외주 조사에서 응답 기관의 48%가 외주 계약을 해지한 경험이 있었고, 불만의 주된 원인은 업체가 범위를 과소평가한 것이었습니다. 범위를 과소평가했다는 건 결국 무엇을 만들지 처음에 충분히 맞추지 못했다는 뜻입니다.

국내에서도 같은 문제가 반복됩니다

• 정부도 이 문제를 법으로 다루고 있습니다. 공공SW 사업은 2012년부터 발주기관이 요구사항을 구체적으로 적도록(요구사항 상세화) 하고 있고, 과학기술정보통신부는 2018년 실무 가이드까지 냈습니다.
• 그런데도 소프트웨어정책연구소(SPRi)의 2017년 연구에서 발주자와 수주자 모두 해결해야 할 1순위로 "과업(요구사항) 명확화" 를 꼽았습니다.
• 진행 중에 요구가 바뀌어 원래 계약보다 과업이 최대 70% 늘어난 사례도 보도됐고, 2026년 7월에는 과업이 바뀔 때 심의위원회를 반드시 열도록 하는 법 개정안이 국회를 통과했습니다.
• 민간 외주도 마찬가지입니다. 외주 플랫폼 위시켓은 외주 실패 이유 1위로 의뢰자의 불명확한 기획과 이해 부족을, 3위로 소통·관리 부족을 꼽았습니다. 프리모아 인터뷰에서는 30일로 잡았던 프로젝트가 기획 협의 부족으로 120일까지 늘어나다 결국 무산된 사례가 소개됐습니다.

왜 외주·프리랜서에서 특히 심할까?

1. 서비스를 아는 사람과 만드는 사람이 다릅니다. 의뢰자는 자기 사업을 잘 알지만 개발 용어로 설명하기 어렵고, 개발자는 코드는 잘 알지만 그 사업의 고객과 업무 흐름을 모릅니다. 둘 사이를 연결하는 기획이 비어 있으면, 개발자는 문서에 적힌 글자 그대로만 만듭니다.

2. "알아서 잘 해 주세요"가 가장 위험한 말입니다. 예를 들어 "예약 기능"이라고만 하면, 취소·변경은 언제까지 되는지, 중복 예약은 어떻게 막는지, 알림은 누구에게 가는지가 정해지지 않습니다. 이 빈칸을 누가 언제 채우느냐에 따라 일정과 비용이 크게 달라집니다.

3. 중간 확인 없이 마지막에 한꺼번에 봅니다. 몇 주 동안 연락이 뜸하다가 마지막에 결과물을 받으면, 방향이 어긋난 것을 고치는 비용이 가장 커진 뒤입니다. Geneca 조사에서 80%가 시간의 절반 이상을 재작업에 쓴다고 답한 것도 같은 맥락입니다.

4. 중간에 사람이 바뀌거나 전달 단계가 많습니다. 상담한 사람과 실제 개발자가 다르거나, 일을 다시 하청 주면 의도가 한 단계씩 흐려집니다.

실패를 줄이려면: 의뢰 전에 확인할 것

의뢰자가 준비할 것

• 누가, 왜 쓰는 서비스인지 한두 문장으로 정리하기
• 꼭 필요한 기능과 나중에 해도 되는 기능을 나누기
• 참고하는 서비스나 화면이 있으면 캡처해 두기

외주 파트너에게 확인할 것

• 견적 전에 우리 사업과 고객에 대해 질문을 하는가? 질문 없이 바로 금액부터 말한다면 이해 없이 만들 가능성이 큽니다.
• 화면 흐름이나 기능 목록을 먼저 정리해 주는가? 개발 전에 "이렇게 만들겠다"는 그림을 함께 확인하는 단계가 있어야 합니다.
• 상담한 사람이 실제로 개발하는가? 전달 단계가 적을수록 의도가 덜 흐려집니다.
• 진행 중 얼마나 자주 결과물을 보여 주는가? 1~2주마다 실제로 동작하는 화면을 확인하는 것이 좋습니다.
• "완료"의 기준을 미리 정하는가? 무엇을 확인하면 끝난 것인지 계약 전에 합의해야 분쟁이 줄어듭니다.

정리하면

외주 개발의 성패는 얼마나 잘 만드느냐보다, 무엇을 만들지 얼마나 잘 맞추느냐에서 먼저 갈립니다. 서비스를 이해하려는 질문, 개발 전에 함께 확인하는 기획, 진행 중 꾸준한 소통. 이 세 가지가 있는 파트너라면 실패할 확률은 크게 줄어듭니다.

딱개발은 프로젝트마다 담당자 한 명이 기획 상담부터 개발, 운영까지 직접 맡습니다. 상담에서 사업과 고객에 대해 먼저 여쭙고, 작업 범위를 기능 단위로 정리한 뒤 견적을 드리며, 진행 중에는 중간 결과물을 공유합니다. 만들고 싶은 서비스가 있다면 문의 게시판에 편하게 적어 주세요. 정리가 덜 된 아이디어여도 괜찮습니다.

출처

• Business Wire — PMI: Project Budget at Risk Due to Ineffective Communications (2013.5.22)
• PMI — Pulse of the Profession 2013: The High Cost of Low Performance, The Essential Role of Communications
• Watermark Learning — PMI Pulse 2014 Requirements Management 요약
• PMI — Pulse of the Profession 2017 (PDF)
• PMI — Pulse of the Profession 2018 (PDF)
• Standish Group — CHAOS Report (PDF)
• PR Newswire — Geneca: Up to 75% of Business and IT Executives Anticipate Their Software Projects Will Fail (2011.3.14)
• IAG Consulting — Business Analysis Benchmark
• PR Newswire — Deloitte 2012 Global Outsourcing and Insourcing Survey
• 소프트웨어정책연구소 — 공공SW사업 발주관리의 현황, 문제점, 개선방안 (2017)
• 디지털데일리 — 공공SW 요구사항 상세화 (2023.7.6)
• 전자신문 — 공공SW 과업변경, 이대론 안된다 (2023.9.26)
• 지디넷코리아 — 과업심의위원회 의무화 개정안 본회의 통과 (2026.7.27)
• 위시켓 블로그 — 외주 개발이 실패하는 진짜 이유 5가지 (2024.8.28)
• 아웃소싱타임스 — 기획서 없는 IT 아웃소싱, 실패 확률 높인다