새로운 고객사와 첫 미팅 후 저희가 자주 듣는 이야기는 '이런 방식으로 개발하는 개발사는 처음 본다'는 것입니다. 인썸니아의 개발 방식이 다른 개발사과 어떻게 다른지, 왜 그런 방식을 택하였는지 정리해봤습니다.
기획서는 없어도 됩니다
저희는 고객사를 대신해서 기획서를 작성해드리지 않습니다. 반대로 고객사에게 기획서 작성을 필수로 요청드리지도 않습니다. 다만 기존에 작성된 기획서가 있으면 참고용으로 공유해달라고 말씀드리고 따로 정리된 기획 문서가 없으면 종이에 그리거나 구두로 간단한 설명을 듣고 일단 개발을 시작합니다.
개발 중인 중간 결과물을 일찍부터 테스트 서버에 배포해서 고객사에게 공유하기 때문에 이때부터는 동작하는 서비스가 기획서의 역할을 대신합니다. 돌아가는 서비스를 고객사에서 써보면서 문구 변경이나 기능 추가를 메신저로 요청합니다. 화면을 캡처해서 카톡 메시지 하나 보내는 것이 기획서를 수정해서 공유하는 것보다 더 쉽고 빠르며 개발자들이 이해하기도 쉽고 반영도 빠르게 할 수 있습니다.
디테일하게 설계된 기획서가 있더라도 그대로 구현하지 않고 각 요소를 개발이 간단한 방식으로 먼저 구현해서 고객사에게 제안하거나 간단한 방식과 복잡한 방식에 대한 예상 비용을 제시해서 고객사가 결정하게 합니다. 이런 논의 없이 기획서 그대로 개발해야 하는 프로젝트라면 워터폴 방식이 적합하기 때문에, 애자일한 방식을 추구하는 저희는 이런 프로젝트를 애초에 수주하지 않습니다.
결과물을 빨리 공유하기 시작합니다
프로젝트 시작 후 약 1~2주 정도면 테스트 서버에서 돌아가는 서비스를 확인할 수 있습니다. 가장 핵심 기능 중 일부와 메뉴 구성이 구현되어 있고 서비스의 골격이 어떤 모습인지 가늠할 수 있습니다. 이에 대한 고객사의 피드백을 개발자들도 빨리 받아볼 수 있기 때문에 좀 더 고객사가 원하는 모습에 가깝게 개발하기가 수월합니다. 동작하는 소프트웨어 기반으로 소통하는 것을 애자일 방법론에서도 중시하고 저희도 이 방법이 가장 잘 동작하였습니다.
고객사는 실시간 구현 결과를 바탕으로 비용 지출 흐름과 타임라인을 가늠할 수 있고 프로젝트를 명확히 관찰하고 통제할 수 있습니다. 더 큰 장점은 서비스를 만드는 과정에 대해 고객사도 학습할 수 있다는 점입니다. 개발자가 피드백을 요청하고 고객사에서 의사결정을 하고 개발 공수와 기능별로 발생한 비용들을 관찰하고 기능들이 만들어지는 과정을 지켜보면서 고객사는 서비스 개발과 운영과정을 학습하게 되어 서비스 출시 후에도 개발자 채용 후에도 원활하게 사업을 운영할 수 있게 됩니다.
일반적인 프로젝트 진행 방식에서는 프로젝트가 시작된 지 석 달 만에 오류가 있는 중간 결과물을 받아보고, 최종 결과물을 6개월 째에서야 받아보았는데 기획서대로 만들었지만 사용자가 사용하기 너무 불편할 때가 많습니다. 기획 상의 이상한 점을 늦게 발견하게 되고 기술적인 오류도 늦게 찾게 되는 것이죠. 한두 달은 버그를 잡는 데에만 시간을 써야 하는 상황이 생기는 이유는 서비스가 일찍 공유되지 않았고 피드백을 빨리 받지 못해서입니다. 고객사가 최초의 사용자로서 테스트를 일찍 시작하면 기획과 개발상의 큰 오류들은 일찌감치 수정할 수 있고 프로젝트가 마무리되어 가는 시점에서는 오류가 별로 안 남게 됩니다.
프로젝트 단위가 아니라 시간 단위로 비용을 청구합니다
프로젝트 개발 비용을 계약 전에 확정하는 것이 아니라 개발자들이 투입한 시간에 따라 개발비를 그날그날 청구합니다. 청구한 시간과 비용, 그리고 그날 개발한 내용을 요약해서 개발자들이 매일 기록하고 고객사는 매일 그 내용을 확인하고 청구된 비용을 확인할 수 있습니다. 정부 창업지원사업 등 정부자금이나 계약 형태가 정해져 있는 대기업/중견기업은 프로젝트 기반의 계약서 양식에 따라 계약을 하지만, 실제 청구 형태는 시간 단위로 하여서 해당 계약금액 이내에서 필요한 기능 추가나 변경, 유지보수 요청을 얼마든지 할 수 있도록 하고 있습니다.
시간 단위로 비용을 청구하면 고객사의 기능 변경이나 추가적인 요구사항에 대해 저희가 부정적으로 답변하고 방어할 필요가 없습니다. 비용이 더 들어가더라도 변경과 추가가 필요하다고 고객사에서 판단한 것이기 때문에 저희는 공수가 얼마 정도들 것인지 대략적으로 예상해서 공유하고 대응하면 됩니다. 개발 시간을 줄이면 고객사 비용이 절감되기 때문에 개발이 간단한 방식으로 제안했을 때 고객사가 높은 확률로 그 결정을 따르게 됩니다. 개발비를 시간 단위로 매일 청구한다고 해서 매일 돈을 달라고 요청드리는 것은 아니고 500만 원 단위로 개발비를 크레딧 형태로 충전해놓고 매일 차감하는 형태입니다.
기획 순서대로가 아니라 우선순위대로 개발합니다
프로젝트 단위로 계약하지 않고 비용을 시간 단위로 청구하기 때문에 우선순위가 높은 순서대로 개발하는 것이 가능해집니다. 기획서의 순서대로 구현하거나 개발자의 선호대로 구현하지 않고 기능들의 우선순위를 고객사에게 판단하도록 하여 중요한 순서대로 구현합니다. 반면, 프로젝트 단위로 계약하는 경우 기획서가 암묵적으로 계약서 조항이 되어 어차피 기획서의 모든 항목을 구현하는 것이 개발사의 의무가 되고 우선순위에 대한 고려가 상대적으로 덜 중요하게 받아들이게 됩니다.
기획서가 30 페이지라면 실제로는 각 페이지의 중요도가 다르고 어떤 것은 사실 구현이 꼭 안 되어도 되고 어떤 것은 기능만 동작하면 기획서대로 구현이 안 되어도 되고, 어떤 것은 핵심 기능이어서 기획서 그대로 구현이 되어야 합니다. 기획서 상의 UI 배치는 대부분 꼭 그렇게 되어야 하기보다는 다른 앱이나 기획서를 참고해서 만든 경우가 많죠. 각 기능에 대해 비용을 고객사가 알고서 판단하게 되면 굳이 기획대로 구현하지 않아도 될 부분들인데 개발자들이 굳이 소통하지 않고 기획서대로 만들게 되어 불필요한 개발 비용 생기게 됩니다.
프로젝트 계약에선 어차피 전체 비용이 정해져 있으니 세부적인 부분의 개발 공수가 커지든 작아지든 개발사의 비용이지 고객사의 입장에서는 상관없는 것 아니냐고 생각하실 수 있지만, 프로젝트 비용을 산정할 때 개발사가 이런 부분들을 감안하여 견적을 제시하게 됩니다. 그렇게 개발이 진행되어 우선순위가 낮은 기능이 구현 대상에서 제외되거나 고객사의 의사결정으로 구현이 간단하게 되어 개발 시간이 단축되어도 프로젝트 계약에서는 개발사의 행운이 되고 고객사는 고정된 프로젝트 비용을 내야 하니 비용 절감 효과가 없습니다.
우선순위가 중요한 것을 가급적 간단한 방법으로 구현했을 때 구현 시간이 짧아지고 프로젝트가 안전해지게 됩니다. 중요한 기능들이 프로젝트 앞 쪽에서 마무리되었고 중요도가 낮은 기능들은 후순위로 구현하거나 구현하지 않기로 결정해도 되므로 프로젝트는 일찍부터 출시 가능한 상태가 됩니다. 이런 방식이어야 프로젝트 후반부에 자투리 기능만 완성되어 있고 핵심 기능이 미완성되어 있는 최악의 사태를 막을 수 있습니다.
요구사항을 가급적 간단한 형태로 먼저 구현합니다
같은 기능을 구현하더라도 개발이 수월한 방식이 있고 번거로운 방식이 있는데 개발이 수월한 방식이 사용자에게도 편리한 경우가 많습니다. 왜냐하면 사용자들이 자주 이용하는 패턴이 라이브러리나 UI 컴포넌트로 만들어져 있고 이것을 적극 활용할수록 개발이 간단해지기 때문입니다. 최대한 간단하게 구현할수록 오류가 줄어들고 기능 추가/수정이 몇 배로 빨라집니다.
이때 시간 단위로 계약을 했다면 고객사는 비용을 절감하게 됩니다. 개발사는 구현 시간이 단축된 만큼 개발비를 덜 청구하게 됩니다. 개발사가 개발비를 일부러 덜 받으려고 하겠냐고 생각하실 수 있을 텐데, 시간 단위로 청구하기 때문에 개별 프로젝트에 개발비를 적게 쓴 만큼 인건비도 적게 투입되어 이익률이 유지되고 수주량이 충분하면 각 고객사에게 많은 비용을 청구할 필요가 없고 개발자분들의 가용시간에 프로젝트를 잘 배분하면서 이익률 유지만 하면 됩니다.
오히려 고객사의 비용을 절감해서 신뢰관계를 형성하고 칭찬과 인정을 받으며 개발하는 것이 개발자와 개발사 입장에서 성취감이 큽니다. 개발업이 평판 비즈니스이다 보니 좋은 평가로 좋은 평판을 유지하면 이것이 가장 좋은 마케팅 방법이기도 하고요. 저희도 이익만 바라보고 이 업을 하는 것이 아니라 스타트업의 가장 어려운 관문 중 하나인 서비스 출시를 비용 효율적이고 안정적으로 할 수 있도록 돕고 고객사들에게 좋은 평가를 받아 나름으로 스타트업 생태계에 기여하고 있다는 것에 자부심을 느끼고 있습니다.
프로젝트 단위 계약에선 요구사항을 간단하게 구현하기보다 기획서대로 구현하여 설계가 복잡해지고 기능 추가나 수정이 어려운 상태가 되어 프로젝트 후반부에 고객사와 개발사의 관계가 서먹해지곤 합니다. 저희는 기능 추가에 방어적이지 않으면서 비용 절감과 더 많은 기능 구현을 위해 열심히 소통하고 개발에 힘쓴 개발자분들에게 고객사가 고맙다고 말씀해주시는 관계가 됩니다. 스타트업 프로젝트 특성상 출시 이후에도 지속적으로 기능 추가와 개선을 해야 하기 때문에 대게는 절감한 예산을 추가 구현에 집행하는 경우가 많습니다.
개발자를 중개하지 않고 직접 관리합니다
외부에 있는 개발자들을 프로젝트별로 중개하는 형태가 아니라 인썸니아 내부에서 개발자를 일정기간 교육시키고 메인/서브/백업 개발자 역할로 프로젝트에 배정하고 회사 차원에서 기술적으로 보조하고 프로젝트 리스크를 관리합니다. 개발자분들은 회사에 풀타임 정규직/계약직으로 소속되어 있고 계약직의 직원들도 특정 조건이 되면 정규직으로 전환하고 있습니다. 개발자를 중개만 하게 되면 리스크를 회사 차원에서 관리하는 것이 아니라 개발자 개인 떠넘기게 되고 개발자 이탈 시엔 반대로 개발사에서 손 쓸 수 없는 경우가 생깁니다.
저희는 개발자 각자의 맨파워에만 의존하는 것이 아니라 다양한 기능 구현 및 오류 대응, 출시 과정에 대한 도큐먼트가 회사에 쌓여 있고 각각의 개발자가 새로운 경험을 하면 회사의 경험으로 누적됩니다. 각자의 경험이 개인에게만 쌓여서 퇴사 후에 사라지는 것이 아니라 회사의 역량으로 집중되어 점점 더 효율적인 개발을 할 수 있게 됩니다. 개발자분들이 단기간이 아닌 장기간의 관계를 인썸니아와 맺고 인썸니아 소속으로 열정적인 동료들과 함께 일하고 있고 회사에서 소통과 개발에 대해 가이드하고 있기 때문에 태도가 매우 좋습니다.
유지보수 기한이 없습니다(무기한)
개발 끝나고 몇 개월 후부터 남남이 되는 것이 아니라 기한에 상관없이 기능 추가나 뒤늦게 발견된 오류 수정, 서버 관리, 신규 스토어 출시 등을 편하게 요청할 수 있습니다. 4년째 유지보수를 맡겨주고 계신 고객사도 있고, 출시 후 1~2년 만에 연락이 와서 간단한 수정 요청을 하시는 고객사도 있습니다. 기존 고객사분들은 신규 프로젝트 출시할 때 저희를 다시 찾아주시고요.
개발비를 시간 단위로 청구하기 때문에 기한이 한참 지나 간단한 수정을 요청하셔도 대응을 안 해드릴 이유가 없고 개발을 인하우스로 하기 때문에 담당했던 개발자가 있는 경우는 이어서 진행할 수 있고 퇴사했더라도 코드 관리를 회사 차원에서 해왔기 때문에 인수인계 및 코드 리뷰 후 다른 개발자가 배정되어 개발을 진행할 수 있습니다. 스타트업 고객사에서 개발자 채용을 하셔서 프로젝트가 저희의 손을 떠나도 좋고, 만약 인건비라는 고정비가 부담되신다면 채용하는 대신 필요할 때만 저희에게 의뢰하실 수도 있습니다.
