제조업 부흥의 선봉장,'인공지능 기반 스마트팩토리'
|
그래서 변화를 관리하는 기법 및 컨설팅 방법마저도 변화 관리의 범위에 포함시켜 디자인해야 할 것이다. 따라서 변화 관리(變化管理, Change management)란 산업계나 기업에 일어나는 중요하고 핵심적인 변화 요인을 기업 성과가 향상되는 방향으로 관리하는 것을 말한다. 그러므로 변화 자체를 관리하는 변화관리 기술이 강조되고 있으며, 그 중심에 복잡성을 운용하는 역량이 미래 경쟁력으로 대두되고 있기 때문이다. 따라서 오늘날 기업 환경에서 가장 핵심적인 요인은 복잡성을 길들이는 혁신이 점점 중요해지고 있다.
복잡성을 길들이는 학습 기반 변화관리의 흥미로운 점은 많은 사람들이 직업적으로 겪었던 엄청난 고난과 희생에도 불구하고 지난 몇 년 동안 미디어 산업과 전 세계의 다른 많은 산업에서 해당 분야의 기술뿐만 아니라 이종 산업 간 융합 기술이 놀라운 속도로 진화하고 있다. 예를 들어, 2년 전만 해도 우리는 원격 근무가 얼마나 빨리 보편화될지 상상조차 할 수 없었다. 매우 어려운 상황이 발생했지만 이러한 변화에 대한 적응력은 산업계에 색다른 활력을 불어넣었고 빠르게 변화하는 요구 사항을 충족하기 위해 해당 기술을 얼마나 빨리 발전시킬 수 있는지 보여주었다. “미디어는 메시지다(the media is the message)”, “지구촌(global village)”이라는 유명한 표현을 남긴 마셜 매클루언(Herbert Marshall McLuhan)의 “필요는 발명의 어머니”란 말이 스쳐간다.
디지털 비즈니스의 핵심은 탄력적이고 효율적인 정보통신기술(ICT) 기반 구축이다. 잘 설계된 기반 없이는 비용 관점의 효율성이 확장될 수 없다. 또한 더 큰 비즈니스를 위해 민첩성과 가치를 제공하는 것이 점점 중요해지고 있다. 급변하는 시장과 고객의 요구 사항을 식별하여 비즈니스 목표를 충족해야 살아남을 수 있다. 제품을 파고 사는 시대는 점점 사라지고 있기 때문이다. 따라서 지속 가능한 경쟁우위를 유지하기 위해서는 고객 경험을 지속적으로 개선하여야 한다. 또한 운용과 비용 관점에서 효율적으로 시장과 고객 대응 서비스를 제공하기 위해 스마트팩토리를 구축해야 한다. 그것이 제조업의 경영 차별화 전략이고 지속 가능한 경쟁우위 제조 플랫폼이기 때문이다.
급변하는 비즈니스 환경에서 적응하기 위해 스마트팩토리를 구축해야 한다. 기업들은 클라우드 컴퓨팅 기술을 기반으로 애플리케이션 설계, 구축 그리고 운영하는 방식을 바꿔야 한다. 또한 제조업이 스피드와 유연성을 얻기 위한 방법으로서 주목하는 키워드가 바로 “클라우드 네이티브 플랫폼”이다. 클라우드 아키텍처 및 기술은 클라우드에서 빌드(build) 되고 클라우드 컴퓨팅 모델을 최대한 활용하기 위해 워크 로드를 디자인하고, 생성 및 운영하는 접근 방식이며, 클라우드 네이티브 플랫폼의 이점을 최대로 활용하여 기존 로컬에 구축되어 있는 애플리케이션을 클라우드로 옮겨서 구축하고 실행하는 방식을 말한다.
클라우드 네이티브 플랫폼을 사용하면 시장 상황에 신속하게 대응할 수 있으며 전체 재배포 없이 실시간으로 복잡한 애플리케이션의 영역을 즉시 업데이트할 수 있다. 클라우드 네이티브 플랫폼(Cloud Native Platform) 개발에는 일반적으로 데브옵스( DevOps ) , 애자일 방법론, 마이크로 서비스 아키텍처, 클라우드 플랫폼, 쿠버네티스 및 도커와 같은 컨테이너 그리고 지속적인 제공 (Continuous Delivery)이 포함된다. 간단히 말해, 새롭고 현대적인 모든 애플리케이션 배포 방법이 사용된다고 봐야 할 것이다.
아래 그림은 클라우드 네이티브 플랫폼이다. 넷플릭스, 우버, 위쳇과 같은 애플리케이션은 이미 클라우드 네이티브 기술을 구현해서 하루에 수백에서 수천 번까지 배포를 진행하고 있다. 조합형 애플리케이션은 마치 레고처럼 필요한 블록을 끼웠다 뺐다 하듯이 기업이 제공하는 서비스이다. 이러한 구조는 모듈형 구성요소로 구축되어 코드를 더 쉽게 사용하고 재사용이 가능해져 새로운 소프트웨어 솔루션의 출시 기간을 단축시키기 때문에 기업 가치를 창출할 수 있다.
스마트팩토리의 클라우드 기반 플랫폼은 지속적인 통합과 제공(CI/CD)을 통해 개발 부문과 운영 부문 간의 업무 속도를 증가시켜야 한다. 제조업은 클라우드 기반 플랫폼에서 이와 같은 실용적인 서비스 기반 아키텍처를 이용하여 지속적으로 기존의 애플리케이션을 최적화할 수 있다. 이를 위해 지속적인 통합(Continuous Integration, CI)과 지속적인 제공(Continuous Delivery, CD) 및 완전히 자동화된 배포 운영 같은 데브옵스(DevOps) 워크플로를 통해 지원된다.
즉 데브옵스 (DevOps)를 도입하여 공통의 목적과 주기적인 피드백을 통해 개발팀과 운영팀의 협업을 지원할 수 있다. 물론 클라우드 네이티브 애플리케이션은 조직 내 인력과 이들의 협업 프로세스를 자동화하는 것으로부터 시작된다.
또한 데브옵스(DevOps) 및 컨테이너 접근 방식에서는 하나의 대규모 릴리스 및 업데이트를 기다리는 것이 아니라 마이크로 서비스처럼 여러 서비스가 탄력적으로 결합된 하나의 컬렉션으로 애플리케이션을 쉽게 출시할 수 있다. 또한 컨테이너(Container)를 도입하면 이상적인 애플리케이션 배포 유닛 및 독립적인 실행 환경을 제공하여 이러한 프랙티스(practice)를 지원할 수 있기 때문이다.
그러므로 마이크로 서비스 아키텍터(MSA) 관점에서 클라우드 네이티브 개발은 아키텍처의 모듈성, 탄력적인 결합, 그리고 독립적인 서비스에 중점을 둬야 한다. 각 마이크로 서비스는 비즈니스 역량을 구현하고, 자체 프로세스를 실행하고, 애플리케이션 프로그래밍 인터페이스(Application Programming Interfaces, API) 또는 메시징을 통해 커뮤니케이션하게 된다.
그리고 마이크로 서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식이다. 또한 마이크로 서비스 아키텍처는 애플리케이션의 확장을 용이하게 하고 개발 속도를 앞당겨 혁신을 실현하고 새로운 기능의 출시 시간을 단축할 수 있게 해 준다. 다른 한편, 모놀리식 아키텍쳐(monolithic architecture)는 마이크로 서비스 아키텍쳐의 반대되는 개념으로 전통적인 아키텍쳐를 의미한다.
하나의 서비스 또는 애플리케이션이 다른 하나의 거대한 아키텍쳐를 가질 때 모놀리식(monolithic)하다고 한다. 따라서 모놀리식 아케텍쳐를 갖는 소프트웨어의 특징은 그 자체로 튼튼하고 내부 요소 간의 의존성이 강해서 구조적인 결합이 강하게 유지되는 결과를 초래하는 것이 일반적이다. 그러므로 각 비즈니스 컴포넌트들이 하나의 강한 결합 구조를 지닌 통일성이 존재한다. 또한 이는 비즈니스 로직이 서비스에 최적화된 코드를 만들어내는데 더 집중할 수 있는 반면에 복합적인 예외를 만들 수 있는 위험성을 내포하고 있다. 따라서 모놀리식 아키텍처와 마이크로 서비스 아키텍처를 비교할 필요가 있다.
모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다. 또한 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해진다. 그리고 이러한 복잡성으로 인해 실험에 제한을 받고 새로운 아이디어를 구현하기가 어려워지고 있다. 종속 관계를 형성하여 긴밀하게 결합된 많은 프로세스 때문에 단일 프로세스의 실패로 인한 영향이 증가되는 경향이 있어서 모놀리식 아키텍처는 애플리케이션 가용성에 대한 위험을 가중시킨다.
반면에 마이크로 서비스 아키텍처의 경우, 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신되고, 비즈니스 기능을 위해 구축되기 때문에 서비스마다 한 가지 기능을 수행할 수 있다. 그러므로 서비스가 독립적으로 실행되는 애플리케이션의 특성에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.
결론적으로 마이크로 서비스의 활용 이점은 민첩성, 유연한 확장성, 쉬운 배포, 재사용 가능한 코드, 복원성 등이다. 마이크로 서비스는 해당 서비스를 소유한 독립적인 소규모 팀 조직을 육성하는 역할이다. 그러므로 팀 조직은 충분한 이해를 바탕으로 소규모 컨텍스트 내에서 활동하며 더 독립적이면서 신속하게 업무를 수행할 수 있다. 그러므로 개발 주기 시간이 단축된다. 그리고 조직의 집계 처리량 측면에서 큰 이점을 누리게 된다. 또한 각 서비스가 지원하는 애플리케이션 기능의 수요를 충족하도록 해당 서비스를 독립적으로 확장할 수 있다. 따라서 팀 조직은 필요한 인프라의 규모를 적절히 조절하고, 기능의 비용을 정확하게 측정하여, 서비스의 수요가 급증하는 경우에도 가용성을 유지할 수 있다.
이는 지속적인 통합 및 소통을 통해 새로운 아이디어를 손쉽게 시험하고 문제가 발생할 경우 간단히 백 롤(back-role) 할 수 있게 해 준다. 이처럼 저렴한 실패 비용 덕분에 실험을 진행할 수 있어 더 쉽게 코드를 업데이트하고 새로운 기능의 출시 시간을 앞당길 수 있으며, 특정한 문제를 해결하는 데 가장 적합한 도구를 자유롭게 선택할 수 있다. 따라서 마이크로 서비스를 구축하는 팀은 작업별로 가장 적합한 도구를 선택할 수 있다. 다른 한편, 소프트웨어를 잘 정의된 소규모 모듈로 분할하면 팀이 기능을 여러 용도로 사용할 수 있게 된다. 특정 기능을 위해 구축된 서비스를 다른 기능의 빌딩 블록으로 사용할 수 있는 것이다. 이를 통해 개발자가 코드를 처음부터 작성하지 않고도 새 기능을 생성할 수 있어 애플리케이션이 자체적으로 부트스트랩(bootstrap) 작업을 생성할 수 있다.
일반적으로 서비스는 독립적이므로 실패에 대한 애플리케이션의 저항성이 증가한다. 모놀리식 아키텍처에서는 단일 구성 요소가 실패하는 경우 전체 애플리케이션이 실패하게 될 수 있지만, 마이크로 서비스에서는 기능을 저하시키고 전체 애플리케이션을 충돌시키지 않는 방식으로 전체 서비스 실패를 처리하기 때문에 안정적인 복원성을 확보할 수가 있다. 따라서 이는 속도와 민첩성을 향상(keep-up) 시켜 비즈니스 속도와 성장을 가속화하는 전략적 대변환(transformation) 무기로 발전하고 있다. 그 까닭은 스마트팩토리의 목적 관점에서 개인화된 맞춤 시장과 고객에게 적기 맞춤(Fit in Time) 기반(基盤)으로 즉시 대응하는 것이 필수적이기 때문이다.
