개발자 동봉 수출 아니면
글로벌 진출 못하는 이유
완성품에 대한 개념 부족
기업용 비즈니스 애플리케이션 솔루션을 개발하고, 국내 시장을 선점한 것 까지는 좋았지만, 이후 글로벌 시장의 문을 두드리다 보니, 글로벌 시장에 대한 자사의 대응력이 자사 개발자 투입 능력에 비례한다는 사실을 발견하게 된다. 솔루션에는 화려한 기능을 담고 있으나, 이를 지역화(locale) 하고, 각 지역에 적합한 비즈니스 프로세스와 데이터가 재구성되어야 하는 이슈에 대응할 수 있는 수단으로, 솔루션 개발자의 직접 투입 아니면 해결할 수 없다는 점을 깨닫는 것이다. "각 지역 특성을 몰랐다. 지역 전문가의 지원이 정부 정책적으로 지원되었으면 좋겠다". 글로벌 시장을 두드렸으나 실패한 솔루션 기업의 대표님들을 만나면 하나 같이 이렇게 실패 이유를 댄다. "개발자를 동봉하지 않으면 안 되는 솔루션 품질 때문이었다"라고 아무도 말하지 않는다. 심지어 개발자 동봉은 당연한 것 아니냐며, 실패 이유는 지역 특성을 너무 몰라서라고 강변하는 분들도 절반 이상이다. 무엇이 문제일까.
개발자 중심 사업의 솔루션은 시장 팽창 한계선 분명
솔루션 개발자가 시장의 커스터마이징이나 확장 이슈에 직접 참여하지 않아도 되려면, 솔루션을 커스터마이징 하거나 팽창하기 위한 수단을 솔루션 내에 내재해야 한다. 그리고 그 수단을 각 지역 전문가 (로컬 파트너)가 사용해 알아서 해당 지역 사업을 할 수 있게 해야 한다. 일반 정보시스템 개발하듯 개발된 애플리케이션 솔루션으로 글로벌 채널 사업을 할 수 없는 이유다. '프로그램 소스를 100% 혹은 블랙박스 부분을 제외한 소스를 오픈해줄 테니, 당신들이 알아서 해라'라고 밖에 할 수 없다. 하지만 이런 유형의 채널 비즈니스를 하게 되면 비즈니스와 솔루션에 대한 '거버닝' 문제가 생기며, 블랙박스의 소스가 제공되지 않으므로 인한 커스터마이징의 한계로 결국 사업 팽창에 실패할 수밖에 없다(자사 개발자 투입으로 대응할 수 있을때까지가, 사업 팽창의 한계다).
솔루션 제작사의 '완성품' 개념 부족
투입 인력 기반으로 운용되는 산업기반이다 보니 빠른 기능 구현에 초점을 맞춰, 동작하는 애플리케이션을 만들어 내는 것에 집중한 결과다. 빠르게 확인할 수 있고, 빠른 성과를 얻을 수 있다는 이유로, 커스터마이징과 기능 확장 수단을 솔루션에 내장하기 위한 애플리케이션 플랫폼 연구 개발에 대한 필요성 조차 고민하지 않는다. 커스터마이징을 위해서는 개발자가 반드시 투입될 수밖에 없다는 프레임을 만들어 놓았다.
여기서 중요한 것은, 대한민국 개발자들의 역량이 부족해서 아니라는 점이다. 개발자들이 그동안 받았던 개발 요구사항의 품질 문제가 근본적인 원인이다. '빨리빨리'와 '투입 인력'에 민감한 국내 소프트웨어 산업 풍토가 우리를 지속적으로 망쳐 놓고 있다. 경영자나 솔루션 개발자 모두, 국내 시장에서 이런 니즈를 위한 자극을 자극을 전혀 받지 못하고 있다. 대한민국 소프트웨어 산업 프레임의 근본적 문제이고 구조 조정이 필요한 이유다.
보편적 소프트웨어 개발 기술과 방법론에 몰입되어 있는 국내 개발자
최근 마이크로 서비스 아키텍처(MSA)와 웹 컨테이너 기술, 그리고 이를 잘 조합하기 위한 오케스트레이팅 프레임웍이 웹 서비스의 최신 기술로 각광을 받고 있다. 그 이전에는 SOA(Service Oriented Architecture)라는 키워드가 있었고, 국내외 할 것 없이 너도 나도 SOA 용어 세일즈에 나섰다. 필자가 기억하기로는 2003년경 SAP에서도 SOA라는 키워드를 마케팅 전면에 내세웠다.
하지만, 이런 보편적 기술 키워드나 방법론이 솔루션을 '제품화' 해주거나 'SaaS화' 해주지는 못한다. '보편적 시스템 구축 기술'과 '제품화 기술'은 그 아키텍처에서부터 다르기 때문이다. 모든 소프트웨어 제품은 아키텍처가 사실 하나인데, 바로 '엔진-프로퍼티' , 그리고 '프로퍼티를 세팅하는 설정 도구'가 그것이다.
'설정 도구'는 솔루션 비즈니스 체인에서 솔루션 직접 개발자 외의 참여인원들이 '커스터마이징 이과 기능 확장을 할 수 있는 수단 역할'을 하고 있고, 이런 사업 비즈니스 모델이 가능하지 않다면, 완성품도 아니요, SaaS를 통한 글로벌 웹 서비스로의 확장도 어렵다.
'제품화 & SaaS화 아키텍처' 무엇이 달라야 하나
제품화 개발에서는, 눈에 보이고 돌아가는 사용자 기능을 절대 프로그램 코드로 일대일 매핑해 개발하지 않는다. 일반 애플리케이션 (정보시스템) 개발은 사용자 요구 업무 처리 요구 사항을 모두 프로그램 코드로 바로 구현하지만, '제품' 혹은 'SaaS 앱'은 이런 사용자 업무 처리 요건을 모두 '프로퍼티'라고 부르는 데이터로 구성해 모아 놓는다. 파워포인트 같은 오피스 소프트웨어 제품뿐만 아니라 SAP나 세일즈포스닷컴과 같은 서비스 내 애플리케이션들 역시, 세부 구현 기술은 다르지만 모두 이런 공통된 아키텍처를 가지고 있다. '설정 도구'나 '확장 수단'을 통해 '프로퍼티'를 재구성하는 방식을 취하고 있다. 이런 구성 방식이 아니면, 다국적 기업 대상의 서로 다른 요구나 환경을 수용할 수 없다.
국내 SI 식 애플리케이션 개발 사업하는 기업들이 '제품화/SaaS화' 역량을 가지지 못한 이유가, 서로 다른 아키텍처 차이에 대한 경험이 없기 때문이다. 솔루션을 제품화하거나 SaaS화 하기 가장 힘든 조직이 국내 대형 SI/SM 기업이라는 현상도 이런 '무경험'과 개발자 노동력 기반 사업 형태에 원인에 있다.
'제품화 & SaaS화 품질' 평가 기준도 없는 나라
GS인증을 비롯해 국내에 꽤 많은 소프트웨어 품질 관련 인증 제도가 존재하지만, 개발된 소프트웨어가 '제품'으로서 글로벌 시장에 유통될 수 있는 사업 모델이 가능한지 평가할 수 있는 인증제가 없다. 플랫폼 사업이 '사용자 네트워크를 얻어 내는 사업'이라는 관점에서, 보편적 정보시스템 구축 방식의 애플리케이션들은 '플랫폼 사업화' 자체가 어불성설이다. 사용자 층을 넓히고 확대해 나가기 위해, 자사 보유 엔지니어만으로 커버할 수 있는 데에 한계가 분명하기 때문이다. 그래서 애플리케이션 솔루션 제품의 품질은 '소스 품질' 관점이 아니라, '플랫폼 사업화'가 얼마나 가능한가? 또는 '솔루션 직접 개발자 참여 없이, 다른 이가 할 수 있는 범위가 얼마나 되는가?'라는 관점에서 측정이 필요하다.
보편적 기술 기반의 접근만으로는 '완성품'도 'SaaS화'가 어렵다. 어떤 기술을 사용했는가라는 관점이 해당 솔루션(서비스)의 품질과 글로벌 경쟁력을 특징짓지도 않는다. 최신 스프링 클라우드나 MSA & 컨테이너 기술 사용해 서비스를 개발하고 서비스하면 클라우드 웹 (앱) 서비스는 된다. 하지만 그것만으로는 세일즈포스나 서비스나우 같은 SaaS 서비스가 되지 않음을 알고, 이를 해결하기 위한 슈팅과 도전이 필요하다.
100억 수출, 200억 수출이라는 당장의 실적주의에서 벗어나야 한다. 100명, 또는 200명의 개발자 수출이 아니라, '이거 줄 테니 너희가 맘대로 해'라고 할 수 있는 애플리케이션과 애플리케이션 플랫폼(변경 및 확장 수단)을 함께 던져 줄 수 있어야 한다. 개발자가 앞으로 할 일은 눈에 보이는 업무 기능 구현이 아니라, 자신이 만든 애플리케이션을 남들이 보다 쉽게 바꿔 쓸 수 있는 소프트웨어 개발이다. 대한민국 소프트웨어 개발자 양성 목표도 이에 준해 육성해야 한다. 웹 퍼블리셔나 데이터베이스 입력 수정 삭제 조회 프로그래머들만 백날 양성해도 국가 소프트웨어 경쟁력 향상에 도움이 되지 않는다.
