외주 개발이 실패하는 7가지 이유: 반복되는 실패의 패턴과 예방법
외주 개발 실패는 개별 운의 문제가 아니라 구조의 문제입니다. 어디에서 무너지는지를 미리 알면, 같은 자리에서 다시 무너지지 않을 수 있습니다. 그 원인으로부터 실패 예방법을 도출하고자 합니다.
May 15, 2026
NIPA 소프트웨어산업실태조사에 따르면 국내 SW 용역 시장은 연 20조 원 규모로 추정됩니다. 그 시장에서 매년 수많은 기업이 앱과 웹을 비롯해서 내부 시스템과 프로그램을 외주 개발을 통해 만들지만, 중소벤처기업부 디지털전환 실태조사에 따르면 외주로 디지털전환을 추진한 중소기업의 상당수가 재작업이나 프로젝트 실패를 경험한 것으로 나타났습니다.
이 글이 다루는 외주 개발이 실패로 귀결되는 7가지 원인은 다음과 같습니다. ① 요구사항이 모호한 채로 시작, ② PM이 없거나 권한이 없음, ③ 계약서가 스코프·IP·유지보수를 다루지 않음, ④ 중간 산출물 검토 부재, ⑤ 개발자 다중 프로젝트 병행, ⑥ 소통 채널·응답 시간 미정, ⑦ 유지보수 계획 없는 출시. 각 원인이 왜 발생하는지, 어떻게 예방하는지를 차례로 살펴봅니다.
결론적으로, 외주 개발 실패는 개별 운의 문제가 아니라 구조의 문제입니다. 어디에서 무너지는지를 미리 알면, 같은 자리에서 다시 무너지지 않을 수 있습니다.
1. 요구사항이 모호한 채로 시작합니다
SW 개발 프로젝트의 실패 원인을 묻는 산업 조사에서 '요구사항 정의 미흡'은 매년 1~2위로 꼽힙니다. 발주자는 "개발사가 우리 말을 이해하지 못했다"고 답하고, 개발사는 "요구사항이 계속 바뀌었다"고 답하는 구조가 반복됩니다. 양쪽이 서로를 가리키는 이 구도 자체가 요구사항 미정의의 증거인 셈입니다.
선명한 요구조건 없이 시작되는 개발 프로젝트
클라이언트는 사업 비전을 가지고 외주를 시작하지만, 개발사는 정량적인 산출물을 기준으로 일을 합니다. 그 사이의 인식 격차가 출발선이 됩니다. 한국 중소기업 외주 시장의 관행은 이 격차를 더 키웁니다. 요구사항을 탐색하는 단계 없이 계약을 구두로 착수하는 경우가 많고, 와이어프레임 없이 "MVP 만들고 싶어요"라는 한 줄로 견적이 오가곤 합니다. 변경 자체가 문제가 아니라, 변경을 어떻게 처리할지에 대한 약속이 없는 것이 진짜 문제입니다.
한 중견 유통사가 재구축 상담을 의뢰해 왔던 시점은, 외주를 시작한 지 3개월이 지난 때였습니다. 처음 4,000만 원이던 견적이 1억 2,000만 원 지점에 도달해 프로젝트가 중단된 직후였던 것입니다. "직원용 재고 관리 앱"이라는 한 줄짜리 정의로 출발했던 프로젝트가 협력사 연동, 고객 주문 흐름, 매장 POS 통합이 차례로 추가되며 "통합 플랫폼"으로 확장된 결과였습니다. 양측이 누가 어디까지 책임지는가를 끝내 합의하지 못한 상태로 끝난 자리에서 — 변경 요청 기록을 들여다보니 28건이 누적되어 있었고, 그중 단 한 건도 변경 처리 절차를 거친 흔적이 없었습니다. 변경 자체가 잘못된 것은 아닙니다. 시장을 보며 방향을 조정하는 일은 자연스럽습니다. 진짜 원인은 변경을 어떻게 처리할 것인가에 대한 룰이 계약서에 처음부터 없었다는 점에 있었습니다.
명확한 '요구조건'과 명료한 계약 조항 정의
핵심은 "변경을 다룰 과정"을 계약 시작 전에 만들어 두는 것입니다. 사전 디스커버리 워크숍에서 핵심 사용자 흐름 3개를 정의하고, 와이어프레임과 사용자 흐름도를 계약 첨부물로 합의해 두면 변경의 출발선이 분명해집니다. 그 위에 "스코프 변경 = 별도 견적"인지 "월 시간 한도 내 흡수"인지를 계약서에 명문화하면, 변경 자체가 분쟁의 씨앗이 되지 않습니다.
✓ 다음 미팅에서 바로 물어볼 3가지
□ 변경 발생 시 비용·일정 산정 룰이 계약서에 있는가?
□ 디스커버리 워크숍이 별도 단계로 잡혀 있는가?
□ 와이어프레임을 계약 전 함께 검토하는가?
2. PM이 없거나, 있어도 권한이 없습니다
10인 미만 SW 개발사에서 전담 PM이 있는 비율은 30% 미만으로 알려져 있습니다(NIPA 소프트웨어산업실태조사 기반). 절반 이상의 외주 프로젝트가 '개발자 겸 PM' 구조로 굴러간다는 뜻입니다. 클라이언트와 직접 소통하는 사람이 결국 코드를 짜는 사람이라면, 의사결정 지연과 트레이드오프 설명 부재는 시간 문제로 이어집니다.
권한 없는 PM이 진행하는 경우
명목상 PM이 있어도 의사결정 권한이 없는 경우가 많습니다. 회의에서 "확인하고 알려드리겠습니다"만 반복되면 그 자리에서 결론이 나오지 않고, 결정은 다음 회의로 미뤄지며, 그 사이 개발자는 가설 위에서 코드를 짜다가 가설이 틀리면 다시 작성하게 됩니다. PMI 글로벌 조사에서도 의사결정자 부재 프로젝트의 실패율이 높다는 패턴이 반복 확인됩니다. 개발자 겸 PM 구조에서는 코드 시간을 통역에 쓰게 되고, 결과적으로 코드 품질도 함께 떨어집니다.
한 의료기기 회사의 환자 데이터 수집 앱 프로젝트에서는, 6개월 동안 매주 정기 회의에서 "그건 결정하고 알려드리겠습니다"라는 답이 반복됐습니다. 사후 자문에서 회의록을 들여다보니 그 이유는 분명했습니다 — 개발사 측 PM은 진척을 보고하는 역할에 머물렀고, 클라이언트 측에서 의료기기 규제 대응을 책임지는 임원은 정작 회의에 참석하지 못하는 일이 잦았던 것입니다. 개발팀은 자체 추측으로 환자 동의 흐름을 설계해 3주 동안 9개 화면을 구현했지만, 검토 자리에서 "이 흐름은 의료기기법 고지 의무와 맞지 않는다"는 한 마디에 화면 전체가 다시 그려져야 했습니다. 잃어버린 3주의 책임 소재를 묻는 자리에서 PM도, 개발자도, 클라이언트 임원도 한 발씩 비켜서 있었던 구조 — 그 자체가 PM 부재의 결과였습니다.
결정 권한을 가진 단일 의사결정자
확인할 항목은 결국 "누가 결정을 내리는가"로 모입니다. 개발사 측에 전담 PM이 있는지, 그 PM이 의사결정에 참여할 권한이 있는지를 계약 전에 묻는 것이 출발점이 됩니다. 클라이언트 측에서도 단일 의사결정자를 지정해야 하는데, 위원회식 결정 구조는 그 자체로 속도를 떨어뜨리기 때문입니다. 주간 미팅 안건은 의사결정 / 보고 / 검토로 구분해 사전에 정리해 두면, 한 시간짜리 회의가 두 시간이 되는 일이 줄어듭니다.
✓ 계약 전 확인할 3가지
□ 개발사 측 전담 PM이 있는가? 의사결정에 참여하는가?
□ 우리 측 단일 의사결정자가 누구인가?
□ 주간 미팅 안건이 의사결정/보고/검토로 구분되는가?
3. 계약서가 스코프·IP·유지보수를 다루지 않습니다
KOSA(한국소프트웨어산업협회)가 보급한 SW 표준계약서는 정부 권고 양식임에도, 민간 중소기업 발주에서는 사용 비율이 절반 수준에 머무르는 것으로 파악됩니다. 분쟁이 발생하면 "계약서엔 그렇게 안 적혀 있어서요"라는 답이 돌아오는 이유입니다. 외주 개발 실패의 상당수는 분쟁 자체보다, 분쟁을 다룰 도구가 처음부터 없었던 데서 시작됩니다.
분쟁을 다룰 조항이 처음부터 부재한 경우
표준계약을 사용하지 않으면 스코프 변경, IP 귀속, 유지보수 책임 같은 핵심 조항이 누락되기 쉽습니다. 분쟁이 조정 단계로 가도 "납품 완료 기준"이 모호하면 양측 주장이 평행선을 달립니다. IP 조항이 없으면 개발이 끝난 후에도 소스코드의 주인이 누구인지에 대한 다툼이 따로 시작되고, 유지보수 책임 범위가 없으면 출시 직후 첫 버그가 분쟁의 시작점이 됩니다.
디지털 구독 플랫폼 1억 5,000만 원짜리를 외주해 6개월 만에 출시한 한 중견 출판사가 있었습니다. 문제는 그 다음이었습니다. 출시 한 달 뒤 모바일 결제 모듈을 추가하려 하자 기존 개발사가 소스코드 인계를 거부했고, 그 근거가 "계약서에 IP 귀속 조항이 명시되어 있지 않다"는 점이었습니다. 추가 기능에 대한 별도 단가 협상도 같은 이유로 막혔습니다. 분쟁조정 절차에 6개월을 잃은 끝에 처음부터 다시 만들어 달라는 의뢰가 들어왔고, 두 번째 외주에 1억 4,000만 원이 더 들어갔습니다. 같은 결과물을 받기 위해, 표준계약서의 IP 귀속 조항 한 줄이 빠진 대가로 약 1년의 시간과 1억 4,000만 원이 추가로 소요된 셈입니다.
계약서에 반드시 들어갈 다섯 가지 조항
계약서에 다섯 가지가 반드시 들어가야 합니다. 변경 관리 조항(스코프 변경 시 비용·일정 산정 룰), 소스코드 IP 귀속 조항(발주자/개발사/공동 중 어디인지), 인수 기준(Acceptance Criteria — '납품 완료'가 무엇을 의미하는지 정의), 유지보수 범위와 기간, 분쟁 시 해결 절차(조정·중재 기관과 관할). KOSA의 SW 표준계약서가 출발점이 됩니다.
✓ 계약서에 반드시 있어야 할 5가지
□ 스코프 변경 시 비용·일정 산정 룰
□ 소스코드 IP 귀속 조항
□ 인수 기준 (Acceptance Criteria)
□ 유지보수 범위와 기간
□ 분쟁 시 해결 절차 (조정/중재/관할)
4. 중간 산출물 검토 없이 끝까지 갑니다
Standish Group의 CHAOS Report는 애자일 방식 프로젝트의 성공률을 약 42%, 워터폴 방식을 약 13%로 보고합니다. 차이는 결국 "중간에 보여주고 고치는가"에서 갈립니다. 한국 중소기업 외주 시장은 여전히 워터폴 일괄 납품이 관행이고, 그 관행이 실패율을 구조적으로 끌어올리는 셈입니다.
중간 공유 없는 프로세스가 모두에게 편한 까닭
워터폴식 일괄 납품이 자리잡은 이유는 양쪽 모두에게 편하기 때문입니다. 클라이언트는 매주 시간을 빼서 산출물을 보는 부담을 피하고, 개발사는 중간 검토로 일정이 깨지는 부담을 피합니다. 그러나 Barry Boehm의 Cost of Change 곡선에 따르면 후반부에 발견된 결함의 수정 비용은 초기 수정 비용의 10~100배까지 증가합니다. "마지막에 한 번에 보면 되겠지"는 가장 비싼 선택지인 셈입니다.
한 EV 충전 사업자의 운영팀이 충전소 관제 시스템의 동작 화면을 처음 본 것은, 4개월 일정의 마지막 데모 자리였습니다. 그 전 3개월 동안 진척은 PDF 보고서로만 받아 왔고, 처음 화면을 마주한 그 순간 "이 흐름은 우리가 충전기 장애를 처리하는 순서와 거꾸로 되어 있다"는 지적이 나왔습니다. 결과적으로 모니터링·알림·복구 지시 순서가 운영 매뉴얼과 어긋나 있었던 것입니다. 핵심 화면 5개를 다시 그리는 과정에서 일정이 6주 더 늘어났고, 비용은 약 2,400만 원이 추가됐습니다. 이후 v2 개편 단계에서 가장 먼저 바꾼 것은 화면이 아니라 검토 일정이었습니다. 첫 데모를 1주 만에 잡았다는 점이 이 사례의 가장 분명한 교훈으로 남았습니다.
스프린트 데모와 단계별 부분 인수
해법은 "끝까지 가지 않는 것"입니다. 2~3주 단위 스프린트 데모를 계약 단계에서 잡고, 매 스프린트 끝에 동작하는 화면을 직접 봅니다. 단계마다 부분 인수를 거치면 서면 피드백과 승인 이력이 자연스럽게 쌓입니다. 여기에 서면 피드백 루프를 합의해 두는 것 — 구두 의견을 문서로 정리하는 책임자가 누구인지 명시하는 것 — 까지 더해지면, 최종 데모에서 전면 재작업이 발생하는 시나리오는 거의 차단됩니다.
✓ 프로젝트 시작 시 합의할 3가지
□ 스프린트 길이와 데모 일정이 계약서에 있는가?
□ 단계별 부분 인수가 명시되어 있는가?
□ 서면 피드백 양식과 응답 기한이 정해져 있는가?
5. 개발자가 여러 프로젝트를 병행합니다
국내 중소 SW 개발사에서 개발자 1인이 동시에 참여하는 프로젝트는 평균 2~3개로 파악됩니다. Gerald Weinberg의 컨텍스트 스위칭 연구에 따르면 2개 이상 병행 시 개인 생산성이 20~40% 감소하고, 3개 이상이면 60% 이상 감소하는 것으로 알려져 있습니다. 응답이 느린 외주 개발자는 게으른 것이 아니라, 구조적으로 그렇게 되어 있는 셈입니다.
대응 지연은 일시적 병목이 아니라 구조적 결함
개발사 수익 구조상 개발자 1인의 시간을 여러 프로젝트에 쪼개야 매출이 나오는 경우가 많고, 그 결과 1인이 2~4개 프로젝트에 동시 투입되는 모델이 일반화됐습니다. 컨텍스트 스위칭 비용은 이 구조의 부산물입니다. 한 프로젝트에서 다른 프로젝트로 전환할 때마다 집중도를 회복하는 데 시간이 걸리는데, 회복 전에 다음 전환이 옵니다.
슬랙 메시지에 답이 오는 데 평균 이틀, 코드 리뷰 응답은 5일까지 늦어지는 외주 일정이 있었습니다. 한 의료 IT 스타트업이 4개월 일정으로 발주한 병원 진료 예약 앱이었는데, 일정 만회를 위한 백업 외주 의뢰가 들어와 들여다보니 담당 개발자가 동시에 다른 두 프로젝트에 투입된 상태였습니다. 일정은 6개월로 늘어났고, 그 두 달 사이에 경쟁사가 유사 기능의 앱을 먼저 출시했습니다. 시장 진입 타이밍을 놓친 비용은 인건비 추가분보다 훨씬 컸습니다. 개발자 개인의 문제가 아니라 한 사람이 세 프로젝트를 병행하는 모델 자체가 응답 지연을 구조적으로 만들어내고 있었던 것입니다.
1인 1프로젝트가 가장 확실한 보험
견적 단계에서 가장 먼저 확인할 것은 "개발자 전담 여부"를 계약서에 명시할 수 있는지입니다. 1인 1프로젝트인지 다중 병행인지를 글로 남기고 그 위에 개발자 가용성을 주간 보고로 받기로 합의하면, 이번 주 우리 프로젝트에 몇 시간이 투입됐는지를 숫자로 보게 됩니다. 그러나 가장 확실한 보험은 1인 1프로젝트 모델로 운영하는 개발사를 우선 선택하는 것입니다. 이 모델은 비용이 더 들 수 있는 대신, 일정과 품질의 안정성으로 그 차이를 회수합니다.
✓ 견적 단계에서 확인할 3가지
□ 우리 프로젝트에 투입되는 개발자가 다른 프로젝트와 병행하는가?
□ 주간 가용 시간이 주간 보고로 제공되는가?
□ 1인 1프로젝트 전담 모델로 계약 가능한가?
6. 단일한 소통 채널과 응답 시간이 정해지지 않았습니다
PMI의 글로벌 조사에서 비효율적 커뮤니케이션을 프로젝트 실패의 주요 원인으로 꼽은 비율은 약 28%로 집계됐습니다(Pulse of the Profession 2023). 한국 외주 시장에서는 이 문제가 한층 더 심한 편입니다. 카톡과 이메일과 전화가 섞여 있고, 응답 시간 약속(SLA)이 어디에도 없기 때문입니다.
채널이 흩어지면 논의와 의사결정도 흩어집니다
채널이 분산되면 의사결정이 어디에서 났는지 추적이 안 됩니다. 누군가는 카톡으로 합의했다고 기억하고, 누군가는 이메일로 보낸 다른 안을 기억합니다. 응답 시간 약속이 없으면 "메시지를 보낸 다음 언제까지 답이 올지"가 매번 모호하고, 주간 정기 미팅이 없으면 의사결정이 미뤄지는 것이 기본 상태가 됩니다. 결과적으로 "그거 말씀드렸는데요"와 "메일에서 못 봤는데요"가 반복되는 시간 낭비 구조가 만들어집니다.
100여 개 가맹점을 둔 한 외식 프랜차이즈 본사는, 매장 관리 시스템을 외주하면서 의사결정을 카톡 단톡방·이메일·본사 PM과의 전화 통화에 분산해 진행했습니다. 운영 자문 자리에서 그 기록을 정리해 보니, 같은 결정 사항을 두 번 합의한 일이 4번 발생했고 그중 두 번은 서로 다른 결론으로 합의되어 있었습니다. 가맹비 정산 주기와 메뉴 등록 절차에 대한 결정이 채널마다 어긋난 채로 남아 있었던 것입니다. 누구의 합의가 유효한지를 다시 회의로 정리하면서 일정이 2주 늘어났고, 그 사이 신규 가맹점 12곳의 시스템 도입이 미뤄졌습니다. 채널 분산이 만든 손실은 결국 본사의 가맹 확장 일정에 직접 도달하게 되었습니다.
킥오프에서 채널과 응답 시간을 합의한다
킥오프 미팅에서 합의할 것은 결국 채널과 시간입니다. 단일 메인 채널을 정해 의사결정이 한 곳에서만 기록되도록 하고, 응답 SLA를 시간 단위로 약속해 두는 것이 출발점이 됩니다. "영업일 4시간 내 1차 응답" 같은 명확한 기준이 좋습니다. 여기에 주간 정기 미팅을 고정 슬롯으로 잡아 두면("매주 화요일 11시"처럼 단일 시간대를 기준으로) 의사결정 누적이 한 자리에서 정리됩니다. 단순하면서도 기본적인 사항이지만, 사전에 협의되지 않은 채 프로젝트가 시작될 경우 책임의 방기와 중복된 요청이 발생할 여지가 매우 커집니다.
✓ 킥오프 미팅에서 합의할 3가지
□ 의사결정은 어느 채널에 기록되는가?
□ 응답 SLA(영업일 시간)는 몇 시간인가?
□ 주간 정기 미팅 시간이 고정되어 있는가?
7. 유지보수 계획 없이 출시합니다
소프트웨어 시스템의 총 생애 비용 중 유지보수가 차지하는 비율은 60~80%로 알려져 있습니다. NIPA의 SW 유지보수 비용 산정 가이드에서도 같은 범위가 인용되고, 국내 공공 SW 사업 원가 산정 기준에도 비슷한 비율이 명시되어 있습니다. 그런 점에서 소프트웨어의 출시는 종료점이 아니라 비용의 시작점을 의미하기도 합니다. 반대로, 그 계획 없이 출시하면 비용 전체가 예상치 못한 일들로 늘어날 수밖에 없습니다.
출시는 종료점이 아니라 비용의 시작점입니다
"출시가 종료점"이라는 불명확한 인식이 가장 흔한 함정입니다. 인수인계 문서 없이 출시하면 첫 번째 버그가 즉시 분쟁으로 번집니다. 무상 유지보수 기간이 계약서에 명시되지 않았다면 개발사는 추가 비용을 청구하고, 발주자는 "이건 처음부터 잘못된 코드"라고 주장하게 됩니다. 양쪽 다 다음 작업이 멈추고, 결국 다른 개발사를 찾거나 시스템을 폐기하는 경로로 빠지곤 합니다.
출시 2주 후 결제 모듈이 멈춘 디지털 구독 플랫폼이 있었습니다. PG사와의 결제 검증 응답을 처리하는 로직에 결함이 있었지만, 정작 더 큰 문제는 기존 개발사 연락이 지연됐다는 점이었습니다. 7일 동안 결제 불가 상태가 이어졌고, 그 기간 신규 구독 가입이 멈추면서 약 2,300건의 가입 기회가 사라졌습니다. 응급 패치 의뢰가 들어와 들여다보니, 무상 유지보수 기간이 계약서에 명시되어 있지 않았고 인수인계 문서도(아키텍처 다이어그램, 환경 변수 목록, 배포 매뉴얼) 한 장 남아 있지 않은 상태였던 것입니다. 코드 분석을 시작하는 데에만 5일이라는 시간이 더 소요되었습니다.
출시 전에 받아야 할 인수인계 5종
출시 전에 인수해야 할 묶음은 다음 다섯 가지입니다. 시스템 아키텍처 다이어그램, 환경별 배포·운영 매뉴얼, 계정·API 키·도메인 권한 인계, 무상 유지보수 기간과 SLA 명시, 유지보수 종료 후 전환 시나리오. 1년 무상 유지보수와 인수인계 패키지를 기본 제공하는 개발사를 우선 선택하면, 이 다섯 가지가 별도의 추가적인 협상 없이 자동으로 들어옵니다.
✓ 출시 전 인수인계 5종 세트
□ 시스템 아키텍처 다이어그램
□ 환경별 배포·운영 매뉴얼
□ 계정·API 키·도메인 권한 인계
□ 무상 유지보수 기간과 SLA 명시
□ 유지보수 종료 후 전환 시나리오
※ 외주 개발사에게 자주 묻는 질문들
끝으로, 외주 개발사에게 많이 들어오는 질문들 중 가장 공통적인 문의사항들을 간추려서 공유드립니다. 계약에 앞서 조금 더 면밀하게 외주 계약에 대한 변수들을 살펴봄으로써 조금 더 안정적인 개발의 토대를 쌓아나가시길 바랍니다.
Q1. 외주 개발 성공률은 얼마나 됩니까?
세계적으로도 외주 IT 프로젝트가 예산·일정·기능 목표를 모두 달성하는 비율은 30~35% 수준으로 보고됩니다(Standish CHAOS 2020). 나머지는 예산·일정 초과 또는 목표 미달로 종료됩니다. 한국 중소기업 환경에서는 디스커버리·PM 부재가 구조적이라 이 비율이 더 낮을 가능성이 큽니다. 성공률을 높이는 길은 외주 자체를 피하는 것이 아니라, 위 7가지 실패 원인을 사전에 차단하는 것입니다.
Q2. 외주 개발 실패 시 환불받을 수 있습니까?
환불 가능 여부는 계약서에 달려 있습니다. 핵심은 "납품 완료 기준"이 계약서에 명시되어 있는지입니다. 인수 기준(Acceptance Criteria)이 명문화되어 있으면 분쟁 시 환불·손해배상 청구가 가능하지만, 기준이 없으면 양측 주장이 평행선을 달리게 됩니다. KOSA의 SW 표준계약서나 정부 고시 양식을 사용하면 분쟁 해결 기간도 단축되는 것으로 보고됩니다.
Q3. 외주 개발사를 중간에 바꿀 수 있습니까?
개발사를 중간에 교체하려면 두 가지가 선행되어야 합니다. 소스코드 IP가 발주자에게 귀속된다는 계약 조항, 그리고 단계별 산출물(설계 문서·코드)의 중간 인수 이력입니다. 이 두 가지가 없으면 중간 교체는 사실상 처음부터 다시 시작입니다. IP 조항이 없는 계약에서는 중도 해지 시 소스코드 인계 거부 분쟁이 자주 발생합니다.
Q4. MVP를 외주로 만드는 게 맞습니까?
외주 MVP는 "빠르게 만든다"는 의미가 아니라, 기능 범위 정의가 더 엄격해야 한다는 의미입니다. 핵심 사용자 흐름 3개 이하, 와이어프레임 완성 후 착수가 외주 MVP 성공의 기본 조건입니다. "MVP니까 일단 만들어보자"로 시작하면 1번 실패 원인(요구사항 모호)이 그대로 재현됩니다. MVP는 작은 프로젝트가 아니라, 작은 기능 범위를 명확히 정의한 프로젝트입니다.
Share article