본문 바로가기

2014
마이크로소프트웨어

글: 손영수 | balancer@nhnnext.org / 2014-04-10


안드로이드의 버전이 빠르게 업데이트되면서 소프트웨어의 크기가 커지고 복잡도가 증가했다. 또 다양한 제조사별 기기들이 쏟아지면서 안드로이드의 파편화 문제가 심화되기 시작했다. 잦은 업그레이드로 인해 불과 몇 년 사이에 5종 이상의 안드로이드 버젼이 생겨났고, 개발자들은 하나의 애플리케이션을 개발하기 위해 적어도 3종 이상의 기기에서 상호 호환성이 보장되지 않는 안드로이드 버전을 맞춰야 하는 불편함에 직면하게 됐다. 이러한 안드로이드의 문제점과 이를 해결하기 위한 오픈소스 라이브러리를 소개하고자 한다. 이 글은 2012년부터 시작한 NIPA 소프트웨어 공학센터의 모바일 참조 아키텍체 과제의 결과물로 제작된 것이며, 이번 시간에는 안드로이드 오픈소스 애플리케이션 블록을 소개하고 다음 시간부터는 오픈소스 라이브러리를 자세히 알아볼 것이다.



안드로이드 개발자들은 하나의 feature를 개발하고도 몇 개 이상의 버전에서 정상 작동 여부를 검증해야 한다. 이러한 테스트 활동은 그대로 개발기간에 반영돼 시장의 요구에 바로 대응해야 하는 부분에 있어서 불편함을 초래한다. 이는 하위 버전과의 완벽한 호환성을 보이는 애플의 iOS와 비교해 안드로이드가 가진 최대의 약점이라고 할 수 있다.


안드로이드 파편화
<그림 1>의 그래프는 안드로이드의 파편화 문제로 불편함을 겪었는지 설문조사한 결과다. 사용자의 14%를 제외한 대부분은 파편화 때문에 문제를 느끼는 것으로 나타났다. 많은 앱을 활용하지 않는 사용자들을 제외하고 어느 정도 활용법을 익힌 사용자들은 불편함을 겪었다고 답했다.


 안드로이드 플랫폼 파편화 불편함 설문조사

<그림 1> 안드로이드 플랫폼 파편화 불편함 설문조사


<그림 2>는 안드로이드 기기들의 해상도를 모두 표시한 것이다. 이를 통해 안드로이드 기반 기기들이 일정한 화면비를 따르지 않음은 물론이거니와 크기 또한 제각각이라는 사실을 알 수 있다. 안드로이드는 가장 표준화된 해상도인 800×480이나 HD 해상도를 제외한 다른 해상도의 스마트폰에서 다소 호환성 문제가 발생한다. 또 안드로이드에서는 iOS에서와 같은 해상도 증폭 기능을 사용할 수 없는데, 이러한 문제는 애플리케이션의 빈약함이 가장 큰 약점으로 지적되고 있는 안드로이드 태블릿의 문제점을 더욱 부각시키는 요소로 작용한다. 이와 같이 여러 가지 이유와 현상으로 판단하건데, 안드로이드에서의 파편화 현상은 개발자나 제조사뿐 아니라 사용자에게도 심각한 문제로 대두되고 있다.


 안드로이드 기기들의 해상도

<그림 2> 안드로이드 기기들의 해상도


그에 따라 많은 개발자와 개발사들은 파편화에 대응할 수 있도록 개발 소스를 매번 수정한 후 본인들의 개발에 적용하고 있다. 이는 개발 생산성이나 효율성에 있어서 심각한 감점 요소로 작용한다. 특히, 다양한 사업자 및 사용자를 대응하기 힘든 소규모 회사나 개발자들의 경우 이러한 현상이 더욱 심각하게 나타난다.


오픈 소스로서의 개방성 문제 : 폐쇄성


<그림 3> Open Governance Index

2011년 Vision mobile이 보고한 ‘오픈성을 측정하는 새로운 방법 : 오픈 거버넌스 지표(A new way of measuring Open ness, from Android to WebKit : The Open Governance Index)’에서 안드로이드는 가장 폐쇄적인 구조를 가진 오픈소스로 조사됐다. 개방성을 의미하는 Open Governance Index가 23%로 가장 낮은 점수를 나타냈다.
즉, 안드로이드는 오픈소스 소프트웨어 임에도 불구하고 폐쇄성이 강할 뿐 아니라, 구글이라는 특정한 회사에 의해 정책이 결정되는 특수한 커뮤니티 구조를 가지고 있다. 따라서 일반 개발자들이 안드로이드 오픈소스에 참여해 새로운 feature를 추가하기란 여간 어려운 게 아니다. 또 구글의 지속적인 정책 변화로 인해 안드로이드의 버전이 올라갈수록 점점 더 폐쇄적인 성향이 짙어지고 있다.


품질 속성 문제 : 사용성
안드로이드가 제공하는 기본 기능을 활용해 개발하려면 일반적으로 개발자나 사용자가 원하는 기능들을 넣기가 매우 까다롭다. 안드로이드는 구글이 주도하는 오픈소스 프로젝트인 관계로 대부분의 feature나 방향들이 구글에 의해 결정되고 유도된다. 즉, 일반적인 오픈소스 프로젝트처럼 개발자가 필요해 제안하는 feature나 사용성이 높은 기능들이 아무리 좋아도 구글의 방향이나 의도에 부합되지 않으면 받아들여지지 않을 가능성이 높다.


개발자가 원하거나 시장이 요구하는 기능임에도 불구하고 안드로이드 기본 기능에 포함돼 있지 않으면 사실상 구현하는 데 어려움이 많고 사용성이 저하된다. 또한 안드로이드에서 제공하는 기본 기능으로는 기획이나 디자이너로부터의 다양한 요구를 충족시키기 어려울 뿐 아니라 다수의 애플리케이션이 경쟁하는 안드로이드 시장에서 차별성을 가지기 위한 요소를 개발하는 데 어려움으로 작용한다. 이 때문에 안드로이드 개발에 대한 경험이 많지 않은 개발자들은 다양한 요구사항을 구현하기 위해 여러 번의 시행착오를 겪어야 하는 경우가 많다.


그래서 실제로 안드로이드에서는 구현하기 어려우나, 개발자들이 편하게 사용할 수 있는 feature나 기능들을 구현하기 위해 수많은 오픈소스 프로젝트가 안드로이드 네이티브(native)가 아닌 외부 프레임워크나 라이브러리를 활용해 개발, 제공되고 있다. 외부에서 제공되는 프레임워크나 라이브러리는 안드로이드 네이티브에서 제공할 수 없는 여러 가지 편의를 전달함으로써 개발 측면에서의 사용성과 효율성을 높이는 데 많은 도움을 준다.


품질 속성 문제 : 유지보수성
안드로이드 개발을 하다 보면, 개발이나 유지보수를 위해 수많은 백엔드 서비스(back-end service)를 편리하게 사용할 수 없는 문제를 경험하게 된다. 실제로 API가 없을 뿐만 아니라 아예 관련 기초 서비스가 없는 경우가 많다. 예를 들어, 앱 배포 후 유지보수나 서비스 향상을 위한 로그 분석을 위해 안드로이드에서 제공하는 로그 관련 서비스를 사용하게 되면, 오로지 개발 툴인 이클립스를 활용해 확인해야 한다.


즉, 앱을 배포한 후 유지보수를 위해 로그를 확인하고자 할 때 매번 이클립스가 연결된 상태에서만 확인할 수 있는 것이다. 개발 전체의 생명주기를 고려했을 때 반드시 필요한 백엔드 서비스들이 부족하다 보니 실무에서 많은 어려움을 겪게 되고 이러한 문제들이 전체적인 품질 속성 및 개발 생산성에 영향을 미치기도 한다.


아키텍처 설계 개선
이 글은 많은 개발자들과 오픈소스 커뮤니티가 검증한 오픈소스들을 가져와 개선, 수정, 리팩토링한 후 앞서 언급한 안드로이드의 문제점들(파편화, 폐쇄성, 사용성, 유지보수성)을 해결하고 개발 생산성을 향상시기키기 위한 목적으로 작성됐다. 더불어 이번 과제 수행을 통해 개선된 아키텍처와 소스 코드를 소개하고 공개, 배포함으로써 개발자들이 이를 쉽게 활용하고 더 나은 feature와 아키텍처를 만들어 건강한 생태계를 구축해 나가길 바란다.


안드로이드 애플리케이션 아키텍처(젤리빈 기준)

<그림 4> 안드로이드 애플리케이션 아키텍처(젤리빈 기준)


안드로이드의 애플리케이션 아키텍처(4.1 기준)는 <그림 4>와 같이 나뉜다. 커널 계층은 리눅스를 그대로 사용한 것이므로 실제 모바일 개발과는 연관성이 낮아 다루지 않기로 한다.


● Java 코어
오라클이 만든 공식 Java 라이브러리는 애플리케이션의 최하위 계층으로 사용되고 있다. 이것은 기존 Java 생태계를 잘 흡수하기 위한 포석으로 볼수 있다.


● Java 써드파티
Java 표준은 아니지만, 앱 개발 시 필요한 네트워크, XML 설정, 테스트 등의 라이브러리를 탑재했다.


● 안드로이드 플랫폼
구글이 개발한 계층으로, 안드로이드 앱 개발 시에 필요한 범용적인 컴포넌트들을 제공한다. 각각의 컴포넌트들은 다음과 같다.

- graphics : 그래픽 처리 중 저수준의 API를 제공(canvases, color filters, points, rectangles 등)
- animation : 애니메이션 처리를 쉽게 할 수 있는 기능을 제공
- view : 스크린에 표시될 레이아웃과 사용자가 상호 소통할 수 있는 화면 제공
- widget : 사용자 애플리케이션 내부에 사용될 UI의 기본적인 구성을 제공하고 사용자가 이를 변경할 수 있음
- preference : 사용자 애플리케이션에서 설정을 쉽게할 수 있는 기능과 UI 제공
- gesture : 제스쳐를 사용자가 정의할 수 있고 쉽게 사용할 수 있도록 화면을 제공
- support : API 버전 업에 따른 UI 관련 하위 호환성을 위한 기능 제공
- webkit : 웹브라우저와 관련된 다양한 기능을 제공
- speech : 말을 통해 입력하는 기능을 제공
- accounts : 안드로이드 내부의 계정관리 기능 제공
- location : 위치정보와 관련된 기능 제공
- media : 다양한 멀티미디어(오디오, 비디오) 관련 기능 제공
- renderscript : 3D나 수학적 수식을 고성능으로 처리하기 위한 저수준 API 제공
- opengl : OpenGL ES와 관련된 인터페이스 제공
- test : 안드로이드 테스트와 관련된 기능 제공
- database : 데이터베이스와 관련된 기능 제공
- net : 기본적인 자바의 java.net. API 대신 네트워크와 관련된 기능을 쉽게 사용할 수 있도록 제공
- security : 안드로이드 보안과 관련된 기능을 제공
- drm : 보편적으로 사용할 수 있는 DRM 관련 기능 제공
- sax : SAX 핸들러 기능 제공
- inputmethodservice : 입력기와 관련된 API 제공
- accessibilityservice : 접근성을 높일 수 있는 장치 개발에 필요한 API 제공
- os : OS(operating system)의 기본적인 서비스들과 내부 통신을 처리함
- app : 안드로이드 애플리케이션 모델을 추상화해 처리하고 관리함
- appwidget : 홈스크린에 표시되는 앱 위젯을 관리함
- util : 보편적으로 사용하는 유틸리티성 메소드를 제공(date/time, base64 en/decoders, XML 등)
- hardware : 하드웨어와 관련된 기능 제공(카메라, 센서 등)
- bluetooth : 블루투스 기능 제공
- nfc : NFC(Near Field Communication) 기능 제공
- telephony : 휴대전화 시스템의 기본적인 상태를 모니터링할 수 있도록 제공(통신사, 전화번호, 전화 가능 여부 등)


● 구글 서비스
안드로이드 표준 라이브러리는 아니지만, 앱 마켓을 이용하거나 결제할 때 필요한 헬퍼 성격의 라이브러리들을 별도로 제공한다.
- GCM(Google Cloud Messaging) : 사용자의 안드로이드 단말기와 서비스 개발사가 구축한 서버간의 메세지를 주고 받을 수 있는 서비스다(푸시).
- Google Play In-app Billing : 구글 플레이(마켓) 서비스이며, 애플리케이션 내부에 있는 디지털 컨텐츠를 판매할 수 있는 시스템이다. 다양한 컨텐츠를 판매할 수 있다(미디어 파일, 사진, 가상 게임 포인트, 레벨, 프리미엄 기능 등).
- Google Analytics : 애플리케이션 내부에서 생성되는 데이터를 쉽게 수집할 수 있도록 만든 시스템이며, 웹애플리케이션에서 사용하는 구글 분석 서비스를 안드로이드에서도 사용할 수 있다.


안드로이드 오픈소스 애플리케이션 블록의 전체 아키텍처
이 글에서 제공하는 모바일 애플리케이션 모바일 블럭의 아키텍처는 6개의 계층으로 구성된다. 선정한 6개 계층은 UI (User Interface), 네트워크, 공용부(Common), 서비스로서의 백엔드(BaaS), Testing, Release Engineering이다. 이를 선정한 이유는 UI, 네트워크, 공용부, 서비스로서의 백엔드가 모바일 애플리케이션 개발에 많은 비용을 초래하며, 이 비용을 효율적으로 줄이기 위해 Testing과 Release Engineering이 필요하기 때문이다.


<그림 5> 안드로이드 오픈소스 애플리케이션 블록


● UI
안드로이드의 화면 단편화 및 버전 단편화로 인해 버전별로 제공할 수 있는 Widget 함수와 기능들이 상이하다. 액션바의 경우 3.X 버전 때부터 안드로이드에 추가됐지만, 2.X 버전의 사용자가 전체 안드로이드 폰 사용자의 40% 이상이므로 실제 배포되는 앱에는 적용할 수 없다. 또한 안드로이드는 커스텀 유저 인터페이스 컴포넌트를 만드는 데 많은 비용이 발생한다.


● 네트워크
독립형 애플리케이션보다 네트워크 기능을 제공하는 애플리케이션의 중요성이(앱 내부 결제나 소셜 서비스의 연동) 갈수록 높아지고 있다. 2012년 Distimo의 조사에 따르면, 네트워크 기반 애플리케이션의 매출이 전체 앱 시장의 72%를 차지한다. 하지만 안드로이드가 제공하는 네트워크 기능은 단순해서 애플리케이션 구축 시 많은 비용이 발생하는 영역이다.


● 공용부
안드로이드는 구글의 폐쇄적인 정책으로 인해 시장의 요구를 재빨리 반영하지 못하고 있다. 이런 이유로 애플리케이션에 필요한 로깅, 결제 모듈, 컴포넌트 설정부 등을 별도로 제공하지 않는다.


● 서비스로서의 백엔드
모바일 앱을 개발할 때 구글이 제공하는 백엔드 기능(푸시, 사용자 통계, 오류 리포트)은 품질이 떨어진다. 푸시 서비스의 경우 지연이나 손실이 발생하고, 에러 리포트 기능은 제한적인 정보만 제공한다. 그 때문에 모바일 개발에 필요한 백엔드 서비스를 직접 구축해야 하는 문제가 발생한다.


● Testing
안드로이드는 운영체제, 디바이스, 화면 단편화에 대응하는 Testing 기법을 제공하지 않는다. 이에 테스트 자동화가 불가능한 상황이다.


● Release Engineering
앱 마켓마다 상이한 결제 모듈, 다양한 오픈소스를 활용해야 하지만, 이것들을 관리하거나 지원하는 방법이 존재하지 않아 마켓별로 라이브러리를 수동으로 바꾸고 일일이 빌드하는 일이 허다하다.



/필/자/소/개/

손영수 balancer@nhnnext.org | NHN NEXT에서 교수로 재직 중이며 소프트웨어 아키텍팅, 오픈소스 엔지니어링에 주력하고 있다. 국내 몇 안 되는 패턴 저자이며, 소프트웨어 아키텍트들의 모임인 ‘Hillside Group’의 이사회 위원이다. 최근에는 스타트업을 돕기 위해 여기저기 뛰어다니고 있으며, 스타트업을 위한 개발 에셋들을 차곡차곡 모으고 있다.

● 기획·정리 | 서준석 기자 seojs@imaso.co.kr




※ 본 내용은 (주)마소인터렉티브(http://www.imaso.co.kr/)의 저작권 동의에 의해 공유되고 있습니다.
    Copyright ⓒ Maso Interactive Corp. 무단전재 및 재배포 금지

    [원문출처 : http://www.imaso.co.kr/news/article_view.php?article_idx=20140410113426]

맨 위로
맨 위로