최적의 외주 개발사를 찾기 위한 비결
나만의 앱, 혹은 서비스를 개발해야 할 때 외주 개발사를 찾아보게 되죠. 빠르고 간편하면서도, 동시에 비용도 저렴한 개발을 모두 원하지만, 과연 어떻게 ‘좋은 외주 개발사’를 알아볼 수 있을까요. 대부분의 외주 개발사들이 ‘역량 있는 개발사’를 자처하며 포트폴리오로 그것을 진열하는 상황에서, 어떻게 나의 필요에 맞는 ‘좋은 외주 개발사’를 발견해서 함께 협업까지 이어갈 수 있을지, 본 아티클을 통해 살펴보도록 하겠습니다.
무조건 피해야 할 외주 개발사
먼저, 좋은 외주 개발사의 요건에 대해 먼저 살펴보도록 하겠습니다. 좋은 외주 개발란 어떤 개발사일까요. 어떤 역량을 가진 외주 개발사가 좋은 외주 개발사인지는 각자의 관점과 경험에 따라 우선순위가 천차만별일 수 있죠. 때문에 ‘좋은 외주 개발사’의 요건에 앞서, 반대로 어떤 외주 개발사를 기피해야 할지부터 살펴보도록 하겠습니다.
가장 대표적인 케이스로, 개발 기간이 너무 지체되는 경우를 꼽을 수 있습니다. 약속된 기간을 6개월, 1년 넘기면서 외주개발이 진행되고, 그에 따라 비용도 비례하여 상승하게 됩니다.
결과론적인 이야기이긴 하지만, 결과물에 수정해야 할 오류가 너무 많은 경우 이는 역량 있는 개발사라 보기 어렵겠죠. 대개 이런 경우 QA 과정에서 발견한 많은 버그들에 대해 수정 요청하지만, 그 버그 처리 각각에 수반되는 소요시간마저도 긴 경우가 많습니다. 물론, 제품 개발을 진행하면서 이슈 없는 개발은 불가능에 가깝다지만 지나치게 많은 버그와 오류들은 외주 개발사의 역량과 직결된다는 점에서 협업의 지속성을 고려해야 합니다.
오류와 별개로, 결과물의 퀄리티가 너무 낮은 경우도 외주 개발사의 역량을 가늠해볼 수 있는 요소입니다. 대개 이런 경우, (추가 비용을 들여서라도) 외주 개발사에 기간을 연장해주며 퀄리티의 개선을 요청하지만, 당초 원하던 결과물의 수준까지 도달하지 못하는 경우가 많습니다.
제품 개발 완료 후, 제대로 된 유지 보수가 이루어지지 않는 경우도 꽤나 빈번하게 발생하는 문제 중 하나입니다. 개발 완료 후 보통 3개월 정도의 시간이 소요되면서 AS기간이 종료되지만 여전히 유지와 보수 인력이 필요한 상황에 직면하게 되거나, 심지어 추가 개발이 필요한 경우도 발생합니다. 개발의 연결성을 위해서 어쩔 수 없이 추가 비용을 들여야 하는 상황이 펼쳐질 수밖에 없죠.
가장 최악의 경우로, 외주 개발사가 당초 예상했던 인력 투입 대비 수익성이 나오지 않거나 내부 사정을 이유로 중도 포기하는 경우도 발생합니다. 시간은 충분히 지난 상황이라 계약금을 반환받더라도 클라이언트 입장에서는 그 기간만큼의 시간과 노력을 이미 쓴 셈이라 제품의 실패로 이어질 수 밖에 없죠.
외주 개발에서 실패가 발생하는 이유
이러한 외주 개발의 실패는 왜 발생하게 될까요? 그 원인이 오로지 외주 개발사에게만 있을까요? 가장 주요한 원인은 최악의 외주 개발사를 거르지 못하고 계약까지 진행하게 된 자신에게 있습니다. 그에 따른 피해도 클라이언트 본인이 고스란히 떠안게 되는 만큼, 책임에서 자유로울 수 없습니다. 외주 개발을 실패하신 경험이 있다면, 혹은 외주 개발사를 탐색하고 알아보고 있다면 아래 일곱 가지의 질문들을 스스로에게 던져보시기 바랍니다. 명확한 답이 나오지 않는다면 바라지 않는 결과물에 대한 책임을 각오해야 될지도 모릅니다.
외주 개발사 선정외주사 선정 시 나름의 검증과정을 거치셨나요? 혹시, 주변의 추천이나 광고를 보고 선택하신 건 아닌가요?
창업 아이템이나 전체적인 서비스 기획에 대해 외주 개발사에게 선명하게 설명할 수 있는 문서와 만반의 준비가 되셨나요?
개발 난이도와 기간에 따른 합리적인 비용을 책정하셨나요? 제품 런칭일에 맞춰 무리한 개발 기간을 설정하시진 않았나요?
외주 개발사가 사용하는 기술이 본인의 서비스에 적합한 지 검증하셨나요? 외주 개발사의 주장을 별다른 검토 없이 수용하시진 않았나요? 기술에 대한 명확한 이해 없이 그저 작동 여부에만 신경 쓰고 있진 않으신가요?
외주 개발사로부터 개발 완료 후 결과물을 검증하는 내부 프로세스는 고민하셨나요? 테스트 기간에서부터 적절한 장비, 오류 발생 시 개선까지의 일정을 감안하고 계신가요?
외주 개발사와 개발 과정에서 의사소통 빈도와 주기, 작업범위에 대해 명확히 의사소통하고 설정하셨나요?
개발 완료 후 유지 보수 방식과 기간은 생각해 보셨나요?
좋은 외주 개발사와의 협업에 앞서 필요한 자세
외주 개발사를 선정하기 전 살펴봐야 할 요소부터 외주 개발사와 개발을 진행하는 초반부터 협의해야 하는 지점들, 개발이 완료될 무렵부터 본격적으로 시작될 서비스를 검증하는 과정에서의 주안점과 완전하게 개발이 완료된 이후 유지 및 보수를 위한 협의점들까지, 좋은 외주 개발사를 알아보고 발견하기 전부터 클라이언트에게 필요한 역량과 나름의 과정을 살펴보도록 하겠습니다.
외주 개발사 선정에 앞서 적합한 개발 기술의 선정
외주 개발사마다 대개 자신만의 기술 Stack을 갖고 있습니다. Flutter 외주를 수행 한다고 하여 Flutter를 전문적으로 다루는 기업이라는 것은 아니라는 의미입니다. 주 기술은 React이고 Flutter를 보조로 사용하는 기업에서 Flutter 의뢰를 받을 수도 있습니다. 기술을 잘 모르는 입장에서는 결과적으로 기능만 하면 앱이 완성만 되기에 개별적인 기술에 대한 부분은 무시하고 넘어가기 쉽습니다. 외주개발사 입장에서는 자신들의 주 기술은 성장시키고 발전시키지만 보조기술은 크게 투자하지 않는 경우가 많죠. 그러나 개발이란 분야는 개발자 개인의 능력도 중요하지만 누적된 아카이브와 경험이 중요합니다. 따라서 외주 개발사에서 내 제품과 앱에 적용하는 기술에 어느 정도의 전문성을 가지고 다각도로 검토하는지 알아볼 필요가 있습니다.
외주개발사가 사용하는 기술이 본인의 회사가 추구하는 기술일 때가 가장 이상적인 조합이자 협업입니다. 외주개발에 6개월에서부터 1년 정도의 기간이 소요되지만 해당 앱의 생존주기는 어떨까요? 대부분 3년~5년이라는 게 현실입니다. 따라서 개발이 완료된 시점에서 유지 및 보수 기간이 끝난 이후부터 회사에서 직접 앱을 운영하고 유지보수까지도 전문성 있게 담당해야 합니다. 당연하게도 앱 개발에 사용된 기술을 학습해야하기 때문에, 앱 개발 기술에 대한 검토는 단지 앱 개발만에 그치는 일이 아닌, 기업의 미래를 결정하는 기술을 선정하는 것이기도 합니다.
외주 개발사는 결과물이 완성된 이후부터 큰 노력을 들이지 않는 경우가 많죠. 따라서 유지 보수 기간 이후의 상황을 고려한다면, 내부 개발자를 채용해서 서비스를 운영하는 상황도 고려해야 합니다. 외주 개발사의 주장대로, 먄약 희귀한 개발 언어로 앱 개발을 진행할 경우, 개발 완료 이후 기업 자체적으로 운영하기에 어려움이 따를 수밖에 없습니다.
내 서비스와 맞는 기술인지 고려해야 합니다. 클라이언트 입장에서는 web 서비스를 생각하는데 Flutter를 선택하는게 과연 적절할까요? 모바일 서비스를 만드는데 파이썬을 선택하는 선택이 괜찮을까요? Flutter란 기술을 선택했는데 Native의 결과물을 상상하면 안 되듯, 자사의 서비스의 특성에 맞는 기술을 선택해야 합니다.
기술선정에 관련해서는 외주개발사의 의견을 너무 신뢰하지 마세요. 외주개발사는 자신들이 보유한 기술의 가치를 더 높게 생각하고 표현합니다. Web 서비스를 만들고자 하는 의뢰인에게 Flutter 외주개발사는 Flutter의 Web개발 능력에 대해 과장되게 포장하기 마련입니다. 하나의 앱을 만들고 구현할 수 있는 기술에는 다양한 방법론이 존재합니다. 그중 의뢰하는 기업의 서비스에 적합한 기술을 선택해야 합니다. 고민하고 선택하는 역할까지 외주를 맡기는 것이 아니라, 기업을 운영하는 입장에서 스스로 생각하고 판단해야 합니다. 외주 개발사를 선정하고 해당 외주사가 할 줄 아는 기술을 따라가는게 아니라, 먼저 적합한 기술을 선정하고 해당 기술을 잘 다루는 외주사를 선정하는 방식이 더 안전할 수밖에 없죠.
외주 개발사와의 의사소통 방식
클라이언트의 기대와 외주 개발사의 목표 사이에는 꽤 큰 간극이 있는 경우가 많습니다. 아무리 열심히 소통을 하더라도 이 두 간극이 좁혀지기는 쉽지 않죠. 그럼에도 끊임없이 이 차이를 좁히기 위해 노력해야 합니다. 누가 더 성심성의 있는 노력을 기울여야 하냐면, 대체적으로 클라이언트가 해야 하죠. 개발 범위와 기간, 결과물의 퀄리티와 결과물의 범위에 대해 구체적으로 문서화해서 커뮤니케이션 해야 합니다. 이 모든 중간 과정마저도 외주 개발사에게 맡겨두고 최종 결과물을 기대한다면, 그 기대와 꽤 차이 나는 결과물이 나올 수 있습니다. 뒤늦게 이슈를 제기한다한들, 드라마틱하게 결과물이 기대치로 끌어올리기는 이미 늦은 경우가 대부분입니다.
하나의 예시로, 서비스에 접속한 방문자를 위한 ‘로그인’ 버튼을 만든다고 해보겠습니다. 이를 개발자가 구현하는 데에는 어마어마하게 많은 선택지가 존재합니다. 외주 개발사 입장에서 이에 대해 별도의 언급이 없을 경우, 어떻게 로그인 버튼을 만들까요? 기존에 해왔던 방식대로 개발할 확률이 높죠. 그러나 변면 클라이언트, 혹은 기업은 어떤 기대를 하고 있을까요? 일반적인 로그인 방식을 넘어 네이버나 카카오, 구글을 통한 로그인 방식을 기대할 수 있습니다. 이에 대해 처음부터 정확히 적시하고 명시하지 않으면, 물 흐르듯 진행되는 개발 과정에서 적절한 타이밍을 놓치게 될 수밖에 없습니다.
물론, 외주 개발사와 클라이언트의 인식을 정확히 일치시키는 건 불가능에 가깝습니다. 근본적으로 서비스를 바라보는 시각과 입장에서 차이가 존재하기 때문입니다. 그렇기 때문에 그 간극을 좁히기 위해 애초부터 기대와 요청사항, 희망사항을 문서 및 서비스에 대한 개괄적이면서도 구체적인 스토리보드를 만들어야 합니다. 물론, 분쟁이 발생했을 때 시시비비를 가리기 위한 목적으로도 활용될 수 있지만, 주된 목적은 분쟁을 대비한 문서화의 관점이 아닙니다. 외주 개발사와의 협업을 통해 성공적인 서비스를 개발하기 위한 관점입니다. 휘발되어 사라지는 말보다는 기록으로 남는 문서로 만들고, 이를 기반으로 서로 소통해야 합니다.
개발 완료 이후 QA에 임하는 자세
외주 개발사의 작업이 완료된 후의 일에 대해 생각해보도록 하죠.
지난한 과정과 각고의 노력 끝에 앱 개발이 드디어 완료되었습니다. 해당 앱이 정상적으로 기능하고 작동하는지 누가 확인할까요? 물론, 개발을 한 외주 개발사가 당연히 QA도 수행하게 되지만 실제 그 안에서 예기치 못한 이슈나 오류가 발생할지는 개발을 의뢰한 기업 내부에서 주도적으로 파악해야 합니다. 외주개발사도 정상동작에 대해 점검을 하지만, 아주 세밀하고 적극적으로 하지 않는 경우가 많죠. 왜나하면 버그나 이슈가 발견되면 본인들이 직접 시간과 노력을 들여 수정해야 하니까요. 만약, 외주 개발사임에도 앱 테스트를 적극적이고 상세하게 하는 업체가 있다면 앞으로 계속 같이 협업해야 하는 개발사로 생각하셔도 좋습니다. 외주 개발임에도 ‘자신의 서비스’처럼 대한다는 말과 상통할테니 말입니다.
때문에 업무에 대한 책임 범위를 따진다면 외주개발사가 앱 테스트를 하게 되지만, 주체적인 시각과 앞으로 운영하는 주체가 되는 기업이 직접 앱 테스트를 진행하는 것이 안전합니다. 그리고 이슈 및 오류 리포트를 만들어 외주 개발사에 보내는 한편, 수정에 따른 기한을 명시하여 오류들을 다 잡아내야겠죠. 외주개발사는 발견된 버그만 수정하게 됩니다. 그 너머 존재하는, 혹은 발생할지 모를 미지의 가능성까지 모두 감안해주는 경우는 많지 않죠. 때문에 이 과정에서 주도 면밀한 테스트를 하면서 대부분의 오류를 다 잡아내 수정을 요청해야 합니다.
외주 개발 완료 후 유지 및 보수 협의
개발 완료 이후 유지 및 보수 기간과 과정에 대해서 정확히 명시하지 않은 채 개발을 진행하는 경우가 있습니다. 그러나 개발 완료 시점부터 어느 범위까지, 또 어느 기간동안 수행해 줄 수 있는지 확인해야 합니다. 비용을 들여서라도 유지 및 보수를 수행해 줄 업체가 있다는 건 그 자체로 장점이 될 수 있습니다. 유지 보수에 대해 미지의 영역으로 남겨두지 않고, 계약서에 기간과 범위에 대해 확실하게 명시한다는 마음으로 외주개발사와 명확한 의사소통을 할 필요가 있습니다. 경우에 따라, 외주 개발사가 유지보수를 보장하지 않을 수도 있습니다. 그럼에도 이 부분을 명확히 해야 하는 이유는 클라이언트와 외주 개발사의 합의점을 일치시키기 위함입니다.
IT 서비스에서 초기 개발비용과 유지보수 비용을 비교할 때면, 대부분 유지보수 쪽에 비용이 더 많이 소요됩니다. 물론 어느 범위까지를 유지보수로 생각하느냐에 따라 비용 구분이 달라질 수는 있겠죠. 그러나 초기 개발은 (길어 봐야 최대) 1년 정도의 시간이 걸리는 반면, 유지보수는 대개 서비스를 지속하는 동안, 그러니까 최소 3년에서 5년 동안 진행해야 하기 때문이죠. 그렇다면, 초기개발과 유지보수 중에 무엇이 더 중요할까요? 비용적인 관점에서 바라본다면, 유지 보수가 중요성을 간과하지 말아야 합니다. 서비스 런칭 후 지속적인 운영을 해야 하는 주체 또한 기업 내부라는 점을 감안한다면 명확하게 소통해야 하죠.
외주개발업체는 초기 개발이 끝나면 대개 유지 보수를 수행하는 데 미온적인 경우가 많습니다. 만약 적극적인 유지 보수를 명시한다면 금액이 상승할 수도 있죠. 클라이언트 입장에서 다른 선택지는 있을까요? 초기 개발업체에 유지보수를 맡기는 것보다 더 저렴하게 진행할 방법은 없습니다. 물론 저렴한 외주 업체와 유지 보수 계약을 진행하는 것이 정답은 아닙니다. 때문에 외주 개발사와 소통하면서 개발 완료 이후의 일도 함께 논의하는 것이 제일 좋은 방안입니다.
좋은 외주 개발사 전에 ‘좋은 클라이언트’부터
당연한 이야기겠지만, 앞서 언급한 여러가지 사항과 이슈에 매끄럽고 빠르게 대응하는 외주 개발사는 분명 존재합니다. 다만, 많은 수요와 적은 공급의 환경 속에서 그 비용이 결코 저렴하지 않을 수 있습니다. 비용이 저렴할 수 있는 이유는 기능 구현을 적은 노력과 시간으로 최대한 단순하게 개발하기 때문입니다. 구현이 단순해지면 개발이 빨라지지만 여러 사항을 고려할 수 없죠.
물론 비용의 정도와 외주 개발의 성공과 실패는 그 상관 관계가 크지 않습니다. 높은 비용을 들였다고 해서 개발의 성공 확률을 높이는 것도 아니고, 비용이 적다하도 서비스는 충분히 성공할 수 있죠. 비용 자체가 개발의 성공 실패를 가르지는 않습니다. 다만, 저렴한 비용 안에서 외주 개발사, 혹은 서비스의 기능 구현에 무리하거나 과대한 기대와 요구를 하는 경우는 없어야겠죠. 아는만큼 보이고, 보이는만큼 외주 개발사와의 더 효과적인 협업이 가능한만큼, 무엇보다 ‘좋은 클라이언트’인지부터 점검하며 부족한 점을 보완해 나가길 바랍니다.
