모든 기업이 디지털 트랜스포메이션이라는 새로운 목표를 설정함과 동시에 애자일이라는 말이 유행어처럼 퍼진 지 꽤 되어간다. 그러나 그 민첩성을 갖는다는 것은 무엇인지, 그것이 기업에 어떤 영향력을 가져다준다는 것인지는 피부로 와닿지 않는다. 단순히 애자일이라는 것이 빠르게 제품이나 서비스를 딜리버리 하는 프로세스를 보유하는 것을 의미하는 것인지, 실제적으로 조직의 혁신을 통해서 수익에 강력한 영향력을 갖게 한다는 것인지에 대한 정의도 명확하지 않다.
안정성이라는 것이 최고의 가치로 설계된 전통적인 기업조직에는 정적이면서 사일로화 된 구조가 있다. 목표와 의사결정권은 아래로 흐르고 가장 강력한 거버넌스 기구가 맨 위에 존재한다. 이러한 조직은 안정성에 기반한 이익의 가치수립을 위해 계획 및 통제를 통해 운영된다. 그러한 구조는 강할 수 있지만 변화에 느리게 움직인다.
이와 대조적으로 민첩성(Agility)을 가진 애자일 조직은 안정성과 역동성을 모두 고려하여 설계되었다. 기술을 중심으로 모든 이해 관계자를 위한 가치를 창출하기 위한 공통 목적에 따라 빠른 학습 및 빠른 의사 결정 주기를 특징으로 하는 팀 네트워크로 구성된다. 이러한 민첩한 운영 모델을 통해 전략, 구조, 프로세스, 인력 및 기술을 가치와 효율에 의해 재구성한다. 애자일 기업은 현재의 우선순위를 가치 창출 기회로 빠르게 전환이 가능해야 한다. 기업의 민첩성을 이야기할 때 나오는 일반적인 오해는 속도와 유연성을 강조하다 보면 안정성과 규모를 희생해야 한다는 것이다. 진정한 애자일 기업이라면 이 두 가지 중 한 가지를 포기한 상태가 아닌 유기 결합한 형태가 된다.
민첩함을 보유하기 위한 기업의 혁신 과정에서 기업 내 디지털 타워역할을 담당하는 IT업무에 필요한 변화를 정의 하는 것은 그 후에 나타나는 여러 지표를 통해서 그 변화가 경쟁력과 수익에 미치는 영향을 확인할 수 있을 것이다.
최근 10년간 디지털 네이티브라고 하는 혁신적인 디지털 기업의 등장은 기존의 선도 기업들에게 더 빠른 속도와 더 유연한 사용자 경험, 고 품질 서비스를 위해 근본적인 비즈니스 운영 모델을 변화시켜야 생존 경쟁력을 가질 수 있다는 것을 보여주었다. 실제로 기존 기업이 전통적인 프로세스, 기술, 그리고 기존 인력으로 제품을 생산하면서 동시에 높은 수준의 디지털 서비스 제공을 어려워하는 반면, 디지털 신기술로 무장한 새로운 기업은 모바일 우선 서비스와 한 차원 높은 사용자 경험을 신속하고 편리하게 제공함으로, 시장을 빠르게 잠식할 수 있었다. 이 현상은 개인금융 서비스나, 커머스과 같은 전통적인 서비스에서 매우 명확하게 나타난다.
기업의 IT업무에서 애자일 하다는 정의는 얼마나 많은 ‘비즈니스 역량(Business Capabilities)’를 수행할 수 있느냐에 있다. 이 역량이라는 것은 기존 시장 체제에서 이기기 위한 비즈니스 스피드, 생산성, 효율성만을 의미하지 않고, 디지털 네이티브와 경쟁할 수 있는 속도, 품질, 사용자 경험을 모두 포함하고 있다. 디지털 네이티브가 갖고 있지 못한 수많은 고객경험과 그동안 구축한 비즈니스 프로세스가 강점으로 나타날 수 있는 구조의 변화를 포함하는 것이 주요 비즈니스 역량이 된다.
그 변화의 방향은 비즈니스와 IT의 공동리더십을 통해 경쟁력을 확보하는 것이다. 그 경쟁력을 확보한 민첩함을 가진 조직은 다음과 같은 뚜렷한 구별점을 가진다.
• 모든 구성원들에게 조직 목표가 매우 명확하다.
• 비즈니스 역량 수행을 위한 권한이 부여되고 커뮤니케이션이 투명하다.
• 빠른 결정과 새로운 경험에 대한 학습과 공유가 활발하다.
• 차세대 구현 기술을 도입하고 적용하는데 적극적이다.
이 구별점을 갖게 하는 엔진 역할이 비즈니스 중심의 IT 업무 체계를 갖는 것이다. 그 중심에 있는 4가지 대전환에 대해서 알아보자.
기업의 살림을 맡아서 하는 최고 운영 책임자(COO: Chief Operating Officer)의 관점에서 보면, IT그룹은 많은 프로젝트가 진행이 늦어지고 예산은 초과되기에, 생산성면에서 매우 부정적인 인상을 갖는다. 반면에 기업의 디지털 전략을 총괄하는 최고 정보 책임자(CIO: Chief Information Officer)의 관점에서는 IT부서가 시시 각각으로 변하는 다른 비즈니스 부서의 요청 사항에 대응할 능력을 초과하고, 그 새로운 요청사항들은 시간과 인력이 많이 소요된다는 고충을 이야기한다. 이런 부서간 비즈니스 및 IT 요구 사항을 정의하고 조정하는 프로세스인 경우, 수직적이고 사일로가 되어있는 전통적인 조직 구조라면 실제 그것이 시행되기까지 수개월이 걸린다.
이렇게 서로간의 다른 관점을 이해하려면 새로운 협업 모델을 필요로 한다. 요구사항을 처리하는 고립된 IT 부서에서 벗어나 비즈니스 라인과 IT 전문가가 혼합된 퓨전 팀 (다기능 팀)으로의 전환이 필요하다. 무엇보다 먼저 실행을 확실히 보장할 수 있는 만큼의 양과 수에 해당하는 업무 프로세스를 세팅하는 것이 중요하다. 그 후에 개발, 출시 및 피드백 통합의 속도를 높임으로 퓨전팀의 효과를 팀 스스로 인식하는 것이 중요하다. 팀은 미션 수행에 필요한 모든 기술 (비즈니스, 개발 및 테스트, 사이트 운영)을 갖춘 5~9명의 전문가로 구성된 "BizDevOps" 퓨전팀이 된다.
비즈니스 팀 구성원에는 고객의 목소리와 ROI를 기반으로 제품 요구 사항을 주도하는 프로덕트 매니저(오너), 프로덕트 전문가 및 고객 경험 전문가를 포함한다. 엔지니어링은 서비스 딜리버리를 주도하는 개발자와, 딜리버리 이후에 안정적으로 지속적인 릴리스와 자동화를 추진하면서 고객 대응을 할 수 있는 운영의 역할로 나누어 진행한다. 같은 토픽에 대한 상황과 달성 목표를 공유함으로 팀은 요구 사항 조정 시간을 단축하여 시장 출시 시간과 의사 소통 지연문제를 근본적으로 줄일 수 있는 효과가 있다.
또 다른 중요한 점으로는 BizDevOps 퓨전팀은 주어진 시간대에 하나의 프로젝트만을 수행하는 것이 아닌, 비즈니스의 다른 영역을 동시에 병렬 지원한다는 것이다. 하나의 팀에 구성원을 고정 할당하는 것이 아니라, 전문가들을 모으고 해체하는 것이 매우 유기적으로 구성 가능하게 하여, 전문가는 다수의 팀에서 업무를 동시에 수행한다. 이렇게 하면, 특정 비즈니스 세그먼트에 대한 결과물을 제공하는 엔지니어링 중심의 전문가 팀이 있고, 그것을 기능이나 사용자에 따라 제품 구성을 개발하는 비즈니스 기반 전문 팀이 있을 수 있다. 또한 세그먼트 및 제품의 자율성을 극대화하기 위한 아키텍처와 IT 비용 효율성을 담당하는 공통 서비스 제공 플랫폼 팀을 운영하는 것도 필요해진다. 이런 과정이 프로세스화가 되면, 모든 업무 과정에서 셀프 서비스 도구를 제공하는 DevSecOps, DataOps, AIOps와 같은 전체적인 협업 파이프라인을 구축하게 된다.
이런 협업구조라면, 기존의 IT업무를 담당했던 부서로서의 존재 의미는 사라지게 된다. 전문 가로 구성된 BizDevOps팀은 사일로를 탈피하여 빠른 의사 결정과 자율성에 의한 경쟁력 있는 결과물을 만들어 낸다.
일반적인 기업의 레거시 시스템은 한 덩어리로 된 일체식(monolithic)이 대부분이다. 이 시스템을 독립적으로 발전할 수 있을 만큼 충분히 마이크로 서비스 형태로 세분화를 하되, 그 마이크로 서비스 역시 비즈니스 요구에 따라서 서로 간의 구성이 자유롭고 유연하게 되는 컴포저블의 형태로 재구성되어야 한다.
예를 들어, 전통적인 은행의 코어 뱅킹 시스템의 경우 상호 연결이 하나의 애플리케이션 구조에서 이루어진 일체식이다. 이 구조는 사이즈와 계산 성능 속도에서는 이점이 있지만 아주 작은 한 기능이 변경되면 전체적인 품질을 확인하기 위해 다른 모든 기능에 대해 테스트를 수행해야 하고, 그 의존도를 체크해야 한다. 또한 이런 시스템은 새로운 커뮤니케이션 채널인 모바일, 웹, 파트너 API와 같은 새롭고 복잡성이 늘어난 디지털 채널을 쉽게 수용하기 어렵다. 예를 들어, 한 은행에서 관세를 변경하거나 모바일 클라이언트를 지원하려면, 수십 개의 시스템을 차례대로 변경해야 하며, 이를 위해 여러 부서에서 병렬 개발이 이루어졌고 각 부서에서 몇 주 동안 품질 테스트가 진행된다. 그렇다고 이 코어 시스템을 모두 마이크로 서비스의 형태로 전환한다는 것은 기간과 비용의 문제가 따른다.
기업은 이것을 해결하기 위해 ‘스트랭글러 패턴(Strangler Pattern)’이라는 접근법을 사용한다. 이 접근 방식은 가장 자주 변경되는 기능을 선택하고, 이러한 기능에 대한 오너십을 비즈니스팀에 할당하고, 이것을 세분화되고 전문화된 마이크로 서비스를 만들기 위한 전담 BizDevOps 팀을 구성한다. 이러한 서비스는 "하나의 서비스-하나의 기능" 원칙을 따르며 레거시 시스템에서 떼어냄으로 레거시 코어를 좀 더 간결하게 만든다. 기본적으로 이 접근 방식은 전체 기능을 다시 개발하거나 수정하는 시간을 피할 수 있기에 상대적으로 빠르게 전환할 수 있다. 즉 은행업무의 예로, 기본 뱅킹 시스템 기능은 코어 내에 있고, 앞으로도 계속 유지되지만 비핵심 기능을 마이크로 서비스 계층 또는 특수 애플리케이션으로 독립시킴으로 해당 부분에 대한 변경을 자주 그리고 쉽게 가능하게 한다. 이 접근법은 새로운 기능에 대한 시장 출시 시간을 단축할 수 있는 구조를 갖게 됨으로 디지털 경쟁력을 보강하는 효과가 있다.
- ESB : CRM / ERP
- Integrated Packaged Applications
- 네트워크화 된 다수의 svc
- Mesh Apps and Services(MASA)
- ERP
- Composable Business Applications
여기에 덧붙여 더욱 강한 경쟁력 확보를 위한다면, 비즈니스 기능성을 중심으로 마이크로 서비스를 패키지화하는 PBC (Packaged Business Capabilities)로의 전환을 시도하기 바란다. 이것은 모듈화된 서비스를 비즈니스 프로세스에 맞게 조합하여 하나의 작은 패키지로 동작하게 한다는 개념이다. 마이크로 서비스의 우수한 기술 아키텍처를 그대로 살리면서 비즈니스 우선순위에 맞추어 조합된 구성을 제공하는 접근법이다. 이 새로운 유형의 기업은 변화하는 고객 현실과 요구사항에 빠르게 적응하며 기존에 사용했던 단일 유형의 기술에 의존하지 않는다. 즉 컴포저블 기업의 기반이 되는 IT 시스템은 분산되어 있지만 협업이 가능한 구조이다. 과거에는 기업 IT시스템 아키텍처가 요구사항을 충족하기 위한 시스템 주문 및 구축, 보고서 작성 및 제공, 시스템 문제 해결 등 사후 대응을 위해서 작업을 수행했다면, 새로운 컴포저블 기업의 IT시스템의 역할은 기존 역할에, 사전 예방적 제안과 혁신을 장려하는 역할까지 부가적으로 수행 가능하다. 많은 서비스와 기능이 사전 구축, 사전 테스트 및 즉시 사용할 수 있으므로 기존 사용하던 전통적인 시스템 설정보다 훨씬 빠른 속도로 애플리케이션과 데이터를 구축하고 구현할 수 있다.
- 애플리케이션 판매자 : 벤더/파트너 제공 application suites - CRM
- 비즈니스 부서 IT팀 : 벤더/파트너 제공 application suites & 커스텀 application suites, 커스텀 app & 벤더/파트너 제공 app
- 셀프 서비스(부서, 개인) : 벤더/파트너 제공 application suites & 다른 커스텀 application suites, 다른 커스텀 app & 벤더/파트너 제공 app
- 비즈니스 본부 ->
- 업무 팀 ->
- 작은 부서, 개인 ->
- 영업 본부
- 전략 고객 관리 팀
- 전략 고객 관리 대표
API, 가상화 및 클라우드를 기반으로 구축된 디지털 서비스의 증가로 인해 기업이 애플리케이션을 바라보는 시각과 엔터프라이즈 IT를 처리하는 방식이 변화하고 있다. 이제 기업 조직은 다양한 내부 및 외부 API에서 필요한 기능을 조합할 수 있을 뿐만 아니라 신속하게 새로운 API를 만들 수도 있고, 끊임없이 변화하는 비즈니스 요구사항에 따라 API를 추가 및 폐기할 수 있다.
많은 기업의 IT인력 구성은 비용이나, 능력 있는 디지털 인재를 뽑는 것이 어렵다는 이유로 많은 부분에서 외주화 한다. 그러기에 이런 일괄 IT 서비스를 제공하는 외주업체나 파트너에게 디지털 민첩성을 기대하는 것은 무리이다. 이렇게 디지털 업무를 아웃 소싱한 상태에서, 빠르게 변화하는 고객이나 시장의 요구 사항을 경쟁력 있게 처리한다는 것은 기업 및 상품 경쟁력을 포기하겠다는 것과 마찬가지이다. 태생이 디지털인 신생 기업과는 제품의 아이디어에서부터 출시까지의 시간과 품질, 기술 스택의 갱신 등 모두가 경쟁이 된다. 이 모든 것을 능력 있는 개발자를 통하여 해결하겠다는 시도도 그리 현실적이지 못하다. “디지털 전환을 위한 우선순위를 진행하는데 무엇이 방해가 되는가?”라는 포레스터 컨설팅의 조사[1]에 기업의 IT 임원들의 대답은 매우 투명한 현실을 보여준다. 74%가 새로운 요구에 맞춰서 디지털 워크플로우를 제공할 시간이 부족하고 65%가 기술과 지식이 모자란 것이 가장 큰 이유가 된다고 답을 한다.
- impedes/significantly impedes
- 74% inability to deliver as quickly as the business needs
- 65% lack of thchnology skills or knowledge
- 63% business process redesign
- 61% customer experience redesign
- 61% security
- 60% project management and/or program management
- 59% legacy technologies(I.e., upkeep)
- 58% data issues
- 52% organizational barriers(e.g., culture)
- 51% vision and strategy of the transformation
- 48% legal/regulatory issues
이런 수급 불균형은 LCNC (Low Code-No Code) 즉 로우코드/노코드 개발 플랫폼의 품질을 비약적으로 발전시켰고, 그에 따라 실제 업무 개발 경험이 거의 없는 시민 개발자(Citizen Developer)라는 비전문 개발자 그룹을 탄생시켰다. 새로운 로우코드 및 노코드 개발 플랫폼은 기존의 운영 체제에 얽매이거나 확장성 요구와 같은 기본적인 설계에 대해 걱정할 필요 없이 사람들이 애플리케이션이나 서비스를 비교적 쉽게 구현할 수 있도록 만들어졌다. 클라우드 기반의 서비스형 플랫폼(Platform-as-a-Service) 환경에서 구축된 로우코드 /노코드 플랫폼은 일반적으로 시각적 프로그래밍 인터페이스를 사용하여 기존 소프트웨어 개발보다 더 빠르게 비즈니스 문제를 해결한다. KPMG의 조사[2] 에 따르면 COVID-19 위기가 시작된 이후, 로우코드/노코드 개발 플랫폼을 디지털 트랜스포메이션의 가장 중요한 투자로 꼽은 기업은 10%에서 26%로 거의 3배 가까이 증가했다.
- most important automation investment
- BPMS(business process management software) - 4~5월:44%, 5~6월:17%
- process mining software) - 4~5월:20%, 5~6월:26%
- low-code/no-code development platforms - 4~5월:10%, 5~6월:26%
- RPA(robotic process automation) - 4~5월:27%, 5~6월:31%
- BPMS ranked as the most important automation investment in the PhaseⅠsurvey, while PhaseⅡ respondents rated RPAmlow-code/no-code, and process mining software as more important after the acceleration of the CoVID-19 crisis.
하지만 이 역시 ‘비즈니스 역량(Business Capabilities)’의 판단이 최우선적으로 검토되어야 하므로, 위에서 이야기한 개발자와 운영자, 비즈니스 프로세스에 전문지식을 소유한 비즈니스 유저가 포함된 BizDevOps의 퓨전팀을 구성하고 진행하는 것이 적절하다.
[그림 5] 로우코드/노코드를 이용한 BizDevOps 퓨전 팀 구성
이렇게 팀을 구성하게 되면, 중급 엔지니어를 많이 배출함으로 다이아몬드 형태의 인재 구성을 만들게 된다. 즉 생산성은 높고, 비용이 많이 들지 않는 IT인력 구성을 이루게 된다. 이런 구성은 외주 IT업체나 파트너와의 업무협력 방법에도 명확한 변화를 만들 수 있는 장점이 생긴다. 코어에 기능을 추가하기 위해 많은 것을 이해하는 시간이 필요하지 않아 정확한 요구사항을 마이크로 서비스 형태로 요구하고 제공받을 수 있음으로 발전적이고 전문적인 전략적 파트너십이 가능해진다.
전통적인 생산 프로세스를 갖춘 기업이나 조직에서는 빠른 딜리버리를 원하는 최고 경영진과 업무 사고를 최소화하려는 IT 부서와의 이해충돌이 꽤 잦은 편이다. 하지만, 기업이 IT 민첩성을 갖춘다는 것은 딜리버리 속도를 높이는 데 있어, 품질 저하와는 관계가 없다는 것을 의미한다. 자율적인 마이크로 서비스를 이용하는 우수한 엔지니어는 CI/CD(지속적 통합 및 지속적 배포)를 이용하여 딜리버리를 최적화할 수 있다. 이것은 각 프로세스에 해당하는 작업을 자동화하여 인크리멘탈 릴리스를 가능하게 하는 데 있다. DevOps 파이프라인에서 보안 테스트를 포함하여, 테스트, 배포에 이르는 서비스 제공의 모든 단계가 자동화된다.
또한 기업은 개발자를 위한 서비스로 내부 플랫폼을 만들어, 각 개발자는 글로벌 포털을 통해 서비스 템플릿에 액세스하고 간단한 클릭으로 필요한 인프라, CI/CD 파이프라인, 보안 도구 및 API 정의에 자동으로 액세스할 수 있다. 이를 통해 개발자는 파이프라인 및 인프라 구성을 설정하는 데 시간을 낭비하지 않고 실제 비즈니스 기능을 개발하는 데 집중할 수 있다. 딜리버리 프로세스의 자동화는 일반적으로 CI/CD 파이프라인과 같은 도구를 설정 및 유지 관리하여 특별한 엔지니어링 서비스로서의 플랫폼(platform-as-a-service)을 담당하는 부서가 주도한다. 물론 이런 전환은 클라우드 인프라스트럭쳐를 기본으로 이야기한다. 이런 클라우드 인프라는 자동화와 마찬가지로, 필요에 따라 컴퓨팅 파워나 및 스토리지 용량을 조정하는 프로비저닝에 시간이 걸리지 않는다. 대부분의 디지털 기업은 PaaS와 함께, 코드로서의 인프라 (Infrastructure-as-code) 개념을 사용하여 API를 통해 용량을 확보하고 물리적 하드웨어 구성을 통하지 않고 소프트웨어에서 추가 환경을 직접 요청한다.
CI/CD를 사용할 때 클라우드 인프라는 대기 시간이나 재작업 시간과 같은 주요 IT 지표를 근본적으로 개선한다. 기업은 표준화된 프로세스와 자동화를 동해 주기 시간을 단축하여 소프트웨어 배포 및 테스트를 가속화할 수 있고, 리그레션 (성능 저하, 디펜던시) 테스트 시간을 혁신적으로 줄일 수 있다. 기업은 생산성 향상 외에도 IT 자산 사용을 최적화하고 비즈니스 요구 사항을 충족하는 데 있어 전반적인 유연성을 개선하여 간접비용을 크게 줄일 수 있다.
컨테이너 단위의 통합 및 배포 방식은 협업 구조와 서비스의 구조적 확장을 가속화 시킬수 있다. 데브옵스를 통하여 컨테이너 기반의 클라우드 네이티브 컴퓨팅 환경으로 전환하게 되면, 온-프레미스, 프라이빗 클라우드, 퍼블릭 클라우드를 혼용하는 하이브리드 컴퓨팅이 보편화되는 지금과 같은 시기에, 마이크로서비스 기술로 실제적인 비즈니스 경쟁력을 확보 할 수 있게 된다. 마이크로서비스의 장점은 외부 서비스와의 연계를 통해 서비스 확장이 쉽다는 점이다. 또한, 내 서비스에 대해서도 외부에서 접근하게 할 수 있게 함으로써 다양한 서비스에 활용될 수 있다. 이러한 유연성은 대규모의 새로운 서비스를 컴포저블이 가능하게 애자일하게 개발하고 데브옵스를 활용하여 자동화할 수 있다는 강점을 제공한다.
오늘날 기업 간의 치열한 경쟁 환경은 조직이 더욱 민첩해지도록 압박하고 있다. 위에서 이야기한 4가지 IT 전환은 기업에 안정성과 역동성의 균형을 유지하고 경쟁력을 갖추는 엔진의 역할을 할 수 있다.
이 IT 전환을 추진하는 과정에서, 기업은 전략, 구조, 프로세스 및 인력 구성에서 수많은 개선 사항을 부가적으로 발견할 수 있다. 보다 독립적이고 전문화된 서비스 소프트웨어 개발, 테스트 및 배포를 위한 자동화된 도구, 더 빠른 릴리즈를 가능하게 한다. 내부 IT 인력은 업무 효율성이 높아지면서, 재투자 또는 비용 절감을 위한 자본을 확보하는 데 기여하게 된다. 이러한 민첩성은 기업과 조직에게 강력한 경쟁력이 될 것이다.
References
[1] Forrester, “Large Enterprises Succeeding with Low-Code”, Mar 2019
[2] KPMG, “Enterprise Reboot”, Aug 2020
▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶ 해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.
SAP France의 Senior Program Manager
한국에서 컴퓨터 공학을 전공 후, 7년간 한국후지쯔에서 개발자로 근무하고, 1998년 프랑스 파리로 이주하여 Business Objects에서 개발 매니저와 프로그램 매니저를 거쳐, 현재 SAP의 클라우드 ERP 엔지니어링 그룹의 시니어 프로덕트/프로그램 매니저로 근무 중입니다. 책 <프로덕트 매니지먼트>의 저자입니다.