얼마전에 미국 실리콘밸리쪽으로 출장을 다녀왔습니다. 1월 말의 그곳 날씨는 우리나라 가을 정도의 기온인데, 비가 자주 옵니다. 잠깐 비가 그친 틈을 타서 저렴하게 골프 한번 쳐 보겠다고 근처 골프장에 갔습니다. 1번홀 플레이를 마치자마자 우박이 섞인 비가 오더군요. 도저히 지나가는 비처럼 보이지 않아서, 포기하고 프로샵으로 돌아와서 환불 협상을 하는데, 그쪽에서 컴퓨터를 이용해서 실시간 위성 이미지를 보여주면서, 지금 내리는 비가 요 구름인데, 곧 지나갈 것이니 조금만 기다려 보라고 하더군요. 아니나 다를까, 곧 비가 그치고 아름다운 쌍무지개가 떴습니다. 얼른 사진 몇장 찍고 나머지 라운드를 즐겼습니다. 날씨 정보가 아니었으면, 정리하고 돌아가는 길에 날씨가 개는 것을 보고 매우 아까워 했겠죠.
OHA(Open Handset Alliance: http://www.openhandsetalliance.com/)의 안드로이드 소스코드 (http://source.android.com/)를 이용해서 상용 제품을 만들다보면 겪는 아주 큰 어려움 가운데 하나가 바로 변화의 속도를 따라잡는 일입니다. 토끼와 거북이의 경주에 비교하자면, 안드로이드 개발팀 (구글 + OHA 멤버 + 오픈소스 커뮤니티)은 토끼라고 할 수 있죠. 2007년말의 첫 공식 발표이후 2009년까지 2년동안, 앞에서 폴짝 폴짝 뛰어가면서 며칠전 발표된 2.0.1 버전까지 진화를 거듭해왔습니다. 반면에 이를 이용해서 제품을 개발하는 제조사는 거북이의 입장이죠. 토끼가 앞서간 발자국을 따라서, 느릿 느릿, 하나씩 하나씩 내용을 이해하고, 포팅하고, 동작을 확인하고, 검증해서 제품을 내놓아야 하니까요. 당연히 가벼운 몸으로 뛰어가는 토끼에 비해서, 짧은 다리에 무거운 등껍질까지 이고 가니 따라가기가 영 버거운 것이 아닐겁니다.
게다가, 이 토끼란 녀석이 젊어서 힘이 펄펄 넘치는지 중간에 잠도 안자고 계속 내달리는 겁니다. 더 열받는 것은, 혼자 가기 심심한지, 딱 거북이 한녀석만 찍어서 같이 폴짝 폴짝 앞서간다는 거죠. 뒤에서 먼지만 풀풀 마시면서 낑낑거리고 따라가는 다른 거북이들에게는 영 입맛이 쓴 상황일겁니다. 근데, 어쩌겠습니까, 그 길로 가야 미래가 보인다니 뭐 어떻게든 따라가야 할 상황인거죠.
일반적으로 리눅스 기반 휴대폰의 개발 기간은 1년 정도를 잡는 것 같습니다. 피쳐폰의 경우 간단한 업그레이드나 지역향별 수정사항만 가하는 경우엔 6개월 이내에도 출시를 한다고 합니다만, 리눅스 기반 폰의 경우, 워낙 모델마다 변화가 커서, 기획에서 출시까지 6개월은 아무래도 무리죠. 6개월 정도를 상품기획, UI 설계, 기능 구현 정도로 잡고, 나머지 3개월에서 6개월까지를 검증과 IOT를 하게 되는 것 같습니다.
그런데 구글의 릴리즈 스케줄은, 뭐 딱 그렇게 규칙으로 정해진 것 같지는 않지만 1년에 2번 정도의 메이저 릴리즈를 생각하고 있다고 합니다. 올 봄에 1.5 (Cupcate)이 나왔고 가을에 1.6 (Donut)이 나왔죠. 현재 오픈소스로 Eclair 브랜치가 있긴 하지만 완전한 버전은 아닌 것 같구요. 그러면 이 상황을 제조사 입장에서 보면 이렇게 되는 겁니다:
지난 6월에 안드로이드 기반 휴대폰 제품 기획을 합니다. 1년후, 즉 2010년 상반기 출시를 목표로, 당시의 가장 최신 버전인 Cupcake 버전을 기반으로, 이런 저런 기능과 UI, 하드웨어 스펙, 디자인 등등을 열심히 의논하고 초기 개발을 시작하죠. 그런데 몇달만에 Donut이 보다 다양한 기능으로 무장을 하고 출시됩니다. 이미 기획이 되고 초기 개발이 진행된 상태라서, 제품의 근본 컨셉을 바꿀만한 변화 (예를 들어 HVGA => WVGA)는 좀 어려울지 몰라도, 소프트웨어의 경우엔 갈아타는 것이 가능하겠죠. 그래서 다시 몇달동안 열심히 Donut 기반으로 개발을 하면 12월 정도에는 설계 검증을 시작할 수 있겠죠. 즉, software는 feature complete이 되고, QA 과정에 들어가는 겁니다. 근데 지금 막 이야기가 나오고 있는 Eclair를 보니까 Exchange Server 지원에서 Google Maps Navigation에 최신 Bluetooth Profile 지원까지, 엄청난 변화가 보이는 겁니다. 이제 이러면 고민에 빠지는 거죠, 이걸 다 무시하고 그냥 QA를 밀어부쳐서 내년 상반기에 출시를 하자니, 그때는 Eclair뿐이 아니고 그 다음 버전인 Flan도 나와있을 확률이 높은데, 그 상황에서 Donut으로 출시해서 과연 상품성이 있을까 하는 걱정이 되는 거죠. 그렇다고, 현재 상황에서 Eclair로 갈아타자니 아직 Eclair가 안정화되지 않은 버전이라서 제품 출시 스케줄 자체가 나오질 않는 상황이구요.
남의 이야기라 저는 참 쉽게 말합니다만, 내년 1Q/2Q에 안드로이드 출시를 목표로 오늘도 개발실의 불을 끄지 못하고 계시는 분들 입장에서 Eclair의 현재 상황을 보는 심정이란, 참으로... 거시기 할겁니다...
이게 어떻게 보면 다른 개방형 플랫폼들 (iPhone, RIM, Palm, WinMo)과 비교되는 안드로이드의 가장 큰 단점일 수 있습니다. 물론 구글이라는 큰형님이 끌고 가긴 하지만, 그래도 50여개가 넘는 OHA 회원사의 다양한 협력 모델에다가, 오픈소스 커뮤니티의 개선 사항까지를 아울러서 소스트리를 관리하다보니, 특정 벤더 플랫폼처럼 로드맵 관리가 칼같이 되기 어려운 거죠. 라이센스 문제와 특허 문제에 기타 복잡하게 얽힌 이해관계까지 고민하면서 동시에 개발자들이 쓰기 편한 SDK와 플랫폼을 릴리즈 해야 하는 거니까요.
반면에 또 이걸 뒤집어서 생각해보면 안드로이드만의 가장 큰 장점이 바로 이 약간은 혼란스러워보이는 다양성에서 비롯되는 혁신이 아닐까 합니다. 정갈하게 차려진 한정식은 아닐지 몰라도, 고추장에 참기름 넣고 썩썩 비벼먹는 비빔밥의 맛이라는 게 또 있는 거니까요... ^^;
어쨌거나 현재의 안드로이드는 여전히 매우 빠른 속도로 진화중인 플랫폼입니다. 좀 고통스럽긴 하지만, 오픈소스 모델의 개방형 모바일 플랫폼의 미래를 믿는다면 따라갈 수 밖에 없죠. 구글이라는 회사의 비전과 능력, 그리고 2007년말 첫 발표이후 얼마전 모토롤라 드로이드의 출시까지 2년만에 이루어진 안드로이드의 발전 속도를 보면 충분히 기대할만하다고 하겠습니다.
일단 한가지는 인정하고 시작해야 하겠습니다. 안드로이드 기반 제품 개발은 쉽지 않습니다. 그냥 취미삼아 돌려보는 거라면 세상에 이것처럼 재미난 장난감이 없습니다만, 돈받고 팔수 있는 제품을 만들기에는 매우 신중한 접근과 많은 노력이 필요하죠. 이걸 한방에 해결해줄 묘책이 어디 있겠습니까. 관건은 개발 기간의 단축과 더불어 오픈소스 개발 모델에 대한 전략적인 접근이 아닐까 합니다. 제품의 기획과 디자인, 상위 레벨 설계에 많은 시간을 들여서 일관된 개발의 틀을 잡고, 최대한의 소프트웨어 테스트 자동화를 통해서 개발과 검증이 동시에 진행되어야 할겁니다. 더불어, 안드로이드의 오픈소스 개발 모델을 완전히 이해하고 최대한 활용해서, 어느부분까지를 제품 차별화에 필수적인 closed source로 가져가고, 어느부분까지를 전략적인 면에서 다양한 Ecosystem과의 공조를 통해서 open source로 가져갈지에 대한 진지한 고민이 필요합니다. 이런 식으로, 일차 개발 완료가 긴 여정의 시작이라는 것을 인지하고 과제를 기획할때 비로소 경쟁력있는 안드로이드 기반 제품의 개발이 가능하지 않을까 하는, 조심스러운 생각입니다.
안드로이드에 기반한 모바일 폰을 만들때 가장 고민되는 부분은 아마도 제품의 차별화라는 부분일겁니다. 그건 사실 Windows Mobile에서도 마찬가지였죠. Windows Mobile 6로 오면서 UI 변경이 허용되기 전까지는 시작 버튼으로 대표되는 윈도 모바일의 기본 UI에서 크게 벗어나기 어려웠던 까닭에, 어떤 제조사에서 만들어도 그냥 윈도 모바일 폰이지, 특정 회사의 색깔을 드러내기가 쉽지 않았거든요.
하지만 이제는 윈도 모바일에서도 UI의 변경이 자유로워지고, 여러 회사들에서 다양한 윈도 모바일 폰들이 나오는 모양입니다. 그런데, 과유불급이라는 말처럼, 최대한 삼성 터치위즈의 색깔을 살릴려고 했을 옴니아 2가 아래와 같이 최악의 평가를 받았습니다:
http://gizmodo.com/5417413/samsung-omnia-ii-review
(요기 http://moux.tistory.com/70 가시면 번역된 내용도 볼 수 있습니다.)
사실 저도 터치위즈의 큐브 써 보면서, 뭐 별로 실용적이지도 않고 잔뜩 멋만 내서 쓰기 오히려 불편하다고 생각했는데요, 이 리뷰에서는 "oh, that horrible fucking cube"라는 극단적인 표현을 써 가면서 원초적인 비난을 늘어놓네요. 전반적으로, 훌륭한 하드웨어 스펙에 비해서 소프트웨어가 완전 최악이다. 일관성도 없고, 느리며, 전체적으로 매우 쓰기 불편하다는 정도의 내용입니다.
근데, 사실 Gizmodo에서는 얼마 전에도 안드로이드 기반의 삼성 비홀드 2에 대해서 비슷한 수준의 평가를 내린 적이 있습니다:
http://gizmodo.com/5406912/samsung-behold-ii-non+review-oh-god-the-ugly
멀쩡한 안드로이드 표준 UI를 삼성 자체 UI로 완전히 망쳐놓았다는 평가입니다. 사실 정도의 차이는 있겠지만, LG도 자사의 S-class UI를 모바일 공통 UI로 미는 분위기입니다. 최근에 나온 LG의 안드로이드폰에도 비록 일부이긴 하지만 S-class UI가 적용이 되어 있죠. 근데 그거 써 본 느낌도, 삼성 터치위즈 UI와 크게 다르지 않더군요, 뭔가 따로 노는 듯한, 그리고 반응도 그리 매끄럽지 않은, 그래서 표준 안드로이드 UI보다 더 쓰기 불편하다는 느낌...
안드로이드 기반 모바일 디바이스를 만들때 제조사의 큰 고민이 바로 여기에 있습니다. 그냥 원래의 UI 그대로 Donut이던 Eclair던 수정없이 내 놓자니, 경쟁사와 다를 것이 없고, 그렇다고 자사 UI를 적용해보자니 안드로이드의 표준 UI 설계 철학과 너무 엇나가게 되서, 이도 저도 아닌 어정쩡한 제품이 나오게 되는 거죠.
아마도 삼성과 LG에서는 모든 모바일 디바이스에 사용 가능한 통합 UI의 환상을 버리고, 각각의 플랫폼에 맞는 최적화된 UI 전략을 새로 짜야 하는 것이 좋을지 모르겠습니다. 물론 자체 플랫폼의 경우 자사 UI에 최적화해서 만들면 되겠지만, 개방형 플랫폼의 경우엔 그 플랫폼에 맞는 UI가 필요하지 않을까요? 오히려 자체 통합 UI가 없는 회사의 경우, 디바이스에 맞는 적절한 UI를 새로 설계해서 잘 만들면 되는데, 대기업의 경우 기존 통합 UI를 고집하는 것이 독이 될 수도 있을 겁니다. UI는 단순히 홈스크린에 큐브 집어넣고 휠넣고 아이콘 배열하는 수준의 눈에 보이는 것이 전부가 아닙니다. 전체 모바일 소프트웨어 플랫폼을 관통하는 사용자 인터페이스의 철학이 있는 것이고, 이를 잘 살려가면서 UI 플랫폼을 설계할려면 그 소프트웨어 플랫폼의 UI의 기술적인 동작에 대한 깊은 이해가 필요합니다.
다시 저 위의 리뷰로 돌아가면, 개발팀을 잘게 쪼개서 각각 소프트웨어의 다른 부분을 맡기되, 절대 서로 이야기 하지 못하게 하면서 만든 것 같다고 평했습니다. 또, 몇분동안 사용해보면 전혀 알아들을 수 없는 여섯가지 서로 다른 언어로 외치는 소리에 둘러싸여있는 것 같다는 비유도 했습니다. 그래픽 디자이너들과 소프트웨어 개발자들이 같이 머리를 맞대고, 보다 나은 사용자 경험을 위해서 고민을 해도 잘 나올까 말까 하는 작업입니다. 말이 되지 않는 개발 스케줄에 이어지는 야근, 기획팀과 디자인팀 그리고 개발팀과 QA팀의 부조화, 게다가 개발 중간에 난데없이 날라오는 비 전문가들의 태클로 인한 낙하산식 소프트웨어 변경 사항들, 이런 것들이 위와 같은 사용자 경험으로 되돌아오는 것은 아닐까요?
앞으로 한국에서 만들어지는 안드로이드 기반 디바이스에, 정말 사용자의 경험을 진지하게 고려한, 개발자와 디자이너가 함께 고민한 흔적이 보이는, 그런 철학이 있는 UI가 탑재되기를 기대합니다.
