adsense(728_90)


WebRTC는 개방형 통신기술 IT


WebRTC의 RTC는 Real-Time Communications의 약자입니다.
말 그대로 WebRTC는 웹기반의 실시간 통신 기술이라는 의미인데요. 처음 이름을 들을 때 거부감이 들고(발음이 입에 좍좍 들러붙지 않아요) 오해하기 쉬운 이름이라고 생각합니다.
RTC가 언제 누구에 의해서 만들어진 용어인지는 확실하지 않으나 그 누구에게도 친근한 이름은 아니죠. 왜 이따위 이름을 지었을까요?

사실 저는 이 WebRTC를 종종 기술적으로는 Open Telecommunications (개방형 통신 기술)이라고 소개하기도 합니다.
왜냐하면 사실 WebRTC는 과거 몇십년동안 폐쇄적으로 운영되고 개발되어왔던 유무선 통신 및 VoIP통신 기술을 기반으로 하는
Telecommunication 기술과 별반 다르지 않기 때문입니다. 다만 codec과 미디어엔진 소스코드등이 모두 무료로 개방되었다는 것이 WebRTC와 여타 다른 통신기술과의 차이점이죠.

하지만 우리가 WebRTC를 개방형 통신기술이라고 이름붙일 경우에 그 파괴력은 WebRTC라고 불리울 때보다 훨씬 크다고 생각합니다. 왜냐하면 이미 국가산업에 의해 통신 기간망을 확보하여 사업을 하고 있는 세계의 수 많은 통신사업자들 입장에서는 너무나 파괴적인 시도이기 때문입니다. 그들이 WebRTC를 적극적으로 반대하리라는 것은 너무나 당연해보입니다.
저는 그래서 WebRTC의 이 발음하기 어렵고 오해하기 쉬운 이 이름이 좋습니다.(?)

사랑한다는 자백 Art and Life

사랑한다는 자백

저녁 늦게
어린 딸과 함께 연로한 부모님을 뵈었다.
갈수록 말을 듣지 않는 몸
아침이 오면 밤이 올 것
몸은 잘 아는데 마음은 잘 모른다.
더 늦기 전에 사랑한다 자백을 받으려
스마트폰 동영상 촬영을 하였다.
언젠가 몸은 가시더라도
마음은 자백 동영상에 남아
밤에도 낮이기를 마음은 바랄 뿐이다.


기술 중간 관리자의 탄생 IT

다른 직종과 다르게 유독 SW업은 기술 중간 관리자의 역할이 폄하되곤 한다. 개발자에 비해 그 실력을 증명하기 어렵고 사업부서에 비해서도 그 성과를 충분히 인정받기 어려운 점이 있다. 개발자들의 언어와 기술적인 이슈 그리고 사업부서의 언어와 사업적 이슈를 모두 어깨에 짊어지고 Software Quality와 Business Success를 모두 이끌어내야 하는 기술 중간 관리자는 요즘과 같이 스타트업에 의한 성공이 유행인 시대에 그 존재감이 더더욱 희미하다. 자유로운 소통을 막는 걸림돌로까지 여겨진다. 그만큼 기술이 좋아져서 생산성이 높아졌고 소통에 필요한 비용이 줄어들었다.

더구나 덩치 큰 SW보다는 기능은 단순하지만 핵심에 집중하는 UX를 가진 가벼운 SW가 선호되면서 그루급의 기술 중간 관리자들이 진두지휘하면서 다수의 개발팀을 이끌만한 매력있는 프로젝트도 많이 줄어들었다. 수많은 기능과 요구사항을 만족하는 아름다운 아키텍처를 그리는 사람보다는 작지만 중요한 기능 몇개라도 직접 개발할 수 있는 고참 개발자가 대우받을 수 밖에 없는 세상이다.

하지만 소프트웨어가 항상 스타트업 상태로만 머물 수는 없고 사람도 스타트업으로만 전전할 수는 없다. 사업이 번창하여 exit하든, 망해서 그 사람들이 기성 조직으로 이직하든, 나이들고 체력이 떨어져서 결국 포기하든 어쨌든 스타트업의 핫한 사람과 핫한 소프트웨어와 핫한 작은 조직은 결국 더 큰 조직에 들어가야만 한다.

그리고 진짜 싸움은 거기서 벌어진다. 진짜 수익과 매출로 증명해야 하는 사업적 성공과 더 차원 높은 안정적이고 경쟁력있는 기술, 그리고 조직 내외에서 이겨내야만 하는 정치와 같은 또 다른 여러가지 진짜 도전에 직면하지 않을 수 없다.
선택의 순간이 개발자를 다시 기다린다. 그 모든 도전을 무시하고 개발 자체만 할 수 있는 역할을 찾던가 아니면 이 도전을 받아들이던가.


NHN NEXT에 대하여 IT

회사에서 주최한 공모전에서 입상한 분 중 NHN NEXT 학생이신 김희재라는분이 있었습니다.
PlayRTC를 사용한 위치기반 파일 공유 서비스였고 제가 개인적으로 너무 좋아하는 스타일의 서비스여서 PlayRTC.com 블로그에 실을 목적으로 NHN NEXT에 직접 김희재님을 뵈러 갔습니다.

인터뷰 내용은 주로 WebRTC나 PlayRTC에 대한 내용이었지만 그 외에도 NHN NEXT에 대한 내용이 많았습니다. 그리고 김희재님을 통해서 NHN NEXT이 현재 처한 안타까운 상황에 대해서도 들을 수가 있었습니다.

저는 사실 현재 NHN 경영진이 NHN NEXT를 어떻게 변화시키려는지는 자세히 알지 못합니다. 다만 이번에 NHN NEXT의 생활공간을 직접 살펴보고 그곳에서 2년간을 살아온 김희재님과 대화를 하면서 NHN NEXT의 지난 2년은 결코 실패하지 않았고 앞으로가 더욱 더 기대된다고 생각할 뿐입니다.

NHN NEXT를 방문하여 여기 저기 살펴보면서 처음 느낀 것은 '자유로움'과 여기야 말로 IT엔지니어들이 꿈꾸던 '지적 공동체'구나! 였습니다. 공간을 보면 그 공간에 있는 사람들이 어떻게 생활했을 지 한 눈에 보이는 경우가 있습니다. NHN NEXT에서 학생들은 서로 다른 관심분야를 가지고 프로젝트를 만들고 아이디어를 공유하고 언제나 손닿을 공간에 있을 교수님과 밤새 토론합니다. 여기에서 학생들은 시간을 잊습니다. 그렇게 2년간을 행복하게 보냈을 김희재님을 생각하니 너무나 부럽기 그지 없었습니다.

김희재님은 이번주부터는 NHN으로 입사하였다고 합니다만 아직 졸업하지 못한 NHN NEXT 2기분들 걱정을 많이 하였습니다. 그 분들이 부디 이 IT인들의 꿈의 학교에서 더 오래 오래 있었으면 하는 마음을 가지고 있었습니다.

저 역시 만약 이 꿈의 학교가 사라지거나 축소된다면 너무나 안타까울 것 같습니다. NHN NEXT 화이팅입니다.

하모니카 OS에 대하여 IT

2014년 8월부터 11월까지 NIPA(정보통신산업진흥원)에서 총 2억원을 들여서 개발한 리눅스민트를 기반으로 하는 한국형(?) OS.
이 소식을 처음 접하였을 때에는 그래도 군기관이나 기타 여러 정부기관등에서 사용할 의지를 가지고 만들었을거라 기대하며 응원의 마음을 가지고 있었다. 리눅스민트는 우분투계열중에서도 가장 사용자가 많은 성공적인 배포판이기 때문에 이걸 이용해서 대체 얼마나 더 좋게 한국화시켰는지도 내심 기대되었다. 자그마치 2억이나 투자되었으니 당연히 남다를 것이라고 생각했다.
그래서 한번 설치해보고 기존의 리눅스민트와 비교를 해보았다.

1. 리눅스 민트와 다른 점을 찾기가 어렵다.
물론 한글입력기가 기본으로 설정되어 별다른 작업없이도 설치하자 마자 바로 한글을 쓸 수 있다는 점에서는 높은 점수를 주고 싶지만 그것 외에는 별로 다른 점, 혹은 하모니카OS의 identity가 없었다는 점이 너무 안타깝다. 아래 캡쳐화면에서도 나오지만. 하모니카 OS만의 약간의 테마가 적용된 것을 제외하면 기존의 배포판과 별다른 차이를 느낄 수 없었다. 최소한 하모니카OS만의 소개글이나 도움말이라도 있다면 좋겠는데 리눅스민트의 identity를 그대로 드러내고 있어서, 개인이 작업해서 공유하는 우분투 배포판과 어떤 차이가 있는지 모르겠다. 아무런 이득을 바라지 않고 한글 잘되는 우분투 배포판을 제작하는 분들이나 우분투 한글화에 봉사하는 마음으로 참여하는 분들이 허탈해하지 않을까 하는 생각을 해본다.


2. 사이트 운영의 문제
두번째 우려되는 점은 하모니카 사이트의 운영 주체가 누구인지, 12월 정식 배포 이후 어떤 계획을 가지고 있는지 하나도 언급되지 않고 있다는 점이다. 홈페이지는 마치 SI프로젝트 완료 산출물 보여주듯 꾸며져있다. 대체 하모니카의 주인은 누구일까? 그리고 어떤 계획으로 이 OS가 만들어질까? 왜 2억원의 국가 예산은 쓰여졌을까?

3. 결론
하모니카는 아직 베타버전이고 12월말에 정식 오픈할 예정이다. 따라서 이번 버전만 가지고 섣부른 판단을 해서는 안될 것이다.
아무튼, 굳이 안해도 되는데도 불구하고 하모니카를 설치해서 민트와 비교까지 해본 이유는, 출시전부터 지속된 사람들의 부정적인 판단때문이었다. 그래도 나름의 애정을 가지고 만들었을 작업에 대해 세간의 평이 너무 안좋았기에 조금이라도 애정을 가지고 설치까지 해보고 장점을 찾아서 글을 남기려고 했는데, 생각보다 많이 실망하였다.
일단 리눅스민트와의 차별성을 발견하기가 너무 어려웠다는 점이 크지만, 그래도 설치하자 마자 잘 적용되는 한글입력기가 나름 맘에 들었기에 넘어간다치자.
그럼에도 불구하고 가장 아쉬운 점은 이런 프로젝트의 생명이 단기적인 산출물보다는 지속적이고 협력적인 프로세스 및 체계에 있다고 보는데, 그런 부분이 전혀 보이지 않는다는 점이 무엇보다 아쉽다.

Physical Web에 대하여 IT

IoT 혹은 WoT의 두가지 접근 방법

Internet of Things를 접근하는 방법을 크게 두 가지 부류로 나눌 수 있다. Thing에 초점을 맞추는 방법과 Thing보다는 Internet에 초점을 맞추는 방법이다.
Thing에 초점을 맞출 경우 Thing은 파워풀해지고 다양성을 지니게 된다. 즉, Thing이 Fat Thing이 되어가게 된다. 바보 Thing에 센서를 달고 마이크로칩을 달고 모니터를 달고 심지어는 인텔리전트한 능력까지 스스로 갖추게 하려 한다.
반면에 IoT에서 Internet에 더 초점을 맞추면 Thing은 Internet에 접근하기 위한 최소한의 것만을 수행하고 나머지는 Internet 혹은 클라우드가 맡게 된다. 즉, Thing은 저렴하고 가벼워진다.
전자의 방식은 스타트업이나 전자쪽에 강점이 있는 곳에서 좋아한다. 반면 후자의 방식은 이미 인터넷이나 모바일쪽에서 클라우드 기반의 플랫폼을 갖추고 있는 사업자들이 좋아한다. 구글, 애플등이다. 애플은 이미 iBeacon 스펙을 공개하였다. 어떤 Thing이라도 BLE기반의 iBeacon규격을 맞춘 서비스를 하는 것은 그리 어렵지 않다. 



위의 그림 중 왼쪽의 것이 바로 Thing의 기능을 최소화하고 대신에 Thing에 대한 정보를 처리하거나 비즈니스로직을 담고 있는 클라우드의 기능이 중요한 애플의 iBeacon방식이다. 그리고 이번에 구글에서 조금 어설프고 못생겼지만 비슷한 기술이 출현했다. 바로 Physical Web이다.


Physical Web의 기본 개념
앞서 그림에서 설명한 대로 Physical Web은 Thing에 소형의 저렴한 BLE칩을 설치하고 오로지 자신의 URI정보만을 broadcasting 한다. 따라서 Thing에 투자할 비용을 최소화할 수 있다. 또한 이 Thing의 URI정보를 스마트 디바이스에 선 탑재된 Physical Web Agent가 수신하여 사용자에게 알려준다. 현재 이 앱은 PlayStore에서 다운로드받을 수 있으며 소스코드 역시 다운로드 가능하다. 향후에 구글이 정말 이 Agent를 안드로이드 기기에 탑재할 지는 알려진 바없으나 정책의 문제일뿐 기술적으로는 아주 단순한 편이다. Physical Web Agent는 수신한 URI들을 정렬하거나 더 자세한 meta데이타를 수신해서 사용자 context에 맞게 보여줘야 한다. 따라서 URI들의 metadata나 비즈니스 로직을 담고 있는 Thing Server에 접근하여 추가적인 Thing정보를 가져온다. 이 Thing 서버는 오픈되지 않았으나 규격은 나와있으므로 업체마다 구현하면 되는 부분이다.
매우 단순한 개념으로 출발한 프로젝트이며 근본적으로 애플의 iBeacon 규격과 크게 차이가 나는 부분은 없다. 다만 iBeacon이 BLE 신호에 UUID값으로 beacon의 identity를 나타낸다면, Physical Web에서는 UUID가 아닌 20byte의 URI정보로 나타낸다는 것과 Thing서버를 통한 데이터 송수신 인터페이스를 규격화한 점(그래봤자 JSON덩어리를 송수신하는 단순한 것이긴 하지만). 그리고 단말에 탑재되는 agent를 공개했다는 것이 다른 점이라면 다른 점이다.

Physical Web에 대한 오해와 한계
Physical Web에 대해 사람들이 오해하는 것은 모든 것이 웹을 기반으로 동작한다고 생각하는 것이다. 사실 엄밀하게 말하면 BLE가 송신하는 identity정보를 URI로 표현한 것을 제외하면 어떤 것도 웹과 밀접하게 관련있는 것은 없다고 할 수 있다. 스마트디바이스에 탑재된 agent도 결국 native app이며 그 app이 사용자에게 보여줄 최종 컨텐츠 역시 굳이 웹일 필요는 없다. Physical Web의 Thing URI는 Deep link 즉, 앱컨텐츠도 지원하고 있기 때문이다.
또한 구글이 뭔가 전략적으로 이 Physical Web을 추진하고 있다는 언론의 설레발에 너무 흥분할 필요도 없다고 생각한다. 위에서 언급한 이상의 뭔가 구글의 대단한 awesome한 것이 탑재되어 있는 상태는 현재까지는 아니기 때문이다. 아주 초기 단계 프로젝트일 뿐이다. 이게 의도대로 잘 커나가면 구글에서도 뭔가 본격적으로 자신들의 전략에 넣겠지만, 미래는 알 수 없다.

그럼에도 불구하고 의미있는 것
Thing과 사용자간의 통신 규격이 Physical Web에서와 같이 단순해지면 결국 Thing서버의 역할이 매우 중요해진다. 구글의 경우 저 Thing 서버를 구글 나우가 대신해 줄 수 있을 것이다. 즉, 구글이나 애플같은 플랫폼사업자들이 궁극적으로 IoT시대에 원하는 아키텍처가 무엇인지 명확해졌다. Thing은 최대한 단순화 경량화 시키고 그 외의 모든 비즈니스 트랜잭션은 자신들이 이미 확보한 모바일 플랫폼과 클라우드를 중심으로 돌아가게 하기! 이것이 그들의 전략이다.

직접 사용해보기
Physical Web Agent를 다운로드받는 것은 그냥 PlayStore에서 할 수 있고 필요하면 소스코드도 공개되어 있다. Beacon을 만드는 것이 관건인데 Bluetooth가 되는 리눅스 랩탑이 있다면 Beacon을 만들 수 있다. 좀 그럴듯하게 하려면 RFDuino나 라즈베리파이+BT Dongle로 Beacon을 만들 수 있는데, 여기서는 라즈베리파이+BT Dongle로 Physical Web Beacon을 구축하는 방법을 공개해본다.

준비물: 라즈베리파이 b+, Bluetooth USB Dongle(싼거 아무거나)
1. 라즈베리파이에 BT 모듈을 설치해야 한다.
2. 라즈베리파이에 node.js를 설치한다.
3. 블루투스 관련 모듈을 좀 더 설치한다. sudo apt-get install bluetooth bluez-utils libbluetooth-dev
4. Bluetooth USB Dongle을 삽입한다.
5. Physical Web node.js 소스코드를 다운로드받아서 라즈베리파이에 설치한다.
6. 해당 node.js 소스코드 디렉토리에 bleno를 설치한다. npm install bleno
7. Physical Web node.js 들을 하나씩 실행해본다.
8. 안드로이드 스마트폰에서 Physical Web agent를 설치하여 확인한다.

웹앱의 개념과 전망 IT

앱(App)이란 무엇인가?

앱(App)은 Application을 뜻하는 IT인들의 은어(Slang)였다. 적어도 2000년대 중반까지는 그랬다. App이라는 단어가 갑자기 대중성을 획득한 것은 애플 아이폰의 AppStore의 등장과 함께라고 할 수 있는데, 미국 방언 협회(America Dialect Society)가 2010년 App을 올해의 단어로 선정한 것은 비록 App이 신조어는 아니지만 앱스토어라는 새로운 시장과 함께 대중들에게 가히 폭발적으로 새롭게 다가온 용어이기 때문이었다. 즉, 원래 App이라 함은 그저 '특정 OS에서 실행되는 프로그램 혹은 애플리케이션의 준말'이었으나 대중들이 이해하는 App은 'AppStore에서 다운로드받는 프로그램'이 되었다.
다시 말해 앱(App)은 단순히 특정 OS에서 실행되는 Application의 준말이 아니라 '특정 유통플랫폼을 통해 접근하거나 다운로드할 수 있는 프로그램'으로 의미가 변하게 되었다.

네이티브앱(NativeApp), 하이브리드앱(HybridApp) 그리고 웹앱(WebApp)

원래 네이티브앱이라는 용어는 아이폰에서 없었다. 2007년 초반부터 일반 앱개발에 웹기술을 활용한 방법이 나오자, 순수한 네이티브 코드로 작성한 앱과 Webkit기반 웹기술을 일부 활용한 앱을 기술적으로 구분하기 위해 네이티브앱(NativeApp)과 하이브리드앱(HybridApp)으로 나눠 부르게 되었다. 특히 안드로이드기반 앱시장이 활성화되면서 개발자들이 플랫폼 종속성에 따른 개발비용을 줄이고자 이러한 하이브리드앱을 이용하게 되었고 Phonegap이라는 걸출한 프레임워크의 등장과 함께 하이브리드앱은 지금까지도 널리 채용되고 있는 개발방식이 되었다.
자연스럽게 사람들은 모바일에 최적화되어 보여지는 웹사이트인 '모바일웹'을 HTML5 기술의 대두와 함께 논의하기 시작했고 논의의 방향은 구글의 크롬OS(Chrome OS)의 대두와 함께 Web OS기반의 웹앱(Web App)으로 흘러가기 시작했다.
기술적인 구현 방식에서는 '모바일웹'이나 '일반 웹애플리케이션'이  '웹앱'과 큰 차이가 나는 것은 아니지만 유통플랫폼 여부에 따라 그것을 부르는 용어가 나뉘게 된다. 즉 웹앱은 애플의 AppStore와 유사한 어떤 특정 유통플랫폼을 통해 접근 및 사용이 가능한, 다양한 플랫폼에서 실행될 수 있는 웹 애플리케이션이라고 정의할 수가 있다.

웹앱의 생사는 유통플랫폼이 쥐고 있다

대체 앱에 있어 유통플랫폼은 무엇인가? 간단히 말해 앱의 생산자와 소비자를 연결시켜주는 시장이라고 볼 수 있다. 앱 이전의 세계에서 이것은 막연하나마 포탈서비스와 검색서비스가 담당했다. 하지만 이것은 매우 느슨한 시장이었다. 웹에는 소수의 값진 컨텐츠와 대다수의 쓰레기가 공존하는 세계였고 나쁜 의미에서든 좋은 의미에서든 내가 원하는 정보를 찾기 위한 웹서핑과 구글링이 필요한 세계였다. 그러나 애플이 앱스토어를 고안하면서 새로운 프리미엄 유통모델이 생겨났다. 앱스토어는 생산자와 소비자간에 편리한 결제방법을 제공하였고 단일 마케팅 창구를 마련해주었다.
흥미로운 점은 사람들이 무형의 컨텐츠를 구매하는 것에 저항감이 없어진 문화이다. 심지어는 너무나 단순한 방구뀌는 앱 하나가 엄청난 인기와 함께 개발자를 돈방석에 앉히는 일까지 벌어지면서 소비자는 사소한 컨텐츠에도 앱스토어에서는 선뜻 지갑을 여는 행위를 하게 되었고 개발자 입장에서는 더더욱 이 유통플랫폼에 기반한 앱을 개발하는 데 열정을 품게 되었다. 디지털 컨텐츠 유통의 새로운 문화가 만들어진 것이다.
웹앱의 개념은 바로 애플이 만들어낸 이 새로운 유통문화를 등에 업고 탄생했다. 웹기술과 함께 마켓플레이스를 제공하면 특정 OS플랫폼에는 종속되지 않으면서도 개발자에게는 더 빨리 개발할 수 있는 환경을 제공하면서 수익 또한 제공할 수 있는 터전이 생긴다. 웹앱이 기존의 웹과 미묘하게 다른 점은 결국 별도의 유통플랫폼이라는 시장이 있다는 것. 따라서 유통플랫폼의 매력도가 웹앱의 생사를 결정한다고 해도 과언이 아니다.

유통플랫폼으로서의 구글 크롬 마켓과 Firefox OS의 마켓플레이스

웹앱의 특성상 브라우저 혹은 브라우저 기반의 OS가 기술적인 관점에서 매우 중요한 요소일지라도 그것이 웹앱의 성공 여부를 결정짓는 절대적인 기준은 될 수 없다. 소비자는 이미 프리미엄 컨텐츠와 고급화된 UX의 유통방식에 익숙해져있고 이런 소비자의 눈높이를 맞춰주는 것은 브라우저의 기술적인 성숙도가 아니라 웹앱만이 제공할 수 있는 유통플랫폼에서의 진화된 무언가일 것이다.
이런 측면에서 구글 크롬의 웹스토어와 Firefox OS의 마켓플레이스는 기존의 앱스토어나 구글플레이와 거의 동일한 방식을 취하고 있다. 사용자는 마켓에서 검색을 하고 앱의 정보를 확인한 후 다운로드한다(웹앱의 경우 실제로 앱을 다운로드하는 것은 아니지만 사용자 경험 측면에서는 매우 유사한 행위를 보인다). 두 플랫폼 모두 특정 사용자 Identity 체계를 제공하고 Firefox OS의 경우에는 결제API를 제공하고 있다. 엄밀하게 말해 기존의 모바일OS기반의 유통플랫폼과 다른 점을 찾아볼 수 없다. 여기서 다음과 같은 질문을 던져볼 수 있다.
동일한 유통플랫폼 UX/서비스를 제공하는 상황에서 소비자는 어떤 시장을 선택할 것인가? 앱자체의 성능이 네이티브보다 더 뛰어나지도 않고 시장 접근성도 기존보다 편리하지 않다면 왜 소비자는 웹앱을 선택해야 하는가?

소비자에게 웹앱은 앱의 짝퉁일뿐인가?

이 질문은 웹앱 신봉자에게 있어서 상당히 뼈아픈 질문일 수 있다. 아직까지 확실한 답을 줄 수 없기 때문이다. 개발생산성과 플랫폼 독립성 등 생산자관점의 장점을 아무리 피력한들 그것만으로 이미 성공한 시장과 경쟁할 수는 없다.
그럼에도 불구하고 여전히 웹앱이 지금보다 더 나은 무언가라고 믿고있다면 이제까지의 웹앱의 행보에서 뭔가 간과되고 있는 점을 찾아야한다. 우리가 놓치고 있는 점은 왜 웹앱은 앱이 되려하는가이다. 즉, 앱과 같은 방식의 경쟁으로 웹앱은 앱을 이길 수가 없다는 점이다.
잊지 않았을 것이다. 15년전 웹이 Rich Client 애플리케이션 기반의 세상을 어떻게 바꾸었는지를. 그 당시 웹은 C++과 VB로 만들어진 Rich client들과 성능으로 경쟁하지 않았다. 사람들을 광활한 네트워크에 흠뻑 적시게 하고 뛰어난 확장성과 연계성 그리고 단순하고도 표준화된 UX가 사람들을 웹의 세상으로 이끌었다.
웹의 성공 요인들을 그대로 담아내면서 다운로드받아 실행하는 Rich Client만의 장점을 그대로 살려 프리미엄 유통마켓 위에 등장시킨 앱(App)을 웹앱은 어떤 가치를 더 담아서 새로운 시대를 열 수 있을까?

앱의 태생적 한계, 폐쇄성

위의 표는 KTH에서 2012년 3분기에 조사한 구글 플레이 사용자가 설치한 앱의 개수를 나타낸 표이다. 다수의 사용자는 10개 이하의 앱만을 사용하고 대부분의 스마트폰을 10여개의 앱이 제공하는 울타리 안에서 정보를 소비한다. 더구나 다수의 소비자는 초기에 스마트폰을 구매 후 한달이 지나면 마켓에 접속하는 횟수가 급격하게 줄어든다. 결국 유명한 앱 몇 개만이 다수의 사용자의 눈과 손을 독점하고 있다. 지금도 앱마켓에서는 이 소비자의 10개의 자주 쓰는 앱목록에 들어가기 위해 다른 70만개의 앱들과 치열한 경쟁을 벌이고 있다. 즉 앱의 세계에서 하나의 앱은 다른 모든 앱과 사용자 독점을 위한 완전 경쟁 관계에 있다.
하지만 웹은 다르다. 웹의 세계에서 하나의 서비스나 페이지는 전혀 다른 서비스나 페이지와 연결되면 연결될수록 그 가치를 인정받고 생명력을 얻게 된다. 웹에서 모든 페이지는 다른 모든 페이지와 기본적으로 공생관계에 있다(비록 국내 몇몇 포털의 경우는 예외이지만). 이러한 큰 차이는 웹이 앱에 비해 가질 수 있는 근본적인 장점일 것이다.

멀티 OS, 멀티 디바이스 그리고 ∞-Screen

앱은 데스크탑 모니터보다 작은 제한된 스크린에서 터치기반의 rich한 경험을 제공하는데 최적화된 형태로 개발된다. 때문에 앱 개발 방식은 단말 스크린이 파편화되면 될 수록 한계를 들어내게 된다. 애플은 이를 막기 위해 많은 노력을 하고 있고 안드로이드 계열에서는 이 파편화로 적지않은 부담을 개발자에게 안기고 있다. 하지만 문제는 지금 이후다. 제3의 OS를 꿈꾸는 Tizen과 Firefox OS, Ubuntu OS, Chrome OS 등의 새로운 OS의 등장으로 멀티 디바이스, 멀티 OS의 시대가 열리고 있고 구글 글래스나 애플 iWatch 그 외 수없이 많은 Wearable Device와 임베디드 기기등의 출현은 N-Screen의 시대를 넘어 ∞-Screen의 시대를 예고하고 있다. 즉 극단적 파편화의 시대를 막을 방법은 없다. 이를 위한 대안 중의 하나는 웹이고 그러한 시대적 흐름의 끝에 웹앱이 존재하고 있지 않을까?

모바일 OS의 혁신 정체와 팬덤현상의 해체

2013년 이상한 현상이 일어났다. 브랜드 가치에서 '갤럭시'가 '안드로이드'를 넘어선 것이다. 애플은 아이폰5 출시를 기점으로 주가가 급전직하한다. 모바일 OS의 혁신은 더 이상 없고 사람들은 점점 디바이스의 스펙에만 겨우 관심을 기울인다. 2013년 이전까지는 제조사가 모바일OS의 진화와 혁신을 따라가는 입장이었다면 2013년은 모바일OS가 제조사의 발전에 발목을 잡고 있는 것처럼 보인다. 이것은 삼성에게 있어 아주 단기간의 꿀맛과 같은 현상일 뿐이다. 머지않아 발전만 있고 혁신이 없는 모바일OS의 스마트폰의 스펙 경쟁은 가치를 상실할 때가 올 것이다. 이미 갤럭시3는 쿼드코어AP를 탑재했다. 이런 속도면 몇년만 지나면 우리는 20개의 코어가 집적된 AP를 맞이하게 될지도 모른다. 과연 우리가 20개의 코어가 필요한 시대에 살게될까? 그보다는 이 집적된 기술을 다양한 소형 디바이스에 이식하여 새로운 디바이스간 네트워크가 중요해지는 새로운 혁신을 맞이하게 되지 않을까?
앞서 언급한 대로 모바일OS에 특화된 것이 앱이라고 한다면 모바일OS의 혁신이 끝나고 약간의 시장변화만으로도 앱의 위치는 지금과는 다르게 매우 초라해질 것이고 Screen과 디바이스의 다양성이 있는 혁신의 중심에는 분명 웹앱이 자리잡고 있을 것이다.

앱의 최소단위와 최대단위는 앱, 규모의 경직성

많은 Provider들의 노력에도 불구하고 앱의 개발비용은 낮지 않다. 1인개발자가 앱개발로 밥벌이하는 건 이제 낭만적인 이야기일 뿐, 정확한 시장 예측 및 대응과 적절한 팀이 없이는 완전경쟁 앱스토어에서 살아남기 어려운 것이다. 이러다보니 컨텐츠의 내용보다는 컨텐츠를 담고 있는 앱의 완성도가 앱의 성공을 좌우하는 경우가 많다. 결국 앱이라고 하는 무형의 생산자는 개별 컨텐츠 소유자가 아닌 개발자이거나 여러 개발자와 자본을 모두 가진 기업이다.
앱을 아무리 최소한으로 개발해도 앱이고 앱을 아무리 무겁게 만들어도 앱이다. 즉 앱의 최소,최대 단위는 모두 앱으로 귀결된다. 이러한 규모의 경직성으로 인해 소소하지만 분명한 경쟁력을 가진 1인 컨텐츠 보유자들의 시장 참여가 매우 힘들었다.
이러한 앱 유통플랫폼의 한계를 뛰어넘고 새로운 시장을 개척하려는 움직임은 이제 조금씩 일어나고 있다. 국내에서는 카카오 페이지가 이러한 보다 경량의 컨텐츠 제공자들이 참여할 수 있는 시장을 열었으며 외국에서도 교육 컨텐츠에 대한 다양한 소셜기반 마켓플레이스가 시도되고 있다.

그리고 더 나은 유통플랫폼

앞서 웹앱이 네이티브기반 앱을 뛰어넘을만한 몇가지 단초가 될만한 요소들을 살펴봤다. 하지만 가장 중요한 것은 소비자와 생산자를 연결시켜주는 유통플랫폼의 혁신이다.
유통플랫폼의 핵심은 결제와 인증 그리고 기반이 되는 OS플랫폼이다. 앞서 주장한 바와 같이 OS플랫폼 자체의 경쟁력은 애초에 웹이 네이티브에 역사적으로 한번도 이겨본 적이 없다. 웹앱이 애플과 구글의 유통플랫폼과 경쟁에서 이기려면 OS플랫폼이 아닌 결제와 인증 그리고 그 이상의 새로운 혁신 즉 판을 뒤엎을 무언가일 것이다. 그 혁신이 무엇일지는 정말 많은 고민과 통찰이 필요한 일이라고 생각한다.


1 2 3 4 5 6 7 8 9 10 다음


Google Analytics