IT서비스 기업을 위한 경영학 (4) - IT서비스 사업과 SW제품 사업의 비교: 본질적 차이점, 유사점과 전후방 연관관계

이전 호: https://www.kosta-online.com/post/global-it-service-business-model

1. SW제품 사업의 역사

IT서비스 사업과 SW제품 사업의 비교를 위해 두 산업의 탄생 역사부터 살펴 보자. 본 시리즈 3호(https://www.kosta-online.com/post/global-it-service-business-model) 에서 언급했듯이, 1950년대 초 소프트웨어가 발명된 후, 50년대 중반에 IT서비스 산업이 먼저 생겼다. 그 후 1960년대에 들어서야 많은 고객이 공통으로 사용할 수 있는 SW제품의 상품화가 시작되었다. 60년대초 미국 법무성에서 SW를 하드웨어에 끼워 파는 걸 공정거래를 위반하는 것으로 금지하자, 소위 ISV(Independent Software Vendor)라고 부르는 SW제품 전문업체들이 성장하기 시작하였다. 미국에는 60년대 중반에 이미 SW제품 산업에 50개의 대기업과 3000개의 중소기업이 있었다.

IBM에서도 1966년에 컴퓨터 하드웨어와 분리된 독립적 SW를 어떻게 상품화하고, SW 관련된 지적재산을 어떻게 보호할 것인 지를 연구하는 태스크포스팀을 운영하였다. 그 결과 SW제품 벤더가 SW의 Copyright를 소유하고, 고객에게는 SW의 사용권(End User License)만 인정해 주는 거래 모델이 채택되었고, 이 거래 모델이 전 세계로 확산되었다. 또한 SW를 구매할 때 먼저 라이선스 요금(License Fee)을 지불하고, 그 후 SW의 기술지원, 유지보수 및 업그레이드를 받으려면 정기적으로 추가적인 요금(Maintenance and Support Fee)을 지불하는 거래 방식이 채택되고 확산되었다.

1990년대 말에 USi, Corio 등 소위 ASP(Application Service Provider) 업체들이 나타나 Oracle, Siebel, Peoplesoft 등 인기 높은 타사의 SW제품들을 자사 데이터센터에서 호스팅해 주고, 고객은 SW를 설치, 운영할 필요 없이 웹을 통해 사용만 할 수 있는 서비스를 제공하였다. ASP는 이익을 내기 어려운 사업 모델로 판명이 났고, 후에 대부분 SaaS 사업 모델로 전환되었다. ASP와 SaaS의 차이에 대해서는 아래에서 다시 살펴 본다.

1990년대 말에 Salesforce가 발명한 Software as a Service(SaaS)와 2000년대 후반에 나타난 Heroku, Google App Engine, Force.com 등의 Platform as a Service(PaaS)는 SW제품을 벤더가 클라우드 인프라에 호스팅해 주는 사업이다. SW를 고객이 On Premise에 설치하고 쓰느냐, 아니면 벤더가 호스팅해 주고 고객은 웹을 통해 사용만하면 되느냐의 차이가 있지만, 표준 상품을 개발해 매스 마켓에 팔아야 한다는 점에서는 공통점이 크다. 이하에서 SW제품은 On Premise 제품과 클라우드 서비스 제품을 모두 포함하는 용어로 쓸 것이다.

2. SW제품 사업의 본질

Microsoft, Salesforce, SAP 등의 SW제품 사업은 표준 SW상품(Commercial off-the-shelf: COTS)을 On-Premise용 License로 또는 Software as a Service(SaaS) 클라우드 서비스로 Mass Market에 파는 사업이다.

SW제품 사업의 본질에 대해 이해하려면 MIT 교수인 Michael Cusumano가 쓴 The Business of Software 책을 읽을 것을 추천한다. 이 책에서 그는 "If the software business were like other businesses, there would be no need for this book.  But software is not like other businesses"라고 역설한다. SW제품 사업의 경영 모델은 어떤 다른 사업하고도 다르다. 제조업하고도 판이하게 다르고, IT서비스업하고도 판이하게 다르다.

SW제품 기업의 경영 모델이 어느 업종과도 달리 독특한 것은 SW 자체의 독특한 특성에 기인한다. SW는 기계와 달리 마손되지 않고, 재생산 원가가 제로에 가깝고, 아무 때나 멀리서도 변경할 수 있고, 역공학을 통해 쉽게 모방할 수 있다.

아래 표를 보면, Microsoft, Salesforce, SAP 등 SW제품 기업은 매출액 대비 30% 미만의 매출원가가 발생한다. 이와 비교해 삼성전자 같은 제조업은 재료비와 감가상각비 때문에 매출액 대비 60% 이상의 매출원가가 발생한다. SW의 재생산 원가가 제로에 가깝기 때문에 매출원가가 기계보다 훨씬 적게 든다.

SW제품 기업은 SaaS 서비스를 제공하기 위한 클라우드 센터를 제외하고는 재료나 설비가 필요하지 않고, SW제품의 개발과 연구에 소요되는 인건비와 판매/마케팅에 소요되는 경비가 원가의 대부분이다. 따라서 연구개발과 판매/마케팅에 얼마나 투자하느냐에 따라 영업이익이 위의 표에서 보듯이 15%~45%의 고수익을 시현한다.

SW제품은 제조업의 기계 제품과 달리 생산 설비나 재료가 필요하지 않아서, 시장에서 성공한 제품은 많은 경쟁업체들이 쉽게 빨리 모방할 수 있다. 따라서 SW제품 벤더는 신제품을 개발 출시하자마자 바로 업그레이드 개발에 투자해야 시장 경쟁력을 유지할 수 있으며, 이러한 지속적인 업그레이드 투자의 재원을 확보하기 위해 매년 유지보수 요금(라이선스 요금의 15~20%)을 추가로 받아야 하는 것이다. 만약에 고객이 유지보수 요금을 지불하지 않으면 신규 업데이트를 제공 받지 못하는 게 상례이다. SaaS 사업에서는 벤더가 SW를 호스팅하기 때문에 고객 기술지원이 필요 없고, 유지보수 및 업그레이드 요금도 월 또는 년별 서비스 사용료에 포함되어 있다.

3. IT서비스 사업과 SW제품 사업의 비교: 본질적 차이

IT서비스업은 본 시리즈의 3호(https://www.kosta-online.com/post/global-it-service-business-model) 에서 언급했듯이, 전문서비스업(Professional Service Business) 및 사람사업(People Business)에 속하며, 위 표의 Accenture 경우와 같이, 매출액 대비 60~70% 가량의 매출원가가 발생하며, 이 매출원가의 대부분이 전문가 인건비로 구성된다. 따라서 한계이익이 30~40%, 영업이익이 15~25% 발생한다. SW제품 사업은 인건비 비중이 상대적으로 작고, 무형자산에 대한 투자가 높아 사람사업에 해당하지 않는다.

IT서비스 기업은 자사의 IT전문가들이 개별 고객을 위한 맞춤형 SW를구축해 주고, 그 전문 용역 서비스에 대한 대가를 매출로 잡으며, 구축된 SW는 고객의 소유로 이전해 준다. 이와는 대조적으로, SW제품 벤더는 수많은 고객이 공통으로 쓸 수 있는 표준 SW제품을 연구 개발하여 자사가 소유권을 가지며, 고객에게는 사용권만 주되, 그 대신에 제품에 하자가 있을 때는 벤더가 책임을 진다.

이와 같이 IT서비스 기업은 고객마다 독특한 솔루션을 제한된 프로젝트 기간 동안에 구축해주는 역량과 고객 성공 성과를 많이 축적해 많은 고객으로부터 높은 평판을 유지하고, 그 평판을 바탕으로 프로젝트 수주를 많이 받아오는 역량이 핵심 역량이다. 반면 SW제품 벤더는 수많은 고객이 공통으로 쓸 수 있는 제품을 연구 개발하고, 끊임 없이 업그레이드하고, 또한 많은 판매가 일어나도록 Mass 마케팅을 잘하는 역량이 핵심 역량이다.

위의 재무제표에서 보듯이, SW제품 벤더는 한 개의 SW를 개발하여 많은 고객에게 파는 만큼, 고객마다 다른 SW를 만들어 줘야 하는 IT서비스 기업보다 한계이익이 높지만 (30% 대비 70%), 연구개발 비용과 판매/마케팅 비용의 투자가 훨씬 높아 (10% 대비 50%), 영업이익에서는 큰 차이가 안 나는 걸 볼 수 있다 (마이크로소프트 같은 예외도 있지만).

4. SW제품 기업의 경영 모델과 성공 요인

A. Volume Business (대량 판매 사업)

SW제품의 신규 판매에 따른 라이선스 요금의 수입은 1회성이지만, 기존 판매 고객으로부터의 유지보수 요금 수입은 매년 반복적으로 일어 난다. SW제품의 신규 라이선스 판매는 경기 변동에 크게 영향을 받고, 제품 시장이 포화됨에 따라 감소하게 마련이다. 따라서 불경기에도, 또 포화된 기존 제품을 대체할 신제품이 개발될 때까지 수익성을 유지하려면 충분한 고객 수를 확보하여, 반복성 유지보수 매출이 라이선스 매출과 대략 1:1의 비율을 유지하는 게 마람직하다.

SAP의 2010년 매출 구성을 보면, SW라이선스 요금, 유지보수 요금, 전문용역서비스 요금의 비중이 26%, 52%, 21%이다. 대부분 SW제품이 클라우드 서비스로 전환된 2023년 매출 구성을 보면, SW라이선스 요금, 유지보수 요금, 클라우드 사용요금, 전문용역서비스 요금의 비중이 7%, 35%, 40%, 18%이다. On Premise SW제품 구매보다 SaaS/PaaS 서비스 가입이 대세인 요즘, 신규 라이선스 판매는 7%로 감소하고, 클라우드 서비스 판매가 40%로 증가한 것을 볼 수 있다. 그런데도 기존 On Premise 제품 고객으로부터 징수하는 유지보수요금이 35%에 달한다는 것은 SAP이 기존 On Premise 제품들을 SaaS/PaaS 제품으로 전환하는 동안 유지보수 매출이 투자재원과 수익성을 지탱해 주었다는 걸 알 수 있다. SAP 같은 기업용 SW제품 벤더 경우, 제품 컨설팅과 교육을 위한 전문가 용역 서비스가 전체 매출의 20% 미만을 차지하는 게 상례이다. 다음 호: "IT서비스와 SW제품의 하이브리드 사업"에서 설명하겠지만, SW제품 기업에서 전문가 서비스의 매출 비중이 20%를 넘어서서 증가하기 시작하면 기업의 수익성이 악화될 위험 신호이다.

SaaS/PaaS 사업에 있어서는 유지보수 비용이 월 또는 년 사용료에 포함되어 있지만, SW 호스팅에 관련된 인프라 운영 및 경영 자동화 비용이 크기 때문에 많은 고객을 확보하여 고정비 비율을 낮추는 게 중요하다.

이렇게 SW제품 사업은 On Premise 제품이나 SaaS/PaaS 서비스 모두 소위 "Volume Business" 즉 고객 수가 매우 많아야 하는 대량 판매 사업이다. 기업용 SW제품은 단가에 따라 100~1,000+, 소비자용 SW제품은 10,000+개의 고객을 확보하는 게 재무적으로 안전하다.

B. Single Code Base to Single Instance (표준 기능의 단일 코드 베이스 내지 단일 인스턴스)

SW제품은 많은 고객이 공통으로 사용할 수 있는 표준 기능 세트를 제공해야 하며, 버전 별로 모든 고객이 동일한 코드 베이스를 사용해야 한다. 즉 개별 고객을 위해 SW 소스 코드 베이스를 변경하면 안된다. 만약에 고객 별로 소스 코드 베이스를 변경해 주면, SW의 유지보수 및 업그레이드를 고객 별로 진행해야 하고, 따라서 수익성과 판매 성장률이 악화된다. 원가 압박 때문에 업그레이드를 정기적으로 못하면, 기존 고객의 유지보수 계약마저 취소되는 상황으로 가서 재무적으로 위험해진다.

SaaS/PaaS 경우에는 모든 고객에게 단일 코드 베이스를 넘어서서 단일 인스턴스를 제공하는 게 바람직하다. 만약에 10,000명의 고객 별로 별도의 서버 인스턴스를 제공한다면, 단일 인스턴스 대비 1:10000의 서버 운영 비용이 소요될 것이다. 모든 고객이 단일 인스턴스를 사용하게 하려면, SW제품을 Multitenant 아키텍처로 설계 구현해야 한다. 한 연구에 따르면, SaaS 사업에서, 고객 별로 별도 인스턴스를 유지하는 Single Tenant 아키텍처를 적용할 경우 매출원가가 매출 대비 40% 정도에서, 모든 고객이 단일 인스턴스를 공유하는 Mutitenant 아키텍처를 적용하는 경우 10% 정도로 절감되는 것으로 나타났다.

C. Mass Customization (코드 베이스 변경 없는 고객 맞춤형 변경)

고객 별로 Customozation 요구가 큰 기업용 SW제품 경우, 소스 코드 베이스를 안 건드리면서 고객이 원하는 기능, 인터페이스, 데이터, 워크플로우 등의 변경을 할 수 있어야 한다. 즉 Mass Customization이 가능해야 한다. 이를 위해 메타 프로그래밍을 통한 Configuration 파라미터의 제공, 서비스 지향 아키텍처를 통한 API 기반의 Customization 및 프로세스 Orchestration 등의 고난도 기술을 적용해야 한다.

SaaS/PaaS 경우 단일 인스턴스를 유지하면서, 고객 별로 기능, 인터페이스, 데이터, 워크플로우 등의 Customization을 허용하려면, 매우 복잡한 아키텍처를 설계 구현해야 한다. Salesforce 경우, 소위 Metadata-Driven Architecture라고 해서, 고객 별 Customization을 위한 Configuration을 데이터베이스에 데이터로 저장했다가, 런타임에 Polymorphism을 통해 코드 실행에 반영하는 독특한 아키텍처를 발명하여 적용하고 있다.

Salesforce의 2013년 상황을 보면, 16개의 인스턴스로 70,000 고객을 서비스했고, 그 해에 30 여건의 메이저 업그레이드를 실시했으며, 18,800,000건의 고객 Customization을 실현했다. 그 해 한계이익은 78%에 달했다.

D. Service-Oriented Architecture (서비스 지향 아키텍처)

오늘날 같이 경쟁이 심한 SW제품 시장에서, 많은 고객이 공통으로 사용할 수 있는 표준 기능 세트로서 기존 경쟁 제품 대비 차별화된 혁신적인 가치를 지닌 기능 세트를 찾아내는 일은 결코 쉬운 일이 아니다. 고객이 절실히 필요로 하는 기능을 찾기 위해서는, 디자인 씽킹(Design Thinking), 린 스타트업(Lean Startup), 애자일 개발(Agile Development), 데브옵스(DevOps)와 같이, 조금의 추가 기능을 실은 제품 업그레이드를 (하루에도 여러번) 자주 출시하고, 고객의 반응을 계량적으로 분석하여 어느 기능을 버리고 취할 지 결정하는, 반복점증적 (iterative) 제품 개발 프로세스를 따라야 한다.

단일 코드 베이스를 유지하면서 이렇게 잦은 업그레이드를 추진하려면, 무엇보다 SW를 변경하기 쉽도록 (즉 Readability, Maintainability, Reusability가 높도록) 개발해야 한다. 사실 SW의 변경 용이성을 높이는 것은 SW공학의 가장 중요한 목적 중 하나이다. 모델 기반 설계, 객체 지향 프로그래밍, 객체 설계 원칙과 패턴, 리팩토링, 도메인 주도 설계(DDD), 서비스 지향 아키텍처, 마이크로서비스 구현 패턴 등이 모두 변경 용이성을 높이고, 배포 빈도를 높일 수 있는 기법들이다.

이중 서비스 지향 아키텍처(SOA)는 SW를 Loose Coupled, Functionally Cohesive 모듈로 나누고, 서비스라고 불리는 이들 모듈의 기능을 API로 노출하여, 모듈 간의 호출은 그 내부의 클레스 메소드나 데이터베이스에 직접 접근하는 대신 API를 통해서만 가능하도록 하는 아키텍처이다. 각 서비스는 API를 유지하면서, 그 백엔드의 구현은 타 서비스와 상관 없이 자유롭게 독립적으로 변경 가능해진다. 또한 서비스들을 달리 조합함으로써 제품의 기능 세트를 변경할 수 있고, 여러 버전 또는 여러 제품에 공통으로 쓰이는 서비스들을 재사용함으로써 업그레이드 및 신제품 개발을 가속시킬 수 있다.

오늘날 SOA는 기계에 내장되는 Embedded SW를 포함하여 모든 SW의 사실 상의 표준 아키텍처이다. 제4차 산업혁명과 디지털 트랜스포메이션도 SOA와 API, IoT와 AI, 클라우드를 기반으로 모든 SW가 인터넷 상에서 API로 연결되고, 주변 환경과 내부 상태 변화에 적응하여 지능적으로 자율적으로 의사결정,행동하는 방향으로 발전하고 있다. 이제 모든 SW제품은 명실공히 SOA 아키텍처로 설계 구현되어야 한다.

예컨대 Amazon은 2002년에 SOA를 회사 내 모든 SW의 표준 아키텍처로 채택했다. 2004년에는 회사의 데이터센터를 운영하는 ITSM SW의 많은 기능을 API로 노출하여 Infastructure as a Service(IaaS)를 발명 출시하였다. 그후 각 서비스를 컨테이너로 빌드하여 독립적으로 배포함으로써 SW 업그레이드 배포 주기를 몇 초 간격 수준으로 격감시키는 소위 마이크로서비스(Microservice) 구현 패턴을 채택했다. 그리고 수 천개의 DevOps팀이 각기 소수의 마이크로서비스에 대해 전적인 책임을 지고 독립적으로 기획, 분석, 설계, 개발, 배포, 운영, 변경하는 개발 체계를 갖추었다. 2015년에만 5천만개의 마이크로서비스를 배포하면서 (0.63초 당 마이크로서비스 한개 배포하면서) 전세계 고객들의 니즈를 반영하여 경쟁 우위를 지키고 있다.

E. SW인재관리 (Software Talent Management)

SW제품 사업은 창업자의 비전과 SW제품의 시장성도 중요하지만, 탁월한 SW 엔지니어들 없이는 성공하기 어렵다. 마이크로소프트 창업자인 Bill Gates가 항상 자사 직원들이 "전세계에서 가장 뛰어난 SW전문가의 팀"이라고 자랑하듯이, 마이크로소프트의 성공은 비범한 사람들을 채용, 훈련, 동기부여 및 유지할 수 있는 인재관리 능력에 기인하는 것으로 분석되고 있다 (Harvard Business School, Microsoft’s Vega Project: Developing People and Products, Jan. 8, 2001 참조).

전사의 필요 역량 분석(Competency Analysis)을 기반으로 전략적인 인력 계획가 인력 개발을 수행하는 SW인재관리는 SW제품사업에서 가장 중요한 경영 활동이다. 인재관리의 목적과 방법을 이해하려면, McKinsey에서 저술하고 하버드경영대에서 출판한 The War for Talent (2001), 카네기멜론대학의 SW공학연구소(SEI)에서 출간한 The People CMM: A Framework for Human Capital Management (2009), 그리고 The Talent Management Handbook: Making Culture a Competitive Advantage by Acquiring, Identifying, Developing, and Promoting the Best People (2017)을 참고할 것을 추천한다.

5. SW제품 산업의 발전 추이

아래 그림에서 보듯이, SW제품 사업의 성숙도가 가장 낮은 단계가 SW제품의 소스코드를 고객 요구에 맞게 변경하면서 라이선스를 파는 경우로, 이 경우에는 Single Code Base를 유지하지 못해 수익 동반 성장이 매우 어렵다.

다음 성숙 단계는 Metaprogramming 기반으로 Mass Customization이 가능한 SW제품을 개발하여 라이선스를 판매하는 경우로, Single Code Base를 유지하면서 수익 동반 성장이 가능한 사업 모델이다.

앞에서도 언급했듯이, 2000년대 초 시도됐던 ASP 사업 모델은 Metaprogramming 기반의 고객 별 Customization으로 인해 SIngle Instance를 유지할 수 없는 Single Tenant 아키텍처로 수익 동반 성장이 어려운 사업 모델이다. ASP 사업은 대부분 실패하거나 SaaS 사업 모델로 전환하였다.

2000년대 중반 SOA가 전세계로 확산되면서, 대부분 성공적인 SW제품은 SOA로 아키텍처를 변환하였다.

예건대, SAP도 2004년 SOA 구조의 ERP 제품인 Enterprise SOA를 개발 출시하였다. 종래 십수개의 모듈로 구성됐던 제품을 7,000여개의 SOA 서비스로 분할했고, 고객들이 원하는 서비스들을 원하는 프로세스로 조립하여 쓸 수 있도록 Netweaver라는 플랫폼도 같이 제공하였다. 오늘날에는 앞서도 지적한대로 모든 SW제품은 SOA 아키텍처로 개발하여 제품의 모든 기능을 API로 노출해야만 글로벌 시장에서 경쟁력을 갖출 수 있다.

2000년대 후반 클라우드 서비스가 전세계로 확산되면서, 대부분 SW제품 기업들은 자사 제품을 SaaS나 PaaS로 변환하였다. 이때 SaaS/PaaS를 Mutitenant 아키텍처로 개발하여 Single Instance를 모든 고객이 공유하도록 한 기업은 수익 동반 성장이 가능하고, 그러지 못하고 종래 On Premise 제품처럼 Single Tenant 아키텍처로 개발한 기업은 수익 동반 성장이 어려운 상황이다.

6. IT서비스 사업과 SW제품 사업의 비교: 유사점

SW제품 사업과 IT서비스 사업이 전자는 표준 상품(COTS)의 Mass 마케팅, 후자는 주문형 솔루션(Custome Solution)의 1:1 마케팅이란 점에서 큰 차이가 있지만, 한편 둘 다 SW 기반의 사업이란 점에서 공통점을 갖는다. 위의 SW제품 기업의 성공 요인 A~E 중 A, B, C (즉 Volume Business, Single Code Base / SIngle Instance, Mass Customization)은 IT서비스 사업에는 적용되지 않지만, D, E (SOA, SW Talent Management)는 접근 방법은 조금 다르지만 IT서비스 기업에서도 중요한 성공 요인이다.

2000년대 후반 SOA가 전세계로 확산되자 IT서비스 기업들도 고객 솔루션을 SOA 아키텍처로 구축하기 시작하였다. 예컨대, IBM은 2007년 당시 대부분의 글로벌 IT서비스 기업이 고객 솔루션 개발에 적용했던 Rational Unified Process를 SOA 아키텍처의 애플리케이션을 개발하는 프로세스로 개편하여 제공하였다 (U. Wahli et al., Building SOA Solutions Using the Rational SDP, RedBooks, IBM, 2007 참조). 유럽의 Capgemini사도 2009년 사내 훈련 커리큘럼을 보면 SOA를 필수 과정으로 포함하고 있다 (2009 Capgemini University Brochure 참조).

1990년대부터 글로벌 IT서비스 기업들은 Labor-Based Service(LBS)에서 Asset-Based Service(ABS)로 전환하기 시작하였다. ABS로의 전환은 고객 솔루션 개발의 결과와 경험(예컨대 업종별 애플리케이션 유형별 기능 요구 스펙, 원가 명세, 아키텍처 설계, 공통기능 소스코드, 실행가능한 애플리케이션 프레임워크 등)을 재사용 가능한 자산으로 축적하여 고객 프로젝트에 활용함으로써 개발 시간, 원가를 줄이고 품질, 생산성을 높이는노력이다. 오늘날 IT서비스 사업의 수익은 축적한 재사용 자산의 질과 양에 비례한다고 볼 수 있다. SOA가 확산되면서, 고객 프로젝트에 재사용 가능한 SOA 서비스의 리포지터리 내지 프레임워크를 구축하여 활용하는 것이 사업 수익 및 성장의 중요한 성공 요인이 되었다.

이제는 SW제품도 SOA 서비스의 조립이고, IT서비스 솔루션도 SOA 서비스 조립이다. 그렇다면 SOA 아키텍처의 SW제품과 IT서비스 솔루션 개발에 투입되는 SOA 아키텍처의 재사용 프레임워크는 뭐가 다른가? SW제품은 모든 타겟 고객이 원하는 모든 기능 중 예외적인 기능을 제외하고 최대한 구현한 솔루션이라면, IT서비스의 재사용 프레임워크는 모든 타겟 고객이 원하는 기능 중 공통 부분만을 구현한 솔루션이다. 즉 IT서비스의 재사용 프레임워크를 구성하는 서비스들은 SW제품을 구성하는 서비스들의 부분 집합이라 볼 수 있다. 따라서 이제는 SW제품 사업과 IT서비스 사업이 필요로 하는 SW인재에 있어서도 공통 부분이 상당히 있다.

IT서비스 사업에는 고객 프로젝트를 수행하는 인재와 재사용 자산을 개발하는 인재가 둘 다 필요하다. 전자는 보통 대학 졸업 후 바로 입사하여 사내 표준 프로세스, 방법론, 툴을 훈련받고 직무 직급 별 사내 역량 인증을 획득한 인재들이다. 후자는 SW제품 사업에 필요한 인재와 유사한 역량과 경험을 갖춘 인재들이다.

7. IT서비스 사업과 SW제품 사업의 비교: 전후방 연관관계

본 시리즈의 2호(https://www.kosta-online.com/post/structural-problems-of-large-it-service-providers-in-korea) 에서 언급했듯이, SW제품, SaaS, PaaS, IaaS, 컴퓨터 하드웨어 등은 IT서비스 제공 시 투입물로 사용되는 전방 산업이다. 마치 병원의 전방 산업은 제약 산업, 의료기계 산업이 있고, 건축시공 산업의 전방 산업은 건축자재 제조업이 있듯이, IT서비스의 전방 산업은 SW제품, 클라우드 서비스, 컴퓨터기기 산업 등이 있는 것이다.

아래 그림에서 보듯이, SW산업의 진화 과정을 보면, 먼저 1950년대에 IT서비스 산업이 생기고, 다음 60년대에 SW제품 산업이 생겼다. 1970년대부터는 IT서비스 기업이 고객 솔루션을 구축할 때, Custom 솔루션을 자체 개발하기도 하고, SW제품을 구매하여 이를 고객 니즈에 맞게 Customize하여 구현하기도 했다. ERP, CRM, SCM 등 SW제품 산업이 성장함에 따라, IT서비스 기업의 매출 중 자체 개발 서비스보다 SW제품 구현 서비스가 더 빨리 증가했다. SW제품 구현 서비스는 전방 산업과의 공생 관계를 강화하여 SW제품 산업과 IT서비스 산업 양 산업의 발전에 크게 기여해 왔다.

한편 IT서비스 기업들도 1990년부터는 고객 프로젝트에 재사용할 수 있는 반제품 자산을 구축하여 자산 기반 서비스( Asset-Based Service)를 확대해 나아갔다. 오늘날 업종 및 애플리케이션 영역 별로, SW제품의 구현을 선호하는 경우도 있고, 자산 기반의 IT서비스를 통한 Custom 솔루션 개발을 선호하는 경우도 있다.

2000년대 후반에 와서는 IaaS, PaaS, SaaS 등 클라우드 서비스의 확산으로, IT서비스 기업들도 고객의 IaaS 도입을 도와주는 Managed Service, 고객 솔루션을 PaaS 기반으로 개발하는 서비스, 고객에게 SaaS를 Customize하여 구현해주는 서비스 등 소위 Cloud Service Brokerage(CSB) 서비스를 확대해 왔다. 이러한 CSB 서비스도 전후방 산업 간 공생 관계를 통해 클라우드 서비스 산업과 IT서비스 산업 양 산업의 발전에 크게 기여해 왔다.