Beyond Google I/O 2013 – It’s Quality and Speed, Stupid!

안녕하세요.  Mobile SW 개발 1팀 박창현 팀장입니다.

첫 번 째 글을 포스팅하고, 어언 10개월은 흐른 듯 하네요.  저번 글은 영문 번역이 메인이어서 꽤 번역체(?)스러웠는데, 이번 포스트는 제가 직접 경험하고 느낀 것들을 기반으로 하기 때문에, 좀 더 읽기 편한 구어체(?)가 될 수 있을 듯 합니다.

이번 포스트에서는 제가 직접 참석했던 Google I/O 2013에서 진행되었던 기술 세션들을 정리하고, 이를 기반으로 향후 Mobile 기술이 어느 방향으로 진화해갈지 예측해보는 내용을 다루어 볼까 합니다.

제가 단말 SW 쪽 및 Web Browser 쪽에만 관심이 있어서 주로 Android쪽 기술 세션에 참여하고, 일부 Mobile Web쪽 세션을 기웃댔었기 때문에, 이번 포스팅도 주로 Android, Mobile Web에 집중하게 될 듯 합니다(Google+, Google Glass, Google Drive 등을 기대하셨던 분들에게는 죄송)  그럼 Let’s start!!

What’s up Android?

이번 Google I/O에서 가장 특징적인 부분은, Android 관련해서 Surprise가 없었다는 점이었습니다.  모두가 기대했던 키라임파이 발표도 없었고, 새로운 Android 디바이스 발표도 없었고, 작년 같이 놀랄만한 기능 추가(Project Bufferfly)도 없었죠.  혹자는 앤디 루빈 부사장 축출(?) 여파라고 해석하기도 하지만, 엔지니어인 필자 입장에서 보자면, 올해 Android 관련 Surprise가 없었던 이유는, 더 이상 할 게 없었기(?) 때문이지 않을까 합니다.

사실 Android는 이미 수년간 급격하게 진화해왔고, 작년 Jelly Bean이 나오면서 기능적/성능적으로 현존하는 H/W Form Factor(CPU, RAM, LCD, Battery, NFC 등) 활용도를 최고 수준으로 끌어 올려놓은 상태이죠.  예전에는 Android의 SW 성능이나 기능이 부족하여, 그 부분을 H/W 성능으로 메웠었는데, Jelly Bean 이후로는 사실 대부분의 사람들이 기능이나 성능에 있어서 경쟁 제품(iPhone) 대비 Android가 부족하다고 느끼지 못하고 있습니다.  이는 대부분의 SW 플랫폼이 일정 임계점을 넘어서서 고도화 되면, 그 기술적 발전이 정체되고, 다른 H/W나 문화적 Tipping Point가 제공되기 전에는 그 상태를 유지하게 된다는 경험적 법칙에 의해 증명 가능하며(Windows XP나 IE6가 그 상태로 몇 년간 유지되었는지 생각해보세요^^) 현재 Android도 정확히 그 임계점의 초입에 와 있다고 보여 집니다.  즉, 이후로 얼마간은 Android에서 Surprise는 기대하지 마시라는 이야기입니다^^

이러한 이유로, 이번 Google I/O 2013에서 Google의 Android Dev. 팀이 포커싱 했던 부분은 개발자 Ecosystem에 대한 고도화였습니다.  주로 어떻게 하면 더 빠른 Android 앱을 만들 수 있게 할 것이냐, 어떻게 하면 Android 앱을 더 편하게 만들게 해 줄 것이냐 하는 것들에 초점을 맞춰서 3일간 세션을 설계했던 듯 합니다(사실 이 두 가지는 도구일 뿐이고, 이러한 기술적 고도화를 통해 Google이 얻고자 한 궁극적 목표는, Android 플랫폼 상에서 서비스되는 앱들이 경쟁 플랫폼 보다 더 많은 이익을 내게 하는 것이겠죠)  저도 이에 발 맞추어 위의 2가지 주제(더 빠른 앱, 더 편한 개발환경)에 대해 이야기 드리도록 하겠습니다.

Faster Apps!

앱에 있어서 속도는 선택이 아닌 필수 사항입니다.  느린 앱은 죄악(?)인 세상입니다.  아무리 기능이 많아도 속도가 느리면 사용자에게 바로 외면 받게 되죠.

현재 스마트폰이 대중화된 환경에서, 앱 속도에 있어서 가장 큰 Bottle-neck으로 지목되는 부분은 Graphic과 네트워크 입니다.  더 정확하게는, 서버에서 네트워크를 통해 데이터를 읽어와 화면에 표시(Graphic)하는, 거의 모든 스마트폰 앱에서 표준화된 형태로 제공되는 동적 데이터 로딩 & 렌더링 속도를 어떻게 높이느냐가 앱의 전체적인 품질을 결정하는 중요한 요소가 됩니다.

이번 Google I/O 2013에 더 빠른 Android 앱을 만들기 위한 다양한 세션들이 소개 되었지만, 그 중 동적 데이터 로딩 & 렌더링 속도와 직접적 연관이 있는  Volley와 Android Graphics Performance 세션을 소개해 드리겠습니다.

Volley: Easy, Fast Networking for Android

Volley는 전체 Google I/O  에서 가장 많은 Feedback(물론 좋은)을 받은 세션 중 하나입니다.  Volley가 무엇인지는 다음 한마디 말로 정리할 수 있습니다.

전천후 네트워크 라이브러리

물론 Android에는 기존 HttpConnection 및 여타 Socket API가 존재하고, 또한 다양한 Open Source 기반 네트워크 라이브러리도 가져다 쓸 수 있습니다.  그러나, 실제 Real World에서부드러운 컨텐츠 로딩/디스플레이를 하기 위해 개발자들이 상당히 많은 작업을 추가로 해야만 했습니다.  사실 이 문제는 개별 개발자들에게 큰 스트레스로 다가왔는데, Android 기본 구조 상 Main Thread에서 UI 작업이 이루어져야 해서, 대부분의 Blocking 작업들(특히 네트워크)은 AsyncTask 등을 통해 처리해야만 했습니다.  그런데, 이 AsyncTask라는 것이 Android OS 버전마다 구현도 조금씩 다르고, 중간에 Cancel이 잘 안 되는 등의 이슈가 워낙 많아서 “잘 돌아가는” 코드를 만드는 작업이 상당히 스트레스 받는 일이었죠.  이러한 문제를 해결해준 것이 Volley 입니다.

Volley는 내부에 Request Queue를 가지고, Main Thread와 분리된 Cache Thread, Network Thread를 각각 별도로 관리합니다.  밑에 그림에서 보시는 바와 같이, 사용자 Request를 받으면, 우선 이 Request를 Cache Thread로 넘겨 Cache를 찾고, Cache에 없으면 Network Thread로 Request를 넘겨 Main Thread/Cache Thread와 독립적으로 네트워크 Request가 수행되도록 합니다.  이러한 구조를 바탕으로 Main Thread 상의 UI 끊김을 방지하고, Cache 를 기반으로 빠른 데이터 로딩을 가능하도록 합니다.

Volley는 네트워크를 통한 다양한 데이터 로딩에 이용될 수 있는데, 그 중에 특히 이미지 로딩에 있어서 큰 힘을 발휘합니다.  이를 위해 ImageLoader를 별도로 제공하고 있으며, 사용법 또한 매우 간단합니다.

우선 아래와 같이 Request Queue를 생성하고,  ImageLoader를 설정 합니다.

mQueue = Volley.newRequestQueue(context);
mImageLoader = new ImageLoader(mQueue, new BitmapCache());

이후, Request를 생성해서 Volley의 Request Queue에 Enqueue 합니다(여기서는 ImageRequest를 Enqueue 하도록 하겠습니다)  성공 시에는 Response.Listener 의 onResponse()를 통해 Encoding된 비트맵 객체가 반환되며, 이를 ImageView 에 설정하도록 구현하면 됩니다.

ImageView imageView 
  = (ImageView) findViewById(R.id.image_view);

Response.Listener<Bitmap> listener = new Response.Listener<Bitmap>() {
    @Override
    public void onResponse(Bitmap result) {
        // On success
        imageView.setImageBitmap(result);
    }
};

Response.ErrorListener error = new Response.ErrorListener() {
    @Override
    public void onErrorResponse(VolleyError error) {
        // error handling
    }
};

ImageRequest imageRequest 
  = new ImageRequest("http://...(URL)", listener, 0, 0, 
                     Config.ARGB_8888, error);
mQueue.add(imageRequest);

이 방법 이외에도 NetworkImageView를 바로 이용할 수 있습니다.  NetworkImageView 사용법은 매우 간단한데, ImageLoader를 URL과 함께 설정해주기만 하면, 알아서 Aysnc로 이미지로 로딩하고, Request 관리까지 수행합니다.

NetworkImageView imageView 
  = (NetworkImageView) findViewById(R.id.network_image_view);

// start load
imageView.setImageUrl("http://...(URL)", mImageLoader);

Volley는 ImageRequest  이외에도, JsonRequest 및 StringRequest를 제공합니다.  이를 이용하여 Request시 GET/POST 메소드를 선택하고, custom 파라미터 전달도 가능합니다.

이와 함께, Request Queue에 들어온 모든 Request 를 한번에 중지할 수 있는 메소드도 제공합니다(사실 이 기능이 기존 AsyncTask를 이용해 Custom하게 코드를 만들던 개발자들에게는 가장 와 닿는 부분일 수 있겠습니다)

public void onStop() {
    mQueue.cancelAll();
}

마지막으로, 세션 끝난 후 Q&A 시간에 나온 이야기로, SPDY와 Volley와의 연계성에 대한 질문이 있었습니다 (SPDY는 Google에서 제안한 새로운 네트워크 프로토콜로 HTTP 퍼포먼스 향상에 초점을 맞추고 있습니다)  일단, 현재 Volley는 SPDY와 연계 되어 있지 않고, 표준 HTTP 만 이용하도록 개발되었다는 응답이 나왔고, 다만 추후 내부적으로 SPDY도 이용할 수 있도록 검토는 진행하겠다고 이야기는 하더군요.  개인적인 판단으로는, Volley 에 SPDY까지 합쳐지면 앱과 서버 연동한 Data Loading/Parsing/렌더링 성능에 있어 가장 뛰어난 Best Practice가 되지 않을까 합니다.

Android Graphics Performance

Google이 2012년도에 Jelly Bean 업데이트 시,  Project Butterfly를 통해 Android 전체 시스템에 대하여 초당 60 프레임으로 랜더링 가능하도록 성능 개선 작업을 진행했습니다.  이에 따라 현재 신규 단말에 가장 많이 이용되는 Android Jelly Bean 버전에서는 대부분의 단말에서 매우 부드러운 UX를 경험할 수 있게 되었죠.

이번 Google I/O 2013에서는, 이러한 시도를 뛰어넘어 마른 수건을 쥐어 짜는 심정으로, 어떻게 하면 렌더링에 있어서 낭비 요소를 더 없앨 것인가에 대한 가이드 및 Google 내부에서 진행 중인 내용들에 대해서 공유하는 세션을 가졌습니다.

이 세션 또한 박수를 많이 받았는데요, 어떻게 보면 뭐 이렇게까지 해야 하나 하는 부분들도 많았지만, 사용자의 눈도 높아졌고, 또 경쟁자인 iOS도 지속적으로 성능 개선을 하고 있기 때문에 Google 입장에서도 대응이 필요했다고 느껴집니다.

여하튼 이 세션에서는 상당히 다양한 이야기들이 나왔었는데, 전 실제 앱 개발 시에 알고 있으면 좋을 몇 가지만 간략히 소개하도록 하겠습니다.

  • Re-ordering

GPU 가속을 사용하는 환경에서 앱 UI 개발 시에 text rendering/image rendering/simple box rendering 등을 막 섞어서 쓰게되면, 각각의 rendering 시마다 GPU 상에서 State가 초기화 되야 해서 GPU 성능에 overhead 가 될 수 있다고 합니다 (마치, 사람이 이거 하다 저거 하다가 하면 전체적으로 업무 효율이 떨어지는 것과 같이, GPU도 동일 종류의 작업간 State 변경이 잦으면, 그에 따라 캐시/상태 초기화, 재설정에 따른 효율이 많이 떨어진다고 합니다)  따라서, 되도록이면 UI Layout  계산이 다 완료된 상태에서, text 들을 모아서 한번에 모두 출력하고, Image 출력하고, box 출력하는 식으로 최적화하면 더 빨라질 수 있다고 합니다.  물론 이 작업을 앱에서 직접 하는 건 매우 어려운 작업일 것이며, 이러한 점을 고려해서 현재 Android OS를 수정하고 있다고 합니다(단, 언제 이 작업이 완료되어 업데이트 될지는 미정이라고 하네요)

  • Over-drawing

이미지 출력 시에 되도록이면 Over-drawing을 하지 말라는 것입니다.  이건… 예를 들어서 Canvas 위에 또 Canvas가 있어서 일부 영역을 덮고 있다면(Child인 거죠) Parent에서 해당 영역(Child Canvas 영역)을 잘라서 투명으로 지정하라는 겁니다.  그러면 애당초 GPU가 그 영역을 안 그리게 되니까(어차피 거기에 뭘 그려도 Child Canvas가 덮어 쓸 테니까요) 속도가 더 빨라진다는 거죠.   이건 비단 이런 예 뿐만 아니라, XML로 Layout 잡을 때 어차피 맨 밑에 깔린 View를 다른 Child View들이 다 덮어쓰는 경우라면, 맨 밑에 깔린 View의 배경색 설정을 xml에서 빼버려야, Over-Drawing이 안되고, 그래야 Graphic Performance가 올라간다는 부분에도 적용이 되더군요.  앱 만들 때 참고하면 좋을 듯 합니다.

  • Alpha-blending

Alpha-blending 이용 시에도, TextView에 setAlpha() 메소드로 Alpah 값을 설정하면, 전체 TextView 영역에 Alpha 값이 적용되고, 그 크기(너비*높이)만큼 픽셀마다 GPU 연산을 해야 하니, 그냥 setTextColor() 메소드를 통해 Alpha 값을 적용함으로써, 실제 text 그려지는 부분만(도트 찍히는 부분)만 Alpha 값 적용하여 연산 속도를 더 높이라는 것입니다.(이것 말고도, Image의 경우도, setImageAlpha()를 써야 Over-calculation이 안 된다고 합니다)  이와 더불어,  Custom View를 만들어 쓰는 경우, hasOverlappingRendering() 메소드를 Overriding 해서, Overlapping이 필요 없는 경우, 꼭 옵션을 끄도록 해야 한다고 합니다.  Overlapping rendering이 enable되면 해당 View에 Offscreen Buffer를 별도로 할당하므로, 메모리 낭비가 심해진다고 하네요.

제가 이 세션 보면서 느낀 점은, 역시 뭐든지 “잘” 만드는 건 어려운 거고, “잘” 만드는 건 “얕은” 지식으로는 안 된다는 점이었습니다 (사실 일반적으로 이야기하는 “UI 따위”를 개발하는데 GPU 나 Rendering Order를 알아야 더 잘 만들 수 있다는 점이 생경하기는 하지만, 거꾸로 이야기하면, 개발자가 “UI 따위”로 치부하고 기본을 잘 안 지켜서 대충 개발하면, “그 정도” Quality 밖에 안 나오는 경우가 많지 않을까 합니다.  언제나 기본이 제일 중요한 듯 하네요)

Key Implication: Quality is so important!

“성능”은 서비스에서 매우 중요한 요소입니다.  실제 앱 기반 서비스에서 사용자 Retention Rate을 올려주는 요소 중 “성능”이 큰 부분을 차지한다고도 합니다.  제가 위 세션들을 보면서 느낀 점은, 이제 Android가 성숙기에 접어들면서(정확히는 Mobile OS 전체가 성숙기에 접어든 거죠) 그냥 앱을 “만드는 것” 보다는 앱을 “잘 만드는 것”이 더 중요해지고 있다는 것이었습니다.  예전에는 어쨌든 빨리 만들어서 후딱 서비스 하는 것이 목표였다면, 이제부터는 “잘” 만들어서 지속적으로 업데이트하면서, 서비스 품질을 지속적으로 유지하는 것이 더 중요해지고 있으며, 이를 위해서는 대충 만들면 안되고, 좀 더 높은 수준의 기술력과 고민이 필요하다는 부분입니다

Powerful Tools!

앞에서 살펴본 Faster Apps! 부분이 앱을 “잘 만드는 것”에 있어 중요한 부분이라면, 이번에 살펴볼 Powerful Tools! 는 성능 좋은 앱을 “빠르게 개발하고, 지속적으로 품질 관리”하는데 있어 매우 중요한 부분입니다.  이렇게 지속적으로 사용자를 끌어 들이고, 서비스 품질을 유지하기 위해서는 훌륭한 개발 툴과 Fast Development를 가능하게 해주는 빌드 시스템이 반드시 필요합니다.  이번 Google I/O 2013에서 Google은 이 두 가지를 모두 발표했습니다.  지금부터 이 두 가지에 대해서 살펴보도록 하죠.

Android Studio

Android Studio는 기존 Eclipse 기반 ADT를 대체할 목적으로 개발된, IntelliJ IDEA 기반 개발 툴입니다.

Android Studio는 다음과 같은 기능을 제공합니다.

  • Gradle 빌드 시스템 지원 (뒤에 또 설명 나옵니다)
  • Android 특화된 refactoring 및  Quick fix 기능 지원
  • Lint Tool / ProGuard / app-signing 지원
  • 새로워진 Layout Editor / Designer 지원

실제로 Quick Fix 기능의 경우, Lint 등과 연계하여 더 나은 코딩 룰이나 Syntax를 제안하고, 그에 따라 자동으로 소스/리소스를 변경해줍니다 (매우 편리합니다!)  또한 Layout Editor나 Designer의 경우, XML에서 수정한 변경 내용이 바로 Designer에 반영되어 나타납니다.  현재 Eclipse 버전에 비하면 장족의 발전이지요.

Android Studio가 현재는 Preview 버전 상태이지만, 그 근간이 되는 IntelliJ 자체가 예전부터 많은 매니아들을 가지고 있었고, 그 기능 자체가 워낙 훌륭하기 때문에 추후 버전이 올라가면 개발 생산성 향상에 큰 도움을 줄 수 있을 듯 합니다 (단, NDK는 지금 지원하지 않으며, 내년 초는 되어야 지원한다고 하니 참고하세요)

Gradle 빌드 시스템

Android Studio 이외에 개발 툴 관련하여 가장 개발자의 환호를 이끌어낸 부분이 바로 Gradle 빌드 시스템 도입입니다.  Gradle은 빌드 시스템 중 하나로, DSL(Domain Specific Language)을 기반으로 다양한 빌드 조건 및 Dependency에 맞춰 빌드 작업을 수행할 수 있도록 합니다 (DSL은 Groovy를 기반으로 한다고 하네요)

짧은 글을 통해 빌드 시스템을 설명한다는 것은 어려운 일인지라, 여기에서는 gradle을 통해 기존 Ant나 Maven 대비 어떤 점들이 나아지는지 정리해보았습니다.

  • 다양한 빌드 설정 제공

Build 시, Build Type(Debug, Release, Test, Instrument..) 과 BuildFlavors(arm, x86, free, paid…)를 각각 정해서 서로 다른 source root에서  source를 받아와 빌드가 가능하다고 합니다.  저는 처음에 보고 정확히 ClearCase에서 사용하는 Config Spec와 유사하다고 느꼈습니다.  여하튼, 다양한 Build Type 및 Flavor를 다 적용할 수 있다는 점은 다양한 단말 및 앱 타입(유료, 무료)에 대응하여 빠르게 개발해야 하는 Android 앱 개발자에게 큰 도움이 될 듯 합니다.

  • CI 서버 & Auto Deploy 지원

CI 서버(Continuous Integration)를 제대로 지원하고, Auto Deploy(to 배포 서버)도 지원한다고 합니다.  특히 Jenkins 연동 모듈도 지원한다고 하네요.

  • Library Project 제대로 지원

드디어 Android Library 패키지 빌드를 “제대로” 지원한다고 합니다.  여기서 “제대로”가 의미하는 바는,  이제 Android Library Project 빌드 시, res, asset, native library, manifest 파일을 하나로 패키징 할 수 있게 되었다는 것입니다(*.aar 포맷)  사실 이 기능은 매우 오랫동안 수 많은 개발자가 요구했던 것이고요(이게 안돼서, Android Library 형태로 여러 조직이 연계하여 프로젝트 진행 시, Library 부분을 완벽히 Black-box화 해서 배포하는 것이 불가능했고, 언제나 소스 레벨로만 붙여야 했습니다.  또한 리소스도 언제나 소스 레벨로 합쳐야 했기에 그 불편함이 이루 말 할 수 없었죠)  이런 이유로 실제 세션 발표장에서는 기능 지원한다는 장표가 뜨자마자 환호가 터져 나왔습니다 (앞에 뭐 별거 다 지원 한다고해도 시큰둥했는데… 역시 개발자들만 모이는 행사라, 거창한 기능 보다는 실제 개발하면서 귀찮았던 사소한(?) 기능 추가에 많이 감동하는 듯 합니다)

Key Implication: Development Speed!

앞에서 이야기한대로, 개발자로 하여금 앱을 빨리 개발하고, 빨리 배포하고, 빠르게 Update Iteration을 돌 수 있도록 해주는 기능 지원은 플랫폼으로써의 Android 경쟁력을 위해 반드시 필요한 부분이었고, 이번 기능 추가들을 통해 점차 iOS와의 격차를 줄여가고 있는 듯 합니다.  여하튼, 다시 한번 강조 드리지만, 성숙한 시장에서 서비스 경쟁력은 높은 품질과 빠른 서비스 업데이트 입니다!

What’s up Mobile Web?

Google은 근본적으로 Web 플랫폼을 기반으로 성장한 회사입니다.  사실 Android는 Web 플랫폼에서 Google의 지배력을 Mobile로 넓히기 위한 일종의 첩자(?)였을 뿐이었고, Android가 예상 밖의 큰 성공을 거둔 지금 현재도 여전히 Google의 근본은 Web에 있다고 봐야 할 듯 합니다.

이러한 이유 때문에, Google I/O에 Android보다 더 많은 세션을 차지한 기술 분야가 Web 이었습니다.  전 그 중에서도 Mobile Web쪽 세션에만 참여를 했었고, 그 중 Mobile Web의 성능 및 개발 편의성 관련한 내용을 소개해드리도록 하겠습니다.

Robuster Mobile Web!

PC Web은 이미 오래 전에 네트워크 대역폭 및 브라우저 성능으로 인한 속도 문제에서 많이 자유로워졌습니다만, Mobile Web에서는 아직까지도 이 두 가지 이슈(대역폭, 브라우저 성능)로 인한 속도 문제가 많이 이슈화 되고 있습니다.

브라우저 성능 부분은 Mobile Chrome 프로젝트 및 H/W 성능 향상을 통해 꾸준히 개선되고 있습니다만, 네트워크 대역폭 문제는 여전히 Mobile Web의 발목을 잡고 있지요.

이에, Google이 Mobile Web에서 네트워크 대역폭을 줄일 수 있는 부분이 무엇이 있을까 분석한 결과, Mobile Web상의 대부분의 데이터가 이미지 파일이라는 것을 알게 되었다고 합니다(60~70%가 넘어간다고 하네요)  이에, 가장 많은 대역폭을 요구하는 이미지 파일 포맷에 대해 개선을 시작하게 되는데, 그 결과가 바로 밑에서 소개해드릴 WebP 입니다.

WebP

WebP 는 Google이 WebM 포맷을 그대로 차용하여 만든 새로운 이미지 포맷입니다.  WebP가 나오게된 배경 및 그 특징을 정리하면 다음과 같습니다.

  • 웹 트래픽 69% 소비

앞에서 이야기 하였듯이, 웹 트래픽의 69%가 이미지 데이터 전송을 위해 이용됩니다.  이걸 줄이면 웹 트래픽을 줄일 수 있고, 특히 모바일에서는 웹 트래픽이 바로 고객의 돈이기 때문에, 이에 따른 파급효과가 매우 크다고 볼 수 있습니다.

  • WebP는 완전 공짜

 WebP는 원래 WebM의 Key Frame을 기반으로 한 것이라고 합니다.  따라서, Open Source이며, Loyalty Free 입니다.

  • JPEG/PNG 대비 높은 압축 효율

현재 Web 상에서 가장 많이 이용되는 PNG/JPEG을 대체할 수 있도록, Lossy/Lossless, Transparent/Alpha, Animation, Color Profile 등의 기능을 제공하고, 더불어서 3D Image 지원을 위해 Layer 기능도 지원합니다 (특히 Lossy 이면서 Transparent 를 제공하는 것 획기적이죠)  또한 Progressive Rendering도 당연히 지원합니다.  가장 중요한 내용으로, WebP가 동일 수준 JPEG/PNG 대비 각각 30%쯤 크기가 작다고 합니다.

  • 그러나, 속도는 아직…

앞에 이야기까지 들으시면 “이거 무조건 써야겠네”라고 느끼시겠지만, Google은 솔직하게 단점도 같이 설명해주고 있습니다.  단점으로, 일단 현재 WebP는 SW 인코딩/디코딩만 지원된다고 합니다.  이러한 이유로 인코딩 속도가 JPEG 대비 10배 쯤 느리답니다.  디코딩도 JPEG 대비 1.3배 느리고요.  사실 디코딩 속도가 그렇게 많이 느리지는 않으니 그나마 다행입니다만, 인코딩 속도는 매우 충격적입니다.  사실 이 정도 느리면, 단말에서 WebP 포맷의 이미지를 생성하는 식으로 당장 사용은 어려울 듯 하네요.

  • Container Overhead도 큼

또 하나 단점은, WebP가 PNG/JPEG에 비해 Container Overhead가 크다고 합니다.  그래서 아이콘 류의 작은 이미지는 오히려 기존 PNG보다 파일 크기가 커진다고 합니다.  따라서, 작은 아이콘을 많이 필요로 하는 앱은 차라리 PNG가 나을 수 있습니다 (물론, 아이콘 이미지를 다 모아 하나의 큰 이미지를 clip해서 사용하는 식으로 돌아갈 수는 있을 겁니다)

다음은 Issue 사항으로, WebP 포맷을 지원하는 브라우저가 현재는 Chrome/Opera 밖에 없습니다(PC).  모든 브라우저가 지원하지 않으니, WebP를 서비스에 이용하기 위해서는 서버에서 많은 추가 작업(기존 PNG/JPEG 이미지 포맷 변환 등)을 해야 합니다.  물론 이를 위해 Google에서 PNG/JPEG to WebP 툴 및 라이브러리를 지원한다고는 합니다.

Android 디바이스에서는 ICS 이상부터 지원(물론 SW 코덱만)한다고 하며, 일반 App.이 쓰려면 명시적으로  System.loadLibrary(“libwebp”) 이렇게 Native so 파일을 로드해서 써야 한다고 하네요.

제 판단에는 이미지를 많이 사용하는 서비스의 경우, 활용하면 좋을 듯은 합니다만, 그 경우 서버에 추가적인 작업(변환 작업 등)이 필요하다는 점을 꼭 명심해야 할 듯 합니다.

Powerful Tools!

HTML5가 등장하고, 대부분의 Mobile Web Browser가 이를 지원하기 시작하면서, HTML5 기술을 이용한 Mobile Web/Hybrid App. 개발 노력이 활발히 진행되고 있습니다.  물론 페이스북 같이 초기 Hybrid App. 형태로 서비스를 제공하다가 느린 속도 때문에 다시 Native 앱 형태로 돌아간 경우도 있지만, Web 기술의 Cross Platform 지원이라는 부분이 워낙 매력적이기 때문에, 아직까지도 많은 개발사가 Web 기술 기반의 서비스를 많이 내놓고 있습니다.

이러한 Mobile Web 기술의 확장에 발맞춰 기존 Web 컨텐츠 Authoring Tool 제공 업체에서도 대부분 Mobile Web 지원 기능을 추가 했습니다만, 한 가지 이슈를 아직까지 해결하지 못하고 있습니다.  그 부분은 바로 “개발자 확보” 부분입니다.

좀 뜬금없다고 느끼실 수도 있지만, 실제 개발 현장과 시장에서의 이해가 가장 많이 다른 부분이 바로 이 부분입니다.  많은 분들이 “Web은 쉽다”, “Web 개발자가 많다”라고 생각하고 계시지만, 실제로 “Mobile Web 기술을 이용하여 모든 Android/iOS 디바이스에서 안 느리게 구동되는 앱을 만들 수 있는 개발자”는 우리나라에 거의 없습니다.

그 이유는, 일단 HTML5가 최신 기술이라 익숙한 개발자가 거의 없고, PC 와 Mobile 의 특성이 매우 달라 PC Web에 능통한 사람도 Mobile에서는 100% 능력을 발휘하지 못하며, Web 기술은 JavaScript라는 스크립트 언어를 이용하는데, 이 언어가 기존 Java나 Objective-C와는 그 근본도 다르고, 사용법/디버깅 등이 그다지 용이하지 않아 기존 단말 개발자의 Web 개발자 전향이 어렵기 때문입니다.  즉, Mobile Web 기술로 모든 Android/iOS 디바이스에서 안 느리게 구동되는 앱을 만들 수 있으려면 HTML5 기술에 능숙하고, Mobile의 특성을 100% 이해하고 있고(기존 Native 앱 개발자면 좋겠죠) JavaScript라는 개발 언어에도 익숙해야 합니다.   제 주변에 이런 개발자는 정말 많지 않습니다.

이러한 고민을 계속 가지고 있던 중, 하나의 대안을 만나게 되었는데 그것이 바로 GWT 입니다.  GWT 는 Google Web Toolkit의 약자로, Java 기반 UI Toolkit이고, Java-to-JavaScript Compiler를 제공해서, 프로그램은 자바 언어로 만들고, Output은 Web Contents(HTML/CSS/JS)가 나오도록 하는 프로젝트 입니다.  예전에 Google Wave(지금은 Google Docs에 통합되었지만)가 이걸로 만들어졌었죠.   몇 년간 좀 잠잠하더니, 이번 Google I/O에서 Google이 GWT를 Mobile에 최적화한 결과를 소개하는 세션을 가졌습니다.이에 이 세션에서 얻은 정보를 일부 공유해드리도록 하겠습니다.

  • GWT는 이렇게 읽어요

GWT가 발음기호 상 [gwit] 입니다 (우리 말로 “그윗”이라고 읽으면 되는 듯 합니다)

  • GWT는 Open Source

GWT가 Community Process로 변경되었다고 합니다 (Google이 아니라 Open Source Committee 에 의해 운영됨) – Apache License 2.0

  • GWT Mobile

GWT Mobile 버전도 나왔고, Phonegap과도 결합이 되었다고 합니다 (밑에 사이트에 가보면 데모도 있습니다.  JQM이나 Sencha Touch 수준은 되는 듯 합니다)  자세한 내용은 다음 사이트 참고하시기 바랍니다 (mGWT:  http://www.m-gwt.com/ )

  • GWT Mobile Performance

GWT Mobile 버전은 다음의 방식을 이용해 획기적으로 Performance를 향상시켰다고 합니다 (물론 Compiler에 적용했겠죠)

  • DOM Element 개수 최소화 (DOM Element 개수가 너무 많으면 Mobile Web Browser에서 Rendering 속도가 느려집니다)
  • CSS tree 최적화 (DOM tree + CSS tree ==> Render tree 인데, 이 연산이 상당히 Computing power를 많이 소모하니, CSS tree도 최소화해야 한다고 합니다.  따라서 필요 없는 CSS 설정은 모두 다 제거했다고 합니다)
  • Native Layout 사용:  Native Layout이란, CSS를 이용한 Layout을 이야기 합니다.  CSS 기반 Layout을 하면, 이미 Browser Engine에서 이 부분을 Native Code로 최적화해 놓아서 상당히 빠르다고 합니다
  • Native Animation 사용: 이 또한 CSS Animation을 의미하는 겁니다.  Animation은 다 CSS로 만들었다는 거죠 (웬만한 위치이동, Transition, Transformation은 모두 CSS로 했다고 합니다)

GWT는, “자바” 언어를 사용하는 개발자들이 바로 “Web” 컨텐츠를 만들 수 있게 하여, 결국 Java 개발자 Pool을 웹 컨텐츠 개발로 흡수하고자 하는 목적으로 시작한 것입니다.  이러한 접근 방법은 다음과 같은 개발자 환경을 가진 조직에 의미 있을 듯 합니다.

  • Java 언어 사용자(Android 개발자, 서버 개발자 등)는 상대적으로 좀 있는 상황에서
  • Android/iOS 및 기타 OS들 타겟으로 앱 개발해야해서, 효율적인 앱 개발 방법이 필요한데(Multi-OS Support Needs 많음)…
  • 그 방법으로는 Web이 좋은 대안이나…
  • Mobile Web 개발이 쉬운 게 아니고,  Java 언어 사용자를 Web 개발자로 전환시켜서는 시간/비용 상 답이 없는 상황(사실 JavaScript는 Java와 아무 상관도 없고, 언어 종류도 dynamic/static 으로 완전 다릅니다.  또한 HTML/CSS도 결국 알아야 하고요)

이러한 환경을 가진 경우에는 GWT가 좋은 대안이 될 수 있으니, 긍정적으로 생각해보시기 바랍니다 (저희 회사도 내부적으로 검토 중에 있습니다)

More Energy-Efficient Mobile Web!

Mobile Network  최적화(배터리 및 Latency 측면) 관련 세션도 의미가 있어서 소개해드리려고 합니다.   다만, 결론부터 말하자면, 예전에 제가 번역했던 App Efficiency Guideline 과 내용은 동일합니다.

한 가지 특이한 사항으로는, 3G/4G는 구조 상 WiFi와 다르게 100ms 이내 RTT를 구조적으로 지원한다는 것이며, 따라서 소량 데이터 Push 케이스에 Reliability와 Latency가 다른 방식보다 훨씬 높다는 점입니다.   또한, at&t에서 Open Source로 만든 Application Resource Optimizer라는 툴이 있는데, 이 툴을 이용하면 실제 특정 시나리오에서 단말이 “네트워크 때문에” 얼마만큼의 전력을 소비하는지도 Emulation 할 수 있다고 하니, 이것도 관심있으신 분들은 한번 찾아 보시기 바랍니다 ( http://developer.att.com/devel… )   그 외 나머지 내용은 위의 기존 글을 참고하시면 될 듯 하네요.

It’s Quality and Speed, Stupid!

이번 Google I/O를 통해 명확히 드러난 점은, Mobile OS 시장이 성숙기에 접어 들었다는 사실과, 또한 Mobile 앱 마켓도 시장 성숙기에 접어들었다는 점입니다.  이로 인해, 서비스(특히 앱) 경쟁은 더욱 치열해질 것이며, 이 경쟁에서 살아남기 위해서는 고품질(빠르고, 빠르고, 빠른)의 앱을 매우 빠른 주기로 개발하고 업데이트 할 수 있어야 한다는 점은 이제 더 설명이 필요 없을 듯 합니다.  이 글을 통해 살펴본 Android/Mobile Web 진화 방향이 그러한 점을 뒷받침 하는 명확한 증거입니다.

그럼 다음 글에서 또 뵙죠. 🙂 이만… 쫑!

박창현 Master

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

Facebook 

공유하기