최근에는 애플리케이션 혹은 웹(Web)을 개발한다고 하면 기능과 화면을 직접 구현하는 경우보다 이미 잘 만들어진 컴포넌트를 재사용[1]하여 개발하는 방법이 증가하고 있다. 특히 thin-client인 모바일 프로그래밍에서는 화면구현에 많은 노력을 기울여야하는 특징으로 이 현상이 두드러지게 나타나고 있다. 이러한 현상과 맞물려 모바일용 오픈소스 컴포넌트의 성장은 주목할만 하다. 많은 개인 개발자들이 자신이 개발한 소스를 공개하는 경우 외에도, 기업 내부용 모바일 컴포넌트를 오픈소스로 공개하거나 상용 컴포넌트를 오픈소스로 제공하는 사례가 발견되고 있는 이유이다.

이같이 수많은 오픈소스 모바일 컴포넌트 가운데 개발하고자 하는 애플리케이션에 가장 적절한 컴포넌트를 선정하는 일은 매우 까다롭고 많은 시간을 요구한다[2]. 이 문제를 해결하고자 지금까지 선정절차와 평가기준을 마련하는 등의 많은 연구들이 있어왔다[3]. 기존 연구 가운데 오픈소스 프로젝트를 선하는 절차와 기준을 정립한 모델[4]와 오픈소스 컴포넌트의 선정절차를 제시한 연구[5], 그리고 상용 컴포넌트 선정 프로세스를 제시한 연구[6]을 참고할 수 있다. 그러나 첫 번째 모델은 프로젝트 단위의 선정절차로 그 범위가 상당히 커 모바일 컴포넌트를 선정하고자 하는 본 연구에 적용하기 어렵고, 두 번째 연구는 오픈소스 컴포넌트 가운데 UI 컴포넌트 위주의 모바일용 컴포넌트에 적용하기에는 모바일의 특성과 UI컴포넌트의 특성을 반영하지 못하는 한계가 있으며, 마지막 연구는 컴포넌트 특징이 잘 반영된 선정절차를 제시하였지만오픈소스 소프트웨어의 특징을 반영하지 못하는 한계가 있다.

본 연구에서는 기존 연구 중 Y.M Lee의 오픈소스 소프트웨어 선정절차[7]을 모바일 컴포넌트 선정에 적합하도록 수정, 보완하고자 한다.

B.D Kang이 제안하는 모바일 앱 개발모델[8]은 총 5가지의 단계를 이루고 있다.

‘요구사항 분석’단계에서 개발자는 모바일 앱의 기능과 목표를 사용자의 입장에서 정의한다. 이 때 개발자의 이해도에 따라 프로젝트의 성패가 좌우된다. 이후 적절한 아키텍처를 설계하는 ‘아키텍처 설계’단계를 지나 ‘내비게이션 설계’단계에서는 각 페이지간의 링크 관계 혹은 데이터 전송 등의 흐름을 정의하게 된다. ‘페이지 설계’단계는 UI를 설계하는 단계로 모든 페이지에 대해 스크린 레이아웃과 기능을 정의한다.마지막으로 ‘구현 및 테스팅’단계에서 실제 구현과 테스트하는 과정을 개발 프로세스를 제안하였다.

QSOS(Qualification and Selection of OpenSource software) 모델[9]는 오픈소스 소프트웨어 선정 절차와 평가기준을 제시하고 있으며 적절한 프로젝트를 선택할 때까지 총 4단계를 반복하여 실행한다.

정의(Definition)단계에서는 이후의 단계들에서 사용할 프레임을 농축, 정립하고 평가(Evaluation)에서는 소프트웨어를 기능적인 적용, 사용자관점의 위험, 서비스 제공자 관점의 위험 등 3가지 축에서 평가해 점수를 도출한다. 자격부여(Qualification)단계는 사용자의 컨텍스트에 따라 가중치를 부여하며, 요구사항이나 제약사항을 결정한다. 마지막 선택(Selection)단계에서는 최종선택하는 단계이다.

기존 오픈소스 컴포넌트 선정 절차에 관한 연구로는 J.B. Kim의 ‘오픈소스 컴포넌트 활용’[5]가 있다. 이 연구에서는 오픈소스 활용전략수립, 소요자원 산정, 라이선스 정책수립 후 수집, 배양, 개정의 오픈소스 선정과정을 거처 변경 명세화와 획득, 변경, 검증의 절차를 제시하였다.

상용컴포넌트 선정 프로세스에 관한 연구로는 K.S. Oh의 ‘상용컴포넌트 선정 프로세스 및 품질평가기법’[6]이 있으며, 품질명세화의 1단계, 평가 명세화의 2단계, 품질 특정의 3단계를 거처 컴포넌트 선정의 4단계를 제시하였다. 동시에 품질측정을 위한 테스팅 기법 및 기능성, 효율성, 사용성의 품질측정 기법을 제안하였다.

본 연구에서는 Y.M Lee의 ‘오픈소스 소프트웨어 선정 절차에 관한 연구’[7]에서 제시한 절차를 바탕으로 각 단계의 활동내용을 수정, 보완하고 J.B Kim의 ‘오픈소스 컴포넌트 활용’연구[4,10]에서 기반으로 한 마르미III 공정 모델[11]을 참조한다.

오픈소스 모바일 컴포넌트의 전체 선정 절차 과정은 아래 그림으로 표현할 수 있다.

먼저 개발계획이 세워지면, 개발하고자 하는 애플리케이션의 요구사항을 수집/식별하는 과정을 거친다[단계1]. 이 과정에서 요구사항을 반영한 기능중심적 키워드를 통해 1차 후보 OSS를 수집한다[단계2]. 1차 후보들 가운데 비기능적 요구사항을 만족하는 2차 후보OSS를 식별한다[단계3]. 식별된 OSS 컴포넌트을 대상으로 평가기준 수립 후, 프로토타입을 제작하여 최초요구사항을 기준으로 선정여부를 결정한다[단계4]. 각산출물을 비교, 분석하여 해당 컴포넌트를 선택할 것인지를 결정하고, 만약 후보 OSS 중 좋은 평가를 받은 컴포넌트 중에서도 적절한 컴포넌트가 없는 경우, 기능중심적 키워드를 통해 수집한 1차 후보 OSS 가운데 비기능적 조건을 수정하며 적절한 컴포넌트를 찾는 과정을순환적으로 진행한다.

각 단계의 세부 선정절차에 대한 내용은 다음과같다.

3.2.1. 요구사항 식별

개발 계획을 위해 요구사항 식별단계이다. 기존에 연구되었던 내용에 모바일 특성을 추가하여 모바일 애플리케이션 아키텍처를 설계한다.

모바일 애플리케이션 개발에서는 UI 구현시에 많은 시간과 노력을 필요로 하며, 완성된 결과물의 평가에도 큰 영향을 미치게 된다. 본 연구에서는 UI 설계시 더 많은 요구사항 수집 및 구현방식을 반영하기 위해 모바일앱 아키텍처를 설계하여 기능적 부분과 UI 부분을 나누어 설계하도록 하였다. UI/UX 설계는 별도로 설계서를 작성하여 추후 컴포넌트 후보군 선정이나 최종 결과물의 요구사항이 반영되었는지를 추적할 수 있도록 한다.

기존 연구에서 마르미III 4.0를 기반으로 제시하고 있는 산출물중 해당 단계에 필요한 입출력 양식은 다음 표1과 같다.

3.2.2. 1차 OSS 후보 식별

단계1을 거쳐 사용하고자 하는 모바일용 컴포넌트의 기능 키워드를 도출하면, 이 키워드로 오픈소스를 검색해 1차 후보군을 선정한다.

UI 구현에서 핵심적인 기능, 예를들면 Listview, imageview, gridview등 기능적인 특성을 반영한 키워드로 검색하여 사용이 가능한 후보들을 선정하게 되며 이는 비기능적 특성이 아닌 아키텍처와 UI/UX 구현에 기능적인 부분임이 다르다.

기존 연구에서는 단계2에서 개념모형을 작성하는데 본 연구에서는 1차 OSS후보군의 수가 상당히 많게 되고, 비기능적 특성을 통해 만족도가 높아지는 특성을 반영해 단계3에서 작성하는 것으로 수정하였다.

단계3에서는 비기능 검색키워드로 2차 후보군을 선정하게 된다. 일관된 UX를 지원하기 위한 기능이나 사용만족도를 높일 수 있는 기능들, 예를 들어 listview 후보군 중, swipe button을 지원하거나 slide loading이 가능하도록 하는 컴포넌트를 선정하기 위한 키워드를 이용할 수 있다.

기존 연구에서는 단계2에서 작성한 개념모형도를 단계3에서 정제/할당하게 되지만 본 연구에서는 2차 후보군만을 대상으로 개념모형도를 작성하도록 한다.

3.2.4. 평가기준 수립

컴포넌트들을 대상으로 프로토타입을 제작해 구현시 인터페이스 연결 수준을 추측하고 최초 계획한 애플리케이션 아키텍처 및 UI/UX설계도와의 비교를 통해 컴포넌트 활용정도를 확인할 수 있다.

오픈소스의 평가를 위해 산출물을 식별/정제하여 선정시 기준으로 삼는다. OSS산출물에는 라이선스정보, 시스템요구사항, 데이터정보 등의 소프트웨어에 대한 내용을 확인할 수 있는 항목들을 가진다.

3.2.5. OSS 평가 및 선정

마지막 단계5에서는 최종 선정의 단계이며, 이 단계에서도 적절한 컴포넌트를 선정하기 어렵다고 판단되면 단계3인 비기능 키워드를 수정하며 2차 후보군을 재선정하는 과정을 반복한다.

표 2에서 보는 바와 같이, 기존의 연구들에서 제시한 절차들은 각 단계를 거치면서 요구사항 정의 및 제한사항 정립 등 점차 오픈소스 프로젝트를 명확히 정의한 뒤, 최종단계에서 선택하고 있다. 그에 반해, 본 연구에서 제시한 절차는 각 단계별 기준에 따라 후보 컴포넌트를 제거하여 비교, 분석해야하는 컴포넌트의 양을 상당히 줄여 효율을 높였다.

또한, 선정 절차가 전체적으로 반복되어야 하는 기존연구에 비해, 본 연구는 비기능 요구사항만을 수정하여 반복수행하도록 설계해 비교적 짧은 반복주기를 가지고 있다.

본 연구는 기존에 연구된 오픈소스 소프트웨어 선정절차보다 반복 주기를 줄임으로서 비교적 빠르게 선정절차를 수행할 수 있다. 또 기존 연구를 모바일 컴포넌트 선정에 적합하도록 확장, 개정하여 요구사항에 적합한 모바일 UI 컴포넌트를 선정하면서도 효율적인 절차를 제시하였다.

본 연구의 결과는 모바일 UI컴포넌트 선정시 주먹구구식의 모호한 절차에서 벗어나 기능/비기능 검색어로 후보군을 이원화해 선정함으로써 일정수준 이상의 컴포넌트를 채택하여 요구사항을 더욱 정확히 반영한 컴포넌트 선정을 가능하게 하여 신뢰성과 생산성을 높여 줄 수 있다.

향후 연구에서는 제시한 절차를 활용해 개발 프로젝트를 수행하고 이 과정에서 각 단계별로 필요한 평가기준도 함께 제시하여 실제 사용이 가능한 모델로 정립하고자 한다.