Smart Phone에서 Efficient한 Smart Apps 개발을 위한 가이드라인 part 2.

이번 포스팅에서는 GSMA의 App. Efficiency TF에서 작성한 문서( Smarter Apps for Smarter Phones )를 참고하여, 모바일 App. 개발 시에 도움이 될 수 있는 Application efficiency 관련 핵심 내용을 선별하여 번역/소개하려고 합니다. guideline 문서 전체를 번역하여 올려드리는 것이라, 조금 딱딱한 말투라고 느껴지실수도 있을것 같네요^^

연관된 포스팅 ( Smart Apps 개발을 위한 가이드라인 개요) 내용에서 조금 더 구체적으로 기술 내용 올려드립니다. 일부 그림설명이 동일하게 쓰인 부분도 있습니다. 참고해주세요~.

1. Introduction

1.1 Scope

본 포스트 내용은 상위 레벨의 개발 방법론에 집중하고 있다. 각 OS별 세부적인 개발에 대해서는 위에 링크된 원문( Smarter Apps for Smarter Phones )의 “3. Detailed Recommendation “(실제 Mobile OS별 개발 예 제시)을 참고하도록 한다.

1.2 See Also

GSMA의 원본 문서와는 별도로, Google I/O 2012 발표 세션 중 하나인 Making Good Apps Great: More Advanced Topics for Expert Android Developers 세션 동영상도 참고하도록 한다. GSMA 문서와 내용과 거의 유사하지만, 직접 개발자가 설명을 진행하기 때문에 이해하기가 좀 더 용이할 수 있다.

2. Network Friendliness

최근 모바일 App.은 대부분 네트워크를 사용하는 형태로 개발되고 있다. 문제는 모바일 네트워크(3G/4G/WiFi/Bluetooth 등) 자체가 1) Unreliable하고, 2) 단말의 모든 Peripheral 중 가장 속도가 느린 인터페이스라는 것이다. 이러한 이유 때문에, 모바일 App.들이 모바일 네트워크 관리를 잘못하게 되면 , 해당 App.의 성능(UX, Data Processing)이나 단말 전체 성능(Battery, UX-lock)에 지대한 영향을 미치게 된다. 이에, 이번 절에서는 개발자가 모바일 디바이스에서 모바일 네트워크를 핸들링 할 때 어떠한 점에 유의를 해야 하고, 모바일 App. 및 모바일 디바이스 성능을 더 올려줄 수 있는 방법이 무엇인지에 대해서 알아 보도록 한다.

2.1 Requirements and constraints in mobile broadband

모바일 네트워크에서 가장 문제가 되는 이슈 사항은 아래와 같다.

  • 제한된 Bandwidth
    • 여하튼 느리다. 이론적으로 존재하는 최대 속도를 사용자는 사실 거의 경험 할 수 없다.
  • 다양한 데이터 요금제(3G/4G)
    • WiFi는 그나마 다행인데, 3G/4G와 같은 Carrier Network은 무료가 아니다. 네트워크 된다고 막 쓰면 안된다.
  • 배터리
    • 모바일 네트워크는 배터리 먹는 귀신이다. 네트워크 이외에도 다양한 색상을 이용하는 UI나 빠른 화면 전환은 배터리를 야금야금 갉아 먹는다.
  • Non-reliable Network Connection
    • 네트워크 연결이 언제나 되는 것도 아니고, 연결이 되었다 하더라도 언제나 끊어질 수 있다. 게다가 QoS도 계속 변한다.
  • 보안
    • 기본적으로 모바일 네트워크는 보안적으로 안전하지 않다. 인증이나 개인 데이터를 그냥 HTTP나 Plain Socket으로 전송하는 것은 절대 피해야 한다.

모바일 네트워크가 위와 같은 다양한 이슈를 가지고 있다는 것을 마음 깊이 새기고, 이제 이와 같은 제약 사항들 하에서 좀 더 나은 UX 및 효율적인 단말 자원 관리를 위해 어떠한 개발 방법들을 채택해야 하는지 하나씩 알아보도록 한다.

2.2 Smooth user experience

모바일 네트워크가 UX에 영향 끼치는 사항은 다음 두 가지이다. 너무 느리다는 것과 자주 끊어진다는 것. 이를 해결하기 위해서, 1) Async하면서 Parallel한 방법으로 데이터를 로딩해야 하고, 2) 모바일 네트워크 때문에 사용자 UI가 Lock되지 않도록 해야 하며, 3) Off-fline이 되었을 경우에도 사용자에게 뭔가를 보여줄 수 있도록 해야 하고, 4) 접속한 네트워크 연결 Quality에 따라 데이터 량을 조절하던가, 사용자에게 적절한 알림을 줘야 한다.

사실 1, 2번은 실제 개발에서 많이 적용되는 예이지만, 3번과 4번은 세심한 기획 및 관심이 없으면 구현하기 쉽지 않다. 특히 3번의 경우, 모바일 App. 내부에서 별도로 데이터 Cache를 관리해야 하기 때문에, App.의 복잡도를 매우 증가시킨다. 따라서 3번 내용의 경우에는 무조건 적용하기 보다는 프로젝트 일정 및 요구 사항을 면밀히 살펴서 꼭 필요한 경우에 적용하는 것이 합리적일 듯 하다.

다음은 앞에서 간략히 설명한 4가지 해결 방안에 대한 세부 설명이다.

2.2.1 Asynchrony

모바일 네트워크에서의 Asynchrony를 한 마디로 정리하면, “네트워크로 원격지에서 리소스 로딩할 때는 Serial하게 하지 말고, Parallel하게 하라”이다.

위 그림에 보는 바와 같이 News feed에 링크된 이미지들을 순차적으로 읽어 들이면 네트워크 속도가 bottle-neck이 되어서 전체 UX 성능이 저하되니, 아래 그림과 같이 각 리소스를 동시에 읽어 들여 사용자에게 Blank page가 보이지 않도록 하라는 것이다. 특히 이때 주의할 점은 원격지의 데이터 로딩을 기다리면서 UX가 lock되지 않도록 주의해야 한다는 것이다.

리소스를 동시에 읽어 들이면서 UX가 Lock되지 않도록 하는 방법은 1) Multi-thread 를 이용하는 방법과 2) Aysnc Network API를 이용하는 방법이 있다. 단말 OS에 따라서 어떤 방법을 사용할지 선택할 수 있지만, 가능하다면 2번 방법(Async Network API)를 이용하기를 권장한다. Multi-thread의 경우, 많이 사용하면 전체 단말 성능을 저하시킬 수 있고, 그 특성 상 잠재적으로 에러가 발생할 확률이 더 높기 때문이다.

만약 Multi-thread를 이용하게 된다면, Main Thread(또는 UI Thread)와 Network Thread를 분리하여 개발하도록 신경 써야 한다. 특히 안드로이드의 경우는 Main Thread가 UI Thread이므로, Multi-thread를 이용하여 네트워크로 리소스를 로딩하는 경우 이를 별도 Thread/Task로 분리하는 것이 바람직하다.

추가로, 위 그림과 같이 Async하게 원격 데이터를 로딩하는 경우는, 로딩과 동시에 그 진행 과정을 Progressive bar 등을 통해서 사용자에게 알려주는 것이 좋다.

2.2.2 Non-blocking user interface

앞의 예와는 다르게, 원격지에서 데이터 로딩이 완전히 끝나야 사용자 이용이 가능한 경우, 이를 Blocking UI라고 하며, 이 경우라도 위 그림 좌측과 같이 아예 UI 전체를 막지 말고, 되도록이면 우측 그림과 같이 로딩 중에도 일부 사용자 Interaction이 가능하고, 사용자가 UI를 전반적으로 살펴볼 수 있도록 구현한다.

또한 Blocking UI 시나리오에서 User-driven activity와 App-driven activity에 따라 그 처리 방법을 구분하는 것이 좋다. 예를 들어, 특정 웹 페이지 로딩을 사용자가 명시적으로 요청한 경우(User-driven), 네트워크 연결이 안되면 팝업을 통해 사용자에게 직접적으로 알려주는 것이 적합하나, 웹 페이지의 특정 이미지 로딩 등 일부 리소스 로딩이 실패했을 경우(App-driven)에는 해당 이미지 위치에 다른 placeholder를 배치하는 정도로 에러 처리하는 것이 올바른 Blocking UI 처리 방법이라고 할 수 있다.

간단히 정리하자면, 사용자가 직접 요청한 주요한 요청에 대한 에러 알람은 팝업 등을 통해 명확히 사용자에게 알려줘야 하지만, 그렇지 않은 Minor한 에러 처리는 사용자 Interaction 및 awareness를 최소화해서 처리하는 것이 바람직하다는 것이다.

2.2.3 Offline mode

Offline mode 처리에서 중요한 사항은 다음 두 가지이다.

  • 사용자 데이터 Post 중에 네트워크 에러 발생
    • 일단 사용자가 입력한 정보 및 App. Context 정보는 유지 되어야 함
    • 사용자에게 명확하며 간결하게 에러 이유에 대한 Notification이 전달되어야 함
    • Background에서 네트워크 연결이 정상화 되었을 때, 자동으로 미전송 데이터를 Post 할 수 있으면 금상첨화임
  • 서버 데이터 Load 중에 네트워크 에러 발생
    • 사용자에게 명확하며 간결하게 에러 이유에 대한 Notification이 전달되어야 함 (앞 절의 Blocking UI 주의 사항 참조)
    • 되도록이면 Cache된 데이터를 기반으로 사용자가 Offline에서도 일부 기능을 이용할 수 있도록 해줘야 함
    • 대용량 데이터 다운로드 중이었다면, 당연히 추후 이어받기 가능해야 함
    • Background에서 네트워크 연결이 정상화 되었을 때 자동으로 나머지 데이터를 Load 할 수 있으면 금상첨화임

2.2.4 Bandwidth awareness

네트워크 Bandwidth에 따라 전달되는 데이터의 Size를 조절하는 것이 좋다는 내용으로, 주로 Streaming Data의 경우에 해당 사항이 있다.

2.3 Efficient network connection usage

모바일 네트워크 사용은 UX, 돈(사용자 요금), 단말 배터리 등과 같은 다양하고 중요한 요소에서 영향을 끼친다. 그러하니, 모바일 네트워크 사용 시에는 매우 신중해야 한다. 모바일 App. 개발 시에는 꼭 네트워크를 사용해야만 하는 상황인지, Cache는 잘 되어 있는지, 3G 망으로 접속 시 시나리오는 어떻게 해야 할지, 현재 배터리 상황이 어떠한지 등을 잘 살펴서, 그때그때 상황에 맞도록 구현이 이루어져야 한다.

특히 3G 망 접속 시에는 더 많은 주의가 필요하며, 이를 명확히 이해하기 위해 우선 3G 네트워크에서의 Fast Dormancy에 대해 이해할 필요가 있다.

Fast Dormancy는 3G UMTS에서 무선 망에서의 네트워크 접속 State 변화에 따른 전류 소모를 극소화하기 위해 도입된 기술이다. 대부분의 Carrier 및 단말 제조사에서 지원하는 기능으로, 단말 출시 시 Carrier에 맞게 설정되어 사용자에게 판매된다. 세부적인 내용은 Call Processing 관련 개발을 하지 않는 이상 깊게 알 필요 없으므로 생략하고, 여기서는 Fast Dormancy의 대략적인 개념에 대해서만 설명한다.

우선 Fast Dormancy를 전류 소모량 측면에서 보면 위 그림과 같다. 먼저 특정 App.이 3G 무선 망을 이용하여 데이터 통신을 요청하게 되면, 단말은 이를 위해 순간적으로 높은 전력을 소모하는 네트워크 상태(Dedicated Channel State)로 천이하게 된다 이후 데이터 통신이 종료하게 되면, 일정 시간(T1) 동안 Dedicated Channel State를 유지하게 되고, 이후에 다시 좀 더 낮은 전류 소모 단계로 천이 한 후, 일정 시간(T2)이 지난 다음에 최소 전류 소모 상태(Idle State)로 천이한다. 이를 좀 더 세부적으로 살펴보면 다음과 같다.

초기 Idle State에서, 특정 App.이 데이터 통신 요청을 하게 되면, Dedicated Channel State로 천이하고, 데이터 통신이 더 이상 없으면 일단 Wait 1 상태로 천이하여 T1 시간만큼 대기하게 된다. T1 시간이 만료하게 되면 좀 더 낮은 전류 소모 단계인 Wait 2 상태로 천이하고, 이후 T2 시간 경과 뒤에야 최소 전류 소모 단계인 Idle State로 천이한다. 도식에서 보는 바와 같이, 최소 전류 소모 상태인 Idle State와 실제 데이터 통신이 이루어지는 Dedicated Channel State 사이의 전류량은 거의100배까지 차이가 난다. 이러한 Dedicated Channel State에서 다시 Idle State로 돌아올 때 까지는 T1 + T2 만큼의 시간이 필요한데, 이 시간이 최소 수 초에서 수십 초까지 소모가 된다 (Carrier 및 단말에 따라 차이가 있음. 대략 10초에서 1분까지 다양한 것으로 파악됨)

정리하자면, 한번 데이터 통신을 하게 되면, 전류량 소모가 일반 상태보다 100배까지 올라가게 되며, 다시 최소 전류 소모 상태로 돌아가기 위해서는 일정 시간이 필요하다는 것이다. 따라서 아래 그림과 같이 짧은 데이터 통신을 나눠서 자주 수행하게 되면, 실제 데이터 통신을 위해 소모되는 전류량 보다 더 많은 전류가 네트워크 상태 천이를 위해서 소모되고, 이는 단말 배터리 효율성에 매우 안 좋은 영향을 끼치게 된다.

따라서, 되도록이면 아래 그림과 같이 데이터 통신을 한꺼번에 모아서, 한 Session에 처리하는 것이 단말 배터리의 효율적 이용 측면에서 좋다고 볼 수 있다.

이와는 별도로, 3G 네트워크 상태 중 실제 데이터 통신을 할 수 있는 상태로 Dedicated Channel State(DCH) 이외에 Forward Access Channel State(FACH) 가 존재하는데, FACH는 DCH와 비교하여 약 1/3 정도의 전류 밖에 소모하지 않으므로, 이를 효율적으로 이용하면 단말 배터리 소모를 줄일 수 있다. FACH 모드로 통신 하기 위해서는 패킷 크기가 128 bytes (TCP/TLS 오버헤드를 계산하면 App.에서 실제 이용 가능한 데이터는 70 bytes 수준임)를 넘어가서는 안된다. 즉, 소량 데이터 통신 시에는 App. 수준에서 한번에 70 bytes 정도의 데이터 통신을 수행함으로써 배터리 효율성을 극대화 할 수 있다.

http://xmpp.org/extensions/xep-0286.html#sect-id67991 문서 참조

3. Ideal mobile application

앞에서는 모바일 네트워크 측면에서 효율적인 App. 개발에 대해서 살펴보았다. 이제부터는 최적의 모바일 App. 을 개발하기 위해 특별히 신경 써야 하는 사항들에 대해서 종합적으로 살펴보도록 한다

3.1 Asynchrony

앞에서도 언급되었지만, 워낙 중요하기 때문에, 다시 정리하도록 한다. 모바일 네트워크에서의 비동기성(asynchronous)이라는 면에서, 다음 두 가지 사항은 반드시 지켜야 할 가이드라인이 되겠다.

  • 네트워크 연결 및 처리 로직은 반드시 Main Thread(UI Thread)와 분리되어 처리되어야 한다.
  • 네트워크 요청들은 반드시 서로 간에 독립적으로, 병렬로 처리되어야 한다.

물론, 이 두 가지 사항이 지켜지기 위해서는 기반이 되는 Mobile 운영 체제(Android, iOS 등)에서 제공되는 API가 일정 수준 이상의 Thread 관련 API 및 비동기 네트워크 API 를 제공해줘야만 한다. 다행히도 Android 및 iOS의 경우는 풍부한 Thread API 및 Network API를 제공하기 때문에, 어렵지 않게 비동기 네트워크 처리 로직을 구현할 수 있다. 또한 Open Source 형태로 다양한 네트워크 라이브러리를 이용할 수 있으므로, 매번 새로 만들 생각하지 말고, 검증된 Open Source를 활용하는 것도 좋은 방법이 될 것이다.

3.2 Connection loss and error handling

근본적으로 모바일 네트워크는 불안정하기 때문에(다양한 속도 품질 및 잦은 네트워크 오류), 네트워크 상태에 대한 인지 및 오류에 대한 올바른 대처는 전체 App. 효율성 향상 및 사용자 UX 개선에 매우 중요한 역할을 하게 된다.

모바일 네트워크 상태 및 오류에 대해 제대로 처리하기 위해서는 1) 네트워크 요청 주체에 따른 차별화 된 에러 처리, 2) 우아한(Elegant) 네트워크 에러 처리, 그리고 3) 대용량 다운로드 처리에 대한 가이드라인을 정리하여 준수해야만 한다.

3.2.1 네트워크 요청 주체 별 에러 처리 가이드

사용자의 직접적인 요구에 의한 네트워크 요청(Primary Network Request)과 사용자에 기인하지 않은, App.이나 단말 상태 변화에 따른 2차적인 네트워크 요청(Secondary Network Request)은 분리되어 처리되어야 한다. 특히 요청 처리 도중 에러가 발생한 경우, Primary Network Request의 경우는 팝업 창 등을 통해 적극적으로 에러를 사용자에게 알려줘야 하지만, Secondary Network Request의 경우에는 사용자의 즉각적인 요청에 의한 에러가 아니기 때문에 사용자에게 직접적으로 에러를 알리기 보다는 간접적으로 알리는 것이 좋다.

예를 들어, 웹 브라우저에서 사용자가 특정 웹 페이지를 요청했는데 해당 페이지가 사용 가능하지 않을 경우, 팝업 등을 통해 에러 상태를 알려주는 것이 올바른 에러 처리 방법이 되겠지만, 해당 웹 페이지 내의 몇몇 이미지 리소스 로딩이 실패할 경우에는 각각에 대해서 일일이 팝업 등을 통해 사용자에게 알려주기 보다는, 로딩 못한 이미지 위치에 default place-holder 등을 배치하여, 간접적으로 사용자에게 네트워크 오류 상황을 알려주는 것이 올바른 에러 처리 방법이다.

이와는 별도로, Primary Network Request의 경우는 반드시 “취소” 기능을 사용자에게 제공해야만 한다. 또한 Primary Network Request가 취소될 경우, 그와 연관된 하위 Second-ary Network Request들도 모두 자동으로 취소 되도록 기능 구현을 해야만 한다.

3.2.2 네트워크 에러 처리 가이드

위에서 이야기한 Primary Network Request에 대한 에러 처리를 다음과 같이 세부적으로 나누어서 살펴보도록 한다.

  • 네트워크 요청 에러가 빨리 처리될 수 있는 경우
    • 대용량 데이터를 받아오는 경우가 아닌 경우는, 사용자에게 명시적으로 “재시도” 팝업 창을 띄워, 사용자가 에러 상황을 인지한 상태에서 다시 네트워크 요청을 진행하도록 하는 것이 바람직함
  • 네트워크 요청 에러가 빨리 처리될 수 없는 경우
    • 음악이나 비디오 같이, 대용량의 데이터를 받는 도중에 네트워크 오류가 발생한 경우에는, 사용자에게 알리기 전에, 내부적으로 일정 시간 동안 자동 재접속 시도를 수 회 시도하도록 구현하는 것이 바람직함
    • 만약 일정 시간 안에 재접속이 이루어지지 않을 경우에는 사용자에게 팝업 창을 띄워 요청을 취소할 지 선택의 기회를 주도록 함

또한 Secondary Network Request 중, 특히 주기적으로 자동 데이터 동기화를 하는 경우(이메일 클라이언트, 스케줄 동기화 등)에는 계속 에러가 발생하는 상황에서 무한 반복으로 재시도를 요청하여 배터리를 소모하지 않도록 해야 한다. 이를 위해 재시도 가능 시간을 지정(5분 등)하여, 해당 시간 동안 재시도가 성공하지 못하면 실패 처리하고, 다음 데이터 동기화 주기에 다시 접속 시도하도록 하는 것이 바람직하다.

3.2.3 대용량 다운로드 처리 가이드

대부분의 경우, 대용량 데이터 다운로드 시에 HTTP를 많이 사용한다. 그 이유는 HTTP가 대중화된 프로토콜이기도 하고, 특히 이어 받기 기능이 프로토콜에 내재되어 있기 때문이다. HTTP에서 이어 받기는 Range 헤더를 이용하여 구현한다. 다만, 초기 다운로드 중 오류가 발생한 이후 이어받기 요청까지의 시간이 길 경우, 해당 컨텐츠의 변경 여부까지 체크해야 하기 때문에, 이어 받기 전에 여러 번의 추가적인 HTTP Request/Response가 필요하다. 이를 피하기 위해서 HTTP의 If-Range / Range 를 조합하여 같이 사용할 것을 권장한다. 특히 If-Range 헤더를 사용하여 부분 다운로드를 할 경우, ETag까지 같이 사용하면 원본 데이터의 업데이트 여부까지 한번에 체크할 수 있어 매우 유용하다. If-Range 헤더에 ETag를 같이 넣어 줄 경우, 웹 서버는 데이터 변화가 있을 경우 Range 헤더에 명시한 부분 데이터 대신 전체 데이터를 바로 전송하고, 아니면 원래 요청에 맞춰 Range 헤더에 명시한 부분 데이터만 전송한다.

3.2.4 기타

나머지 원문에 있는 내용들은 일반적인 내용이므로 세부적으로 설명하지는 않는다. 다만, 선불 요금제(PAYG:Pay As You Go) 단말인 경우, Data 플랜에 따라 네트워크 접속이 제한될 수 있으므로, 이 경우는 별도로 체크하여 사용자에게 명시적 알람을 주고, 해당 요금 이슈가 처리될 때 까지 네트워크 접속을 하지 않는 등의 특별한 처리가 필요하다는 점은 별도로 기억하도록 한다. 이를 따로 설명하는 이유는, 국내의 경우 선불 요금제가 활성화 되어 있지 않아, 대부분의 모바일 App.들이 이에 대한 에러 처리가 안되어 있는 경우가 많기 때문이다.

3.3 Caching

캐쉬는 모바일 네트워크를 이용하는 App.의 응답성을 증대시키고, 실제 데이터 네트워크 량을 감소시켜 배터리 및 사용자 Data Plan에 긍정적인 영향을 끼치므로, 대부분의 App.에서 반드시 적용해야 하는 기능이다. 캐쉬 처리를 위해 다양한 방법을 고민할 수 있겠지만, 기본적으로 HTTP 1.1 버전에 이미 높은 수준의 실용적인 캐쉬 관련 기능이 들어가 있으므로 이를 살펴보도록 한다.

HTTP 1.1에 정의된 캐쉬 관련 기능을 이용한 단말/서버 간 캐쉬 관리 방법을 간단히 설명하면 다음과 같다.

① First Request: Cache에 해당 리소스가 없는 경우, 서버에 리소스를 요청한다.

② First Response: 서버는 Modified Date 또는 ETag와 함께 실제 리소스를 전송한다.

③ Local Cache 저장: Local Cache에 리소스 및 Modified Date / ETag를 함께 저장한다.

④ Second Request: App. 이 필요 할 때, Local Cache에 저장된 해당 리소스 명 및 Modified Date / ETag를 전송하여 리소스가 Update되었는지 체크한다. 이때 사용할 수 있는 HTTP Header는 다음과 같다

A. If-Modified-Since: Modified Date만 인자로 주어지며, 주어진 시간 이후 변경된 경우에만 요청 리소스를 반환한다.

B. If-Unmodified-Since: Modified Date만 인자로 주어지며, 주어진 시간 이후 변경되지 않은 경우에만 요청 리소스를 반환한다.

C. If-Match: 요청한 리소스/ETag 쌍이 서버에 저장된 리소스/ETag 쌍과 동일할 경우에만 요청 리소스를 반환한다.

D. If-None-Match: 요청한 리소스/ETag 쌍이 서버에 저장된 리소스/ETag 쌍과 다를 경우에만 요청 리소스를 반환한다.

E. If-Range: 요청한 리소스/ETag or Date 쌍이 서버에 저장된 리소스/ETag or Date 쌍과 다를 경우에는 전체 리소스를 반환하고, 같을 경우에는 Range 헤더에 명시된 Partial 데이터만 전송한다(이어 받기에 사용됨)

위에서 소개한 기법의 경우, 개별 리소스 캐쉬 관리에는 효율적이나, 캐쉬된 리소스 개수가 많을 경우에는 많은 HTTP Request/Response가 필요하기 때문에 여전히 어느 정도 한계를 가지고 있다. 이를 좀 더 효율적으로 관리하기 위해서는 App.의 리소스들을 동시에 같이 바뀔 수 있는 것들 별로 그룹화 하여(예를 들어, 특정 한 화면에 배치된 이미지들은 UI 개편 시 다 같이 변경될 확률이 높으므로 하나의 그룹으로 묶을 수 있음), 그룹 단위로만 Modified 여부를 관리하는 것이 좋다. 실제 HTML5에 명시된 App Cache 규격이 이러한 방법을 이용하고 있으니 참고하도록 한다 (자세한 규격 내용은 HTML5 – Offline Web Applications 을 참고)

3.4 Security

모바일에서의 보안은 단말 보안부터 네트워크 보안, App. 자체 데이터 보안까지 그 영역이 다양하나, 여기서는 네트워크 보안에 대해서만 논하도록 한다.

3.4.1 Classification of information

모바일 App.이 다루는 데이터는 보안 관점에서 일반적으로 다음과 같이 분류한다.

  • Public
    • 인터넷을 통해 일반적으로 쉽게 취득 가능한 데이터로 특정 사용자와 연관되지 않는 데이터
  • Private
    • 특정 사용자와 직접적으로 연관될 수 있어, 보안 상 위험을 내포한 데이터

따라서 개발자는 실제 모바일 App. 개발에 들어가기에 앞서, 자신의 App.이 다루게 될 Data를 위의 기준에 따라 분류하여, Private 정보의 경우에는 Plain Text 형태로 단말 외부 또는 다른 모바일 App.에 제공되지 않도록 주의해야 한다.

3.4.2 Authentication

보통 대부분의 모바일 App.들은 별도의 Client ID(User ID) 및 그에 따른 Password를 기반으로 사용자 인증을 수행한다. 그러나, 전통적인 Mobile Network Operator(이동통신사)들의 경우, 사용자 편의를 위해 Device ID(단말 고유의 Static Data – Serial Number, Phone Number, IMEI 값 등)만으로 사용자 인증을 대체하기도 한다.

그러나, 이러한 Static한 Device ID를 이용하여 사용자 인증을 수행하는 것은 보안상 매우 위험한 것으로 절대 피해야 하는 방법이다. 되도록이면 별도의 Client ID를 사용자에게 입력 받아 인증하는 것이 보안 상의 다양한 위협에 효과적으로 대처할 수 있다. 그러나 개별 사용자에게 서비스 마다 Client ID를 만들도록 하는 것이 부담스러워 굳이 Device ID로 사용자 인증을 수행해야 한다면, Static한 Device ID를 바로 이용하지 말고, 이러한 Device ID를 별도 알고리즘을 통해 변형한, 별도의 Unique ID를 만들어 사용할 것을 권장한다.

이와는 별도로, 최근 유행하는 3rd Party를 통한 인증 공유 방식(주로 OAuth를 사용)도 이용 가능하다. 이 경우는 Facebook, Twitter와 같은 3rd Party 서비스를 통해 인증 받은 Credential을 각 모바일 App.이 잘 관리하는 것이 매우 중요하다고 할 수 있다.

앞에서 소개한 3가지 방법 중 어떠한 방법을 사용하던 간에, 다음의 두 가지 사항은 반드시 지키도록 한다.

  • 인증은 반드시 Secure한 Protocol을 통해 이루어져야만 한다
  • 되도록이면 HTTPS나 또는 SSL/TLS를 통해 인증이 이루어지도록 해야 한다
    • 인증을 통해 보안 세션이 맺어진 이후에는, 모든 인증 관련 데이터(사용자나 단말을 대표하는 모든 인식 값들)는 보안 세션을 통해 전달되어야 한다.

3.5 Efficient traffic usage

3.5.1 Cloud-based transformations

모바일 App.을 개발하다 보면, 외부의 Public한 데이터를 이용하는 경우가 많은데, 이 경우에는 다음과 같은 사항들을 고려해서 개발을 해야 네트워크 트래픽을 줄이고, 서비스 오류를 예방할 수 있다.

  • 되도록이면 Public Data를 제공하는 서비스 사의 Open API를 이용하도록 한다
  • Open API가 없을 경우는, Raw Data를 바로 단말에서 처리하지 말고, 중간에 자체 서버를 구축하고, 모바일 App.에 맞도록 가공하여 서비스 하도록 한다

자체적으로 서버를 구축하기 힘들다면, Yahoo Pipe와 같은 무료 Data Transformation 서비스가 있으니 활용해보도록 한다.

3.5.2 Media Transcoding

일반 텍스트 데이터는 압축 전송 등을 통해 네트워크 트래픽을 대폭 줄일 수 있으나, 멀티미디어 데이터(사진, 동영상)의 경우는, 이미 그 자체가 압축되어 있기 때문에, 텍스트와 같이 간단한 방법으로 네트워크 트래픽 양을 줄이기가 어렵다. 따라서 멀티미디어 데이터의 경우는 네트워크 트래픽을 줄이기 위해, 다음과 같은 방식들을 이용하도록 한다.

  • 실제 멀티미디어를 재생할 단말의 해상도를 넘기지 않도록 데이터를 맞춰서 전송
  • 단말이 현재 접속해 있는 네트워크 QoS를 확인하여, 그에 알맞는 bit rate로 데이터 전송
  • 되도록이면 Progressive download를 사용할 것

Apple의 경우도 멀티미디어 전송에 대한 서비스 Quality 유지를 위해, 전체 비디오 데이터가 5 MB가 넘거나 재생 시간이 10분이 넘는 경우, 전송 방식을 HLS(HTTP Live Streaming)으로 하도록 강제하고 있다(그 외의 경우는 Progressive Download 이용 가능)

위와 같은 조건을 만족시키기 위해서는 사실 단말 단이 아니라, 서버 단에서 여러 기능을 제공해야 한다. 그 기능 리스트는 다음과 같다.

  • 이미지 리사이징 기능
  • 비디오/오디오 파일 크기를 줄일 수 있는, Quality Reduction 기능을 내장한 코덱
  • HLS 및 RTSP와 같은 미디어 스트리밍 기능 지원

3.6 Compression

HTTP 프로토콜에서 지원하는 인코딩 타입 중 압축 타입이 이미 포함되어 있으며, 또한 대부분의 웹 서버에서 압축 인코딩을 지원하므로, 가능하면 꼭 사용하도록 한다. 특히 모바일 App.과 서버 간 데이터 연동을 위해 XML/JSON을 HTTP로 전송하는 경우 사용할 것을 권장 한다.

3.7 Background / Foreground modes

대부분의 모바일 OS(Android, iOS, Windows Phone 등)는 Application Lifecycle에 Foreground 및 Background mode를 가지고 있다. 여기서 Foreground란 일반적으로 전면 UI를 차지하고, 사용자 입력을 받는 모드이며, Background란 UI를 가지지 않으며, 사용자 입력을 받지 않는 모드이다. 제한된 단말의 리소스를 생각할 때, 모바일 App.이 Foreground에서 Background로 천이하는 경우, 다음의 리소스들을 Release하도록 구현되어야 한다.

  • Handlers
  • Timers
  • Network Transaction
  • Memory/Objects
  • Media codecs
  • File & Databases

특히 Background에서 네트워크를 사용하는 모바일 App.의 경우, 그 이유가 대부분 주기적으로 서버로부터 데이터를 Polling하기 위해서이므로, 이 경우에는 되도록이면 Push Notification(Android, iOS 등에서 모두 제공함)을 이용하도록 한다.

3.8 Application Scaling

서버와 주기적으로 통신하는 모바일 App. 서비스하는 경우 많이 하는 실수가, 모든 모바일 App.이 특정 시간에 동시에 서버와 통신하도록 하는 것이다. 이 경우, 서비스 서버의 부하를 일시에 증가시켜 불필요한 네트워크 트래픽(접속 실패에 따른 지속적인 접속 요청)을 유발할 수 있으므로, 반드시 개별 App.들이 별도의 Time Table을 가지고 서버에 접속하도록 해야 한다. 또한 접속 네트워크 환경(3G인지 WiFi인지)을 인식하여 접속한 네트워크 Bandwidth에 알맞은 데이터가 전송되도록 지능적으로 개발해야 한다.

4. References

① GSMA: Smarter Apps for Smarter Phones

② Google I/O 2012: Making Good Apps Great: More Advanced Topics for Expert Android Developers

③ XMPP.org: XEP-0286 – XMPP on Mobile Devices

④ W3C.org: HTML5 – Offline Web Applications

박창현 Master

SK planet에서 단말 SW 관련 개발을 하고 있습니다. 현재는 Android 보안, Web Browser, Android 가상화 개발을 하고 있고… 그 전에는 열악한 Feature Phone에서 단말 플랫폼 개발로 30대를 다 보냈습니다. 사원/대리/과장/차장/부장/팀장/이사/사장까지 다 해봤는데, 역시 “개발”하는게 제일 재미있다는…^^

Facebook 

공유하기