1. 들어가는 글

Palm이 Palm Pre라는 신제품을 들고 나온지 어느 정도 시간이 흘렀지만 아직까지 명확한 실체가 밝혀진 것은 없다. 플랫폼이라는게 하루 아침에 나오는 것이 아니니 어쩌면 당연한 것인지도 모른다. Palm의 입장에서는 iPhone OS 3.0 릴리즈 계획 때문에 이래저래 김이 많이 새는 상황이 되고 있다. iPhone OS 대비 우위에 있다고 생각했던 많은 것들이 OS 3.0에서 대부분 지원되기 때문이다. Palm에서 일정대로 OS를 내놓을지, iPhone OS 3.0 에 대한 경쟁력을 갖추기 위해 좀 더 시간을 투자할지는 지켜봐야 할 듯 하다.

예상보다 길어지는 그들의 신비주의를 얼마전 O'Reilly 에서 출판한 'Palm webOS'라는 책을 토대로 조금이라도 짐작을 해보도록 하자. 포스트를 들어가기에 앞서서 모든 플랫폼은 릴리즈가 되기 전까지 어떤 모양이 될지 알 수가 없으며, 공개된 자료만으로는 깊이 알기가 힘이 들어 최종 제품은 조금 다른 모습이 될 수 있다는 것을 밝힌다.

2. Palm OS와는 전혀 다른 제품

Palm은 오래전 H/W사업부인 Palm과 S/W 사업부인 Palm Source로 분리를 하였다. Palm과 Palm Source는 상호 계약에 의해 파트너 관계를 계속 유지하면서 단말을 계속해서 개발해 왔으나 얼마전(2007년으로 기억한다) 계약이 끝나면서 독자적인 길을 걷게 된다.

그 직전, Palm Source는 Access에 합병을 당하면서 이미 계열회사라는 개념이 없어져 버렸다. Access에 합병된 Palm Source는 Palm OS를 고도화만 해서는 최신 기술 트렌드를 따라가기에는 무리가 있다고 판단하고 Linux 기반의 ALP라는 플랫폼을 개발한다. ALP는 Linux 기반이지만 Application을 구동하고 관리하는 부분의 메카니즘은 Palm OS와 무척 닮아 있다. 게다가 Ghost라는 플랫폼 내의 에뮬레이터에 의해 고전 Palm의 어플리케이션과 Binary 호환이 된다.

이로 인해 Palm OS가 실질적인 upgrade가 중단이 되고, H/W 업체인 Palm은 독자적인 플랫폼이 필요할 수 밖에 없는 상황이 되었다. 그렇게 해서 개발에 들어간 자체 플랫폼이 Palm Pre OS이다.



3. 새로운 Application Model을 제시

기존에는 Application이라 하면 Native Application과 Web Application으로 구분하였다. Native Application은 Application의 모든 내용(UI, S/W Logic, Data, View 등)이 Local Application에 있는 것을 말하고, Web Application은 Web Browser를 이용해서 Web Server와 통신을 해가면 실행되는 것을 말하였다. 이때 일반적으로 Web Browser를 구동하는 클라이언트와 Web Server는 서로 다른 머신이며 브라우저는 S/W Logic과 Data를 전혀 가지고 있지 않았다.

Palm Pre에서 이야기 하는 Web Application은 기존 개념과 달리 Ajax 기술을 이용한 것으로 S/W Logic과 Data를 클라이언트와 Web Server에서 분산해서 가지고 있는 것이다. 또한, 클라이언트는 디바이스에 있는 각종 자원들을 Native Application과 동일한 수준으로 접근 할 수 있다.

이 외에도 화려한 UI를 구성하기 위해 다양한 API와 Framework를 제공하고 있으며, 멀티태스킹과 Push, Notification등을 완벽하게 제공한다. 참고로 Pale Pre에서 사용하는 브라우저는 Webkit 기반으로 알려져 있다.



4. 아키텍쳐


Palm Pre OS 아키텍쳐는 위와 같은 구조를 가진다. 일반적으로 플랫폼 아키텍쳐에서 소개하는 Drawing Engine, Database 지원, Event driven 처리, 외부 장치 연동 Protocol 지원 등은 위 그림만으로는 알 수가 없다. 서두에서 언급했듯이 지금도 계속 개발 중인 제품이라 정리가 아직 덜되지 않았나 하는 생각이다. 다소 복잡한 위 그림을 간략화 시키면 아래와 같다.


Core OS는 Linux 2.6 커널을 기반으로 하여 만들어져 있고 ext3 File System을 사용한다. Web OS Services는 커널과 어플리케이션의 중간에서 미들웨어와 같은 역할을 담당한다. UI System을 정말 말그대로 UI를 담당하는 부분이다.


5. UI는 iPhone과 유사


흔히들 Windows라고 익숙하게 불렀던 것을 Palm Pre에서는 Card라고 부른다. iPhone에 익숙한 개발자라면 View Controller 하나를 Card, Card View 하나라고 이해하면 된다. Card 위에 시간이나 상태 등을 알 수 있는 영역을 Status Bar라고 부르고, 아래 부분에는 Banner Notification이나 Notification Bar등이 존재한다.

iPhone의 Navication Controller를 통한 Push, Pop의 메카니즘은 직관적인 UI를 구성하기에 무척 편리한데 Palm Pre역시 동일한 UI를 제공해 주고 있다. Design 느낌은 다르지만 알게 모르게 iPhone을 많이 벤치마킹했음을 짐작할 수 있다.



6. iPhone은 Cocoa, Palm Pre는 Mojo

새로운 플랫폼을 접하다 보면 처음에는 UI 적인 요소의 낯설음을 먼저 접하게 되지만, 조금만 익숙해지면 결국 Core Framework의 이해도가 관건이라는 것을 알게 된다. Palm Pre는 Mojo라는 Java Script Framework를 제공하고 있으며, 이에 대한 실체는 지금까지 공개된 자료로는 좀처럼 알기 어렵다.

하지만 전혀 알 수 없다는 뜻은 아니다. Mojo Framework는 Web에서 널리 알려져 있는 Java Script Toolkit인 Dojo SDK를 기반으로 한 것이다. Mojo는 Dojo에서 크게 바뀌지 않은 상태라고 알려져 있다. 그러므로, Dojo를 통해 Mojo을 어느 정도 짐작은 할 수 있다. Dojo에 대해 궁금한 분은 Dojo Campus에 있는 'Dojo Feature Explorer'를 방문해서 잠깐 Demo를 보면 어떠한 기능이 있는지 아쉬운데로 맛 볼 수 있을 것이다. 불행히도 'Dojo Feature Explorer' 내의 Dijit, DojoX 등의 일부 기능은 FireFox에서 구동이 되지 않으니, IE나 Safari를 이용해서 접속하기 바란다.


7. 향후 계획

이미 알려진 바와 같이 Palm Pre는 Sprint향으로 첫번째 단말을 개발 중이다. Sprint의 3G 망을 통해 서비스될 예정이며 음성, Data, SMS 등을 모두 포함하는 파격적인 요금제를 준비 중이다. 다양한 3rd Party Application도 준비 중인 것으로 알려져 있는데 지금 밝혀진 바로는 Navigation, Sprint NFL 등이 개발 중이다. iPhone의 App Store와 동일한 Market Place도 개발 중에 있으나 3D Game과 같은 화려한 Application은 Java Script의 기술적인 한계로 1차 버전에서는 제외될 것으로 알려져 있다. 또한 2009년 말까지는 Flash도 지원할 계획이 있음을 Palm에서 밝히고 있다. 최종 릴리즈는 2009년 중반이라고 이야기 되고 있으나 예정보다 조금 늦어질 것 같은 느낌이다.

보다 더 자세한 내용을 알고 싶은 분은 O'Reilly Webcast 동영상을 아래 embeded해 놓았으니 보기를 바란다. 약 1시간 정도가 소요되며, 전반적인 Palm Pre OS에 대한 소개와 더불어 Sample Application 까지 제작해 준다. 포스트 내용 외의 디테일한 기술적인 내용은 질문을 해도 답변을 드릴 수 없으니 반드시 동영상을 보기를 권한다.

모바일 플랫폼은 이미 한치 앞을 예상할 수 없는 전쟁터이다. 이런 상황에서 연초부터 Sun의 JavaFX Mobile OS, Palm의 Palm® webOS™가 새롭게 등장하면서 더욱 복잡한 상황이 연출되고 있다. 연구 개발해야할 것도 많아지고 있으며, 시장의 흐름 또한 더욱 민감하게 주시해야 한다.

Application을 개발하는 입장에서 타인과 자신으로부터 '어떤 플랫폼을 선택해야 하는지' 끊임없는 질문을 받고 있다. 과연 어떤 플랫폼을 선택해야 효과적인 것일까? 이번 포스팅에서는 다소 원론적인 이야기를 해보고자 한다. 원론적인 이야기일 수 밖에 없는 이유는 제품의 성격, 조직 문화에 따라서 전혀 다른 결론이 나올 수 있기 때문이다. 아래 이야기는 Application 개발자 입장에서 보는 일반적인 관점이라는 것을 염두해 주기를 바란다.


실질적인 마켓크기를 고려해야


흔히 플랫폼의 시장 크기(Market Size)를 단말수와 비례해서 생각하는 경우가 많지만 매우 위험한 생각이다. 위 그림은 각 플랫폼별로 개략적인 누적 판매수이다. Nokia의 S60 플랫폼이 가장 많이 시장에 팔려있다. 그렇다면 Application Developer의 입장에서 저 수치 그대로를 시장 크기라고 판단할 것인가?


시장 크기는 단말 판매량, Data 정액 사용자, Application에 대한 인지도, 유통 채널등이 모두 고려되어야 한다. 그리고, Global 시장을 타겟으로 하는지, Local Market만을 고려하는지에 따라서 수치는 전혀 다르다. huikea.com의 한 보고서에서는 단말 판매량, Data 정액제 가입 비율, 어플리케이션 인지율을 통해서 실제 시장 크기를 계산하였는데, 그중 가장 대표적인 iPhone과 S60을 비교한 내용을 재구성하여 소개한다.


Application Developer 입장에서 보면 시장에 100M 팔린 S60 보다 10M 팔린 iPhone의 크기가 더 크다는 것이다. 위 보고서에 언급되지 않은 요소인 유통 채널의 다양함, 그리고 LCD 크기의 일관성(LCD 해상도가 다양하면 개발 비용이 증가한다.) 등을 고려하면 현재로서는 iPhone 시장이 가장 크다고 해도 과언이 아니다.


Cross Platform에도 관심을

Mobile Platform은 위와 같은 Low level Platform만 존재하는 것이 아니다. Low level platform위에서 작동하는 Cross Platform들이 있다. Flash Lite는 현재 S60과 Windows Mobile 일부에 탑재가 되어 있고, Platform에서 지원하지 않아도 일부 풀브라우저에서 지원하여 Flash가 플레이된다. Flash Lite는 PC 환경과 유사하고, 네트워크와 다운로드 등도 지원하여 간단한 Application이라면 Flash Lite로 충분히 개발할 수 있다.

요즘은 관심사에서 멀어지고 있는 J2ME도 아직은 무시하지 말자. S60과 Blackberry는 기본적으로 J2ME를 탑재하고 있고, Sun의 J2ME와는 약간 다르지만 Android도 Java 기반이다. 다른 플랫폼들이 스마트폰 위에서만 작동되는 것과는 달리 J2ME는 일반폰위에서도 작동이 된다는 것도 플랫폼 전쟁터에서 잊고 있던 상식이다. 가장 큰 시장인 iPhone이 성능 이슈로 인해 Virtual Machine을 포팅하지 않은 것이 아쉬울 뿐이다. 대략적으로 J2ME가 포팅된 누적단말은 1B으로 이야기 되고 있다.

가장 확실한 Cross Platform은 Web 이다. Web만큼 발전되고 독립적인 Platform은 없다. 어디에서나 브라우저만 있으면 Web Application이 작동한다. 이미 'Mobile Native App와 Web App 비교'에서 Web App의 특징을 설명한 적이 있으니 개발하려는 제품이 어디에 적합한지 참고하기 바란다.

Web App의 가장 큰 단점은 Local Resource에 대한 접근을 못한다는 것인데 일부 풀브라우저들은 Ajax나 Dynamic Menu와 같은 기술을 이용해서 Local Resource 접근을 지원하고 있다. 위와 같이 Native App과의 차이가 점점 없어지는 추세이다. Native App과 Web App의 중간이 되는 Web Runtimes App(위젯이 가장 대표적인 예이다.)도 있으니 개발하고자 하는 Application의 특징에 맞추어 선택을 해야 한다.



플랫폼 독립적인 아키텍쳐의 설계가 중요

지금은 플랫폼을 선택할 때가 아니다. 국내만 보아도 Windows Mobile 외의 플랫폼이 이제야 도입되는 시기인 만큼 추이를 지켜보아야 할 필요가 있다. 현재 필요한 것은 다양한 플랫폼에 이식이 가능한 개발 설계를 해야 하는 것이다. 개발의 측면에서 몇가지 주요한 내용을 정리하자면 아래와 같다.



플랫폼보다 중요한 것은 Business를 만드는 것

제품을 개발하기 전에 Platform을 선택하는 것은 어리석은 짓이다. Platform 선택보다 중요한 것은 '어떤 제품(Business)을 개발하는 것이냐'이다. 시장이 어떤 제품을 원하느냐, 그리고 새롭게 적용할 수 있는 기술이 무엇인지를 먼저 고민하고 결정하라. 그 외에 이통사와 제휴를 하거나 Platform별로 이루어지는 Challenge와 같은 기회요인이 있는지 검토를 해보아야 한다.

이런 기본적인 결정이 끝난 후에 제반 사항이 가장 맞는 단말과 플랫폼을 선정해야 한다. 어떤 플랫폼이 다양한 API와 매쉬업 서비스, 그리고 오픈 마켓을 제공한다고 무턱대고 해당 플랫폼을 선택하는 우를 범하지 않기를 바란다.

이번에는 좋은 컬럼 하나를 소개할까 한다. BlueCoat의 후원을 통해 Jack E. Gold가 작성한 "Strategic Planning for Mobile Applications"은 아래와 같은 3개의 컬럼으로 구성되어 모바일 어플리케이션 개발에 대해 유의할 점, 그리고 전사적인 전략 기획의 중요성에 대해서 이야기 하고 있다.


작성자인 Jack E. Gold는 research firm인 J. Gold Associates의 창립자이자 애널리스트로 모바일쪽 전문가로 알려져 있다. 컬럼인 만큼 대단한 해법을 주는 문서는 아니고 기본적이고 뻔한 이야기를 하고 있지만 무척 공감가는 이야기를 많이 해 주고 있어 재미나게 본 컬럼이다.

모바일 전문 기업에 근무하는 분들에게는 조금은 식상한 이야기라 권해주고 싶지는 않고 Web 서비스나 일반 응용 프로그램 기업이 모바일 관련 제품을 고민하는 상황이라면 개발팀장, 전략 기획자, 그리고 개발에 대한 의사 결정권자는 반드시 읽어보기를 바란다.  또한 개발은 다 똑같아서 윈도우즈 응용프로그래머던 웹개발자던 누구나 모바일 개발을 할 수 있다고 생각하는 분은 필독 컬럼이다.

개인적으로 두번째 컬럼이 무척 마음에 와닿았는데 문서 중에 가장 공감이 가는 부분은 아래와 같았다.

이주째 계속되는 철야작업...
날마다 새벽 2시를 넘어서야 집에 가는 택시를 탈 수가 있다.
이정도 속도라면 추석을 반납해야 한다고 소리지르는 팀장과 묵묵히 쌓여가는 팀원들의 불만들 사이에서 어찌하면 프로젝트 후에도 팀이 깨지지 않을 수 있을까를 생각한다.
하나의 프로젝트를 위해서 갑자기 동원된 6명의 팀원들도 미쳐 소스를 볼 새도 없이 급한 마음에 개발은 시작되고 나름대로의 경험과 퍼포먼스도 한없이 뱉어내는 VC의 Link Error와 SVN의 Complicated 메시지, 느려터진 컴파일 속도 앞에서 내세울 수가 없게 된다.

갑작스럽게 두달안에 모든 걸 끝내야 한다는 본사의 총개발부장의 지시..
스펙은 정해져있지도 않고 시작부터 모두들 실패할 프로젝트를 생각한다.
본사와의 관계는 초반부터 어긋나고 매일마다 계속되는 Release에 긴장을 놓을 수가 없다.

비즈니스 컨설팅을 해주는데 대상 회사가 예전에 다니던 회사다.
그 회사의 모든 장단점을 알고 있기에 신랄하게 이야기를 해주었다. 사장님이고 사원들이고 속쉬원한 소리 해서 고맙다고 하는데 깨어보니 책상 안에 엎드려 잠시 눈을 붙힐 때 꾼 꿈이었나보다.
깨어나 생각해보니... 컨설턴트라면 예전 다니던 회사를 컨설팅 해주는 것도 재미있겠다 싶다.

꿈인지 생시인지도 모르고...
블로그 할 시간은 없어 출근길에 그냥 하소연을 해본다.
아마 다음달 중순은 되야 정신을 차릴 수 있을텐데....

모바일쪽에서 개발을 하다보면 가끔씩 Main Entry를 못찾아서 개발한 Application이 실행이 안되는 경우가 종종있다. 플랫폼에 따라 약간씩 차이가 있지만 모바일에서 Application을 Loader하는 순서는 Windows에서 LoadLibrary를 이용하여 dll내의 함수가 호출되는 것과 유사한 동작을 한다.

문제는 각각의 Application에서 할당된(플랫폼에 따라 다르긴 하지만) 메모리를 앞의 Application이 Over를 하는 경우에는 Main Entry 영역이 없어져 버리기 때문에 Application Loader가 가끔 void main() 의 함수 Pointer를 못 찾는 경우가 종종 생긴다.

또는 Applicaiton 영역의 크기가 얼마인지 정확히 알지 못할 때는 main 함수만 보유한 Blank Applicaiton을 만들어서 확인을 해야 한다. 그 후에 Main 함수의 크기를 점점 늘여나가면서 확인을 해야 하는 경우가 있다. 리소스가 가능한 Platform인 경우 리소스의 크기로 조절을 해도 되지만 모바일에서 리소스를 지원하지 않는 플랫폼이 상당수인데다가 리소스는 실행 모듈의 뒷부분에 있기 때문에 되도록이면 main 이 불려 질 수 있는 앞쪽이 좋다.

이번에 비슷한 일을 겪으면서 간단하게 유틸을 하나 만들었다.
배열값을 간단하게 만들어 버리면 컴파일러가 압축을 해버리기 때문에 원하는 실행 모듈의 크기를 얻을 수 없으므로 random 하게 값을 만들어 주어야 한다. 워낙 간단한 유틸이라 뭐 만들고 잣이고 할게 없었다. Size는 컴파일러마다 압축을 조금씩 하므로 원하는 값과 정확히 일치는 하지 않지만 결과는 대충 비슷하게 들어 맞는다. 에러 처리가 빠진게 있을지는 모르겠다~

근데... 이런게 필요한 사람이 있기는 있으려나??

아래는 내가 모바일 게임 전문 업체로서 몇개 안되는(그때 당시 2개) 상장 기업의 개발 부장으로 있을 때에 3년 전 쯤 입사시험으로 냈었던 문제이다.


문제는 어차피 어려우리라 예상을 했었고, 대다수의 응시자들이 신입이 아닌 경력자였기 때문에 문제의 정답 여부보다는 답변을 쓰는 자세를 보고자 했었으나 결과는 참담했었다. 한명도 제대로 모두 답변을 쓴 사람이 없었던 것은 물론 대부분의 단답형의 무성의한 답변을 작성하였다.

어쩌면.... 성의있게 쓸만한 여지조차 줄 수 없는 어려운 문제였는지도..

하나의 Application이 성능이 나지 않을 때 무조건 Performance만 운운하는 경우가 있다.
Performance라는 것은 알고리즘이나 로직, 디자인등에 관련된 개발자 수준에서 개선될 수 있는 사항이고 Response는 하드웨어나 네트워크 속도 등 어쩔 수 없거나 장비등을 통해서 개선될 수 있는 사항이다.

개발자의 입장에서 Reponse는 어쩔 수 없는 대상이지만 때로는 피해가야 할 때가 있다.
이를 테면 핸드폰에서 소켓 연결이 아주 빈번하다면 그때마다 연결하지 말고 계속 연결해서 사용하는 것이 대표적인 예이다.

Performance의 종류는 아래와 같다.

- Computational Preformance
- RAM Footprint
- Startup Time
- Scalability
- Perceived Performance

이중 개발자들이 가장 지나치기 쉬운 것이 Perceived Performance이다. 이는 사용자가 인지하는 수행속도를 뜻한다. 윈도우에서 복사를 할 때 서류철이 날라가는 에니메이션을 보여주거나, 다운로드 받을 때 몇 %가 수행되었는지를 보여주는 것들을 말한다.

모바일에서는 부족한 리소스로 Application을 수행하다 보니 이러한 것을 지나치기가 쉽다. 예전과는 많이 달라졌으니 세심한 UI 배려가 좀 더 필요하다는 생각을 많이 한다.

처음 모바일을 할 때만 해도 맵툴이니, 스프라이트툴이니, 스크립트툴이니 하는 개발도구들은 온라인에서나 사용되는 툴이어서 모바일과는 거리가 있었는데 요즘은 일반화가 되어버린 듯 하다.
고용량화니 대작 RPG 운운하면서 원인을 떠들어대는 것은 블로그 글자 채우기 외에 다른 의미는 없는 것 같고..

두가지 이야기만 해주고 싶다.

첫째는 관리자들에게 하고 싶은 이야기인데..
개발자들이 개발툴의 필요성에 대해서 이야기를 하면 그거 개발하면(또는 사용하면) 개발 기간이 얼마나 줄어드는데? 라는 질문에만 초점을 주로 맞추는데..
개발툴을 사용하면 개발 기간이 약간 줄어드는 것은 사실이지만 획기적으로 줄어들지는 않는다.
개발툴의 사용은 오히려 QA나 Level Balance 등의 이슈에 오히려 더 중요하게 작용을 한다.
현실적으로 툴 도입을 하면 기획 요소 수정등이 쉬워짐으로 개발 막바지에 발란스 요소들이 자주 바뀌게 되어 개발과 QA가 길어지는 수도 있다. 해서 개발툴을 도입한다고 하는것은 완성도에 더 가까운 이야기지 개발기간과는 2차적인 이야기인것을 명심하기를 바란다.

둘째는 개발자들에게 하고 싶은 이야기...
모바일도 커질데로 커져서 현재 온라인에서 사용하는 공용 개발툴을 사용해도 큰 지장이 없다.
스크립트툴이야 사실 하나 만들어 놓고 그것을 프로젝트 할때마나 약간씩 변형하는 것은 인정하겠으나 맵툴이나 스프라이트툴, 이미지 압축툴, 텍스트 압축툴등 의 경우에는 쓸데없는 개발 일정 잡아먹지 말고 공개되어 있는 툴을 사용하는 것이 좋다고 권하고 싶다. 개발자들은 이래저래 이유대며 자기 프로젝트에는 이용을 못하니 개발을 반드시 해야한다고 하는데.. 고건... 욕심이다.

그러한 의미로 유용한 맵툴 하나를 소개하고자 한다. Mappy 라는 툴인데.. 벌써 1.4.11 버전까지 나왔다.

요넘을 좋아하는 이유는 레이어, 오브젝트와 같은 기본 맵툴 기능은 물론이거니와 쿼터뷰 맵에서 사용될 수 있는 다각형 맵타일까지 지원을 잘하고 있기 때문이다. 또한 오픈소스로 소스가 공개되어 있기 때문이다. DirectX를 사용하니 컴파일하기 위해서는 DirectX SDK가 필요하다.

어지간한 기능은 대부분 지원함으로 아주 특별한 Map 형태가 아니고서야 모바일 프로젝트를 진행하는데 있어서 부족함은 없으리라 생각된다.

메모리 절약등의 이유로 저장 포맷이 마음에 들지 않으면 저장 부분만 뜯어 고쳐서 사용하기를 바란다.

그리고 좀 사족같은 발언이기는 하지만 기획자들에게 하고 싶은 이야기는...
되도록이면 쿼터뷰 게임은 하지 않기를 바란다. 물론 좀더 비주얼쪽으로 강점을 가지는 것은 인정하겠으나 생각해야 할 것도 많아지고, 메모리 낭비도 무척이나 심해진다. 개발자는 사각형을 좋아한다~

KTF WIPI COD 컴파일 할때 가끔 실패가 되고 나서 삭제버튼이 생기지 않을 때가 있다.
이때는 아무리 기다려 봐야 자동으로 생성이 되지는 않으니 아래의 형식으로 wipiktf@magicn.com 으로 메일을 보내면 된다.

BREW에서 JPEG을 리사이징을 하려고 하는데 어케 할까 고민이다.

1. 가장 무식한 방법은 2.0부터는 JPEG 디코더를 자체 지원을 하니깐 IIMage 객체로 디스플레이 객체에 뿌린 다음에 IDISPLAY_GetDeviceBitmap를 이용하여 스크린 캡쳐(??)를 한다. 리턴된 IDB를 가지고 리사이징을 하고 다시 뿌려준다. 또는 IGRAPHICS_StretchBlt를 사용해서 뿌린다.

무식한만큼 간단한 방법이긴 하다만..
문제가 생긴다. 화면이 뿌린 이미지가 액정보다 클 때는 복잡해 진다.
게다가 IGRAPHICS_StretchBlt가 아직은 약간 불안정한 감이 없지 않아 있다.

아무래도 JPEG 디코더를 만들어야 할 것 같다.
슬슬 귀찮아 지고 있는 것이다. 만들때 만들더라도 어떻게 할까 고민이다.

2. JPEG 자체를 메모리에 올려서 JPEG이미지 정보로 리사이징을 하고 그 메모리 버퍼를 그대로 IImage 객체로 변환 후 뿌리는 방법
깔끔할 것 같지만 쉬어 보이진 않는다.

3. JPEG를 BMP로 디코딩 한 후에 그 메모리 버퍼를 이용해 리사이징을 시킨다. 새로 만들어진 버퍼를 가지고 CONVERTBMP를 불러서 IImage 객체를 만든다.

아무래도 3번이 제일 날 것 같다.
이미지 크기에 따라서 Heap에서 마구 Out of Memory를 부르겠지만 적당히 예외 처리를 하면 될 듯 하다. 자료가 많아서 그닥 어렵지는 않지만 꽤나 삽질을 해야 할 듯..
IImage에서 StretchBlt를 지원하면 좀 좋아?

누가 더 쉬운 방법 아는 사람이나 BREW용 JPEG Decoder 있는 사람??