외주 개발이 실패하는 가장 큰 이유와 원인

누구나 자신있게 시작하는 외주 개발, 그러나 결과는 처참하게 이어지는 경우가 많죠. 실패로 가는 과정과 이유를 살펴봅니다.
Dec 09, 2024
외주 개발이 실패하는 가장 큰 이유와 원인

외주 개발로 프로젝트를 진행하시다가 실패해보신 경험이 있으신가요?

성공적인 프로젝트를 정의하는 요소는 직관적이고 명료할 때가 많습니다. 그러나 외주 개발 실패로 가는 길은 너무나도 다양하고 모호하며 뚜렷한 몇 가지로 좁히기가 어려울 때가 많죠. 어느 하나로 원인을 돌리기에 애매한 그 길은 경험해보지 않고선 알 길이 없습니다. 빠져나오려 발버둥칠수록 더욱 더 큰 수렁에 빠지는 듯한 기분을 한번이라도 겪어보셨다면 그 암담함에 공감하실 수 있을 겁니다.

그렇다면 외주 개발에서 벌어지는 다양한 실패들은 어떤 양상으로 현실화되고, 그 원인과 이유에 대해 살펴보도록 하겠습니다. 실패의 원인을 규명하고 직시함으로써 그것들을 사전에 경계하고 피할 수 있는 방법을 짚어보도록 하죠.

외주 개발에서의 실패 요인

1. 일정 관리의 실패

외주 개발사와의 가장 대표적인 협업 실패는 정해진 기한을 엄수하지 못하고 일정이 지연되는 경우입니다. 결론적으로 기한 내에 개발이 완료되기 어려운 가장 대표적인 이유는 바로 명확한 기획의도 및 개발에 대한 기본적인 개념이 없는 상태로, 단순 “아이디어” 하나로 외주 개발을 의뢰하기 때문입니다.

가장 흔한 사례는, 시장의 트렌드에 편승한 사업 아이템에 기반하는 경우입니다. 기업이 당초 주력으로 삼고 있던 사업이 아니었음에도 단순히 시장에서의 니즈라는 점에 착안하여 서비스를 개발해 보겠다는 목적성만을 가지고 외주 개발을 진행했지만, 사업에 대한 명확성과 의도의 구체성이 미진한 상태에서 이는 실패로 귀결될 확률이 매우 높습니다. 이 경우 기획의 중요성이 크지만, 창업가(혹은 담당자)는 해당 분야의 전문가도 아니었을뿐더러, 개발에 대한 기초적인 지식도 없는 상황이 대다수입니다. 바라는 상은 있을지 몰라도 그 결과물에 수반되어야 할 다양하고도 구체적인 그림 없이 진행되는 외주 개발에서 의미있는 성과를 이루기가 어렵습니다. 일정은 기약없이 지연되고 비용은 늘어나며 결국 실패로 귀결되게 됩니다.

2. 기획에서의 잦은 변경에 따른 실패

의뢰하는 기업 측에서 기획을 완성시킨 후 개발 단계로 넘어가 개발이 본격적으로 진행되면서 문제가 시작됩니다. 기업 측에서 초기의 기획에서 더 발전되거나 확장된 형태를 원하면서부터죠.

트렌드는 계속 변화하고, 그 변화 속에서 새로운 기능을 추가하길 바라면서, 당초 함께 협의했던 서비스의 상은 끊임없이 변화하게 됩니다. 그나마 개발 초기에 새롭게 정립한다면 다행일지 모르나, 이미 진행된 개발물 안에서 무언가를 더하고 변화시키는 일은 말처럼 쉬운 게 아니라 사실상 새롭게 만드는 일과도 같다는 사실을 기업 측에서 이해하지 못하는 경우가 많죠. 현업에서 중간중간 기획을 변경시키는 일은 사실 매우 흔하게 발생합니다.

외주 개발 기업과의 소통은, 내부 개발만큼 빠르거나 정확하지 않을 수 있습니다. 때문에 사전에 명확한 기획안과 함께 소통 빈도와 밀도를 정의하는 일에서부터 출발해야 합니다.

3. 소통의 실패

외주 개발은 기업 내에서 개발이 이루어지는 내부 개발과 달리 기업 외부에 있는 외주 개발사와의 소통이 기반이 되는 협업 체계죠. 때문에 정확하고 신속한 소통 방식이 전제되지 않는다면 서로가 생각하는 개발 방향에 대해 오해하게 되는 경우가 발생합니다. 영세한 외주 개발사의 경우, 한 담당자가 여러 프로젝트에 동시 다발적으로 투입되는 환경일 수 있기 때문에 소통 오류에 더욱 신경 써야하죠. 이는 기업 내부에서의 담당자도 마찬가지라, 기업 담당자가 되었건, 외주 개발사의 담당 PM이 되었건 소통 오류가 발생하지 않도록 명확한 커뮤니케이션 방식을 사전에 정립해야 합니다. 아무리 역량 있는 개발자를 보유하고 있는 외주 개발업체라도 소통 오류의 늪에 빠진다면 헤어나오기 어려운만큼, 이는 외주개발사와 기업 모두 주의를 기울여야 하는 부분이기도 합니다.

4. QA에서의 검증 실패

앱 혹은 웹서비스는 오류가 항상 존재합니다. 따라서 서비스를 상용화하기 이전에 이에 대한 디버깅 혹은 테스트 과정을 거치는 것이 필수적입니다. 대표적으로 사용하는 네이버, 카카오톡, 인스타그램, 페이스북 등의 서비스들도 모두 개발 단계가 끝난 후, 개발 기간과 맞먹는 기간 혹은 그 이상의 기간 동안 디버깅 혹은 테스트 과정을 거친 후 출시된 서비스들입니다. 이렇게 디버깅 과정을 거쳐 오류를 수백, 수천 번 수정하고 나서 출시했음에도, 오류는 발생할 수 있습니다. 꼭 오류가 발생했을 경우 뿐 아니라, 새로운 웹 브라우저가 출시되거나, 모바일 운영체제가 업데이트될 때면 항상 업데이트 과정을 거치게 됩니다. 해당 운영체제에 맞도록 지속적으로 업그레이드를 거쳐 사용자에게 최적화된 서비스를 제공하는 것이 필수죠.

진정한 의미에서의 개발 완료는, QA 과정을 통해 ‘일어날 수 있는 모든 경우의 수’를 파악하고 그에 따른 수정사항을 모두 반영한 이후를 의미합니다. 그리고 이는, 외주 개발사 뿐만 아니라 기업에서 주도적으로 점검해야 하는 일이기도 하죠.

이처럼 웹 및 모바일 서비스는 출시 후에도 지속적으로 오류를 발견 및 수정하는 과정을 거치는 것이 당연한 단계이나, 많은 클라이언트는 개발이 완료되는 즉시 개발은 거기에서 끝이라고 착각하는 경우가 빈번합니다. 만일 단기간 내에 독창적인 웹서비스를 오류 없이 완성시키고 상용화시킬 수 있다는 외주 개발 업체가 있다면, 기본적인 QA 및 사후 서비스가 전혀 제공되지 않는 외주 개발사인 것은 아닌지 의심해 봐야 합니다. 새롭게 개발하는 웹 혹은 모바일 서비스를 단기간 내에 오류 없이 개발한다는 건 거의 불가능에 가깝기 때문이죠.

그러나 많은 클라이언트들이 초기 기획 시 디버깅에 소요되는 시간을 고려하지 않고 개발을 의뢰합니다. 이처럼 비현실적인 기대와 개발에 대한 이해 부족으로 별도의 테스팅 없이 서비스가 런칭되거나, 혹은 QA 기간에 생각보다 오랜 기간이 걸린다면 높은 품질의 서비스를 기대하기가 어렵게 됩니다. 혹여 개발 완료 후 오류가 빈번하게 발견되는 상황이라면 해당 외주 개발을 통한 결과물에 대한 소비자 만족도는 당연히 떨어질 수밖에 없죠.

외주 개발 실패로 이어지는 과정

1. 기업의 불명확한 기대치와 외주 개발사의 성의없는 결과물 사이의 간극

상호 간의 기대치 불일치는 외주 개발 실패로 가는 주요한 원인으로 꼽힙니다. 기업은 구현하고자 하는 사업적 아이템에 대한 모호한 그림만을 외주 개발사에 전달하고, 외주 개발사는 이에 대해 구체적으로 적시하지 않은 채 적절성에 대한 검토 없이 단순 기능만을 구현하는 데 그치는 경우가 대표적입니다. 이같은 문제는 전체적인 외주 개발 기간이 늘어나는 점으로 표면화되곤 하죠. 구체성 없이 진행된 외주 개발 중에 기능에 대한 범위와 요구사항이 점차 늘어나는 건 필연적입니다. 시간이 더 소요되는만큼 최신 트렌드 또한 주기적으로 계속 바뀌기 때문에 개발 요청사항은 더 늘어나게 됩니다.

2. 비용과 품질 사이의 간극

품질에는 가격이 따르지만, 앱 개발이라는 목표를 눈앞에 둔 많은 기업들 입장에선 품질보다 가격에 치중된 결정을 내리기 쉽습니다. 결과적으로 제품, 혹은 서비스를 개발하기 위해 가장 저렴한 견적(가격)을 제시한 기업에 소프트웨어 개발을 아웃소싱하는 것이 최선의 결과로 이어지는 건 아닙니다. 여전히 많은 외주 개발사들이 가장 저렴한 가격을 내세우며 개발 수주를 따낸 뒤 책임감 없는 자세와 함께 최악의 결과물을 내놓는 경우가 허다하죠.

물론 수익을 기반으로 해야 하는 기업 입장에서 투입 비용을 무시할 순 없죠. 그러나 구현하고자 하는 서비스 및 제품의 난이도와 기간 및 품질에 따라 그에 상응하는 비용은 담보되어야 합니다. 되려 지나치게 낮은 비용은 품질에 대한 담보를 의심해야 하죠. 비용에 앞서 외주 개발사의 포트폴리오를 면밀하게 검토하는 한편, 단순한 포트폴리오 너머 외주 개발사의 평판과 결과물의 퀄리티를 직접 확인하며 검증하는 절차를 거쳐야 합니다. 이 단순한 과정을 무시하게 된다면, 초기 낮은 비용을 훨씬 상회하는 비용을 들여 다른 외주 개발사를 찾아야 할지 모릅니다.

3. 소통의 부재를 통한 간극

소프트웨어 외주 개발에서 가장 큰 과제 중 하나는 프로젝트 내내 커뮤니케이션의 빈도와 밀도를 유지하는 것입니다. 기업과 외주 개발사 간 규칙적이면서도 높은 밀도의 소통은 각자가 생각하고 있는 업무의 과정과 결과에 대한 이해도를 높여줄 수 있는 유일한 도구입니다. 전체 프로젝트 범위를 이해함은 물론, 중간 중간 제품의 개발 상황과 현 위치를 알 수 있으며 예기치 못한 문제와 당면한 과제를 확인할 수 있어야 합니다. 이러한 커뮤니케이션이 부족하게 되면 이해 관계자와 개발자 간의 연결이 끊어져 모호함이 생기고 이 모호함은 이도저도 아닌 결과로 이어질 확률이 매우 높게 됩니다. 아무리 역량 있는 개발자가 있는 외주 개발사라 하더라도, 또한 아무리 사업성과 시의적절한 서비스 기획이 수반될지라도, 이 소통에 간극이 발생하는 경우 높은 품질의 결과로 이어지기는 매우 어렵다는 점에서 외주 개발사와의 커뮤니케이션에 성공의 키가 숨어 있다고 말할 수 있습니다.

대부분의 외주 개발이 실패로 귀결되는 과정에서 ’소통의 부재 및 간극‘이 주요하게 꼽힙니다. 프로젝트를 진행함에 따라 기본적인 절차들을 무시하고 가는 것이 아닌지, 계속해서 점검해 봐야 하는 이유이기도 하죠.

외주 실패에서 얻는 교훈

지금까지 외주 개발 실패가 일어나는 이유와 요소들을 전체적으로 조망해봤을 때, 대부분의 실패는 모호함으로부터 발생함을 알 수 있습니다. 그렇다면 이 모호함을 선명함으로 바꾸기 위해 우린 무엇을 어떻게 해야 할까요. 결론적으로 가장 단순하고 간단한 방법이지만, 프로젝트와 관련된 모든 사항들을 문서화하는 일에서부터 시작해볼 수 있습니다. 앱이나 웹을 통해 구현하고자 하는 기능과 상세 설명, 그에 따라 소비자에게 전달하기 원하는 가치적인 요소에 이르기까지 기업의 입장에서 구현하고자 하는 모든 정보를 담아야 합니다. 그리고 이것을 효과적이고도 효율적이며 압축적으로 잘 담기 위해서 우린 개발 요구사항 정의서를 잘 만들 줄 알아야 하죠.

개발 요구사항 정의서의 중요성

요구사항은 크게 배경과 상세로 구성됩니다. 배경이란 이번 IT 서비스 개발 프로젝트를 기획하고 외주 개발사에 의뢰하게 된 배경을 의미합니다. IT 서비스 제작에 대한 구체적인 요구사항과는 관련이 없지만 외주 개발사가 좋은 서비스를 만들기 위해서 반드시 알고 있어야 할 내용입니다. 배경이 충분히 공유되어야 의뢰자와 외주 개발사 사이의 ‘동상이몽’을 줄일 수 있습니다.

상세 내용은 말 그대로 어떤 서비스가 제작되어야 하는지에 대한 설명에 해당합니다. 보통 사용자 스토리라는 틀을 이용해서 누가 보아도 이해할 수 있도록 쉽게 작성합니다.

배경: 비즈니스와 프로젝트 소개하기

배경은 풍부하고 구체적일수록 좋지만 적어도 아래의 5가지는 외주 개발사와 만나기 전에 미리 고민하시는 것이 좋습니다.

  1. 프로젝트 목표

    이번 IT 프로젝트를 통해 달성하고자 하는 것이 무엇인지 적습니다. 요구사항을 처음 읽는 제작사도 어떤 프로젝트인지 직관적으로 이해할 수 있도록 한두 줄로 목표를 작성해 보세요.

  2. 비즈니스 모델

    보통, 수익을 내는 것이 서비스의 핵심 목표인 만큼 비즈니스 모델은 서비스 기획 시 가장 중요한 고려 사항 중 하나입니다. 서비스 내 모든 수익원을 적어 보세요.

  3. 사용자

    해당 서비스의 사용자를 고민해 보세요. 서비스 분야에 따라서, 고객과 관리자 외에도 운영에 참여하는 다양한 사용자가 있을 수 있습니다.

  4. 핵심 기능

    비즈니스 모델을 구현하고 프로젝트 목표를 달성하기 위해서 필요한 핵심 기능을 적습니다. 비즈니스의 성공을 위해 제작사가 가장 신경 써서 개발해야 하는 기능을 고민해 보세요.

  5. 레퍼런스 서비스

    특정 사용자를 대상으로 하는 서비스의 경우 구두로 설명해서는 정확히 이해가 어려울 수도 있습니다. 하지만 ‘백문이 불여일견’이죠, 제작사가 참고할 서비스를 이미 알고 계신다면 알려주세요. 많게는 몇 시간의 소통을 줄여주기도 합니다. 꼭 유사한 서비스가 아니어도, 유사한 기능을 제공하는 레퍼런스가 있다면 적어 보세요.

기업과 외주 개발사가 논의하는 대부분의 논의는 문서화 되어야 합니다. 문서를 통해 이야기 하고, 문서를 통해 피드백을 해야 하죠. 그렇지 않다면 소통에 있어서의 누락과 오해가 생길 가능성이 매우 높습니다.

상세 내용: 사용자 스토리를 통한 요구사항 정의하기

지금까지 외주 개발사에게 전달할 요구 사항 중 ‘배경’을 준비했으니, 이제 어떤 서비스를 만들고 싶은지 구체적으로 적어볼 차례입니다. 상세 내용은 사용자와 목적, 행위를 모두 포함하는 사용자 스토리를 중심으로 작성하면 됩니다.

사용자 스토리 = 사용자 + 목적 + 행위

사용자 스토리를 쓰는 방법은 매우 간단합니다. 누가, 왜, 무엇을 하는지 적는 것이 전부입니다. 그것을 서비스로 구현하는 것은 외주 개발사의 몫이죠. 다만 사용자 스토리를 최대한 구체적으로, 풍부하게 작성해 두시면 외주 개발사와 짧은 미팅을 진행하고도 제작사가 프로젝트를 제대로 이해하도록 할 수 있습니다.

사용자 스토리는 아주 단순해 보이지만, 의뢰자의 상황과 니즈를 파악할 수 있는 좋은 자료가 됩니다.

지금까지 외주 개발을 의뢰할 때 요구사항을 정의하는 방법을 알아보았습니다. 명확한 요구사항은 정확하고 빠른 견적 산출을 가능하게 하고, 프로젝트 도중에 기획을 변경하는 불상사가 일어날 확률을 낮춰줍니다.

합리적인 외주 개발 비용 산출을 위한 준비

개발 요구사항 정의서와 함께 외주 개발사와 적정한 견적 산정을 위해 준비해야 하는 사항들이 있습니다. 이때 아래 사항에 맞춰 내용을 준비하면 보다 정확하고 합리적인 견적을 얻을 수 있을 뿐만 아니라, 개발사와 원활하게 의사소통할 수 있습니다.

  • 작업 복잡성

    개발 작업의 복잡성은 견적에 큰 영향을 미칩니다. 작업의 규모, 기능의 다양성, 기술적인 난이도 등이 복잡성을 좌우합니다.

  • 개발 시간과 기한

    외주 개발사의 리소스 배분을 위해 개발 작업의 예상 소요 시간과 프로젝트의 기한은 매우 중요합니다. 급하게 요청할 경우 비용이 추가될 수 있으니 최대한 빨리 준비해 의뢰하는 것이 좋습니다.

  • 기술 요구사항

    개발 시 사용하는 스택과 플랫폼도 개발 비용을 결정하는 중요한 요소입니다. 또한 외부 API나 라이브러리 통합 여부도 개발 비용에 반영됩니다.

  • 인력 및 리소스 비용

    개발 프로젝트에는 개발자뿐만 아니라, 디자이너, 테스터 등이 참여합니다. 개발 견적 산정 시에는 프로젝트 종료까지 투입되는 모든 인력의 비용이 포함됩니다. 프로젝트 진행에 필요한 하드웨어나 소프트웨어, 라이선스 등의 비용도 추가됩니다.

  • 추가 요청 사항

    의뢰자가 기본 개발 프로젝트 외에 유지 보수, 기술 지원, 보안 조치 등의 서비스를 요청할 경우 추가 비용이 발생할 수 있습니다.

이번 아티클에서는 외주 개발 실패에 영향을 미치는 요소와 실패로 가는 필연적인 과정, 그리고 실패를 통해 우리는 사전에 무엇을 준비하고 대비해야 할지를 살펴봤습니다. 이를 통해 외주 개발사와의 협업을 앞두고 있는 분들에게 사전에 대비책을 마련할 수 있는 계기를 제공해 드리고자 합니다. 앞서 언급했던 것처럼, 성공적인 프로젝트를 정의하는 요소는 직관적이고 명료할 때가 많습니다. 그러나 외주 개발 실패로 가는 길은 너무나도 다양하고 모호하며 뚜렷한 몇 가지로 좁히기가 어려울 때가 많죠. 어느 하나로 원인을 돌리기에 애매한 그 길 앞에서 실패로 귀결될 지 모를 각각의 방향을 점검해 보시길 권합니다.

Share article
Subscribe to our newsletter

직계약으로 끝까지 책임지는 매칭 플랫폼, 스파르타빌더스