글 : 김동일 부장, 기술지원부 / 윈드리버(www.windriver.com)
VSD(Virtualized Systems Development)란 무엇인가?
1999년 개봉된 영화 '매트릭스'에서 주인공 네오는 현실에서는 불가능한 일들이 가상 세계에서는 가능하다는 것을 알게 된다. 주인공이 날아오는 총알을 엄청난 속도로 몸을 앞뒤로 굽히면서 피하는 모습은 굉장히 인상적인 장면이었다. 이와 비슷하게 VSD(Virtualized Systems Development)는 전자 장비의 개발에 있어서 불가능해 보이는 많을 것들을 가능하게끔 해준다.
즉 VSD는 개발자들로 하여금 '가상플랫폼(Virtual Platform)'을 이용하여 물리적인 하드웨어 출시 이전에라도 충분히 시스템 디자인/코드실행/디버깅/시뮬레이션이 가능하도록 하는 개발 방법이라고 말할 수 있다. 이로 인한 혜택은 제품의 정의 단계에서부터 개발과 출시에 이르는 라이프 사이클의 거의 모든 단계까지 확대된다.
VSD를 이용함으로써 하드웨어와 소프트웨어 개발팀은 프로젝트의 시작 단계에서부터 새로운 방식으로 협력할 수 있게 된다. 그 어느 때보다 더 빠르게 버그를 잡아낼 수 있고 시스템 통합 또한 훨씬 초기에 이루어 질 수 있다. 또한 고객지원과 고객 교육 프로그램도 보다 효과적이고 간편하게 제공할 수 있게 된다.
VSD가 필요한 이유
최근 수 년간 전자 시스템은 기하급수적으로 빠르게 복잡해져 왔다. 오늘날에는 상대적으로 단순한 디자인조차도 DSP, ASIC, FPGA와 기타 디바이스가 복합적으로 통합된 CPU 형태의 다중 프로세서를 포함하고 있다. 오늘날의 시스템은 하드웨어의 다양한 조합을 가능하도록 하기 위해 최근까지만 해도, 하나의 제품이나 솔루션 내에서는 함께 결합하여 사용하지 않았던 다양한 운영체제와 애플리케이션 스택을 결합하여 사용하고 있다. 그러나 불행스럽게도 시스템이 복잡해짐에 따라서 단일 프로세서와 기본적인 클라이언트/서버 모델로 동작하는 시스템에 맞춰져 제공되던 과거의 개발 툴들과 프로세스들은 변화에 보조를 맞추지 못하고 있다.
이와 같이 수백만 라인의 코드와 복잡한 시스템 아키텍처를 가진 최신의 시스템을 효율적 개발하기 위해서 개발자들은 새로운 개발방식을 찾아내야 하는 문제에 당면해 있다. 또한 새로운 개발방식을 통해 위험요소는 줄이고 개발시간은 단축하는 동시에 더 나은 품질의 제품 개발이 가능하기를 기대하고 있다.
PC나 워크스테이션이 아닌 임베디드 디바이스를 위한 소프트웨어 개발에 있어서 가장 중요한 문제중의 하나는 개발된 소프트웨어를 최종 타겟 하드웨어상에서 동작시켜 테스트 해야 한다는 것이다. 그러므로 테스트를 위해서는 개발자가 실제 타겟 하드웨어를 가지고 있던지 아니면 타겟 하드웨어와 유사한 레퍼런스 하드웨어라도 가지고 있어야 한다.
하지만 개발 현실상 최종 타겟 하드웨어가 개발자에게 충분히 공급되는 경우는 드물며 더구나 하드웨어 디자인 단계에서는 타겟 하드웨어와 유사한 레퍼런스 하드웨어를 가지고 소프트웨어 개발을 진행할 수 밖에 없다. 이러한 개발방식에는 여러 가지 제한점이 있을 수 있는데 먼저 개발하려는 시스템의 복잡성이 증가함에 따라 최종 타겟 하드웨어와 유사하게 동작하는 레퍼런스 하드웨어를 찾기가 어려우며 두 하드웨어 간의 미묘한 차이로 인해 발생하는 문제들에 대해서는 레퍼런스 하드웨어에서 문제를 해결하였다고 해서 최종 타겟 하드웨어에서도 해당 문제가 해결되었다고 볼 수 없다는 것이다.
경우에 따라서는 개발자 리소스가 레퍼런스 하드웨어의 소프트웨어 버그를 잡기 위해 낭비되는 경우도 있을 수 있다. 이러한 비효율성을 개선하기 위해서 제시된 솔류션이 VSD 또는 가상 플랫폼을 이용한 개발 방식이다. 개발자의 타겟 하드웨어를 소프트웨어 모델링을 통해 PC상에 가상으로 구축하고 이 가상 플랫폼 상에 타겟 하드웨어에서 실행될 바이너리와 동일한 바이너리를 실행시켜 테스트 및 디버깅을 하는 방식이다. VSD는 시스템이 복잡해 질수록 더욱 그 진가를 발휘할 수 있으며 물리적 하드웨어를 이용한 개발방식에 비해 개발비용과 개발시간 모두에서 유리하다.
가상 플랫폼의 강력함
'가상 플랫폼'은 물리적인 하드웨어에 대응하는 기능 모델이라는 말로 설명할 수 있다. 소프트웨어 개발을 위한 타겟으로 사용되는 가상 플랫폼은 단일 프로세서와 메모리만을 가진 베이직 보드 형태일 수도 있고 네트워크가 연결된 보드와 섀시, 랙으로 구성된 완전한 시스템 형태일 수도 있다.
그림 1. Wind River Simics 블록 다이어그램
그림 1은 윈드리버에서 공급하고 있는 가상 플랫폼인 Simics의 블록 다이어그램이다. 마이크로프로세서, 메모리, 각종 디바이스들이 Simics Core상에서 모델링을 통해 가상화되며 모듈화된 모델링 방식을 사용하기 때문에 앞서 기술한 바와 같이 보드나, 섀시, 랙등 개발자가 원하는 다양한 방식으로 확장 시스템을 구성하는 것이 용이하다.
Simics에 적용된 모델링의 정확도와 신뢰도는 타겟 소프트웨어가 물리적 하드웨어와 가상 플랫폼간의 차이를 구분할 수 없는 수준이다. 가상 플랫폼은 물리적인 하드웨어와 동일한 바이너리를 실행할 뿐 아니라 완전히 동일하게 동작한다. 개발자들은 이 높은 신뢰도를 제공하는 가상 플랫폼을 다양한 기능을 가진 시뮬레이션 환경과 결합시켜, 하드웨어 디자인과 생산을 진행하는 동시에 해당 하드웨어를 위한 펌웨어와 운영체제, 디바이스 드라이버, 애플리케이션과 커뮤니케이션 스택을 정의, 개발, 배포, 통합하는 작업에 사용할 수 있다. 그러므로 가상 플랫폼을 사용하게 되면 가상 플랫폼의 특성, 혹은 가상 플랫폼에 적용할 수 있는 여러 개발 기법으로 인해 제품 라이프 사이클에 많은 이점을 제공한다.
가상 시스템의 유연성
가상 플랫폼은 기본 플랫폼 형태의 모델부터 최종적인 전체 시스템 모델까지 개발 단계에 맞춰 같이 진화하므로 소프트웨어 개발자에게 그 상황에 맞는 적합한 환경을 제공해 줄 수 있다. 가상 플랫폼을 사용할 때 명심해야 할 점은 모든 종류의 소프트웨어 개발이 시스템 전체에 대한 완벽한 모델링을 필요로 하는 것은 아니라는 것이다.
때때로 IO나 ASIC 또는 특정 메모리와 같은 하드웨어 디바이스의 경우 해당 디바이스에 대한 기능이 정의되어 있지 않거나 심지어 존재하지 않더라도 특정 소프트웨어 개발작업에 있어서는 문제가 되지 않을 수 있다. 이 경우에 그 디바이스는 간략히 생략되어도 되고 유사한 기능을 제공하는 다른 모델로 대체될 수도 있다.
예를 들어 몇몇 디바이스를 초기화하는 부팅코드를 생각해 보면 이 코드는 오로지 CPU, 메모리, 그리고 코드에 의해 실제 액세스되는 디바이스 레지스터만으로 구성된 모델로도 충분히 개발, 디버깅, 테스트가 가능하다. 디바이스 레지스터를 읽고/쓰는 초기화 단계 이후의 전체기능에 대한 모델링은 추후 운영체제 포팅이나 디바이스 드라이버 개발이 필요할 때까지 뒤로 유예될 수 있다.
그림 2. 개발 단계에 따라 유연하게 대응 가능한 가상 플랫폼
가상 플랫폼은 하나의 모델이 완전한 하드웨어의 모든 형태를 가지고 있지 않을 때에도 기능을 제공할 수 있다는 점에서 차별화된다. 이러한 특성은 가상 플랫폼과 하드웨어 디자인이 계속 변경되며 완성화 되어가는 중에서도 소프트웨어 개발이 진행될 수 있도록 해준다.
실행 가능한 사양
VSD를 통해 하드웨어와 소프트웨어 개발팀은 여러 개의 가상 플랫폼을 만들거나 서로 네트워킹하도록 구성함으로써 새로운 아키텍처에 대한 실험을 할 수 있다. 이와 같은 가상 시스템은 프로젝트의 아키텍처, 시스템 정의 단계에서도 프로토타이핑이나 디자인 컨셉 테스트를 위한 목적으로 실제 소프트웨어 가동 테스트를 할 수 있다. 이러한 방식으로 사용될 때에 가상 플랫폼은 시스템 엔지니어, 하드웨어 및 소프트웨어 개발 팀, 마케팅 팀, 그리고 영업담당자에 이르기까지 누구나 사용할 수 있는 살아있는 실행 가능한 사양으로서의 역할을 하게 된다.
전통적인 요구 사항 문서나 사양처럼 가상 플랫폼 모델은 저장되고 보관되어 향후 다른 제품 디자인을 위한 템플릿으로서 사용될 수 있다. 실행 가능한 사양의 사용은 하드웨어와 소프트웨어 개발팀이 프로젝트의 시작 단계부터 협업할 수 있도록 만들어준다. 이로 인해 근본적인 시스템 디자인 문제들이 실제로 물리적인 디자인에 반영되기 훨씬 이전 단계부터 발견되고 수정될 수 있게 된다. 전통적인(예를 들어 VSD를 사용하지 않는) 개발 방식으로는 이러한 문제들이 시스템 통합 과정에서나 발견되기 때문에 수정하기도 어렵고 이에 소요되는 비용도 올라간다.
단순화된 빌드 환경
가상 플랫폼에서는 물리적 시스템과 동일한 소프트웨어 바이너리를 실행할 수 있기 때문에 별도의 크로스 컴파일 과정이나 시뮬레이션, 혹은 개발 빌드를 필요로 하지 않는다. VSD의 이 같은 측면은 하나의 프로젝트를 위한 코드 빌드 수를 현격히 감소시키고 유지관리 비용을 절감하며 일관되지 않은 빌드로 인해 발생하는 오류의 위험을 경감시켜 준다.
재사용이 가능한 기술 자원
현재는 아주 작은 소비자 단말조차도 프로세서 코어들과 디바이스들의 다양한 조합으로 이루어져 있다. 이러한 하드웨어 복잡성 때문에 이를 시뮬레이션 해야 하는 기저 인프라스트럭처는 복잡한 실제 하드웨어 조합을 빌딩 블록 형태로 구성할 수 있어야 한다. VSD를 사용하면 모든 개별적인 시뮬레이션 구성요소와 플랫폼 모델(프로세서 코어, 디바이스, 커스텀 ASIC, 특정 애플리케이션용 FPGA, 보드 혹은 네트워크 모델 등)은 재사용이 가능한 기업의 자산이 된다. 예를 들어서 일단 한번 만들어진 IP 블록 혹은 ASIC 모델은 차후의 다른 시스템 디자인에 적용됨으로써 재사용할 수 있는 것이다.
하드웨어 디자인이 물리적인 구성요소들과 연결되듯이 모델 구성요소들은 가상 플랫폼 내에서 결합된다. 모델 라이브러리가 지속적으로 확대되고 통합됨에 따라서 개발자와 프로젝트를 위한 VSD의 장점 역시 확장된다.
Wind River Simics 특징
윈드리버 Simics가 제공하는 가상 플랫폼은 기존 개발방식에서 불가능하던 것들을 가능하도록 해준다. 가상 플랫폼을 이용하여 개발자들은 하드웨어 내의 모든 비트와 레지스터를 모니터링 하고 전체 시스템을 정지시키거나 어떤 하드웨어 에러라도 시스템에 인가할 수 있으며, 체크포인트 설정이 가능하고 매번 정확히 모든 작업을 반복하고, 심지어 시스템을 역으로 실행시킬 수도 있다.
그림 3. Wind River Simics 주요기능
공유, 재사용 그리고 적용의 간편함
시뮬레이션 인프라스트럭처는 어느 호스트 컴퓨터 상에서도 가상 플랫폼이 정확히 동일한 타겟 소프트웨어의 동작을 유지하면서 실행되어야 하기 때문에, 호스트에 대한 독립성을 제공해야 한다. 호스트에 대한 독립성은 가상 플랫폼이 서울에서나 산 호세에서나 지역에 상관없이 동일하게 동작하고, 개발자가 듀얼코어, 쿼드코어, 혹은 그 이상의 멀티코어 데스크탑 시스템을 사용하는지에 관계없이 같은 방식으로 작동할 것을 보장한다.
전체 시스템 정지
물리적인 하드웨어와는 달리 가상 플랫폼 그리고 전체 가상 시스템은 완벽하게 그리고 동시에 정지시키는 것이 가능하다. 가상 플랫폼에는 시스템이 점차적으로 정지되는 단계적(wind-down) 지연이라는 것은 존재하지 않는다. 모든 프로세서 코어는(물리적 시스템에서와 같이 디버거 커맨드에 의한 개별적인 종료가 아닌) 단 하나의 명령(커맨드)에 의해 정지한다.
가상 플랫폼의 이 같은 정지 방식은 프로세서 코어에만 적용되는 것이 아니며 주변기기는 물론 심지어 네트워크와 버스를 통해 전송되고 있던 데이터에까지 모두 동일하게 적용된다. 이러한 정지된 상태 속에서 개발자는 모든 하드웨어와 소프트웨어 변수들에 대한 완전한 접근성과 가시성을 얻을 수 있으며 소프트웨어와 하드웨어에 새로운 브레이크포인트를 설정한 뒤, 마치 플랫폼이 한번도 멈춘 적이 없었던 듯이 정상적인 가동을 재개할 수 있다. 또한 전체 시스템의 정지와 완전한 하드웨어 가시성의 결합을 통해서 전체 시스템을 스텝 단위로 실행시키는 것도 가능하다.
체크포인트/스냅샷
소프트웨어 개발자는 종종 과거의 세션 중 작업을 중단했던 부분부터 작업을 다시 진행할 수 있기를 바란다. 그러나 물리적 하드웨어에서 플랫폼의 실행 과정 중 원하는 지점으로 돌아가기 위해서는 시스템의 모든 사건을 동일한 순서대로 처음부터 재가동해야만 한다. 개발자들은 추후 원하는 정확한 위치에서 작업을 재개할 수 있도록 그 시점에서의 전체 시스템 상태를 캡처하고 저장하고 복원할 수 있는 기능을 원한다.
Simics 가상 플랫폼에서 제공하는 '체크포인트' 기능은 엔지니어가 긴 주말 후 혹은 시스템이 다운되는 사고 후나, 심지어는 수년이 지난 후에 기존 소프트웨어의 개선 작업을 할 때 조차도 별다른 노력 없이 작업을 계속할 수 있게끔 도와준다.
재현성
엔지니어가 버그를 탐지했으나 이를 재현할 수 없는 경우는 얼마나 될까? 그 가장 주된 원인은 물리적인 하드웨어 고유의 무질서한 동작과 변화무쌍한 타이밍에 있다. 경우에 따라 물리적인 하드웨어 상에서는 개발자가 시스템의 버그를 재현하기 위해 각 변수들을 모니터링하고 격리하는 작업에 수 주 혹은 수 개월이 소요되기도 한다.
한편 가상 플랫폼에서는 완벽한 재현이 가능하다. 버그가 일단 발견되면 몇 번이라도 쉽게 반복 시킬 수 있는데 간단히 프리버그(pre-bug) 시스템 체크포인트를 로딩한 뒤에 시스템을 작동시키는 것으로 이를 가능하게 한다. 이 재현성을 통해서 매 작동 시에 동일한 체크포인트부터 시작하게 되고, 그 때마다 정확하게 동일한 동작이 보장되어 버그는 항상 동일한 지점에서 검출되게 된다.
역실행
' 내가 오늘 아는 것을 그 때 알았더라면! ' 인간은 실수로부터 배우는 것처럼, 어떤 문제든 발생하고 난 이후가 확인하기도 수정하기도 훨씬 쉽다. 역실행은 개발자가 문제가 발생한 시점부터 시작해서 시스템을 거꾸로 가동할 수 있게 해줌으로써 시스템 재현성을 보완한다. 역실행을 통한 디버깅은 매우 직관적이다. 왜냐하면 시스템이 문제가 일어난 시점을 향해 거꾸로 실행되는 동안에도 개발자는 원하는 지점에 브레이크포인트를 설정하여 살펴보는 것이 가능하기 때문이다. 이와 같은 역실행 기능은 개발자로 하여금 몇 달씩이나 걸릴 수 있는 시스템 버그를 짧은 시간 내에 손쉽게 찾을 수 있도록 도와준다.
시스템 가시성, 제어 및 폴트 인젝션
물리적인 하드웨어를 사용할 경우에는 SoC 디자이너가 개발자들의 편의를 위해 공개한 특정 레지스터 외에는 접근이 거의 불가능하다. 여기에는 CPU 레지스터의 대부분과 MMU의 특정 레지스터 세트 그리고 이를 지원하는 IO 디바이스가 포함된다. 불행히도 일부 OS 커널과 드라이버 소프트웨어는 물리적인 하드웨어 상에서는 단순히 보이지 않는 (혹은 디버깅 될 수 있는) 디바이스나 레지스터에 액세스 해야만 한다.
빠른 개발과 더 높은 코드 품질을 제공하기 위해 가상 플랫폼에서는 시스템 위에 존재하는 모든 비트, 바이트와 레지스터를 검사하고 또 수정할 수 있다.
그림 4. Debugging with Wind River Simics
그림 4은 하드웨어 장비의 레지스터 및 다른 유용한 정보들에 어떻게 접근할 수 있는지를 보여준다. 이러한 가시성은 개발자들이 소프트웨어의 모든 라인들을 디버깅하고 모든 하드웨어 구성요소들과의 전체적인 상호작용을 검토할 수 있게끔 해주며 TLB(Translation Lookaside Buffer)와 같은 내부의 디바이스들을 제어하는 소프트웨어 개발을 용이하게 한다. 이와 같이 모든 하드웨어 레지스터에 접근할 수 있는 기능을 통해서 테스트 팀은 물리적인 하드웨어로는 확인할 수 없는 코너 케이스 시나리오를 위한 폴트 인젝션(fault injection)이 가능하게 된다.
스크립트와 자동화
앞에서 살펴본 것처럼 Simics는 전체 가상 플랫폼에 대한 가시성과 제어성을 부여한다. 이러한 제어를 통해 복잡한 시스템 작업이 정교하게 구성, 제어, 복제할 수 있도록 자동화(혹은 스크립트화)될 수 있다. 모든 스크립트화된 동작은 ' 정확히 cycle 41691156 시점에 이더넷 컨트롤러에 의한 인터럽터가 발생할 예정'과 같은 식으로 시간의 개념에서 정의되며 다른 예로 ' 착륙 기어 락 표시등이 켜지는 순간 레지스터 r6와 r5의 컨텐츠 오류'와 같은 식으로 가상 시스템 내의 다른 구성요소와 관련하여 정의될 수도 있다.
스크립팅은 또한 프로그램된 명령에 따라서 적합한 커맨드와 텍스트를 실행하기 전에 시리얼 콘솔의 출력 결과를 읽어내는 것과 같은 시스템과의 상호작용을 수행하기 위해 사용될 수 있다. 시스템을 매우 정교하고 세밀한 부분까지 자동화하는 이 같은 기능은 버그의 탐지와 복제, 시스템 코너 케이스 테스팅, 통합과 테스트, 진보된 트레이닝 시나리오 및 세일즈 데모를 가능하게 만들어준다.
유연성
가상 플랫폼에서 지연, 속도 혹은 메모리 크기를 변경하는 것이 간단하다. 또한 플랫폼에 또 다른 프로세서를 추가하거나 새로운 플랫폼을 시스템에 추가하고 혹은 새로운 네트워크 인터페이스를 추가하는 등의 작업이 간편하다. 이제 개발자들은 구성 관련 버그를 찾아내거나 하드웨어의 변경 시(물리적 하드웨어가 변경되기 훨씬 전에) 성능 확장성을 확인하는 작업에 물리적인 하드웨어를 사용할 때와 비교하여 더 다양하게 설정을 바꾸어가면서 실험할 수 있다.
확장성
전체 시스템 모델은 수백 혹은 수천 개의 개별적으로 모델링된 구성요소를 포함하는 커다란 크기가 될 수도 있다. 시뮬레이션 인프라스트럭처가 확장을 지원하지 않는다고 하면 이러한 커다란 모델의 크기는 소프트웨어 개발자가 도저히 작업을 수행할 수 없을 정도로 성능을 떨어뜨리는 요인이 될 수 있다. Simics의 시뮬레이션 인프라스트럭처는 현재의 멀티코어 기술 혹은 네트워크로 연결된 서버의 성능을 충분히 활용하므로 확장성을 보장한다.
가상 플랫폼 적용 사례
가상화된 시스템 개발은 새로운 방법론, 제품의 정의와 개발, 출시를 위한 워크플로우와 기술을 도입함으로써 전통적인 하드웨어 중심의 워크플로우를 보완한다. 가상 플랫폼 채택은 진화하는 과정에 있다. 가상 플랫폼이 많이 사용되면서 더 많은 모델들이 만들어지고, 개발자들은 이를 통해 무엇을 할 수 있을 것인지에 대해 더욱 익숙해지며, 가상 플랫폼 채택의 결과적 가치와 이점 역시 점점 커지게 된다.
제품 정의 단계
가상 플랫폼은 마케팅, 하드웨어 및 소프트웨어 팀이 문서 기록을 남기지 않으면서도 하나의 실제적이고 동적이며 증명 가능한 방법을 통해 시스템 아키텍처를 정의할 수 있게 해준다. 일부 고객들은 심지어 가상 플랫폼을 이용한 데모를 프로젝트 입찰 과정의 일부로 사용하기도 한다.
- 예 : 아키텍쳐 검사 및 디자인
가상 플랫폼은 특히 최종 제품이 이미 모델링을 한번 거친 기존 제품에서 파생된 것일 경우에 시스템 디자인 프로세스에서 가치가 있다. 가상 플랫폼의 유연성과 확장성은 새로운 시스템 구성을 보다 빠르게 만들고 테스트할 수 있도록 한다. 다음은 전형적인 사례들이다.
- CPU상에서 작동하는 소프트웨어 기능을 하나의 독립적인 하드웨어 가속기(예를 들면 ASIC, FPGA, PLCD)로의 마이그레이션하는 경우
- 플랫폼의 숫자(예를 들어서 3개의 라우터와 6개의 스위치의 경우와 2개의 라우터와 7개의 스위치의 경우 비교)와 관련된 변화를 조사하는 경우
- 단일 쓰레드 플랫폼에서부터 다중 쓰레드 플랫폼으로의 포팅 작업 후의 애플리케이션의 정상 동작 검증하는 경우
제품 개발 단계
종종 제품의 개발 단계 중에는 하드웨어 가용성과 준비성, 스케줄, 디버깅, 시스템간의 커뮤니케이션 그리고 시스템 통합 등과 관련된 문제점으로 인해 진행에 어려움을 겪을 수도 있다. 이 같은 각각의 문제들은 가상 플랫폼을 사용하여 완화시킬 수 있는데 그 이유는 가상 플랫폼이 물리적인 하드웨어와의 바이너리 호환성을 가지기 때문에 초기 부팅 코드 개발로부터 시스템 통합 과정 및 최종 제품 판매 단계까지 모든 과정에 적용될 수 있기 때문이다.
가상 플랫폼은 소프트웨어 개발을 위한 하드웨어의 대체품 이상의 가치를 제공한다. 가상 플랫폼은 물리적인 하드웨어에서는 절대로 불가능한 '마술적인' 기능(예를 들면 전체 시스템 정지, 재현성, 전체에 대한 가시성과 제어, 역실행, 체크포인팅, 그리고 스크립팅/자동화)을 지원하며 이 기능들이 서로 결합하여 더욱 우수한 개발 플랫폼을 만들게 된다. 실제로 Simics를 불과 몇 주간 사용해 보고도 많은 소프트웨어 개발자들은 가상 플랫폼을 더욱 선호한다.
- 예 : 가상 플랫폼을 통한 점진적 시스템 통합
가상 플랫폼을 운영체제 포팅과 애플리케이션 스택 개발을 위해 사용할 때와 마찬가지로 가상 플랫폼은 시스템 통합과 테스팅에도 역시 많은 이익을 제공한다. 물리적인 하드웨어에서 서브시스템 간에 커뮤니케이션과 인터액션이 가능하기 위해서는 각각의 서브시스템이 완성된 상태여야만 한다. 그러나 가상 플랫폼을 사용하는 경우엔 오직 각 서브시스템의 화이트 박스 기능이 시스템의 나머지 부분의 동작에 영향을 미치지 않을 정도로만 최소한으로 구현되면 된다. 종종 이러한 수준의 화이트박스 기능을 제공하기 위해서 필요한 노력은 부족한 서브시스템의 소프트웨어를 개발하는 데에 필요한 노력보다 훨씬 적다.
이러한 점진적 진행방식으로 초기에는 시스템 통합이 오로지 가상 플랫폼 상에서만 시작될 수 있게 하며 가상 및 물리적 하드웨어의 조합으로 점진적으로 확대시키다가, 최종적으로는 완벽하게 물리적인 하드웨어만으로 구성된 시스템에 이를 수 있게 만들 수 있다.
- 예 : 역실행을 통한 시스템 디버깅
소프트웨어 디버깅에는 세 개의 단계가 있다. 버그의 재현, 버그 격리와 버그 수정이 그것이다. 물리적인 플랫폼에서 이 같은 작업을 성공적으로 완료하기 위해서는 개발자에게 높은 수준의 기술과 경험을 요구한다. 반면 가상 플랫폼에서는 버그의 재현, 버그의 격리, 그리고 버그의 수정 작업을 훨씬 간편하고 빠르게 수행할 수 있다. 예를 들면 물리적인 하드웨어에서 버그의 재현과 격리 작업에 몇 달을 고생하던 개발자도, 가상 플랫폼을 사용하면 하루도 안 걸려 이를 해결할 수 있다.
버그의 재현
물리적 하드웨어 상에서 버그를 재현하기 위해서는 버그의 원인으로 추측되는 새로운 인풋 변수와 데이터 스트림 혹은 사용자 조작을 통해 시스템 혹은 애플리케이션을 수백 수 천 번을 재 시작 해야 한다. 가상 플랫폼에서는 전혀 다르다. 가상 플랫폼에서는 데이터 스트림과 IO 매개변수를 스크립트화 시키고 동작 중에 캡처할 수도 있으며 이를 재사용하는 것도 가능한데 이러한 모든 과정은 가상의 세계에서 이뤄진다.
결과적으로 시스템은 언제나 같은 지점에서 시작하고, 그러므로 모든 시스템 기능과 타이밍, 동작과 결과에 대한 동일성을 보증할 수 있다. 이는 버그가 발생할 경우, 단순히 기존의 체크포인트(스냅샷 파일)를 로드하고 재가동함으로써 간단하게 재현할 수 있다는 것을 의미한다. 반드시 버그가 재현되는 체크포인트 파일을 사용함으로써 개발자들은 쉽게 전세계의 팀원들과 하나의 버그에 대해서 협력할 수 있게 된다.
물리적 하드웨어의 무작위성을 필요로 하는 개발자들을 위해서 가상 플랫폼은 다양한 '시드(seed)' 값을 공급받을 수 있다. 이를 통해 가상 플랫폼에서도 다른 시스템 응답을 유발시키는 것이 가능하다(물리적 하드웨어와 유사한 환경을 제공하지만 주어진 시드 값에 대한 동일한 재현성은 완벽히 유지한다). 새로운 시드 값은 서로 다른 시스템 응답을 유발시키므로 코너 케이스 테스트를 위해 사용된다. 이 시드 값들은 수동, 자동 혹은 메트릭 기반의 인증 기술을 사용하여 제공될 수 있다.
버그 격리
일단 버그를 안정적으로 재현할 수 있게 되면, 개발자는 버그의 원인을 파악해야 한다. 전통적인 하드웨어 중심의 디버깅 방식은 초기 브레이크포인트가 설정된 곳에 대한 반복적인 접근이 필요하며 시스템은 브레이크포인트에서 정지할 때까지 가동된다. 시스템이 정지한 뒤에 표준 디버깅 툴이 CPU 레지스터와 스택을 확인하기 위해서 사용되는데 모든 것은 문제가 발생했는지 아닌지를 발견하는 것에 목적을 두고 실행된다.
만일 문제가 발생했다면 이전의 브레이크포인트가 설정되기 전 지점에 새로운 브레이크포인트를 설정하고 애플리케이션 혹은 시스템을 재가동한다. 이와 같은 기술을 사용하여 결국 개발자는 소스코드의 정확한 문제 지점을 발견하게 되는 것이다. 역실행이 가능한 가상 플랫폼을 사용하였을 때의 디버깅 절차는 완전히 달라진다. 개발자는 언제 문제가 발생했는지를 알 수 있으며, 문제가 발생한 정확한 지점을 빠르게 찾아내기 위해서 코드를 따라서 거슬러 올라가면서 모든 하드웨어와 소프트웨어의 브레이크 포인트를 관찰할 수 있다.
이와 같은 접근은 물리적 하드웨어가 요구하는 반복적인 '추측/정지/재가동' 디버깅 방식을 사용하는 대신, 문제가 발생한 시점에서 시작해서 버그가 발생하는 원인 지점까지 역추적하는 방식을 사용한다.
버그의 수정
버그의 재현이 가능하고 이에 대한 원인이 밝혀진 상태라면 버그를 수정하는데 필요한 노력은 버그를 재현시키고 그 원인을 찾아내는데 필요한 노력에 비하면 매우 적은 것이다. 가상 플랫폼이 개발자들로 하여금 올바른 코드를 작성하도록 도와주는 툴을 제공하지는 않는다. 그러나 가상 플랫폼의 체크포인트, 역실행 그리고 런투런(run-to-run) 반복 실행기능을 통해 개발자들은 버그를 재현하고 격리하는데 큰 도움을 받을 수 있다.
제품 판매 단계
모델을 만드는 데에 요구되는 노력 때문에 만일 가상 플랫폼 기반 접근 방식이 제품 라이프 사이클의 초반부터 사용된 경우가 아니라면, 제품의 판매 단계에서 도입하는 것은 실용적이지 않을 수 있다. 하지만 가상 플랫폼이 제품 정의 혹은 개발 단계에서부터 적용된 경우라면 가상 플랫폼을 고객이 제품에 요구하는 특정 구성에 맞도록 하는 것은 어려운 일이 아니다. 이를 통해 더욱 효과적인 고객 교육 프로그램 또는 고객지원이 가능하게 된다.
- 예 : 고객별 특화된 구성에 대한 대응
대부분의 복잡한 시스템은 고객의 특화된 요구에 따라 서로 다른 방식으로 구성될 수 있다. 어떤 고객은 15개의 라우터와 20개의 스위치 그리고 10개의 게이트웨이를 필요로 할 것이다. 다른 고객은 그저 5개의 라우터와 4개의 스위치 그리고 1개의 게이트웨이만을 필요로 할 수도 있다.
각각의 고객에게 시스템을 공급함에 있어서 동일한 구성요소를 사용한다고 하더라도 그 개수(숫자)와 서브시스템의 분포는 달라질 수 있다. 확장성과 커스터마이징을 제공하는 것은 고객 입장에서는 유리하지만, 각각의 고객별 특정 지원 시나리오를 위해 담당 장비 랩을 재구성해야만 하는 제품 공급업자에게는 고객지원 문제가 큰 어려움이 될 수 있다.
가상 플랫폼은 그 어떤 실재하는 물리적인 하드웨어가 없이도 빠르게 재구성되고 확장/축소될 수 있다. 일단 특정 구성이 생성되고 나면 동일한 구성을 복구하고 가동하는 것은 수 초 내에도 가능할 만큼 쉬운 일이다.
요약
가상 플랫폼을 이용한 개발은 전통적인 하드웨어 중심의 개발 방식을 보완해, 개발자들이 효율적으로 작업을 할 수 있게 하고, 소프트웨어의 품질 향상과 더불어 제품의 납기 시간을 단축시킬 수 있다는 측면에서 매우 큰 이점을 제공한다. 이를 위해서는 다양한 아키텍처에 대한 모델 세트가 제공되고 또한 손쉽게 커스텀 모델을 만들 수 있어야 하며 이 모델들에 대해서 완벽한 기능 시뮬레이션이 가능한 인프라스트럭처를 필요로 한다.
개발자들이 더욱 많은 모델을 사용하고, 가상 플랫폼에 기반한 개발 경험을 쌓아갈수록 가상 플랫폼 도입의 이점과 가치, 그리고 ROI도 따라서 향상될 것이다.
윈드리버의 가상 플랫폼 솔루션인 Simics에 대한 추가적인 정보는 http://www. windriver.com/products/simics/ 에서 확인할 수 있다.
회원가입 후 이용바랍니다.
개의 댓글
댓글 정렬
BEST댓글
BEST 댓글
답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
내 댓글 모음