을의 Digital Finance 블로그(3)
국내 IT서비스 발전을 위해 - "우리는 좋은 SW를 만들고 있는가?"
국내 IT서비스 생태계에서 생산하는 SW를 간단한 전략 모델인 Wardley Map을 이용하여, 구분해 보고 우리가 얼마나 좋은 SW를 만들고 있는지 살펴보고자 한다.
Wardley Map은 Simon Wardley가 만든 모델인데, Digital/IT전략 수립 시 사용할 수 있는 간단하지만 유용하고 강력한 맵이다. X축에는 진화과정인 Evolution (Genesis-Custom-Product-Utility)를 나타내고, Y축으로는 가치사슬인 Value Chain (Invisible- Visible)을 나타내는데, SW 같은 IT시스템만이 아니라, 인간이 만드는 모든 상품/서비스를 매핑할 수도 있다.
X축 진화의 축을 보면, 모든 SW는 최초로 만들어졌다가, 맞춤 SW로, 그리고 상용 패키지, SaaS SW 제품으로 나아가 클라우드와 같은 일상품화, Commodity화 되어 간다. IT는 경쟁의 산물이고, Commodity화 되어 갈수록 기술은 점점 예측가능한 영역으로 움직이게 된다. 진화라는 척도에서 보면, Genesis /Custom 단계의 SW는 모두 Product/Commodity 단계의 SW대비 원시적인 수준이라고 오해할 수도 있겠다. 하지만 경쟁사와 차별화를 위해 전략상 Genesis/Custom 단계의 SW시스템을 만드는 경우가 대부분이다. 하지만 SW가 더 많이 사용되고 가치 있게 사용되려면, Product/Commodity 단계로 진화해 가야 한다는 관점에서 진화의 축은 많은 것을 설명해 준다. 기술은 사라지고, 더 범용화 되어 간다고도 하는데, 곧 구글의 검색, 네이버의 검색 뒷 단에 ChatGPT와 같은 초거대 AI가 자리 잡게 되는 세상이 도래하는 것을 보게 될 것 같다.
Y축 가치사슬 관점에서 보면, 사람의 눈에 보이는 visible한 가치사슬부터 보이지 않는 invisible한 가치사슬이 있다. 실제 많은 SW 시스템은 사람 또는 고객의 눈에 보이지 않는 Invisible한 많은 솔루션( SW Framework, Middleware 등)을 기반으로 만들어지고 있다. 통상 Visible한 영역의 컴포넌트는 우리가 자유도를 가지고 구성해 갈 수 있는 반면에, 보이지 않는 Invisible한 영역의 컴포넌트는 기술적으로 숨겨져 있기도 해서 상대적으로 자유도가 적다.
이해의 편의를 위해 Wadley Map에 AWS re:invent executive summit의 Jonathna Allen 세션에서 사용된 금융 Contact Center 솔루션을 매핑해 보면 다음과 같다. 고객센터 상담원과 통화하든, 모바일 고객서비스 앱을 활용하든 우리가 사용하는 많은 금융 서비스는 더 많이 클라우드 상의 SaaS 제품과 Managed 서비스, Commodity를 이용하게 되는 것을 직관적으로 보여준다.
상기 Wardley Map 기준으로, 우리가 만드는 SW를 나누어 보면 맞춤 SW 영역 (Genesis-Custom 단계)과 구매하는 상용SW (Product-Utility 단계)으로 구분해 볼 수 있다.
1) 우리는 좋은 SW를 만들고 있는가?
맞춤 SW, Custom Built 영역에서는, 기업이 직접 SW시스템을 구축하거나, 또는 SI사를 통해 구축하는 방식으로 SW를 만든다. 국내 금융기관의 경우, 자체 인력 비중이 적은 관계로 대부분 외부 IT서비스 회사를 통한 구축방식이 많다. 외견상으로는 국내 IT서비스업은 높은 성장세를 시현하고 있는 것처럼 보인다. SDS, LG CNS, SK등 대형 그룹사 소속 SI회사를 필두로, 많은 금융 SI회사들이 존재하고 있고 수많은 금융시스템을 맞춤 방식으로 개발한다.
하지만 과연 좋은 SW를 만들고 있는가? 과연 비지니스 가치를 내고 있느냐는 질문을 하면서 뒤 돌아보면 자신 있게 비지니스 가치를 창출하고 있다고 답하기 어려웠다. CIO역할에서건 CEO역할을 할 때 이건 결국 투자대비 비지니스 가치를 얼마나 창출했는가하는 그 당시 비지니스 상황에 따라 판단해야 할 질문이었다. 발전적인 방향을 논의한다는 관점에서, 잘했던 것보다 더 잘하기 위한 관점에서 몇가지 관점을 공유해 보고자 한다.
첫째, 상용 SW로 처리할 수 있는 업무를 굳이 맞춤 SW로 만드는 건 아닌지 자문해 봐야 한다. 차별화 대상이 아닌 총무구매업무도 루이뷔통 명품처럼 수작업으로 맞춤 SW로 개발하기도 한다. 우리나라 SI에서는 비지니스 가치가 적은 기능도 패키지SW보다 맞춤으로 개발하는 경향이 아직도 강하다고 생각한다. 소위 IT, 패키지를 이용해서 일하는 방식을 바꾸고자 하는 노력은 90년대 이래로 BPR, Package Driven Transformation 등 여러 가지 이름으로 시도되어 왔다. 국내에서 제조업은 ERP(전사자원관리) 시스템을 통해, 일하는 방식과 비지니스 프로세스를 변화시켜 왔고, 패키지 도입에 대한 거부감이 적은 편이다. 반면 금융업에 있어서는 현재 일하는 방식을 바꾸기보다, 전략적으로 차별화하기 힘든 업무까지 수작업 명품으로 만들려고 하는 경향이 있다고 생각된다. 해당 현업 담당자 입장에서야, 본인이 하는 업무를 명품으로 만들고 싶은 생각이야 많겠지만, 이미 상용SW로 명품이 존재하기도 하고, 이를 따라 비지니스 프로세스를 변화시키면 해당 프로세스의 경쟁력을 높일 수 있는 이점도 많다. 무엇보다 자체 인력과 외부 파트너사 인력들을, 이미 상용SW로 해결된 문제를, 다시 SW화 하는 데 투입함으로써 초래하는 기회비용이 가장 크다고 생각한다. 과거 대비, SaaS 제품부터 더 다양한 상용SW 옵션이 많아졌다. 통상적인 Buy or Build 전략에 대한 옵션을 현업과 IT가 더 많이 고민해봤으면 한다.
모 그룹 IT회사에서 그룹 HR시스템을 담당하고 있었는데, 실제로는 계열사별로 4~5개 버전을 관리하고 있어서 발전방향을 계열사 IT, HR과 협의를 진행한 바가 있었다. 사업에서 손익이 나지 않고 있었고, 투입된 인력들도 IT전문가로 발전할 가능성이 적었다. 하지만 전통적으로 파워가 있는 계열사 HR부서를 대상으로, 설득하는 작업은 쉽지 않았고, 추가적이 비용을 청구하기도 어려운 상황에서, 패키지 버전 수를 줄이는 데에도 노력이 많이 들었던 기억이 난다. IT개발자들의 가치가 더 커진 지금이었다면 상황이 어떠했을까 생각해 본다.
참고로 22년 말 시가총액 83조원인 싱가포르 개발은행 DBS도, 인소싱 비중이 95%에 달하고 년간 1조 가까운 IT예산을 집행하지만, 코아뱅킹은 외부 패키지를 사용한다고 한다. 중요한 것은 코아뱅킹이 만들어 내는 데이타를 어떻게 사용하여 비지니스 가치를 창출할 것인지에 초점을 맞추고, AI, Data, Cloud에 더 투자하고 있다. 반면에 국내에는 Corebanking 시스템을 패키지로 사용하는 금융기관은 거의 없다.
둘째, 자체 인력으로 구축하기보다는, 외부 SI사를 통한 구축이 대부분으로 외부 의존도가 너무 크다는 점이다. 차별화할 수 있는, B2C 디지털 플랫폼을 자체개발하고 맞춤 SW로 구현하는 것은 이제는 당연하다고 생각한다. 문제는 자체 개발 인력 부족으로, 대부분의 디지털 플랫폼이 외부 SI사에 발주해서 구축하고 있는 현실이다. 특히나 디지털 플랫폼은 Agile 방식으로 개발하면서, 지속적인 변화에 대응해 가야 하는데, 전통적인 SI 계약관계를 통해 해결하려다 보니, 근본적인 문제 해결이 되지 않는다. 자체 개발인력이 참여하지 않다 보니, 운영 과정에서 지속적인 개발과 변화를 반영하기 어렵다. 결과적으로 고도화, 업그레이드라는 명칭으로 1~2년 주기로 반복적인 SI개발 프로젝트를 계속 진행할 수밖에 없는 경우가 많았다.
셋째, 기술 중심으로 대형 프로젝트가 진행되는 경우가 많다. 우리나라 금융시스템은 빠르면 7~8년 늦어도 10년에 1번은 차세대를 진행해 왔다. 압축성장을 하다 보니, 우리는 Mainframe에서 Unix로 Linux로 빠르게 기술을 Catch Up해 왔다. IT서비스 생태계의 발전을 위해서도, 새로운 기술을 도입하여 인력을 양성하고, 새로운 비지니스 기회를 모색하는 것은 좋은 전략이라고 생각한다. 하지만 20년 전의 차세대 계획, 10년 전의 차세대 계획, 요즈음의 차세대 계획을 보면 기술기반이 바뀌는 점을 제외하고 비지니스 적인 관점의 변화가 크게 달라 보이지 않는다. 기술은 더 복잡해졌지만, 모든 것이 확실하고 미래가 보장되어 있을 때 수립했던 경제개발 5개년 방식으로 차세대 계획을 수립하고 있는 것은 아닌지 돌아봐야 한다고 생각한다. 전체적인 전략부터 Big Bang 보다는 단계별 modernization 접근법으로 진행하면서, 기술과 비지니스가 더 깊은 아키텍처 단계에서 조율되고, 기술 용어와 비지니스 용어가 서로 상호 통역되면서 최적안을 모색하는 커뮤니케이션하는 것이 더 바람직하다고 생각된다.
필자가 글로벌 금융기관의 CIO 역할을 할 때, 미국, 일본의 선진금융기관들이 아직도 많이 Mainframe을 사용하고 있는 것을 보았다. 변화가 적은, 안정적인 비지니스 영역에 한정하여 사용하고 있었는데, 무엇보다 계정계 시스템이 여러 벌이 있기도 했다. M&A를 통해, 피합병 법인의 코아 시스템들을 수용하여 유지보수 운영하면서, 통합이 필요한 고객서비스, 경영관리 리포팅 영역들만 시스템을 통합하고 있었다. 국내처럼 M&A를 하면 무조건 시스템을 통합하는 대규모 프로젝트 진행하는 방식과는 많이 달랐다. 합병 법인 간의 정치적 이슈와 변화관리 이슈도 고려해야 하지만, 대규모 프로젝트인 만큼 비용 대비 효과를 분석할 때, 아키텍처적인 입장에서 여러 옵션을 진지하게 검토하는 것도 필요하다는 생각이다.
2) 우리는 좋은 상용SW를 만들고 있는가?
우리가 구매하는 상용 SW 영역에서 보면 글로벌 SW회사 대비 가치를 창출하는 국내 SW회사가 극히 적다. 글로벌에는 MS, Oracle, SAP, Salesforce와 같은 경쟁력 있는 SW가 많은 반면에, 국내에는 한컴, 티맥스, 더존 정도의 SW회사들이 있고 대부분은 완성도 낮은 SW를 가진 더 영세한 SW회사들이 존재한다. 과도한 Customize를 요구하는 환경, 구매하기보다 스스로 만드는 맞춤SW를 선호하는 경향, 검증된 솔루션을 고집하는 관행, 국내 SW에는 정상적인 License를 지불하지 않는 관행들이 국내 상용SW시장의 발전을 저해하고 있다. 최근 SaaS Product들이 출시되고 있는 것은 바람직한 현상이나, Enterprise Application영역에서의 SaaS Product를 만들기에는 국내 환경이 너무 척박하다는 생각이다.
금융사 CIO를 하다가 모 제조, 유통 그룹의 IT계열사에 을로 근무할 때 우리나라 IT생태계에 대해서 더 많은 것을 알게 되었다. 을의 입장에서 많은 소규모 SW솔루션 회사와 일 하면서, 국내 중소 SW회사 대표들의 어려움과 도전에 대해서도 더 많이 공감하게 되었다. 그때부터 더 중소기업 대표들을 존경하게 되었는지 모르겠다. 이하에서는 국내에서 상용SW의 발전을 저해하는 몇 가지 요인을 공유해 보고자 한다.
첫째, 맞춤형 SW에 대한 선호현상과도 맞닿아 있는데, 상용SW에 대해서 커스터마이징 요구가 과다하다.
해외 금융기관의 경우, Core Banking 패키지부터 주식, 채권, 파생상품 등 자본시장 패키지에 이르기까지 많은 패키지 솔루션을 활용한다. 반면 국내 금융기관의 경우에는 패키지 솔루션이 설 자리가 거의 없었다. 가장 큰 이유로는 커스터마이징 요구가 크다는 점이었다. 해외 패키지를 도입할 때 국내 금융기관에서는 많은 어려움을 겪었다. 모 보험사에서 SAP시스템을 기간계로 구축하면서 치른 시간과 비용은 유명한 사례이다. 글로벌 프로세스 대비 생각보다 국내 금융 프로세스가 고유한 것이 가장 큰 이유이다. 반면에 주식, 채권, 파생상품 등 글로벌 패키지를 적용하는 경우에도, 많은 어려움이 있었다. 많은 경우 국내 금융기관의 커스터마이징 요구가 받아들여지지 않았다. 생각보다 국내 금융기관이 요구하는 변경사항이 해외패키지사 입장에서 볼 때 범용성이 떨어진다고 판단한 것도 주요 이유였다. 글로벌 패키지에 맞게 업무 프로세스를 바꾸는 것이 더 비용효율적이고 효과적일 수 있는데, 프로세스 변경을 위해 현업과 협의하기는 정말 어려운 일이었다. 더구나 빠르게 발전하는 국내 금융환경에서, 현업의 변동도 많아서 기존의 업무요건조차 제대로 설명해 줄 수 있는 전문가도 없었다. 당연히 프로젝트가 지연되고 비지니스 가치를 창출하는 데 수년간의 시간이 더 소요되었다.
특히 국내SW기업에 대해서는 더 많은 커스터마이징을 요구한다. 상대적으로 을의 입장인 국내SW 기업 입장에서는 수지 타산이 맞이 않는 커스터마이징을 많이 반영하게 되고, 기술력과 자본력이 없이는 상용SW로 발전해 나갈 정도의 SW를 만들기는 정말 어려운 환경이다.
카카오뱅크가 전북은행 코아뱅크 패키지를 사용하는 등 몇 가지 사례가 있지만, 카카오의 경우는 Front End에 경쟁력이 있다고 보고, 디지털 플랫폼에 전략적으로 집중한 케이스였다. 종종 금융기관이 차세대를 구축할 때 유사 금융기관의 패키지를 구입하여 사용하는 경우도 있는데, 대부분은 Asset으로 가져와서, 많은 부분은 커스터마이즈하는 것이 보통이다. 만약 패키지에 맞추어 프로세스와 조직까지 변경한다면, 커스터마이징 비용의 상당 부분을 절감하고, 더 나은 프로세스로 변경할 수 있을 거라고 보지만, 실제로 이런 방식을 택하는 경우는 거의 없는 거 같다.
둘째, 상용SW구매 관행도 재검토되어야 할 사항이 아닌가 싶다. 특히 금융권에서는 검증된 솔루션, 유명 외산 브랜드 SW를 선호하는 편이다. 레퍼런스를 많이 요구하는 데, 상대적으로 국내SW솔루션은 적용한 곳이 많지 않다. 업체와의 유착 등도 의심을 받는 상황이 많다 보니, 외산 브랜드를 선호하기도 한다. 한때 IBM 솔루션를 구매하는 것을 선호했던 구매 담당자는 그 이유 중의 하나로, 상대적으로 깨끗한 영업을 하는 글로벌 기업 이미지를 들기도 했었다. 연간 SW 라이선스 비용도 글로벌 기업의 SW가 구입가격의 20%대인 반면에, 국내 SW의 경우 구입가격의 10%를 넘지 않는 저렴한 경우가 많다.
올바른 구매결정을 위해서는 프로젝트를 책임지는 현업, IT 그리고 구매부서 각자의 자리에서 Risk taking을 해야 하는데, 환경적으로 감사와 컴플라이언스가 강한 금융기관 특성상 구매 프로세스를 개선하는 것은 어려운 문제이다.
전체적으로 볼 때 개별 담당자 입장에서 보면 합리적인 선택이지만, 우리나라 SW산업 발전을 위해서는 구매자, SW판매기업이 서로 Win-win 할 수 있도록 국내SW구매에 대한 세액공제 등 제도적인 지원도 있어야 하지 않을까 싶기도 하다.
하지만 최근 국내 SaaS 기업들이 많이 등장하고 있는 점은 고무적이다. 협업 툴, 인프라 모니터링 등에 집중되어 있고 아직 비지니스 애플리케이션 영역까지 확대되지는 않고 있지만, 클라우드 네이티브 기술이 발전하면서 점점 더 영역을 확장해 갈 것으로 예상된다. SaaS 비지니스 애플리케이션의 경우, 가장 중요한 포인트는 사용자들이 얼마나 수용성이 있느냐 하는 점이라고 생각한다. 기술적으로 Cloud Native는 아니지만, 글로벌로 유명한 Corebanking SaaS 패키지 중의 하나인 manbu는, 금융기관 고객을 설득하여 패키지의 비지니스 프로세스를 수용하게 하는 기술영업 인력이 강하다고 한다. 우리나라 SW기업들도 더 경쟁력있는 SW를 만들고, 금융기관 고객을 설득하는 힘을 더 기르기도 해야겠지만, 금융기관 내부에서 상용SW에 따라서 비지니스 프로세스도 변화시켜 보겠다는 생각의 전환들도 가속화되었으면 한다.
점점 더 노동집약적인 인력중심의 SI보다, Asset 기반, 나아가 Product/ SaaS 기반의 IT서비스 사업모델로 발전해 가고 있다고 생각한다. 코로나가 종식되어 가면서, 갑자기 불어닥친 R의 공포와 긴축으로 다시 일시적으로 사람보다 자본, 돈의 중요성이 커지고 있다. 하지만 기술보다는 사람이 우선이다. 팬데믹 기간에 상승한 디지털, IT인력의 인건비는 임금의 하방경직성으로 쉽게 내려가지는 않을 거 같다. SW는 가능한 재사용되고 더 널리 활용되어야 한다. 우리나라 IT서비스 산업도 인력중심에서 Product/SaaS 중심으로 더 발전해 가기를 기대해 본다.
