Category: 기술 이야기

비트코인 경제학

몇 주 전부터 미국 각종 언론에 비트코인 이야기가 정말 많이 등장하더니, 계속해서 비트코인의 가격이 최고가를 기록했다는 소식이 들린다. 땡스기빙 휴가 이틀째인 엊그제(11월 29일)는 비트코인의 가격이 1,242달러에 달해, 1온스당 1,250달러에 거래되는 금값에 가까워졌다. 비트코인의 시장 가치가 일시적으로 1,000달러를 넘은 후 단 이틀만의 일이다. 지난 4월에 비트코인 가격이 200달러로 급등하면서 언론에서 갑자기 비트코인 이야기를 많이 했던 적이 있었다. 그러나 직후 다시 가격이 절반으로 떨어지면서 비트코인이 과연 신뢰할 수 있는 통화 수단인가를 놓고 많은 사람들이 의견을 내놓았었는데, 오랫 동안 200달러를 회복하지 못하다가 지난 한달간 갑자기 6배 이상 급등하면서 1,200달러를 넘은 것이다. 13달러였던 1년 전에 비해서는 거의 100배 상승한 가격이다.

비트코인 가격
지난 1년간 비트코인 가격 변동 추이. 1년 전 가격은 13달러에 불과했다. (출처: http://blockchain.info/charts/market-price)

이제는 눈에 보이지도 않는 비트코인 한 개를 소유하기 위해 1,000달러 이상을 내야 한다. 비트코인의 수는 꾸준히 증가하고 있는데, 총 통화량(Circulation)에 가격을 곱하면 비트코인의 ‘시가 총액(market capitalization)이 나온다. 현재 통화량이 1200만개 가량 되므로, 시가 총액은 무려 15 billion USD, 즉 17조원에 달한다. 무시할 수 없는 경제 규모다.

비트코인
지난 1년간 비트코인 시가 총액 (Market Capitalization) (출처: http://blockchain.info/charts/market-price)

비트코인 가격이 급상승한 이유

지난 11월 13일, 비트코인 가격이 급등해 400달러를 초과하던 시점, bitcorati라는 비트코인 사업 디렉토리 사이트에 ‘비트코인 가격이 급등하는 10가지 이유‘라는 글이 올라와서 재미있게 읽은 적이 있다. 아래에 몇 가지만 간략히 정리해 보겠다.

  1. 미국 FBI가 비트코인을 통한 불법 마약 거래를 하던 실크로드(Silk Road)라는 웹사이트를 폐쇄했다. 26,000개의 비트코인을 압수. 비트코인 상거래 사이트가 폐쇄되었는데 왜 비트코인의 가격이 올라가나 싶겠지만, 이 때 비트코인 가격이 일시적으로 내려갔다가 다시 올라가는 것을 보고 투자자들이 비트코인이 마약 거래에만 쓸모있는 것이 아니라는 것을 알았기 때문이다.
  2. 중국의 거대한 수요. BTC China라는 중국의 비트코인 거래소에 거래가 몰리고 있다. (실제로 비트코인 총 거래량의 60% 이상이 BTC China를 통해 이루어지고 있다고 한다. ‘세계의 공장’이 된 중국에 막대한 부가 이미 축적되어 있고, 샌프란시스코와 실리콘밸리에 위치한 고급 주택들이 중국인들의 손에 넘어가고 있다는 것이 그 증거였는데, 갈 곳 없었던 돈이 비트코인으로 몰리고 있는 것 같다.)
  3. 비트코인의 미래에 베팅하고 있는 큰 투자자들이 생겨났다. 페이스북 초기 임원이었던 Chamath Palihapitiya가 이미 10월 29일 당시 시가로 $5 million (55억원) 어치의 비트코인을 사들였고, 앞으로 수백억원어치를 더 사겠다고 공언을 했다. (당시 개당 200달러이던 시장 가격으로 55억원어치니까, 가격이 6배 상승한 지금 시장 가격으로는 무려 330억원어치이다.)
  4. 비트코인 관련 회사들이 벤처캐피털들의 투자를 받고 있기 시작했다. 그 중 제레미 알레어 Jeremy Allaire 라는 사업가가 만든 Circle(도메인 확보에만도 돈이 상당히 들었을 것 같다)은 ‘비트코인 관련 사업’ 아이디어로 실리콘밸리 투자자들로부터 무려 $9 million(100억원)의 투자를 받았다.
  5. 비트코인 마이닝(아래에 더 자세히 설명)이 어려워졌다. 전에는 비트코인 마이닝을 통해 공짜로 비트코인을 벌던 사람들이 있었으나 이게 어려워지면서 사람들이 비트코인을 사서 모으기 시작했다.
  6. 캐나다, 독일, 네덜란드 등 몇몇 국가들이 비트코인을 인정하고 규제를 완화하기 시작했다. 뱅쿠버에 있는 한 비트코인 환전 ATM기에서는 8일간 10만달러어치의 비트코인이 거래되었다. (더불어, 비트코인으로 물건을 살 수 있는 온라인 쇼핑몰의 수가 크게 늘어났다.)

비트코인이란?

비트코인이란 무엇인가에 대해서는 위키피디아(영어, 한글)에 이미 잘 정리가 되어 있지만, 이해하기가 쉽지 않다. 그동안 읽은 글들을 바탕으로 내가 이해한 바를 정리해 보겠다.

  • 2009년에 ‘사토시 나카모토’라는 가명을 가진 사람이 만들었다. 그런 이름을 가진 팀일 수도 있다. 그 정체에 대해서는 거의 알려진 바가 없지만, 그가 FBI에 의해 폐쇄당한 마약 거래 사이트인 실크로드와 밀접한 관계가 있다는 것을 이스라엘의 수학자들이 밝혀냈다고 해서 크게 회자가 되었다.
  • 오픈소스 소프트웨어로 운영된다. 즉, 비트코인을 운영하는 소스 코드는 GitHub에서 누구나 볼 수 있다. 소스코드 수정 히스토리를 보면 전 세계 프로그래머들이 매일같이 소스 코드를 조금씩 수정하고 있는 것을 볼 수 있다. 소스코드가 공개되어 있다고 해서 누구나 소스코드를 조작해서 비트코인을 가져가거나 비트코인에 영향을 줄 수 있다는 뜻은 아니다. 소스코드는 커뮤니티에 의해 관리되고 있고, 누구나 받아갈 수는 있지만 누구나 업데이트할 수는 없다. 게다가 코드가 워낙 방대하고 복잡해서 전체를 파악하는 것은 쉽지 않다.
  • ‘코인’이라고 부르지만, 손에 쥘 수 있는 물건은 존재하지 않는다. 비트코인은 코드 값으로만 존재한다. 모든 것은 복잡한 RSA 암호화 기술이 적용된 수학이다. 비트코인의 소유자만 개인키(private key)를 가지고 있으며, 이를 통해 비트코인을 다른 사람에게 줄 수 있다. 공개키(public key)와 개인키(private key)를 이용한 암호화 방식은 우리나라의 ‘공인인증서’를 생각하면 이해가 쉽다. 공인인증서의 개인 암호에 해당하는 것이 이 개인키이다.
  • 비트코인을 거래할 때는 한 주소에서 다른 주소로 코인을 보내면 된다. 이 주소는 1MyhygBUrT6aakgRFDs8ECgoJMqVo9u5n2 와 같이 생겼으며, 임의로 생성할 수 있고 소유자에 대한 정보가 포함되어 있지 않다. 즉, ‘익명성’이 보장된다.
  • ‘중앙 은행’과 같은 기관이 없다. 비트코인 거래를 한 군데서 관리하는 것도 아니다. 비트코인 거래가 일어날 때마다 그 내역이 전 세계로 전파되며, 다른 사람들이 유효한 거래라는 것을 증명해준다.
  • 비트코인 소유자에 대한 정보는 없지만, 거래 내역은 ‘블록 체인’이라는 곳에 보관된다. 이 블록 체인을 확인함으로서 비트코인 소유자가 한 곳에만 비트코인을 보냈는지, 악의로 동시에 여러 군데에 비트코인을 보냈는지 알 수 있다.
  • 블록 체인을 확인하는데는 수학적 계산과 고성능의 하드웨어가 필요하며, 확인해준 것에 대한 보상으로 비트코인을 주도록 알고리즘이 설계되어 있다. 이렇게 해서 비트코인을 얻어내는 것을 ‘비트코인 마이닝 (bitcoin mining)’이라고 부른다.
  • 비트코인 마이닝을 위한 하드웨어를 파는 회사들이 있다. 그 중 하나가 ButterflyLabs인데, 성능에 따라 2500달러짜리도 있고 22500달러짜리도 있다.
  • 비트코인 수는 일정하게 증가하고 있지만 점차 그 폭이 줄어들며, 2100만개가 되면 더 이상 증가하지 않는다. 이 제한 때문에 심각한 비트코인 디플레이션이 일어날 것이라고 걱정하기도 하는데, 비트코인 하나가 수백만개로 쪼개어질 수 있으므로 상관 없다. 실제로 비트코인 거래 내역을 보면 0.0531 BTC 이런 식이다.
  • 비트코인 거래에는 수수료가 거의 없다. 특히 국제 송금을 할 때 큰 수수료가 붙게 마련인데, 비트코인은 국가 장벽이 없이 움직일 수 있으므로 (인터넷처럼) 수수료가 따로 없다.
  • 비트코인은 현금과 마찬가지 속성을 띠므로, 잃어버리거나 도둑맞으면 영영히 사라지며, 문제가 발생하더라도 되돌려받을 수가 없다. 이 점은 신용카드에 비해 장점이자 단점이 될 수 있다.
비트코인 마이닝을 해주는 하드웨어. 4,680달러 (출처: http://www.butterflylabs.com/monarch/)
비트코인 마이닝에 쓰이는 하드웨어 (ASIC 보드). 4,680달러 (출처: http://www.butterflylabs.com/monarch/)

비트코인의 원리

비트코인의 수학적 원리는 ‘사토시 나카모토’가 쓴 “비트코인: 개인간 전자 화폐 시스템(Bitcoin: A Peer-to-Peer Electronic Cash System)“이라는 논문에 잘 나와 있다. 여기에서는 비트코인을 아래와 같이 정의한다.

We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership. (우리는 전자 화폐를 디지털 서명의 체인으로 정의합니다. 코인 소유자는 거래 내역에 디지털 서명을 한 후 다음 사람에게 전달하고, 이를 받은 사람은 자신의 공개 키를 코인 맨 뒤에 붙입니다. 돈을 받은 사람은 앞 사람이 유효한 소유자였다는 것을 확인할 수 있습니다.)

아래 도표에 그 과정이 설명되어 있다.

비트코인이 거래되는 원리
비트코인이 거래되는 원리 (출처: http://bitcoin.org/bitcoin.pdf)

복잡해 보이지만, 자세히 보면 원리는 간단하다. ‘화폐’라는 것이 가져야 하는 가장 기본적인 두 가지 속성은 1) 액수가 표시되고 보존되어야 한다는 것, 그리고 2) 위조가 어려워서 주고 받았을 때 사기당하지 않아야 한다는 것인데, 그 두 가지 문제를 푼 것이다. 위 도표를 이해하기 위해서는 먼저 공개키와 개인키를 이용한 비대칭 암호화를 이해해야 하는데, 이에 대해서 자세히 설명하자면 글이 너무 길어질 수 있으니 간략히만 이야기하면(또는 이 문서를 참고), 공개키와 개인키는 세트로 만들어지고, 공개키를 이용해서 암호화한 것은 거기에 해당하는 개인키를 이용해서만 풀 수 있고, 반대로 개인키를 이용해서 암호화한 것은 공개키를 이용해서만 풀 수 있다. 도표 중 가운데 그림을 보자. Owner 1이 Owner 2에게 비트코인을 전달하는 과정이다. Owner 1은, 비트코인 거래 내역과 Owner 2의 공개 키를 가져와서 해싱(hashing)을 한다. 여기서 ‘해싱’은 보안에서 등장하는 용어인데, 텍스트를 짧은 숫자와 문자열로 요약하는 것을 의미한다. 해싱은 비가역적이다. 즉, 문서 A를 해싱해서 문서 B를 만들 수 있지만, 문서 B를 이용해서 문서 A를 복원하는 것은 불가능하다. 어쨌든, Owner 2의 공개키를 가져와서 해싱한 후에 자신의 개인키를 사용해서 서명을 한다. 서명된 결과를 Owner 2에게 보낸다. Owner 2는, 자신의 공개키를 활용해 암호화된 문서가 도착했으므로, 자신의 개인키를 사용해서 암호를 풀 수 있다. 암호가 제대로 풀리면 비트코인의 거래가 완료된다.

비트코인이 가치를 지니는 이유

위 알고리즘은 그렇다 치고, 아무리 생각해도 잘 이해되지 않는 의문이 있을 것이다. 실체도 없는 컴퓨터 코드가 어떻게 해서 사람들이 기꺼이 돈을 주고 사고 싶어하는 ‘가치를 지닌 물건’이 되는가? 온라인 게임 아이템을 생각하면 이해가 쉬울 것 같다. 지난 10월, 리니지에서 ‘진명황의 집행검’이라는 아이템을 인첸트(inchant)하려다 실패해서 리니지를 상대로 아이템 복구 소송을 냈다가 패소한 사례가 있었다. 이 재판의 쟁점이 되었던 ‘진명황의 집행검’은 시가가 무려 3천만원이다. 게임 아이템이 뭐길래 시가 3천만원이 되는가? 그 이유는 ‘희소성’, 그리고 ‘시간과 노력’에 있다. 게임 내에서 이 아이템을 만들기 위해서는 무수히 많은 시간을 써야 하고, 거기에 운도 따라야 한다. 사람의 시간이 들어가서 쓸모 있는 무언가가 만들어지면, 그것이 무엇이든간에 어느 정도의 가치를 지닌다.

리니지에서 가장 희귀한 아이템 중 하나인 '진명황의 집행검'. 호가 2500만원~3000만원이다.
리니지에서 가장 희귀한 아이템 중 하나인 ‘진명황의 집행검’. 호가 2500~3000만원이다.

비트코인도 마찬가지이다. 다만 차이는, 리니지에서는 사람이 노가다를 해서 아이템을 획득해야 하지만, 비트코인은 사람 대신 ‘기계가 노가다를 해서’ 코인을 획득해야 한다는 것이다. 기계는 공짜가 아니다. 몇 천 달러를 주고 사야 하고, 전기도 많이 든다. 이렇게 ‘투자’를 해야만 비트코인을 얻을 수 있기 때문에 그 결과물은 일정 이상의 가치를 지닌다. 그 가치가 10달러가 맞는지 1000달러가 맞는지에 대한 논의는 별개로 하고, 시간이 지날수록 더 비트코인을 얻기 힘들고, 더 고가의 장비가 필요하도록 설계되어 있기 때문에 가치가 상승할 내재적 가능성이 있다. 그 때문에 ‘마이너(miner)’들은 하루라도 빨리 비트코인을 얻으려고 혈안이 되어 있다.

미국 상원 의원 공청회 = 비트코인 파티

한때는 ‘아는 사람만 알던’ 비트코인이 갑자기 미국 전역에서 주목을 받게 된 것은 지난 11월 19일에 있었던 미국 상원 의원 공청회가 열리면서이다. 미국 상원에서 비트코인에 대해 관심을 갖고 한 번 ‘들어보겠다’고 한 소식만으로 비트코인의 가격은 400달러로 솟았으며, 그 공청회를 통해 비트코인의 장단점을 상세히 알게 되자, 다시 한 번 가격이 뛰었고, 오늘날 1,000달러에까지 이르게 된 것이다. 이 때 비트코인 관련 사업을 하던 사람들과 화폐 정책에 관여하는 다양한 사람들이 모여 이야기를 나누었는데, 여기에서 발표된 내용 전문을 읽을 수 있다. 그 중 BitPay의 CEO인 Anthony Gallippi가 발표한 내용이 비트코인의 장단점을 잘 요약하고 있어 트위터에 올렸었는데 142명이 Favorite으로 등록했었다. 그 중 흥미로운 문단 몇 가지를 간략히 번역한다.

Credit cards are “pull” transactions. The shopper provides their account number, and secret credentials that the business can use to pull money from their account. The problem is that the same credentials to pull money one time can be used to pull money many more times – by that same business, or by anyone who has these credentials. This is the fundamental design problem with credit cards, and it is the root cause of the identity theft and fraud that we see today. (신용카드는 ‘당기기’ 방식입니다. 즉, 고객이 신용카드 번호를 제공하면 회사는 그 계좌에서 돈을 빼갑니다. 문제는, 그 신용카드 번호를 가진 누구든 돈을 빼갈 수 있다는 사실입니다. 바로 이 문제 때문에 ‘명의 차용’을 이용한 사기 죄가 생겨납니다.)

Because of this design flaw, security around credit cards is massively expensive. Apple has iTunes, with over 500 million credit card numbers stored on file. The cost and risk of securing this data is enormous. Visa alone spends $200 million a year on fraud prevention. They are throwing big money at the problem and it is not working, because every year fraud remains very high. (신용카드 사기를 방지하기 위해 쓰이는 돈은 엄청납니다. 비자(Visa) 혼자 사기 검출에 쓰는 돈이 무려 2천억원 이상입니다. 어차피 되지도 않는 일에 돈을 낭비하고 있는 셈이지요. 항상 사기율은 매우 높으니까요.)

Bitcoin payments are “push” transactions, which are very different than credit cards. If I want to pay someone, I push them the exact amount I want to give them. The recipient does not get my account number, they do not get my secret credentials, and they do not get any permission to ever pull money from my account. Only I can push out a payment. Bitcoin works similar to email, and text messages. Text messages are a push transaction. You cannot pull an email from me or a text message from me, only I can push the message to you. Bitcoin works the same way, for payments. (반면 비트코인은 ‘밀기’ 방식입니다. 제가 누구에게 돈을 보내고 싶다면, 딱 그만큼의 돈만 보낼 수 있습니다. 받는 사람은 제 정보를 가지고 있지 않고 제 계좌 정보도 모르므로, 저에게서 절대로 돈을 더 빼갈 수 없습니다. 오직 저만 돈을 보낼 수 있습니다. 이메일이나 텍스트 메시지와 비슷하다고 보시면 됩니다.)

단점과 한계

여기까지 보면 장점이 참 많은 것 같지만, 분명한 한계도 많이 있다.

  1. 정부의 통제를 받지 않는다는 것 자체가 한계가 될 수 있다. 지금은 정부가 통화량을 관리하고 돈을 찍어낼 수 있으므로 경기가 과열되거나 침체가 올 때 통제를 할 수가 있지만, 만약 세계 경제가 비트코인으로만 움직인다고 하면 그런 통제가 어려워지므로 경기 파동이 지나치게 커질 수 있다.
  2. 트랜젝션에 시간이 많이 걸린다는 것도 문제다. 비트코인이 A에서 B로 옮겨지는 데에 10~20분이 걸리는데 (아래 그래프), 그 이유는 한 사람이 동시에 두 곳 이상으로 비트코인을 보내는 것을 방지하기 위해 전 세계에서 발생하는 비트코인 트랜젝션을 검사하고, 거래의 유효성을 확인하기까지 시간이 걸리기 때문이다. 10~20분은 국가간 거래에서는 획기적으로 짧은 시간이지만, 스타벅스에서 비트코인으로 커피 한 잔을 사기에는 너무나 긴 시간이다.
  3. 신용카드는 잃어버려도 분실 신고 후 재발급 받으면 그만이지만, 비트코인은 현금과 같아서 잃어버리면 끝이다. 어제 아침에는, 비트코인 7500개가 들어 있는 하드 디스크를 실수로 버린 한 비트코인 마이너의 이야기가 포브스 지에 실렸다. 현재 시장 가치로 80억원~100억원에 이르는 액수다.
  4. 비트코인을 보내고 나면 되돌려받을 길이 없기 때문에, 물건을 사기로 하고 비트코인을 보냈는데 상대방이 물건을 안 보내면 되돌릴 수가 없다.
  5. 당분간은 비트코인의 가치가 주식과 같이 급상승하거나 급락할 가능성이 크다. 비트코인으로 거래를 해 놓고 누군가는 후회할 가능성이 크다는 뜻이다. 앞으로도, 비트코인이 시장에 퍼진 후에, ‘큰 손’이 비트코인을 모두 털고 나가기로 결정하면 비트코인 가격이 폭락할 위험도 있다.
  6. 중국의 규제가 어떻게 나올 지도 위험 요소이다. 중국에서 비트코인을 많이 사서 모으고 있는데, 중국이 비트코인 구매를 막기 시작하면 (그러기는 힘들겠지만), 비트코인 가격이 떨어질 위험이 있다.
비트코인 트랜젝션
비트코인 거래 확인에 걸리는 시간 (출처: blockchain.info)

결론

비트코인의 단점에도 불구하고, 미래를 희망적으로 보고 비트코인을 사서 모으는 사람들이 많이 있다. 그 중 대표적인 사람들은 페이스북 아이디어를 처음 가지고 있었던 것으로 유명한 윙클보스 형제들이다. 비트코인이 15달러대일때부터 사기 시작했다는데, 지난 4월에 비트코인을 10만개 이상 소유하고 있다고 발표했다. 현재 비트코인 가격으로 환산하면 $100 million, 즉 천억 원이 넘는 액수이다.

비트코인으로 결제 가능한 레스토랑과 카페도 늘어나고 있다. 그 중 팔로 알토의 유니버시티 거리에 위치한 쿠파 카페(Coupa Cafe)가 있다. 이 카페는 지난 7월부터 비트코인 결제를 받고 있다. 온라인에서 비트코인으로 물건을 살 수 있는 곳은 이미 많이 있다. 비트코인 위키에 그 리스트가 정리되어 있는데, 이미 비트코인 관련 웹사이트들의 수가 수천에 달해 깜짝 놀랐다.

비트코인 시장 규모가 아무리 커진다 해도, 수백년 이상 쌓아온 현재의 금융 제도를 바꾸기는 힘들 것이다. 그리고 지금 하나에 1천 달러나 하는 비트코인의 가치가 과연 지속될 수 있을 것인가도 의문이다. 하지만, 적어도 비트코인에 결정적 결함이 발견되어 그 체계가 무너지지 않는 한 (그럴 가능성은 거의 없어보인다) 비트코인은 어느 정도의 가치를 지닐 것이고, 더 많은 사람들이 비트코인을 사용하기 시작함에 따라 비트코인 경제 규모는 커질 것으로 보인다.

지메일이 핫메일을 이긴 진짜 이유 (Ajax가 가져온 유저 인터페이스의 혁신)

Gmail의 탄생

2004년 4월 1일, 만우절. 지메일(Gmail)이 세상에 등장했다. 그 전에 대부분의 사람들은 마이크로소프트 아웃룩(Microsoft Outlook)이라는 데스크탑 프로그램을 사용하고 있었다. 데스크탑 프로그램의 가장 큰 단점은 설치를 해야 한다는 것이었다. 사람들은 브라우저에서 바로 이메일을 확인하기를 원했다. 그런 사람들을 위한 웹메일이 탄생했다. 그 중 가장 인기있었던 것은 마이크로소프트가 인수해서 발전시킨 핫메일Hotmail이었다. 그 때 한국에서는 한메일(Hanmail)이 인기였다. 이러한 웹메일이 편리하기는 했지만, 느렸고, 사용하기 불편하다는 것은 여전히 단점이었다. 무엇을 하든지 페이지 전체가 새로 로드되는데, 그 때마다 화면 전체가 껌벅 하는 것이 거북했다. 그리고 아웃룩에서 편리하게 쓸 수 있는 많은 발전된 기능들이 웹메일에서는 지원되지 않았다.

내가 처음 지메일을 쓰기 시작한 것은 2005년 초였다. 같이 일하던 파트너가 미국 샌디에고에 있어서 샌디에고로 출장가서 일하던 때였는데, 내가 대용량 파일을 보내야 하는데 뭐가 좋을까 고민하고 있는 것을 보더니 그가 지메일을 사용해보라고 권했다. 자기한테 초대장이 있으니 보내주겠다는 것이었다. 당시로서는 파격적인, 무려 1기가 바이트나 되는 용량을 무료로 제공한다고 했다. 당시 다른 웹 메일 서비스는 수십 메가 정도밖에 제공하지 않는데 1기가바이트를 준다니 믿기 힘들 정도였다 (지금은 가입하면 10기가바이트를 무료로 제공한다).

지메일을 처음 썼을 때의 느낌은 빠르고 쾌적하다는 것이었다. 핫메일이나 한메일에서와는 달리 지메일에서는 새로운 이메일을 확인하거나 이메일을 발송하고 난 후에 화면 전체가 깜빡하는 일이 없었다. 새로운 이메일을 작성하고, 답장하고, 이전 이메일을 확인하는 모든 것이 아주 빨랐다. 그 비결은 Ajax(Asynchronous JavaScript and XML)라는 기술에 있었다.

Gmail이 탄생한 지 정확히 5년이 되던 2009년 4월 1일, 와이어드(Wired)에 ‘Gmail Hits Webmail G-Spot(지메일이 웹메일의 지스팟을 발견했다)‘라는 재미있는 제목으로 실린 글에 다음과 같은 구절이 있다 (발췌).

It’s difficult to ignore the enormous influence Gmail has had not only on web-based e-mail services, but on rich web applications in general. Several of the concepts introduced by Gmail, which were at the time on the bleeding edge of application design, have since been adopted by the web’s mainstream. (지메일이 웹 기반의 이메일 서비스 뿐 아니라 풍부한 웹 애플리케이션 전체에 미친 영향을 무시할 수 없다. 당시에는 생소했던 지메일에 처음 소개된 많은 기능이 지금은 웹 전체에 적용되어 있다)

The biggest was the use of Ajax, a technique for building web interfaces that gave Gmail that extra snappiness, more closely matching the desktop applications it eventually lured us away from. (그러한 영향 중 가장 큰 것이 Ajax의 사용이다. 이 기술을 사용한 덕분에 Gmail은 쾌적한 느낌을 주었고, 데스트탑 애플리케이션을 더 가깝게 따라할 수 있었다.)

Before Ajax, users would click a link or a button on a webpage, and then they’d have to wait for the entire page to reload in order to see the result. Using Ajax, web programmers could build an application that redrew pieces of the page on the fly without having to reload the whole thing. A user could see new elements appearing and disappearing on the page as they clicked, minus all the waiting. (Ajax 시대 이전에는, 유저가 웹 페이지의 링크나 버튼을 클릭할 때마다 페이지 전체를 다시 불러왔고, 그 때마다 기다려야 했다. Ajax 기술을 이용해서 화면의 일부만 업데이트할 수 있었고, 이제 클릭을 하면 새로운 내용만 화면 위에 나타나거나 사라진다. 기다릴 필요도 없어졌다.)

Ajax란?

Ajax란 Asynchronous JavaScript and XML(비동기식 자바스크립트와 XML)의 약자이다. 여기서 가장 중요한 것은 ‘비동기식‘이라는 단어이다. 사용자가 버튼을 클릭하거나 요청을 해야만 웹 브라우저가 새로운 내용을 가져오는 이전의 방식과는 달리, 화면의 일부분만 업데이트된다. 이 과정을 설명하기 위해, 웹 브라우저에 무언가가 표시되기까지의 과정을 간략히 표현하면 다음과 같다.

웹 브라우저와 웹 서버 사이의 정보 교환
웹 브라우저와 웹 서버 사이의 정보 교환 (출처: tonymarston.net)

즉, 브라우저에서 페이지 요청하고, 서버에서 요청한 페이지를 찾은 후 필요한 작업을 한 후 결과물을 브라우저로 보내준다. 그러면 브라우저에서 이 내용을 표시한다. 그러나 Ajax 방식을 사용할 때는 중간에 한 가지 과정이 더 있다. 브라우저가 서버에 페이지 전체를 요청하는 대신, 필요한 내용만 요청한다. 그 결과가 오면 화면 전체에 뭔가를 그리는 대신 화면 위에 있는 내용을 곧바로 조작한다. 이미지가 새로 나타나게 할 수도 있고, 텍스트가 사라지게 할 수도 있고, 새로운 뭔가를 띄울 수도 있는 등, 무엇이든 조작할 수 있다. 웹페이지는 문서 객체(Document Object)라는 것으로 구성되어 있는데, 이를 이해하는 것이 중요하므로 아래에서 간략히 설명을 해보겠다. 웹페이지는 HTML(Hypertext Markup Language)이라는 언어로 표현되어 있다는 것은 대부분 이미 알고 있을 것이다. 아주 간단한 HTML 코드 하나를 이용해서 예를 들어 보겠다.

<HTML>
<HEAD>
<TITLE>이것은 타이틀입니다</TITLE>
</HEAD>
<BODY>
<P>이것은 하나의 문장입니다</P>
<IMG SRC="elephant.jpg"></IMG>
</BODY>
</HTML>

위 코드를 브라우저에서 로드하면 다음과 같은 결과를 볼 수 있다.

elephant
위에서 예로 든 HTML 코드를 실행한 화면

코드를 가만히 살펴보면 정말로 간단하다. 처음에 <HTML>로 시작하는데, HTML언어로 쓰여져 있다는 것을 알리는 것이다. <TITLE>로 감싸져 있는 것은 말 그대로 타이틀이다. 이 안에 타이틀이 들어가는데, 여기 있는 내용이 브라우저의 타이틀로 사용된다. 그 다음은 <BODY>라고 정의되고, 그 아래에 <P…> 로 시작하는 한 줄이 있다. ‘P’는 ‘Paragraph(문장)’의 약자이며, 그 사이에 문장이 들어간다. 그 다음은 <IMG…>로 시작되는데, IMG는 Image(이미지)의 약자이다. 이미지를 표시하는데, 이미지 파일 이름을 입력하면 위와 같이 코끼리 이미지가 나타난다.

위와 같은 HTML 코드는 실제로 브라우저에서 처리되기 전에 아래와 같이 분해가 된다.

dom
문서 객체 모델(Document Object Model)

이렇게 분해된 모습을 ‘문서 객체 모델(DOM: Document Object Model)’이라고 부른다. 이것이 중요한 이유는, 일단 이렇게 분해되고 나면 조작하기가 쉽기 때문이다. 예를 들어, 이 상태에서 코끼리 그림을 고양이 그림으로 바꾸고 싶다면, 페이지 전체를 다시 구성할 필요 없이 “IMG” 아래 “elemphant.jpg”라는 요소만 “cat.jpg”로 바꾸면 된다. 이런 식으로 하면, 웹 페이지 위에 있는 어떤 것이든 조작할 수 있게 된다. 웹페이지에 새로 보여줘야 하는 내용이 서버에서 와야 할 경우가 있다. 그럴 경우, 서버에 그 내용을 요청해놓고 다른 작업을 한다. 원하는 내용이 도착하면 그 때 업데이트한다.

이해를 돕기 위해 또 다른 예를 들어보겠다. 소포를 주문해놓고 기다리는 경우를 생각해보자. 한 화가가 화실에서 그림을 그리고 있다고 하자. 노란색 물감이 떨어졌다. 전화로 노란색 물감을 추가 주문했다. 이 경우, 화가는 두 가지 선택을 할 수 있다. 하나는 물감이 올 때까지 기다리는 것이다. 이것이 바로 “동기(Synchronous)” 방식이다. 또 한가지는, 노란색 물감이 필요한 일은 그대로 두고 가진 물감으로 그림의 다른 부분을 그리다가, 소포가 도착하면 그 때 노란 물감으로 필요한 작업을 하는 것이다. 이것이 “비동기(Asynchronous)” 방식이다. Ajax에서 A의 약자가 바로 Aynchronous(비동기 방식)를 의미한다.

페이지 전체를 새로 로드하는 것이 첫 번째 방식과 비슷하다. 이 경우, 사용자는 버튼을 눌러 놓고 (즉, 노란색 물감을 주문하고) 페이지 로드가 모두 끝날 때까지 가만히 기다려야 한다. 두 번째 방식의 경우, 사용자는 버튼을 눌러 놓고 다른 일을 할 수 있다. 노란색 물감이 도착하면, 그 때 물감을 필요한 곳에 사용한다.

내가 알는 한, 지메일에 처음으로 Ajax 기술이 전면 적용되었다. 지메일이 세상에 등장하기 전을 회상해보자. 이메일을 모두 작성하고, “보내기”를 누르고 나면 이메일이 전송된 후 새로운 화면이 뜰 때까지 기다려야 했다. 모든 과정이 동기화되어있기 때문에 모든 과정이 순차적으로 일어나는 것이다. 하지만 지메일에서는 “보내기”를 누른 후 기다릴 필요가 전혀 없다. 이메일을 보낸 후 다른 일을 있으면, 아래와 같이 이메일이 성공적으로 전송되었다는 메시지가 페이지의 맨 위에 뜬다. 만약 보내기에 실패하면 이를 알리고 다시 보낼 수 있도록 해준다.

sent
지메일에서, 이메일이 성공적으로 전송되면 화면에 뜨는 메시지

Ajax 기술이 훌륭하게 사용된 또 다른 사례는 주소창이다. 지메일에서는 상대방 주소를 타이핑하기 시작하는 순간 그 단어로 시작되는 주소가 추천된다. 예를 들어서, “al”을 타이핑하면 주소 중에 “al”이 포함된 사람들이 모두 표시된다.

lookup
주소창에 이름을 타이핑하기 시작하면 즉시 그 글자가 포함된 이메일 주소를 추천해준다.

지금은 너무 당연하게 생각되는, 널리 사용되는 기술이지만, 당시에는 데스크탑 애플리케이션에서나 찾아볼 수 있는 매우 혁신적인 기술이었다. 그 전에는 이러한 주소 자동 완성 기능을 사용하고 싶다면 데스크탑 애플리케이션인 마이크로소프트 아웃룩을 이용해야만 했다. 웹 메일에서는 불편하게 써야 한다는 것을 당연하게 여겼다. 하지만, 지메일의 등장으로 웹에서도 마치 아웃룩에서처럼 편리하게 사용할 수 있게 된 것이다.

이러한 기술이 지메일에 처음 등장한 것은 아니지만, 지메일에서 훌륭하게 쓰이는 것을 보고 많은 사람들이 도입해서 사용하기 시작했다. 사실, Ajax라는 용어도 지메일이 성공한 이후에 생긴 것이다.

지메일의 창시자, 폴 부크하이트
지메일의 창시자, 폴 부크하이트

이 기술 뒤에는 구글에서 지메일을 처음 만든 폴 부크하이트(Paul Buchheit)가 있다. 구글의 23번째 직원이었고, 구글의 모토는 “Don’t be evil”이 되어야 한다는 말을 처음 했던 그는, 예전부터 이메일에 관심이 많았다. 하지만 검색 엔진이 전문 분야인 회사에서 인터넷 이메일을 만든다는 것이 쉬운 일을 아니었다. 어쨌든 그는 종류의 이메일을 만들고 싶어했고, 보다 사용하기 편리한 이메일 서비스를 만들고 싶어했다. 책 “Founders At Work“를 보면, 그가 어떤 계기로 지메일을 만들게 되었는지 설명이 되어 있다.

1996년. 핫메일(Hotmail)이 등장하기 전이었지요. 이메일을 확인하려면 꼭 기숙사에 돌아가서 접속해야 했어요. 말이 안된다고 생각했어요. 웹 기반 이메일이 등장해야 한다고 생각했죠. 그래서 제가 하나 만들어봤었어요. 우연히도 그 이름이 Gmail이었죠. 구글에서 만든 Gmail과는 관련이 없었어요. 시간이 지나고, 구글에서 일을 시작한 후에 구글 그룹스 프로젝트를 마친 후였어요. 이메일을 만들어보고 싶어 구글 그룹스에서 썼던 코드를 사용해서 혼자 작업하기 시작했어요. 특히 저에게는 검색 기능이 중요했어요. 당시 하루에 500개나 되는 이메일을 받고 있었거든요. 첫 Gmail은 하루만에 만들었는데, 그걸 동료들에게 보여줬더니 검색 기능이 유용해보인다고 하더군요. 그래서 개선하기 시작했어요.

당시에도 자바스크립트는 다양하게 사용되고 있었지만, 간단한 작업을 하는 정도였지, 이메일같은 복잡한 곳에 쓰이지는 않고 있었다. 자바스크립트를 많이 쓰게 되면 처음 로딩하는 시간이 길어져 적합하지 않다고 생각했기 때문이다. 하지만, 그는 인터넷 속도가 빨라지면서 그 문제는 곧 해결될 것이라고 예상했고, 그의 예상은 적중했다. 사람들은 처음 로딩에 시간이 조금 걸리긴 하지만 일단 로드가 끝나면 너무나 쾌적한 지메일을 좋아했고, 나 역시 그 이후로는 줄곧 지메일만 사용하고 있다.

Ajax 기술을 본격 도입한 이러한 공헌 때문에 사람들은 폴 부크하이트가 Web 2.0 시대를 열었다고 한다. 실제로 많은 웹사이트가 그 이후 달라졌고, Ajax 기술은 구글맵, 구글 캘린더, 구글 리더 등 거의 대부분의 구글 제품에 많이 사용되고 있다.

등장한 지 10년이 되어 가고, 셀 수 없이 많은 웹사이트에 널리 사용되고 있는 기술이지만, 어찌된 이유인지 한국의 웹사이트에서는 거의 적용이 되지 않고 있거나 제한적으로만 적용되고 있는 듯하다. 이유야 여러 가지 있겠지만, 한국에서는 인터넷 속도가 너무 빨라서 매번 페이지 전체를 불러오더라도 느리다는 것을 인식하지 못해서인 것 같기도 하다. 그럼에도 불구하고 불편한 것은 사실이다. 그런 사이트를 방문할 때마다 참 답답하고 귀찮다. 보다 널리 적용되어 쾌적한 경험을 주게 되면 좋겠다.

‘쉽게 설명한’ 구글의 페이지 랭크 알고리즘

네이버 검색엔진의 문제점을 처음 지적한 글을 썼던 2년 전부터 이 블로그에 언젠가 한 번 써보고 싶었던 주제가 하나 있었다. 구글의 PageRank 알고리즘을 설명하는 것이다. 원리는 간단하지만 알고리즘을 설명하려고 하면 말이 길어질 것 같고 쉽게 설명할 수 있을까 싶어 블로그에 쓸까 말까 망설였는데, 그냥 한 번 시작해보려고 한다. “Google”이라는 230조원짜리 회사가 처음 시작된 곳이 바로 이 세르게이 브린과 래리 페이지가 쓴 논문(The Anatomy of a Large-Scale Hypertextual Web Search Engine)이었다는 것을 생각하면 한 번 시간을 들여 배워볼 만한 의미가 있지 않을까? 이 논문은 1998년에 쓰여졌으나, 논문에서 소개된 PageRank 알고리즘은 14년이 지난 지금에도 구글 검색 엔진의 핵심을 이루고 있다.

오늘날의 구글을 만든, 페이지랭크(PageRank) 알고리즘을 소개한 논문에 포함되어 있던 세르게이 브린과 래리 페이지의 사진. 참 앳된 두 대학원생의 모습이다.

논문은 이렇게 시작한다.

Our main goal is to improve the quality of web search engines. In 1994, some people believed that a complete search index would make it possible to find anything easily. (우리의 주요 목표는 검색 엔진의 품질을 향상시키는 것입니다. 1994년 당시, 사람들은 검색 인덱스를 완성하고 나면 무엇이든 쉽게 찾을 수 있을 것이라고 생각했습니다.)

However, the Web of 1997 is quite different. Anyone who has used a search engine recently, can readily testify that the completeness of the index is not the only factor in the quality of search results. “Junk results” often wash out any results that a user is interested in. (하지만, 1997년의 웹은 사뭇 다릅니다. 최근에 검색 엔진을 사용해 본 사람이라면 누구나 인덱스를 완성하는 것만으로는 좋은 품질의 검색 결과를 얻을 수 없다는 것을 압니다. ‘쓰레기 정보’가 종종 사용자들이 진정 관심있어하는 정보를 가려버립니다.)

One of the main causes of this problem is that the number of documents in the indices has been increasing by many orders of magnitude, but the user’s ability to look at documents has not. People are still only willing to look at the first few tens of results. (그러한 이유 중 하나는, 인덱스되는 문서의 숫자는 엄청난 속도로 성장하고 있지만, 사람들이 그 문서들을 볼 수 있는 능력은 같은 속도로 성장하지 않기 때문입니다. 사람들은 여전히 검색 결과중 처음 몇십 개 정도만 살펴볼 뿐입니다.)

Because of this, as the collection size grows, we need tools that have very high precision. Indeed, we want our notion of “relevant” to only include the very best documents since there may be tens of thousands of slightly relevant documents. (그렇기 때문에, 인터넷이 성장할수록, 우리에게 더 정밀한 도구가 필요합니다. 사실, 우리는 ‘관련 있는 페이지’가 수만 개라도, 그 중 최고의 웹 페이지만을 정확하게 찾아주기를 원합니다.)

There is quite a bit of recent optimism that the use of more hypertextual information can help improve search and other applications. In particular, link structure and link text provide a lot of information for making relevance judgments and quality filtering. Google makes use of both link structure and anchor text. (하이퍼텍스트 정보를 이용하면 검색 결과를 많이 향상할 수 있다는 최근의 연구 결과가 있습니다. 특히, 웹 페이지 사이의 연결 관계가 상당히 유용한 정보를 제공해줄 수 있습니다. 구글은 바로 이러한 링크 구조와 링크 달린 텍스트를 이용합니다.)

그리고, 페이지랭크 알고리즘을 다음과 같이 소개한다.

Academic citation literature has been applied to the web, largely by counting citations or backlinks to a given page. This gives some approximation of a page’s importance or quality. PageRank extends this idea by not counting links from all pages equally, and by normalizing by the number of links on a page. (학술지 인용 방식은 그동안 웹에 적용되어 왔습니다. 특히, 특정 페이지를 인용하는 다른 페이지가 얼마나 많이 있느냐를 세는 방식으로요. 이렇게 하면 특정 페이지가 얼마나 중요한 지 알 수 있스니다. PageRank는 이러한 아이디어를 연장하는데, 즉, 다른 페이지에서 오는 링크를 같은 비중으로 세는 대신에, 그 페이지에 걸린 링크 숫자를 ‘정규화(normalize)’하는 방식을 사용합니다.)

말이 좀 어려운데, 아래 수식을 한 번 보자.

PR(A) = (1-d) + d (PR(T1)/C(T1) + … + PR(Tn)/C(Tn))

PR은 PageRank의 줄임말이고, PR(A)는 ‘A’라는 웹페이지의 페이지 랭크를 의미한다. T1, T2, … Tn은 그 페이지를 가리키는 다른 페이지들을 의미한다. 그리고  PR(T1)는 당연히 T1이라는 페이지의 페이지 랭크값이다. d는 ‘Damping Factor’라고 하는데, 설명이 길어질 수 있으니 조금 후 설명하겠다. C(T1)는 T1이라는 페이지가 가지고 있는 링크의 총 갯수를 의미한다.

d에 연연하지 않고(즉 d=1이라고 가정하고) 위 수식을 가만히 보면 사실 매우 간단하다. ‘어떤 페이지 A의 페이지 랭크는 그 페이지를 인용하고 있는 다른 페이지 T1, T2, T3, .. 가 가진 페이지 랭크를 정규화시킨 값의 합‘이다. 다시 말해 페이지 A의 페이지 랭크는 A라는 페이지를 가리키고 있는 다른 페이지의 페이지 랭크값이 높을수록 (즉, 더 중요할수록) 더 높아진다. 여기서 ‘정규화시킨 값의 합‘이라는 말을 굳이 쓴 이유는, 페이지 랭크의 단순 합산이 아니기 때문이다. 예를 들어, T1의 페이지 랭크가 높다고 하더라도, 그 페이지에서 링크를 수천 개 달아놓았다면(즉, C(T1)값이 높다면) 그 페이지가 기여하는 비중은 낮아진다.

이 수식을 그림으로 한 번 표현해보겠다.

PageRank 알고리즘을 그림으로 표현한 것. Dampen Factor가 있기 때문에 이것과 똑같지는 않지만, 간단하게 표현하면 위와 같다.

위 그림에서 웹 페이지 A를 가리키는 페이지는 T1, T2, T3, T4, T5의 다섯 개가 있고, 이들을 정규화해서 합한 값이 0.34이므로, A의 ‘페이지 랭크’는 0.34가 된다. 이 페이지랭크 값은 A가 가리키는 또 다른 페이지의 PageRank를 계산하는 데 쓰일 것이다. 그럼 T1의 페이지 랭크는 어떻게 구했나? 마찬가지로 T1을 가리키는 다른 페이지들의 PageRank값으로부터 구한다. 이렇게 해서 파고 내려가면 무한히 가게 될 것 같은데, ‘제한 조건’을 걸면 언젠가는 계산이 끝이 난다. 이러한 방법으로 계산하는 것을 컴퓨터 과학에서는 ‘recursive(재귀적)‘이라고 한다. 즉, PageRank는 재귀 호출 알고리즘이다.

이제 d, 즉 Damping Factor에 대해 생각해 보자. 위 수식을 다시 한 번 보자.

PR(A) = (1-d) + d (PR(T1)/C(T1) + … + PR(Tn)/C(Tn))

d 값은 0과 1 사이에서 정해지는데, d값이 커져서 1이 되면 앞의 (1-d)는 0이 되고, 뒤 수식의 합이 그대로 A의 PageRank가 된다. 이것이 바로 위 그림에서 가정한 상황이다. 반대로 d값이 작아져서 0이 되면, 뒤 수식의 합은 0이 되고, A의 PageRank는 1이 된다. d가 0이면 모든 페이지의 PageRank는 1이 되므로 아무 의미가 없어진다. 그래서 d는 실험을 통해 0과 1 사이의 어떤 값에서 정해지는데, 논문에서는 보통 0.85로 설정해놓았다고 되어 있다. 논문에 따르면 damping factor란 ‘어떤 마구잡이로 웹서핑을 하는 사람이 그 페이지에 만족을 못하고 다른 페이지로 가는 링크를 클릭할 확률‘이다. 즉, damping factor가 1이면, 무한히 링크를 클릭한다는 뜻이고, 0이면 처음 방문한 페이지에서 무조건 멈추고 더 이상 클릭하지 않는다는 뜻이다. 0.85이면, 85%의 확률로 다른 페이지를 클릭해볼 것이라는 뜻이다. 이 경우 15%의 확률에 걸리는 순간 클릭을 멈추고 그 페이지를 살펴본다.

논문에 따르면, 모든 웹페이지의 페이지랭크 값을 합산한 값은 1이 된다고 한다. 그러나 이 수식을 보면 그렇게 되어 있지 않다. 예를 들어 d가 0이면 PR(A)는 1이 되고, 모든 웹페이지의 PageRank가 1이 되기 때문에 PageRank의 합산은 모든 페이지의 숫자(N)이 된다.

위키피디아에 따르면, 세르게이와 래리가 논문을 쓸 때 실수한 것 같다며, 올바른 수식은 아래와 같다고 한다.

PR(A) = (1-d)/N + d (PR(T1)/C(T1) + … + PR(Tn)/C(Tn))

이렇게 하면 전체 페이지의 PageRank를 합산한 값이 1이 된다.

페이지랭크와 그 관계를 도식화한 그림. A, B, C 등은 페이지를 나타내고, 숫자는 PageRank를 의미한다. C의 경우 B에서 링크를 걸었다는 것만으로도 PageRank값이 높게 책정됨을 볼 수 있다. (출처: Wikipedia)

이게 다이다. 이렇게 해서 온 세상의 모든 페이지를 PageRank 등수에 따라서 미리 정렬을 해 두면, 누군가가 검색어를 입력하는 순간, 그 검색어가 포함된 페이지들을 순위별로 나열하기만 하면 끝이다. 구글의 검색 엔진팀에 있는 지인의 말에 따르면, 지금의 구글 검색 알고리즘은 엄청나게 많은 다른 요소를 고려하고, 튜닝을 했기 때문에 이것보다 훨씬 복잡하다고 한다. 그러나 앞에서 말했듯, ‘영향력 있는 페이지가 인용할수록 페이지랭크가 올라간다‘는 근본적인 알고리즘은 그대로 남아 있다.

구체적 예를 들면 이와 같다. 내 블로그를 인용한 다른 블로그들이 있다. 그 중 아마 가장 사람들에게 신뢰를 얻고 인기 있는 블로그 중 하나가 ‘에스티마의 인터넷 이야기‘일 것이다. 또한 그 블로그를 상당수의 사람들이 인용했을 것이므로 구글 검색 순위가 높을 것이다. 이런 상황이라면, ‘에스티마의 인터넷 이야기’에서 내 블로그로의 링크를 거는 순간 내 블로그의 PageRank는 많이 올라갈 수 있다. 마찬가지 이유로 인기가 있는 다른 웹사이트에서 내 블로그로 링크를 걸면 PageRank가 올라간다. 그러나 만약 그 사이트에서 나 뿐만 아니라 엄청나게 많은 블로그로 링크를 걸고 있다면 (예를 들어, 단순히 수만개의 블로그 주소를 나열한 경우), 그 사이트가 아무리 인기 있다 해도 내 블로그의 검색 순위는 크게 상승되지 않는다.

또 한가지 예로, Stanford.edu와 같은 사이트의 경우 조회수가 엄청나게 높다. 따라서 이 사이트에서 누군가에게 링크를 걸어주면, 구글 검색 순위가 바로 상승할 수 있다. 예전에 Stanford.edu를 관리하는 사람이 돈을 받고 특정 사이트에 링크를 걸어주는 사업을 한 적이 있다고 MBA 수업 시간에 교수님이 이야기한 적이 있다. 물론, 구글이 이를 가만히 놔두지 않았기 때문에 그런 방식은 더 이상 통하지 않는다.

여기에서 덧붙일 말이 있다. 이렇게 훌륭한 알고리즘이지만, 소위 ‘불펌’이 만연하는 곳에서는 이 알고리즘은 바보가 된다는 사실이다. 글을 ‘퍼가기’ 하면서 원문의 링크를 걸지 않는다면, 이 알고리즘에 따르면 아무리 많은 사람들이 퍼가도 웹사이트의 순위는 올라가지 않는다. 한국 인터넷에서는 싸이월드, 또는 그 이전 시절부터 출처 없이 ‘퍼가기’가 참 유행했다. 네이버 블로그가 생기고, 이렇게 글을 퍼가기 해서 많이 쌓아둘수록 블로그 순위가 올라가자 사람들은 더욱 정신없이 ‘퍼가기’를 했다. 그 결과 인터넷은 지저분해지고, ‘내리와 인성의 IT 이야기‘라는 인기 웹툰에서 밝혔듯 원본 문서는 찾기가 힘들어졌다. 이런 상황에서 구글이 한국 시장에 진입했으니, 처음에 구글 검색 결과가 네이버에 비해 훨씬 뒤쳐져 있었던 것은 당연하다. 다행히 요즈음엔 이런식의 ‘펌 문화’가 많이 잦아들었고, 원본의 링크를 다는 ‘건전한 문화’가 많이 정착되면서 원글을 찾기도 쉬워졌고, 구글 검색의 품질도 좋아졌다.

PageRank, 구글이 야후보다 월등히 좋은 검색 결과를 낼 수 있었던 비결이었고, 결국 야후를 꺾고 검색 엔진의 대명사로 등극한 출발점이었다.

코딩의 즐거움

작년 겨울부터 새로운 취미를 시작했다. 작년 겨울 휴가를 근처 스키 리조트인 Lake Tahoe에서 보냈는데, 그 때 내가 킨들에 담아 간 책은 소설 책이 아니라 ‘iOS 프로그래밍:The Big Nerd Ranch Guide‘ 였다. 원래 대학 졸업하고 처음 시작한 일이 게임을 만드는 일이었으니까 코딩은 전에도 많이 했었지만, MBA에 진학한 이후로는 거의 할 일이 없었는데 다시 해보기 시작한 것이다.

전에 페이스북에서 Friend Collage라는 것을 보았다.

페이스북 친구 콜라쥬(Facebook Friends Collage)로 만들 수 있는 그림들

페이스북 친구들의 프로필 사진을 이용해서 자신의 프로필 자신을 모자이크로 재구성하는 것이다. 꼭 친구들의 프로필 사진들만이 아니라 내가 원하는 이미지들을 이용해서 자유자재로 만들어보고 싶어 그런 게 있는지 여기 저기에서 검색해 보았지만, 딱 내가 원하는 것은 없었다.

가만히 생각해 보니 그리 어렵지 않겠다는 생각이 들어 코딩을 시작했다. 내가 생각한 알고리즘은 이런 것이었다.

  1. 그림을 격자로 나눈다.
  2. 각 격자마다 빨간색(R), 초록색(G), 파란색(B)의 평균 값을 구한다. (컴퓨터는 Red, Green, Blue의 세 가지 색을 이용해서 화면에 색을 표현하고 있다)
  3. 타일로 쓰일 그림을 불러온 후, 마찬가지로 각각에 대해 빨간색, 초록색, 파란색의 평균 값을 구한다.
  4. (2)와 (3)의 결과를 비교한다. 즉 값의 차이, 또는 색의 거리를 계산한다.
  5. ‘값 차이’가 가장 적은 이미지를 찾아 이를 배치한다. 같은 그림이 계속 등장하면 재미가 없으니 한 번 쓰인 이미지는 다시 쓰이지 않도록 한다.

이걸 코드로 옮기면 어떻게 될까?

1. 먼저, 그림을 정해진 크기의 격자로 나누어서 저장해둔다.

위 코드에서 ‘bg‘는 배경 그림 이미지를 나타내고, getSubimage 는 그림의 특정 부분을 잘라내는 명령어이다. 즉, bg.getSubimage 라고 하면 ‘bg라는 이미지에서 특정 부분을 잘라내어라’라는 뜻이다. 그 ‘특정 부분’이 괄호 안에서 정의된다. 첫 번째는 가로 좌표, 두 번째는 세로 좌표, 그 다음은 격자 가로 크기, 그 다음은 격자 세로 크기이다. TILE_WIDTH와 TILE_HEIGHT 미리 정의되어 있다. 그림으로 나타내면 다음과 같다. 가운데 있는 등호는 ‘오른쪽 연산의 결과를 왼쪽에 저장하라’는 뜻이다. 예를 들어, A = 3 * 5 는, 3과 5를 곱한 결과, 즉 15를 A에 저장하라는 뜻이다. 위의 예에서는 잘라낸 그림을 tileToAnalyze라는 곳에 저장해두라는 뜻이다. 이렇게 일단 저장해 두면 저장된 그림을 가지고 뭐든 할 수 있게 된다. 이 경우에는, 그 그림마다 R, G, B값을 얻어내어 평균 값을 구할 것이다. 그림으로 표현하면 아래와 같다.

이미지를 작은 사각형으로 잘라낸다

2. 잘라진 그림의 평균 R, G, B 값을 구한다.

잘라진 각 그림의 평균 R, G, B 값을 계산하는 코드

복잡해 보이는데, 설명을 해보겠다. image.getRGB(k, l)은, k와 l에 해당하는 지점에서 있는 점의 R, G, B 값을 구하는 명령어이다. 그 결과 R, G, B값이 pixel이라는 숫자에 저장된다. 그런데 pixel에는 이 세 개의 값이 합쳐서 들어가 있으므로 R, G, B값을 따로 찾아내려면 분리를 해야 한다. 그래서 ((pixel >> 16) & 0xff)과 같은 코드가 필요하다 (이 코드는 설명이 길어지므로 생략한다.). 분리된 R, G, B 값은 각각 rgb[0], rgb[1], rgb[2]에 들어가는데, 그냥 들어가는 게 아니라 누적 합산해서 들어간다 (rgb[0] = rgb[0] + xxx). 값의 평균을 구하려면 값을 다 더한 상태에서 픽셀의 갯수로 나누면 된다. 픽셀의 총 수는 (이미지 가로 크기 X 이미지 세로 크기) 이므로 (width*height)라고 표현된다. rgb[0] = rgb[0] / (width*height)는, rgb[0]에 들어가 있는 값(각 픽셀마다의 R 값을 모두 누적 합산한 결과)을 픽셀의 총 수로 나눈 다음에 다시 rgb[0]에 저장하라는 뜻이다.  k와 l값은 좌표를 나타내는데, for 명령문이 있기 때문에 (0, 0), (1, 0), (2, 0), …, (0, 1), (1, 1), (2, 1), …, (k, l), …, (이미지 가로 크기, 이미지 세로 크기) 까지 값이 변한다. for (int k=0; k<width; k++) 는 ‘k 값이 0부터 시작해서 width 값보다 작은 동안 k값을 1씩 증가시키면서 아래에 있는 명령을 반복 실행하라’는 뜻이다. 아래 그림을 보자.

왼쪽 이미지에서 잘라 낸 각각의 타일에 대해 모든 픽셀을 훑으면서 R, G, B의 평균 값을 계산하는 과정

3. 타일로 쓰일 그림에 대해 마찬가지로 R, G, B 평균 값을 구한다.

이는 바로 위와 완전히 동일한 과정을 통해 계산할 수 있다.

4. 배경 이미지를 자른 타일의 R, G, B 값과 타일로 쓰일 이미지의 R, G, B 값을 서로 비교한다.

R, G, B 값을 서로 비교해서 값의 차이를 저장해 둠

Math.abs(a, b)는 a와 b의 absolute(절대적) 차이를 계산하는 명령어이다. 즉 Math.abs(5 – 3)의 결과는 2이고, 마찬가지로 Math.abs(3 – 5)의 결과도 2이다. 위 코드의 결과로 R, G, B 값의 차이는 deltaSum이라는 공간에 저장된다.

5. 그 값의 차이가 최소인 타일(즉, 배경 이미지를 자른 타일과 가장 R, G, B값이 유사한 타일)을 찾아내어 타일을 배치한다.

6. 이 작업을 모든 타일에 대해 반복한다. 아래는 그 결과이다.

페이스북 친구들의 프로필 사진 700여개를 이용해서 만든 제레미 린 콜라쥬
원본 이미지

전체 코드는 여기에서 설명한 것보다 더 길지만, 앞에서 설명한 것이 가장 핵심적인 알고리즘이다. 결국 ‘코드’이란 머리속으로 생각한 논리를 영어 단어와 기호로 변환하여 표현한 것에 불과하다. 그런 면에서는 외국어를 배우는 것과 비슷하다고 볼 수도 있다. 특수한 사람들만 배울 수 있거나 이해할 수 있는 것이 결코 아니다. 누구나 ‘논리’를 생각해낼 수 있고, 그 논리를 코드로 그대로 옮기면 프로그램이 된다.

마이클 블룸버그 뉴욕 시장은, 올해 초에 트위터를 통해 새 해 결심이 코딩을 배우는 것이라며 코드 아카데미에 등록했다고 했다. 인기 아이폰 앱을 만든 회사, 인스타그램(Instagram) 창업자의 여자 친구는 발렌타인 데이를 맞아 Lovestagram이라는 앱을 만들어서 남자친구를 깜짝 놀라게 해주었다고 한다(결국 나중엔 남자친구의 도움을 받았지만). 인터뷰에서, 그녀는 “누구도 코딩하는 것을 두려워할 필요가 없다.”라고 이야기했다. 2012년, 코딩을 한 번 배워보면 어떨까?

마이클 블룸버그 뉴욕 시장의 새 해 결심 트윗: "나의 2012년 새 해 결심은 코드아카데미에서 코딩을 배우는 것입니다. 같이 합시다." (출처: Mashable.com)

API란?

아는 사람들로부터 “API란 무엇인가?“라는 질문을 참 자주 받았다. API는 Application Programming Interface(애플리케이션 프로그래밍 인터페이스)의 약자이다. 쉽게 설명하기 위해 자동차의 예를 들어 보겠다.

자동차는, 운전하는 사람 입장에서는 참 간단하게 보인다. 액셀러레이터를 밟으면 나가고, 브레이크를 밟으면 선다. 핸들을 돌리면 방향이 바뀐다. 기어를 사용해서 변속을 할 수 있다. 사실, 내부에서 일어나는 일은 훨씬 복잡하다. 휘발유가 공급되고, 공기와 섞이고, 이를 연료로 엔진 속에서 연소가 일어나고, 그 결과 엔진이 돌아간다. 브레이크를 밟으면 바퀴에 달린 브레이크 패드에 압력이 가해진다. 하지만 운전하는 사람은 내부에서 일어나는 일은 알 필요가 없다. 여기서 ‘액셀러레이터, 브레이크, 핸들, 기어’에 해당하는 것이 “자동차의 API”이다. 코드로 예를 들면 아래와 같다.

  • putOnAccelerator (int pushLevel): 엑셀러레이터를 발로 밟는 정도(pushLevel)를 보내면, 그만큼 차가 추진력을 받을 것이다.
  • putOnBreak (int pushLevel): 브레이크를 밟는 정도(pushLevel)를 보내면, 그만큼 차의 속력이 감소할 것이다.
  • rotateSteeringWheel (float angle): 핸들의 회전 각(angle)을 보내면 차가 그만큼 왼쪽이나 오른쪽으로 돈다.
  • changeGear (int newGear): 새로운 기어 값(newGear)을 보내면 그에 따라 차가 변속한다.
  • getCurrentSpeed(): 현재 차의 속도를 알려준다.
'자동차의 API'에 해당하는 핸들, 액셀, 브레이크, 기어

다시 말해, ‘자동차의 API’란 사용자가 차를 움직이게 하기 위해서, 또는 차의 상태를 알아내기 위해서는 어떻게 해야 하는지를 일정한 규칙으로 정해둔 것이다. 사용자는 차의 내부 원리에 대해 모두 알 필요 없이 자동차의 API만 익히면 차를 운전할 수 있다. 더 나아가, 원하면 이러한 API들을 이용해서 원격으로 차를 움직이게 하는 프로그램을 만들 수가 있다. 어떤 사용자는 더 이보다 더 많이 차의 세부적인 내용을 조정하고 싶을 수가 있다. 예를 들어 차에 따라서는 ‘스포츠’ 옵션이 있어서, 이걸 켜면 기어 변속이 지연되고, 차가 전반적으로 힘이 세졌다는 느낌을 받는다. 자동차 회사에서 이러한 API를 더 많이 공개할수록 사용자의 자유도는 올라간다.

페이스북 API, 트위터 API도 비슷한 개념이다. 페이스북 API를 익히면 페이스북에서 정보를 얻어오고, 친구들의 사진을 다운로드하고, 페이스북에 업데이트하는 프로그램을 만들 수 있다. 예를 들어 페이스북의 그래프 API 중에 이런 것이 있다.

https://graph.facebook.com/sungmoon.cho

‘sungmoon.cho’라는 페이스북 유저의 가장 기본적인 정보를 요청하는 API이다. 아래와 같은 결과를 얻는다 (브라우저에 이 주소를 직접 복사해서 붙여넣기하면 테스트할 수 있다).

{
   "id": "524334413",
   "name": "Sungmoon Cho",
   "first_name": "Sungmoon",
   "last_name": "Cho",
   "link": "https://www.facebook.com/sungmoon.cho",
   "username": "sungmoon.cho",
   "gender": "male",
   "locale": "en_US"
}

즉, sungmoon.cho라는 아이디를 가진 유저는 페이스북 번호가 524334413이고, 이름은 Sungmoon, 성은 Cho이며, 남자이고, 설정 언어는 영어(en_US)이다. 주소에서 ‘sungmoon.cho’를 다른 아이디로 바꿔 보면 다른 결과를 얻는다. (이와 같이, 페이스북에서는 아이디만 알면 별도의 보안 절차 없이 성별은 무조건 알아낼 수 있도록 되어 있다.)

비슷하게, https://graph.facebook.com/me/friends 는 ‘내 친구들의 리스트’를 알아오는 API이다. 아래와 같이 친구 리스트를 얻는다 (물론, 다른 사람의 친구 리스트를 얻어오기 위해서는 그 사람의 사전 허락이 있어야만 하고, API 사용자는 허락 받았음을 증명할 수 있어야 한다. 이 때 사용되는 프로토콜이 OAuth이다.’).

{
   "data": [
      {
         "name": "Andrew Danger Chung",
         "id": "2493"
      },
      {
         "name": "Johanna Javadizadeh",
         "id": "6110"
      },
      {
         "name": "John Luna",
         "id": "7592"
      },
      {
         "name": "John Lai",
         "id": "20158"
      },

또한, https://graph.facebook.com/sungmoon.cho/picture 는 sungmoon.cho라는 유저의 프로필 사진을 얻어오는 API이다. https://graph.facebook.com/arjun/feed 라는 API를 이용하면 ‘arjun’이라는 사용자의 벽(wall)에 메시지를 남길 수 있다. 페이스북에 정의된 이러한 API는 무궁무진하고, 개발자들은 API를 이용하면 수많은 재미있는 응용 프로그램들을 만들어낼 수 있다. 이런 응용프로그램이 많아질수록 페이스북의 가치는 올라간다. 그래서 많은 회사들이 API를 정의하고, 잘 정리해서 사용법과 함께 이를 공개하는 것이다. 공개하는 API가 많아질수록 개발자들에게는 더 유용하지만, 프라이버시 침해 및 보안의 위험 또한 증가하기 때문에 무조건 많은 것을 공개하는 것이 정답은 아니다.

HTML5가 바꿔가는 애플리케이션 세상

이전 블로그에서 네이티브 앱(Native App)과 웹 애플리케이션(Web Application)을 비교하며 그 차이와 한계에 대해 설명했다. 여기서는 HTML5의 등장으로 어떻게 데스크탑/모바일 웹 애플리케이션들이 한계를 극복하고 있고, 실제로 애플리케이션에 어떤 차이를 가져오는지에 대해 두 가지 내용을 기준으로 – 구글 I/O 컨퍼런스, NextStop.com – 이야기해보고자 한다.

HTML5에서 제공하는 새로운 기능에 대해서는 여러 곳에서 더 자세한 정보를 찾을 수 있기 때문에 (Mickey Kim(@mickeyk)님의 블로그 중 “HTML 5란 무엇이며 왜 중요한지에 대한 이야기” 참고), 여기에서 간략히만 설명하면, Google과 Apple이 리드하며 개발하고 있는 HTML의 새로운 규약이고, 기존에 웹이 가지는 한계(비디오 재생을 위한 표준화된 방법이 없음, 디바이스에 액세스할 수 없음, 멀티태스킹 못함,…)를 극복하고자 하는 다양한 기술 (Canvas, Device Access, Worker, Push, Video tag…)등이 포함되어 있다.

구글 개발자 컨퍼런스 Google I/O 2010

지지난주 (5월 19일) 샌프란시스코에서 열렸던 구글 개발자 컨퍼런스 Google I/O에서의 최대 화두는 HTML5였다. (여기서 잠깐 다른 얘기. Google IO 키노트 연설을 한 Vic Gundotra(VP of Engineering)는 I/O가 Input과 Output을 의미하기도 하지만, 다른 한편으로는 Innovation과 Openness의 약자이기도 하다고 이야기했다. 왜 컨퍼런스 이름을 I/O라고 지었는지 궁금했었는데, 구글의 정신을 표현한 멋진 네이밍이다.)

첫째날 키노트 연설에서는 웹 기술의 발전에 대한 설명과 함께 HTML5의 새로운 기술들을 사용하고 있는 다양한 회사들이 나와 HTML5를 어떻게 적용하고 있는지, 그래서 어떤 일들을 하고 있는지에 대해 설명했다. 정말 재미있는 예들이 많았다. 여기서 중요 장면을 몇 가지 소개해 보겠다.

Forrester Research의 조사 결과에 의하면 사람들이 점점 웹에서 더 많은 시간을 보내고 있다고 한다. 아는 이야기도 나의 생활 패턴도 그렇게 변했지만, 이렇게 그래프로 보니 놀라게 된다.
2004년부터 우리가 많이 쓰는 애플리케이션들이 웹으로 옮겨가고 있다.
이와 함께 HTML5가 발전해내가고 있는데, 실제로 많은 브라우저들이 이를 이미 지원하고 있고, 올해 말에는 IE를 제외한 모든 브라우저가 HTML5의 주요 기능을 제공하게 될 것이라고 예측하고 있다.

데스크탑에서는 이렇게 많은 브라우저에서 지원이 되는데, 모바일 브라우저에서의 상황은 어떨까? 물론 단말기 대수로 생각하면 HTML5를 지원하는 폰의 비율이 높지 않을 것이다. 그러나 구글이 수집한 아래 자료에 의하면 HTML5를 지원하는 모바일 브라우저에서 사람들이 훨씬 더 많은 검색을 하고 있다. 즉, 갯수는 작지면 사용량이 월등히 높은 것이다. 이는 최근 급속도로 성장한 스마트폰 사업과 결코 무관하지 않다.

HTML5가 지원되는 모바일 브라우저에서 훨씬 더 많은 검색이 일어나고 있다.

그리고 나서 HTML5를 활용하고 있는 많은 회사들이 등장해 어떤 새로운 기능들을 써서 브라우저용 애플리케이션을 만들었는지 설명하였다. 첫 번째 등장한 회사는 DarkRoom, Sketchpad라는 웹 애플리케이션을 만든 MugTug이다. 아래는 실행 화면이다.

웹에서 즐기는 그림판, Sketchpad
웹 기반의 사진 편집 애플리케이션, Darkroom

웹사이트를 직접 방문해서 한 번씩 해보시길 (Internet Explorer에서는 지원이 안될 수도 있습니다.) 권한다. 두 가지 사실에 놀라게 된다. 첫째는 웹에서 이런 것도 가능하다는 것이고, 둘째는 그 성능이다. 네이티브 애플리케이션만큼 빠를 수는 없겠지만, 크게 불편을 느끼지 않을 만큼 성능이 좋다.

아래 유투브 동영상의 12:18부터 감상하면 더 많은 예를 볼 수 있다.

모바일에서의 HTML5

이제 모바일 이야기로 넘어가보자. Google I/O의 둘째날 키노트 연설에서는 HTML5가 모바일에서는 어떻게 적용되고 있는지에 대해서 설명하고 실제 그 기능을 안드로이드 디바이스에서 시연하였다. 아래, 네 가지 데모이다.

1. Geolocation (위치 정보)

이전 블로그에서도 소개했지만, GPS 등을 이용해서 위치 정보를 알아내는 기능은 이미 브라우저에 구현되어 있다.

2. Accelerometer (엑셀러로미터)

모바일 브라우저에서, 단말기에 내장된 액셀러로미터 정보를 가져오는 것을 시연하는 모습이다.

3. 카메라

브라우저에서 카메라를 구동시킬 수 있고, 카메라로 찍은 사진은 웹 서버에 보내져 브라우저에서 곧 볼 수 있다.

4. 마이크

브라우저에서 마이크를 통해 들어오는 정보를 받을 수 있고, 이를 서버에 보낼 수 있다.

케이스 스터디: NextStop의 웹 애플리케이션

NextStop의 웹 애플리케이션

이번에는 NextStop.com이라는 회사의 창업자들과의 인터뷰를 통해, 그들이 실제로 아이폰 전용 앱 대신 HTML5를 사용한 웹 애플리케이션을 채택하게 된 배경, 그리고 HTML의 한계를 구체적으로 어떻게 극복하고 있는지에 대해 설명해보고자 한다.

NextStop의 두 창업자는, 아이폰 네이티브 앱 대신 웹 애플리케이션을 선택한 이유를 다음과 같은 네 가지로 설명하고 있다.

1. 웹이 훨씬 개발하기 쉽고 반복해서 수정하기 쉽다. 하루에 네 번씩 업데이트를 하고 있는데, 네이티브 앱으로 한다면 업데이트에 훨씬 시간이 오래 걸린 것이다.

2. 많은 앱의 경우 굳이 네이티브 앱으로 만들 필요가 없다. 하드코어 프로세싱 파워가 필요한 게임을 만드는 것도 아닌데 말이다. 빠르고 반응성 좋은 웹 애플리케이션을 HTML5를 사용하면 만들 수 있다.

3. 다른 웹 페이지랑 연결하기가 쉽다. 예를 들어, 마음에 드는 레스토랑을 발견했는데 그 웹사이트를 방문하고 싶다면, 굳이 브라우저를 떠나거나 애플리케이션을 떠나지 않고 아주 자연스럽게 그 페이지로 갈 수 있고, 갔다가 다시 돌아오기도 쉽다.

4.”바탕화면에서 추가하기” 기능을 이용하면 바로 가기 버튼을 홈에 넣을 수 있어서 유저 입장에서는 네이티브 애플리케이션처럼 접근할 수 있다.

브라우저 기반의 애플리케이션에서 내가 가장 크게 느꼈던 불편은 페이지 전환에 시간이 많이 걸린다는 것이었는데, HTML5를 써서 그 문제를 얼마나 개선했는지 궁금해서 iPod Touch를 이용해서 아이폰/안드로이드 전용 웹사이트에 접속해 보았다.

상당히 놀랐다. 오른쪽, 왼쪽 버튼을 눌러 다음 사진 보기 기능이 있는데, 누르면 거의 곧바로 반응한다. 대부분 다른 웹사이트에서 문제가 되는 긴 로딩 시간이 없었다. 인터뷰를 보니 캐싱을 사용해서 그렇게 구현했다고 한다. 즉, 이전 페이지와 다음 페이지를 미리 로드해 와서 저장해두기 때문에 매번 이미지를 불러오느라 시간을 쓰지 않는다. 게다가 보았던 페이지로 되돌아갔을 때도, 그 페이지가 이미 저장이 되어 있기 때문에 시간이 걸리지 않는다.

멀티터치를 이용해서 브라우저 위에 떠 있는 지도를 확대하고 축소할 수도 있다.

심지어, 카메라로 사진을 찍어 올리는 기능이라든지, 폰에 저장된 사진 라이브러리에서 사진을 웹페이지에 업로드하는 기능도 있다. 다만, HTML에서 아직은 이를 지원하지고 않고 있어서 이를 이용하기 위해서는 별도의 아이폰 앱을 다운로드해서 설치해두어야한다고 한다. 아래는 브라우저에서 카메라를 구동하고, 사진을 찍은 후 다시 브라우저에서 확인하는 장면이다.

HTML5, 아직은 더 갈 길이 있지만, 지금의 발전 속도라면 네이티브 앱과 웹 애플리케이션의 차이는 점차 줄어들 것이 분명하고, 더 많은 애플리케이션이 HTML과 JavaScript를 이용하여 개발될 것은 자명하다. 그렇다면 모든 네이티브 앱(native app)이 웹으로 옮겨가게 될까? 그렇지는 않다. 컴퓨터에서 많은 앱이 브라우저로 옮겨져서 우리의 삶이 이미 브라우저 위에서 이루어지고 있지만 여전히 데스크탑 애플리케이션을 써야 훨씬 편한 몇몇 케이스가 있듯, 모바일에서도 마찬가지로 많은 기능이 웹으로 옮겨지겠지만 여전히 네이티브 앱을 쓸 수밖에 없거나, 그게 더 사용하기 편해서 사람들이 네이티브 앱을 선호하는 케이스는 여전히 존재할 것이고, 그런 것들은 여전히 네이티브 앱으로 남을 것이다.