트위터가 어떻게 개발되었을 까? 아래는 타임지에 실린 트위터의 기사이다. 타임지에서 트위터가 우리의 삶을 어떻게 바꾸어 놓을 것인가 에 대한 기사를 실었다. 이처럼 현재 트위터같은 실시간 웹은 온-오프라인을 넘나들면서 새로운 문화를 만들어 가고 있다.

개인적으로도 맥장비에는 Twitterrific 을 설치하고 윈도우의 FireFoX에는 Twitter Extension을 설치하여 사용하고 있다. 분명한 것은 트위터가 폭발적으로 성장하고 있고 앞으로도 성장할 것이라는 것이다. 개인적으로는 무선 환경 특히 , SMS 서비스로 길들여진 실시간 정보 교환 문화가 140개의 문자로 소통하는 트위터를 성장시킨 밑거름이 아닐까 싶다. 지금도 인터넷에서는 트위터로 , 현실에서는 핸드폰 문자와 포스트잇으로 의사를 교환하곤 한다. 

사회.문화적 관점을 떠나 개발자 입장에서 트위터가 어떻게 개발이 되었을까 고민을 하며 그 기술을 추적을 해보았다. 특히, 트워터는 실시간에 대용량 데이타에 대한 Push 서비스를 제공해야 하기 때문에 서비스의 구조와 운영 기술은 아주 중요하다. 

먼저 트위터의 아키텍쳐에 대한 전반적인 소개 자료를 보면 트워터는 아래와 같은 기술을 사용하여 개발되었다.

-개발 언어 : Ruby on Rails , 자바 , Scala
-시스템 관리 : Puppet , 오픈소스 서버 관리 툴
-Cache : Memcache , 오픈소스 분산 객체 캐쉬 시스템(트워터의 성능을 위해 중요한 역할을 한다.)
-H/W : X86 기반 리눅스
-DBMS : MySQL
-Web Server : Apache
-서비스 특징 :  일반 웹 서비스처럼 웹 페이지를 중심으로 서비스를 제공하는 것이 아니라 트워터 서버에서 API를 제공하고 이를 통해 웹과 디바이스등 다양한 생태계를 구성하고 있다.

트위터의 경우 웹 프론트는 성능의 이유때문에 Ruby on Rails를 사용하고 백엔드는 자바를 사용한다. 특히, 자바를 사용할 때 Scala 를 함께 사용한다.  Scala는 자바 등의 언어와 함께 사용하여 보다 코드는 간결하게 만들어주는 개발 언어이다. 간략히 테스트 코드는 보면 스칼라 코드에서 직접 자바 라이브러리를 호출하여 사용할 수 있다. 이렇게 자바와  Scala , Memcache 를 사용하여 초기 서버를 구축하여 2008년까지 사용하였다.

이렇게 개발된 시스템의 현재 상황은 다음과 같다.

- 초당 600개의  Request를 처리함
- 초당 평균 200-300 커넥션( 초당 800 커넥션 까지 확장 가능함 )
- MtSQL 은 초당 2,400 Request를 처리함
- 웹 서버는 Mongrel 이고 180개의 레일스 인스턴스를 운용
- 8 코어 하드웨어 박스에 1 MySQL 서버와 1 슬래이브 구성( 슬래이브는 통계 및 레포팅용으로 데이타 마트 구성 )
- 예외 상황에 대비하여 30개 이상의 추가 프로세스를 운영중
- Sun X4100 모델, 8대
- 평균 DB에서 처리 시간 : 50-100 밀리초
- 16GB Memcached

트위트 사이트보다 트위트의 API가 10배 이상 호출이 많다고 한다. 이러한 상황에서 최대한의 성능을 내기 위해 당연히 DB를  denormalization하여 테이블간의 죠인을 줄이고 , 메모리 캐쉬에 모든 데이타를 올려놓아서 성능을 보장한다.

과거 DBMS 수업시간에 DBMS Normalization을 배우고 오라클에 종속적인 지식을 갖고 있는 DA(Data Architecture)가 테이블과  SQL을 설계하고 곳에서는 상상할 수 없는 일이다. 왜 Normalization을 안하냐고 당장 공격이 들어올니까.. 그게 그 분들의 밥줄이기도 하지만... 얼추 계산해 보니 하드웨어와 기타 라이센스 해서 2억 정도면 서비스를  구축하지 않을까 싶다. 나머지 상용제품은 눈을 씼고 찾아볼 수 없다... 쩝.. 외국 회사의 장비와 소프트웨어를 구매해야 데 많은 비용을 써야 하는 입장에서는 가슴이 아프다..

스마트폰을 통한 모바일 환경이 일상화 되면서 웹 클라우드와 모바일 디바이스간의 동기화는 아주 중요한 기본 서비스로 자리잡고 있습니다. 가령, RIM의 블랙베리는 Push Mail을 앞세워 비지니스 맨들의 문화를 바꾸면서 이 분야의 강자로 자리잡았습니다. 이러한 Push Mail의 구현 방법중 하나가 바로 씽크 기술을 이용하는 것 입니다. 간략히 모바일 클라우드와 동기화 서비스의 현황에 대해 정리해 봅니다. ( 참고로 아래 그림들은 테크런치에 올라온 싱크 솔루션에 대한 비교 자료에서 발췌한 것 입니다. 해당 자료는 실제 오픈소스  씽크 솔루션과 플랫폼 제공업체인 Funambol에서 작성한 자료입니다. )


1. 동기화 대상

아래 그림은 모바일 클라우드와 모바일 디바이스간의 동기화 대상을 정리한 것 입니다. 전체적으로는 사진과 주소록, 전자우편,소셜 네트웍,일정 데이타가 현재 주요한 동기화 대상임을 알 수 있습니다. Apple MobileMe와 Funambol, MS Myphone,Nokia OVI,Plam Synergy 에서 이들 데이타를 동기화해주고 있습니다. 아마 다른 서비스들도 조만간 이들 데이타의 동기화를 모두 제공할 것입니다.
 

개인적으로는 앞선 데이타 타입들 외에 사용자 정의 데이타(User defined data type)에 대한 동기화의 지원 여부가 중요한 경쟁요소가 될 것이로 보입니다. 현재 모바일 플랫폼의 개발 환경이 개방화되면서 개발자들이 자발적으로 많은 어플리케이션을 개발하고 있습니다. 또한 핸드폰 뿐만 아니라 디자탈 액자, TV 등 다양한 디바이스간 동기화가 필요하기 때문에 보다 어플리케이션에서 사용자가 정의한 데이타에 대한 동기화 지원이 아주 중요해 질 것으로 보입니다.

사용자 정의 데이타외에 또 하나 중요한 동기화 대상은 외부 서비스 데이타(External service data type)에 대한 동기화입니다. 다음은 현재 각 동기화 서비스서 지원하는 외부 쇼셜 서비스의 대상이다. 현재 플리커와 페이스북에 대한 동기화를 주로 지원하고 있습니다. 그러나 현재 이들 서비스외에 Twitter나 Friendfeed같은 실시간 마이크로블러깅 등 모바일 분야의 Killer Application 들에 대한 지원이 주요한 경쟁력으로 부각되고 있습니다.


2. 비용

대부분의 서비스가 무상으로 제공되고 있음을 알 수 있습니다.  아마 기본 서비스는 무상으로 제공되겠지만 백업이나 기타 다른 디바이스로의 Restore 등 기타 부가 기능을 제공한 프리미엄 버전이 동시에 제공될 것입니다.


3. 동기화 방법

단순히 모바이 디바이스상의 데이타를 웹상의 모바일 클라우드로 백업을 하는 개념의 동기화하면 그 구현은 단순할 것입니다. 그러나 양방향으로 실시간에 이들 데이타를 동기화하기 위해서는 많은 고민이 필요합니다. 특히, 모바일 디바이스는 장비 특징상 대기 시간이 길수록 밧데리가 빨리 소모하며, 고정 IP가 아니라 수시로 IP가 변경되는  특징들 때문에 보다 스마트한 구조를 필요로 합니다. 일반적으로는 기존의 SyncML을 사용하거나 블렉베리 처럼 자체 개발한 표준 방법을 사용하여 개발합니다.


- 자체 개발한 미들웨어와 프로토콜 사용
현재  Push Mail을 가장 먼저 서비스한 RIM의 블랙베리는 기존의 메일 서버와 블랙베리 디바이스 간에 자체 개발한 미들웨어와 프로토콜을 사용하여 기존 메일 서버를 모니터링한 후 새로운 메일을 가져와서 블랙베리 디바이스에 Push를 합니다. 이 때 사용하는 프로토콜은 자체 개발한 것 입니다.  
 
- 기존 표준 방법의 확장 모델
기존의 대표적인 디바이스상의 동기화 방법은 SyncML을 이용하는 것입니다. 따라서 많은 동기화 서비스들은 HTTP(S) 프로토콜과 SyncML에 기반하여 개발합니다. 메일의 경우에는 IMAP IDLE(RFC2177) 커멘트를 사용하여 동기화를 하기도 합니다. IMAP IDLE 커멘트는 디바이스가 메일을 받을 수 있는 상태라는 것을 알려주는 커맨트입니다.

아래 그림은 MS에서 구현한 Direct Push 란 Push mail 모델입니다. Exchange server 2007에 구현되어 있는 이 방법은 Device가 Long-standing https로 동기화를 요청하면 이에 따라 사용자의 메일 박스의 상태를 점검하여 새로운 메일을 Device에 HTTP 프로토콜을 통해 SyncML로 Push를 해 줍니다.


모바일 디바이스를 이용하다 보면 간혹 디바이스를 잃어버리거나 다른 디바이스로 변경을 할 경우가 종종 발생합니다. 이 때, 가장 필요했으면 하는 기능이 바로 기존의 정보를 백업하거나 해당 정보를 다른 디바이스로 쉽게 옮기는 것입니다. 이처럼 모바일 환경이 일반화되면서 모바일 디바이스와 웹 클라우즈, 모바일 디바이스간 동기화는 아주 중요한 기본 서비스로 자리 잡을 것 입니다. 또한 외부 쇼셜 서비스를 비롯하여 새롭게 개발되는 모바일 웹 어플리케이션에서 동기화 기능은 필수적인 기능이 될 것 입니다. 

세상의 모든 것들의 웹으로의 연결이 가속화되고 있다. 특히, 손안의 인터넷이라 말할 수 있는 스마트폰이 확산되면서 웹은 생활의 일부가 되어 가고 있다. 디지탈 카메라나 스마트폰으로 찍은 사진과 동영상이 실시간에 플리커와 유튜브같은 웹에 업로드되고 , 페이스북이나 트위터에 남긴 글들을 스마트폰을 통해 실시간으로 모니터링을 하고 답변을 달기도 한다. 쇼핑을 할 때는 가격 비교 사이트에서 조회를 하고 다시 가격 비교 사이트에 낚이는 것을 방지하기 위해 내 쇼셜 네트웍에 있는 친구들에게 자문을 구하고 쇼핑을 한다. 이 모든 것이 현재의 모습이다. 과거에 비해 다른 것은 점점 더 웹이 실시간화 되고 있다는 것이다.


실시간 방송
직접 야구장에 가서 경기를 관람하는 게 가장 좋치만 그렇치 못할 경우에는 포탈에서 제공하는 실시간 방송을 보곤한다. 특히, 포탈의 실시간 방송이 재미난 것은 사용자들이 실시간에 올리는 댓글이다. 물론, 때론 눈살을 찌푸리게 하는 경우도 있지만 사용자의 반응을 실시간에 보는 것 만으로도 무척 즐겁다. 간혹 실시간 캠을 통해  독도나 한강변을 보기도 한다.



실시간 정보 - 교통,주식,등등
포탈에서 제공하는 실시간 정보도 유용하다-교통,주식 정보 등등. 아쉬운 점은 실시간으로 변경되는 해당 정보를 일일이 포탈에 방문해야 확인할 수 있다는 점이다. 실시간 웹으로 발전하기 위해서는 해당 정보를 전달받을 수 있도록 RSS,Atom같은 피드를 제공하면 보다 유용할 것이다.




실시간 검색
구글의 검색은 방대한 양의 HTML 데이타를 크롤러가 수집하고 이를 색인한 후 검색한다. 크롤러가 수집하는 HTML은 실제 죽어있는 데이타이다. 보다 생생하고 살아있는 정보는 없을까? 일반적으로 쇼셜 서비스로 알려져 있는 트위터(Twitter)의 서치는 검색양에 있어 구글보다는 못하지만 실시간으로 살아있는 정보를 조회할 수 있다. "Samsung Electronics"란 단어로 만들어지는 실시간 정보를 트워터는 제공해 준다. 구글의 죽어있는 문서간의 연결되는 URL을 기반으로 한 페이지 랭킹 알고리즘과 실시간 사람들의 관심사를 랭킹으로 한 알고리즘은 많은 차이가 있을 것 같다. 나는 문서 검색을 할 때는 구글을 이용하지만 사람들의 관심사와 지식에 기반한 정보를 원할 때는 트위터 서치를 이용한다.



실시간 매쉬업
페이스북, 마이스페이스,구글 독스,구글 리더,트위터,플리커,피카사,유튜브,.. 현재 사용하고 있는 사이트만 나열해 보아도 10가지는 넘는 것 같다. 이 들 사이트에 실시간에 업로드되는 나와 관련된 정보는 얼마나 많을까? 이들 정보를 조회하는 것도 무척 큰 일이다. 이러한 다양한 서비스들의 실시간 정보들을 한 곳에서 실시간에 조회하고 관리하는 서비스를 이용하면 손쉽게 해결할 수 있다. friendfeed를 이런 용도로 사용한다. friendfeed를 이용하여 내가 가입되어 있는 많은 쇼셜 서비스와 정보를 실시간에 확인하고 업로드할 수 있다.



아주 다양한 분야에서 웹이 실시간화되는 것을 볼 수 있었다. 이렇게 웹이 실시간화 되면서 사회,문화적으로도 많은 영향을 줄 것이다. 보다 스마트해진 디바이스들을 통해 텍스트와 이미지, 동영상 등이 업로드될 것이며 이를 항상 휴대하는 스마트폰을 통해 실시간에 조회하고 참여하여 정보를 생산하게 될 것이다.  모바일 디바이스가 실시간 웹을 항상 사용자에게 전달하는 매개체가 되면서 기존의 통신 수단이라는 개념에서 탈피하여 사용자를 실시간 웹을 연결해주고 궁극적으로는 하나의 노드가 되도록 해준다. 사용자는 실시간 정보를 생산해 내는 생산자이자 이 정보를 이용하여 다양한 활동을 수행하는 소비자가 될 것이다. 과거부터 현재까지 우리는 SMS 단문 서비스를 실시간처럼 사용해 오고 있다. 어떤 경우에는 SMS가 실시간 서비스인 것 같다. 아니 우리는 SMS를 실시간 서비스인 채팅처럼 사용하고 있다. 마찬가지로 우리는 웹을 실시간으로 이용하게 될 것이다. 실시간화된 웹이 바로 차세대 웹의 모습중 하나가 아닌가 싶다.