우선 이번 호를 시작하기 전에 예정되어 있던 연재 목차의 순서가 내부 사정으로 인하여 변경되었음을 말씀드리고 이에 대한 양해를 구하는 바이다. X인터넷 개발방법은 제품에 따라 다소 차이가 있으나 현재 시장을 확장해 나가고 있는 X인터넷 제품은 오늘 소개할 구현 방법과 유사하다. 이번 호에서는 X인터넷 구현방법에 대하여 자사 X인터넷 제품인 마이플랫폼(MiPlatform)을 중심으로 설명하고자 한다. 본지 특성상 구현 소스 차원의 상세한 설명은 생략하고 개념 중심으로 설명을 풀어가고자 하나 엔지니어가 아닌 일반 독자가 이해하기에는 어려울 듯하다.
X인터넷으로 무엇을 만들어야 하는가?
X인터넷을 이미 접해보신 분들은 아시겠지만, 그렇지 않은 독자들은 X인터넷으로 뭔가를 구현하고자 할 때 무엇부터 시작하면 좋을지 당장은 막막한 생각이 들게 될 것이다.
X인터넷으로 만들고자 하는 것은 무엇일까? 결론부터 말하자면, ‘C/S(Client/ Server) 개발툴로 만든 것 같은 화면 XML File’ 즉, 프레젠테이션 유저 인터페이스(Presentation User Interface)이다.
X인터넷을 제외하고 현재 화면을 만들 수 있는 방법에는 대표적으로 C/S (파워빌더, 델파이 등)와 HTML(웹 화면) 및 자바 애플리케이션 등이 있다. 여기서 잠깐 기존의 방법들에 대해 살펴보자.
C/S의 경우 최종결과물은 ‘컴파일된 화면 Dll 파일’이다. Dll 파일은 서버에 상주한다고 해서 사용자 PC에서 동작되지 않는다. 즉, 사용자 PC에 설치되어 있어야 하는 것이다. 이는 자바 애플리케이션도 동일하다. 자바로 만든 화면 Class File은 사용자 PC에 설치되어 있어야 사용자가 볼 수 있다. 자바의 경우 C/S와 다른 점은 자바 버추얼 머신이 반드시 설치되어 있어야 한다는 점이 다르다.
반면, HTML의 경우 최종 결과물은 ‘화면 HTML File’이다. HTML 파일은 Interpreting 방식으로 처리되므로 사용자 PC에 설치될 필요가 없다. C/S에 비하여 기능이 떨어지는 HTML 파일(웹 화면)이 왜 폭발적으로 애용되게 되었을까? 필자의 견해로는 웹 브라우저외에는 PC에 설치하지 않아도 되는 것이 가장 큰 이유라고 생각된다. 수많은 웹 콘텐츠를 PC에 설치하고 봐야 한다면 이토록 많은 사람들이 웹을 선호하지 않았을 것이다.
그렇다면 X인터넷은 왜 ‘C/S로 만든 것 같은 화면 XML 파일’이 최종 결과물일까? 현재 많은 기업체들이 사내에서 사용하는 화면의 경우 기능과 속도 등의 이유로 C/S를 아직도 선호하고 있는 것으로 알고 있다. 설령 웹 기반의 시스템을 구축하였더라도 이미 많은 ActiveX, 자바 애플릿 등으로 C/S와 같은 유저 인터페이스를 구현하고 있다.
그러나, 사외용 고객 서비스 화면의 경우는 C/S로 만들지 않는다. 사용자에게 그 많은 화면(EXE, DLL)을 설치하라고 하면 거의 대부분이 중도에 설치를 포기하기 때문일 것이다. 즉, 많은 기업체들이 사내용, 사외용 이중으로 화면을 개발하고 있는 것이 현재 실정이다. 이는 업무의 차이보다는 개발방법 혹은 개발환경이 틀려 개발자에게 두 가지 시스템을 개발하고 관리하는 부담이 되고 있다.
필자를 포함한 많은 사람들은 이중화면 개발에 대한 부담을 떨쳐 버리고, 기능이나 속도는 C/S 같되 배포는 하지 않을 수 있는 화면을 만들고 싶어한다. 이를 충족할 수 있는 방법은 현재까지는 X인터넷을 제외하고는 없다.
바로 이 X인터넷의 화면이 ‘C/S로 만든 것 같은 화면 XML 파일’이다. 그런데 여기서 많은 분들이 필자에게 이런 질문을 한다. “다 좋은데 왜 HTML이 아니라 XML인가? XML로 하게 되면 기존의 HTML을 못쓴다는 문제가 생기게 되는데...?” 안타깝게도 HTML은 스펙 자체가 C/S 화면을 구현할 수 있을 만큼 다양한 기능을 지원하지 않는다. 때문에 현 스펙의 HTML을 수용하는 순간 C/S 기능을 화면에 구현하기가 힘들어지기 때문이다. 몇몇 HTML 기반의 X인터넷 개발툴이 얼마나 개발자를 고생시키고 있는지 알고 있다. 그리고 웹 서비스의 표준을 기억하는가? XML, SOAP, UDDI, WSDL... 또한 전호에 밝혔듯이 X인터넷은 웹이 아니다.
그리고 필자는 계속 화면과 프레젠테이션 계층 이야기를 계속하였다. 애플리케이션을 구현하기 위해서는 통상 논리적으로 3계층 구조를 가진다. Database Layer, Business Logic Layer, Presentation Layer가 그것인데, 대개의 X인터넷은 이중 Presentation Layer를 중점적으로 담당한다.
Business Logic 부문은 현재의 구조 및 자원을 거의 그대로 쓴다. 그래서 서버 독립적이란 용어를 쓰거나 레가시 시스템을 재활용한다고 기술하고 있다. X인터넷은 JSP, ASP, PHP, EJB 등의 다양한 Business Logic을 모두 연계, 지원하고 있으며 서버의 데이터를 PC에 가져오기 위해서 X인터넷 제품마다 각 제품이 이해할 수 있는 데이터 포맷으로 reformatting 하는 기능의 API, 엔진 혹은 서버 모듈 등의 형태로 제공하여 서버에 탑재하도록 하고 있다. MiPlatform과 같은 X인터넷 제품은 특히 Multi-tier를 지원하여 서버 및 PC/PDA의 DB를 연동하고 Business Logic, Presentation Logic을 서버, 클라이언트에 분배, 배치하도록 지원할 수 있다
사용자는 어떤 순서로 화면을 보게 되는가?
X인터넷 구현 방법에 대해 이야기하기에 앞서 사용자가 X인터넷으로 구현된 화면을 보게 되는 시스템 절차에 대해 먼저 언급해야 할 것 같다. 이 순서를 알아야 구체적으로 어떤 것을 만들어야 할지 이해 될 것이다. 간단한 순서에 대해 언급하고 각 부분별로 상세한 설명하기로 한다.
1. 사용자 PC/PDA에 전용 브라우저 및 UI 콤포넌트 설치
“화면 XML File”을 보기 위해서는 새로운 브라우저 혹은 뷰어가 필요하고 C/S 기능을 처리하기 위하여 각종 UI Component가 필요하므로 이를 설치해야 화면을 볼 수 있게 된다. 물론 과거 C/S처럼 화면단위로 매화면 정보를 컴파일하여 설치하는 것이 아니라 한번만 다운로드하면 된다. 화면의 표현은 서버에서 화면 속성 및 배치 정보를 다운로드 받아 그대로 표현하게 된다.
2. XML 화면처리용 브라우저 구동
사용자(혹은 자동으로)는 브라우저를 구동한다. 여기서 브라우저는 웹 브라우저가 아니다. 화면XML을 처리하기 위한 브라우저이다. 제품마다 뷰어, 플레이어, 버추얼 엔진이란 용어를 사용한다.
3. 환경(Configuration) 파일 로딩 및 브라우저 환경 세팅
이 부분은 MiPlatform 및 몇몇 제품에서 환경 설정 및 버전관리, 히스토리 관리를 위하여 서버에서 다운로딩 받게 된다. MiPlatform에서는 브라우저가 구동된 후 환경 파일을 로딩하도록 되어 있다. MiPlatform에서는 이를 Start XML이라고 부른다.
4. 화면 XML 로딩 및 화면 브라우징
화면 XML 파일을 브라우저가 로딩하여 XML을 사용자에게 보기 좋은 형태로 표현하게 된다.
5. 화면을 데이터와 연계하여 처리
예를 들어, 사용자가 화면에서 ‘조회’ 버튼을 누르면 DB에서 데이터를 가져와 화면상에 보여주게 된다. 이상이 전체적인 X인터넷 화면처리 순서가 된다. 이제 이에 대한 각 부분에 대하여 설명하고자 한다.
사용자 PC에 브라우저 및 콤포넌트 설치
제일 먼저 X인터넷 화면인 XML 파일을 보려면 먼저 사용자 PC에 브라우저와 각종 콤포넌트가 설치되어야 한다. 브라우저는 XML 파일을 Parsing 및 Browsing하기 위해 필요하다. 실제로 브라우저 및 콤포넌트는 각 X인터넷 솔루션 벤더에서 제공하게 된다. MiPlatform은 위 브라우저 및 콤포넌트를 EXE 형태로 브라우징하는 경우와 ActiveX 형태로 브라우징되는 경우 등 2가지 형태로 제공한다. 그렇다고 MiPlatform에서 2가지 형태에 대해 화면을 별도로 구현해야 하는 것은 아니니 걱정하지 않아도 된다.
EXE 형태로 브라우징한다는 뜻은 웹 브라우저 등과 관계없이 독립된 애플리케이션 형태로 브라우저가 구동되어 화면을 동작하게 됨을 의미한다. 반면 ActiveX 형태로 브라우징한다는 뜻은 웹 브라우저나 C/S 등의 기존 애플리케이션 화면 위에서 MiPlatform 화면이 동작된다는 것을 뜻한다. X인터넷 솔루션 벤더에 따라 2가지를 모두 제공하는 경우가 있고 ActiveX 형태만 제공되는 경우가 있다. 몇 제품은 자바 혹은 별도의 독자적인 플랫폼을 가진 제품도 있다.
혹자는 클라이언트 설치 문제와 관련해서 “브라우저와 콤포넌트를 설치하지 않고 화면을 볼 수 없는가?”라는 질문을 한다. 하지만, 이는 “HTML을 보고자 하는데 IE 브라우저를 설치하지 않고 볼 수 없는가?”라는 질문과 동일한 질문이기 때문에 불가능한 요구사항이다. 왜냐하면, 현재 우리가 제일 많이 사용하고 있는 MS IE 브라우저는 HTML에 대하여는 화면을 예쁘게 보여주지만 XML은 그냥 XML 원문자체를 보여주기만 한다. 이를 사용자에게 예쁘게 보여주려면 기본적인 브라우저와 콤포넌트는 설치되어야 하는 것이 당연하다.
또 다른 이는 C/S 또는 자바 애플리케이션의 화면배포 문제와 MiPlatform 설치를 혼동하여 질문을 하는 경우도 있다. C/S의 경우는 개발된 화면모두가 사용자 PC에 설치되어야 한다. 하지만, X인터넷이 지향하는 바는 이와 같이 개발된 각 화면을 사용자 PC에 설치되지 않는 것을 목표로 한다. 따라서, 기본적인 모듈인 브라우저 및 콤포넌트만 설치하고 화면은 웹의 HTML처럼 실시간으로 로딩되어야 한다. 즉, C/S의 경우는 원하는 모든 파일을 사용자 PC에 설치해야 하므로 사이즈가 큰 데 비해 X인터넷의 경우는 기본 모듈만 설치하면 되므로 사이즈가 적게 되는 것이다.
그림 3. X인터넷을 도입한 웹 트리이딩 시스템 (한국투자증권)
그림 4. 다양한 기기 및 외부 컴포넌트와의 연동이 가능한 eXtended Internet
또한, X인터넷 용어 중에 스마트 클라이언트(Smart Client)라는 용어가 있다. 웹 상에서 스마트 클라이언트에 대한 설명을 보면 추상적인 느낌이 강한데 이 스마트 클라이언트가 정확히 무엇인지 묻는 분이 많다. 정확한 표현은 아니겠지만 스마트 클라이언트는 기본적으로 사용자 PC에 설치되어야 하는 모듈, 즉 브라우저 및 콤포넌트라고 이해하면 쉬울 것 같다. 이제, 실제로 사용자 PC에 브라우저 및 콤포넌트를 설치하는 방법을 간략하게 소개하면 다음과 같다. ActiveX 형태로 사용할 경우는 CAB 파일만 설치하면 되므로 별도의 설명이 필요없을 것으로 생각하여 EXE 형태로 사용할 경우에 대하여만 설명하겠다. MiPlatform에서는 Updater라는 버전 관리 모듈을 제공한다. Flex 등 많은 X인터넷 제품들이 내부적으로 비슷한 기능을 내포하고 있다.
Updater의 동작원리를 상세히 살펴보면 다음과 같다. 먼저, ActiveX의 경우는 HTML에서, EXE 형태는 타 애플리케이션에서 Updater를 구동한다. Updater가 구동되면 먼저 Update XML을 웹서버로부터 수신하여 패치, 업그레이드할 파일 목록 및 정보를 확보하게 된다. 이 목록을 이용하여 클라이언트에 기설치된 정보와 다운로드 받은 목록에 기록된 정보를 비교하여 업그레이드 여부를 결정하게 된다.
이에 시스템 운영자는 사용자에게 MiPlatform 설치를 위해 HTML(ActiveX Updater구동용) 또는 애플리케이션(EXE 형태의 Updater 구동용) 및 Update XML을 제작해야 할 것이다.
XML 화면처리용 브라우저 구동
이 경우도 EXE 형태로 사용하는 경우와 ActiveX형태로 사용하는 경우에 대해 구분하여 설명한다. ActiveX 형태로 사용하는 경우에는 먼저 ActiveX를 구동하기 위한 HTML을 제작한다. 이 HTML에 브라우저 ActiveX를 올리고 최초 URL을 연결하여 주면 된다. 이후의 화면제어는 MiPlatform 브라우저에서 처리하게 된다.
주의할 점은 HTML은 단순히 ActiveX를 구동하는 용도이고 화면 브라우징은 MiPlatform 브라우저에서 처리된다는 것이다. EXE 형태로 사용하는 경우는 대부분의 프로젝트에서 Updater의 브라우저 구동기능을 직접 이용한다. Updater의 방법을 사용하거나 구동하고자 하는 애플리케이션에서 MiPlatform 브라우저 EXE 파일을 직접 호출하면 된다.
환경 파일 및 브라우저 환경 세팅
MiPlatform에서는 프로젝트 단위(애플리케이션 대그룹)로 환경을 구축한다. MiPlatform에서는 프로젝트의 모든 환경정보가 Start XML이라는 환경(Configuration) 파일에 담겨져 있다. MiPlatform 브라우저가 구동되면 최초에 이 Start XML 파일을 웹서버로부터 다운로드 받아 환경을 설정하고 화면을 로딩하도록 구성되어 있다.
Start XML은 MIPlatform에서 제공하는 PID(Presentation Interface De-veloper)를 이용하여 구현하며 Style, Domain 정보, 전역변수 등과 애플리케이션 그룹에 대한 정의 및 사용하게 될 콤포넌트, 통신용 어댑터, MDI 관련정보, 다국어 지원항목 등으로 구성되어 있다.
여기서 주목할 점은 MiPlatform의 경우 콤포넌트 및 통신용 어댑터를 Start XML 내에 기술하여야 한다는 것인데 이는 MiPlatform의 큰 장점이기도 하다. MiPlatform은 콤포넌트 및 통신용 어댑터를 MiPlatform에서 기본 제공하는 것을 사용하게 할 수도 있고 사용하지 않게 할 수도 있도록 설계되어 있다. 이는 기업에서 이미 사용중인 추가 콤포넌트나 별도 통신 프로토콜을 MiPlatform에 플러그인 방식으로 지원하게 된다.
화면 XML 로딩 및 화면 브라우징
화면 XML은 기존의 HTML구현처럼 일반 에디터를 사용하여 직접 편집 할 수도 있겠지만 대부분의 X인터넷 제품과 마찬가지로 MiPlatform은 화면 디자인 툴인 PID(Presentation Interface Developer)를 사용하여 구현하면 된다. 개발툴 UI도 일반적인 C/S 툴과 상당히 유사하며 개발방법 또한 C/S의 화면 개발방법과 상당히 유사하다. 필자가 여러 개발자에게 MiPlatform을 교육하여 본 결과 웹만 해보셨던 개발자들에 비해 C/S를 개발하셨던 분이 교육효과 및 달성도가 큰 이유이기도 하다.
일반적으로 화면제작 툴을 이용하여 화면을 구현하게 되면 다음과 같은 순서를 따르기 마련이다. 신규 화면의 생성, 화면에 콤포넌트 배치하기, 각 콤포넌트의 Property를 조정하여 예쁘게 만들기(예를 들어, 색깔이나 폰트의 조정 등)의 순서로 진행된다.
여기까지는 웹 화면이나 C/S화면이나 구현방법이 동일하며 MiPlatform 역시 동일하다.
그 다음으로 해야 할 것이 데이터를 다운로드하여 메모리에 저장한 데이터셋과 콤포넌트를 연동(Binding)하는 절차이다. 이 부분은 C/S의 구현 방법에서 일반적인 방법이며 많은 X인터넷 제품들이 데이터셋 바인딩(Binding) 방식을 제공하고 있으며 개발생산성 제고에 큰 도움이 되는 기능이다.
그림 5. MiPlatform 개발툴 PID(Presentation Interface Developer)
웹의 경우 화면 구현시 JSP나 ASP 등의 페이지 형태로 화면을 구현한다. JSP나 ASP로 HTML을 구현할 때 제일 불편한 사항은 결과 화면을 눈으로 직접 보지 않는 상태에서 단순 에디터로만 편집한다는 점이다. X인터넷 개발툴은 최종 출력형태를 확인하면서 개발이 가능하여 이 역시 개발생산성을 제고하는데 도움이 된다. 마지막으로 이렇게 만들어진 화면에 각 콤포넌트들의 이벤트에 원하는 로직을 구현하게 된다. 이와 같이 만들어진 화면 및 이벤트 처리 스크립트는 화면 XML 파일 형태로 저장하게 된다. 웹의 HTML 파일처럼 생각하면 이해가 쉬울 것이다. 단, C/S나 자바 애플리케이션처럼 컴파일을 하지는 않는다. 개발자 PC에서 만들어진 화면을 개발툴의 Deploy 기능을 이용하여 웹서버에 배포하여 놓으면 HTML을 웹 브라우저에서 보듯이 MiPlatform 브라우저에서 화면 XML을 볼 수 있게 된다.
그림 6. X인터넷을 도입한 기업은행 스마트 u뱅킹 사례(MiPlatform)
화면을 데이터와 연계하여 처리
먼저, 이 부분의 설명에 앞서 독자들에게 이런 질문을 하고 싶다. “C/S는 웹보다 빠르다. 왜일까?”
물론, C/S는 컴파일 방식이고 웹은 Interpreting 방식이기 때문에 C/S가 빠른 것은 당연하다. 그러나, 정작 이 질문의 중요한 요지는 웹화면에서 ‘조회’ 버튼을 누르면 화면이 리로딩되기 때문에 응답속도가 느려진다는 것이다.
C/S는 화면이 데이터 버퍼 콤포넌트(화면에 보이지 않는 데이터를 저장하는 콤포넌트)와 프레젠테이션 콤포넌트(데이터를 화면에 보이도록 하는 Grid, EditBox 등의 콤포넌트)로 분리하도록 되어 있는 반면 웹은 소스 페이지에 데이터 요소와 프레젠테이션 요소가 나누어져 있지 않다. C/S의 경우 대개 데이터만 처리하는 콤포넌트가 별도로 존재하며 프레젠테이션 콤포넌트는 바인딩이라는 기술을 사용하여 데이터를 사용자에게 보여지게 된다. 데이터는 데이터 버퍼 콤포넌트만 보유하게 된다.
즉, C/S는 화면의 변화없이 데이터만 서버의 DB 등으로부터 가져와서 데이터 버퍼 콤포넌트에 넣게 되는 것이다. 데이터만 변하게 되므로 화면의 리로딩이 없고 N/W 트래픽도 적어지고 응답속도도 빨라지게 되는 것이다. 이에 반해 웹은 HTML 자체가 데이터와 화면요소가 분리되지 않으므로 데이터가 변하면 HTML을 전부 다시 가져오게 된다. 따라서 N/W 트래픽도 많아지고 화면을 리로딩할 수밖에 없는 것이다. 많은 X인터넷 제품도 용어와는 무관하게 C/S와 유사한 방식을 따르고 있어 화면의 리로딩을 없애고 있다.
이외에 몇 가지 DB연동 및 통신 관련해서 기본적인 개념과 관련해서 뜻밖의 질문들을 정리하여 본다.
● N/W는 HTTP 프로토콜을 기본적으로 사용한다?
왜냐하면, 전호에서도 언급하였듯이 X인터넷은 웹이 아니다. N/W측면에서 보면 HTTP만 사용하는 것이 아니라 TCP/IP를 수용하여야 한다. 그러나 TCP/IP는 데이터의 Layout에 대한 규정이 없으므로 HTTP를 사용하게 된다. HTTP를 사용한다는 것은 웹서버를 사용한다는 뜻이다. 의외로 많은 분들이 웹서버를 왜 사용하는지 모른다. 웹서버는 HTTP 프로토콜을 처리하기 위한 통신 Daemon이다. 물론 보안시 HTTPS의 지원이나 웹 서비스시 SOAP 지원도 있다.
● 서버측에서 DB로부터 데이터를 어떻게 가져올까?
데이터는 웹의 애플리케이션인 JSP/ASP/PHP 등을 사용하면 된다. DB의 데이터를 처리하려면 File형태로 가져올 수는 없고 애플리케이션 형태가 되어야 함은 물론이고 웹서버를 사용하므로 JSP/ASP/PHP 등을 사용하게 되는 것은 너무나 당연하다. 물론, DB가 아니라 일반 레가시 시스템이어도 전혀 문제가 없다. 왜냐하면, 레가시 연계는 MiPlatform에서 처리하는 것이 아니라 WAS에서 이미 제공하고 있는 중요 기능이기 때문이다. 혹자는 MiPlatform의 서버측 라이브러리가 레가시와 연계되는 것으로 착각하시는 분도 있다. 하지만, 라이브러리가 레가시 연계를 지원한다면 오히려 기존의 시스템을 변경하는 일이 일어날 수도 있는 문제가 생기게 된다.
● JSP 등의 애플리케이션에서는 무엇을 하면 될까?
JSP 등의 애플리케이션에서는 웹서버로부터 전달된 XML 형태의 데이터를 DB에 넣거나 DB로부터 데이터를 추출하여 XML 형태로 웹서버에 전달하면 된다. 이러한 처리를 웹과 비교하여 설명하면 웹도 거의 동일한 처리를 하지만, 웹의 경우 JSP는 프레젠테이션 콤포넌트에 대한 처리(Table Tag 등의 처리)도 포함하지만 MiPlatform은 데이터만 처리하게 되는 점이 다르다. 웹을 구현해보신 분은 알겠지만 편집기로 화면요소를 제어한다는 것이 말처럼 쉽지만은 않다. 많은 분들이 MiPlatform을 사용하면서 JSP에서 화면을 뺀 데이터만 처리하게 되어 웹에 비해 많이 편하다는 말씀을 많이 한다. DB나 레가시와의 연계는 기존 웹에서 처리하던 것과 동일하게 사용하면 된다. JSP등에서 발생한 데이터는 XML 형태로 N/W으로 전송되어 MiPlatform 브라우저로 전달되며 이러한 XML의 내용은 해당 데이터셋의 내용물이 된다.
PDA에서 화면 보기
위에서 언급한 내용은 모두 PC를 기준으로 한 것이며 여기까지는 eXecutable Internet의 영역에 해당한다. 하지만, 위에서 언급한 화면을 PDA에서 보고 싶다면 어떻게 해야 할까?
즉, eXtended Internet으로 영역을 확장했을 경우의 구현방법에 대해 알아보자.
먼저, PDA라면 대표적인 PDA OS인 WinCE에서 동작되는 Smart Client(브라우저 및 콤포넌트)가 필요하다. 여기서, 이러한 의문이 생긴다. X인터넷에서 Extended Internet의 구현은 개발자의 몫인가? 솔루션 벤더의 몫인가?
이 질문에 대한 답은 “솔루션 벤더의 몫이다”가 답이다. 어떠한 기기나 OS에서 화면을 볼 수 있느냐 하는 문제는 솔루션 벤더가 제공하는 브라우저나 콤포넌트가 해당 OS를 지원하느냐 하는 것과 동일한 의미이다. 개발자는 해당 OS의 프로젝트시 겪었던 경험만 적용해서 화면을 재구성하기만 하면 된다.
PDA용 화면을 PC용 화면과 별개로 새로이 작성하는 것이 아니다. 실제로, MiPlatform의 경우는 PC에서 구동되던 화면 XML을 PDA(WinCE)에서 동작시킬 경우 별도로 제공되는 PDA용 MiPlatform 모듈을 사용하면 되고 기능의 차이는 거의 없다. 그렇다고 개발자가 PDA용 화면을 재개발하지는 않는다. PC용 화면을 가져다가 PDA용 화면 사이즈에 맞게 콤포넌트를 재배치하거나 리사이징 하기만 하면 된다. 이때, 개발자의 PDA에 대한 경험이 약간 필요하게 되는데, 예를 들어 이미지의 경우 PDA 무경험자라면 PC의 것을 그대로 쓰겠지만, 유경험자라면 중요치 않은 이미지는 화면에서 제거시킬 것이다.
왜냐하면, PDA에서는 통신요금이 유선과는 다르게 사용량당 요금이 부과되므로 요금을 줄이는 방안을 강구해야 한다는 것을 PDA 개발 유경험자는 알고 있기 때문이다.
