사이버 물리 시스템의 자원 제어 프로그래밍 모델과 프로그램 환경클라우드 컴퓨팅이 사이버 물리 시스템의 자원 관리를 위한 운영체제의 역할을 하려
클라우드 컴퓨팅의 특성상 네트워크를 통해 원격지에 있는 자원에 접근할 수 있도록 하는 RESTful API와 같은 원격 프로그래밍 인터페이스로 제공될 수밖에 없다. 오픈소스 클라우드 컴퓨팅 소프트웨어인 오픈스택도 모든 API는 RESTful API로 정의되며, 아마존웹서비스와 마이크로소프트 애저, 구글 클라우드와 같은 주요 클라우드 컴퓨팅 서비스 업체의 API도 RESTful API로 정의되어 제공된다.
오픈스택이나 아마존웹서비스의 “아웃포스트(Outposts)”, 마이크로소프트의 “애저스택(Azure Stack)”등을 통해 구축되는 사설 클라우드(private cloud)와 아마존웹서비스와 마이크로소프트 애저, 구글 클라우드와 같은 공용 클라우드(public cloud) 서비스에서 사용가능한 프로그래밍 인터페이스가 현재 클라우드 컴퓨팅의 프로그래밍 모델을 제공하고 있다.
오픈스택이 클라우드 컴퓨팅 분야에서 가장 크게 공헌한 것이 바로 이런 클라우드 컴퓨팅 프로그래밍 모델과 인터페이스에 대해 구체적인 산업계의 합의를 이룰 수 있는 기반이 되었다는 점이다. 오픈스택에서 정의한 프로그래밍 모델과 인터페이스가 실제 기술로서 구현되기 위해 클라우드 컴퓨팅 시스템 내부에서 어떤 방식으로 프로그램되어야 하는지 다양한 실험을 구체적으로 시도하고, 이런 실험과 시행착오의 결과가 오픈스택이라는 하나의 구체적인 소프트웨어로 응집될 수 있도록 하여 클라우드 컴퓨팅이 단순한 용어가 아닌 하나의 구체적인 기술로서 자리를 잡는 데 큰 역할을 한 것이다.
이렇게 오픈스택을 통해 자리를 잡고 구체적으로 모양을 갖추게 된 클라우드 컴퓨팅 기술은 클라우드 컴퓨팅 기술을 이용한 다른 응용 기술을 상상하고 만들 수 있게 해주었다. 제일 대표적인 예가 차세대 이동통신 분야에서 최근 핵심 기술로 부상하고 있는 “네트워크 기능 가상화(Network Function Virtualization; NFV)”이다.
차세대 이동 통신 분야에서 “네트워크 기능 가상화”를 실제 상용 수준의 기술로 만들려고 하는 프로젝트 중의 하나인 가입자망(subscription network) 및 국사(Central Office; CO) 통신 인프라 가상화 기술 개발 프로젝트인 “CORD(Central Office Re-architected as a Datacenter; CORD)”와 같은 프로젝트[8]도 오픈스택을 통해 응집된 클라우드 컴퓨팅 기술이 없었다면 결코 상상하고 실험해볼 수 없는 기술이다. 실제 미국의 이동통신 사업자인 AT&T는 이 CORD 프로젝트를 제안하고 실행하여 미국 내 기가인터넷망의 구조를 오픈스택(OpenStack)과 소프트웨어 정의 네트워크(SDN), 네트워크 기능 가상화(NFV) 기술을 통해 비용을 낮추는 실험을 여전히 진행하고 있다. ONOS라는 오픈소스 네트워크 운영체제로 유명한 ONF에서는 참조(reference) 오픈소스 CORD 구현체인 OpenCORD를 ONOS와 오픈스택을 이용해 개발하는 프로젝트도 진행하고 있다[8].
오픈스택을 기반으로 한 공용 클라우드 서비스를 제공하는 랙스페이스와 같은 회사가 아마존웹서비스와 같은 규모의 비즈니스를 하지 못한다고 해서 실패했거나 영향력이 없는 것이 아니다. 오픈스택으로 산업 표준화된 클라우드 컴퓨팅 API와 프로그래밍 모델이 이를 기반으로 클라우드 컴퓨팅 외의 이동통신과 다른 산업에 필요한 IT 기술의 혁신에 영향을 미치고 있기 때문에 앞으로 비즈니스에의 파급력은 더 커지게 될 것이고, 이러한 영향을 사이버 물리 시스템 기술과 서비스가 받게 될 것이다.
사이버 물리 시스템을 위한 클라우드 컴퓨팅 기술 발전에서 또 하나 필요한 중요한 요소는, 모바일 네트워크와 고성능 유선 네트워크로 연결된 대규모 사이버 물리 시스템을 신속하게 개발할 수 있으면서 안전성과 신뢰성을 손쉽게 확보할 수 있게 해주는 프로그래밍 환경과 런타임 환경이다.
오픈스택이 파이썬(Python) 프로그래밍 환경을 이용해 개발된 것 때문에 파이썬 프로그래밍 언어가 클라우드 컴퓨팅 기술 개발의 표준 개발 환경처럼 부각된 것은 안전성, 신뢰성이 보장된 클라우드 컴퓨팅 기술과 이를 통합하는 사이버 물리 시스템 개발에도 보다 발전된 프로그래밍 언어와 런타임 환경이 필요하다는 것을 간접적으로 암시한다.
파이썬(Python)언어가 오픈스택 개발의 기본 환경으로 사용된 이유는 오픈스택의 전신인 NASA의 네뷸라(Nebula)가 파이썬(Python)으로 개발되었기 때문이다. 이후 랙스페이스(Rackspace)와 같이 공동으로 오픈소스화 하면서 핵심 프로젝트인 노바(Nova)와 스위프트(Swift)를 중심으로 파이썬(Python)이 오픈스택의 공식적인 개발 환경이 되었다. 파이썬 언어가 오픈스택 개발에 사용된 것은 네뷸라 개발팀의 개발 환경 선호도의 영향도 있었던 것 같지만, 파이썬 언어의 특성이 오픈스택 개발의 속도를 유지하고 완성도를 높이는 데 크게 기여한 측면도 있다.
파이썬 언어는 동적 언어여서 저수준의 하드웨어 세부 사항에 신경을 쓰지 않고 프로그램 작성시 개발하려는 알고리즘과 비즈니스 로직에 집중할 수 있게 해주며, 통상적인 의미의 인터프리터 언어이기 때문에(사실은 파이썬 인터프리터가 가상 머신에서 실행하는 바이트코드를 코드 라인 입력 후 즉시 생성하는 컴파일 과정(Just-In-Tim(JIT) compile)이 있기는 해서 완전히 컴파일을 하지 않는다고 보기는 어렵다), 코드를 작성하고 배치함과 동시에 실행시킬 수 있어 개발 시간이 단축되는 장점이 있다.
이와 함께 C와 C++로 작성된 저수준 소프트웨어 모듈들을 통합하여 대형 소프트웨어를 만들 수 있도록 하는 접착 언어(glue language)로서 초반부터 개발된 것도 파이썬이 오픈스택 개발 환경으로 채택되는데 공헌한 주요 특성인 것으로 보인다. 리눅스 환경에서 기존에 C와 C++ 언어로 개발된 저수준 시스템 라이브러리와 모듈들을 C/C++ API를 이용해 파이썬 런타임 환경 안에 통합하는 것도 용이했기 때문에 기존의 하드웨어 자원과 리눅스 운영체제 자원을 클라우드 컴퓨팅 로직으로 효과적으로 통합하기에도 용이했다.
오픈스택 개발에 파이썬을 채용한 것은 초반에는 다소 우연이었을 수 있지만, 결론적으로는 파이썬 언어의 특성 때문에 오픈스택이 대대적으로 성공할 수 있었다. 파이썬 언어를 사용하지 않았다면, 광범위한 영역의 하드웨어와 운영체제 자원을 사용하는 오픈스택 주요 핵심 프로젝트 개발에 훨씬 더 많은 개발 시간이 걸렸을 가능성이 높고, 클라우드 컴퓨팅에 본질적인 로직이 아닌 다른 세부 사항을 해결하느라 6개월마다 새로운 릴리즈의 오픈스택 버전을 발표하는 것은 거의 불가능했을 것이다.
광범위한 지역에 걸친 클라우드 컴퓨팅 자원과 자율 에이전트와 같은 물리적 요소가 통합된 대규모 사이버 물리 시스템을 개발하기 위해, 사이버 물리 시스템이 목적으로 하는 서비스와 비즈니스 로직에 집중하여 손쉽게 클라우드 컴퓨팅 자원과 사이버 물리 시스템 컴포넌트를 개발, 통합하고, 저수준의 시스템 자원 관리와 작업들에 대해서는 사이버 물리 시스템을 개발하는 엔지니어들이 되도록 신경을 쓰지 않게 해주는 개발 및 런타임 환경이 필요하게 된다.
현재까지는 신뢰성과 안전성을 중요하게 생각하는 사이버 물리 시스템의 특성 때문에 미션 크리티컬 시스템을 개발하는데 많이 쓰인 C/C++, 그리고 에이다(Ada)와 같이 실시간 환경 개발을 목적으로 개발된 프로그래밍 언어들이 사이버 물리 시스템의 개발, 통합에 많이 사용되었다. 앞으로 5G 및 차세대 이동통신을 기반으로 한 대규모 사이버 물리 시스템의 개발, 클라우드 컴퓨팅 환경을 다루는데 적합한 프로그래밍 언어와 개발 환경이 사이버 물리 시스템 개발에 새롭게 들어오게 될 것으로 보인다.
파이썬이 좋은 언어이기는 하지만, 엄밀한 소스 코드 정적 분석 및 검증이나 컴파일 타임 메모리 오류 검출과 같은 소프트웨어 신뢰성을 근본적으로 개선, 보장해주는 기능을 지원하기 어려운 측면이 있다. 현재까지는 오픈스택과 같은 클라우드 컴퓨팅 소프트웨어나 클라우드 컴퓨팅 서비스를 다루는 서버리스 컴퓨팅이나 클라우드 네이티브 프로그래밍에 파이썬이 많이 쓰이기는 했지만, 좀더 근본적으로 신뢰성과 안전성을 보장해줄 수 있는 사이버 물리 시스템 소프트웨어 개발 환경이 등장할 것으로 보인다. 이와 함께, 파이썬 환경 자체가 미션 크리티컬 클라우드 컴퓨팅을 위한 요구 사항을 수용해서 새로운 모습으로 진화할 가능성이 있지만, 필자 개인적으로는 파이썬 언어가 개발될 때의 목적이 미션 크리티컬 시스템 개발을 지원하는 것이 아니었기 때문에 이런 변화는 제한적일 것으로 전망한다.
현재 나와 있는 기술중에서 사이버 물리 시스템 개발의 생산성과 안전성에 기여할 수 있을 것으로 보이는 개발 환경은 사용하기 쉽고 클라우드 네이티브 프로그래밍에서 강점을 가지고 있는 “고(go)” 언어, 최근 안드로이드 앱 개발과 마이크로서비스 기반의 분산 컴퓨팅 시스템 개발에 많이 활용되기 시작한 “코틀린(Kotlin)” 언어, 메모리 관리의 안전성을 크게 높이고 간결하고 단순한 구문으로 시스템 프로그래밍과 서버 사이드 프로그래밍에서 각광 받고 있는 “러스트(Rust)” 언어와 같은 특징을 가진 프로그래밍 언어가 사이버 물리 시스템 개발에 많이 활용될 수 있을 것으로 보이는 새로운 프로그래밍 언어이다.
앞으로의 사이버 물리 시스템 개발에는 다양한 계층의 이종(heterogeneous) 자원을 통합해야 하는 이유로 기본적으로 폴리글랏(polyglot) 프로그래밍이 활용될 것으로 보인다. 이 폴리글랏 프로그래밍은 요즘 복잡해지고 있는 인터넷 서비스 개발에서도 빠르게 확산되고 있는 프로그래밍 트렌드이기도 하다. 광범위한 지역에 걸쳐 있는 자율 에이전트와 하부 사이버 물리 시스템 요소들과 클라우드 컴퓨팅 자원이 통합되어 하나의 서비스로서 신뢰성과 안전성을 보장하기 위해 각 계층과 하부 사이버 물리 시스템 요소들의 특성과 요구사항에 맞는 프로그래밍 언어와 런타임 환경이 사용되고, 이들을 통합된 서비스로 엮어내는 점착 프로그래밍 언어와 런타임 환경이 계층을 이루어 서비스를 통합하는 방식으로 개발되어야 하기 때문에 폴리글랏 프로그래밍은 피할 수 없는 트렌드이기도 하다.
그럼 앞에서 언급한 “고(go)” 언어, “코틀린(Kotlin)” 언어, 그리고 “러스트(Rust)” 언어의 어떤 측면이 사이버 물리 시스템을 위한 클라우드 컴퓨팅 시스템 통합과 개발에 도움이 되는지 같이 생각해보도록 하자. 사실 대규모 사이버 물리 시스템 개발에는 다양한 측면의 요구 사항이 고려되어야 하는데, 이번 글이 지면이 많이 모자란 관계로 위에서 언급한 고(go)언어, 코틀린(Kotlin)언어, 러스트(Rust)언어가 사이버 물리 시스템 개발에서 클라우드 컴퓨팅 자원 통합과 개발에 어떻게 도움이 되는지에 집중해서 생각해보려고 한다. 클라우드 컴퓨팅 통합 및 개발 외 사이버 물리 시스템 개발에 관련된 빅데이터 처리, 분석 환경과의 통합, IoT, 엣지 컴퓨팅과 사이버 물리 시스템과의 관계, 인공지능 및 기계 학습, 인지 컴퓨팅 기술과의 통합과 관련된 측면은 앞으로 기고할 글에서 다시 자세히 다루기로 한다.
제일 먼저 고(go)언어가 사이버 물리 시스템 개발에 던져주는 시사점에 대해서 같이 생각해보자. 고(go)언어는 구글에서 일하던 로버트 그리즈머, 롭 파이크, 그리고 C언어의 설계자로 유명한 켄 톰슨이 2007년 구글 내부에서 인페르노 분산 운영 체제와 관련된 문제를 해결하기 위해 설계, 개발한 프로그래밍 언어이다. 고(go)언어가 왜 사이버 물리 시스템 개발에 중요한 특성이 있는지 이해하기 위해 어떤 배경에서 고(go)언어가 설계되었는지 같이 생각해보도록 하자.
고(go)언어는 먼저 소프트웨어 개발의 복잡성을 줄이는 것을 최소화하려는 목적으로 개발된 언어이다. 이 때문에, 고(go)언어의 예약어를 보면 최근 유행하는 다른 프로그래밍 언어에 비해서 예약어가 많지 않고 단순해서 정말로 현대 프로그래밍 언어가 맞는지 의심하게 된다. 코드 재사용을 위해 객체지향 프로그래밍을 위한 예약어와 표현 방법들이 기본적으로 포함되는 것이 요즘 추세이지만, 객체지향 프로그래밍 언어에서 흔한 클래스 선언, 정의 관련 예약어도 없다[9, 11].
객체지향 프로그래밍 언어에서 흔한 클래스 선언, 정의 관련 예약어가 없다고 해서 객체지향 프로그래밍이 불가능한 것은 아니지만, C++, 자바(Java)의 문법과 객체지향 프로그래밍에 익숙한 사람들은 뭔가 모를 이질감과 불편함을 느끼며, 예전 Objective-C가 나올 즈음에 C언어의 예약어만을 이용해서 객체지향 프로그래밍을 하려고 했던 시절을 떠올리게 한다. 고(go)언어에서 객체지향 프로그래밍을 아예 제외하려고 했던 것은 아니지만, 현대 프로그래밍 언어에서 생기는 많은 복잡성들이 객체지향 프로그래밍을 하는 과정에서 생긴다는 것을 안 고(go)언어 설계자들이 C++스타일의 객체지향 프로그래밍언어에서 나타나는 복잡성을 줄이기 위해 의도적으로 관련된 많은 예약어들을 삭제하고 C와 비슷하게 단순한 언어로 만들었다.
객체지향 프로그래밍 언어에서 흔하게 나타나는 예약어들을 생략한 대신, 클로저를 통해 코드 재사용성을 함수형 프로그래밍을 통해 지원하는 방식으로 디자인되었다. 함수형 프로그래밍은 익숙해지려면 객체지향 프로그래밍보다 어렵지만, 극도로 추상화된 함수로 정의된 프로그래밍 패턴들을 통해서 코드를 간결하게 하고 복잡성을 줄일 수 있으며, 현대 인터넷 프로그래밍에서 자주 요구되는 확장성(scalability)과 병행성(concurrency)을 지원하기 쉽다는 장점이 있다[9-11].
주요 현대 프로그래밍 언어에서 필수적으로 지원하는 객체지향 프로그래밍 관련 예약어를 의도적으로 없애면서까지 프로그래밍 언어의 디자인을 단순하게 만든 고(go)언어가 사이버 물리 시스템 기술에 주는 의미는 명확하다. 인터넷과 5G 및 그 이후의 차세대 이동통신망으로 엮여 시스템의 복잡도가 급격하게 높아지는 사이버 물리 시스템을 디자인하고 구현하는데 시스템의 복잡도를 줄이고 제어하기 위해서는 단순히 아키텍처 설계 과정에서 복잡도를 줄이는 설계를 한다고 해서 근본적으로 해결되지 않는다는 것이다. 사이버 물리 시스템이 구성되고 동작하는 방식을 기술하는 프로그래밍 언어 수준에서 복잡도를 제어하고 줄일 수 있는 방법이 근본적으로 새로이 고안되어야 하는 것이다.
복잡한 실세계를 포함하기 위해서는 프로그래밍 언어도 이런 실세계의 복잡성을 포용할 수 있도록 만들어져야 한다는 생각으로 디자인, 개발되기 시작한 객체지향 프로그래밍 언어들은 실제로 클래스와 객체라는 개념을 통해 소스 코드 수준에서 실세계 객체들을 직관적으로 추상화할 수 있는 방법을 제공함으로써 실세계 문제들을 표현하고 해결하는데 큰 기여를 해왔다. 객체지향 프로그래밍을 통해 코드 재사용성이 높아지면서, 오히려 소프트웨어의 복잡성은 전반적으로 높아지기 시작했으며, 객체지향 프로그래밍 언어들의 단점이 드러나기 시작했다.
고(go)언어의 설계자중 한 사람인 켄 톰슨은 C언어를 설계, 개발한 컴퓨터 과학자로 유명하며, C언어를 통해서 현대 프로그래밍 언어 역사에 굵직한 한 획을 그은 사람이다. 켄 톰슨은 프로그래밍이 복잡해지는 문제 때문에 C++를 극도로 싫어해서, C++에서 나타나는 복잡성을 최소한으로 줄일 수 있는 단순한 프로그래밍 언어를 만들기 위해 고(go)언어를 디자인했다고 알려져 있다[9, 11].
C와 같은 간결한 문법과, C언어에서는 지원되지 않던 가비지 콜렉션을 제공함으로써 C언어에서 다루기 가장 어려운 부분이었던 메모리 관리를 단순화한 점, 그리고 클로저(closure)를 지원하여 함수형 프로그래밍을 포용함으로써 객체지향 프로그래밍과는 다른 방식의 코드 재사용성을 지원하는 점, 병렬, 분산 컴퓨팅과 멀티 코어 아키텍처가 부상하면서 중요해진 “고 루틴(Go-routine)”을 이용한 병행성(concurrency) 지원과 고(go)언어 구문의 단순명료함이 소프트웨어의 복잡성을 낮추는 데 기여하고 있다.
이렇게 프로그래밍 언어 수준에서 소프트웨어의 복잡성을 근본적으로 줄이기 위해 설계된 고(go)언어의 설계 철학과 특성들은, 5G 이동통신과 저지연, 광대역 유선 네트워크를 통해 다수의 클라우드 컴퓨팅 자원을 끌어와 복잡한 대규모의 연산을 해야 하는 지능형 서비스를 개발하는 개발 환경이 어떤 식으로 발전되어 갈 것인지 엿볼 수 있게 하는 트렌드로 볼 수 있다.
고(go)언어와 함께 또 살펴보아야 할 프로그래밍 언어는 “코틀린(Kotlin)”이다. “코틀린(Kotlin)”은 고(go)언어와는 달리 “자바 가상 머신(Java Virtual Machine; 이하 JVM)” 계열의 언어이다. 자바(Java)와 JVM 계열 언어의 특성을 다수 채용하면서, 자바(Java)언어로 개발된 소프트웨어 모듈들을 별다른 수정과 포팅 없이 코틀린(Kotlin)으로 개발된 소프트웨어에서 바로 불러 사용할 수 있도록 자바(Java)언어와의 100% 상호호환성을 지원한다. 자바(Java)언어의 단점으로 지목되어 온 같은 기능을 표현하는데 다른 언어보다 장황한 표현이 필요한 점도 코틀린(Kotlin)의 간결한 구문과 람다식(lambda expression), 클로저(closure) 등의 함수형 프로그래밍 개념의 도입을 통해 상당히 많이 개선되었다[13-17].
“코틀린(Kotlin)”언어가 사이버 물리 시스템과 클라우드 컴퓨팅에 주는 의미는 소프트웨어 개발 과정의 협업과 생산성을 중시하고 이를 개선하기 위한 디자인이 상당수 포함되었다는 것이다. “코틀린(Kotlin)” 언어를 개발한 “젯브레인즈(JetBrains)”사가 프로그래밍 언어 개발을 위한 통합 개발 환경(Integrated Development Environment; IDE)”과 개발 도구를 개발하는 회사라는 것도 눈여겨봐야 할 점이다. 코틀린(Kotlin)은 애초부터 통합 개발 환경과 개발 도구를 통한 자동화를 염두에 두고 개발된 언어이기 때문에 개발 도구와의 통합이 용이한 디자인을 가지고 있고, 코틀린(Kotlin)을 개발한 젯브레인즈가 자사의 IntelliJ 개발 환경에서 100% 코틀린(Kotlin)을 지원하고 있기 때문에 다른 프로그래밍 언어에 비해 통합 개발 환경 지원과 개발 도구 지원이 탄탄하다.
코틀린(Kotlin)이 소프트웨어 엔지니어들의 고충을 해결하고 팀 단위로 소프트웨어를 개발할 때 겪게 되는 소프트웨어 엔지니어링 문제들을 해결하기 위해 디자인된 프로그램 언어 특성들을 보면서 이런 것들이 사이버 물리 시스템 개발에 어떤 의미를 갖는지 같이 생각해보자.
코틀린(Kotlin)의 데이터 클래스(data class)는 스칼라(Scala)언어의 케이스 클래스(case class)의 기능을 일부 차용한 자질(feature)로, 자바(Java)언어에서 데이터를 전달하는 객체로서 많이 쓰이는 자바 빈즈(Java beans)의 고질적인 문제였던 코드 라인수가 길어지고 지나치게 소스 코드가 장황해지는 문제를 간결하게 해결해준다[13-14, 17].
데이터 클래스는 자바 빈즈(Java beans)를 선언, 정의할 때 getter, setter함수를 일일이 선언, 정의해주어야 하는 문제 때문에 순식간에 코드량이 늘어나는 자바(Java)의 단점을 개선하고, 데이터를 전달하는 객체 사용을 단순히 해당 필드를 public으로 선언하고 접근하도록 하며, 코틀린(Kotlin)에서 데이터 클래스로 선언된 클래스는 해당하는 자바(Java) 표현에서 자동으로 getter, setter함수를 생성하도록 컴파일하게 되어 있어 데이터 객체를 다루기 위해 길어진 소스 코드를 작성하고 다루느라 낭비하는 시간과 노력을 줄일 수 있게 해준다.
C언어에서 소프트웨어 엔지니어들의 가장 큰 고충사항이 포인터를 통한 메모리 관리 과정에서 생기는 실행시간 오류(runtime error)라면, 자바(Java)에서는 가비지 콜렉션을 통해 메모리 관리의 어려움은 많이 해소되지만, “널(null)” 체크 및 처리를 제대로 하지 못해서 생기는 “널 포인터 예외(NullPointerException)” 때문에 많은 고충을 겪는다. 코틀린(Kotlin)의 “널 가능(Nullable)” 형 표현은 “널(null)” 체크 및 이에 따른 형변환과 문제들을 경감해주는 소프트웨어 엔지니어들에게 유용한 언어적 자질중의 하나이다[13-14, 17].
코틀린(Kotlin)에서 “널 가능(Nullable)”로 선언된 변수는 if문을 통해서 널(null) 값인지 여부를 체크하거나, is연산자를 사용해서 객체의 타입을 검사하면 맥락에 맞게 자동으로 형변환을 해준다. 코틀린(Kotlin)언어의 이런 자질은 개발자들이 널(null) 체크와 “널 포인터 예외(NullPointerException)”를 다루기 위해 들여야 하는 노력을 크게 경감시켜 주기 때문에 코틀린(Kotlin)으로 개발된 언어가 예상치 못한 널(null) 값 발생과 이를 제대로 예외 처리하지 않아 생기는 다양한 결함들을 손쉽게 포용하고 소프트웨어의 안전성을 높일 수 있게 해주어 소프트웨어 엔지니어들의 수고를 덜어준다.
코틀린(Kotlin)의 눈에 띄는 특징 중 하나는 역시 함수형 프로그래밍을 지원하면서 소스 코드가 장황해지지 않고 양이 크게 감소하며, 표현이 간결해지는 것이다. 이는 스칼라(Scala)언어의 장점을 많이 도입한 것에서 오는 특성인데, 스칼라(Scala)언어의 경우 자바(Java)언어에 비해 소스 코드 양이 크게 줄고 표현도 훨씬 간결해진다. 필자의 경우 자바(Java)언어에서 몇십 줄에 이르는 소스 코드가 스칼라(Scala)로 표현하면서 단 3~4줄이면 끝나는 경우를 많이 경험했다. 코틀린(Kotlin)이 클로저(closure)와 함수형 프로그래밍을 지원하면서 역시 스칼라(Scala)의 이런 장점을 수용한 것이다[17].
같은 기능을 구현하는데 소스 코드 양을 줄이는 것이 소프트웨어 엔지니어들의 수고를 왜 줄여주는지 선뜻 이해가 안 가시는 분들도 있을 법하다. 더군다나 이 글을 읽으시는 분들 중 CIO와 같은 의사 결정을 주로 하시는 분들이라면 프로그래밍 언어를 디자인할 때부터 소스 코드 양이 대폭 줄어들도록 표현을 간결하게 디자인하는 것이 왜 중요한지 이해가 가지 않을 수 있다.
소스 코드 양이 줄어들면 우선 오류나 버그가 줄어들게 된다. C언어나 자바(Java)와 같은 언어로 프로그래밍을 할 때 소프트웨어 엔지니어들을 가장 괴롭히는 것 하나가 {}나 ()와 같은 코드 블록이나 스코프를 표현하는 기호들을 짝이 맞게 매치하는 것이다. 코드가 표현하는 내용이 복잡해지고 길어지면 이런 블록을 아무리 정성 들여 보기 좋게 표현해도 실수를 하게 마련이고, 또한 예약어와 다르게 이런 블록 표현들은 여러 개가 중첩되어 표현되면 짝이 맞지 않는 부분을 찾기도 어렵다. 그런데, 스칼라(Scala)와 코틀린(Kotlin)의 클로저(closure)와 함수형 프로그래밍을 지원하는 구문을 사용하면 소스 코드의 구조도 단순해지고 읽기도 쉬워진다.
소스 코드 양이 줄어들게 되면 소프트웨어 엔지니어들이 같은 기능을 작성할 때 들이는 시간과 노력이 줄어들어 생산성 향상에도 도움이 된다. 프로그래밍 언어를 배울 때 짜는 예제 정도의 몇십, 몇백 줄 정도의 소스 코드를 작성할 때에는 소스 코드 양을 줄이는 것이 얼마나 도움이 되는지 체감하기 어렵다. 그렇지만, 현대 소프트웨어의 상당수는 분산 컴퓨팅 소프트웨어인 데다가, 시스템의 규모와 복잡성에 따라 소프트웨어의 크기도 몇십만, 몇백만 라인을 넘기는 것은 그리 어렵지 않다. 더군다나 이런 대형 소스 코드는 한 사람이 작성하는 것이 아니라 팀이 개발하게 된다. 프로그래밍 스타일과 생각도 많이 다른 여러 사람이 작성한 대형 소스 코드를 읽고 이해하면서 개발하는 것은 정말 어려운 일이며, 이런 대형 소프트웨어의 소스 코드 수준에서의 품질을 관리하기는 정말 쉽지 않은 일이다.
코틀린(Kotlin) 개발자들은 현대의 소프트웨어 개발 과정이 이런 팀으로 이루어지는 소프트웨어 엔지니어링 과정이라는 것을 인지하고, 팀으로 개발하는 소프트웨어 엔지니어링을 효과적으로 지원할 수 있도록 언어 디자인부터 근본적으로 다시 고려한 언어라는 것이 코틀린(Kotlin)이 다른 언어들과 다른 근본적인 차이이다. 과거 C/C++와 자바(Java)에 비하면 코틀린(Kotlin)의 표현들은 간결하고 가독성도 높다. 함수형 프로그래밍을 어렵지 않게 수용한 덕분에 함수형 프로그래밍을 통해 얻을 수 있는 극단적인 단순함을 소프트웨어 엔지니어들이 어렵게 느끼지 않고도 활용할 수 있게 되었다.
이렇게 표현의 간결함과 경제성을 추구한 코틀린(Kotlin)언어의 디자인 덕분에 소프트웨어 엔지니어들이 같은 기능을 작성하더라도 소스 코드의 양을 대폭 줄이고 더 가독성이 높은 소스 코드를 작성할 수 있게 되었다. 소프트웨어 엔지니어 한 사람이 들이는 노력과 시간도 경감이 되지만, 소프트웨어를 개발하고 유지보수하는 팀의 노력과 시간도 경감할 수 있게 되어 소프트웨어의 품질이 더 높아지게 된다.
사실 소프트웨어 엔지니어링이라는 학문의 발전을 촉발했던 “소프트웨어의 위기”라는 이런 현상 때문에 소프트웨어 개발에 도움이 되는 수많은 방법과 도구들이 개발되어 오늘날 소프트웨어 엔지니어들이 더 복잡하고 세련된 소프트웨어를 개발하게 되었다. 기존의 소프트웨어 엔지니어링 도구들은 이미 디자인된 프로그래밍 언어의 특성을 지원하도록 도구들이 개발, 활용되었다면, 코틀린(Kotlin)은 코틀린(Kotlin)언어를 만든 회사인 젯브레인즈가 소프트웨어 개발 도구를 만드는 회사이고, 코틀린(Kotlin)을 지원하는 소프트웨어 개발 도구와 이의 활용을 코틀린(Kotlin)언어를 디자인하기 시작한 초반부터 소프트웨어 엔지니어들이 고려한 것이 다른 프로그래밍 언어와 근본적으로 큰 차이이다.
프로그래밍 언어중에서 객체지향 소프트웨어 개발의 효시가 된 스몰토크(Smalltalk)가 바로 이런 접근 방식으로 디자인된 몇 안 되는 언어의 하나이다. 스몰토크는 프로그래밍 언어를 디자인할 때부터 “클래스 및 객체 브로우저”와 같이 이클립스(Eclipse) 같은 현대 개발 도구에서 볼 수 있는 개발 도구가 같이 고려되어 개발되었다. 코틀린(Kotlin)도 프로그래밍 언어와 함께 젯브레인즈 고유의 영역인 소프트웨어 개발 도구와 환경이 같이 개발되어 지원되기 시작한 아주 드문 경우이다. 코틀린(Kotlin)언어는 젯브레인즈의 개발 환경인 IntelliJ IDEA에 코틀린(Kotlin)언어 지원을 위한 플러그인이 코틀린(Kotlin)언어 초창기부터 지원되어 코틀린(Kotlin) 개발 환경의 일부로서 지원되고 있고, 많이 쓰이는 개발 환경인 이클립스 플러그인과 빌드 도구인 앤트(Ant), 메이븐(Maven), 그레이들(Gradle)에서도 기본으로 지원되고 있다.
프로그래밍 언어 개발 초반부터 이렇게 개발 도구가 완전하게 지원되어 포함되는 경우는 매우 드문 경우이다. 프로그래밍 언어를 디자인하고 개발하는 초반부터 팀으로서 개발 협업을 고려하여 디자인하고, 팀 개발을 지원하기 위한 소프트웨어 개발 및 빌드 도구들을 완전하게 개발, 지원하기 시작하며, 코틀린(Kotlin) 개발의 시작이 된 스칼라(Scala)의 긴 컴파일 타임을 자바(Java) 수준으로 줄일 수 있는 프로그래밍 언어를 개발한다는 목표를 가지고 프로그래밍 언어를 근본적으로 다시 설계, 개발하는 노력을 들이는 것이 사이버 물리 시스템과 클라우드 컴퓨팅 시스템과 어떤 관계가 있을까?
사이버 물리 시스템은 규모나 복잡성으로 보았을 때 하둡과 같이 특징지어질 수 있는 새로운 기술이라기보다는 엔지니어링 체계에 가깝다. 사이버 물리 시스템은 지금까지 사람들이 만들어온 기계와 시스템중에서 가장 복잡하고 규모 면에서도 가장 큰 시스템들로 발전해 나갈 것으로 보인다.
이런 사이버 물리 시스템들을 개발할 때, 다양한 배경을 가진 과학자와 엔지니어들이 설계, 디자인하고 개발에 참여하면서, 이들이 개발하는 소프트웨어에 대해 쉽게 이해하고 구현할 수 있도록 하는 프로그래밍 언어가 없다면 크고 복잡한 사이버 물리 시스템 소프트웨어를 결함 없이 신뢰성 있게 동작시키기 위해서는 훨씬 더 많은 시간과 노력이 필요하게 될 것이다. 또한, 결함과 오류가 많아져 원하는 수준의 안전성을 확보하기 어려워지기 때문에 전체 시스템이 목적하는 기능과 서비스를 제공하기 어려워질 것이다.
프로그래밍 언어에서 제공되는 작은 자질 하나가 대형 사이버 물리 시스템을 위한 소프트웨어를 개발할 때에는 수천, 수만 라인의 소스 코드, 또는 수십, 수백 일에 걸치는 개발 일정을 단축할 수 있게 해줄 수도 있다. 나비의 날갯짓 하나가 연쇄 작용을 통해 증폭되면서 지구 반대편에 폭풍을 일으킬 수도 있다고 하는 일종의 “나비 효과(butterfly effect)”인 셈이다.
프로그래밍 언어는 사람이 사용하는 언어와 비슷해서, 새롭게 디자인한 프로그래밍 언어가 정말로 유용하고 쓸모 있는지 확인하기 위해서는 최소 십 년 이상의 시간이 걸리게 마련이다. 수십 년에 걸쳐 발전된 컴퓨터 과학과 소프트웨어 기술의 발전으로 요즘은 예전에 비해 프로그래밍 언어를 만드는 것이 상대적으로 쉬워졌다. 범용 프로그래밍 언어까지 아니더라도, 요즘 나오는 그루비(Groovy), 코틀린(Kotlin)이나 스칼라(Scala) 같은 언어는 언어 자체에서 도메인 특화 언어(Domain-Specific Language; DSL)를 쉽게 만들고 확장할 수 있는 기능을 제공하여 사용자의 도메인에 맞는 프로그래밍 언어를 만들어 활용하기도 쉬워졌다. 최근 다양한 프로그래밍 언어들이 새롭게 나타나고 경쟁하는 것도 이런 상황을 반영해주는 것이다.
프로그래밍 언어나 도메인 특화 언어를 개발하고 활용하는 것이 쉬워졌기 때문에, 사이버 물리 시스템과 같이 복잡한 시스템을 만들 때 아예 시스템 특성에 맞고 개발 비용과 시간을 절약하기 위해 새로운 종류의 프로그래밍 언어나 도메인 특화 언어를 개발해서 소프트웨어 복잡도를 근본적인 제어하는 것도 가능해진 것이다. 코틀린(Kotlin)과 같은 언어가 이런 트렌드를 반영한다고 볼 수 있다.
사이버 물리 시스템과 클라우드 컴퓨팅을 위한 프로그래밍 환경의 미래를 엿볼 수 있게 해주는 프로그래밍 언어의 마지막 예로 요즘 시스템 프로그래밍 언어로 주목받으며 성장하고 있는 “러스트(Rust)” 언어를 살펴보려고 한다.
“러스트(Rust)” 언어는 파이어폭스 웹브로우저로 유명한 모질라 재단에서 일하던 그레이든 호아레라는 소프트웨어 엔지니어에 의해 2006년에 처음으로 개발되었고, 이후 그레이든이 일하고 있던 모질라 재단이 공식적으로 후원을 하면서 같이 개발에 참여하였다[21]. 2012년에 처음으로 0.1 알파 버전이 공개되었으며, 2020년 현재 1.41.1 버전이 공개된 상태이다[19-20].
러스트언어 또한 최근 프로그래밍 언어의 가장 큰 특징 중 하나인 함수형 프로그래밍(functional programming)과 인터넷 환경에서의 프로그래밍을 위한 개선된 병행(concurrent) 프로그래밍을 지원한다. 러스트언어 자체가 인터넷에서 실행되는 클라이언트와 서버 프로그래밍을 효과적으로 할 수 있는 언어로 개발되었기 때문에 인터넷 환경에서의 확장성을 효과적으로 지원할 수 있는 병행 프로그래밍 지원이 언어 개발 초기부터 목표였다.
러스트언어에서 눈여겨보아야 할 특징은 바로 컴파일된 바이너리의 안전성과 메모리의 직접 관리, 컴파일 시간 메모리 할당 오류 검출, 타입 추론과 같이 시스템 프로그래밍을 하는 개발자들이 가장 취약한 부분을 지원하는 기능을 가졌다는 점이다.
C와 C++언어를 사용하는 소프트웨어 엔지니어라면 누구나 공감하는 것이 바로 메모리 관리의 어려움일 것이다. 1998년 처음 제정된 C++ ANSI/ISO 표준 이후에 기존의 포인터를 보완하는 새로운 종류의 포인터 라이브러리들이 표준 템플릿 라이브러리에서 지원되기 시작하면서 예전보다는 메모리 관리가 조금 수월해졌다고 해도, C/C++로 개발된 소프트웨어들은 언제나 실행 시간(runtime) 메모리 오류가 일어날 수 있는 잠재적인 폭탄을 안고 있는 셈이다.
메모리 오류가 가장 많이 일어나는 경우는 초기화되지 않는 포인터로 인해 생기는 문제, 그리고 포인터에 할당된 메모리를 미처 해제하지 않고 프로그램이 종료되거나 다른 메모리 영역이 포인터 변수에 할당되어 메모리 누수가 생기는 경우인데, 메모리 관리 오류들은 컴파일 때 검출되지 않고 실행 시간 오류가 되는 경우가 많아 소프트웨어 엔지니어들이 찾아내고 수정하기가 어려웠다.
러스트언어는 이렇게 메모리 관리 과정에서 일어나는 소프트웨어 결함과 생산성 저하를 막기 위한 구문과 자질을 포함하여 메모리 관리의 안전성과 컴파일 시 메모리 오류 검출을 지원하는 기능을 가지고 있다. 지나친 메모리 관리의 통제로 인해 생길 수 있는 프로그래밍의 경직성을 해소할 수 있도록, 프로그래머 자신이 위험을 안고 직접 메모리를 제어할 수 있도록 하는 “안전하지 않은 러스트(unsafe rust)” 모드를 지원하는 “unsafe” 예약어를 가지고 있다[19-20, 23-24].
러스트언어가 가장 각광 받는 이유가 바로 메모리 관리를 비롯한 시스템 프로그래밍의 안전성을 강화하여 컴파일 시 오류를 낼 수 있도록 한 것이다. 지금까지 C/C++ 언어를 사용하던 시스템 프로그램 및 저수준(low level) 소프트웨어를 개발하던 소프트웨어 엔지니어들이 얼마나 C/C++언어의 메모리 관리를 활용하는 과정에서 어려움을 겪었는지 알 수 있을 법하다.
사이버 물리 시스템의 개발 과정은 임베디드 시스템과 같이 커널 및 저수준 프로그래밍이 필요한 소프트웨어 계층과 고수준의 서비스 계층을 구현하는 것과 같이 다양한 계층에서의 소프트웨어 개발과 데이터 수집, 여러 계층에서 수집된 데이터를 기반으로 하는 기계 학습 및 인공지능 기술을 활용한 자동화된 판단, 이 판단 결과를 사이버 물리 시스템의 물리 요소 제어를 위한 다양한 계층의 소프트웨어에 피드백을 주는 과정을 포함한다. 이때, 계층별로 필요한 로직을 구현하는 데 집중하지 못하고, 하위 계층에서 일어나는 메모리 관리 오류 같은 것들에 자꾸 신경 쓸 수밖에 없다면 안 그래도 복잡한 사이버 물리 시스템을 개발하는데 생산성을 높이기는 정말 어려울 것이다.
러스트와 같은 언어가 앞으로의 사이버 물리 시스템과 클라우드 컴퓨팅 통합에 주는 의미는 바로 이와 같은 저수준의 시스템 자원 관리를 프로그래밍 언어 수준에서 손쉽게 하고 복잡도를 낮출 수 있도록 지원하는 것에 있다. 사이버 물리 시스템의 복잡도와 개발 범위의 광범위함을 극복하고, 다양한 계층 수준의 자원 관리를 하면서 신뢰성 있는 서비스를 만들기 위해서는 이를 만드는 소프트웨어 엔지니어들과 데이터 과학자들이 시스템 개발의 모든 계층 수준에서 일관된 생산성을 발휘할 수 있도록 기존 프로그래밍 언어의 단점을 보완하는 것이 필요하고, 현재 프로그래밍 언어 기술의 트렌드가 이를 보여주고 있다. 사이버 물리 시스템의 발전과 함께 프로그래밍 언어와 환경의 발전이 기대되는 이유이기도 하다.
사이버 물리 시스템을 이용한 지능형 서비스가 인간과 기계의 상호 작용을 통해 사회 문제를 해결하는 고급 사회 인프라로서 역할을 다하도록 빅데이터와 데이터 과학이 온전하게 활용되기 위해서는, 사이버 물리 시스템 개발 과정의 수많은 기술적인 난관과 복잡성을 극복하게 해주는 다양한 기술들이 필요하다. 이런 기술 중, 클라우드 컴퓨팅을 이용한 자원 관리와 저수준의 시스템 프로그래밍 과정에서 동원되는 자원 관리가 다양한 계층에서 통합되고 프로그램되는 데에 가장 근본적이고 중요한 기술인 클라우드 컴퓨팅 서비스 API와 최근 급격하게 발전하고 있는 새로운 프로그래밍 언어의 발전 양상을 같이 살펴보았다.
클라우드 컴퓨팅 기술의 발전과 함께 점점 구체적으로 정의, 확장되어 가는 클라우드 컴퓨팅 인터페이스들은 그 인터페이스를 정의하고 구현하는 과정에 들어가는 많은 시행착오와 비용, 개발 노력으로 인해 그 자체로 중요한 의미가 있다고 얘기하였다. 사이버 물리 시스템에 요구되는 다양한 계층의 자원 관리와 소프트웨어 복잡도 극복을 위해, 간결한 프로그래밍 표현 방식, 함수형 프로그래밍, 간단한 병행성(concurrency) 지원, 널 값 및 초기화되지 않은 변수의 관리, 소프트웨어 엔지니어링 도구 지원 강화, 메모리 관리 개선과 같은 방법을 통해 소프트웨어 엔지니어들의 고충 사항을 해결하려 노력하고 있는 “고(Go)”, “코틀린(Kotlin)”, “러스트(Rust)”와 같은 현대 프로그래밍 언어들의 눈에 띄는 특징을 같이 살펴보았다.
이들 클라우드 컴퓨팅 서비스 인터페이스와 새로운 프로그래밍 언어들의 자질들은 사이버 물리 시스템이 데이터를 기반으로 자율적, 지능적으로 환경에 적응하며 우리에게 서비스를 제공하는데 필요한 컴퓨팅 자원을 손쉽게 끌어 쓰고 관리할 수 있도록 하여 사이버 물리 시스템의 실현에 중요한 디딤돌 역할을 하게 될 것이다. 최근 인공지능과 같이 눈에 띄지는 않지만, 분명한 효용과 쓰임으로 보다 구체적인 비즈니스 기회를 만들어 내는 이런 흐름을 독자 여러분들이 관심을 가지고 지켜보았으면 한다.
사이버 물리 시스템, 프로그래머블 하드웨어, 클라우드 컴퓨팅
이번 글을 마무리하기 전에 마지막으로 클라우드 컴퓨팅이 발전하면서 나타난 최근 하드웨어 아키텍처의 변화에 대해 필자의 생각을 공유하고 싶다. 사이버 물리 시스템과 클라우드 컴퓨팅의 상호발전 과정에서 독자 여러분들이 관심을 가지고 지켜봐야 할 중요한 트렌드로 “프로그래머빌리티(programmability)”가 높아지고 소프트웨어와의 통합이 긴밀한 하드웨어 아키텍처가 발전하는 경향을 들고 싶다.
사실 컴퓨터 자체가 이미 “프로그램 가능(programmable)”한 하드웨어이지만, 필자가 여기서 얘기하는 프로그래머블 하드웨어란 전통적인 계층과 구조의 노드 단위의 컴퓨터에서 얘기하는 “프로그래머빌리티(programmability)”가 아니다. CPU와 같은 프로세서, 메모리와 같은 휘발성 저장장치, SSD와 같은 비휘발성 저장장치, 그리고 네트워크 자원이 서버 노드 단위로 가상화 기술과 클라우드 컴퓨팅 소프트웨어를 통해 분할, 할당, 관리되는 것이 아니라, 클라우드 컴퓨팅의 개념과 컴퓨팅 자원의 확장성 있는 프로그래머빌리티(programmability) 개념을 근본적으로 수용한 컴퓨팅 하드웨어를 의미하는 것이다.
클라우드 컴퓨팅의 개념이 하드웨어 수준으로 근본적으로 수용된 프로그래머블 하드웨어에 가장 근접한 시스템은 최근 인텔이 데이터센터 컴퓨팅과 클라우드 컴퓨팅을 위해 발표했던 “랙스케일 아키텍처(Rack-Scale Architecture; RSA)” 또는 “랙스케일 디자인(Rack-scale Design; RSD)”이다[27-32].
지난 열 번째 글에서 잠시 소개한 바와 같이 인텔의 랙스케일 아키텍처는 컴퓨팅 자원을 랙(rack) 단위로 필요에 맞게 조직하고, 프로세서, 메모리, 스토리지, 네트워크 자원을 랙 단위의 자원 구성과 관리를 수행하고 RESTful API 인터페이스를 제공하는 팟 매니저(pod manager)가 필요에 따라 조합하여 하나의 서버와 같은 노드로 구성할 수 있는 컴퓨팅 시스템이다[27-32].
랙스케일 디자인은 데이터센터의 컴퓨팅 자원을 하드웨어 수준에서 클라우드 컴퓨팅을 지원할 수 있도록 만들어 클라우드 컴퓨팅의 성능과 데이터센터에 상면된 컴퓨팅 자원 활용의 효율성을 높이기 위한 기술이다. 랙스케일 디자인이 그 목표했던 기능을 모두 갖추게 되면, 가상 머신과 같은 하드웨어 가상화 기술이 없어도 하드웨어 수준에서 컴퓨팅 자원 분할과 재조직이 가능하게 되고, 사용자가 원하는 만큼의 컴퓨팅 자원을 묶어 테넌트를 부여하고 조직할 수 있게 된다.
기존 서버 노드 단위로 구성되던 랙 때문에 한 노드를 구성하는 서버 섀시의 하드웨어 제약으로 전체적인 성능에 제약을 받은 과거 분산 컴퓨팅 시스템보다 랙스케일 디자인을 기반으로 조직된 하드웨어는 프로세서, 메모리, 스토리지, 네트워크 수준에서 자원을 쉽게 확장할 수 있어 현재의 클라우드 컴퓨팅 기술보다 훨씬 더 유연하고 확장성 있게 자원을 활용할 수 있다.
랙스케일 디자인의 프로그래머빌리티를 제공할 수 있도록 하는 특징은 바로 “팟 매니저(Pod Manager)”이다. “팟 매니저(Pod Manager)”는 랙스케일 디자인의 하드웨어 자원의 관리 및 프로비저닝을 할 수 있도록 하는 프로그래밍 인터페이스를 갖춘 소프트웨어로, 랙스케일 디자인 규격에 포함된 표준 소프트웨어이다. 오픈스택과 같은 클라우드 컴퓨팅 소프트웨어나 네트워크 기능 가상화(NFV)에 사용되는 MANO(Management And Network Orchestration)와 같은 오케스트레이터(orchestrator)에서 랙스케일 디자인 규격을 준수하는 랙에 있는 CPU, 메모리, 저장 장치 및 네트워크 자원을 프로비저닝하고 관리할 수 있도록 하는 소프트웨어 구성요소가 “팟 매니저(Pod Manager)”이다.
“팟 매니저(Pod Manager)”는 RESTful API 형태로 접근할 수 있도록 되어 있어서, 랙스케일 디자인을 준수하는 랙이 네트워크에만 연결되어 있으면 네트워크를 통해 RESTful API에 접근할 수 있는 소프트웨어가 얼마든지 “팟 매니저(Pod Manager)”를 통해 컴퓨팅 자원을 프로비저닝하고 제어, 관리할 수 있다. 이 “팟 매니저(Pod Manager)”를 통해서 랙 내부의 컴퓨팅 자원을 사용자가 원하는 대로 조직, 구성하여 응용 프로그램에 맞는 컴퓨팅 자원을 구성할 수 있도록 하는 것이다.
랙스케일 디자인이 상징적으로 표현하는 것과 같이, 앞으로 데이터센터의 IT자원은 노드 단위 계층이 파괴되고, 100Gbps 이더넷과 같이 네트워크의 성능이 저지연, 고대역폭을 지원할 수 있도록 향상되면서 자원 통합의 경계가 데이터센터 스케일로 확장되며, “팟 매니저(Pod Manager)”와 같이 원격 API로 IT자원을 통합, 제어, 관리할 수 있도록 IT자원의 프로그래머빌리티가 개선된다. 이를 통해, 클라우드 컴퓨팅에서 지능형 사이버 물리 시스템을 위해 제공할 수 있는 자원 규모가 기하급수적으로 확장된다.
이렇게 자원 통합, 관리의 스케일이 향상된 클라우드 컴퓨팅 기술은 사이버 물리 시스템의 지능을 크게 높일 수 있게 해주며, 이렇게 필요한 컴퓨팅 자원이 더 풍부하게 공급되면서 사이버 물리 시스템은 더 많은 빅데이터를 활용할 수 있게 된다.
서른일곱 번째 글부터 지금까지 세 편의 글에서 살펴본 것 같이, 데이터센터 하드웨어 기술부터 시작해서, 프로그래밍 언어의 발전과 클라우드 컴퓨팅을 위한 분산 컴퓨팅 시스템 기술에 이르기까지 다양한 수준에서 일어나고 있는 클라우드 컴퓨팅 기술의 발전을 통해 사이버 물리 시스템으로 상징되는 미래 지능형 인프라의 지능이 크게 높아지게 될 것을 짐작해볼 수 있다.
클라우드 컴퓨팅 소프트웨어 기술의 발전이 인텔 랙스케일 디자인과 같은 하드웨어 아키텍처와 기술을 발전으로 이어지고, 이런 하드웨어 아키텍처와 기술의 발전으로 향상되는 데이터센터 스케일의 자원 확장성이 다시 클라우드 컴퓨팅 소프트웨어와 서비스를 향상시키는 선순환이 지능형 사이버 물리 시스템이 사회 인프라로서 실현되고 자리 잡는데 튼튼한 기반이 될 것이다.
클라우드 컴퓨팅 기술의 발전이 사이버 물리 시스템에 필요한 빅데이터를 더 쉽고 빠르게 다룰 수 있도록 하면서 빅데이터 기술의 발전도 가속화되고, 데이터 과학과 이를 위한 데이터 처리, 분석을 자동화하기 위한 인공지능 기술의 발전을 가속하게 될 것이다. 이런 측면에서 클라우드 컴퓨팅의 발전이 지능형 사이버 물리 시스템의 발전과 실현, 이를 위한 빅데이터 기술과 데이터 과학에 깊게 관련되어 있으며, 앞으로 우리가 클라우드 컴퓨팅 기술의 발전을 주의 깊게 지켜보아야 하는 이유이다.
[참고문헌]
[1] 김진철, “LHC에서 배우는 빅데이터와 machine learning 활용 방안”, 2016년 9월 28일, A CIO Conversation for Technology Leadership – Breakfast Roundtable 발표 자료
[2] 김진철, “김진철의 How-to-Big Data (9) – 빅데이터와 클라우드 기술 (1)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/35688)
[3] 김진철, “김진철의 How-to-Big Data (10) – 빅데이터와 클라우드 기술 (2)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/36179)
[4] 김진철, “김진철의 How-to-Big Data (11) – 빅데이터와 클라우드 기술 (3)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/36540)
[5] 김진철, “김진철의 How-to-Big Data (12) – 빅데이터와 클라우드 기술 (4)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/36748)
[6] 김진철, “김진철의 How-to-Big Data (13) – 빅데이터와 클라우드 기술 (5)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/37099)
[7] 김진철, “김진철의 How-to-Big Data (14) – 빅데이터와 클라우드 기술 (6)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/37380)
[8] Larry Peterson, “CORD: Central Office Re-architected as a Datacenter,” presentation at OpenStack Summit 2015, Tokyo, 2015. (https://www.openstack.org/videos/summits/tokyo-2015/cord-central-office-re-architected-as-a-datacenter)
[9] Alan A. A. Donovan, Brian W. Kernighan, The Go Programming Language, Addison-Wesley, 2016.
[10] Documentation – The Go Programming Language, https://golang.org/doc/.
[11] Go (programming language) – Wikipedia, https://en.wikipedia.org/wiki/Go_(programming_language)).
[12] Go(프로그래밍 언어) – 나무위키, https://namu.wiki/w/Go(프로그래밍%20언어).
[13] Dmitry Jemerov and Svetlana Isakova, Kotlin in Action, Manning Publications, 2017. (https://www.manning.com/books/kotlin-in-action)
[14] Language Guide – The Kotlin Programming Language, https://kotlinlang.org/docs/reference/.
[15] Kotlin (programming language) – Wikipedia, https://en.wikipedia.org/wiki/Kotlin_(programming_language).
[16] Kotlin – 나무위키, https://namu.wiki/w/Kotlin.
[17] Hazealign, “Android 개발을 수주해서 Kotlin을 제대로 써봤더니 최고였다.”, https://gist.github.com/Hazealign/1bbc586ded1649a8f08f. (원문: 오모치 메타루(omochimetaru), “Android開発を受注したからKotlinをガッツリ使ってみたら最高だった”, https://qiita.com/omochimetaru/items/98e015b0b694dd97f323.)
[18] 심재석, “카카오가 메시징 서버에 자바 대신 코틀린 써본 경험담”, Byline Network, 2018년 9월 5일. (https://byline.network/2018/09/5-20/)
[19] Steve Klabnik and Carol Nichols, with contributions from the Rust Community, The Rust Programming Language, The Mozilla Foundation, 2018. (https://doc.rust-lang.org/book/)
[20] The Mozilla Foundation, The Rust Reference, https://doc.rust-lang.org/reference/index.html.
[21] Wikipedia, “Rust (programming language),” https://en.wikipedia.org/wiki/Rust_(programming_language).
[22] Jim Blandy, Jason Orendorff, Programming Rust – Fast, Safe Systems Development, O’Reilly Media, December 2017. (http://shop.oreilly.com/product/0636920040385.do)
[23] Tim McNamara, Rust in Action, Manning Publications, July 2017. (https://www.manning.com/books/rust-in-action)
[24] Rahul Sharma, Vesa Kaihlavirta, Claus Matzinger, The Complete Rust Programming Reference Guide: Design, develop, and deploy effective software systems using the advanced constructs of Rust, Packt Publishing, May 22, 2019. (https://www.packtpub.com/application-development/complete-rust-programming-reference-guide)
[25] Rahul Sharma, Vesa Kaihlavirta, Mastering Rust – Second Edition, Packt Publishing, January 31, 2019. (https://www.packtpub.com/application-development/mastering-rust-second-edition)
[26] Claus Matzinger, Rust Programming Cookbook, Packt Publishing, October 18, 2019. (https://www.packtpub.com/programming/rust-programming-cookbook)
[27] Jean-Louis Lezaun, “What Future for the Data Center,” presentational material at OpenStack in Action 4! organized by eNovance, October 10, 2013. (http://www.slideshare.net/enovance/intel-clouddatacenterdec5th2013)
[28] Ryousei Takano, “From Rack scale computers to Warehouse scale computers,” July 31, 2014. (http://www.slideshare.net/oraccha/rack-scale-computers-to-warehouse-scale-computers)
[29] Figen Ulgen, Intel® Rack Scale Design Gaining Momentum, Intel IT Peer Network, January 10, 2018. (https://itpeernetwork.intel.com/rack-scale-design-momentum/#gs.12y7pv)
[30] Intel, “Standardizing the Hyperscale Data Center.” (https://www.intel.co.kr/content/www/kr/ko/architecture-and-technology/rack-scale-design/standardizing-the-hyperscale-data-center-infographic.html)
[31] Intel, “Meeting the Challenges of Data Center Digital Transformation.” (https://www.intel.co.kr/content/www/kr/ko/architecture-and-technology/rack-scale-design/rack-scale-design-dc-transformation-brief.html)
[32] Intel, “Intel® Rack Scale Design (Intel® RSD) Architecture,” White Paper. (https://www.intel.co.kr/content/www/kr/ko/architecture-and-technology/rack-scale-design/rack-scale-design-architecture-white-paper.html)
[33] Intel, “Intel Rack Scale Design (Intel RSD) – Getting Started Guide, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/getting-started-guide-v2-5.pdf)
[34] Intel, “Intel Rack Scale Design (Intel RSD) – Architecture Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/architecture-spec-v2.5.pdf)
[35] Intel, “Intel Rack Scale Design (Intel RSD) – Pod Manager (PODM) User Guide, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/podm-user-guide-v2-5.pdf)
[36] Intel, “Intel Rack Scale Design (Intel RSD) – Pod Manager (PODM) Representational State Transfer (REST) API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/podm-api-spec-v2.5.pdf)
[37] Intel, “Intel Rack Scale Design (Intel RSD) – Pooled System Management Engine (PSME) User Guide, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/psme-release-notes-v2-5.pdf)
[38] Intel, “Intel Rack Scale Design (Intel RSD) – Pooled System Management Engine (PSME) Representational State Transfer (REST) API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/psme-user-guide-v2-5.pdf)
[39] Intel, “Intel Rack Scale Design (Intel RSD) – Storage Services API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/storage-services-api-spec-v2-5.pdf)
[40] Intel, “Intel Rack Scale Design (Intel RSD) – Rack Management Module (RMM) Representational State Transfer (REST) API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/rmm-api-spec-v2-5.pdf)
[41] Intel, “Intel Rack Scale Design (Intel RSD) – Generic Assets Management Interface (GAMI) Representational State Transfer (REST) API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/gami-api-spec-v2-5.pdf)
[42] Mohan J. Kumar, “Look Inside Intel Rack Scale Architecture,” a contributed talk in the 9th Extremely Large Databases Conference, May 24-26, 2016. (https://www-conf.slac.stanford.edu/xldb2016/talks/published/Tues_6_Mohan-Kumar-Rack-Scale-XLDB-Updated.pdf)
[43] Scott Fulton III, “Intel Finally Releases Its Rack Scale Design to Open Source,” DataCenter Knowledge, July 29, 2016. (https://www.datacenterknowledge.com/archives/2016/07/29/intel-finally-releases-rack-scale-design-open-source)
[44] Sabina Jeschke, “Everything 4.0? – Drivers and Challenges of Cyber Physical Systems,” Forschungsdialog Rehinland – Invited Talk, Wuppertal, December 4, 2013.
[45] Helen Gill, “From Vision to Reality: Cyber-Physical Systems,” Presentation at the HCSS National Workshop on New Research Directions for High Confidence Transportation CPS: Automotive, Aviation, and Rail, November 18-20, 2008.
[46] Insup Lee, “Cyber Physical Systems – The Next Computing Revolution,” Lecture – CIS 480, Department of Computer and Information Science, University of Pennsylvania, 2009.
[47] Insup Lee, “Cyber Physical Systems – The Next Computing Revolution,” Adream Lecture, LAAS-CNRS, June 15, 2010.
[48] Raj Rajkumar, Dionisio de Niz, Mark Klein, Cyber-Physical Systems, in the SEI Series in Software Engineering, Addison-Wesley, 2017.
[49] Rajeev Alur, Principles of Cyber-Physical Systems, The MIT Press, 2015.
[50] Edward Ashford Lee, Sanjit Arunkumar Seshia, Introduction to Embedded Systems – a Cyber-Physical Systems Approach, 2nd Edition, The MIT Press, 2017.
[51] 진회승, 서영희, 김원태, “CPS의 기능, 비기능적 소프트웨어 요구사항 분석”, 연구보고서 2017-008, 소프트웨어정책연구소(SPRi), 2018년 4월.
[52] Francesca Palumbo, “Introduction on Cyber-Physical Systems,” Lecture at CPS Summer School – From Concepts to Implementation, Alghero(IT), September 17 ~ 21, 2018.
[53] Wolfgang Wahlster, “Industrie4.0: Cyber-Physical Production Systems for Mass Customization,” German-Czech Workshop on Industrie4.0/Průmysl4.0 Prague, April 11, 2016.
[54] Teodora Sanislav, Sherali Zeadally, George Dan Mois, “A Cloud-Integrated, Multilayered, Agent-Based Cyber-Physical System Architecture,” Computer, April, 2017.
[55] Kartikey Joshi, Dhivya Sampath Kumar, Rahul Mehta, Shiva Muthuraj, “Autonomous Vehicles (AVs) – Technology, Economics, and Opportunities,” (https://www.slideshare.net/Funk98/autonomous-vehicles-60845449)
[56] Edward A. Lee, “The Past, Present and Future of Cyber-Physical Systems: A Focus on Models,” Sensors Vol. 15, pp. 4837-4869, 2015. doi:10.3390/s150304837
[57] Kyoung-Dae Kim and P. R. Kumar, “Cyber-Physical Systems: A Perspective at the Centennial,” Proceedings of the IEEE, Vol. 100, p. 1287 ~ 1308, May 13th, 2012.
[58] Kyoung-Dae Kim and P. R. Kumar, “An Overview and Some Challenges in Cyber-Physical Systems,” Journal of the Indian Institute of Science, Vol. 93(3), p. 341 ~ 351, Jul.–Sep. 2013. (http://journal.library.iisc.ernet.in/index.php/iisc/article/view/1693)
[59] Alessandro D’Innocenzo, Henry Muccini, “Introduction to CPS,” 1ST DISIM WORKSHOP ON ENGINEERING CYBER-PHYSICAL SYSTEMS, TUESDAY 26, JANUARY 2016.
[60] Urban Sedlar, Mitja Rakar, Andrej Kos, “Big Data Analysis and Cyber-Physical Systems,” in Cyber-Physical Systems – A Computational Perspective, edited by Gaddadevara Matt Siddesh, Ganesh Chandra Deka, Krishnarajanagar GopalaIyengar Srinivasa, Lalit Mohan Patnaik, CRC Press, 2016.
[61] Krishnarajanagar GopalaIyengar Srinivasa, Gaddadevara Matt Siddesh and Kushagra Mishra, “Influence of Big Data on Cyber-Physical Systems,” in Cyber-Physical Systems – A Computational Perspective, edited by Gaddadevara Matt Siddesh, Ganesh Chandra Deka, Krishnarajanagar GopalaIyengar Srinivasa, Lalit Mohan Patnaik, CRC Press, 2016.
[62] Houbing Song, Qinghe Du, Pinyi Ren, Wenjia Li, and Amjad Mehmood, “Cloud Computing for Transportation Cyber-Physical Systems,” in Cyber-Physical Systems – A Computational Perspective, edited by Gaddadevara Matt Siddesh, Ganesh Chandra Deka, Krishnarajanagar GopalaIyengar Srinivasa, Lalit Mohan Patnaik, CRC Press, 2016.
*김진철 박사는 1997년 한국과학기술원에서 물리학 학사, 1999년 포항공과대학교에서 인공신경망에 대한 연구로 석사 학위를, 2005년 레이저-플라즈마 가속기에 대한 연구로 박사 학위를 받았다. 2005년부터 유럽입자물리학연구소(CERN)의 LHC 데이터 그리드 구축, 개발에 참여, LHC 빅데이터 인프라를 위한 미들웨어 및 데이터 분석 기술을 연구하였다. 이후 한국과학기술정보연구원(KISTI), 포항공과대학교, 삼성SDS를 거쳐 2013년부터 SK텔레콤에서 클라우드 컴퓨팅과 인공지능 기술을 연구하고 있다. 빅데이터와 인공지능 기술의 기업 활용 방안에 대해 최근 다수의 초청 강연 및 컨설팅을 수행하였다. dl-ciokorea@foundryco.com