웨어러블 디바이스, 가전제품, 스마트 팩토리, 스마트 홈, 자동차 등 이제는 임베디드 OS가 적용되지 않는 제품을 찾기 힘든 시대가 되고 있다. 그만큼, 일반 소비자에게 중요하게 보여지지 않을 수도 있는 임베디드 OS는 앞으로 신제품을 출시해야 할 제조 기업 입장에서는 매우 중요한 선택적 이슈를 가져온다. 오픈소스형부터 고가의 OS까지 다양화되고 있는 상황은 이를 선택해야 하는 기업 입장에서는 상당한 난제가 될 수도 있다.
임베디드 OS를 선택하는 기준은 기업마다 다양하겠지만, 가장 중요한 포인트는 제품의 안정성, 효율성을 보장할 수 있어야 한다는 점이다. 스마트워치가 됐든 항공기가 됐든 어떠한 경우더라도 검증되지 않는 OS를 적용했을 경우에 발생하는 문제들이 고스란히 일반 소비자의 불편으로, 혹은 자동차, 항공기, 군사용 기기와 같이 인간의 생명과 직결되는 부분에 있어서는 매우 위협적인 요인으로 작용한다면, 이는 기업의 생존 측면이나 사회적 측면에서도 돌이킬 수 없는 위험으로 다가올 수밖에 없다. 이러한 측면에서 어떤 기준에서 임베디드 OS를 선택해야 하는 지, 피해야 할 것들은 무엇인지에 대해 명확히 이해하고 실행할 필요가 있다.
이와 관련해 QNX의 말트 문트(Malte Mundt) 시니어 필드 애플리케이션 엔지니어는 ‘임베디드 OS를 선택할 때 피해야 할 7가지 치명적인 실수’라는 보고서에서 “특징, 비용, 지원 옵션 등과 같은 다양한 기준들을 객관적으로 평가해 임베디드 OS를 선택해야 한다고 생각할 수 있으나, 실제로 결정권자를 치명적인 함정으로 빠트릴 수 있는 7가지의 함정이 존재한다”고 밝히고 있다.
말트 문트 엔지니어가 말하는 임베디드 OS를 선택할 때 피해야 할 7가지 치명적인 실수에 대해 정리해본다.


치명적 실수 1. 아예 아무것도 선택하지 않는다
임베디드 OS를 선택하는 의사결정권자들은 애플리케이션에 집중하기 때문에 OS를 선택할 때 충분히 생각하지 않게 된다. 즉 하드웨어와 함께 보내진 OS가 이미 ‘충분히 좋은 것’이라고 가정하고 만다. 이 가정은 기업의 성공에 생각 이상으로 영향을 미칠 수 있다. 왜냐하면, 특정 OS를 기반으로 개발을 시작한다는 것은 5년에서 7년 후에 개발자 또는 개발자의 후임의 유산이 될 소프트웨어 무더기를 만드는 것의 시작이 되기 때문이다.
이러한 실수를 저지르는 관리자들은 앞으로 그들의 삶이 얼마나 달라질 수 있는지를 전혀 알지 못한다. 윈도우와 같은 일반용 OS가 목적하는 대로 행해 질 것으로 기대할 수 있겠는가? 그렇지 않을 경우 문제가 발생하게 되는데, 결국 OS에 대한 통제 측면에서 한계가 있다는 사실을 알게 될 것이다. 중요한 점은 일어나지 말아야 할 문제들을 수정하고 고치는 데 많은 비용이 든다는 점이다. 결국 신중하게 OS를 결정하는 것이 왜 높아진 프로젝트 비용과 지나친 데드라인 위험을 크게 줄여주는 지에 대해 회의를 하게 될 것이다.
치명적 실수 2. 다른 사람이 하는 것을 따라한다
이 실수는 인간에 깊이 내재되어 있는 본성, 즉 확신을 할 수 없는 경우 다른 사람들이 하는 것을 따라하면 된다는 측면과 연결된다. 아주 오래 전, 이 방식은 시도되고 실험 과정을 거쳐 삶을 유지할 수 있게 된 것처럼, 종(種)의 생존에 중요한 역할을 했다.
하지만 현대사회에서 끊임없는 변화는 생활의 일부가 됐고, 혁신은 임베디드 산업에서 심장이 됐다. 따라서 임베디드 OS를 결정할 때, 단순히 사람들이 좌우에서 무엇을 하는 지에 의존하는 것은 위험하다. 화산폭발로 완전히 파괴된 도시 폼페이를 기억하는가? 어째서 폼페이 사람들은 화산 가깝게 도시를 건설하게 됐을까? 아마 누군가 그곳이 집을 짓기에 좋은 장소라 생각했고 이를 본 몇몇 사람들이 따라 집을 지었을 것이다. 그리고 이를 본 사람들은 쉽게 정착을 결정했다.
“화산이 가깝지만 문제될 게 없어. 다른 사람들도 여기에 집을 지었잖아.”
멀리 떨어진 곳에 정착하기로 결정한 사람들은 ‘너무 조심스럽거나 과민한 사람들’이라고 입방아에 오르내렸을 거라 상상해 볼 수도 있다. 이 시점에서 심리학적인 의사결정 과정에서 또 다른 강력한 메커니즘이 효과를 나타내기 시작한다.
“줄을 따라 서라, 너무 다르게 행동하지 마라.”
오늘날에도 사람들의 의사결정 방식은 별로 달라지지 않았다. 고대의 메커니즘을 극복한 사람들만이 임베디드 OS를 결정할 때 성공할 수 있다.
“이 회사에서 우리는 언제나 X를 사용했다”거나 “하드웨어 벤더가 Y를 추천한다” 또는 “우리 대학에서 교수님이 Z가 가장 좋은 선택이라고 하셨다”와 같은 말에 현혹되지 마라.
모든 문제에 대한 책임은 그 사람들이 아닌 자신에 있다. 폼페이가 파괴된 후 그 재앙에 대한 일반적인 반응은 “이건 운명이야”였다. 임베디드에서는 프로젝트가 실패하면 ‘관리 문제’, ‘지나치게 공격적인 일정’, ‘아웃소싱 파트너의 실패’로 원인을 돌릴 것이다. 올바른 임베디드 OS와 툴셋을 결정함으로써 절감할 수 있었던 개발, 테스팅, 문제 수정에 걸리는 많은 시간에 대해서는 별로 생각하지 않는다.
따라서 현재 그리고 미래 요구와 리스크에 입각해 스스로 결정을 내려야 한다. 소속되어 있는 부서 또는 회사에서 지금까지 채용한 적 없는 OS를 제안할 때 빈축을 살 준비를 하라. 그리고 기억하라. 저비용 국가의 기업들은 종종 낮은 예산에 대규모 개발팀을 고용하는 것으로 경쟁한다. 하지만 고비용 국가의 기업들은 언제나 일을 다르게 더 스마트한 방식으로 하는 등 혁신에 초점을 둔다.


치명적 실수 3. 항상 사용한 OS를 계속 사용한다
이는 매우 어려운 문제다. 수년간 이 사업을 해왔고 몇몇 프로젝트를 성공적으로 완료했으며, 회사도 잘 돌아가고 있는데, 굳이 회사에서 현재 사용하고 있는 OS를 계속 사용하지 않을 이유가 있을까?
가장 안전한 것은 과거에 우리가 선택한 경로를 따라가는 것이다. 이는 마케팅 전문가들이 나이가 들어가면서 언급하는 말이기도 하다. 캠페인 대상인 대중을 설득해 브랜드를 바꾸는 것은 점점 어려워지고 있다. 어느 연구에 따르면, 시간의 흐름에 따라 사람들은 선호하는 제품에 더욱 집착하게 된다. 그리고 나이가 들면서 위험을 회피하려는 열망이 점점 깊어지면서 새로운 것이라면 모두 회피하게 된다.
임베디드 OS를 선택할 때, 결정권자들은 변화에 대한 저항에 직면한다는 점을 알아야 한다. 만약 영향을 받았는지에 대해 알라보려면, 과거보다 새로운 발명품 몇 가지에 대해 어떻게 생각하는지 자신에게 자문하고 검증해보면 된다. 즉 소셜 네트워크(Social Network)가 좋다고 생각하는지, 아니면 가능한 거리를 두고 있는지? 인쇄판 서적을 선호하는지, 아니면  eBook 리더 단말기를 가지고 있는지? 전기자동차에 관심을 가지고 있는지, 아니면 별 의미가 없다고 생각하는지? 등처럼 말이다.
둘 중 하나를 제안할 필요는 없다. 물론 모든 새로운 것이 위대하지는 않으며 무조건 수용해야 하는 것도 아니다. 하지만 이러한 것들, 그리고 이와 유사한 것들은 일반적으로 새로운 것에 대한 개인적인 반감 정도를 측정하는 측정기로 사용될 수 있으며, 이러한 방식으로 객관성의 수준을 향상시킬 수 있다.
기존 솔루션에서 알려지지 않은 새로운 솔루션으로 OS를 바꾸는 데에는 상당한 투자가 필요하다. 반면 현재 가지고 있는 것을 고수하면 매우 제한적이 될 수도 있다. 이는 전체적으로 볼 때 많은 경우에 더 높은 비용 선택으로 이어질 수 있다.


치명적 실수 4. 어떤 경우에도 비용 줄이기
소프트웨어가 무료로 배포되고 있을 때 이것을 어디에서 누가 만들었고 무료배포의 이면에는 어떤 동기가 있는 지 아무도 묻지 않는다. 무료배포 제품을 사용하는 것은 인간의 본성이기도 하다. 누가 무료로 주는 차가운 맥주, 그것도 상당량을 주는데 거절할 수 있을까? “공짜인데 뭐”.
소비자들이 무료 소프트웨어와 서비스가 현금으로 계산되지 않는 가격(예를 들어, 광고를 수신해야 한다거나 기꺼이 트래킹되는 것을 받아들이는 식)으로 제공된다는 것을 점차 알게 되지만, 이것도 리눅스처럼 공개 OS에는 적용되지 않는 것처럼 보인다.
그럼 도대체 단점은 어디에 있는가?
높아지고 있는 비용 압력, 폭넓은 사용성으로 일부 의사결정권자들은 리눅스와 같은 공개 OS를 지향하며, 통상적인 선택을 한다.
“그래, 이건 잘 될거야. 잘 안 된다 해도 나중에 고칠 수 있기 때문에 상용 솔루션을 선택하는 것보다 비용도 적게 들거야.”
놀랍게도 임베디드 리눅스는 무료이지만, 많은 OS 전문가와 기업들은 리눅스로 돈을 벌고 있다. 리눅스 관련 지원은 커뮤니티에서 제공하고 있는데, 처음 볼 때에는 커보여도 실제 임베디드 부분의 포션은 그리 크지 않다. 예를 들어, 리눅스 ‘실시간 패치(Real Time Patch)’는 리눅스 선택을 좀더 결정적인 것으로 만드는 데에 필요하지만, 매우 소규모의 사람만으로 유지되고 있다. 만약 이들이 활동을 중단하기로 결정한다면(실제 이미 여러 번 고려됐다), 이 패키지의 미래는 의문일 수밖에 없을 것이다. 겉으로 보기에는 무료인 OS 솔루션은 단지 비용을 산정, 측정, 추적하기 어려운 다른 영역으로 옮겨 놓은 것임이 명백하다.
몇몇 성공적인 대규모 기업을 살펴보자. 메르세데스 벤츠, 포드, 아우디가 온보드 인포테인먼트와 계기판 시스템(instrument cluster systems)에 QNX 임베디드 OS를 채택한다. 이는 단순히 공급할 수 있기 때문만은 아니다. 수백만 대의 자동차에 설치되는 기기들을 위해 임베디드 OS를 선택하는 것은 결코 가벼운 문제가 아니다. 그러면 왜 자동차 메이커들이 리눅스 계열이 아닌 QNX와 같은 상용 OS를 선택하겠는가? 거기에는 4가지 이유가 있다.
첫째, 엄격한 데드라인이다. 신차 모델이 발표될 때 소프트웨어는 제때 완성돼야 한다. 중요한 문제들을 수정하는 데 수주 또는 수개월 간의 지연은 선택사항이 아니다.
둘째, 확실한 기술이다. QNX와 같은 OS는 그냥 개발된 것이 아니라 안정적이어야 하는 장치들에 채용될 수 있도록 밑바닥부터 철저히 설계됐다. 자동차 벤더들은 그들의 자동차 내 시스템에 문제가 발생했을 대 부정적인 고객 경험과 그 사실을 제공할 수는 없다.
셋째, 분명한 설명이다. 수백만 달러의 프로젝트에서 OS를 포함한 개개의 부품에 대해 기술 및 법적 측면 모두에서 확실히 누가 책임이 있는 지 명백히 할 필요가 있다. 공개 소프트웨어의 경우에는 책임소재를 밝히는 것이 매우 어렵다.
넷째, 최상의 지원이다. 많은 중소기업과 몇몇의 대기업은 리눅스에 대한 컨설팅 서비스를 제공하지만, 그들의 OS를 만든 단 하나의 벤더만이 프로젝트 성공에 필요한 지원을 적정시간에 고품질로 제공할 수 있다.
시험 삼아 상용 임베디드 OS를 사용해보라. 그것들은 충분히 존재 이유가 있다. 삶의 전부에는 아니지만, 대부분의 경우에는 ‘싼게 비지떡’이라는 격언이 적용된다.


치명적 실수 5. 임베디드 OS 대신 데스크톱 OS로 진행하기
2010년에 스턱스넷(Stuxnet)이라는 컴퓨터 웜바이러스가 윈도우 OS의 취약성 때문에 공장을 강타했다. 그리고 2014년 이래 윈도우 XP의 보안 허점은 더 이상 수정될 수 없게 됐다. 이 두 가지로 인해 디바이스 제조사들은 엄청난 비용을 지불했는데, 이런 일은 문제가 되어서는 안 되는 것이었다. 이들 두 가지 주요 재앙으로 데스트톱 콘텍스트에서 나온 OS는 산업용 제어, 의료기기 또는 빌딩 자동화 애플리케이션에는 잘못된 선택이었음이 명백해졌다. 보안을 염두에 두고 수십 년 간 채용될 수 있는 목적지향의 임베디드 OS에 대한 강한 수요가 생겨났다.
그러면 왜 처음에 데스크톱 OS가 임베디드 애플리케이션에 채용됐는가? 과거 시스템의 주요 요구사항 중 하나는 향상된 데이터의 그래픽 표현(시각화)이었는데, 이때 윈도우가 채택됐다. 그 이유는 윈도우가 그래픽에 강력한 초점을 준 OS로 보였던 데 반해 임베디드 OS는 제어과제를 담당했으며, 블랙박스 안에 있었다. 그렇지만 지난 몇 년에 걸쳐 두 가지 주요 요인에 변화가 일어나고 있다.
임베디드 OS는 더 이상 지금까지와 같은 그래픽 특징에 한정되지 않는다. QNX와 같은 현대의 제품들은 스마트폰 등급의 유저 경험도 제공하며, 시각화를 위해 윈도우 기반 시스템에 대한 필요를 없앴다.
데스크톱(또는 모바일) OS에서 보안문제는 점점 부각되고 있다. 오늘날과 같은 총체적인 네트워크로 연결된 세계에서 장치들을 매월 다중 보안 패치를 필요로 하는 OS 상에 둔다는 것은 벤더와 엔드유저 모두에게 높은 리스크와 큰 비용을 부과하게 된다.
큰 차이는 데스크톱 OS가 유저 지향으로 개발된 데 비해 임베디드 OS는 개발자를 위해 설계됐으며, 장치의 핵심이라는 점이다. 전형적으로 해당 벤더들은 그것으로 무엇을 할 것인지 염려하며, 컨설팅 및 엔지니어링 서비스를 제공함으로써 함께 개발에 참여할 수 있다. 이렇게 함으로써 담당자가 전문가의 지식 풀에서 개발에 필요한 것들을 끄집어 낼 수 있게 해준다. 그리고 기존 소프트웨어가 프로젝트에 필요하지만 쉽게 이식할 수 없는 경우에는 하이퍼 바이저가 레거시 OS도 새로운 OS와 함께 나란히 실행되도록 해주며, 핵심과제는 윈도우를 리부팅하는 경우에도 실행상태를 유지해준다.
치명적 실수 6. 가장 빠른 OS를 찾으려고 노력하기
다른 것보다 먼저 의도적으로 OS 선택을 결정하려고 시도하는 사람들의 경우, 관건은 결정을 위한 올바른 기준을 찾는 것이다. 따라서 쉽게 측정 가능한 것에 쉽게 집착하는 경향이 있다. 오늘날 메모리 사용은 더 이상 문제가 되지 않지만 속도나 성능은 중요할 수 있다. 많은 사람들이 페라리를 운전하고 싶어 한다. 하지만 우리 일상에서 쇼핑백을 옮기는 일에 페라리는 적합하지 않으며, 유지 비용도 많이 든다. 그렇다면 이 문제가 임베디드 OS에 어떻게 영향을 미칠까?
통상 임베디드 OS의 벤치마킹 과제를 담당하는 소프트웨어 기술자들은 다음 사항을 살핀다.
· 데이터가 얼마나 빨리 네트워크로 보내지는가
· 주어진 시간에 얼마나 많은 복잡한 수학적 연산이 행해지는가
· 이벤트에 반응하는 시간이 얼마나 걸리나(latency)
· 프로세스 간 통신의 속도
위와 같은 테스트를 행하는 통상적인 방법은 다양한 OS 기능성을 항상 여러 다양한 상황에서 일정 시간동안 사용하는 작은 프로그램을 작성하는 것이다. 이런 측정의 가장 큰 문제는 OS 기능성이 실제 애플리케이션에서 어떻게 사용되는지에 대해 별로 공통성을 가지지 않는다는 것이다. 예를 들어, OS는 시스템 안에서 그들이 ‘항상 통신하고 있는가 아니면 대부분의 시간을 통신하고 있는가’, ‘설계된 일을 하고 있는가 그리고 가끔만 통신하는가’와 같은 서로 통신하는 소프트웨어 요소를 가질 가능성을 제공한다.
데이터를 항상 송수신하는 표준 네트워킹 벤치마크를 살펴보자. 여기에는 데이터 처리량을 넘어서는 중요한 발견을 할 수 있다.
소프트웨어 요소들을 서로 깔끔하게 분리해 유지하기 위해, 그리고 안전을 위해 설계된 OS는 벤치마킹 프로그램을 밀봉된 프로세스로 취급할 것이다. 이런 방식으로 네트워킹 동작은 조금 더 시간을 소비할 수 있지만 벤치마킹 프로그램이 송신하고자 하는 데이터는 OS 코어(커널)에 의해 네트워크 프로세스로 이동(복사)될 필요가 있다. 그러나 최대 성능을 위해 설계된 OS에서 네트워크 스택(stack)은 OS 커널에 연결되어 있고 또한 언제든 벤치마킹 프로그램의 메모리 공간에 들어와 그곳에서 직접 보내야할 데이터를 낚아채는 것이 가능하다. 이것은 빠르기는 하지만 큰 단점은 잘못된 네트워킹 패킷 또는 프로그래밍 에러들에 기인하는 문제들이 전체 OS 커널을 위태롭게 한다는 것이다.
질문 하나를 던져보겠다. 속도의 차이는 실제 애플리케이션에서 알 수 있는가?
소프트웨어는 OS 기능 안에서 실제로 얼마나 많은 시간을 소비할까? 깊이 있는 분석을 하지 않는 한 답변이 쉽지 않다. 그러나 경험에 의하면 많은 경우에 보내는 시간이 적다. 이상적으로 실제 어느 정도의 속도가 필요한지 알지만, 그리고 설사 모른다 해도 한 가지는 확실하다. 최대속도는 기대하는 알맞은 숫자가 아니라는 것이다. OS 속도는 덜 안정적이고, 더 복잡하고 따라서 제품의 안정성과 보안성의 저하와 같은 사항들의 희생으로 얻어진다.
경험에 의하면 클린 애플리케이션 설계는 성능이 좋은 시스템의 이면에 존재하는 동인이다. 그 어떤 빠른 속도의 OS도 잘못된 애플리케이션 설계 결정을 상쇄할 수 없지만 좋은 OS는 소프트웨어를 더 신뢰할 수 있고, 안전하며 관리가 쉽게 해준다.
그 의미는 하드웨어 속도가 OS 속도보다 더욱 중요하다는 것이다. 하드웨어는 OS를 실행하지만 더욱 중요한 것은 애플리케이션을 실행한다는 것이며, 이것은 하드웨어 리소스의 알맹이를 소비할 것이다. 약간의 여유가 있는 하드웨어 플랫폼을 선택하면 비용이 약간 올라가지만 소중한 개발시간을 단축할 수 있으며 성능 문제를 회피하는데 도움이 되고, 미래 기능성을 위한 여지도 남겨둘 수 있다.
치명적 실수 7. ‘필요하지 않아’ 신드롬, 미리 계획 세우지 않기
임베디드 OS를 고려할 때 사람들은 종종 QNX를 만나게 되고 이 회사가 다음을 제공한다는 것을 알게 된다.
· 결정론적인 거동을 위한 매우 정교한 실시간 능력
· 산업용, 자동차용, 의료용 등 용도에 맞는 안전 인증을 받은 버전들
· 시스템의 신뢰성을 극대화하기 위해 고객이 추가하거나 제3자로부터 구입한 것까지 포함해서 각 소프트웨어 요소들을 다른 소프트웨어 요소 및 커널로부터의 분리
· 깊이 있는 시스템 프로파일링과 분석을 할 수 있는 포괄적인 개발툴 슈트
경험이 적은 의사결정자들에게 위 목록은 많이 있으면 있을수록 좋은 것들처럼 보인다. 달리 말하면 꼭 필요하지는 않다고 인식되는 특징들이다. 임베디드 OS의 문맥에서 흔히 언급되는 핵심적인 특징은 ‘실시간’이다. 일반적인 믿음과는 달리 이 단어는 ‘정말 빠름’을 의미하지 않으며, 대신에 결정론적인 행동을 제공할 수 있다는 것을 뜻한다.
시스템은 설계된 바를, 그것도 언제나 적정한 시간 범위 내에 실행한다. 예를 들어, 키를 누르면 일정시간 내에 어떤 반응을 하게 된다. 때로는 웹브라우저의 주소 필드에 무엇을 타이핑하면 그것이 나타나기까지는 시간이 걸린다. 이 시간은 짧을 수도 있지만 비상시 오작동하고 있는 제트엔진에 공급되는 연료를 차단하는 것이라면 치명적일 수 있다.
OS 레벨에서 절대적인 차이는 어떤 OS들은 실시간이 가능하게 제작되지만 다른 것들은 어느 정도의 실시간 능력을 제공하기 위해 확장된다. 이 두 가지를 모두 ‘실시간 가능’이라 부른지만 그 반응시간의 차이는 엄청나다. 만약 기기에서 이것을 용인한다 해도 ‘실시간 OS가 필요하지 않다’고 말해서는 안 된다. 진정한 실시간 OS는 임무수행이 필수적인 장치에서 채용되는데, 여기서는 반응시간이 짧아야 한다. 이것이 충족되지 않을 때는 돌발적인 고장으로 인해 인명손상, 환경위기 또는 손상된 제품 생산으로 이어진다.
이외에도 이런 시스템에서는 적어도 10년 이상 지속될 수 있는 안정성, 신뢰성, 적용가능성, 인증성, 유지관리성 등과 같은 또 다른 매력적인 특징들이 필요하다. 위의 특성 중 여러 가지는 아니더라도 적어도 한 가지는 반드시 필요하다.
이것이 바로 실시간용으로 설계된 임베디드 OS가 기대할만한 좋은 OS인 이유다. 실시간용으로 설계됐다는 것은 가장 절박한 애플리케이션 시나리오를 위해 설계됐음을 의미한다.
임베디드 OS는 많은 사람들이 생각하듯 태스크 스케줄러, 다양한 하드웨어 부품을 구동하는 드라이버, 동기화 메커니즘 등을 가지고 있다. 커다란 차이는 성공적이라는 단어의 정의다.
· 주어진 시간범위와 예산으로 프로젝트 완수
· 고객 만족, 저렴한 보증비용
· 차기 제품을 위한 확장성 있는 솔루션
선택한 임베디드 OS에 따라 목표에 도달하는데 필요한 비용과 시간은 크게 다를 수 있다. 잘 설계된 임베디드 OS의 장점은 자동차에 추가되는 부속물(주차거리 조절 등)과는 다르며, 안전을 위한 핵심 조치(안전벨트, 에어백, 크러시존)들과 같은 것이다. 이들 중 어느 하나도 결코 필요하지 않기를 바라지만 이들이 없이 운전할 수 있겠는가.
임베디드 OS를 선택할 때 자신의 분석과 현재의 프로젝트 요구, 그리고 장래 요구사항을 토대로 신중하게 골라야 하는지가 중요하다. 또한 속도가 전부가 아니며 신뢰성과 보안성을 완벽하게 지원하는 또 다른 OS 특징도 존재한다. 이 순간에 이 모든 것들이 필요하지 않다하더라도 이들은 미래 과제를 위한 훌륭한 보험 역할을 할 것이다.