Jonathan Schwartz's Weblog : Weblog

« 흐린 하늘 속의 햇살... | Main | 거역할 수 없는 거대한 흐름 »

수요일 11월 08, 2006

네트워크 클라이언트의 힘을 믿습니다

지난 주, John Markoff와의 인터뷰에서 제가 언급한 내용을 들으신 분은 아마 제가 제정신이 아니라고 생각하셨을지도 모르겠습니다. 그때 저는 "씬 클라이언트를 믿지 않는다"라고 말했었죠.

우선, 저의 기술쪽 경력이 클라이언트(예: 데스크톱) 소프트웨어를 만드는 기업에서 출발했다는 것에서부터 제 이야기를 시작하겠습니다. 저는 사용자 경험을 상당히 중시합니다. 그런 이유 때문에 씬 클라이언트(thin client)란 단어에 모순이 있다고 늘 생각해 왔습니다. 이 두 단어처럼 서로 어울리지 않는 단어도 없습니다. 장치에 최소한 몇 가지 기능이나 '상태'가 없는 이상 클라이언트는 성립되지 않습니다. 이러한 상태(메모리, 스토리지 또는 애플리케이션 풋프린트에 의해 측정 가능한)의 크기는 클라이언트의 상호 작용 방식과 직접적인 연관이 있습니다.

쉽게 예를 들어 설명해보면 다음과 같습니다. 셋톱 박스를 채택하면서 TV가 더욱 관심을 끌게 되었고, iPod가 등장하면서 라디오의 인기 역시 상승했지요. Java 플랫폼으로 게임과 벨소리를 다운 받을 수 있게 되면서 휴대폰이 붐을 이루기 시작했습니다. (캐시는 분실 가능성이 있긴 하지만- 노트북을 생각해 보세요.-강력한 기능이 있습니다. 이 부분은 다른 블로그에서 자세히 언급하겠습니다.)

업계 관행에 따르면 브라우저에 작성된 애플리케이션을 "씬"이라고 정의합니다. 이 정의에 따르면 서비스 랜더링에 브라우저 자체의 존재가 필요하다는 측면에서 씬은 "다른 누군가의 런타임 환경을 사용하는 것"이라는 동일한 의미를 갖게 됩니다. 하지만 브라우저는 운영 체제와 윈도윙(windowing) 환경을 필요로 하기 때문에 엄밀한 의미에서 씬과는 다릅니다. 즉, 제가 저서에서 Google이나 YouTube가 "씬 클라이언트"라고 언급한 것은 엄밀히 말하면 부정확한 표현이며, 이 경우 다른 누군가의 씩 클라이언트(thick client)를 활용하는 서비스라고 해야 정확합니다. 여기서 씩 클라이언트는 브라우저가 되겠지요.

앞서 말끔드린 바와 같은 생각과 함께, 저는 또한 강력한 클라이언트를 통해 우리가 직접 눈으로 확인하는 고객 혁신이야말로 가장 중요한 혁신이라고 생각합니다. 최근까지 클라이언트 소프트웨어나 하드웨어에 투자하는 기업들을 찾는 것은 쉬운 일이 아니었습니다. 물론 브라우저 애플리케이션들이 다수 있었지만 그 이상도 이하도 아니었지요.

하지만 이제 상황이 바뀌고 있습니다. 클라이언트에 대한 혁신 노력이 재개되고 있습니다. Web 2.0이 이슈로 등장하고, 상호작용 방식의 독창적인 데스크톱 기능과 수많은 툴바에 대한 기업들의 투자가 봇물처럼 이어지면서 대형 포털이 JavaScript의 부활을 주도하고 있습니다. 더욱 흥미 있는 것은 10대들의 소지품은 물론 자동차 대시보드와 거실 등, 우리 주변의 거의 모든 곳에서 사용할 수 있는 다양한 새로운 장치들이 속속 등장하고 있다는 사실입니다. 제 나름의 정의에 따르면 이들은 모두 씬이 아닙니다. 다만 모두 네트워크를 활용합니다. 하지만, 이것이 일대 혁신일 수 밖에 없는 이유는 사용자에게 단순히 네트워크만 제공하는 브라우저가 아닌 독립형 클라이언트 애플리케이션 및 장치이기 때문입니다.

그렇다면 클라이언트가 새로이 주목 받게 된 이유는 무엇일까요? 이 분야는 위험도가 높아 몇 년 전만 해도 투자가 미비했지만 이제는 상황이 달라졌습니다.

그 첫 번째 원인은 전략적 이유입니다. 타사의 브라우저에 의존하는 것이 불확실한 선택이라는 것이지요. Microsoft Vista의 브라우저에 "news"란 단어를 입력하면 news.com이 아닌 MSN News로 이동하듯이 브라우저 배포사들이 이 점을 경쟁에 이용하는 경우 더 위험할 수 있습니다. 이런 이유 때문에 많은 기업들이 Firefox, Opera 및 Java 플랫폼에 맞게 서비스를 인증하고 있으며 iTunes 또는 NetBeans 개발자 도구와 같은 독립형 네트워크 클라이언트를 구축하기 위해 자체 애플리케이션을 다시 작성하고 있기도 합니다. 독립형 네트워크 클라이언트는, 하드웨어와 소프트웨어 모두의 비우호적인 런타임 환경에서 탈매개화(Disintermediation)의 위협을 피할 수 있습니다.

두 번째 이유는 사용자들이 기다리는 것을 싫어하기 때문입니다. 개인적인 사용자 입장에서 "Web 2.0"이 등장하게 된 기본적인 동기에 대해 공감합니다. Google Earth나 NASCAR의 PitCommand 등의 상주 기능은 사용자가 웹 사이트를 방문할 때마다 방대한 양의 JavaScript를 브라우저로 불러들일 필요가 없기 때문에 웹 서핑이 훨씬 만족스럽다는 것이죠. 컴퓨팅의 세계에서 인내는 미덕이 아닙니다. 문자 그대로 눈에서 멀어지면 마음까지 멀어집니다. 사용자를 기다리게 하면 다른 곳을 찾아 가버립니다. 사용자가 떠나지 않도록 지속적으로 실행 가능한 상태를 유지하거나 허리띠에 부착할 수 있는 장치를 제공한다면 고객을 확보할 가능성이 더 높아지겠죠.

마지막으로 네트워크가 널리 보급되고 있기 때문입니다. 거의 모든 곳에서 신호를 수신할 수 있게 되었고 비교적 신뢰할 수 있는 유선 네트워크 방식이 모바일과 무선 네트워크를 통해 서비스를 공유하는 방식으로 전환되고 있는 상황입니다. 하지만 후자의 경우, 다소 떨어지는 신뢰성이 점점 문제가 되고 있지요. 네트워크 서비스의 유용성을 유지하려면 네트워크를 벗어나 호출이 되었을 때에도 이를 표시할 수 있는 방법이 필요합니다. 즉, 잠시 동안 네트워크 접속이 끊어져도 상호작용을 계속하는 클라이언트가 되어야 한다는 것을 의미합니다. 업데이트 기능을 사용할 수 없는 경우에도 자동차 네비게이션 시스템이 작동하는 것처럼 말이죠.

다시 강조합니다면, 클라이언트와 사용자 경험을 중시하는 것이 저의 기본 입장입니다. 클라이언트가 없는 서버는 난방용 히터에 지나지 않습니다. 따라서 클라이언트, 특히 네트워크 클라이언트가 다시 주목을 받게 된 것은 바람직한 일입니다. 그 동안 씬에 대한 기존의 정의에 너무 오랫 동안 얽매여 왔습니다. 저는 (매우 순수하고, 전력 소모가 낮으며, 분실위험이 없는 한 가지만 제외하고) 씬에 대해선 그다지 큰 믿음은 없지만 네트워크와 네트워크에 연결된 모든 장치에 대해서는 확고한 믿음이 있습니다. (내년에라도 CES를 한 번 방문해 보시면 놀라실 겁니다.)

여러분께 미리 말씀드리자면 어제 Java Community Process를 통해 전해 들은 바로는 Java 커뮤니티에서 투표를 통해 신형 Java 플랫폼인 Java Standard Edition 6를 채택하기로 했다고 합니다. 근래에 가장 획기적인 기능을 갖춘 Java 플랫폼이 출현할 것으로 예상되며 이것은 사용자 경험에 엄청난 변화를 줄 것입니다. 엄청난 변화 말입니다.

Java를 통해 수십억개 이상의 장치(네트워크 클라이언트)를 가동할 수 있게 되면서, 우리는 다음에 출현하게 될 또 다른 수십억개의 장치에 대해 어떤 방식으로 접근할 것인가라는 질문을 받게 되었습니다. 이 질문에 대한 답변은, 제가 가장 좋아하는 격언으로 대신하고 싶습니다.