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

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

댓글을 달아 주세요



티스토리 툴바