IT/Mobile Platforms | Posted by 철규님(최규철) 2011.04.08 00:34

Android Architecture Overview


Android Architecture Overview
Written by GyuCheol Choi on April 08, 2011



플랫폼? OS? 프레임워크?

안드로이드에 대한 설명에 앞서서, 필요한 몇 가지 용어를 정의하고 시작하려고 한다. 크게 중요하게 느껴지지 않을지도 모르는 용어 정의이지만 다른 개발자, 특히 외국 개발자와의 명확한 의사 소통을 위해서는 용어의 정확한 뜻, 정확한 사용법 등을 아는 것이 많은 도움이 된다(고 필자는 생각한다).

스마트폰이 보급되에 스마트폰용 어플리케이션 작성에 대한 관심이 어느 때보다 높아지고 있는 최근, 개발을 시작하려고할 때에 가장 먼저 듣게 되는 용어를 뽑으라면 '운영체제(OS)', '프레임워크', '플랫폼' 등일 것이다. 이 용어들에 대해 간단하게 알아보자.


운영체제(operating system)

운영체제는 CPU, 메모리, I/O 장치, 저장장치 등의 하드웨어 자원을 직접 관리할 뿐만아니라, 응용 프로그램이 이들 하드웨어 자원을 손쉽게 사용할 수 있도록하는 추상화 계층을 제공하는 시스템 소프트웨어를 말한다. 또한 응용 프로그램이 하드웨어의 CPU에서 직접 수행될 수 있도록하는 역할도 한다. 멀티태스킹을 지원하는 운영체제의 경우에는 동시에 실행되고 있는 여러 개의 응용 프로그램에 대한 자원 관리나 스케줄링 등의 기능도 지원한다.

대표적인 PC 운영체제로는 Microsoft Windows, Linux, Max OSX 등이 있다.


프레임워크(framework)

프레임워크는 정확한 의미를 가장 알기 힘든 용어 중의 하나라고 생각된다. 응용 프로그램 개발 과정을 살펴보면 각종 응용 프로그램에서 유사한 형태의 기능을 사용하는 경우가 많은데, 이 경우 개발자의 부담을 덜어주기 위해 프레임워크에서는 해당 기능에 필요한 API들을 묶어서 제공한다. 일반적으로는 이러한 API 집합 들을 프레임워크라고 본다. 물론 정확한 의미를 따지면 단순히 API 뿐만 아니라 코딩 패턴 등을 포함하기도 한다.

개발자의 입장에서는 라이브러리와 유사하다고 느낄 수도 있지만, 프레임워크는 그 프레임워크를 사용하는 응용 어플리케이션의 틀과 구조를 결정하며, 라이브러리와는 반대로 개발자의 코드를 직접 제어할수 도 있다.


플랫폼(platform)

위키백과(http://ko.wikipedia.org)의 내용을 요약하면 플랫폼은 '응용 프로그램의 동작을 가능하게 하는 하드웨어 아키텍처와 소프트웨어 프레임워크'를 말한다. 구체적으로 플랫폼은 '하드웨어 아키텍처, 운영체제, 프로그래밍 언어, 런타임 라이브러리, GUI' 등을 포함한다. 즉, 안드로이드 플랫폼이라고 한다고 해서 구글에서 배포하는 '안드로이드'만을 의미하는 것이 아니라, 그 안드로이드가 동작하기 위해 필요한 하드웨어 아키텍처부터 안드로이드 응용 프로그래밍 작성을 위한 개발 환경, 안드로이드가 사용자에게 보여지는 GUI까지 모두 포함한다.

예를 들어 설명을 하면, PC 플랫폼은 Intel 또는 AMD CPU를 기반으로 하는 하드웨어 아키텍처에 윈도우나 리눅스가 운영체제 및 GUI 지원을 위해 올라가고, 윈도우 및 리눅스용 응용 프로그램 개발/실행을 위한 라이브러리나 개발 툴 등을 포함한 것이라 할 수 있다.

대표적인 휴대용 기기 플랫폼은 iOS, 안드로이드, 바다 등을 들 수 있는데, 대부분 ARM CPU를 기반으로 하는 아키텍처를 채용하고, 각각의 OS 및 SDK 등을 제공한다.


명확하게 정리되지는 않지만, 위의 내용을 토대로 운영체제, 프레임워크, 플랫폼에 대해서 정리를 해보면, 플랫폼이 운영체제와 프레임워크를 포함한다는 것을 알 수있다. '안드로이드 플랫폼'을 예로 들면, 이 '플랫폼'은 ARM CPU를 기반으로 한 하드웨어 아키텍처 위에 리눅스를 '운영체제'로 탑재하고, 응용프로그램 작성 및 실행을 위한 어플리케이션 '프레임워크'들 을 포함하고 있다.

각각의 구성 요소에 대해서는 아래에서 자세히 설명하려고 한다.





안드로이드 플랫폼 아키텍처(Android Platform Architecture)

안드로이드 플랫폼 아키텍처에 대해서는 구글 안드로이드 개발팀의 Mike Cleron이 설명한 동영상 강의가 있다. 아래 링크에서 직접 볼 수 있으며, 아래 글의 내용도 이 동영상 강의 중의 일부를 정리한 것이다.

[동영상 바로가기] Androidology - Part 1 of 3 - Architecture Overview


System architecture

전체적인 구조를 먼저 살펴보기 위해 다음 그림을 보자.


안드로이드 플랫폼은 운영체제로 Linux Kernel을 사용하고 있으며, 이 위에 Library, Android Runtime, Application Framework, Application 등을 포함하고 있다.



Linux Kernel


안드로이드 플랫폼은 Linux 2.6 커널을 기반으로 하고 있으며, 이 리눅스를 HAL(Hardware Abstraction Layer)로 사용하고 있다. 안드로이드 플랫폼에서 리눅스를 채택한 이유는 이미 각종 드라이버에 대한 지원이 충분하고, 메모리 관리, 프로세스 관리, 보안 모델, 네트워킹 등 많은 운영체제 기본 요소들이 이미 구현되어 있고 또한 충분한 시간 동안 검증을 받았기 때문이다.



Libraries

안드로이드 플랫폼에 포함된 라이브러리들은 모두 C나 C++로 작성되었다. Mike는 이 부분이 안드로이드 플랫폼의 강력함의 원천이라고 설명한다.


Surface manager: 실행되는 여러 어플리케이션이 화면에 어떻게 나타나는지를 관리한다.
OpenGL/ES, SGL: 안드로이드 플랫폼 그래픽 라이브러리의 핵심. OpenGL/ES는 3D 그래픽을 지원하며, 장치에 따라 H/W 가속 기능 또한 지원한다. SGL은 대부분의 어플리케이션이 사용하는 2D 그래픽을 위한 것이다. 안드로이드 플랫폼의 그래픽 라이브러리 특징 중 흥미로운 점은 한 어플리케이션에서 3D 그래픽과 2D 그래픽을 혼합해서 사용할 수 있다는 점이다.
Media Framework: Media Framework는 OHA(Open Handset Alliance)의 회원인 PacketVideo에서 지원되는 라이브러리로, 미디어 지원을 위한 각종 코덱을 포함하고 있다.
FreeType: Font를 그려주기 위한 라이브러리
SQLite: Data 저장
WebKit: 구글 브라우저의 코어로 사용되고 있는 오픈 소스 브라우저 엔진으로 모바일 장치의 작은 화면에서도 잘 동작하도록 수정되어 있다.



Android Runtime


Dalvik Virtual Machine: .Class, .Jar 파일을 변환(converting)해서 얻어지는 바이트코드(bytecodes)인 .dex 파일을 실행한다. .dex 파일은 저성능 프로세서(small processor)에서도 잘 동작하도록 효율적인 메모리 사용, 프로세스간 데이터 공유를 위한 자료구조 등을 지원한다. 이러한 효율성 덕분에 Dalvik Virtual Machine은 동시에 여러개의 인스턴스를 실행해서 어플리케이션을 실행할 수 있다.
Core library: Java 언어로 쓰여진 부분으로, Container, Utility, I/O 등 필수적인 기능을 제공한다.



Application Framework

Core library와 마찬가지로 Java 언어로 쓰여진 부분으로, 실제로 대부분의 어플리케이션이 사용하는 툴킷이다.


Activity manager: 어플리케이션의 Life Cycle을 관리하고, common backstack을 포함하고 있어서 다른 프로세스에서 실행 중인 어플리케이션들간의 원활한 이동(navigation)을 지원한다.
Package manager: 장치에 어떤 어플리케이션들이 설치되어 있는지, 각각의 어플리케이션이 어떤 기능을 수행하는지를 관리한다.
Windows manager: 화면에 보이는 Window를 관리하는 부분으로 Library 부분의 Surface manager에 대한 Java 추상화 모듈이라고 볼 수 있다.
Telephony manager: 전화 기능 지원을 위한 API들을 포함하고 있다.
Content provider: 안드로이드 플랫폼의 특이 사항 중 하나로, 어플리케이션간의 data 공유를 가능하게 해주는 역할을 한다. 폰의 전화번호부(contacts) 어플리케이션이 Content manager를 사용하고 있어서, 전화번호나 이름 등의 데이터를 필요로하는 어플리케이션에서는 이를 이용해서 데이터를 가져다 쓸 수 있다.
Resource manager: 지역화된 문자열, 비트맵/벡터 이미지, 레이아웃 정의 파일 등 어플리케이션에서 코드 이외의 부분을 관리한다.
View system: 버튼, 리스트 등과 같은 UI 구성 요소를 제공하며, 이벤트 dispatching, 레이아웃, 드로잉 등을 관리한다.
Location manager: GPS 등을 이용한 위치 기반 서비스에 필요한 기능을 제공한다.
Notification manager: 상단의 Notification bar를 사용할 수 있게 해준다.
XMPP service: XML을 기반으로 한 메세지 기반 미들웨어를 위한 오픈 표준 통신 프로토콜인 XMPP(eXtensible Message and Presence Protocol)을 제공한다.



Applications


전화걸기, 전화번호부 등 기본 어플리케이션 및 사용자 설치 어플리케이션이 위치하는 부분으로, 모든 어플리케이션은 바로 아래의 Application framework에서 제공하는 기능을 이용하여 만들어진다.




한두페이지의 글로 하나의 플랫폼에 대한 이해를 한다는 것은 불가능한 일이지만, 간략하게 안드로이드 플랫폼의 기본 구조에 대해서 정리해 보았다. 일반적인 사용자 어플리케이션을 작성하는 개발자라면 특별히 몰라도 되지만, 아는 만큼 더 나은 어플리케이션을 작성할 수 있지 않을까 생각한다.


댓글을 달아 주세요

  1.  댓글주소  수정/삭제  댓글쓰기 소혼 2011.04.20 09:09 신고

    추가로 WebOS가 뭔지 정리 부탁해도 되까? ㅋㅋ

IT/Web Dev | Posted by 철규님(최규철) 2011.03.29 02:48

[번역] The Node Ahead: JavaScript leaps from browser into future

※ 잘못 번역된 내용이 “당연히” 있을 테니 원문을 꼭 참고해서 읽으세요.
번역 오류나 개선, 오타에 대한 피드백은 언제나 환영하고 감사드립니다. ^^

The Node Ahead: JavaScript leaps from browser into future
Node가 간다: 자바스크립트, 브라우저를 넘어 미래로
Google V8 엔진, 서버 세계의 도플갱어로 급부상

Written by Cade Metz on March 1, 2011
Translated by GyuCheol Choi on March 22, 2011
원문 보기



Voxer는 현대판 워키토키 iPhone 앱으로, 이 프로그램을 사용하면 당신이 원하는 만큼 실컷 인터넷을 통해 이야기를 하고, 동시에 듣고, 반대편에 아무도 없으면 음성 메세지를 남기고, 동시에 여러명과 채팅을 나누고, 텍스트와 음성을 전환할 수도 있다. 이것은 극도로 실시간적인 인터넷 앱이고, 이것이 바로 이 프로그램이 세상 대부분의 사람이 들어보지 못한 개발 플랫폼으로 만들어진 이유다.

Matt Ranney의 팀은 원래 Voxer를 군용 쌍방향 VoIP 라디오로 착안하고, 좋은 구식의 C++로 코드를 작성하기 시작했다. "중요한 상활에 사용될, 고성능 군용 어플리케이션이다."라고 그는 말했다. 그런데 C++은 당장 그 프로젝트에 쓰기에는 너무 복잡하고 엄격했다. 그래서 Google, Yahoo!, NASA 등의 서비스를 훌륭하고 운영하고 있는 고수준 언어 파이썬으로 옮겨간다. 그러나 파이썬은 저지연 VoIP 앱에는 너무 느려서, 다시 Node로 변경했다.

Node는 개발자들이 Node.js를 부르는 말로, 동적인 넷 어플리케이션 작성에 특화된 2년 밖에 되지 않은 개발 플랫폼이다. "js"는 JavaScript를 의미한다. Node는 Google Chrome 브라우저의 심장인 오픈소스 자바스크립트 엔진, V8을 기반으로 그 위에 만들어졌다. 그러나 Node는 브라우저 기술은 아니다. Node는 V8을 클라이언트에서 서버로 옮겨놓음으로서, 개발자들이 자바스크립트 프론트 엔드를 개발하는 것과 매우 유사한 방식으로 어플리케이션의 백 엔드를 개발할 수 있게 해줬다.

하지만 이것은 Node를 추천하는 이유의 절반에 불과하다. Node는 쓰레드나 데이터가 아닌, 다른 프로그램으로부터의 메세지나 사용자로부터의 입력이 중심이 되어 만들어진 "event-driven" 시스템의 최고의 예제이다. 즉, Node는 다음으로 넘어가기 위해서 어떤 것이 발생하기를 기다리지 않는다. 예를들어 데이터베이스에 자료를 요청하면, 데이터베이스로부터 응답이 오기전에 다음 태스크를 호출할 수 있다. 기존의 멀티쓰레드 시스템이 CPU 작업량이 매우 많았다면, event-driven 시스템은 많은 I/O 작업량을 포함한 네트워크 어플리케이션에 어울린다고 할 수 있다.

사용자가 네트워크 상으로 연결하면, 다음에 무슨 상황이 일어나든 Node의 "event loop"는 대규모의 메모리를 미리 할당하지 않는다. -커넥션을 구분하기 위한, 말하자면 플레이스 홀더 같은-작은 크기의 메모리만을 할당하고 필요에 따라 추가 메모리를 확보한다.

Mat Ranney는 이러한 구성이 제법 많은 수의 연결을 필요로하는 Voxer와 같은 앱에는 이상적이라는 것을 알게되었다. "사용자가 어떤 것의 실시간 스트림 업데이트를 할 수 있는 무엇인가를 만들려고 한다면, 서버로 몇 개의 연결을 유지하고 있어야 한다. PHP 아키텍처에서는 그건 매우 비용이 비싼 방법이다. 하지만 Node는 거의 공짜이다. 아주 오랫동안 연결을 유지하고 있을 수 있고, 연결마다 증가하는 비용도 매우 저렴하다."라고 Voxer의 CTO인 Ranny가 말했다.

"Noe는 두 가지의 세상에서 모두 최고이다. 우리는 이벤트 프로그래밍 등에 특히 적합한 자바스크립트를 사용하고, 또한 성능도 놓치지 않았다."

Voxer를 처음 만들었을때, Ranney는 단일 서버에 얼마나 많은 연결을 오픈할 수 있는지 테스트를 실시했었다. "어느 정도에서 다운되는지 보기 위해서 가능한 많은 연결을 오픈하기로 마음 먹었었다." Ranney가 말했다. "Node를 쓰면, 거의 모두를 오픈할 수 있다. 내 테스트 머신에 IP 주소를 더 얻어오지 않고서는 더 이상 연결을 오픈할 수 없었다. Node는 그렇게 작은 메모리를 사용한다. 놀라운 일이었다. 난 포트 번호가 부족했다."



모든 것이 새로움(The New Everything)

실리콘 밸리의 일부에서는, Node가 새로운 PHP, 새로운 Ruby on Rails 또는 새로운 Black으로 알려져있다. Node를 써본 사람들에 따르자면, 그것은 거대한 차세대의 그 무엇인가다. 발간을 앞둔 O'Reilly의 책, "Up and Running with Node.js"의 저자이자 Node를 최초로 사용한 클라우드 컴퓨팅 팀 Joyent의 최고 전도사인 Tom Hughes-Croucher는 "잠시동안은 Node를 새로운 Rails로 불렀었다. 하지만 GitHub에 레일즈보다 더 많은 뷰를 유도하는 것을 깨닫고는, 새로운 PHP라고 부른다."라고 말했다.

Ruby on Rails는 인기있는 오픈 소스 저장소인 GitHub에 사용된 첫 주요 프로젝트였다. 아직은 Rails가 Node보다 -대략 7,000 대 5,000 정도로 - 더 많은 "follower"를 가지고 있지만, Node는 정말 더 많은 뷰를 모으고 있다. 그리고 Rails가 약 7년 동안의 좋은 개발 시간을 거친 성숙한 언어인반면에, Node는 2009년에 데뷔했을 뿐이다. 우리는 아직 1.0 버전의 릴리즈에도 미치지 못하고 있고, 지난달 막 0.4 버전이 릴리즈 되었다.

Joyent는 Node 오픈 소스 프로젝트에 스폰서로 참여하고 있을 뿐만 아니라, 플랫폼의 호스팅 버전, 개발자들의 빌드를 도와주는 온라은 서비스, 브라우저 상의 실행 프로그램을 제공하고 있다. no.de라고 알려진 서비스는 아직 베타 버전에 있기는 하지만 몇몇 알만한 곳에서 흥미를 불러일으켰다. 구글 앱 엔지니어인 Ikai Lan은 2월 중순 "오~예!, Joynet node.js 호스팅에 초대받았어!"라고 트위터에 글을 올렸다.

지난 여름 첫번째 Node 해커톤(해킹+마라톤, 역자주)인 Node Knockout을 주최한 Gerad Suyderhoud에게는 Node 플랫폼은 웹 개발의 지속적이고 급속한 진화의 차세대 주요 단계였다. 그는 "처음에는 아마존을 작성하는데 쓴 C가 있었고, 그 뒤는 Perl이었는데, Craigslist가 Perl로 작성되었다. 그러곤 PHP와 Facebook이 생겨났고, 또 Rails와 Twitter가 나타났다. 이 모든 것들을 보면, 많은 양의 고난이도 문제를 해결하면 새로운 문제가 나타나는 식이었다. Nobe는 실시간성과 관련해서 발생한 다음 번의 어려운 문제들을 풀고 있다."

웹 사이트의 와이어프레임(구조)를 보여주는 웹 어플리케이션은 Mockingbird나 학교 성적부 서비스인 LearnBoost 및 Voxer와 같은 몇몇 어플리케이션이 Node에 의해서 운영되고 있지만, 아직 Facebook같은 큰 사이트를 지원할 수 있는 정도는 아니다. 하지만 다른 사람과 마찬가지로 Suyderhoud는 그렇게 될 것이라고 확신한다. 지난 8월 Joyent's의 사무실에서 열린 Node Knockout 대회는 500명의 개발자가 참여했으며, 이 대회를 통해 Scarabble의 대규모 멀티사용자 버전인 Word2라는 상용 어플리케이션이 탄생하였다.

하지만 Nodes가 단순히 웹 사이트나 어플리케이션을 만드는 도구인 것만은 아니다. Node는 차세대 어플리케이션이나 웹사이트를 가능하게 하기 위해 고안된 백앤드 서비스와 같은 클라우드 서비스를 가능하게 하는 도구이기도 하다. Joyent는 Node를 즉시 조절이 용이한 프로세스 능력과 저장 공간에 대한 실시간 접근성을 제공하는 Amazon EC2 유사 인프라스트럭쳐 클라우드 서비스를 보강하는데 이용하기도 한다. Rackspace가 최근 구매한 클라우드 관리 스타트업인 Cloudkick은 Node 상위에 일련의 서버-관리 툴을 만들어준다. 또한 현재 VMWare가 보유하고 있는 클라우드-메세징 장비인 Rabbit Technologies는 Node에 기반한 RabbitMQ 오픈 소스 메세징 플랫폼의 확장형인 rabbit.js를 제공한다.

프리렌서 개발자로서 Node를 개발하고 지금은 Joyent에서 일하고 있는 Ryan Dahl은 "클라우드 관리 요소들 덕분에 우리는 어디서든 이 모든 에이전트들을 사용할 수 있으며, 이들은 많은 양의 데이터를 처리할 필요는 없다. 이러한 작은 것들을 작성하는 것이 [이벤트-기반] 영역에서는 매우 그럴싸한 결과를 낳는다. 여러개의 쓰레드를 관리할 필요없이, 메세지를 받고 메세지를 보내기만 하면 된다."라고 말한다.

동시에 Node는 서버측에서 클라이언트측으로 다시 이동하고 있다. HP는 Palm WebOS 휴대폰과, 곧 나올 터치패드 태블릿에서 디바이스 자체적으로 백그라운드 서비스를 운영하는 것에 Node를 사용하고 있다. 이것은 이 플랫폼이 얼마나 효율적인가를 나타내는 또 하나의 표시에 지나지 않는다. Dahl는 "스케일을 실제로 줄일 수 있다는 것을 알게 될 것이다. 몇 기가의 메모리를 할당할 필요도 없다. 아주 빠른 시동 시간을 가지고 있으며, 메모리 사용량도 적다... 임베디드 장치에서 실행되기에는 충분히 작은 것이다."라고 말한다.



구식 비블락형 버리기(Chip off the old non-block)

Ryan Dahl은 원래 빠른 웹 서버, 최신 웹 어플리케이션에 적합한 웹서버를 위해 Node를 개발했다. 과거 수학을 전공한 그는 프리랜서 프로그래머로 직업을 바꾸고, "비블락형 IO"라고 부르는 흥미로운 이벤트-기반 시스템을 개발했다. 또한 그는 Ebb로 알려진 이벤트-기반 Ruby 웹서버도 만들었다. 하지만 Ruby로는 그가 원하는 성능의 해법을 찾을 수 없었다.

서버는 이벤트-기반이었지만, 시스템이 전통적인 멀티스레드나 "블락형" 시스템과 상호작용을 해야했기 때문에 성능은 최소화될 수 밖에 없었다. Dahl은 다음과 같이 말했다. "[Ebb]를 빠르게 만드는 작업에서 실패를 했었다. 하지만 모두 비블락형 I/O로 한다면 아주 좋은 성능을 얻을 수 있다는 점을 알아냈다. 실제 문제는 이것이 양자택일성의 일이라는 점이었다. 모두 비블락형으로 할 수도 있고, 모두 블락형으로하고 쓰레드를 사용할 수도 있다. 비블락형 I/O를 사용하려고 하면 비블락형 인터페이스가 없는 다른 시스템과의 상호작용을 해야되는 점때문에 매우 어려웠다."

결국 그는 완전히 새로운 플랫폼을 만들기 시작했고, 그 플랫폼은 어플리케이션을 작성하는 방법을 재정의했다. 그는 처음에 C 라이브러리로 시작했다. 하지만 C가 예전만큼 인기있는 것이 아니라는 것을 깨닫고, Lua를 이용했다. 하지만 그것도 문제가 있기는 마찬가지였다. Lua는 모든 종류의 "블락형" 라이브러리 있어서 모두 매우 무겁게 동작했다.

"블럭형쪽으로는 이미 Lua 방식이 있었다. 내가 정말 찾았던 것은 깨끗한 슬레이트 같은 것이었다. 새로운 플랫폼을 만들려고 할때, 아마 모든 방법을 다 해볼 것이다. 어떻든 Lua는 블록형 라이브러리가 이미 많이 있어서 전혀 흥미롭지 않았다."라고 Dahl은 말했다.

프로젝트가 시작된지 6개월이 지나서야, JavaScript에 대한 깨달음을 얻을 수 있었다. 그때 Wikipedia에서 100개의 흥미로운 JavaScript 서버측 프로젝트를 공개했는데, 그 중에 아무것도 인기를 얻지 못했다. 어떻게 서버를 열고,소켓을 생성하고, 사용자와 연결하고, DNS 주소를 해독하고, 사용자와 통신하고, 파일을 열고 같은 것에 대한 선행적인 것들이 전혀 없었다. Dahl는 "그것과 관련해서는 제반 분위기가 전혀 형성되지 않았었다. 그것이 어떻게 보여져야 하는지에 대한 생각도 없었다. 그래서 단지 비블럭형으로 정의하고 사람들에게 전달하면, 사람들은 '아, 알겠어'라고 말할 뿐이었다."

JavaScript는 여전히 엄청난 수의 클라이언트측 개발자들에게 친숙하 존재다. 전혀 새로운 언어가 아닌 것이다. "클라이언트 작업을 할 때의 사고 방식을 서버 작업을 위해서 전환할 필요는 없다."라고 Voxer의 CTO인 Ranney는 말한다. 그리고 Dahl과 Ranney 모두 현존하는 클라이언트측 개발 언어들은 이벤트-기반 프로그래밍에도 적합하다는 점을 강조한다. JavaScript는 이벤트 기반 시스템에서의 사용할 콜백으로 꽤 사용하기 쉬운 편인 closures를 포함한 높은 수준의 추상화를 제공한다.

"[Node]는 [클라이언트측 JavaScript 어플리케이션을 작성하는] 개발자들에게는 매우 친숙한 것이어야 한다. 클라이언트측 개발자가 웹 사이트의 버튼 콜백을 만드는 것과 같은 방법으로 - '여기에 버튼을 두고, 이것을 클릭하면, 이 함수를 부르고' - Node 프로그래머는 서버를 셋업한다. 버튼을 클릭하는 누군가 대신에, 서버에 연결하는 누군가가 되는 것이다. '서버에 연결을 하면, 이 함수를 실행해라.'

이벤트 기반 시스템은 결코 새로운 아이디어가 아니다. 비슷한 플랫폼이 이미 Ruby와 Python에서 -각각 EventMachine과 Twisted로- 사용 가능했다. 단지 JavaScript에서 선택을 함에 있어서 Dahl은 그 아이디어를 새로움의 극치로 만들었다. 이 모든 것들을 기반으로 거대 브라우저 제조사들은 JavaScript를 최대한 빠르게 하기 위한 끝없는 군비 경쟁을 벌이고 있다. - 그 중 Google이 가장 앞서있다. "Node를 찾았을 땐, 완벽하다고 생각했다." Ranney가 말했다

"고성능 서버를 만들기 적합한 이벤트 루프이다. 고급 언어인 JavaScript이다. 이벤트 기반 시스템에서의 콜백 지원을 위해 필요한 closure에 대한 훌륭한 지원도 있다. 그리고 JavaScript 경쟁에서 V8을 내세운 Google도 있다."



V8 한번 써볼래?(Would you like to touch my V8?)

Ryan Dahl은 그의 JAvaScript 플랫폼을 FireFox의 가장 핵심 엔진인 Mozilla의 SpiderMoney에 올리려고 했다. 하지만 채 이틀도 되지 않아 Google의 V8로 변경하곤 지금까지 계속해오고 있다. "V8은 정말 멋지고, 깔끔한 라이브러리이다. 매우 간소한 라이브러리로 Chrome에서 분리된 것이다. 단일 패키지 형태로 배포되는데, 빌드하기 쉽고, 잘 정리된 문서화 헤더 파일을 제공한다. 마치 사용을 강요하는 것 같다. 다른 어떤 것에 대한 의존성도 없다. Mozilla의 것보다는 훨씬 더 진보한 방법인 것 같다."라고 Dahl은 설명했다.

Google이 공식적으로 이 프로젝트에 참여하는 것은 아니지만, Dhal을 비롯한 다른 Node 개발자들에 따르면, Google은 프로젝트 진행 중 V8 버그 수정이나 추가 내부 분석이 필요할 때는 계속 협조적이었다고 한다. Google V8 팀원인 Erik Corry는 The Reg와의 인터뷰에서 다음과 같이 말했다. "매우 흥미로운 프로젝트다. 지난 해 Berlin에서 열린 jsconf.eu 컨퍼런스에 참석했었는데, Node 주변으로 많은 사람들이 모여 있었다. V8을 아주 멋지게 사용하고 있었고, 최초 작성자가 기대했던 것은 아니었지만, 오픈 소스 프로젝트를 새로운 방법을 통해 병합할때 무엇을 해 낼 수 있는 지를 보여준다."

처음에 Dahl은 그 프로젝트를 web.js로 불렀다. 그 프로젝트는 Apache나 다른 "블럭형" 서버를 대체하는 웹서버에 지나지 않았다. 하지만 프로젝트는 이내 최초 웹서버 라이브러리 이상으로 성장했고, 거의 모든 것을 만드는데 사용되는 프레임워크로 확장되었다. 결국 node.js라는 새로운 이름을 가지게 됐다.

2009년 6월에 플랫폼 최초 버전을 공개했지만, 작년 jsconf에서 데모를 시연하기 전까지는 거의 관심을 받지 못했다. 그의 45분 동안의 발표는 기립 박수를 이끌어냈고, 그의 프로젝트는 어플리케이션 개발자들에게 뿐만 아니라 유명한 클라우스 제공회사에서도 사용되기 시작했다.

"[Ryan Dahl]은 확실히 [실시간] 세계가 의미하는 것을 이해하는 것에 가장 앞서 있었다. 그가 Node를 발표할때, 나는 깊은 인상을 받았다." RabbitEM을 보유한 Rabiit Technologies의 전 CEO이자 VMware의 수석 이사인 Alexis Richardson이 Node가 발표되기 전 Dahl의 블로그를 읽은 후 말했다.

한달 후, Dahl은 Joyent에 입사했다.



천국에서의 Node(Node in the heavens)

Joyent에서는 이미 JavaScript를 서버측에서 사용하는 방법에 대한 연구가 진행되고 있었고, Node가 그 아이디어에 맞아떨어질 것이라 생각했다. Dahl은 Joyent의 내부 기반 클라우드 서비스를 위한 코드를 작성하기 시작했고, 2년이 지나, Node는 Joyent의 서비스에서 매우 비중있게 사용되고 있다. Node는 Joyent의 SDC6 소프트웨어의 일부이기도 한다. SDC6를 이용하면 IPS나 다른 회사들이 독자적인 내부 기반 클라우스 서비스를 만들 수 있다.

Joyent에서는 Node를 클라우드 서비스에서 데이터 전송을 위한 오픈 소스 메세지 플랫폼인 RabbitMQ와 함께 사용한다. VMware에서는 Alexis Richardson과 팀원들은 개발자들이 비슷한 일을 할 수 있는 소프트웨어를 개발했는데, 그들은 이것을 rabbit.js라고 부른다.

RabbitMQ는 이미 Spring Integration, EventMachine, Twisted를 포함한 Java/Ruby/Python 이벤트 기반 시스템과의 통합 작업을 완료했고, Node는 자연스레 다음 차례가 될 것이다.Richardson은 "Node와 Rabiit의 조합은 data의 이동을 간소화한다. Rabbit은 데이터베이스과 같은 저장 장치 기술과는 다른 이동성 데이터 기술이고, Node는 그 부분이 어플리케이션과 상호작용하는 것을 위한 간단한 툴킷을 제공할 것이다. Rabiit은 데이터의 이동을 가능하게 한다. Node는 Javscript user들이 그 스타일대로 프로그래밍을 하는 것을 가능하게 해준다."하고 말한다.

동시에 rabbit.js는 클라이언트에 데이터를 즉시 보내기 위한 Node 기술을 Socket I/O 위에 구현하고 있다. LearnBoost의 CTO인 Cuillermo Rauch에 의해 고안된 Socket I/O는 상대적으로 새로운 push 표준을 지원하지 않는 브라우저 뿐만 아니라 웹소켓 지원 브라우저로 정보를 전달하는 단일 인터페이스를 개발자에게 제공한다.

"Socket I/O는 이중 채널을 지원하는데, 대신 채널을 통해 어떤 정보를 주고 받을지는 정의하지 않는다.RabbitMQ는 메세징을 어떻게 할지에 대한 의미론적인 것을 가지고 있기 때문에 [RabbitMQ와 Node의 조합]은 아마 스위트 스팟일지도 모른다."라고 rabbit.js를 작성한 VMware 수석 엔지니어인 Michael Bridgen은 말한다.
이 아이디어는 메세징을 클라우드에서 브라우저까지 확장시킬 것이다. 백앤드에서는 RabbitMQ가 개발자들이 데이터베이스 없이 데이터를 넘기는 것을 가능하게 해준다. Rabbit.js와 Socket I/O를 이용해서 Bridgen과 VMware는 웹 상에서 어플리케이션이 클라이언트와 대화할 때 위와 유사하게 동작할 수 있게 했다. 이것은 단지 Node가 해야하는 특징일 뿐이다.

Bridgen은 "Node는 스스로 웹 프로그래밍이 데이터베이스에 관한 것이 아니라 네트워크 프로그래밍에 관한 것이라는 걸 알고 있는 듯 하다. Node는 어떤 데이터를 선택하고, 특정한 곳으로 전송하고, 응답을 받고 다시 응답을 보내는 것, 여기저기 데이터들을 보내는 것에 대한 것이다. Node가 성공한 이유 중의 하나는 위와 같은 방식의 비동기식 데이터 전송을 사용자들이 JavaScript 안에서 사용할 수 있게 했다는 점이다."

Rauch도 같은 생각이다. Node는 LearnBoost 앱의 영역을 확장시켰다. Node를 사용하면 프론트 앤드와 백 앤드에서 동일한 언어를 사용할 수 있다는 점을 언급한다. "그것이 매우 매력적인 점이다. 어플리케이션을 JavaScript로 작성할 수도 있고, 모든 백 앤드 하부 구조도 JavaScript로 작성할 수 있으며, 클라이언트용 웹 어플리케이션도 JavaScript로 작성할 수 있다. 이것이 진정 싱글-스택 환경이다.



저 끝까지(All the way to the end)

처음에 Rayn Dahl은 Node를 최종 사용자용 어플리케이션을 개발하는 "최종" 개발자를 위한 플랫폼으로 생각하지 않았다. 하지만 곧 그의 생각이 잘못 되었음을 깨달았다. "Node를 단지 TCP 연결 오픈하는 것, 하위 레벨을 위한 것, 운영 체제 하부에서 하는 것이라 생각했다. 하지만 사람들이 Node를 이용해서 웹 사이트를 개발하기 시작했다."

이러한 관심때문에 Joyent은 Node를 웹 브라우저를 통해 서비스로 사용할 수 있게 해주는 no.de를 만들었다. LearnBoost의 Rauch에게 Node는 -다른 어떤 시스템보다- 서비스로서의 플랫폼(PaaS) 같은 것을 위한 맞춤 도구였다. Node는 그 클라우스 서비스에 정말 딱 맞았다. Node 서버를 운영하는 것은 리소르를 거의 쓰지 않았지만, 정말 많은 수의 사용자들을 관리할 수 있었다."

no.de를 이용하여 Node서버에 Git 저장소를 일단 만들고, 이것을 Joyent 하부 클라우드 위에서 동작하는 가상 머신에 넣는다. 그럼 데몬이 지속적으로 실행된다. 서비스 기반 사항들도 SDC6에 포함되어 있으므로, 써트 파티 업테들은 그들의 no.de를 운영할 수 있다.

Joyent의 Tom Hughes-Croucher에 따르면, Node 셋업을 벤치마킹할 때, Joyent은 단일 CPU 코어에서 초당 8,000개의 요구를 처리할 수 있는 'hello world' 서버를 만들었다. "단지 'hello world'라고 말하는 것이었는데, 아직도 그러고 있다. 일부 어플리케이션은 단일 서버에서 15,000명의 동시 접속자를 처리할 수 있다고 한다.

Hughes-Croucher는 이러한 효율성덕에 Node가 최종 개발자들 사이에서의 인기가 하늘을 찌를 것이라 믿고 있다. 히지만 Ryan Dahl이 지적했듯이, Node는 아직 틈새 플랫폼에 불과하다. "대부분의 사람들은 ASP, Java, PHP 등을 이용해 작업하고 있으며, 새로운 플랫폼을 찾으려하지 않는다. 그들은 고객이 있다. 그래서 그들은 Microsoft의 다음 제품을 사용하지, 새로운 런타임을 찾지는 않는다."

게다가, 개발자들이 멀티스레드 개발에서 기대하는 것과는 컨셉적으로 많은 차이가 있다. Dahl은 "이 비블락형 방식을 사용하도록 강요를 받았다. 원격 백 앤드 같은 것에게 정보를 보내려고 할때마다, 콜백을 설정해줘야 한다. '데이터베이스로부터 결과를 받고, 다음 줄에서 그 결과를 사용한다.'하고 할수는 없다. 콜백을 설정해야 무엇을 전달받든 다른 함수로 이동할 수 있다.

"a하고, b하고, c하고, d하고처럼- 순차적으로 많은 작업을 해야된다는 것은 매우 힘든 일이 될 수도 있다. 일반적인 블락형 언어에서는, 단순하게 한줄 한줄 있는 a, b, c, d를 차례로 할 수 있다. Node에서는 각각의 함수로 점프해야한다. 데이터베이스가 데이터를 보내도록 요청을 하고 이벤트 루프로 돌아가서 다른 요청을 처리한다. 응답을 받으면 다음 요청을 보내는 함수를 호출한다. 다시 이벤트 루프로 돌아가고 더 많은 요청을 처리한다."

또 다른 면을 보면, 서버쪽 작업을 해보지 않고 프론트 앤드에서 JavaScript를 사용하는 사람들에게는 이 플랫폼이 편할지도 모른다. "클라이언트측 개발자들에게는 비블락형 방식이 꽤나 자연스럽다. 그들은 다른 방식은 생각하지 않을 것이다."


하지만 무엇보다 중요한 점은 Node가 실시간 웹앱의 새로운 태동에 적합하다는 것이다. 실시간 툴을 작성하는 많은 방법들이 있지만, Node는 사이트의 다른 부분을 운영하는 같은 플랫폼에서 개발을 가능하게 해준다. 훌륭하게도, Facebook의 채팅 서버는 Erlang으로 개발되었지만, Guillermo Rauch가 지적했듯이, Facebook의 나머지 부분은 그렇지 않다.

Rauch는 다음과 같이 말했다. "PHP와 Apache의 전통 구조를 가지고 있다면, 실시간으로 무엇을 한다는 것은 거의 불가능하다. 항상 실시간 통신은 다른 웹서버나 직접 작성한 특수 서버로 옮겨야한다. Facebook은 Facebook 채팅 만을 위해서 Erlang 서버를 만들었고, 그것이 PHP 스택과 통신하도록 했다. Node를 이용하면 이 모든 하부구조 구성요소의 복잡성이 완전히 제거된다. 실시간 스택을 일단 웹 어플리케이션, DBMS 레이어, 또 다른 것에 사용한 동일한 코드를 이용해 작성할 수 있다."

그래서 Node는 새로운 Rails도 새로운 PHP도 아닌 것이다. 그것은 완전히 다른 무언가이다.



댓글을 달아 주세요

  1.  댓글주소  수정/삭제  댓글쓰기 소혼 2011.04.03 08:14 신고

    원문 링크가 이상한가? 안가지네;;
    Node.js는 언제 볼라나 ㅋ

  2.  댓글주소  수정/삭제  댓글쓰기 toms outlet 2013.08.04 08:44 신고

    지금은 반짝반짝 빛이 나겠지,, 하지만 시간이 흐르면 그빛은 사라저버릴거야,지금 우리처럼

※ 잘못 번역된 내용이 “당연히” 있을 테니 원문을 꼭 참고해서 읽으세요.
번역 오류나 개선, 오타에 대한 피드백은 언제나 환영하고 감사드립니다. ^^

P2P Web Apps
- Brace yourselves, everything is about to change
P2P 웹 앱 - 긴장하라, 모든 것이 바뀔 것이다


Written by Mark Boas(@maboa) on March 7, 2011
Translated by GyuCheol Choi(@gc8134) on March 20, 2011
원문 보기



이전의 클라이언트-서버 웹 모델은 구식이 되었다. 생명력의 마지막에 다다라서, 조만간 사라질 것이다. 다음 세대에 걸맞게 견고하고 독립적이며 빠른 웹 어플리케이션을 만들려고 한다면, 새로운 방법을 찾고 생각하는 방법을 바꿀 필요가 있다. 중앙에 모여있던 것을 해제하고 새로운 분산 아키텍쳐로 변경해야 한다. 이 포스트에서 내가 설명하고자하는 기본 아이디어가 바로 이것이다.

분산 아키텍쳐는 많은 이유로 매력적인 것처럼 보인다. 현재는 많은 웹 어플리케이션이 어떤 작업을 수행하기 위해 다른 웹 어플리케이션에 의존하고 있지만, 이점은 처음 상상했던 모습만큼 좋은 것은 절대 아니다. 주요 문제는 실패 단일점(SPOF)이다. 다수의 개발자들이 많은 실패점을 가진, 하지만 그 대안은 없는 어플리케이션을 개발한다.(또한 현재 웹 모델이 그렇게 개발하게 만든다.) jQuery를 위한 Google CDN을 예로 들어보자 - 조금 황당한 이야기이지만, 이 서비스를 다운시켜 버리면 웹 어플리케이션의 절반이 동작하지 않는다. Google.com은 아마 전 세계 소프트웨어가 그동안 알고 있는 모든 것들 중 가장 큰 실패 단일점일 것이다. 좋지 않다! 많은 개발자들은 만약 '구글에 의존할 수 없다면 누구에게 의존하란 것인가? '라고 생각할 것이다. 요점은 어떠한 단일 서비스에 의존하지 말라는 것이다. 더 많은 단일 서비스에 의존할 수록 더 나빠질 것이다. 핵 전쟁에도 버틸 수 있는 ARPANET을 기반으로 한 인터넷의 기본 원칙을 (그리고 그 속에 심어진 중복성)을 잊어버린 것 같다.

이제는 더 견고하고 중앙화되지 않고 분산된 새로운 웹 모델을 찾기 시작해야할 때라고 믿는다. 그리고 P2P가 그것의 중요한 일부분이라고 생각한다. 서버로도 쓰이게 된 다수의 클라이언트는 요구되는 견고함을 전달할 수 있어야 하고, 특히 SPOF를 없을 수 있어야 한다. P2P 앱 형태의 Wikileaks를 상상해보자. - 단일 중앙 서버 URL 모드를 없앤다면, wikileaks.com에 어떤 문제가 발생해도 웹 앱은 상관없이 잘 동작할 것이다. Wikileaks가 문서 배포를 위해 bittorrent를 선택한 것은 우연이 아니다. 분산 아키텍처의 또 다른 장점은 크기를 변경하기 쉽다는 것이다. 이것에 대해서는 이미 잘 알고 있다. 클라이언트측 코드의 이점 중의 하나이다. P2p 웹 앱으로서의 트위터를 생각해보자. 클라이언트들간에 대량 분산 처리를 조절하는 것이 얼마나 쉬운지 상상해보자. 광범위한 웹 기반 P2P 표준으로 부터 엄청난 이득을 위한 수 있을 것이라 생각한다.

잠깐동안 위험한 상상을 하려고 한다. 그 가능성을 탐구하는 동안 참아주면 좋겠다. '만약'부터 시작해보자. 만약, 클라이언트측 JavaScript를 캐시 매니페스트에 다운로드 받을 수 있을 뿐만 아니라, 서버측 JavaScript도 다운로드 받을 수 있다면? 그리고 만약 데이터/통신 브로커에 불과한 것이 아니라면 서버-사이드는 무엇일까? NoSQL 솔루션과 서버측 JavaScript(SSJS)의 인기 상승을 고려해보면, 서버에서 실행되는것 보다는 약간은 다른 버전을 전달하고 싶을 수도 있으므로 SSJS를 브라우저내에서 실행할 수 있게 하는 것은 그리 오래 걸리지 않을 것처럼 보인다. 그리고 이것은 아마 중계하는 방식과 다름이 없을 것이다. 우리는 이미 색인형 데이터베이스 API를 클라이언트에 가지고 있으므로, 동등한 데이터 스토리지 API를 표준화하려고 한다면, 이미 거의 다 되어 있다. 그렇지 않은가?

Twitter를 다시 예로 들어 간단한 예를 들어보자. 이 모든게 어떻게 동작하는 것인가? twitter.com을 접속하면 우리의 P2P 사용가능성을 인식하고 p2p.twitter.com으로 페이지를 전환해준다. 페이지가 로드된 뒤에는 SSJS를 다운받고 로컬 서버에서 실행 시키기 시작한다. 아마 다른 어떤 피어(peer)가 Twitter를 사용중인지에 대한 정보도 얻을 수 있을 것이다. P2P가 잘 동작했다고 가정하면, 거의 즉시 twitter.com에서는 독립적이되고 SPOF 문제는 해결된다. 오프라인 실행을 선택한다면 거의 동시에, 일반적으로 하는 송수신 기능 등 모든 것ㅇ르 가능하게 하는 데이터와 로직을 이미 충분히 가지게 된다. twitter.com을 로드하는 양은 서버측과 클라이언트측 코드를 각각 실행함으로써 극적으로 줄어들게 된다. P2P 브라우저에는 twitter.com은 트래커나 업데이트 소스처럼 여겨질 것이다. 로컬에서는 더 빠르게 동작한다는 사실도 잊지 말자.

이 시점에서 서버측과 클라이언트측 JS의 차이점이 약간은 불명확해진다는 것은 명백하다. 그러나 적어도 중계자의 입장에서는, 웹 앱이 취해야하는 이동 경로를 제공해준다는 점 때문에 이러한 구분을 유지하는 것이 필요하다. P2P 브라우저를 지원하지만, 구형 브라우저에서는 여전히 단일 서버 방식에 의존한다. 또 다른 흥미로운 유익한 사이드 이펙트는 아마 '소스 보기'의 강력함을 서버측 코드에도 적용할 수 있다는 점일 것이다. 다운로드를 받을 수 있으면, 당연히 볼 수도 있다.

가장 확신히 가지 않는 부분은 이 모든 것에서 HTTP는 어떤 역할을 하는가이다. 이러한 혁명적인 변화에 맞춰 진화하는 방법이 가장 최선일 것이다.REST적 구조의 많은 장점을 취하고, 어플리케이션의 실시간 'push' 특성을 위해 더 효율적인 TCP 기반 통신을 한정함으로 써 클라이언트와 서버간의 통신을 위한 HTTP를 계속사용할 수 있다.

Opera Unite(P2P와 웹서버가 브라우저에 포함되기 시작한)와 같은 시도, 다른 브라우저들의 동일한 것에 대한 연구를 보면, 이것이 웹 앱이 지향하는 방향인 것 같아 보인다. 무시하기에는 너무 많은 이점이 있다: 견고함, 속도, 확장성 - 매우 매력적인 것들이다.

이제 필요한 것은 좀더 깊고 심도 있는 토론, 그리고 실현 가능하다면, 채택 가능한 표준이 정립되어 구현을 위한 공통 접근법을 통해 모든 브라우저가 전진해나가는 것이 아닐까 생각한다. 보안도 명백히 이러한 토론의 주요한 요소가 될 것이며, 클라이언트에서의 라이브러리 재사용이 일반화 될 것이다.

웹 앱이 네이티브 앱과 경쟁하려고 한다면, 웹 앱은 네이티브 앱이 하는 모든 것을 가능하게 해야하고, 이것은 P2P 통신이나 개선된 오프라인 지원능력도 포함한다. 이 중요한 두 가지 요소들은 서로 연관된 것 처럼 보인다. 일단 적합인 매커니즘과 표준이 정립되면, 모든 플랫폼에 동일한 접근 방법을 이용하여 네이티브 앱과 동일한 또는 더 나은 웹 어플리케이션을 만들 수 있다는 사실은 강력한 차별 포인트가 될 것이다.

댓글을 달아 주세요