WP7의 표준화된 H/W, S/W 플랫폼

마이크로소프트는 Windows Phone 7(이하 WP7)을 준비하면서 단순히 모바일 운영체제의 구성 요소를 변경하는 것에 그치지 않고 모바일 플랫폼에 대한 접근 방식부터 다시 고려했다. 최근 급속히 시장 점유율을 확대한 아이폰 및 안드로이드 디바이스와 종래의 스마트폰, 특히 Windows Mobile 디바이스를 비교하자면 어떤 차이점이 있을까? 디바이스의 형태(Form Factor), 개발 환경 등 여러가지 요소를 꼽을 수 있겠으나, 우선 이전에 출시된 Windows Mobile 디바이스를 먼저 생각해보자. Windows Mobile 디바이스를 많이 다뤄본 사람이라면, 제조사마다 디바이스의 외형과 기능이 상당히 다양했음을 기억할 수 있을 것이다.

Windows Mobile 기기는 제조사마다 CPU는 물론, 디스플레이의 해상도, 하드웨어 자판 및 각종 버튼의 유무, GPS의 유무, SD 카드 슬롯, 이어폰과 마이크, 카메라, 가속도계 등 디바이스 내외에 존재하는 모든 것들의 사양이 서로 상이했다. 마이크로소프트는 다양한 Windows Mobile 디바이스를 비교적 자유롭게 설계할 수 있도록 허용함으로써 제조사가 독특하고 매력적인 하드웨어를 설계할 수 있는 환경을 제공해 주었지만, 이로 인해 모바일 앱 개발자는 엄청난 양의 호환성 테스트와 함께 타겟 디바이스의 선정까지 고민해야 하는 처지가 되었다. 개발자가 흥미로운 기능을 가진 모바일 앱을 설계하는데 있어서 필요한 기능이 무엇이냐에 따라서 특정 디바이스는 아예 구동조차 할 수 없는 경우가 많았고, 그러한 상황에서 모바일 앱의 유지보수는 점점 어려워지는 상황이 계속되었다.

잠시 눈을 돌려 개발 환경을 살펴보면, 개발 환경에서도 마찬가지 현상이 벌어지고 있었다. Windows Mobile의 개발 언어는 C, C#, VB.NET 등을 사용할 수 있었으며, WinCE API, ATL, MFC, .NET CF(Compact Framework) 등을 개발 라이브러리로 사용할 수 있었다. Visual Studio가 표준 통합 개발 환경이긴 했었지만, Visual Studio 버전별로 제공하는 개발 환경에 조금씩 차이가 있었을 뿐만 아니라, 서드파티 업체들까지 가세해서 개발 환경의 다양성을 제공하고 있었다. 예를 들면, 볼랜드의 Borland C++ Builder, Delphi도 Windows Mobile을 지원하는 개발 환경 중 하나였다. 물론 여기에 ‘Write once, run anywhere’를 기치로 내걸고 있는 자바 또한 빼놓을 수 없다. Windows Mobile 개발 환경은 단순 수치상으로는 그 수가 적어 보일지 몰라도, 그 다양성과 복잡성에 있어서는 사실상 데스크톱 개발 환경과 다를 바가 없었다. 이런 특성은 처음 Windows Mobile을 접하는 개발자가 Windows Mobile 개발에 쉽게 접근할 수 있는 동인이 되기도 했지만(아무래도 데스크톱 환경과 개발 환경이 유사하므로) 후에 프로그램의 유지 보수와 호환성 확보 측면에서는 어려움을 겪게 되는 원인이 되기도 했다.

게다가 Windows Mobile에서는 스마트폰 제조사뿐만 아니라 통신사도 정책적으로 개별 디바이스의 운용 환경을 마음대로 조정하는 것이 가능했다. 이는 개발자에게 주어진 개발 환경이 다양하다는 것뿐만이 아니라, 실제 스마트폰을 사용하게 되는 사용자도 각자 다른 사용자 경험을 갖게 되는 결과를 초래했다. 동일한 Windows Mobile을 사용하는 사용자들끼리도 사용자의 수준에 따라 완전히 다른, 그리고 다양한 사용자 경험을 겪게 되었다. 결과적으로는 이러한 Windows Mobile의 다양성이 최종 사용자에게까지 영향을 끼쳤다. 풍부한 기능을 가진 멋진 Windows Mobile 앱 다수가 호환성 문제로 사용하기 어려워지거나, 개발자가 애초에 의도한대로의 사용자 경험을 줄 수 없게 되거나, 최악의 경우에는 아예 실행조차 되지 않는 상황에 처하곤 했다. 하지만 마이크로소프트도, 스마트폰 제조사도, 통신사도 이러한 상황에 제동을 걸지 않은채로 커스터마이징된 Windows Mobile 스마트폰 제품을 계속해서 출시했고, 이는 Windows Mobile 생태계가 개발자와 사용자 모두에게 있어 점점 복잡해져서 접근하기 어려운 환경이 되어간다는 것을 의미했다. 생태계에서의 다양성은 보통 좋은 결과를 가져오지만 불행하게도 Windows Mobile 생태계에서는 그다지 좋은 결과를 낳지 못했다.

 

제멋대로 Windows Mobile

 

마이크로소프트는 새로이 WP7의 전략을 수립하면서 이러한 다양성으로 인해 빚어지는 일관성의 부족을 타개하기 위해 모바일 플랫폼에 약간의 제약을 가하기로 결정했다. 이러한 제약은 크게 WP7 디바이스와 개발 환경 측면으로 나누어 볼 수 있다.

디바이스 측면을 살펴보면, 마이크로소프트는 스마트폰 제조사에게 WP7 스마트폰의 하드웨어 구성 요소의 최소 요구사항을 종전보다 상세히 규정함으로써 가급적 WP7 스마트폰의 사양이 일관성을 갖도록 강제한다. 이러한 최소 요구사항에는 스크린 사이즈, 그래픽 가속 기능, DirectX 지원, 최소 요구 메모리/플래시 메모리, CPU 사양 등이 포함되며, 그 외에도 멀티터치 스크린, 가속계, GPS, 하드웨어 버튼, 컴퍼스, 조도 센서, 진동 기능 등이 포함된다. WP7 스마트폰에는 이러한 기능들이 최소 요구사항으로 강제됨에 따라 개발자는 어떤 WP7에든 이러한 기능이 존재한다는 것을 가정하고 개발을 진행할 수 있으며, 그 결과 개발자는 다양한 디바이스에서도 사용자에게 비교적 일관성 있는 사용자 경험을 전달할 수 있게 되었다.

 

비슷비슷 Windows Phone 7

 

개발 환경 측면의 제약을 살펴보면, 이제 WP7 플랫폼에서는 더 이상 개발자에게 Windows CE[1] 기반의 API를 사용할 수 없도록 하고 있으며 관리된 코드[2]를 사용한 개발 방식만을 허용한다. 종전에 API 방식으로 개발되었던 Windows Mobile 호환 앱은 더 이상 WP7에서 실행되지 않으며, 비록 WP7이 Windows CE 기반의 커널(Windows Mobile의 커널과 유사한)을 채택하고 있긴 하지만 일반 앱의 실행 및 운용 환경이 완전히 다르기 때문에, 개발자 입장에서 WP7 플랫폼은 Windows Mobile과 완전 별개의 플랫폼이라고 생각해도 좋을 정도이다.

물론 일반 개발자 및 앱 개발사에 적용되는 이야기이다. 스마트폰 제조사나 통신사는 여전히 WP7에 네이티브 코드로 작성한 프로그램을 추가할 수 있다. 하지만 이렇게 작성되는 프로그램도 기존 WP7의 UI를 침범할 수 없는 등, 여러 제약이 존재한다.

WP7 플랫폼의 실제 운용 환경은 기존의 Windows Mobile보다는 iOS나 안드로이드에 더 가깝다. 또한 개발자가 사용할 수 있는 개발 환경은 Silverlight, XNA로 제한되긴 하지만, WP7의 앱은 .NET 기반의 안전한 런타임 환경 위에서 구동되며 Silverlight와 XNA라는 이미 성숙된 프레임워크 라이브러리를 활용하여 개발하는 것이 가능하다. 마이크로소프트는 위와 비슷한 맥락에서 WP7 개발을 위한 개발 도구를 배포 중이다. 다음 장에서 좀 더 자세히 살펴보겠지만, 마이크로소프트의 소프트웨어 개발 도구인 Visual Studio와 Silverlight 개발 도구인 Expression Blend 등이 포함되어 있는 패키지로써, 무료로 이러한 개발 도구를 다운받을 수 있다.

이러한 일관성은 WP7 디바이스의 형태와 개발 환경 전반에 걸쳐 유지되고 있으며, 그로 인해 사용자는 일관성 있는 사용 환경을 누릴 수 있다. 비단 WP7의 UI 뿐만 아니라 디바이스의 외관에서도 이러한 일관성은 유지되고 있다.

 

 

[1] 마이크로소프트의 모바일 OS. WP7도 Windows CE 기반의 커널을 갖고 있지만, 일반 개발자는 Windows CE 레벨의 커널에 접근하는 것이 허용되지 않는다.

[2] Managed code. 마이크로소프트에서는 .NET 기반의 실행 코드를 관리된 코드(Managed code), 그 외의 실행 코드는 비관리 코드(Unmanaged code) 혹은 네이티브 코드(Native code)라는 명칭으로 구분하고 있다.