기존 개발 방식을 버리고 새로운 개발 방식으로 변화하려는 MS와 윈도 폰 7 시리즈

윈도 폰 7 시리즈(WP7)용 모바일 파이어폭스의 개발이 중단되었다는 뉴스가 들렸다. 개발 환경 때문이라고 하는데 이는 향후 그동안 윈도 폰에서 사용하던 어플리케이션들의 WP7의 업그레이드에 많은 영향을 미칠 것이라고 생각이 든다. 모바일 파이어폭스 뿐만 아니라 윈도 폰의 영원한 기본 웹브라우저(^^)인 오페라 역시 WP7용으로 못나올 수 있다는 얘기도 들린다. (참고로 이후에 쓰는 내용들은 프로그래밍을 하셨던 분이라면 이해할 수 있겠지만 그렇지 않다면 어려운 이야기가 될 수 있으니 참고하시길.. ^^;)

WP7용 어플리케이션 개발은 아마 WP7 이후에도 그렇게 유지될 듯 보이지만 C#.NET과 실버라이트가 될 것이다. 이미 WP7용 어플리케이션 개발은 C#.NET과 실버라이트만 허용한다고 MIX'10에서 MS가 밝혔고 이후에도 쭉 그렇게 될 가능성이 높다.

그동안 수많은 윈도 폰용 어플리케이션들은 MFC, Win32 API 등 MS에서 제공해주는 C, C++ 기반의 네이티브 언어로 만들어졌다. 나 역시 모바일 프로그래밍을 이들 언어를 이용해서 만들었으며 지금도 만들고 있다. 데스크탑 플랫폼인 윈도용 어플리케이션을 만들때 주로 사용하는 언어로 모바일에서도 그대로 사용하고 있었던 것이다. 이들 언어는 UI 뿐만 아니라 시스템 부분까지도 컨트롤 할 수 있다는 장점이 있는 반면에 모든 시스템 자원들을 어플리케이션이 자체적으로 다 컨트롤해야 한다는 단점도 있다. 그렇기에 메모리 관리 등에서 많은 문제를 일으키는 것은 사실이다. 하지만 퍼포먼스 부분으로 인해, 또 그동안 많이 사용해왔기 때문에 지금도 꾸준히 사용되고 있는 것이 사실이다.

이런 상황에서 MS는 WP7용 어플리케이션을 C#과 실버라이트로만 만들라고 한다. C#은 C++을 기반으로 만든 Java와 비슷한 언어다. 누구 이야기로는 자바(Java)의 MS 버전이라고도 하고. 여하튼간에 .NET 프레임워크 위에서 돌아가는 관리형(Managed) 언어다. 참고로 자바도 JVM(자바 가상머신) 위에서 돌아가는 것이라 내부적으로 돌아가는 메카니즘은 같다고 보면 된다. 자바의 경우 JVM에서 메모리 관리 등을 다 맡아서 처리하기 때문에 메모리 관리나 보안 부분에 많은 신경을 안쓴다. C# 역시 .NET 프레임워크에서 맡아서 처리해주기 때문에 적어도 기존의 C, C++ 등으로 프로그래밍 할 때보다는 더 편해진 것은 사실이지만 시스템 자원을 가져다 쓰는 부분을 직접 가져다 쓰는 것이 아닌 .NET 프레임워크에 맞겨야 하는 부분 때문에 많은 개발자들, 특히 시스템 프로그래밍 개발자들이 꺼려했던 것이 사실이다. 또한 직접 시스템에 붙는 기존 C, C++ 스타일이 아닌 .NET 프레임워크라는 하나의 단계를 더 거쳐야 하는 C#의 경우 퍼포먼스에서도 약간 더 느리다는 생각을 갖고 있기 때문에 퍼포먼스를 중시여기는 모바일 프로그래머들에게 있어서는 약간의 금기사항처럼 보여졌던 것이 사실이다. 뭐 이는 프로그래머에 따라서 다른 사항이라 뭐가 정답일지는 모르겠다.

MS가 기존의 C, C++ 스타일의 프로그래밍을 버리고 C#, 그리고 실버라이트로 모바일 프로그래밍의 방향을 바꾼 것에는 여러가지 이유가 있을 수 있다. 내가 MS의 핵심 관계자가 아닌 이상 자세한 사항은 잘 모르겠지만 개발자로서 그동안 느꼈던 부분을 바탕으로 한번 얘기해볼까 한다. 내 주관적인 이야기니 참고만 하면 좋을 듯 싶다.

첫 번째로 MS는 모바일 UX에 실버라이트를 적극적으로 도입함으로 풍부한 UX를 WP7부터 제공하려고 하는 듯 싶다. 플래시, 실버라이트 등은 이미 데스크탑 웹 어플리케이션에서 상당한 UX를 보여줬는데 그것을 모바일로 끌어와서 모바일 컴퓨팅의 UX를 더 향상시킬려고 하는 것이다. 이미 아이폰 등에서 보여줬던 다양하고도 화려한 UX를 구현하는데 있어서 기존의 스타일로 만드는 것보다는 이미 그런 UX에 최적화 되어있다고 보여지는 실버라이트와 같은 UX 프레임워크를 도입함으로 단숨에 격차를 줄여보겠다는 의미가 아닐까 싶다. 플래시와 달리 실버라이트는 MS에서 직접 만든 UX 프레임워크이기 때문에 WP7에 커스터마이징 하는 부분에 있어서 플래시보다 훨씬 더 유리하다는 생각이 아닐까 싶다.

두 번째로는 메모리 관리 등의 시스템 자원 관리의 효율성 때문이라고 보여진다. 앞서 얘기했다시피 이전까지의 C, C++ 기반의 프로그래밍은 메모리 관리 등을 직접 다 해왔다. 그러다보니 흔히들 메모리 누수 현상이 자주 나오곤 했고 그것이 어플리케이션의 안정화에 별로 좋지 않은 영향을 끼친 것이 사실이다. 자바의 경우 JVM에서 가비지 컬렉션이라고 알아서 사용하지 않는 할당된 메모리를 해제하는 기능이 있는데 .NET 프레임워크에서도 그런 기능으로 메모리 관리를 하겠다는 의미로 보여진다. 뿐만 아니라 내부적으로 포인터 등의 시스템을 직접 건드리는 방식(포인터는 메모리의 주소를 직접 활용하여 뭔가를 하는 방식이라고 간단하게 설명하고 싶다. 세부적인 내용은 아마 책 한권을 써도 모자를 듯 -.-)으로 시스템을 불안정하게 만드는 요소를 제거하여 최대한 안정적으로 어플리케이션이 시스템에서 운영되겠끔 하겠다는 것이다. 메모리 관리와 불필요한 시스템 접근 방지 등이 안정성을 최고로 쳐야 하는 모바일 프로그래밍에서 꼭 필요하다고 생각했기 때문이라 보여진다.

일단 저렇게 2개정도로 요약하고 싶다. 풍부한 UX 활용의 용이함과 안전한 어플리케이션 자원 관리, 이것만큼이나 중요한 이유는 없다는 생각이다. 다른 이유도 있겠지만 말이다.

아직까지 MS는 WP7용 NDK(Native Development Kit, C, C++ 등을 활용하여 직접 시스템 자원을 활용하도록 제공해주는 인터페이스)를 제공해주지 않는다. 안드로이드의 경우 기본적으로는 자바를 활용하는 ADK(안드로이드 개발자 툴킷) 이외에 NDK를 제공해주기 때문에 C나 C++로 만들어진 모듈들을 활용할 수 있는 방법이 있는 반면에 WP7에는 아직까지는 그런 기능을 제공해주지 않는다는 것이다. 물론 여기에 예외가 하나 있다. 플래시의 경우 예외를 허용하여 시스템을 직접 건드릴 수 있게 해줬다. 실버라이트와 마찬가지로 플래시도 모바일 UX 요소 중 중요한 요소라 여겨지기 때문에 그런 결정을 내린 듯 싶은데 아직까지는 플래시를 제외한 어떤 것도 예외를 인정하지는 않은 듯 싶다.

그렇다면 서두에서 언급했던 모바일 파이어폭스와 오페라 웹브라우저는 왜 WP7로의 개발이 어렵다고 포기단계에 이르게 되었을까? 이들 어플리케이션의 중요부분이 다 C나 C++로 작성되어 있기 때문에 MS에서 제시한 C#으로 다시 만들기 위해서는 정말로 처음부터 다시 만들어야 하는 상황이라는 것이다. 기존의 소스를 재활용할 수 없는 상황이기 때문에 그만큼의 시간과 노력이 더 들어가야 한다는 의미다. 이런 이유로 인해 WP7에서는 모바일 파이어폭스와 오페라 웹브라우저를 보기가 어렵지 않겠느냐 하는 것이 내 생각이다. 오페라 미니의 경우 그렇게 복잡하지 않기 때문에 WP7용으로 나올 수 있다고는 한다. 하지만 과연 WP7에서 웹브라우져가 IE만으로 버틸 수 있을지는 미지수다.

과거와의 단절을 통해 새롭게 시작하려는 WP7 입장에서 저런 개발방식의 변화는 이해할 수 있는 대목이다. 그동안 문제가 되었던 시스템 안정성 문제를 해결하고 풍부한 UX를 제공하려는 그들의 결정은 WP7을 다시 한번 모바일 시장에서 힘을주게 만드는 요소가 될 것이라고 생각이 든다. 하지만 이런 결정으로 인해 기존 어플리케이션들의 재활용이 불가능하게 됨으로 어플리케이션 확보에 문제가 생길 수도 있고 사용패턴의 변화를 못쫒아가게 만드는 요인으로도 작용할 수 있다는 생각 역시 든다. 언어의 변화로 인해 기존 어플리케이션을 그대로 WP7에 옮길 수 없어서 새로운 스타일로 다시 만든다면 기존 어플리케이션에 익숙한 사용자들이 새로운 스타일로 적응하는 것에 시간이 걸릴 수 있으며 모바일 파이어폭스와 같이 아예 못만드는 어플리케이션들이 나올 경우에는 그것에 익숙해져있는 사용자들이 과연 대체 어플리케이션으로 옮겨가서 과거와 같은 사용성을 보여주겠느냐 하는 우려가 나올 수 있다는 생각이다. 시스템적으로만 봤을 때는 충분히 이해할 수 있지만 사용자 측면으로 봤을 때는 약간의 문제가 나올 수 있다는 말이다.

물론 시간이 지나면 이런 부분들은 해결되겠지만 올해 말에 나올 WP7에서 이런 혼란은 잠시나마 일어나지 않을까 싶다. MS의 지속적인 개발자 지원이 필요한 부분이기도 하고 말이다.

ps) 쓰면서 느낀 부분이지만 이 글은 아무래도 프로그래밍을 조금 아는 사람이라면 이해할 수 있지만 그렇지 않으면 정말 이해하기 어려울 수 있겠다는 생각이 든다 -.-;