<월드리포트>모바일 애플리케이션 개발

　세계적으로 많은 업체들이 모바일 애플리케이션 시제품을 내놓고 있다. 이 시장 성장 속도를 감안해 볼 때 2001년 후반기가 되면 유럽과 미국의 많은 업체들이 시제품 단계를 넘어 상용화 단계로 진입할 것으로 보인다. 최근 미국 IT기술 자문업체인 기가인포메이션그룹(Giga Information Group)은 한 조사보고서는 모바일 제품 개발시 발생할 수 있는 문제점을 해결해 위험을 최소화하고 시제품 개발기간을 효율화할 수 있는 방법과 해결책을 제시했다. 다음은 이 보고서의 요약이다.

　

　기가인포메이션그룹이 2000년 말부터 2001년 초까지 수행한 조사에 따르면 대부분의 업체, 특히 미국 업체들은 아직 무선 애플리케이션 개발을 시작조차 않은 것으로 나타났다. 이 분야에서 미국보다 더 발전돼 있는 유럽조차 시제품, 혹은 초기 모바일 및 무선 애플리케이션 개발 단계를 넘어서 실제 서비스를 제공하는 업체는 거의 없는 실정이다.

　기술 개발 업체들은 문제의 소지가 있는 부분을 초기에 해결함으로써 위험을 최소화할 필요가 있다. 위험을 최소화하고 시제품 개발 기간을 효율화하기 위한 세 가지 요소는 △개발 기술 △서버 리소스 △테스트 대상 기기의 조심스러운 운영 등이다. 가장 이상적인 상황에서라면 이 세 가지 분야는 독립적으로 다룰 수 있다. 하지만 현실적으로 이 세 가지는 서로 밀접하게 연관되어 있고 성공적인 시제품 기간을 갖기 위한 방법은 이 세 가지 영역을 최대한 분리시키는 것이다.

　◇개발 기술=모바일 개발 기술을 확보하려면 신 클라이언트(thin client) 애플리케이션이나 리치 클라이언트(rich client) 애플리케이션 모두 기존 개발인력이 필요하다. 대개 신 클라이언트 아키텍처가 리치 클라이언트 아키텍처보다 전환이 용이하다. 특히 대부분의 HTML 전문 개발자들은 기술적으로 큰 어려움 없이 신 클라이언트로 전환할 수 있을 것으로 보인다. 하지만 설계의 어려움이 프로그램의 어려움보다 더 클 것으로 예상된다.

　업체들은 HTML 및 기타 다른 기술에 대한 경험 수준에 따라 컨설팅을 의뢰하거나 외부 전문가를 영구적으로 영입해 기술 습득 속도를 높여야 한다.

　목표 기기에 따라 시제품은 HTML의 하위집합을 사용하는 애플리케이션, 예를 들어 마이크로소프트의 포켓 인터넷 익스플로러(Pocket Internet Explorer)나 아방고(AvantGo) 같이 비교적 단순한 형태로 개발될 수도 있지만 WML(Wireless Markup Language) 및 관련 WML 스크립트를 이용할 경우에는 어려움을 겪을 수도 있다.

　WML의 경우 개발이 무난하지만 WML의 프로그래밍 모델은 HTML 모델과 개념이 다르다. 특정 마크업 언어(markup language)를 특정 기기에 대해 직접 코딩하는 것은 1∼2개의 기기에 대해 시제품을 신속하게 창출하고 관련 지식을 개발하는 방법으로 효과적일 수 있다.

　리치 클라이언트의 경우 타깃 플랫폼에 따라 기술 개발과정이 좀 더 복잡하다. 윈도CE 기기를 이용한 프로그램의 경우 노련한 윈도 개발자에게 비교적 쉽다. 하지만 이는 시스템 수준의 코딩이 필요없는 애플리케이션에 제한된다. 팜OS의 경우 운영시스템과 API는 복잡하지 않다. 하지만 세부적으로 들어가면 개발자가 익숙해 있는 운영시스템과는 다른 점이 많다. 팜 OS 애플리케이션 대부분은 아직도 C++로 작성되고 있으며 일부는 퓨마테크 새털라이트 폼즈(PumaTech Satellite Forms)나 펜라이트 모바일 빌더(PenRight Mobile Builder) 같은 RAD(Rapid Application Development)로 개발되고 있다.

　이 도구들은 다른 RAD 도구에 익숙한 개발자들이 이용하기 쉽지만 다른 제품 및 OS와 호환되지 않을 수 있다는 점에 유의해야 한다. 비주얼 베이직(Visual Basic) 기술을 보유한 업체들이 만약 팜을 노린다면 앱포지(AppForge)를 고려해 봄직하다. 하지만 이 기술은 아직 검증되지 않은 기술이라는 점을 명심해야 한다. 자바는 팜 개발을 위한 현실적인 대안이 될 수 있지만 자바의 이용은 2002년 초가 되어야 가능할 것이다. 자바 개발자에게 J2SE(Java 2 Standard Edition)에서 J2ME(Java 2 Micro Edition)으로의 이전은 데스크톱 버전의 윈도에서 윈도CE로 이전하는 것에 비유할 수 있을 것이다.

　여느 신기술과 마찬가지로 컨설팅회사의 전문가나 시스템통합자를 이용하는 것도 가치 있는 일이다. 만약 이런 방식을 선택했다면 무선 개발에 있어 다음과 같은 두 가지 실사조사가 중요하다.

　첫째 애플리케이션 개발 업체는 시스템통합자가 프로젝트에 배치한 프로젝트담당자를 면밀히 조사해 이들이 판매 기간 중 소개된 직원(최소한 동등한 기술과 경험을 가진 직원)과 동일한 사람인지를 확인해야 한다. 해당 프로젝트가 시스템 인터그레이터에게 학습기회를 제공하는 것이 돼서는 안되기 때문이다.

　둘째 기술 이전이 확실하게 이뤄지도록 한다. 시스템통합자가 개발 업체를 위해 이런 일을 해 줄 것으로 기대해서는 안된다.

　◇서버 리소스=무선 신 클라이언트를 위한 서버 및 게이트웨이를 선택할 경우 선택한 제품이 비호환 기종이 될 수 있는 위험이 따른다. 무선 애플리케이션 서버는 애플리케이션 서버의 일부(서블릿 기반의 프레임워크)로서 혹은 애플리케이션 서버 벤더가 제공하는 무선 버전 및 옵션으로서 별도로 판매될 수도 있다. 예를 들면 WAP폰용 WAP 게이트웨이나 음성 기기를 위한 VoxML 게이트웨이.

　네트워크가 이 프로토콜을 사용할 수 있다면 일부 PDA는 HTTP 서버만 있으면 충분할 것이다. 만약 프로토콜을 사용하지 못한다면 네트워크에 연결되는 게이트웨이가 필요하게 될 것이다. 일부 사업자의 게이트웨이는 추가 마크업 번역이나 필터링을 방해한다는 것도 주의해야 한다. 예를 들어 스프린트(Sprint) PCS는 미국에서 오픈웨이브(OpenWave) WAP폰을 초기에 채택한 업체였다. 따라서 이 전화기를 사용하는 대부분의 사용자들은 WML의 이전 언어인 HDML을 지원하는 전화기를 갖고 있는 반면 다른 사용자들은 WML과 HDML 모두를 지원하는 브라우저를 갖고 있다. 이런 문제를 해결하기 위해 스프린트 PCS의 오픈웨이브 게이트웨이는 WML 콘텐츠를 HDML로 변환해준다. 향후 사용자들이 WML폰으로 이전하고 게이트웨이가 업그레이드되면 HDML 콘텐츠를 WML로 변환해줄 것이다.

　하지만 사용자에게 인지되지 않는 이런 번역 과정은 때로 예상치 못한 부작용을 낳을 수 있다.

　시장에 나온 대부분의 무선 애플리케이션 서버는 중간 마크업 언어를 작성해 작동한다. 이 언어는 각 기기가 이해할 수 있는 최종 마크업 언어(WML, HTML)로 번역된다. 최소한 이 언어는 어떤 형태로든 XML을 이용해야 한다. 하지만 XML만을 사용하면 개발된 애플리케이션이 호환이 불가능한 경우가 될 수도 있다. 여기에는 두 가지 이유가 있다.

　첫째 벤더들 사이에 공유되는 추상적 크로스 디바이스 사용자 인터페이스를 나타내기 위한 단일 표준(예를 들면 XML태그 집합)이 없기 때문에 어떤 벤더의 중간 XML을 받아 다른 벤더의 중간 XML로 직접 태그 대 태그로 번역할 수 있다는 보장이 없다.

　지금과 같은 초기 시장에서는 여러 벤더들의 중간 언어는 서로 상당 부분 다를 수도 있다.

　둘째 XML은 자체적으로 완전한 사용자 인터페이스를 구축할 수 없다는 점에서 불투명 하다. 즉 XML은 ‘Y기기의 파라미터를 사용하여 X스크린을 생성하라’ 같은 명령으로 사용될 수 있다는 것이다.

　여기서 X스크린 Y기기는 열려있지 않는 테이블이나 포맷에서 외부적으로 정의된다. 아니면 테이블의 공개돼 있어 읽기가 가능하지만 중간 XML이나 외부 테이블에서 최종 마크업을 생성하는 과정은 런타임 엔진의 ‘블랙박스’ 코드 내에 숨길 수 있다.

　이런 점을 감안해 볼 때 심지어 중간 XML 및 테이블을 마음대로 이용할 수 있는 개발자도 항상 최종 마크업 언어를 추론하지는 못한다.

　학습 및 시제품을 개발하는 도중 시제품 개발을 위해 선택한 서버가 서비스에 적합하지 않다는 결과를 얻을 수도 있다. 가능한 한 공개돼 있고 표준 기술에 기반한 환경을 선택함으로써 손실을 최소화할 수 있다. 그러나 무선 애플리케이션 서버 사이에 높은 이식성을 제공하는 기술로서 J2EE에 비할 수 있는 것은 현재 존재하지 않는다.

　◇테스트 기기=오늘날 시장에 출시된 많은 기기에 대한 시험에 있어 적합한 기기를 어떻게 구하는가가 가장 큰 문제일 것이다. 기기 자체를 구하는 것도 문제이지만 그뿐 아니라 기기는 네트워크에도 연결될 수 있어야 한다. 또 대부분의 경우 음성 계약만 했기 때문에 데이터 액세스가 포함돼 있지 않은 것도 문제가 될 수 있다. 실제 기기에 대한 시험을 하기 위해서는 다음과 같은 조건이 만족되어야 한다.

　첫째 개발자가 시험하고 콘텐츠를 볼 수 있는 하나의 기기가 있어야 한다.

　둘째 다양한 포맷과 브라우저에 걸쳐 콘텐츠를 테스트하기 위한 소수의 기기가 필요하다.

　셋째 시험 도입을 위한 소수의 단일 기종 기기 혹은 여러 기종의 기기들이 요구된다.

　처음 조건의 경우, 특히 현재 출시된 기기의 경우 이를 구입하고 관련 서비스에 가입하는 것보다 더 좋은 방법은 없다. 기기 가격은 수백달러면 될 것이고 무선이용료 또한 1개월에 수십달러면 충분하다. 그러나 이런 접근 방식은 많은 기기에 대해 시험하거나 다양한 종류의 기기를 시험할 경우 적합하지 않다. 비용이 금방 수천달러에 이르게 될 것이기 때문이다.

　특히 WAP폰과 PDA용 WAP 브라우저 같은 경우가 이에 해당된다. 비용과 관리상의 어려움을 최소화하기 위해 소수의 대표적인 전화에 대해서만 테스트하는 것이 바람직할 수도 있다. 대표적인 테스트용 전화기는 WAP 브라우저(오픈웨이브와 노키아)나 PDA 브라우저(프로젝트에 적합한 브라우저)가 될 수 있을 것이다. 자동화된 테스트 도구는 사용상의 차이점을 밝히는 작업을 단순하게 만들어 준다. 시험 도입이 시작되면 더 많은 기기를 테스트해야 할 지도 모른다. 제조업체나 네트워크 사업자가 시제품 개발을 위해 기기를 내놓도록 설득할 수도 있겠지만 이 방식이 성공했던 경우는 거의 없었다.

　중요한 것은 기기 제공업체와 긴밀한 사업관계를 유지하는 것이다. 기기 제조업체나 네트워크 사업자로부터 기기를 대여 받을 수 있는 가장 좋은 접근 방법은 RFP 과정을 통하는 것이다. RFP는 예상 목표를 제시하는 시험의 목적, 제품 발표의 규모를 포함해야 한다. RFP에서 제의한 계획은 차질없이 수행해야 하며 장비의 반환도 확실히 이뤄져야 한다.

　<정리=방은주기자 ejbang@etnews.co.kr>