SI(System Integration)란, 기획에서부터 개발과 구축, 나아가서는 운영까지의 모든 서비스를 주로 기업에 제공하는 일을 말한다. 보통 부가가치를 높이기 위해서 전문 IT 컨설팅과 같이 수행하는 경우들이 많으며, SaaS가 대세로 등극하게 된 배경에는 구축형 S/W의 수명이 짧고 무엇보다 유지보수 비용이 생각보다 커지는 경우들이 많아졌기 때문이다. 또한 도커와 퍼블릭 클라우드 서비스가 대세가 된 환경에서 사실 확실한 기반 SaaS가 있다면 당연히 엔터프라이즈 버전을 고민해 볼 수 있고 기업체 환경에 맞는 Customization 기능을 고객사가 요구하게 되는 일도 다반사다.

하지만, 개발 원가 계산과 유지보수 체계, 영업인력과 비즈니스 어카운팅 능력이 없다면 이건 서비스 제공사로서나, 구매하는 구매 기업으로서나 상당한 손실을 가져올 수 밖에 없는 일이 될 수 밖에 없다.

간혹 SaaS 운영사 대표자들 중에 SaaS의 기업용 Customization 과 구축형 사업을 매우 헷갈리는 분들이 존재하는데 나름 몇십억 규모 SI 사업에 기반 솔루션을 가지고 기술PM으로 일해본 경험도 있고, 포털 서비스 개발 운영 본부장도 역임했었고, 많은 SaaS에 투자하고 있는 매쉬업벤처스의 테크 어드바이저로 보고 들은 바가 있는 필자로서는 SI 가 그렇게 남는 장사인가에 대해서 심각하게 의문을 제기해 보고자 한다.

• 우선 구매 기업 고객의 리스크

  • 우선 기술기반이 탄탄한 스타트업이라고 해도 당장 그 기업이 도산하거나, 경영이 어려워 졌을때 유지보수가 요원해지는 것이 그 기업의 가장 큰 리스크다.

  • 애초에 투입 비용대비 낮은 퀄리티의 서비스를 제공받고, 커스터마이징 한 부분 호환성 이슈로 빠른 버그대응이나, 기능개선이 반영되기 어려울 수 있다.

  • 구축형 서비스는 보통 1년 - 2년 추가 비용을 내고 유지보수를 해야 버그 수정이나 기능개선이 반영된다. 그마저도 작은 SaaS기업의 경우, Customization 파트에서 원천해결을 못하는 경우도 발생한다.

  • 요즘 기업체의 인프라 자체도 퍼블릭 클라우드화 또는 하이브리드 형태로 진화되는 추세인데, 본체가 IT 투자가 제대로 되지 않은 곳이라면 유지보수비용 지불 능력이 된다고 해도, SLA(Service Level Agreement)를 잘 맞추는지 모니터링하면서, 유지보수시키는 것도 시간이고 리소스 추가 투자다.

• 공급 기업의 리스크

  • 우선 기업체에서 투입 인력 인건비를 개발비로 계상하는 경우, 해당 서비스 개발업체의 이윤은 스펙이 높은 사람들은 이름만 걸어두고 실제 인건비는 저렴한 인건비의 개발인력이 투입되거나, 기간이 사실 2개월이면 되는 일을 6개월로 포장하거나 하는게 남는 장사다. 

  • 저 기업이 쓰면 다들 따라 쓸거야 이런 검증되지도 않은 가설로, 개발 및 유지보수 원가도 안나오는 영업들을 하다 보면 점점 개발진들은 지칠거고, 개발되는 서비스 퀄리티는 떨어질거고, 회사는 질질 끌어다니다가, 영업은 의외로 당장 확장가능하지 않을것이므로(Customization 범주가 작을것이므로) 서서히 가치가 떨어져 갈거다.

  • 실제로 잘 나가다가 투자 혹한기 시즌에 도산하거나 폐업한 많은 SaaS사례들을 보면, 당장 통장 돈이 떨어져가니, 직원 월급에 퇴직금도 나가야 하는 상황에서 목돈입금의 희망으로 뭐든지 된다 마인드로 영업을 하는 경우다. 기업체가 크면 클수록, 구매팀 따로, IT운영부서 따로, 회계팀 따로다. 목돈만 던져주는 경우는 전무하고 최근 SaaS커스텀 빌미로 사용료만 내고 너네 다 제공하면 되지 이런 명목으로 개발비를 전혀 책정하지 않는 기업들도 존재한다.

  • 커스텀 기능 개발 시간동안 경쟁사는 고객의 Unmet needs를 발빠르게 맞춰주고 가격경쟁력으로 본체 파이를 가져가서 본체 시장에서 시장점유율이 생각보다 빨리 떨어질 개연성이 존재한다.

  • 비전문가가 개발비용, 시기 측정, 개발 투입 자금 계산, 특히 유지보수 비용까지 계산한다는 건 불가능한 일이다. 숙련된 기술영업, Project Manager 가 있어도 어려운 일이 이 일이다. 시스템 전문가 적어도 System, Network, Data Architect 가 존재해야 가능한데 그 능력을 다 구비한 조직은 드물거다. 또 하나는 커뮤니케이션 코스트다.

• 그렇다면 SaaS의 엔터프라이즈 Customization 은 어떻게 추진되어야 하는가?

  • 일단 SaaS본체 자체가 커스텀 가능한 영역이 잘 구분, 구축 설계되어 있는게 바람직하다. 그리고 유지보수 부담은 공급기업뿐 아니라, 지불고객사도 가지게 되는 구성이므로 유지보수부담이 낮은 Customization을 선택하는게 바람직하다. 이 때 돌아볼 포인트. 지금 우리회사 SaaS 본체의 리팩토링이나 선진화에 시간과 리소스를 어느정도라도 투자하고 있는가? 그렇지도 않으면서, 일단 우리는 SaaS가 있으니까 레고블럭처럼 요거 요거만 바꾸면 될거야. 라고 쉽게 단정 좀 짓지 말자.

  • 여러 고객사의 다양한 요구사항을 듣다보면 SaaS본체가 좋아지고 나아질거야. 나이브하다. 거의 30년 이 업계에서 일해본 바로 고객은 현존 IT 제품 개선에 관심이 없고 그들의 일도 아니다. 단지 Pain Point(또는 지불 비용)이 존재할 뿐이고 그 Pain Point를 없애는데 얼마를 지불하고자 하는 Willing To Pay 마지노션이 있을 뿐이다. 내 추천은 차라리 커스텀 영역과 우리 SaaS의 핵심 영역을 확실히 구분하라는 거다. 예를 들면, 기본 통계 대쉬보드는 제공하되, Advanced Form과 데이터를 받으려면 추가 비용을 내는거다. 또는 그 기업만 사용하는 분리된 공간에 데이터와 고객정보를 구분하는거다. 또는 커스텀 기능과 아닌 기능을 애초에 구분하는 등의 방식이 있을 수 있다.

  • 배포, 유지보수가 리모트로 될 수 있는 체계를 구축해야 한다. IT인력이 있다면 내부에서 간단한 다운로드 후 업데이트로, 없다면 리모트로 최신화 코드 배포와 버그수정 패치가 될 수 있는 체계 구축이 되어야 한다.

  • POC (Proof Of Concept) 기간을 두는게 바람직하다. POC자체도 최소 수준의 Customization 을 해서 실제 커스텀 기능이 잘 수용되는지, 또 유지보수 부담은 얼마나 드는지 공급사와 수요사가 같이 검증하는 시기를 두는것도 바람직하다. 또 이때 사실상 QA와 수용도 테스트를 진행해 볼 수 있다.

  • 기업체 전용 클라우드 VPC도 좋으니, 제발 클라우드 기반에서 운영하자. 요즘 AWS, GCP모두 엔터프라이즈버전 POC를 한다고 하면 무료 크레딧을 지원해 주는등 기업 고객 확보에 공을 들이고 있다. 이걸 SaaS기업은 이용해볼 수 있다.

  • 전담부서나 전담자가 대표이사나 C레벨 말고, 운영레벨, 개발레벨에서 있어야 한다. 대표이사가 단위 고객사에 신경을 쓰면 쓸수록 그런데 그 기대 캐쉬사이즈가 작으면 작을 수록 그 기업은 망하는 트랙 진입이기 때문이다.

  • 메인 프로덕트 PO와 비즈니스 어카운트매니저의 고객 니즈 수렴 창구가 있어야 하고, 서로 롤이 분리되어 있어야 한다. 영업 담당자가 PO가 되는데 심각하게 이슈제기를 한다. 이게 정말 그 영업딜을 완성하기 위함이 목표가 아니라 더 범용적으로 많은 고객에 기여할 수 있는 것이어야 SaaS기업은 ROI가 나오기 때문이다.

우리 타겟 고객은 SMB거나 소상공인이라, 해당이 안돼. 그렇다면 과감히 엔터프라이즈 커스텀 사업은 포기하는게 맞다. 다른 고객에게 확장가능하게 세일즈 가능한 모델이 아니라면. 여기서 확장가능은 적어도 구매의향서나 POC 사용 계획, 계약 레벨을 확정하는 단계다.

또, 시스템 구축 사업을 메인으로 하는 곳들과 작은 규모의 SaaS제공사들은 큰 기업에 같이 제안하거나 프로젝트를 컨소시엄형태로 수주하라고 권유하는 편이다. 시스템 구축에도 노하우가 존재하기 마련이다. 인프라 배치와 스펙 디자인, 이슈 처리, 고객응대와 매뉴얼, 기술지원 체계가 상당히 비용경쟁력있게 구축되어 있을 가능성이 높고 S/W개발능력이 주요 능력인 SaaS개발사는 이들과 파트너쉽으로 구축사업또한 시도할 수 있겠으나, 이런 기업과 일해보면 정말 원가 계산 잘 나올거다. SaaS만 해본 특히 기업체 근무 경험이 짧거나 적은 창업가나 경영진일 수록 이 원가 계산에 취약한 경우가 다반사다.

내가 아주 예전에 쓴 글 하나 더 투척하면서 끝맺어 보려고 한다. 아래는 많은 SI 프로젝트들이 실패하는 이유를 적었던 글. 그리고 난 아직 SaaS는 초기라는 생각. 꽃피울려면 멀었고, 국내시장에 안주하지 않고 글로벌화할 수 있다고도 믿는다.

그리고 생각보다 터프한 작건 큰규모건 SaaS커스텀에 대한 환상과 오해에 대해서 경각심을 주고자 한다. 그리고 좋은 비즈니스 기회라면, 당연히 도전해야 겠으나, 위에 소개한대로 스마트하게 도전하시길. 그리고 PO보다는 PM, 단순 세일즈보다는 기술영업이 이 일에는 더 필요하다. 롤 셋업과 업무분장도 달라져야 하기 때문에 이것도 하고 저것도 하고는 아무것도 하지 말자와 다른 말이 아님을 명확히 해야할 것 같다.

https://brunch.co.kr/@yj5wqu/19