윈도우 임베디드 CE 운영체제를 사용하는 프로젝트는 간단하게 보드를 만드는 프로젝트에서 수 백억의 개발비가 들어간 스마트 폰 프로젝트가 있다. 많은 회사들이 윈도우 임베디드 CE 운영체제를 탑재하여 제품을 개발하고 있다. 또한 갑자기 나타났다 사라지는 수 많은 업체들이 있다
10년 전 MP3 붐이 일었을 때 자그마치 100개 이상의 업체가 난립했던 것과 비슷한 상태다.
현재 많은 업체들이 저 너머로 역사 속으로 사라졌다.
지금도 PMP, 내비게이션, 전자사전 등 많은 부분의 업체들이 화려하게 등장했다가 소리 소문 없이 사라지는 것을 보고 있다. 현재 시장 상황이 안 좋아서 그럴 수 있다고 생각하지만 그보다 근본적인 문제점을 집어 보고자 한다. (물론 이러한 판단은 지극히 개인적인 사견이기 때문이라는 것을 먼저 밝혀두고 싶다)
우선 윈도우 임베디드 CE 운영체제를 사용해서 개발하는데 오해하기 쉬운 몇 가지 사항에 대해 집고 넘어가고자 한다. 최근 여러 외부업체의 담당자들과 만날기회가 생기면서 윈도우 임베디드 CE를 운영체제로 이용하는 시스템 개발에 관한 잘못된 생각들을 듣게 되었다. 그 내용들은 대략 다음과 같다.
“윈도우 임베디드 CE 운영체제를 사용한 시스템 개발은 쉽다!”
절대로 쉽지 않고 오히려 RTOS(실시간 운영체제)를 사용한 운영체제보다 개발이 어렵다고 본다.
“그럼 윈도우 CE 운영체제 개발이 어려운 이유는 무엇인가?”
윈도우 CE 운영체제는 임베디드 시스템을 위한 운영체제다. 따라서 임베디드 시스템에 관한 기술이 시스템을 개발하는 중요한 요소로 작용한다. PCB 설계 기술, 프로세서 주변 회로 설계 기술, 프로세서에 대한 깊은 이해, 많은 테스트 및 검증 작업. 이러한 것들이 바탕이 되어야 좋은 시스템이 나오고 윈도우 임베디드 CE 운영체제 개발이 이루어 진다.
하지만 이런 사실은 무시한 체 업체에서 제공한 개발 보드 회로도를 마음껏 Copy&Paste 하고, CE 운영체제를 올려서 개발 했다고 자랑한다. 과연 이런데 제대로 시스템이 동작할까? 또한 운영체제에 관한 기술은 하루 아침에 터득 되는 것이 아니다. 필자는 10년 이상 임베디드 시스템을 개발했어도 아직까지 어려운 부분이 많다.
하지만 실상은!
운영체제 엔지니어 한 두 명이 고분분투 하며 윈도우CE 운영체제를 포팅하여 제품을 출시한다.(물론 이렇지 않은 업체도 많다.) 윈도우 임베디드 CE 용역 업체는 수천만원의 적은 용역비와 적은 인원을 투입하여(용역 업체 입장으로는 매우 효율적인 업무다!) 윈도우 CE를 포팅해서 준다. 이 프로젝트에서 하던 소스를 저 프로젝트에서 사용하고, 대강 보이는 데로 동작하면 운영체제 포팅은 끝난다.
어차피 용역을 준 업체도 시스템에 대한 지식도, 어떻게 운영해야 할지도 잘 모른다. 다만 싼 가격에 운영체제를 포팅 했다고만 생각한다. 그러다 보니 실제 제품이 나오면 끊임없는 문제가 생긴다. 생긴 문제를 수정하면 또 다른 문제가 나오는 나비효과도 체험하게 된다. 이러다 보니 출시한 제품에 문제가 계속 생기게 되고, 결국 소비자의 관심을 잃는다.
따라서 결론은?
보다 현실적인 접근을 하기 바란다. 개발은 하루 아침에 되는 것이 아니고 포팅도 날짜만 가지고, 비용만 가지고 되는 것이 아니다. 따라서 정리해 본다면
장기적인 관점에서 윈도우 임베디드 CE 운영체제를 접근하라! – 물론 대부분의 업체가 장기적으로 접근하고 있으며, 개발에 대한 충분한 경험도 있다. 단지 신생 업체에서 무모하게 접근하는 경우에 해당한다.
용역을 싸게 주려면 차라리 용역을 주지 말고 제품 개발을 하지 말라! – 어차피 좋은 제품이 안 나올 거 만들어 봐야 소용 없다.
윈도우 임베디드 CE 운영체제를 가지고 개발하는 것을 어려운 일이라고 생각해라! – 너무 개발이 쉽다고 이야기를 하지만 그 실체는 위험하다.
단기간에 결과를 얻으려고 하지 말라 – 강조하는 것 중에 하나가, “원하면 1주일 안에 당신의 보드에서 동작하는 데모를 보여주겠다. 하지만 제품이 되는 것은 기대하지 말라! 이처럼 초기에는 누구나 쉽게 윈도우 임베디드 CE 운영체제가 잘 동작할 것 같은 환상을 심어준다. 환상이 클수록 제품화될 가능성은 적다.
윈도우 임베디드 CE 운영체제를 개발하는 과정은 험난하고 어려운 과정이다. 시간과의 싸움보다는 전략과 노하우, 기술의 싸움이다. 이런 점을 유념해서 개발을 시작한다면 좋은 성과를 얻을 수 있지 않나 생각해 본다.
이제 부터는 윈도우 임베디드 CE를 이용한 개발 프로젝트 시 유의해야 될 사항들에 대해서 살펴보겠다.
1. BSP를 믿지 마라!
BSP(Board Support Package)는 프로세서를 제조한 업체에서 통상 제공하고, 이 BSP를 바탕으로 개발을 시작하게 된다. 하지만 BSP의 성능이나 완성도의 차이는 회사마다 판이하다. 따라서 BSP를 처음부터 신뢰하고 전체 프로젝트 계획하지 말아야 한다.
BSP는 프로젝트의 시작을 용이하게 해주는 단계에 불과하다. 실제 제품화를 위해서는 추가적인 작업이 많이 필요하며, 심지어 BSP를 새로 만드는 것까지 고려해야 한다.
윈도우 임베디드 CE 프로젝트에서 BSP의 의미는 다음과 같은 내용으로 정리하고자 한다.
-윈도우 임베디드 CE 운영체제를 사용하여 개발을 시작하는 시작점
-개발보드가 제대로 동작하는지 검증하는 소프트웨어
-프로젝트의 시작
-발생된 문제가 하드웨어의 문제인지? 운영체제나 BSP의 문제인지 검증하는 용도로 사용.
결론은 BSP는 프로젝트를 시작하는 시작점이지 개발의 중요한 부분으로 생각하지 말아야 한다는 것이다. 물론 BSP 마져 없다면 개발은 시작도 못한다.
2. 보이는 것이 다는 아니다!
윈도우 임베디드 CE 운영체제가 초기 화면이 개발하는 개발보드의 LCD에 떠오르면 뭔가 되어 간다는 기분이 들것이다. 하지만 시작은 아직도 멀었다는 것을 명심하기 바란다.
윈도우 임베디드 CE 운영체제에 사용되는 디바이스 드라이버는 BSP에 있는 드라이버뿐만 아니라 BSP에 제공 되지 않은 드라이버까지 개발해야 한다. 또한 제공된 디바이스 드라이버라고 하더라도 검증이라는 단계가 필요하다. 개발자뿐만 아니라 윈도우 임베디드 CE 운영체제에 대한 프로젝트를 기획하는 담당자 역시 윈도우 임베디드 CE 운영체제에 대한 개발 프로세스를 제대로 이해 하는 것이 필요하다.
개발의 어려움뿐만 아니라 앞으로 예상되는 문제점을 서로 공유함으로써 개발 시에 발생될 부 적확성을 배제할 수 있다. 모든 부정확성은 개발에 대한 잘못된 이해에서 비롯됨을 인지해야 할 것이다.
3. 개발보드에 아까워하지 말아라!
윈도우 임베디드 CE 프로젝트는 운영체제에 대한 포팅으로부터 시작된다. 따라서 잘 갖추어진 플랫폼이 있다면 시행착오를 줄일 수 있다. 새로운 프로세서를 사용할 때, 새로운 프로젝트를 사용할 때 해당 프로세서를 장착한 개발 보드가 있다면 반드시 구매를 하는 것이 좋다.
윈도우 임베디드 CE 운영체제를 개발하면서 개발보드를 사용할 때 장점을 정리해 본다면 다음과 같다.
-하드웨어가 만들어지기 전에 운영체제를 포팅해 볼 수 있다. 하드웨어의 개발은 시간을 필요한다. 적개는 1개월에서 수 개월이 걸릴 수 있다. 따라서 윈도우 임베디드 CE 운영체제에 대한 포팅을 해보고 익숙해지는 시간을 개발보드를 통해 가질 수 있다. 물론 계속 개발을 해왔다면 문제가 안되지만 어차피 새로운 프로세서, 새로운 환경을 접해야 한다. 이때 개발보드를 통해 그 차이점을 좀 더 쉽게 넘을 수 있다.
-윈도우 임베디드 CE 포팅시 필요한 기술적인 요소에 대해 사전 검증할 수 있다.
-설계한 하드웨어가 문제가 있을 때 비교해보며 검증해 볼 수 있다.
-운영체제뿐만 아니라 개발될 응용 프로그램의 동작 성능을 미리 검증해 볼 수 있다.
4. 개발 장비에 돈을 아끼지 말아라!
윈도우 임베디드 CE 운영체제를 개발하는데 있어서 가장 중요한 것은 디버깅 환경을 확실하게 갖추어 놓으라는 것이다. 이전 내용에서 설명했던 KITL과 같은 개발 환경도 물론 중요하지만 하드웨어적으로 검증하고 디버깅할 수 있는 장비를 준비해 둘 것을 권한다.
플랫폼 빌더로 운영체제에 사용되는 커널 영역부터 응용 프로그램까지 다 디버깅을 할 수 있다. 하지만 전원 관리에 관한 부분은 플랫폼 빌더로 디버깅 할 수 없는 부분이 있다. 관련 사항은 ‘원도우CE에서 효율적인 전원관리에 관한 이야기(http://www.zdnet.co.kr/builder/dev/0,39035659,39174229,00.htm)’를 참고하기 바란다.
또한 개발을 빨리하기 위한 장비에는 개발을 위한 컴퓨터가 있다. 윈도우 임베디드 CE 운영체제는 운영체제를 만드는 운영체제 빌드 과정에 시간이 많이 걸리기 때문에 PC의 성능이 중요하다. 성능 좋은 PC를 준비하는 것으로 개발 속도를 진척시킬 수 있다.
5. 판도라의 상자
판도라의 상자를 열어 온갖 질병고 고통들을 꺼내듯이 윈도우 임베디드 CE 운영체제 프로젝트의 이면을 모른체 개발을 시작한다면 그때부터 고통의 시작일 것이다. 물론 조금 과장된 면은 있다. 윈도우 임베디드 CE 운영체제를 직접 설계나 개발을 안해본 상태에서 운영체제를 포팅하는 개발업무를 시작한다는 것 자체가 위험한 발상일 수 있다.
윈도우 임베디드 CE 운영체제가 지금과 같이 널이 쓰이게 된 기간이 짧기 때문에 하는 이야기다. 다른 프로젝트 역시 마찬가지 겠지만 IT 산업의 역사 만큼이나 많은 노하우 및 기술들이 전수되었고 유지되었다는 것이다. 따라서 긴 시간동안 축적된 문제점과 해결 방법이 프로젝트 진행을 무리없이 할 수 있게 해주는 것이다. 물론 새로운 기술들이 많이 생겨나고(특히나 지금은 웹과 인터넷에 관련들이 쏟아져 나오는 상황이라) 있다. 하지만 하드웨어를 다루어야하는 윈도우 임베디드 CE 프로젝트는 소프트웨어만으로 이루어진 프로젝트와는 근본적인 차이가 있다.
따라서 판도라의 상자를 열기 전에 그 안에 들어있을 위험요소들을 예상하고 접근한다면 좀더 현실적인 프로젝트를 진행할 수 있을 것이다. 마치 ‘희망’이라는 마지막 판도라 상자의 내용물처럼....
6. 어플리케이션 개발자에게 기대지 말라.
Win32이라는 윈도우 개발용 함수들은 PC뿐만 아니라 윈도우 임베디드 CE 운영체제 환경에서 사용할 수 있기 때문에 가장 큰 강점으로 부각되어 왔다. 하지만 실상은 100% 자유롭게 윈도우 임베디드 CE 운영체제 환경에 Win32 함수를 사용할 수 있는 것이 아니다. 따라서 윈도우 임베디드 CE 운영체제 환경에 맞추어 응용 프로그램을 포팅하는 작업이 필요하다.
물론 다른 운영체제 기반의 응용 프로그램 소스를 윈도우 임베디드 CE 운영체제로 포팅하는 것보다는 쉽다. 또한 .NET로 개발된 응용 프로그램은 거의 100%로 호환이 된다(하지만 실제 프로젝트에서 .NET이나 MFC를 이용하여 응용 프로그램을 개발하는 비중은 그리 높지 않다. 임베디드 시스템의 특성상 Win32를 이용하여 C 언어로 개발하는 것이 실행 속도 측면에서 이득이 있기 때문이다.).
이에 윈도우 임베디드 CE 운영체제상에서 개발하는 응용 프로그램은 Win32 API가 차이가 있는지 파악하는 것에서부터 시작해야 한다. 그리고 나서 임베디드 시스템에 맞추어 메모리, 파일 시스템과 같은 하드웨어적인 제한 사항을 어떻게 효율적으로 이용할 것인가에 대해서 알아야 한다. 따라서 정리한다면
-PC와 윈도우 임베디드 시스템에서 사용되는 함수의 차이점을 분석하라.
-임베디드 시스템의 한계와 제약 사항을 파악해라.
-응용 프로그램의 개발 환경을 제대로 제공해라
7. 하드웨어 검증부터 해라
윈도우 임베디드 시스템이 아니라 운영체제가 없는 임베디드 시스템을 개발할 때는 소프트웨어 개발자가 모든 것을 개발해야 했다. 하드웨어가 만들어지면 플래시 메모리와 SRAM과 같은 메모리의 초기화 코드를 작성하고 LCD가 켜지도록 일일이 코드를 작성해야 했다. 이러한 작성과 검증과정에서 하드웨어에 대한 문제점 및 개선점을 발견하는 경우가 많았다. 물론 이러한 과정은 8비트나 16비트의 프로세서에서 개발할 때 일이다.
지금은 보통 400MHz이상의 프로세서환경에서 많은 주변장치를 사용하기 때문에 일일이 장치를 위한 소프트웨어를 개발한다는 것은 어려운 일이다. 이런 연유로 프로세서 업체에서 BSP 제공이 일상화 되었고 BSP가 제공되지 않는 프로세서는 개발 자체를 검토하지 않는 경우가 있다.
이러다 보니 프로세서에 대한 깊은 지식이 쌓이기도 전에 소프트웨어를 개발하고 운영체제를 포팅하는 단계를 진행하고 있다. 문제가 발생하면 운영체제 자체의 문제인지 하드웨어적인 오류인지 디버깅하는데 시간이 많이 걸리게 된다(물론 윈도우 임베디드 CE 시스템에서 발생하는 문제를 쉽게 디버깅 하는 경우는 드물다.) 이러한 어려움을 미연에 방지하는 방법은 개발초기에 하드웨어를 제대로 검증할 수 있는 테스트 코드를 추가하라는 것이다.
장착된 하드웨어를 간단히 검증할 수 있는 코드를 추가하고 이 코드가 동작하면 하드웨어의 이상 유무를 확인하게 하는 것이다. 이러면 하드웨어에 대한 이해뿐만 아니라 추후 디바이스 드라이버를 개발할 때에서 좀더 용이하게 개발할 수 있게 한다.
-윈도우 임베디드 CE 운영체제 포팅보다 먼저 하드웨어 검증을 위한 코드를 작성하라.
-작성한 코드는 디바이스 드라이버 개발을 위한 기반이 된다.
-검증 코드는 개발 단계에 따른 새로운 개발 보드가 제대로 동작하는데 확인하는 용도로도 사용할 수 있다.
-개발한 하드웨어를 좀더 세부적으로 테스트 할 수 있다.
8. MS를 믿지 마라
운영체제를 만든 MS를 믿지 말라고? 운영체제를 사용하지 말라는 말과 같다. 하지만 의도는 MS를 믿지 말라는 것이 아니라 윈도우 임베디드 CE 운영체제가 다 해줄 것이라는 생각을 버리라는 것이다. 모든 기능을 다 제공해 줄 수 있지만 그 모든 기능이 제대로 동작하도록 만들어야 하는 일은 엔지니어의 몫이다. 운영체제라고 하는 소프트웨어의 모든 기능을 잘 이용하도록 해야 하며, 동작하는 디바이스 드라이버가 무리 없이 만들어야 한다.
말은 쉽지만 결코 쉽지 않은 개발 과정이다. 흔히들 윈도우 임베디드 CE 운영체제가 많은 부분을 해줄 것이라는 믿음을 가지고 시작할 경우가 많다. 이 믿음을 많은 일을 해야 한다는 생각으로 바꾸고 시작하라는 것이다. 윈도우 임베디드 CE 운영체제뿐만 아니라 다른 임베디드 운영체제 역시 개발 과정은 동일할 것이다.
-윈도우 임베디드 CE 운영체제 개발 과정에 대한 정확한 이해가 필요하다.
-윈도우 임베디드 CE 운영체제 자체보다는 주변 기술에 대한 기반을 미리 다져야 한다.(하드웨어 설계 및 임베디드 시스템 구성, 하드웨어 제어 등등)
-운영체제는 개발해야 할 소프트웨어의 일부분을 대신해준 것뿐이지 실제 할 일은 더 많이 남아 있다는 것이다.
-실제로 운영체제가 정상적으로 동작하고 문제없더라도 탑재하는 소프트웨어를 개발하고 제 동작을 잘하는 상태까지 만드는 데 역시 많은 노력이 필요하다.
9. 기억에 의존하지 말아라
다른 프로젝트도 마찬가지지만 프로젝트는 관리에 중요성을 느낄 것이다. 프로젝트 관리를 어떻게 하는가에 대한 문제는 많은 학문과 관리 기법이 있을 것이다. 윈도우 임베디드 CE 운영체제에 대한 프로젝트 관리는 두가지 측면에서 이루어져야 한다.
첫째는 윈도우 임베디드 CE 시스템에 대한 운영체제 프로젝트라는 것이고 이 운영체제를 이용하는 응용 프로그램에 대한 프로젝트 관리다. 소스를 관리하는 소스 관리 툴과 개발한 운영체제와 응용 프로그램을 테스트 하고 문제점 해결 과정을 기록하는 기록 시스템을 갖추는 것을 먼저 추천한다.
소스를 관리하는데 있어서 마이크로 소프트사의 비주얼 소스 세이브(Visual SourceSafe)나 SVN(Subversion)과 같은 소스 관리 툴과 버그질라(www.bugzilla.org)나 Mantis(www.mantisbt.org)와 같은 이슈 관리 시스템을 사용할 것을 권한다. 상용이던 공개된 무료 툴이건 중요한 것은 아니고 개발하고 개발한 내용을 관리하는 것 자체가 중요한 것이다.
-개발한 소스를 관리할 수 있는 방안을 찾아라
-개발된 소스의 변화, 변경 사항, 문제점들을 기록하고 관리할 수 있는 시스템을 구축하라
다음 그림은 소스 세이프와 Mantis를 이용해 실제 프로젝트에서 소스와 문제점 관리를 하는 그림이다. 관리 소프트웨어를 통한 문제점 관리는 ‘관리를 위한 관리’ 혹은 ‘관리를 하기 위해 더 복잡한 관리’작업이 되지 않도록 최대한 간략하고 사용하기 용이한 방법으로 이용되어야 한다.
간단히 현재 상황과 문제점을 빠르게 파악하고 어떠한 우선 순위로 작업 해야 할 것인가만 제대로 파악할 수 있다면 좋은 관리 시스템이 될 것이다.
10. 검증
검증 작업은 개발한 윈도우 임베디드 CE 운영체제와 응용 프로그램이 제대로 동작하는지 검사하는 작업이다. 검증을 통해 시스템의 안정성과 문제점을 파악할 수 있는 단계가 되어야 한다. 초기 윈도우 임베디드 CE 운영체제에 대한 개념이 없었을때는 테스트와 검증에 대한 개념이 별로 없었다. 이제는 대부분의 회사들이 자체적으로 또는 검증 절차에 의해 하드웨어 및 소프트웨어의 검증 절차를 진행하고 있다. 윈도우 임베디드 CE 운영체제의 검증에 대해서 간략히 살펴 본다면 다음과 같다.
-윈도우 임베디드 CE 테스트 킷트(WCETK)를 통한 운영체제 및 디바이스 드라이버 테스트
-각 모듈에 따른 테스트 항목을 지정하고 세부 테스트 내용을 지정하여 테스터가 직접 테스트를 통하여 문제점 확인 및 검증
-자동화된 하드웨어를 통해 각 장치의 부품 및 기구의 안정성을 테스트 하고 아울러 탑재되어 있는 소프트웨어의 안정성을 검증하는 방법 등이 있을 수 있다.
11. 프로젝트의 시간
윈도우 임베디드 CE 운영체제를 탑재하는 프로젝트의 기간과 일정은 어떻게 구성하는가? 프로젝트의 성격과 개발 방향에 따라 다양할 수 있다. 스마트 폰이나 PDA 개발 프로젝트 같이 1년에서 2년이 걸리는 큰 프로젝트도 있고 수 개월 걸리는 시스템 개발 프로젝트도 있다.
하드웨어, 제품을 구성하는 하드웨어 케이스, 운영체제, 시스템에 탑재 되는 응용 프로그램에 따라 프로젝트의 개발 기간은 차이가 있게 된다. 개발 시작에서부터 출시까지 3개월도 안 걸리는 프로젝트도 있을 수 있다. 처음 윈도우 임베디드 CE 운영체제를 사용해서 개발할 때는 운영체제 포팅 시작에서 안정성을 어느 정도 확보할 시간을 여유롭게 잡아야 한다는 것이다.
대부분 운영체제 포팅에 관한 외주 작업을 하게 되면 간단한 프로젝트의 경우 3개월 전후한 기간으로 포팅 기간을 선정하는 경우가 있다. 이런 경우는 외주 업체는 다년간 개발 노하우 및 기술 축적을 통해 가능한 것이지 일반 업체에서 그렇게 하는 경우는 드물다. 프로젝트가 진행 되더라도 실제 문제점은 밝혀지지 않은 상태(?)라고나 할까? 따라서 윈도우 임베디드 CE 시스템에 대한 프로젝트 일정은 다음과 같은 점을 먼저 고려하면서 작성하기 바란다.
-개발 보드를 통해 운영체제 포팅에 대한 개념과 개발해야 할 항목들을 선정해본다. 이때 각 드라이버나 새로운 기능들을 추가할 때 걸리는 시간을 산출하여 전체 계획을 잡는다.
-개발하는 개발보드가 나올때는 개발보드에 대한 충분한 하드웨어적인 검증 후에 윈도우 임베디드 CE 운영체제를 포팅한다. 이러한 부분을 전체 계획에 포함 시켜야지 하드웨어 문제점 때문에 발생되는 필요없는 디버깅 시간을 없앨 수 있다.
-응용 프로그램 개발을 위한 환경을 조기에 릴리스하면 응용 프로그램 개발시 필요한 사항과 문제점을 미리 파악할 수 있다.
12. Release It!
윈도우 임베디드 CE 운영체제에 관한 업무를 시작하고 나서 가장 큰 부담감은 개발된 각 요소를 모아 하나의 운영체제 이미지로 만드는 작업이다. 1주일 단위로, 혹은 1일 단위로 개발한 요소들을 합치고 만들 수 있다.
이 작업의 중요한 점은 협동 작업에서 생기는 문제점을 미연에 해소하는 것이다. 각 개발자가 만드는 디바이스 드라이버나 운영체제 구성요소들은 1차적으로는 담당자에 의해 테스트가 이루어진다. 하지만 한 운영체제에 합쳐졌을 때 제대로 동작한다고는 장담할 수 없다. 개발자가 잘못 사용하고 있는 이벤트나 태스크에 의해 전체 시스템의 동작이 문제가 생기는 경우도 종종 있다. 또한 개발한 소스를 소스 관리 시스템에 최신으로 업데이트하여 최신 환경에서 다른 개발자가 개발할 수 있도록 하는 것도 필요하다.
이러한 모든 과정은 운영체제를 릴리스 하는 과정에서 처리할 수 있다. 소스를 통합하고, 통합된 소스를 빌드 하는 과정에 오류를 수정하고, 완성된 운영체제 이미지를 테스트 하면서 어떤 문제가 발생하는지 확인해야 한다. 그러면서 최신 소스 환경으로 유지할 수 있는 것이다.
-정기적인 운영체제 빌드 시간을 가져라.
-운영체제를 빌드 하면서 생기는 문제점을 해결하고 최신 개발 소스 상태로 유지해라.
-빌드와 테스트는 바로 이루어져서 문제점을 빨리 검증하고, 검증된 문제점을 해결하여 현 상태에서의 안정적인 시스템을 만들도록 해야 한다.
윈도우 임베디드 CE 운영체제를 개발하면서 소스를 통합하고 빌드하는 과정은 어려운 과정이었다. 누가 문제점을 일으켰는지 파악하기도 힘들었고 어떠한 운영체제 요소가 문제를 일으키는지 확인하기도 어려웠다. 하지만 그 과정을 통해 발생될 많은 문제점을 예방할 수 있었던 것 같다.
끝으로
지금까지 윈도우 임베디드 CE 프로젝트에 관한 사항에 대해서 살펴봤다. 본 내용은 업체와의 대화를 통해 어떠한 생각들을 가지고 있는지 알게 되었고 잘못된 생각들을 조금이나마 바꿨으면 하는 마음에서 작성했다. 물론 대부분의 회사들이 알고 있는 것보다 더 정확하게, 기술력 있게 개발을 한다. 단지 일부 업체의 문제일 것이다.
아울러 윈도우 임베디드 CE 운영체제를 탑재하여 임베디드 시스템을 개발하는 과정에서 필요한 요소가 뭔지 제시하고 싶었다. 비록 비싼 라이선스를 주고 탑재하는 임베디드 CE 운영체제지만 여기에 라이선스 비용의 몇 곱절의 부가가치를 창출해야 하는 것이어야 한다. 그러기 위해서는 윈도우 임베디드 CE 시스템에 대한 정확한 판단과 이해를 바탕으로 해야 한다는 것을 마지막으로 말하고 싶다.
