이성훈의 매거진

스타트업 개발 견적 계산해보기

이성훈

2020.01.23 17:58
  • 4644
  • 콘텐츠에 ‘좋아’해줘서 고마워요 -
    0
  • 0

견적 계산 기능을 만든 이유

저희가 스타트업 전문 개발사로서 가장 많이 듣는 질문은 이 앱을 만드는 데 비용이 얼마나 들고 기간이 얼마나 걸리느냐입니다. 수십 페이지에 달하는 미완의 기획서를 보고 또는 구두로 몇 마디의 설명을 듣고 견적을 산출하기가 쉽지 않아 견적 계산 기능을 만들었습니다.

 

모바일앱이나 웹서비스를 제작하고자 하는 고객이 저희 홈페이지를 통해 직접 견적을 계산해보실 수도 있고, 저희도 결국 이 기능을 이용해 프로젝트 비용과 기간을 산출하고 있기 때문에 저희가 견적을 산출하던 고객이 직접 해보시던 결과는 거의 같게 됩니다.

 

다만, 서비스 개발 경험이 없는 고객사의 경우, 견적 산출 페이지에 있는 기능별 설명만으로 이게 어떤 기능을 말하는 것인지, 내가 만들고자 하는 서비스에 이 기능이 들어가야 하는지 아닌지를 판단하기 어려워하셔서 세부적인 설명을 담은 글을 작성하게 되었습니다. 꽤 길지만 개발 의뢰를 맡기시려는 고객사라면 이 글을 꼼꼼하게 검토하실수록 내 서비스에 필요한 기능을 추리고 적절한 예산 계획을 세우시는데 도움이 되실 겁니다.

 

견적 산출 기능 이용해보기 

인썸니아만이 갖추고 있는 견적 산출 기능

예상 견적은 실제 청구 금액이 아님

먼저 말씀드릴 부분은 견적 산출로 나온 금액은 실제 청구드리는 금액이 아니며 실제로는 투입되는 개발자 분들의 작업 시간에 따라 개발비를 청구하게 되는데 개발자분들이 매일 작업 내역과 소요 시간을 대시보드에 기록하게 되고 고객사는 인썸니아 대시보드를 통해 작업 내역과 청구 비용을 확인할 수 있습니다. 구현 진행 상황과 비용 발생 상황을 보고 기능을 더 추가하거나 축소/변경하는 등 예산 상황에 맞춰 의사결정을 하실 수 있고 견적 산출 페이지는 전체적인 개발 비용과 기간을 대략적으로 판단할 수 있도록 함과 동시에 예산에 맞춰 중요한 기능을 선별하도록 돕는 역할을 하고 있습니다.


예산 범위 내에서 구현이 진행되어야 저희 입장에서도 고객사와의 신뢰관계가 확보되고 그래야 좋은 분위기 속에서 협업이 가능해지며, 더불어 고객사의 서비스 성장, 투자 유치 성공 등 좋은 상황일 때 지속적으로 개발 의뢰를 주시기 때문에, 개발을 가성비 있게 진행하여 비용을 낮추는 방향으로 지속적으로 고객사에게 제안하고 소통하게 됩니다. 견적 산출까지 해보신 후 그 내역을 문의에 남겨주시면 한 두 차례 미팅 후 개발이 빠르게 진행될 수 있습니다. 


웹/앱 플랫폼 선택

저희는 개발 속도가 빠르고 쉽게 인수인계할 수 있으며, 개발자가 쉽게 배울 수 있는 루비온레일스 웹 프레임워크를 사용하고 있습니다. 출시 플랫폼을 반응형 웹과 모바일 앱 중에 선택하게 되어 있는데, PC 브라우져와 모바일에서 동시에 서비스가 필요하고 모바일에서는 굳이 앱 수준으로 모바일 최적화 될 필요가 없으면 반응형 웹으로 개발하게 되고, 모바일에 최적화될 필요가 있을 때 모바일 앱으로 제작하게 되는데 저희는 웹앱 방식으로만 제작하고 있습니다. 네이티브와 리액트 네이티브, 하이브리드앱, 웹앱 방식의 차이에 대해서는 글로 따로 정리하겠습니다.


구현할 화면 수/디자인



인썸니아가 구축하여 내부적으로 사용하고 있는 타이퍼 모바일 앱빌더. 앱 디자인 템플릿


고객사에서 기획서 정리를 해보셨다면, 서비스의 전체 페이지 수를 대략적으로 산정할 수 있지만 정리해보지 않은 경우는 서비스 플로우가 간단한지, O2O나 판매 중개 서비스처럼 이용자와 제공자가 따로 있어서 복잡도가 높은지를 바탕으로 전자의 경우 20~30 페이지, 후자의 경우 30~50 페이지를 체크하게 됩니다.


고객사에서 신기해 하시는 것 중 하나가, 디자인을 고객사에서 제공하면 오히려 비용이 크게 올라간다는 사실인데(전체 프로젝트 비용의 1.5배로 증가), 저희가 권장하는 템플릿 커스터마이징의 경우 내부적으로 구축해둔 반응형웹 또는 웹앱 디자인 템플릿으로 개발을 진행하고 이 때는 고객사의 디자인 선호를 반영하지 않고 레이아웃 피드백 정도만 참고합니다.


기능 구현이 완성되는 시점에 고객사의 선호나 벤치마킹하는 서비스에 맞추어 색상, 폰트, 레이아웃, 그림자, 로고, 이미지 등을 퍼블리셔가 커스터마이징하게 되는데, 기능 구현이 거의 끝났으므로 프로젝트 리스크는 낮아진 상태이고 완성된 기능을 바탕으로 디자인 개선 작업을 하므로 중간 기능 변경에 따른 재퍼블리싱 작업이 사라집니다.


디자인 템플릿 자체의 완성도가 높은 편이기 때문에 디자이너/퍼블리셔가 초반부터 투입되지 않고 서버 개발자가 템플릿의 UI 컴포넌트만 잘 배치해도 꽤 깔끔한 상태로 개발이 진행되고 디자인/퍼블리싱 때문에 개발이 멈추고 대기할 필요가 없기 때문에 중요한 기능 구현이 빠르게 끝날 수 있습니다.


기획

기획서 작업을 저희도 안 하고 고객사에게 디테일한 수준의 기획서를 요구하지도 않는데, 주기적인 미팅과 메신져/통화를 통한 빈번한 소통을 합니다. 그리고 개발 착수 후 1~2주부터는 테스트 서버를 통해 구현 중인 서비스를 고객사가 직접 테스트하고 피드백 주실 수 있도록 하기 때문에 기획서 없이도 구현된 서비스를 바탕으로 구체적인 수준의 기획 논의가 가능합니다.


저희가 기획서 작업을 안 한다고 해서 기획 과정이 없는 것은 아닌데, 고객사와 UI와 사용 플로우 관련해서 논의하는 시간이 있고 저희가 고객사의 서비스를 이해하는 시간, 적절한 기능을 제안하면서 내부 논의를 하는 시간 등 시간 비용이 발생하고 개발자들이 얼마나 시간을 쓰는지에 따라 비용이 나눠져 있다고 보면 됩니다. 보통 부분 지원을 체크하게 됩니다.


관리자 


인썸니아 홈페이지 관리자 페이지. 고객사 서비스의 관리자 페이지도 동일한 라이브러리를 사용합니다


모든 데이터에 대한 조회/검색/편집/삭제 기능은 당연히 필요하기 때문에 필수 체크이고, 배송 상품이 있는 상거래 서비스의 경우 배송 및 반품 상태에 따른 배송관리 부분이 복잡해지기 때문에 따로 체크하게 됩니다. 디지털 상품 같은 배송이 없는 상품은 체크하지 않아도 되요. 통계는 주간, 월간, 일간 사용량, 가입자 수, 방문 수 등을 조회하는 대시보드가 필요한 경우에 체크하면 되고, 정산 기능은 O2O 서비스처럼 서비스 제공자들에게 주간/월간 정산 내역을 계산해서 지급해야 할 경우 이를 계산해서 보여주는 페이지가 필요할 때 체크합니다.


데이터를 한 번에 여러 건을 자주 올리고 내려야 할 때는 액셀 임포트/익스포트 기능을 체크하면 되고, 운영 초반이라 어드민에서 직접 조회/입력을 해도 된다면 생략해도 됩니다. 권한 설정은 슈퍼 어드민 권한 하나만 있을 때는 필요 없고, 컨텐츠 관리자, 회원 관리자, 게시판 관리자 등 관리자의 권한이 메뉴별로 나눠져야 하는 경우 체크합니다.

 

편집/업로드

위지윅 에디터는 블로그나 커뮤니티 서비스의 에디터 처럼 볼드/이탤릭/밑줄/글자색 등 텍스트 스타일 편집이 가능한 에디터를 넣고자 할 때 체크하고 단순한 텍스트 입력창만 필요하다면 생략합니다. 이미지/문서 업로드 기능이 필요하면 체크합니다. 앱이나 웹서비스에서 동영상을 보여주는 방법은 크게 두 가지가 있는데 유튜브/비메오 같은 서비스를 임베드 하는 방식과 저희 서버에 직접 동영상을 올리고 스트리밍 플레이어를 자체 구축하는 방법이 있습니다.

 

유튜브/비메오는 트래픽 비용 걱정을 안 해도 되고 특히 비메오는 다른 사이트에 임베드하는 것을 막을 수 있어서 영상 컨텐츠를 유료 구독자/결제자에게만 공개할 때 사용할 수 있습니다. 사용자가 직접 동영상을 업로드해야 하는 경우 고객사 유튜브/비메오 계정에 바로 업로드할 수 없기 때문에 동영상 스트리밍를 자체 구축하게 됩니다. 그리고 모바일 등 다양한 환경에서 업로드가 가능해야 하면 여러 디바이스 환경에서 문제 없이 재생되도록 서버 인코딩 과정을 거쳐야 합니다.


태그 자동완성은 인스타그램의 해시태그 입력할 때처럼 한 글자만 입력하면 주요 해시태그가 노출되는 자동 완성과, 태그를 클릭했을 때 태그 검색 기능을 포함합니다. 그래프는 사용자 대시보드나 어드민에 파이차트, 바차트 등의 그래프 표시가 필요할 때 체크하면 됩니다.


O2O/보안 기능

온라인 견적 산출은 인썸니아 견적 기능과 유사하게, 요소들을 체크하면 금액이 계산되는 로직이 필요할 때 체크하면 되고, 단계별 의뢰 요청은 숨고 같은 의뢰/문의 서비스에 필요한데, 예를 들면 에어컨 청소 서비스를 요청할 때 천장형인지 몇 평 형인지 등을 순차적으로 선택하는 인터페이스가 필요할 때 체크하면 됩니다.

 

전문가 비딩은 구매자 또는 서비스 이용자가 자신이 이용하고자 하는 상품/서비스를 요청하면 판매자 또는 서비스 제공자가 얼마에 해주겠다, 우리는 어떤 것이 강점이다며 제안을 하고 이를 이용자가 선택하는 프로세스를 말합니다. 질문/답변 기능은 네이버 지식인처럼 질문/답변 형태의 게시판을 말하고 전문가 대시보드는 서비스 제공자 쪽의 대시보드 화면, 예를 들면 판매 내역, 상품 관리 등의 기능이 필요할 때 체크하게 됩니다. O2O 서비스는 사실상 전문가 대시보드가 꼭 필요합니다.

 

HTTPS 적용은 웹/모바일 서비스에 필수 사항이고, 중요 데이터 암호화는 주민등록번호나 계좌번호 등 민감한 개인정보를 암호화해 저장해야 할 때 체크합니다. 비밀번호는 기본적으로 복구할 수 없는 형태로 암호화 되어 있는데 다른 데이터들은 일반적으로 암호화하지 않고 데이터베이스에 저장하므로, 만에 하나 데이터베이스가 해커에 의해 유출되었을 때 열람되어서는 안 되는 데이터를 암호화하는 것이 안전합니다.


캘린더

캘린더 인터페이스는 생각보다 구현이 어렵고 보통 라이브러리를 이용하며 이를 커스터마이징하는 데는 공수가 많이 들고 제약이 따릅니다. 캘린더 상에 날짜를 표시만 하는 것인지, 이벤트를 입력까지 할 수 있어야 하는지, 입력한 이벤트를 드래그앤드롭으로 이동할 수 있어야 하는지, 특정 일을 관리자나 서비스 제공자가 대시보드에서 활성화/비활성화할 수 있어야 하는지에 따라 공수 차이가 커집니다.

 

서버 환경

최초 서비스 출시 때는 서버 1대로 시작하면 됩니다. AWS 클라우드보다 카페24의 서버 호스팅이 더 저렴해요. 월 7만 5천 원 정도만 내면 4코어 SSD 서버에 1테라 백업디스크와 꽤 많은 트래픽까지 제공해주는데 비슷한 성능의 AWS 인스턴스는 3배 정도 가격에 백업 디스크도 안 주고 트래픽 비용도 별도입니다. 사용자가 많아지면 어떡하냐, 오토스케일해야 하는 것 아니냐 걱정하시는 고객사가 있는데 사용자가 늘어나는 시기에 자연스럽게 확장해나가면 됩니다. 처음에 설계를 단순하게 해야 나중에 확장을 하기 더 좋습니다.


가입/로그인

가입 기능 구현은 이메일이 기본이고, 인증은 이메일/휴대폰/실명 중 필요한 경우 체크합니다. 휴대폰 인증과 실명 인증의 차이를 말씀드리면, 휴대폰 인증은 입력하는 번호의 휴대폰만 가지고 있으면 인증이 되고 실명인증은 실명, 생년월일, 이통사, 휴대폰 번호를 입력하고 휴대폰 인증까지 해야 인증이 됩니다. 실명 인증과 휴대폰 인증은 인증 건당 비용이 있습니다.


SNS 로그인은 중요한 기능들이 마무리 된 후에 추가하는 것을 권합니다. 특히 모바일앱의 경우 단순하게 SNS 웹 로그인만 구현하면 사용자가 페이스북 로그인, 카카오톡 로그인 버튼을 눌렀을 때 해당 SNS 아이디/비밀번호 전체를 입력해야 로그인이 됩니다. SNS 앱까지 연동되어서 간단하게 로그인을 하게 하려면 네이티브 로그인 항목을 체크해야 합니다. 아이폰/안드로이드 코드에 각 SNS 로그인 SDK를 탑재하고 웹 로그인과 연동을 하는 등 구현이 복잡해서 웹 로그인과 앱 로그인 견적이 분리되어 있습니다.


가입/로그인 권한 분리는 O2O 서비스처럼 서비스 이용자와 제공자가 로그인 시 각기 다른 화면에 접속해야 할 때 접근할 수 있는 메뉴 권한을 나눠서 구현해야 하기 때문에 체크가 필요합니다. 가령 학원 수강생과 학원 선생님 계정이 나눠져 있고 수강생은 로그인하면 수업 목록, 학원 선생님은 로그인하면 학생 목록이 먼저 뜨는 등 메뉴 구성이 달라져야 하니 이 때 필요하겠죠.


알림/채팅

채팅은 생각보다 번거로운 기능이긴 한데 단순한 문자 채팅은 그래도 그렇게 까다롭지는 않습니다. 그런데 '채팅이 필요하다'고 말씀하시고 실제 그 채팅에서 어떤 기능들이 필요한지는 처음에 잘 전달받기가 어려운데요, 가령 채팅 안에서 이미지, 동영상, 앱 내 특정 페이지 링크, 또는 입력폼 등이 필요한 경우에는 단순한 채팅보다는 구현이 번거로워집니다. 이런 것까지 어느 정도 감안한 비용입니다.


1:1문의는 관리자와 해당 이용자만 볼 수 있는 비밀 게시판이고 고객 채팅 솔루션은 채팅을 직접 구축하지 않고 사이트 우측 하단에 channel.io나 톡상담 등을 붙이는 경우를 말합니다. 직접 구축과 비교해 탑재가 간단하기 때문에 비용이 크지 않죠. 알림은 푸시, SMS, 이메일, 카카오톡 등이 있고 푸시 메시지는 모바일앱에서만 동작하며 나에게 온 알림 내역을 알림 메뉴에서 목록으로 보려면 알림 내역을 모두 기록하고 알림 화면을 구현해야 하므로 구현 공수가 따로 듭니다.


푸시 메시지는 전체 사용자 대상으로 보낼 때는 사용자 별 디바이스 정보를 따로 저장해둘 필요가 없기 때문에 추가 비용이 들지 않는 반면, 개별 사용자에게 발송하거나 사용자 그룹을 채널로 정의해 발송하는 경우는 사용자 아이디와 디바이스 토큰을 매칭해 네이티브 쪽에서 서버에로 전송하고 서버에는 이 토큰을 바탕으로 개별 사용자에게 푸시 메시지를 발송해야 하므로 공수가 추가로 발생합니다.


네이티브 /지도

저희가 주요 기능과 사용자 인터페이스를 웹앱 방식으로 제작하지만 푸시메시지 수신을 비롯해 네이티브 관련 기능이 필요한 경우는 네이티브로 구현을 하고 있는데요, 블루투스 연동, QR코드와 바코드 인식, 현위치 추적 등의 기능은 웹앱 쪽에서는 구현할 수 없으므로 네이티브 쪽 구현을 하게 됩니다.


구글, 네이버, 다음 등의 API를 이용해 지도를 표시만 하는 것은 간단한데 지도위에 정보 팝업을 띄우는 것은 지도 API의 팝업 UI를 활용해야 하므로 시간이 더 걸립니다. 더불어 위치기반 검색이 필요한데 목록 형태의 검색 결과와 지도 위의 위치 내역이 연동되어야 하면 공수가 더 들죠. 직방 같은 부동산 정보 앱에서 지도 위의 매물 위치와 매물 목록이 함께 드는 것을 예로 들 수 있습니다. 


목록/상세

상거래라면 상품 목록 페이지와 상세 페이지가 있을 것이고 O2O라면 상점 목록, 서비스 제공자 목록, 선생님이나 트레이너 목록과 상세 페이지가 있을 것입니다. 즐겨찾기, 별점, 연관 목록 등이 각각의 공수가 들고 단순 검색이 아닌 다양한 조건들, 예를 들면 가격이나 성별, 지역, 전문분야 등으로 필터링해야 한다면 상세조건 필터링을 체크합니다. 거리순 정렬이 필요한 경우는 주소 정보를 등록할 때 이를 좌표로 변환해 저장해야 하므로 공수가 따로 들고요. SNS 공유를 웹으로 하는 것과 앱에서 하는 것은 구현 방법에 차이가 있어 금액이 다릅니다.


결제

결제는 흔한 기능이지만 구현 복잡도에 따라 공수 차이가 많이 납니다. 우선 국내 카드사 결제를 가장 일반적으로 넣습니다. 가상 계좌 결제의 비용이 큰 이유는, 카드결제는 주문 전 상태와 주문 완료 상태만 관리하면 되지만 가상계좌는 주문 전, 입금 전, 주문 완료로 입금 전 상태가 추가되어 어드민 상에서도 입금 전 주문이 따로 관리되어야 하고 가상계좌 입금 정보 수신 API를 구축해야 하며 정산 쪽에서도 입금 전과 주문 완료 상태를 구분해야 해서 생각보다 공수가 큽니다.


해외 서비스인 경우 페이팔 등 해외 결제를 붙이고, 계좌이체, 휴대폰 결제 등은 카드결제 구현 후 필요하신 경우에 구축하면 됩니다. 쿠폰은 금액이 큰데, 이는 쿠폰의 종류가 다양한 경우 때문입니다. 장바구니 쿠폰, 상품별 쿠폰, 고정 금액 쿠폰, 할인율 쿠폰, 배송비 쿠폰, 쿠폰 이용 가능 금액 제한, 환불시 쿠폰 금액 계산 등 다양한 이슈가 엮여 있어서 꼭 필요한 경우에만 넣는 것을 추천합니다. 쿠폰 번호만 넣어서 단순하게 금액 할인이 되는 경우라면 구현이 더 간단하기 때문에 이 만큼의 비용이 들지 않습니다.


포인트를 충전해 차감되는형태의 결제나 구매시마다 적립금이 쌓이고 이를 결제할 때 활용할 수 있다면 적립금 결제를 체크하면 되고, 매월 자동결제는 카드 결제 정보 빌링키 형태로 저장해두고 자동 결제되는 구독 서비스에 적합합니다. 카드 미리 등록 결제는 매월 자동결제와 기술적으로 유사하지만 자동 결제와 달리 구매자가 구매 버튼을 누르는 시점에 결제가 되니 스케쥴러가 돌고 있을 필요가 없어서 비용이 상대적으로 적게 듭니다.


결제 취소는 기본적으로 PG사 어드민 또는 결제 연동시 이용하는 아임포트 어드민에서 할 수 있기 때문에 따로 비용이 들지 않지만, 사용자 쪽의 결제 취소 기능을 넣고자 하면 취소 API 구축, 또 부분 취소 하는 경우는 부분 취소 금액 계산하는 로직이 필요하기 때문에 공수가 더 듭니다. 특히 부분 취소는 구매한 상품들이 여러 개일 때 여기에 할인 적용된 쿠폰, 적립금, 배송비를 계산하는 것이 쉽지 않습니다.


다국어 처리

다국적 서비스인 경우 다국어 처리가 필요한데, 메뉴만 다국어 표시를 할 것인지, 게시글도 언어별로 분리할 것인지, 아니면 전체 프로젝트를 언어별로 분리해서 관리할 것인지에 따라 전체 프로젝트 공수의 몇 배수의 공수가 듭니다. 메뉴명만 다국어 처리하는 것은 2.5배의 공수가 드는 프로젝트 분리보다는 적은 공수(전체 프로젝트 비용의 1.3배)가 들지만 프로젝트가 커지면 전체 메뉴, 텍스트, 이미지, 사용자의 언어 설정 등 모든 페이지와 모든 기능들을 한 번씩 손봐야 하므로 가급적 꼭 필요한 경우에만 선택하시기를 바랍니다.


고급 기술

딥러닝과 블록체인, 화상 채팅은 현재 예제도 많고 솔루션도 많이 나왔으므로 과거보다는 도입이 쉬워졌지만 우리 서비스에 맞게 적용하기 위해서는 단순 탑재가 아니라 실제 구현하면서 진행하는 R&D가 필요합니다. 각 천 만원이라는 예상 금액은 추상적인 산정이고 실제로는 어느 정도로 연구를 해야되는지에 따라 절반의 비용이 들 수도, 두 세 배의 비용이 들 수도 있습니다.


타임존

다국어 처리와 비슷하게 다국적 서비스인 경우 도시별 시간대를 고려해야 하는데 사용자별 시간대를 설정하고 그 시간대에 맞추어 타임존이 변환되어 예약 기능이 동작해야 하고 모든 페이지에 시간대 표시가 로그인한 사용자 타임존에 맞추어 보여져야 하므로 역시 더하기가 아닌 곱하기 견적이 책정됩니다.

 

크롤링/스크래핑

크롤링과 스크래핑은 비슷한 목적이지만 상황에 따라 다르게 사용합니다. 목적은 다른 웹페이지의 정보를 가져와 활용하기 위한 것인데, 크롤링은 크롤링 서버에서 대상 서버로 요청을 보내 html 형태로 결과물을 가져올 수 있으면 이를 분석해서 원하는 데이터로 변환할 수 있어 상대적으로 간단한데, 대상 서버가 크롤링 서버의 접근을 막아놓은 경우는 스크래핑 방식을 이용해야 합니다.


스크래핑은 크롤링이 안 되는 경우, 브라우져 인스턴스를 생성해서 일반 사용자가 브라우져를 통해 사이트에 접근한 것처럼 해당 웹페이지 정보를 읽어올 수 있습니다. 브라우져 인스턴스를 띄우는 것은 메모리를 많이 사용하기 때문에 크롤링보다 느리고 구현도 번거로워서 비용 차이가 발생합니다. 크롤링을 먼저 시도하고 데이터를 가져오는데 실패하면 스크래핑을 시도합니다.


멀티 서버 크롤링은 대상 페이지에서 요청이 많은 IP 접속을 막는 경우 AWS 등의 클라우드 서버에서 인스턴스를 재시작하며 IP를 변경해가면서 접속을 시도할 때 사용합니다. 클라우드 운영 및 크롤링 환경 구축을 위해 많은 시간을 투입해야 하므로 비용이 많이 듭니다. 크롤링과 스크래핑은 대상 서비스에 크롤링 허락을 받은 상태 또는 일반적으로 허용되는 상태에만 구현이 가능합니다. 저작권 이슈 발생시 의뢰한 고객사의 책임이기도 하지만 저희 쪽에서도 법적인 이슈가 발생할 가능성이 있는 경우는 개발을 진행하지 않습니다.


외부 API, PDF 생성, 정부사업 문서, 주석 작업

외부 API를 활용할 때 간단한 호출로 간단한 데이터를 가져올 수 있는 경우와, API 호출을 위한 인증 절차가 복잡하고 가져온 데이터의 구성도 복잡한 경우 공수가 다릅니다. 외부 API의 데이터와 우리 데이터베이스의 데이터를 주기적으로 싱크해야 하는 경우는 스케쥴러가 돌아야 하고 데이터 정합성 여부도 체크해야 하기 때문에 공수가 더 큽니다.


PDF문서를 만들어 내는 기능은 단순한 PDF인지, 좀 더 복잡한 양식의 PDF인지에 따라 공수가 다릅니다. 정부지원사업 시 개발사에서 작성해야 하는 문서나 준비해야 하는 선급금이행보험증권, 데이터베이스 설계서 등이 필요한데 개발자나 계약 담당자의 인건비가 발생하므로 동일하게 시간 단위로 비용을 청구합니다. 기본적으로 코드를 간결하게 작성하려고 하기 때문에 주석은 많이 작성하지 않고 부분적으로 작성하는데, 고객사 중에서 주석을 상세히 작성하기를 원하시는 경우는 조금 더 시간을 들여 주석을 작성하기도 합니다.


프로젝트 예산과 기간

O2O 서비스 만든다고 가정하고 체크해보면 보통 3천 만 원에서 5천 만 원 가량의 예상 견적이 나옵니다. 기간은 천 만원의 개발 분량이면 1개월 정도 소요되기 때문에 3개월에서 5개월 정도의 개발기간이 소요됩니다. 이 금액이 넘어가면 프로젝트 리스크가 커지고 개발 기간이 예측을 벗어나기 쉬우며 후반부에 디버깅을 하기 어렵기 때문에 중요한 기능 위주로 추려서 3천 만 원에서 5천 만 원 분량으로 1차 마일스톤을 정하도록 가이드하고 있습니다. 


즉 구현하고자 하는 전체 기능을 모두 체크하니 9천 만 원이 나왔다면, 3개의 마일스톤으로 나눠서 1차 마일스톤에 핵심 기능만 체크해서 구현을 진행하고 검수한 후 출시 및 운영을 하면서 2차, 3차 마일스톤을 그 때 다시 정해 개선해나가는 것이 안전합니다. 운영을 하다보면 원래 구현하려고 했던 기능보다 더 급하고 중요한 기능들이 발견이 되기 때문에 개발 단위를 적절하게 쪼개서 빠르게 시장 검증을 하는 것이 스타트업 다운 방법입니다. 


문의와 견적서

체크한 견적을 바탕으로 아래 문의 버튼을 누르면 견적 내용과 함께 인썸니아에 개발 문의를 남길 수 있습니다. 문의 작성과 동시에 고객의 메일로 PDF 형태의 견적서와 개발 서비스 안내 페이지가 발송되므로 안내와 견적서를 살펴보시고 저희의 연락을 기다리면 되시겠습니다. 


 

인썸니아 사이트 방문하기 > 

원문 보러가기 > 

  • # 개발자
  • #인썸니아