앱 개발을 준비하며 직면했던 가장 큰 난관은 무엇이었나요?
스파르타빌더스는 서비스 개발을 원하는 기업에 맞는, 적합하면서도 책임감 있는 외주 개발 업체를 찾아서 연결합니다. 클라이언트의 요구 조건에 부합하는 소규모 외주 개발 업체들과 제품을 개발하거나, 큰 규모의 제품과 서비스를 개발한 이력이 있는 외주 개발 업체들과의 협업 속에서 느낀 건, 포트폴리오만으로는 해당 기업의 전문성과 적합성을 담보하기 어렵다는 점이었습니다. 큰 프로젝트를 진행한 경험이 있는 업체의 경우, 그에 상응하는 높은 비용이 수반되며 작은 프로젝트들의 성공사례를 내세우는 기업들의 경우 운영적인 면에서의 안정성과 개별 서비스의 지향점에 따른 효과적인 솔루션을 제안할 수 있을지가 미지수였습니다. 성공적인 프로젝트를 위해 어느 누구든 자신의 적합성을 주장할 수밖에 없는 탐색 단계에서, 개발과 유지, 보수 면에서 모두 신뢰할 만한 업체를 알아보기란 결코 쉽지 않습니다.
그렇다면, 서비스 개발을 목표로 하는 대부분의 기업들에서 본격적인 앱 개발 시작에도 대부분이 직면하는 ‘적합한 외주 개발사를 찾는 과정‘과 실제 협업에서 직면하는 어려움의 실체는 어디에서 비롯될까요? 반대로 그 실체와 이유를 명확히 파악한다면, 보다 효과적이고도 효율적인 개발이 가능하지 않을까요? 본 아티클을 통해 앱 개발에 수반되었던 어렴풋한 난관들을 보다 선명히 직시하고 이를 통해 그것들을 타파할 수 있는 나름의 방법을 고민해 보시길 바랍니다.
포트폴리오보다는 앱 개발 프로세스와 협업 방식
기업의 환경과 상황에 따라 내부 개발팀이 존재하기도 하고, 혹은 개발팀 없이 외주 개발로 서비스를 개발해야 할 때가 있습니다. 이는 신규 서비스를 개발해야 하는 신규 기업과 이미 초기 서비스 개발을 진행하면서 내부 리소스의 부족 등의 이슈로 외주 개발을 통한 추가 개발을 목표로 하는 기업으로도 구분됩니다.
먼저 신규 서비스를 개발해야 하는 개인 혹은 기업의 경우 기존 네트워크를 통해 개발팀을 소개받는다거나, 광고를 비롯한 다양한 경로로 개발 관련 비용과 방법을 문의하죠. 그러나 기업이나 개인이 바라는 서비스의 카테고리와 방향성에 맞는 적절한 개발사는 단순히 네트워크와 광고를 통해 가닿기가 쉽지 않습니다. 다양한 개발사들만큼이나 각자 가진 강점과 경쟁력이 명확히 다른 까닭이죠. 그렇기 때문에 대부분의 기업들은 포트폴리오를 통해 개발사가 가진 역량과 경험을 가늠할 수밖에 없습니다. 그러나, 대부분의 개발사에서 제시하는 포트폴리오는 그 시기와 방법이 명확히 특정되지 않은, 단순한 기록으로써 의미를 가지는 경우가 많습니다. 포트폴리오에 기재되었다고 해서, 해당 프로젝트를 성공적으로 수행했다고 예단하기가 어렵기도 하죠. 그렇기 때문에 포트폴리오보다 근본적으로 더 중요한 건, 개발사가 어떤 개발 프로세스와 협업 방식을 채택하고 있는냐에 달려 있습니다.
과정을 신뢰할 수 없다면 원하는 결과값을 얻는 건 요행에 가깝습니다. 반면, 결과에 이르는 과정을 신뢰할 수 있다면, 그에 상응하는 결과물을 기대할 수 있죠. 그렇다면 어떤 개발 프로세스와 협업 방식이 보다 안전하고 신뢰할 수 있을지를 살펴보도록 하겠습니다.
Check Point 1. 앱 개발을 관리하는 담당 PM의 존재 여부
프로젝트를 시작하기 전, 개발팀은 먼저 클라이언트의 기대, 혹은 클라이언트의 조직이 기대하는 바를 수집하게 됩니다. 소프트웨어 개발 프로세스와 다양한 접근 방식을 이해하며 값비싼 실수를 피하는 것이 중요하기 때문입니다. 일반적인 소프트웨어 개발 프로세스에는 다음 단계가 포함됩니다.
요구 사항 수집: 서비스에 수반되는 앱 사용 로직과 플로우를 비롯한 상세한 기능 리스트들을 수집하는 단계
디자인: 아키텍처, 구성 요소, 인터페이스를 포함한 소프트웨어에 대한 청사진을 만드는 단계
구현: 코드를 작성하고 소프트웨어가 예상대로 작동하는지 테스트하는 단계
테스트: 소프트웨어의 버그를 식별하고 수정하는 단계
배포: 소프트웨어를 사용자에게 제공하는 단계
유지 관리: 버그 수정, 새로운 기능 추가, 새로운 운영 체제 및 하드웨어와의 호환성을 유지하기 위한 소프트웨어를 업데이트하는 단계
이러한 전 개발 단계에서 가장 중요한 역할은, 이 모든 과정 속 다층적인 커뮤니케이션의 축이 되는 PM이라고 할 수 있습니다. 그러나 많은 경우, 클라이언트 사에서 PM 역할을 수행할 수 있는 담당자가 부재하죠. 커뮤니케이션을 담당하는 책임자는 존재하겠지만, 단순히 의사결정을 전달하는 통로일 뿐, 개발 언어와 프로세스를 명확히 이해하는 역량은 없는 경우가 대다수입니다. 반대로 담당 PM의 개발 역량이 갖춰진, 그래서 개발사와 효과적으로 커뮤니케이션을 하면서 더 나아가 클라이언트의 요구를 개발 언어화 하고 실무진들과 더 나은 방법을 함께 고민할 수 있다면, 프로젝트가 성공적으로 완수될 수 있는 확률이 비약적으로 높아지게 됩니다.
앱 개발은 완벽을 지향할 뿐, 일반적으로 제작과정에서 수많은 이슈가 발생하게 됩니다. 몇 백 개가 넘는 다양한 난이도의 이슈를 처리해서 서비스를 오픈한다고 해도 문제는 반드시 발생하죠. 운영을 하면 할 수록 이슈는 더 늘어나게 됩니다. 그렇기 때문에 서비스 운영이 목적인 회사는 개발 업체만큼의 이슈를 파악하고 있어야 합니다. 서비스 운영은 개발이슈를 이해하지 못하고는 불가능하기 때문입니다. 그런 의미에서 중요한 것은 개발 그 자체라기보다, 개발에서 런칭, 그리고 이후의 운영에까지의 과정을 얼마나 이해하고 있는지 여부에 달려있다고 해도 과언이 아니죠. 그리고 개발의 시작부터 그 모든 여정을 관리하는 역할이 PM에게 달려있다는 점에서 성공적인 프로젝트의 핵심 요소라고 할 수 있습니다. 개발을 완수하는 단계에서 목표치를 근접한 경우도 많지만, 원했던 목표치를 만족시키지 못하는 경우도 많죠. 그렇기에 PM은 목표치를 재조정하거나 추가, 유지보수에 대한 계획과 일정을 수립하는 역할을 해야 합니다.
물론, 클라이언트의 요청에 따라 담당 PM이 추가될 수도 있겠지만, 해당 PM의 역량을 확인할 수단이 존재하는지 여부와 함께, PM 인력에 따른 ‘외주사의 유지 비용’이 프로젝트 견적에 포함되며 생각보다 큰 비용이 책정되기도 합니다. 프리랜서 외주 개발자 한 명이 PM의 역할까지 담당하는 일반적인 개발 환경을 감안한다면, 이 역시 사전에 면밀히 검토되어야 합니다.
Check Point 2. 앱 개발 과정 속 커뮤니케이션 방식과 빈도
외주 개발의 경우, 진행 과정과 상황에 대해 내부 구성원처럼 시시각각 소통을 하기 힘든 환경일 수밖에 없습니다. 그러나 의뢰한 방식과 기능을 제대로 구현하면서 의도된 바대로 개발이 진행되고 있는지를 확인하며, 채택한 방식에 어떤 이슈가 예상될 지, 또 그것을 해결하기 위해 무엇이 필요한지 등을 빈번하게 소통할 수 있어야 합니다.
보편적인 외주 개발사들의 경우 한 명 또는 한 팀이 동시에 2~3개의 프로젝트에 참여하는 경우가 많습니다. 때문에 클라이언트 각자의 프로젝트에 어느 정도의 시간이 실제로 투입될지 확신하기 어려울 때가 많죠. 물론, 순조롭게 개발이 진행될 땐 문제 될 여지가 전혀 없지만, 도처에서 발생하는 이슈사항들이 하나 둘 제기되면서 대응 속도에 차이가 나게 됩니다. 몇 건의 프로젝트를 동시 다발적으로 진행하는 현실 속에서 아무리 이슈가 급하다고 해도 해결하기까지 시간이 걸릴 수밖에 없으며, 동시에 커뮤니케이션의 밀도와 빈도가 낮아지게 됩니다.
때문에 개발을 시작하기 전부터 커뮤니케이션 빈도와 밀도에 대해 명확히 정의할 필요가 있습니다. 프로젝트를 이제 막 시작하는 단계에선 빈도를 짧게 나눠 여러 번의 미팅을 진행한다면, 양 사가 서로의 지향점과 방향성을 더 잘 이해할 수 있고, 또 이를 통해 개발 초기 단계에서 발생할 수 있는 미스커뮤니케이션의 가능성을 억제할 수 있습니다. 개발사 입장에서는 고객사의 요구 조건을 조금 더 면밀히 검토하며 해당 요구 조건에 수반되는 기능적 피드백을 제공할 수도 있죠.
커뮤니케이션 방식은 미팅의 목적에 따른 빈도를 정의하고 각 미팅에 수반되는 프로토콜을 명확히 수립함으로써, 단순 문의부터 변경 사항 요청, 이슈 보고 등을 미팅에 앞서 사전에 서로 공유합니다. 프로젝트의 시작 전, 의도와 목적에 따라 미팅의 성격을 세부적으로 정의하며 미팅의 주기를 설정할 필요가 있습니다.
정기 보고 미팅: 개발 요구사항을 세밀하게 정의해야 하는 개발 초기에는 주간으로, 개발 작업이 안정화 되면서 월간으로 프로젝트 진행 상황을 문서화하여 공유합니다.
스탠드업 미팅: 정기 보고 미팅 외에도 필요에 따라 짧은 일일 미팅을 통해 진행 상황과 이슈를 공유합니다.
또한, 피드백 루프를 구축하며 각각의 개발 단계마다 피드백을 수집, 수정 사항을 요청할 수 있도록 해야 합니다.
프로토타입 및 데모 주기적 제공: 개발 진행 중간마다 프로토타입이나 데모를 제공하여 피드백을 수집합니다.
피드백 일정 명시: 피드백 제공 기한을 명확히 하여 개발 지연을 방지합니다.
피드백 수용 및 반영 절차 확립: 받은 피드백을 어떻게 처리하고 반영할지에 대한 절차를 수립합니다.
문제 해결 및 리스크 관리를 위한 커뮤니케이션 방식도 사전에 정의해야 하죠.
이슈 트래킹 시스템 활용: 발생하는 문제를 추적하고 우선순위를 지정하여 신속하게 대응합니다.
리스크 관리 계획 수립: 잠재적인 리스크를 식별하고 대응 전략을 마련합니다.
변경 관리 프로세스 도입: 요구사항 변경 시 영향을 평가하고 승인 절차를 거칩니다.
개발 초기 단계부터 클라이언트는 이러한 커뮤니케이션 빈도 및 방법, 절차 정립에 적극적으로 참여하여 방향성을 제시해야 합니다. 이 과정에서 현실적인 일정과 목표 설정함으로써, 무리한 일정보다는 현실적인 계획을 세워 서로 간의 신뢰를 구축할 필요가 있습니다.
성공적인 외주 개발을 위해서는 명확하고 일관된, 그리고 사전에 정의된 커뮤니케이션 전략이 필수입니다. 이는 프로젝트의 목표 달성뿐만 아니라 장기적인 파트너십 형성에도 큰 도움이 되죠.
Check Point 3. 개발 역량을 넘어 유지와 보수, 그리고 근본적인 파트너십까지
서비스 개발을 준비하고 있고, 이에 따라 앱 개발이 필요한 스타트업들에게 변화 무쌍한 시장 환경에 유연하게 대처할 수 있는 역량이 필요합니다. 늘 변수를 고려해야 하기 때문에 각자가 정의한 솔루션 하나도 다각도로 면밀히 분석하고 검토할 수 있어야 하죠. 이런 환경에서 아무리 탄탄한 사업모델과 서비스 기획안을 가진 기업이라 하더라도, 개발하려는 서비스에 필요한 기능만을 개발 의뢰하는 일반적인 탑다운 방식의 개발 환경은 양 사 모두 시시각각 변화하는 환경에 유연하게 대응하기 어렵게 만듭니다.
빠르게 사업을 정의하고 외주 개발을 통해 서비스를 검증하는 일이란 험난한 여정과도 같죠. 직접 고객 앞에 내보이며 출시하지 않은 이상 ‘아이디어’에 불과한 막연한 단계에서 단순히 외주개발사가 요구하는 비용을 감당하며 막대한 시간과 비용을 투자하는 것은 좋은 의사결정이라 할 수 없을 것입니다. 더욱이 개발은 개발이 완료된 시점 이후부터 시작되는 운영과 유지, 보수부터 본격적인 여정이 시작된다고도 할 수 있습니다.
그렇기 때문에 개발사는 단순히 원하는 기능을 구현해 주는 외주 대행 업체를 넘어, 개발적인 관점으로 서비스의 운영과 관리까지 이르는 전체적인 과정을 조망하며 조금이라도 더 나은 결과물을 함께 고민해 주는 파트너가 되어야 합니다. 이는 개발사의 개발 역량 뿐만이 아니라 실제 서비스를 운영해본 경험과 그 경험을 쌓기까지 걸어온 다양한 시도와 실패까지 클라이언트 입장에서 고려해야 함을 의미합니다. 단순히 개발만 진행하여 아웃풋을 내는데 집중하기보다는, 기획의 의도나 목적까지 함께 고민할 수 있는 파트너십을 개발사와 함께 공유할 수 있다면, 개발 이후의 본격적인 운영에 수반되는 리스크 역시 비약적으로 줄일 수 있겠죠. 개발사가 직접 서비스를 기획해서 개발해본 적 있는지, 개발을 넘어 운영과 관리 경험도 있는지를 살펴봐야 하는 큰 이유입니다.
성공적인 앱 개발과 서비스 런칭까지의 여정
흔히 스타트업을 망망대해에서 배를 수리하며 항해하는 상황과 비유합니다. 그런 점에서 새로운 서비스를 개발한다는 것은 단순히 아이디어를 실현시키는 일을 넘어서, 미처 예측하지 못했던 다양한 난관들을 하나하나 해결해 나가며 동시에 계속 노를 저어야 하는 일에 가깝죠. 앱 개발은 그것을 실현시키는 도구로 이는 이제 막 시작한 출항은 물론 앞으로의 항해 속 험난한 풍파를 이겨낼 수 있는 주요한 핵심 역량이 되어야 합니다.
많은 창업가들과 스타트업에서 시장의 문제를 정의하는 각자의 가설과 나름의 솔루션 개발을 가장 본질적인 핵심 역량이라고 규정하는 반면, 앱 개발을 단순한 기능의 구현이나 사업 아이디어가 구동되는 제품 제작으로 그 영역과 범위를 한계짓곤하죠. 그러나 이는 서비스 개발의 본질을 협소하게 한정함과 동시에 시장의 변화에 유연하게 대처하기가 어렵게 만드는 요인이 됩니다.
앞으로 펼쳐질 항해에서 예상 못했던 풍파와 빈번해질 고장, 발빠르게 수리해야 하는 상황을 미리 예견한다면, 앱 개발이 단순히 개발에만 그쳐선 안된다는 사실을 직시할 수 있습니다. 단순히 클라이언트가 요구한 기능의 구현에 그치는 것이 아니라, 코드의 지속성까지도 감안하여 전체적인 그림을 그리는 역량에 더해 서비스 가치를 개별 기능 측면이 아닌 통합 시스템 측면에서 바라볼 수 있는 파트너십이야말로 외주 개발사를 통한 성공적인 서비스 개발에 가장 중요한 요소가 아닐까요. 단순한 포트폴리오와 비용을 넘어서 스파르타빌더스에서 외주 개발사를 검토할 때 가장 중요하게 바라보는 요소이기도 합니다.
앱 개발을 준비하는 기업, 혹은 창업가들이 맞닥뜨리는 첫 난관에서 이 점을 결코 간과하지 않으시기 바랍니다.
