사이드바 영역으로 건너뛰기

게시물에서 찾기네트는 정말 광대해~

66개의 게시물을 찾았습니다.

  1. 2007/06/25
    RIA와 인터넷의 미래(1)
    레니
  2. 2007/06/07
    위키피디아의 중립성 신화
    레니
  3. 2007/05/25
    참을 수 없는 로그인의 무거움
    레니
  4. 2007/04/10
    잡스의 당혹스런 선언과 DRM
    레니
  5. 2006/11/20
    누구를 위해 컨텐트는 생산되는가 - UCC(2)
    레니
  6. 2006/10/19
    TCP/IP의 이해 #2 - 게이트웨이와 DNS(3)
    레니
  7. 2006/09/24
    TCP/IP의 이해 - IP 주소
    레니
  8. 2006/08/17
    버퍼링을 미워하지 마세요 : 스트리밍 기술(7)
    레니
  9. 2006/08/16
    티스토리 분양받다(2)
    레니
  10. 2006/07/14
    서비스로 알아보는 Web 2.0
    레니

RIA와 인터넷의 미래

지난 21일에 webappscon 2007에 다녀왔습니다. 웹앱스콘은 웹 어플리케이션의 새로운 기술을 소개하고 논의하는 컨퍼런스로서, 웹기술과 관련된 업체들이 자발적으로 조직한 행사입니다. 꽤 홍보가 잘 되어서인지 이 업계에서 유명하단 사람들은 여기서 죄다 볼 수 있고 다양한 새로운 기술들을 접할 수 있었죠.

관심 분야에 따라 심도있는 논의를 진행하는 오전 행사 이후, 이날의 오후 세션은 내노라하는 여러 업체들의 주제 발표로 이루어졌습니다. M$, 구글 등 거대 글로벌 기업은 물론이고 크고 작은 국내 기업들의 발표가 이어졌습니다. 꽤 길었던 오후 행사를 보며 느낀 점은 인터넷이 또다른 경쟁의 시대로 들어섰다는 것이었습니다. 물론 지금까지도 인터넷의 역사는 브라우저, 웹서비스, 검색 등 기술 경쟁의 역사와 궤적을 같이 했다고 할 수 있습니다. 그리고 이번 컨퍼런스를 통해 앞으로 이러한 경쟁은 웹 어플리케이션으로 이어지고 있다는 것을 알 수가 있었습니다.

처음 웹서비스는 "서버가 요청을 빠르고 안정적으로 처리할 수 있는 것"을 중요하게 생각했습니다. 트래픽이 많지 않고 네트웍 장비 기술과 인프라가 충분하지 않았던 때에는 보다 빠른 응답과 다운되지 않는 웹서버가 더욱 중요했었죠. 아파치Apache나 PHP같은 프로그램들이 크게 인기를 끌었던 이유가 위와 같은 것이 가능하기 때문이었습니다. 그러나 서버와 네트웍 기술이 발전하면서 장비의 성능이 크게 향상되고 가격도 저렴해 지면서, 화두는 "쉽게 개발할 수 있고 유지할 수 있는 기술"이 중요해지기 시작했습니다. 덩치가 크고 느려서 실용성이 없다고 생각되었던  자바Java가 부활하게 된 것도 체계적으로 개발이 가능하고 유지보수하기가 쉽다는 특성이 있기 때문이었죠. 동시에 시스템의 기본적인 기능을 갖추고 개발을 용이하게 해 주는 프레임웍Framework이 주목받게 되었습니다. 프레임웍이 있으면 개발자는 네트웍 프로그래밍, 데이터베이스 통신, 설정 파일 처리 등 시스템의 기반이 되는 기본적인 기능들을 별도로 개발할 필요 없이, 가장 필요로 하는 기능만 개발하면 된다는 장점이 있습니다. 그리고 복잡한 서버 시스템의 구조를 최대한 정리된 형식에 맞춰 개발할 수 있어서 프레임웍 기술이 중요하게 여겨지게 된 것이죠. 지금도 다양한 프로그래밍 언어 기반의 프레임웍들이 경쟁하며 춘추전국시대를 열어가고 있다고 할 수 있습니다.

하지만 누가 뭐라 해도 요즘 웹서비스계의 최대 화두는 "서버에 부담을 덜어주면서 더 많은 일을 처리할 수 있는 것"이라 할 수 있습니다. 이제까지는 강력한 서버가 복잡한 요청을 받아 엄청난 데이터를 처리하여 빠른 시간 내에 결과를 돌려주는 것이 미덕이었으나, 이것은 서버의 구조를 복잡하게 만들고 유지보수하기 힘들게 만든 측면이 있었습니다(설령 프레임웍을 잘 사용한다 하더라도). 게다가 서버가 아무리 미끈한 데이터를 뽑아서 돌려준다 하더라도 그것을 사용자에게 보여주는 클라이언트의 성능이 형편없다면 사용자가 만족하기 힘들겠죠. 요즘 사용자들은 단순한 HTML 페이지를 받아보는 것에 만족하지 못하고 보다 다이나믹한 화면을 보기를 원합니다. 이런 현상은 특히 플래시가 클라이언트로 사용되는 경우가 많아지면서 더욱 심화되고 있습니다. 그래서 요즘의 웹서비스는 단순히 초강력 서버의 수퍼맨같은 활약으로만 이루어지지 않고, 클라이언트까지 포함한 총체적인 프레임웍을 구성하려는 움직임이 강화되는 추세입니다.

이러한 추세의 대표주자가 화려한(rich) 클라이언트의 서막을 연 플래시입니다. 플래시는 예전에 매크로미디어Macromedia라는 회사에서 개발한 클라이언트 도구로서, 현재는 포토샵 등으로 유명한 어도비Adobe 사에 인수되어 있습니다. 원래 플래시는 동영상을 만들듯이 로컬 컴퓨터에서 만들어 배포하면 플래시 플레이어나 웹브라우저에서 재생하던 클라이언트 전용 프로그램이었습니다. 단지 거의 모든 브라우저와 OS에서 원활하게 보인다는 장점 때문에 널리 사용되고 있었죠. 그러나 2004년 Flex의 등장으로 인해 플래시는 단순 클라이언트 프로그램을 벗어나 서버-클라이언트를 아우르는 플랫폼으로 확장되게 되었습니다. Flex는 서버-클라이언트 기술, 프로그래밍 언어로서 액션스크립트, XML 기반 유저 인터페이스 기술(MXML) 등을 망라하는 웹기반 플랫폼입니다. 부담스러운 수준의 라이선스 비용에도 불구하고 많은 웹서비스들이 Flex를 사용하여 구성되고 있는데(특히 한국에서), 이는 플래시의 엄청난 범용성 덕을 많이 본 셈이죠.

플래시처럼 화려하고 동적인 클라이언트는 웹 어플리케이션의 새로운 중심으로 자리잡고 있습니다. 이들을 RIA(Rich Internet Application)라고 총칭해서 부릅니다. RIA는 마치 기존의 오피스 같은 데스크탑 어플리케이션처럼 강력하고 많은 기능들을 수행할 수 있으며, 입력창과 라디오 버튼 몇 개로 이루어진 정적인static HTML보다 동적이고 편리한 유저 인터페이스를 제공합니다. 하지만 RIA와 기존 웹 어플리케이션 사이의 결정적인 차이는 서버와의 관계에 있습니다. 기존 웹 어플리케이션은 서버에서 보내주는 내용에 거의 의존하여 출력을 합니다. 표 하나만 그리더라도 서버에서 표의 마지막 라인까지 지정해서 보내줘야 출력이 가능했죠. 하지만 보통 RIA는 서버에서 모든 정보를 얻어오는 것이 아니라 순수한 데이터만을 XML등으로 받아오는 경우가 많습니다. 일단 데이터를 받아오면 RIA는 이 데이터를 뒤섞거나 순서를 재정렬하거나 하는 작업을 임의로 할 수 있습니다. 아까처럼 표 전체를 요청하는 것이 아니라 표에 들어가는 데이터만을 요청하게 되고, 순수한 데이터만을 이용하여 표의 마지막 줄을 제일 앞으로 보내는 식으로 하는 출력을 할 수 있게 되는 것이죠.

RIA계의 전통의 강자는 아직까지 Flex임이 분명합니다. 하지만 플래시 플레이어에 의존해야 하고 엄청난 비용이 들어가는 Flex에 불만을 느끼는 사람들이 많습니다. 그래서 가장 일반적인 웹의 표현방식인 다이나믹HTML(DHTML)과 자바스크립트, XML을 이용한 Ajax(에이작스라고 보편적으로 읽습니다)가 2006년 선풍적인 인기를 끌 수 있었죠. 역시 예전에 네트워커에서 소개한 바가 있는 Ajax는 비동기적asynchronous 통신을 사용하여 서버 부하를 줄이고, 데이터 교환 형식으로서 XML을 사용하며, DHTML과 자바스크립트로 동적인 페이지를 구성하는 방식입니다. 플래시 플레이어 같이 별도의 프로그램을 깔 필요가 없으며, 브라우저만 있으면 동작한다는 장점때문에 많은 관심을 받았으며, 지금도 Ajax 어플리케이션은 널리 사용되고 있습니다. 다만 XML 처리나 브라우저마다 자바스크립트를 별도로 작성해야 한다는 점 때문에 다소 사용에 번거로운 점이 있다는 단점이 있지만, 이는 프레임웍이나 라이브러리 등의 배포로 점차 나아질 것 같습니다.

이와 함께 최근 RIA계를 크게 흔든 사건이 있었으니, 바로 M$의 등장입니다. 구글 데스크탑, 구글 어스 등 웹에서 데스크탑으로 영역을 넓혀가는 구글의 행보와 정반대로 M$는 데스크탑에서 웹으로의 진출을 노리고 있는데, 최근 실버라이트의 출시를 발표함으로써 어도비와 정면 승부를 선언하게 된 것이죠. 실버라이트는 XAML이라는 XML 포맷의 유저 인터페이스을 제공함으로써 M$가 보유하고 있던 데스크탑 플랫폼인 닷넷(.NET) 프레임웍을 연결시킬 수 있다고 합니다. 아직 정식 출시된 단계가 아니라 구체적인 것은 나오지 않았지만, OS와 브라우저를 가리지 않고 지원한다는 호언장담을 믿어본다고 하면(현재는 아직 리눅스 버전이 없습니다만), Flex와 좋은 승부가 되지 않을까 하는 예상을 할 수 있겠습니다.

이밖에도 구글은 구글 API를 기반으로 한 플랫폼 구글기어즈Google Gears를 발표했으며, XML 기반의 유저 인터페이스를 만들 수 있는 오픈라즐로OpenLaszlo도 눈길을 끌었습니다. 바야흐로 지금은 어도비가 수성하고 있던 웹 어플리케이션계에 RIA라는 전장이 마련되고 전운이 감도는 상황이라고 할 수 있겠네요.

RIA 는 보통 웹 어플리케이션 기술에 더하여 서버, 데이터 교환, 프로그래밍 언어, 개발도구 등과 함께 이루어지는 것이 보통입니다. 위에서 언급한 Flex는 Flash 클라이언트와 Flex 서버, MXML, 액션 스크립트, Flex SDK 등으로 묶이는 것처럼 말이죠. 물론 결국 하나의 RIA는 하나의 플랫폼을 이루는 것이 보통이고, RIA의 각축장은 결국 플랫폼의 각축장입니다. 최후의 승자가 누가 되던 간에, 사용자들은 요즘 많이 강조되는 UX(User Experience), 즉 보다 풍부한 사용자 경험을 할 수 있는 환경이 조성될 것으므로 경쟁을 즐거운 마음으로 지켜보면 될 것 같습니다. 물론 그 사이에서 변화하는 환경에 적응해야 하는 개발자와 디자이너들은 무척 힘들겠지만요. :)
진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크

위키피디아의 중립성 신화

얼마전 위키피디아와 관련된 재미있는 기사를 봤는데, 많은 사람들에 의해 작성되고 있는 위키피디아조차도 소수 의견이 쉽게 묵살되는 과정을 보여주고 있다.

처음 위키라는 툴을 봤을 때에는 든 생각은 참 개발자스러운-_- 도구란 것이었다. 사용자 편의성을 지향하면서 갈수록 복잡해지는 게시판이나 블로그 등과 비교해 보면, 위키는 단순한 기능이지만 필요에 따라 확장시키기 쉬운 구조로 되어 있다. 몇몇 룰만 알면 쉽게 사용할 수 있는 에디터, 문서 제목을 기준으로 한 단순하지만 막강한 인덱싱,  필요에 따라 붙여 쓸 수 있는 매크로 등은 위키가 심플하지만 강력한 기능이라는 점을 잘 보여준다.

이와 함께 위키를 주목하는 또다른 이유는 바로 공동 편집 시스템 때문일 것이다. 지금은 한 물 갔지만 웹2.0이 뜨면서 새삼스레 주목받던 집단지성이란 키워드에 의해 위키 시스템과 위키피디아가 많은 사람들의 관심을 받게 되었다. 솔직히 집단지성Collective Intelligence이 라는 용어는 상당히 아카데믹한 용어라 정확히 이해하기는 힘들다. 오히려 개인적으로 관심있는 부분은 "브래태니커(1인 편집) vs 위키피디아(집단 편집)"의 대결 구도였는데, 이 구도는 "지식을 수집하고 정리하는 데 있어 어떤 방법이 더 합리적인가"라는 흥미로운 논점을 낳게 되었다.

위키의 편집 시스템은 공동작업을 할 때 상당한 위력을 발휘한다. 실제로 내가 속한 팀에서도 기본적인 프로젝트 문서 작성은 위키로 하고 있고, 지식 공유, 일정 관리 등 다양한 일을 병행하고 있다. 기존 문서의 내용에 이의가 있다면 정중하게-_- 줄을 긋고 편집자의 이름과 함께 새로운 설명을 단다. 문서를 통합하거나 재배치를 할 때면 관련자들에게 노티를 하고 일괄적으로 문서를 정리한다. 기본적인 룰만 지켜주면 위키를 통한 문서 관리와 지식 축적은 다른 어떤 툴보다 쉽고 강력하다.

하지만 이 방식이 유효한 것은 일정한 규모의 공동체 내부이기 때문이라는 생각이다. 팀원들이 서로를 알고 있고 위키를 합리적으로 사용할 책임이 모두에게 있기 때문에, 위키를 통한 지식 축적과 정리가 가능하다고 생각한다. 중소규모 이상의 공동체에서 과연 이런 방식이 문제없이 통용될 지 의문이다. 특히 익명성이 보장되는 공간에서 모든 참여자의 의견을 존중하고 최대한 합리적인 문서를 만들어내려는 노력을 누구나 할 수 있을 지 의심되는 것이다.

이것은 컨텐츠의 종류에 따라 달라지는 문제는 아니라고 생각한다. 위키피디아에서는 정치적 문제에 대한 충돌을 방지하기 위해 중립적 시각을 요구하는 경우가 있으며, 토론이 가능한 페이지를 만들어 놓기도 한다. 그러나 황우석 사태에서도 드러났듯이 순수한 학문적 중립성이라는 것이 존재하는지 의문이며, 모든 지식은 정치적으로 쟁점화될 여지가 있다. 모든 논쟁 사안에 대해 익명의 다수파가 소수파에 대한 예의를 지켜줄 수 있을지 의문이 든다는 것이다.

위키피디아의 가장 위험한 점이 바로 여기에 있다. 위키피디아는 "키워드=설명"로 지식을 정의한다. 다양한 의견을 받아들이는 페이지도 존재하지만, 위키피디아의 기본 포맷이 키워드와 1:1로 대응하는 설명이라는 점은 분명하다. 이런 시스템에서 다른 의견을 제시하기 위해선 앞선 의견을 부정해야 가능하다. 물론 별도의 키워드로 가지를 치는 방식도 가능하겠지만, 위키의 기본 운영 형태인 계층형 구조에서는 상위 키워드의 순서가 더 중요하게 다뤄지기 때문에 다른 의견을 개진하는 데 있어 그닥 효율적이지 않다. 물론 위키피디아는 기본적으로 "사전"이기 때문에 이견들을 통합해 하나의 페이지로 만들고, 비주류 의견들은 링크 등으로 참조하도록 되어 있지만, 사전에 최우선으로 등재되기 위한 정치적 투쟁이 벌어질 가능성은 언제나 존재하게 되는 것이다.

하지만 이런 문제는 분명 위키가 가지는 도구적인 합리성과 별개의 것이다. 분명 위키는 다른 어떤 툴보다 빠르고 쉽게 지식을 찾을 수 있는 툴이다. 하지만 현재 일반적인 위키의 구조는 (특히 대규모의) 논쟁을 벌이기에 적합하지 않다고 생각한다. 그러나 이건 어떤 툴도 마찬가지라는 생각도 든다. 게시판의 무한 리플 논쟁은 체계적으로 따라가기 힘들고, 블로그의 트랙백은 논쟁이 산만해지기 쉽다. 그나마 체계적인 지식 축적이 가능한 위키가 논쟁에 그나마 적합한 툴일지도 모른다. 이런 의미에서 "논쟁형 위키"를 한 번 고안해 보는 것도 재미있지 않을까?

ps. 포스팅을 하려고 봤더니 이미 다섯병님이 포스트를 써 놓으셨다.
진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크

참을 수 없는 로그인의 무거움


요즘 포털들의 때아닌 이메일 서비스 경쟁이 한창입니다. 몇 년 전 G메일의 등장으로 인해 촉발된 기가바이트(GB) 단위 메일 서비스 경쟁을 마지막으로, 그간 이메일 서비스 시장는 특별한 변화가 없이 평온한 나날을 보내고 있었습니다. 그러다 최근들어 난데없이 이메일 서비스 시장은 다시금 포털들의 치열한 각축장이 되고 있는 것이죠.

이메일 서비스는 지금처럼 웹이 활성화되기 이전부터 존재하던 전통적인 서비스입니다. 초기 포털들은 이메일 서비스와 함께 성장하기 시작했고, 온라인에 적용된 최초의 광고 플랫폼도 이메일 기반의 광고였죠. 최초의 배너광고가 출현하기도 전에 스팸 메일의 존재가 있었다는 것이 이메일의 오래된 역사를 보여주는 단적인 예라고 할 수 있겠습니다.

초 기 웹에서 이메일 광고는 효과적인 광고 플랫폼이었으며, 많은 이메일 계정(즉, 고정적인 사용자)을 보유하는 것 자체가 가치있던 시기가 있었습니다. 그러나 현재의 웹은 검색이나 블로그 등의 개인 미디어를 통한 불특정 다수의 사용자를 대상으로 하는 광고 플랫폼이 주류를 이루고 있기 때문에, 예전처럼 메일 서비스를 통해 충성스러운 사용자군을 형성할 필요성이 상대적으로 줄어들고 있는 것이 사실입니다. 하지만 재미있는 것은 이메일 서비스가 더이상 매력적인 플랫폼이 아님에도 불구하고 포털들의 지속적인 투자가 이루어지고 있다는 점입니다. 이것은 이메일 서비스가 가지는 또 하나의 특징인 "로그인 기반" 서비스라는 점 때문입니다.

포털이든 특정 사이트든 간에, 사용자가 한 번 로그인을 하고 나면 그 다음부터 사용자는 로그인 된 상태로 돌아다닐 수 있게 됩니다. 이는 웹서버와 사용자의 브라우저 사이에 세션Session이 생성되기 때문입니다. 웹이 기반하고 있는 HTTP 프로토콜은 기본적으로 요청(사용자)-응답(웹서버)의 연속으로 이루어지는데, 통상적인 HTTP 통신에서는 이러한 요청이나 응답의 결과들을 별도로 저장하지 않습니다. 하지만 로그인 정보 같이 특정한 정보를 사용자가 요청할 때마다 저장해서 사용해야 하는 경우가 있는데, 이 때를 위해 사용되는 것이 바로 쿠키Cookie와 세션입니다.

네트워커에서 한 번 쿠키에 대해 설명드 린 적이 있는데요, 쿠키가 사용자 측에 텍스트 파일 형태로 정보를 남겨 저장하는 반면, 세션은 웹서버에서 정보를 저장하고 관리합니다. 만약 사용자가 로그인을 해서 세션이 생성되었다고 하면, 웹서버에는 특정한 세션을 구분해 주는 세션 ID를 발급하고 파일 하나를 웹서버에 생성합니다. 그리고 사용자에게 이 세션 ID를 전달해 주면, 사용자는 이후 이 세션 ID를 통해 저장된 정보를 사용할 수 있게 되는 것이죠. 쿠키는 사용자 컴퓨터에 파일로 남기 때문에 그 파일에 접근할 수만 있다면 다른 사용자의 정보를 알아낼 수 있는 반면, 세션은 세션 ID만을 사용자에게 넘겨주기 때문에 비교적 안전하다고 할 수 있겠습니다...만, 세션 ID만 알아낼 수 있다면 역시 다른 사용자의 정보를 빼 올 수 있다는 점(세션 하이재킹)에서 세션 역시 아주 안전하다고는 할 순 없겠습니다.

세션이나 쿠키에는 보통 매우 중요한 사용자 정보들이 들어있습니다. 인증 정보(아이디 및 패스워드)는 물론이고, 사용자가 사이트에 가입하면서 기록한 정보(주소, 전화번호, 생년월일 등)나 사이트에서 임의로 저장한 정보들(최근 접속시간, 방문 이력 등)이 모두 세션이나 쿠키에 기록되게 되죠. 어떤 사이트에서 로그인을 하고 나면 보통은 초기화면으로 이동하게 되는데, 그 짧은 사이에 사용자에 대한 정보들을 세션에 쑤셔넣는 작업을 합니다. 이렇게 집어넣은 정보는 기본적인 인증 이외의 많은 부분에 사용되게 되죠.

최 근 포털들은 사용자 정보 축적에 많은 관심을 기울이고 있습니다. 아무리 복잡한 수식을 통해 알고리즘을 잘 세운다 하더라도 실제 사용자들의 행동과 괴리가 있을 수밖에 없기 때문에, 사용자들의 행동 이력을 축적하고 분석하는 것이 보다 중요하다는 의미겠죠. 빅브라더에 대한 구글의 야망이 새삼스레 부각되는 것도 이런 맥락과 닿아 있으리라 생각됩니다. 이메일 같이 전통적인 로그인 기반 서비스에 대한 관심을 버릴 수 없는 것도 바로 이런 이유 때문이기도 하구요. 아마 포털들의 입장에선 다음과 같은 웹서핑 프로세스를 가장 좋아할 겁니다.

브라우저를 켠다 -> 포털로 접속 -> 로그인 -> 이메일 확인 -> 웹서핑

웹 서핑을 할 때 로그인을 한 것과 하지 않은 것은 큰 차이를 보입니다. 물론 로그인 하지 않은 상태라 할지라도 쿠키를 통해 사용자 정보를 수집할 수는 있지만, 데이터의 양과 질적인 차원에서 세션 정보를 활용하는 것과는 큰 차이가 있죠. 사용자 입장에서는 무심코 하는 로그인 한 번이지만,  일단 한 번 하고 나면 그 이후의 사용자의 행동은 사이트에서 마음껏 수집할 수 있으니깐요. 개인적인 서핑 이력이 드러나는 것을 참을 수 없다면, 메일만 확인하고 바로 로그아웃하는 것도 하나의 방법이겠습니다. :)
진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크

잡스의 당혹스런 선언과 DRM

애플의 CEO인 스티븐 잡스는 2007년 2월 디지털 저작권 관리, 즉 DRM을 폐기하자는 내용의 서신을 발표했습니다. 잡스도 어떤 꿍꿍이가 있어 한 말이겠지만, 온라인 뮤직 스토어인 iTMS를 통해 많은 이익을 내고 있던 애플이기에, 잡스의 이 선언은 약간 의외라는 생각이 들기도 합니다.물론 비슷한 온라인 뮤직 비지니스를 하고 있던 MS나 야후의 입장에서는 잡스의 선언이 매우 황당했으리라고 짐작됩니다. 하물며 불법복제되는 mp3 탓에 CD가 안팔린다는 하소연을 몇 년째 되풀이 하고 있던 한국의 음반제작사들은 더욱 당황스러웠겠죠. :) 뒤이어 EMI가 No DRM 행렬에 동참하면서 잡스의 선언은 더욱 현실감을 얻고 있습니다.

이제까지 온라인에서 음악으로 장사를 하기 위해서는 DRM(Digital Rights Management)이 필수로 받아들여지는 분위기였습니다. DRM은 음악, 이미지, 문서 등의 디지털 컨텐츠에 대해 배타적인 접근을 가능하게 하는 기술, 또는 솔루션 패키지를 일컫는 말입니다. DRM이 걸린 디지털 컨텐츠는 특정 사용자가 특정한 조건 하에서만 사용할 수 있게 됩니다. 마치 암호를 걸어놓은 압축 파일이나 문서 파일처럼 말이죠. 하지만 DRM의 인증 방식은 알집을 통해 암호를 설정해 놓은 zip 파일보다 훨씬 정교한 메커니즘을 가지고 있습니다.

DRM 에서 가장 중요한 부분은 암호화 기술입니다. DRM 인증을 통하지 않은 사용자는 사용할 수 없도록 파일을 암호화시켜 변형해야 하고, 만약 사용자가 인증을 통과하면 이를 다시 복원시킬 수 있어야 하기 때문에,  DRM의 가장 핵심적인 기술이 여기에 있다고 해도 과언이 아닙니다. 여기에 암호화된 파일을 다시 원래의 파일로 복원시켜야 하기 때문에 반드시 키가 필요합니다. 만약 그 키가 패스워드처럼 단일한 키로 되어 있다면, 그 패스워드가 유출되었을 경우 거의 모든 사람이 DRM을 무시하고 컨텐츠를 사용할 수 있게 되어 버립니다. 그래서 보통 사용자마다 서로 다른 키를 통해 암호화하는 방법을 씁니다. 예전에 많이 사용하던 방식은 사용자의 컴퓨터마다 있는 고유번호를 쓰는 것인데요, 예를 들면 CPU의 일련번호나 랜카드의 맥어드레스 등을 적절히 변형시켜 사용하곤 했습니다. 하지만 컴퓨터의 일련번호는 다른 사람이 쉽게 알아낼 수 있는 번호이기 때문에 보안성이 떨어진다는 단점이 있습니다. 그래서 요즘엔 사용자마다 공인인증서 같이 별도의 키를 발급하고 이를 컴퓨터 어딘가에 내장시켜 놓고 쓰는 방식이 일반적입니다. 이렇게 개인키를 통해 암호화 했을 경우에는 제3자의 컴퓨터에서는 복제된 컨텐츠를 사용할 수 없다는 장점이 있습니다.

이러한 암호화 기술 외에도 DRM은 컨텐츠에 대한 사용 제한을 제어할 수 있습니다. 특정 컨텐츠는 얼마 동안의 기간만 볼 수 있다던지, 몇 번 이내로만 재생 가능하다던지 하는 제한을 걸 수 있게 되죠. 또한 결제 시스템과 연동하여 결제를 거친 후 재생 권한을 주는 것도 가능하게 합니다. 예를 들어 인터넷으로 드라마를 본다고 하면, 일단 결제를 해야 드라마를 볼 수 있게 되고, 3번 이상 재생할 수 없으며, 4번째로 드라마를 재생하려 할 때에는 다시 결제를 해야만 한다...는 식으로 사용 제한을 걸 수 있게 됩니다. 또한 만약 다운로드 방식으로 드라마를 구입한 사용자의 경우 다른 컴퓨터에서는 재생시킬 수 없도록 할 수도 있구요.

하지만 암호화시킨 컨텐츠를 다시 복호화 한다는 것은, 다른 누군가가 암호를 깰 수 있다는 말입니다. 실제로 널리 사용되는 DRM은 끊임없는 해킹 시도를 당해 왔고, 실제로 해킹에 성공한 사례들 도 꽤 있습니다. 또한 DRM은 전세계적인 표준이 없고 웬만한 큰 기업들은 자기만의 DRM을 가지고 있어서 이들 사이의 호환이 되지 않습니다. 애플 것이 다르고 M$ 것이 다르고 소니 것이 다르기 때문에, 사용자는 여러모로 불편함을 감수할 수밖에 없는 것이죠. (물론 M$의 영향력이 막대한 한국은 미디어플레이어를 기반으로 한 WMRM을 많이 사용하지만요.)

DRM은 이렇게 컨텐츠의 사용을 엄격하게 제한하기 때문에 많은 사용자들이 불편을 느낄 수밖게 없습니다. 또한 컨텐츠를 완전하게 소유할 수 없고, 비록 유료로 구입한 컨텐츠라 할 지라도 사용성에 많은 한계가 있으며, 보통은 특정 하드웨어와 소프트웨어에 종속되는 형태로 DRM이 구성되기 때문에, 잡스의 선언은 많은 사용자들의 환영을 받았죠. 스톨만 아저씨가 (반드시 GPLv3 때문만은 아니더라도) DRM을 싫어하는 이유가 어떻게 보면 사용자들의 반감과 맞닿아 있는 것 같군요. 하지한 이제까지 잡스가 한 발언 중 가장 정의로워 보이는 이번 선언을 두고도 의혹이 끊이지 않는 것을 보면, 역시 잡스의 장사꾼 이미지는 참 벗기 힘든 게 아닌가 싶습니다. :)
진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크

누구를 위해 컨텐트는 생산되는가 - UCC

UCC라는 단어를 아마 한 번쯤은 들어보셨을 것입니다. 분명히 1년 전만 해도 이 단어는 "업계 용어"였습니다. 작년에 팀장이 뜬금없이 "혹시 UCC라는 말 아나?"라고 저한테 물었을 정도로, 아는 사람만 아는 그런 단어였죠. 일본에서 UCC 커피를 발견하고 속으로 킥킥댔던 기억도 어렴풋이 나는군요-_- 블로그나 게시판, 그리고 일부 기사 등에서 반드시 부연 설명과 함께 쓰여지던 이 말이, 어느날 갑자기 신문과 TV에 화려하게 등장하기 시작했습니다. 요즘엔 아예 부연 설명도 달아주지 않는 곳도 있을 정도로 UCC라는 단어는 상당히 일반화되었죠.

참으로 허무한 것은-아마 다들 아시겠지만-UCC가 User-Created Contents의 약자라는 겁니다. 영미권에서는 UGC(User-Generated Content)로 많이 불리기도 합니다만, 어쨌든 "사용자에 의해 생산한 컨텐츠"라는 것으로, 최근에 생긴 개념이 아니라 피씨통신의 게시판 시절부터 존재하고 있었던 것이죠. 어떻게 보면 UCC라는 개념은 전번에 소개한 적이 있는 Web 2.0과 비슷하게, 예전부터 존재하고 있었던 개념을 포장만 바꿔 그럴듯하게 만들어놓은 것일수도 있습니다. 그래서 UCC라는 단어 자체도 마케팅 용어 정도로 이해하는 사람들도 꽤 있죠.

여기서 주목할 것은 UCC라는 단어 자체가 아니라 이 단어가 널리 뜨게 된 배경입니다. UCC라는 단어가 포함된 뉴스를 검색해 보면 아시겠지만, 상당수가 동영상 UCC를 다루고 있음을 알 수 있습니다. 요즘 검색의 최대 이슈가 동영상 검색이라는 점과 최근 구글에 인수된 유튜브(YouTube)를 생각해 볼 때, 예전에 비해 동영상이라는 포맷의 비중이 매우 커졌음을 알 수 있죠.

동영상의 급부상은 충분히 수긍갈만한 현상입니다. 어떤 내용을 전달하려 할 때 동영상만큼 직관적이고 분명한 수단은 많지 않을 것입니다. 하지만 동영상이 대중화되기 위해서는 여러가지 환경적인 제약이 존재했는데, 첫째는 동영상을 부담없이 끊기지 않게 볼 수 있는 충분한 네트워크 환경의 조성되어야 했었고, 둘째는 동영상을 제작하기 위해서는 캠코더 같은 장비와 프리미어 등의 동영상 편집툴을 다룰 수 있는 상당한 고급기술이 필요한 것이라 생산자가 극히 제한적일 수밖에 없었던 것입니다. 전자의 제약은 비약적으로 발전하는 네트워크 기술에 의해 극복되고 있었지만, 후자의 제약만큼은 만만치 않은 것이었죠.

동영상 UCC가 각광받는다는 것은 이런 제약들을 넘어설 수 있는 기반이 마련되고 있다는 말로 이해 가능합니다. 멀티미디어 작업에 능숙한 유저들이 늘어나고 있을 뿐만 아니라, 쉽고 간단한 동영상 제작툴도 많이 나오고 있기 때문에 이런 변화들이 가능한 것이겠죠. 이런 변화는 비단 동영상 뿐만이 아니라 음악이나 이미지 등 전반적인 UCC에 걸쳐 일어나고 있는데요, UCC가 주목받게 된 데는 이렇게 두터워진 생산자 층이 큰 역할을 담당하지 않았나 생각합니다. VI 에디터 만큼이나 어려웠던 하이텔의 문서작성기(당시 글 하나 올리는데는 상당한 난관을 돌파해야 했습니다)를 기억하시는 분이라면, 지금의 문서/이미지/동영상 편집기들은 분명히 보다 많은 사람들을 생산의 장으로 끌어들일 수 있을테니깐요.

이러한 UCC 시대에는 생산자들의 자발적인 참여 구조가 매우 중요하게 됩니다. 사람들에게 인정받기 위해서든, 즐거움을 선사하기 위해서든, 또는 한 몫 잡아보기 위해서든, 동기가 어떻든 간에 생산하고 참여하려는 사람들이 존재해야 하고, 생산된 UCC에 쉽게 접근할 수 있는 통로가 확보되어야 합니다. 하지만 아직은 펌글이 넘쳐나고 있는 한국의 블로그들과 자신의 마당 안에서만 자유로이 놀 것을 허용하는 닫힌 포털의 구조에서 이러한 참여 구조가 제대로 정착될 지는 의문입니다. 임정현 씨가 YouTube에 캐논을 올려놓지 않고 국내 포털의 한 블로그에 올렸다면, 이 컨텐츠는 해당 포털 안에서는 유명해질 수 있겠지만 외부로 알려지는데는 꽤 시간이 걸릴 것이고, 알려지더라도 펌에 펌을 거쳐 원작자가 누군지도 불명확한 채 네트워크에서 떠돌 가능성이 크겠죠. 따지고 보면 포털들은 UCC 시대의 화려한 만개를 꿈꾸고 있지만 한편으로는 그것을 가로막고 있는, 역설적인 상황이라고도 할 수 있겠습니다.

UCC는 직관적으로 이해하기 어렵지 않은 개념임에도 불구하고, 용어 자체를 엄밀하게 정의하기 위해서는 아직 해명되지 않은 부분이 꽤 있습니다. 그럼에도 이제까지 그랬듯이 업체들은 새로운 수익모델로서 UCC를 밀려 할 것이고, 이는 사용자에게 컨텐츠 생산 비용을 전가함과 동시에 UCC 풀의 닫힌 구조를 강화하는 방향으로 나아가지 않을까 우려됩니다. 또한 강화되어가는 저작권의 개념과 UCC 생산자의 자기 통제가 필요하다는 부분에 있어서 역시 UCC 열풍을 가로막는 요인이 될 수 있을 것입니다.

UCC에 대한 한국판 위키피디아의 약간은 자조적인 설명UGC에 대한 영문판 위키피디아의 희망섞인 설명이 이루는 대조가 상당히 묘한 느낌을 주는 것 같군요.

진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크

TCP/IP의 이해 #2 - 게이트웨이와 DNS

누군가의 말대로, 네트는 광대합니다. 그래서 그런지 네트워크를 흔히 우주에 많이 비유하곤 하죠. 물론 전 세계에 흩어져있는 서버와 클라이언트 컴퓨터(호스트)들이 밤 하늘의 별들만큼 많기야 하겠냐만은, 네트워크가 이루는 세상은 그 크기를 미루어 짐작할 수 없을만큼 광대한 공간이라는 사실만큼은 틀림없는 것 같습니다.

하지만 우주에도 은하계가 있고 행성계가 있듯이, 전체 네트워크 상에 호스트들이 무질서하게 흩어져 있는 것처럼 보여도 실은 나름의 체계가 있습니다. 같은 사무실에서 사용하는 PC들이나 특정한 망에 가입되어 있는 사용자들의 컴퓨터는 네트워크 우주 안에서 하나의 소우주를 이루고 있죠. 이들은 단일한 인트라넷으로 묶이기도 하고, 일정한 IP 대역 안에서 IP를 부여받습니다. 결국 광대한 전체 네트워크는 이러한 소우주 네트워크들이 모여서 만들어내는 것이지요.

게이트웨이는 특정한 네트워크와 다른 네트워크의 연결점이라 할 수 있습니다. 게이트웨이gateway의 사전적인 정의와 같이 일종의 관문 역할을 수행하는 셈이죠. 다른 말로 하면, 특정 네트워크의 게이트웨이는 그 네트워크의 시작점이라고도 할 수 있습니다. 보통 게이트웨이 주소를 잡을 때 끝자리가 1번으로 잡는 경우가 많은데요(xxx.xxx.xx.1), 게이트웨이가 네트워크의 시작점이라는 상징적인 의미라고도 볼 수 있죠.

예를 들면, 제가 관리하는 www.abc.com이라는 서버의 IP 주소가 211.255.23.39라고 하고, 그 서버가 속해있는 네트워크의 게이트웨이 주소가 211.255.23.1이라고 합시다. 만약 www.abc.com으로 페이지 접속 요청을 보냈을 때, 이 요청은 무조건 게이트웨이를 먼저 통과하여 제 서버로 전달됩니다. 웹페이지를 응답할 때에도 마찬가지로 게이트웨이를 통과하여 요청한 사용자의 PC로 전달하게 되죠.

이렇게 게이트웨이가 하는 역할이 관문이다보니, 통로로서의 역할 뿐만 아니라 검문소의 역할을 하기도 합니다. 그래서 보안이 필요한 네트워크에서의 게이트웨이는 방화벽의 역할을 수행하기도 하죠. 네트워크를 통해 들어오고 나가는 데이터들(패킷packet이라고 합니다)을 전부 관리할 수 있기 때문에, 악성코드나 특정 데이터에 대해 쉽게 걸러낼 수가 있습니다.

약간은 생소한 게이트웨이에 비해 DNS Domain Name System, 즉 도메인 서버에 대해서는 많이 알고 계실 듯 합니다. 도메인은 네트워크 상의 특정 위치를 결정지어주는 IP 주소 대신 쓸 수 있는 이름입니다. 인터넷 서핑을 할 때 브라우저를 켜고 주소를 치게 되는데, 이 주소가 바로 도메인입니다. 아까의 예에서, 사실 www.abc.com을 보고 싶을 때, 211.255.23.39라고 입력해도 같은 내용이 나옵니다. www.abc.com과 211.255.23.39은 둘 다 제가 관리하는 서버의 네트워크 상에서 위치를 나타내는 주소이기 때문이죠. 하지만 숫자 네 개로 이루어진 IP에 비해 도메인은 기억하기가 훨씬 용이하기 때문에, IP 주소를 일일히 집어넣는 수고 대신에 도메인으로 간단하게 요청을 보내는 것이죠.

DNS가 하는 역할은 www.abc.com이 211.255.23.39라는 점을 알려주는 일입니다. 즉, 특정 도메인을 IP 주소에 매핑mapping하는 것이죠. TCP/IP 네트워크에서는 IP가 특정 네트워크 포인트를 알려주는 주소라고 했습니다. 만약 도메인을 입력해서 특정 포인트를 찾으려고 한다면, 먼저 DNS가 도메인을 IP 주소로 번역하고, 그 IP 주소로 요청을 날리게 되는 것이죠.

재미있는 것은, 도메인과 IP 주소의 데이터베이스인 DNS를 정해진 누군가가 관리하지는 않는다는 점입니다. 만약 전세계에 DNS 서버가 한 대만 존재하고 있다면, 만약 그 서버가 다운되었을 때 도메인 이름을 모른다면 어떠한 네트워크 포인트에도 접속할 수 없을 것입니다. 그래서 DNS는 세계 도처에 존재하며, 하나의 DNS 서버가 못 쓰게 되거나 효율이 좋지 않다면 다른 DNS를 참조해서 IP 주소를 얻어오게 됩니다.

그렇다면 새로운 도메인이 출현했을 경우 어떤 일이 벌어질까요? 일단 www.abcd.com이라는 새 도메인을 발급받아 근처에 있는 DNS 서버에 등록했다고 가정합시다. 그 시점에서는 운좋게도 새 도메인을 등록한 DNS 서버에서 IP 주소를 받아온 사람은 www.abcd.com을 잘 찾아갈테지만, 다른 DNS 서버를 사용하고 있던 대부분의 사람들은 www.abcd.com을 주소창에 쳐도 그런 페이지는 없다는 에러밖에 볼 수 없을 것입니다. 그러나 DNS 서버들은 서로의 변경 사항을 주기적으로 교환해서 새로운 데이터베이스를 유지하도록 설계되어 있습니다. 새 도메인이 등록된 DNS 서버는 www.abcd.com에 대한 정보를 다른 DNS 서버에 전파하게 되고, 대략 하루 정도가 지나면 모든 DNS 서버가 www.abcd.com에 대한 정보를 가질 수 있게 되는 것이죠. 그래서 새 도메인을 등록하면 전체적으로 적용되는데 일정한 시간이 필요하도록 되어 있습니다. 이것은 DNS의 분산 환경 때문에 생기는 일이죠.

뭔가 단순하게 설명해놨는데, 실제로는 이보다 더 복잡한 일들이 네트워크 세계에서 일어납니다. 전세계로 통하는 복잡한 네트워크 환경에서 빠르고 정확하게 요청을 주고받게 하기 위해, 인터넷의 발전과 더불어 네트워크 기술도 계속 발전한 셈이죠. 어디서든 네트워크와 연결할 수 있는 유비쿼터스 시대니 뭐니 해도 TCP/IP의 기본적인 구조는 인터넷이 존재하는 한 남아있을 것 같습니다. 왠지 공각기동대의 전뇌 통신도 TCP/IP 기반으로 이루어지는 것이 아닐지요;;;

진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크

TCP/IP의 이해 - IP 주소

얼마 전에 시간을 가장 가치없게 사용하는 방법 중 상위 3위 안에 랭크될 것이 분명한 동원예비군 훈련을 갔다왔더랩니다. 제가 갔던 부대는 의정부에 있는 통신대대인데, 여기서 하는 일은 말 그대로 부대 사이의 통신을 연결하고 관리하는 일입니다. 통신대는 크게 전송조, 교환조, 유무선조로 나뉘어집니다. 저는 이 중 교환조에 속하는데, 교환조는 타 부대의 교환조와의 네트워크를 구성하여 이를 제어하고, 내부의 전화를 연결해 번호를 부여하는 등의 역할을 수행합니다. 옛날 전화에 있었다는 교환수와 비슷한 역할이라 할 수 있긴 하지만, 전화번호를 부여하고 음성 통신 뿐만 아니라 데이터 통신까지 중계한다는 점에서 보다 하는 일의 범위가 넓다고 할 수 있겠죠. 여튼 하려는 얘기는 이게 아니고-_-;;;

 

컴퓨터 사이의 네트워크도 전화와 비슷한 중계 구조를 가지고 있습니다. 집마다 있는 전화가 전화번호로서 고유하게 식별할 수 있듯이, 네트워크에 연결된 컴퓨터(정확히는 모뎀 또는 랜카드 등의 네트워크 장비)는 고유한 식별 번호를 가집니다. 예를 들면 공유 폴더로 접근할 때 사용하는 윈도의 인트라넷에서는 네트워크 아이디라는 것을 지정하도록 되어 있습니다.("시스템 등록 정보"의 "네트워크 식별" 탭에서 지정 가능합니다.) 그리고 일반적인 인터넷 연결에 사용하는 TCP/IP 네트워크에서는 바로 IP 주소라는 것을 발급하도록 되어 있죠.

 

TCP/IP는 인터넷의 가장 기본적인 프로토콜입니다. 프로토콜은 (전에도 한 번 설명했지만) 통신을 위해 정의된 규약입니다. TCP(Transmission Control Protocol)라는 프로토콜과 IP(Internet Protocol)라는 프로토콜이 결합된 것이 TCP/IP로서, 웹(WWW)에 사용되는 HTTP, 원격 컴퓨터 제어를 위한 텔넷(Telnet), 파일 전송을 위한 FTP, 메일에 사용되는 SMTP등이 TCP/IP를 사용하는 프로토콜들입니다. 물론 인터넷 통신을 하기 위해서는 TCP/IP 프로그램이 반드시 필요합니다. 당연히 윈도나 리눅스 등의 거의 모든 OS에는 TCP/IP를 사용하기 위한 프로그램이 기본적으로 깔려 있죠. 보통 IP 주소를 잡기 위해 들어가는 설정 프로그램도 이런 제어 프로그램의 일부입니다.

 

IP 주소는 현재 IPv4라는 방식이 사용되고 있습니다. "211.255.23.35" 같이 0~255 사이의 수를 4개 붙여서 사용하는 것이 IPv4의 방식입니다. IP 주소는 앞에서 언급했듯이 전화번호같이 네트워크 상에서 특정 컴퓨터(호스트host)를 인식 가능하게 하는 고유한 번호입니다. 따라서 전세계의 모든 컴퓨터에 IP 주소를 붙여주어야 한다고 하면, 이론상 각 자리마다 256개의 숫자가 들어갈 수 있으므로 256x256x256x256=4,294,967,296, 즉 대략 43억 대의 컴퓨터가 붙을 수 있게 되는 셈이죠.

 

하지만 복잡한 IP 주소 부여 법칙에 의해 실제로는 이보다 적은 수의 IP 주소만이 사용할 수 있으며, 특히 각 국가마다 할당된 IP 주소의 영역이 제한되어 있기 때문에 IP 주소는 지금도 매우 부족한 상황에 놓여 있죠. 그래서 방화벽으로 구성된 폐쇄적인 네트워크에서는 보안상의 이유와 더불어 사용 가능한 IP 주소를 늘이기 위해 내부에서만 사용할 수 있는 IP를 따로 정의해 쓰기도 하고, 하나의 IP를 여러대의 컴퓨터가 공유하기도 합니다. 가장 흔한 예가 인터넷 공유기를 사용해 2대 이상의 컴퓨터를 붙여 쓰는 경우인데요, 이 경우에는 공유기가 라우터의 역할을 수행하여 별도의 IP를 각 컴퓨터에 붙여줍니다.

 

라우터는 독립된 네트워크의 시작점이 되는 장비로서 보통 게이트웨이의 역할을 수행합니다. IP주소를 직접 잡아 보신 분들은 아시겠지만 IP주소를 설정하기 위해 IP주소는 물론이고 게이트웨이 주소와 DNS 주소를 넣어줘야 하는데, 그 게이트웨이 주소가 일반적으로 이 라우터의 주소입니다. 게이트웨이와 DNS에 대한 설명은 조금 길어지므로 다음에 다루도록 하겠습니다.

 

만약 자신의 컴퓨터가 네트워크에 등록되어 있는데 IP 주소를 알아야 하는 경우가 있습니다. 물론 컴퓨터의 설정 정보를 뒤져보면 어딘가에 IP 주소를 정의해 놓은 곳이 있겠죠. 그러나 그 곳을 찾기 귀찮거나 IP를 자동 설정으로 해 놓으신 분들은 TCP/IP 프로그램을 이용하여 쉽게 IP 주소를 알아낼 수 있습니다. 윈도 2000이나 윈도 XP 이상을 사용하시는 분들은 윈도의 커맨드 창에서 "ipconfig"를 입력하시면 관련 정보가 쉽게 나타납니다.(커맨드 창을 띄우시려면 윈도의 시작 ->실행에서 "cmd"를 입력하시면 되죠.) 리눅스 등 유닉스 계열의 OS에서는 일반적으로 /sbin/ifconfig를 실행하시면 관련 정보가 나옵니다.

 

 

위에 보면 제 컴퓨터의 IP 주소는 10.0.1.3으로 나오는데요, 일반적인 IP 주소는 이런 식으로 발급되지 않습니다. 10.으로 시작하는 IP는 보통 내부에서만 사용 가능한 IP 주소인데요, 저희 집에서 공유기를 사용해 여러 컴퓨터를 연결해 사용하기 때문에 앞에서 얘기한 대로 제 공유기가 임의로 발급해 준 가짜 주소를 얻은 셈이죠. 제 컴퓨터의 진짜 IP 주소는 공유기가 가지고 있으며, 제 공유기에 연결된 컴퓨터는 외부로 접속할 경우 공유기가 갖고 있는 그 IP 주소를 모두 사용하게 됩니다.

 

IP 주소도 하나의 자원이다 보니 사용하는 사람이 많아질수록 점차 부족 현상이 심각해질 것임이 분명합니다. 만약 지구 상의 60억 인구가 한 대씩 네트워크에 연결된 컴퓨터만 갖고 있어도 일찌감치 IP 주소는 동이 날 터이고, 특정한 주인이 없는 컴퓨터들(예컨데 서버들)도 수없이 많이 있을테니까요. 그래서 IP 주소의 범위를 늘이기 위해 IPv6라는 방식을 도입하려 하고 있습니다. IPv6는 이론적으로 기존의 IPv4보다 65536배 많은 주소를 사용할 수 있기 때문에, 아마도 IP 주소 부족 현상은 해소 가능하다고 할 수 있겠죠. 하지만 집을 지어도지어도 내 집을 가지기가 어려운 것처럼, 왠지 IP 주소 부족 현상이 쉽게 해결될지 의심이 되는 것은...나쁜 성격 탓일까요? ;;;

진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크

버퍼링을 미워하지 마세요 : 스트리밍 기술

얼마전 하나로텔레콤이 TV포털 서비스가 출시하면서 한바탕 논란이 일었습니다. 이제까지 인터넷 망 서비스를 하던 하나로텔레콤이 가지고 있던 인프라를 이용하여 VOD 서비스를 시작하려 하자, 기존의 방송 사업자인 케이블TV방송협회에서 반발하고 나선 것이죠. 이는 기본적으로 굴러온 돌과 박힌 돌의 대결 구도이기는 하지만, 근본적으로는 시대의 변화에 따른 방송사업자와 통신사업자의 대리전이기도 합니다.

 

전파나 케이블로 컨텐츠를 전달하던 방송과 유무선망으로 정보를 주고받던 통신은 지금와서 거의 구분이 무의미해졌습니다. 케이블TV 망을 통해 인터넷 서비스를 이용할 수도 있고 인터넷으로 TV를 생방송으로 볼 수 있습니다. 통신과 방송이 융합(컨버전스)을 이루어 시너지를 낼 수 있는 기반은 이미 충분히 마련되었다고 볼 수 있죠. 이런 융합을 가장 극명하게 보여주는 것이 바로 IPTV입니다. 전파나 케이블TV망이 아니라 인터넷망과 디지털TV를 이용하여 방송을 볼 수 있는 서비스가 벌써 실시되려 하고 있습니다. IPTV는 일방적으로 정보를 전달해주기만 했던 기존 방송과 달리 양방향 통신이 가능하고, 네트워크와 연결되어 여러 일을 동시에 할 수 있는 새로운 미디어입니다. 현재 이미 기술적인 기반은 충분한 상태이고 법제도를 정비하는 단계로 가고 있는 상황이죠.

 

웹에서도 동영상 기술이 중요하게 된 지 오래입니다. 유튜브(YouTube)가 새로운 트렌드도 부상했고, 검색 포털들은 동영상 검색에 승부를 걸고 있으며, 동영상 플레이어에는 웹TV를 볼 수 있는 기능이 추가되고 있습니다. 그리고 (지금 와서 약간 뒷북치는 감이 없진 않지만) 웹에서 동영상 재생에 있어 빠질 수 없는 기술이 바로 스트리밍입니다.

 

2400bps 모뎀을 사용하던 초창기 웹에는 이미지를 올리는 것만해도 큰 고역이었습니다. 페이지에 이미지를 올리는 것은 물론이고 페이지를 읽을 때에도 이미지는 큰 걸림돌이었죠. 그래서 초기 웹페이지는 텍스트 중심의 단조로운 구성을 취하게 됩니다. (미국이나 일부 유럽의 페이지들은 지금도 이미지 사용을 최소화하는 곳이 많죠) 물론 지금은 전용선에 의해 대규모의 패킷을 주고받을 수 있기 때문에 이미지 뿐만 아니라 플래시 까지 페이지에 덕지덕지 붙여도 뭐라고 할 사람이 많지는 않죠.(당연히 이런 페이지 구성은 정보 접근성에 비추어 볼 때 매우 좋지 않습니다)

 

하지만 이렇게 살림살이가 많이 나아졌어도 동영상은 부담스러운 존재입니다. 기껏해야 몇백KB 밖에 안되는 이미지에 비해, 동영상은 툭하면 몇백MB를 넘기기 일쑤입니다. 그래서 동영상은 일반적인 방식으로 열 수가 없는데, 보통 웹페이지를 브라우저로 열게 되면 페이지에 속해 있는 모든 파일들을 다운 받은 후에야 페이지를 제대로 볼 수 있기 때문에, 다운받는데 얼마나 많은 시간이 걸릴지 예측할 수 없는 동영상을 다 받기까지 기다릴 수는 없는 것이죠. 스트리밍 기술은 기본적으로 이러한 제약에 의해 출현하게 되었습니다.

 

웹에서 동영상을 열게 되면 동영상 플레이어는 다음 두 가지 중에 하나를 하게 됩니다. "다운로드" 또는 "버퍼링"이죠. 만약 동영상이 스트리밍 방식으로 올라가 있지 않다면 "다운로드"하게 됩니다. 예전에는 당연히 다운로드가 다 끝나야지만 동영상을 볼 수 있었지만, 요즘엔 기술이 좋아져서 다운로드 중에도 받은 부분까지 동영상을 볼 수가 있게 되었죠. 즉, 다운로드 하면서 동영상을 틀어주는 것인데, 만약 동영상의 진행상황을 알려주는 프로그레시브바가 끝까지 차지 않았는데 동영상이 플레이되고, 영상이 나오는 중에 프로그레시브바가 끝까지 계속 올라가고 있다면, 이건 다운로드하면서 동영상을 재생해 주는 것으로 보면 됩니다. 물론 다운로드를 받는 것이기 때문에 플레이가 끝났을 때 사용자 컴퓨터 어딘가에 그 동영상 파일이 남아있게 됩니다. 만약 사용자가 같은 동영상을 다시 볼 때 이 파일이 캐시로 남아있다면 다운로드 없이 빠른 속도로 동영상을 감상할 수 있습니다.

 

만약 동영상을 열었을 때 "버퍼링"을 한다면, 이 동영상은 스트리밍 방식으로 제공되는 것으로 보면 됩니다. 스트리밍은 실시간으로 동영상을 조금씩 흘려보내 주는 것으로서 플레이어에서는 그때그때마다 들어오는 데이터를 그대로 보여주는 셈입니다. 마치 TV에서 어디선가 날아오는 전파를 받아 바로 보여주듯이 말이죠. 하지만 인터넷 망의 상태에 따라 언제나 일정한 속도로 동영상 데이터가 들어오는 것이 아니기 때문에, 동영상이 끊기거나 지연되는 사태가 종종 발생합니다. 그래서 동영상 플레이어는 그런 지연을 방지하기 위해 얼마간의 데이터를 미리 받아놓고 상태가 좋지 않으면 미리 받아놓은 영상을 보여주어 끊기는 현상을 최대한 방지하려 합니다. 바로 이것을 "버퍼링"이라고 부르는 것이죠. (보통 망이 불안정해서 동영상이 자주 끊길 때 이 버퍼링이 많이 나오는데요, 버퍼링을 하기 때문에 나쁜 환경에서도 그나마 재생이 되는 것입니다) 스트리밍 방식으로 재생되는 동영상은 받은 데이터를 보여주고 그것으로 땡입니다. 따라서 다운로드 방식처럼 파일이 어딘가에 남거나 하지 않기 때문에, 만약 동영상을 다시 한 번 보고 싶다면 똑같이 버퍼링부터 하고 똑같은 데이터를 다시 받아 봐야 합니다. 별도의 복사본이 남지 않기 때문에 대부분의 유료 컨텐츠 등은 스트리밍 방식을 취하기도 합니다.

 

IPTV가 정식으로 서비스된다면 VOD 서비스와는 달리 TV처럼 실시간 방송을 보여주기 때문에 이러한 스트리밍 기술을 사용하게 될 것입니다. 많은 데이터를 빠른 시간에 보내고 받는 기술이 보다 중요해지겠죠. 기술의 진보는 누구나 보다 쉽게 방송을 할 수 있도록 도와줄 것 같습니다. 그러나 이와는 별개로 갖가지 법적, 제도적 장치들이 방송을 쉽게 하지 못하도록 막겠죠. 마치 FM 시대에 그랬던 것처럼, IPTV 시대에도 해적 방송이 다시 출현하지 않을지 모르겠습니다;;;

진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크

티스토리 분양받다

베타 테스트 시작한 지는 꽤 됐지만...

티스토리 분양 받았다.

 

(당연한 말이지만) 태터랑 거의 똑같은 기능과 인터페이스;;;

 

일단 열심히 사용하기로 혈서를 쓴 관계로-_-

티스토리에도 동시에 포스팅 해야 할 듯;;;

 

http://renegade.tistory.com

진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크

서비스로 알아보는 Web 2.0

* 회사에서 청탁받아 쓴 글입니다;;;

 

Web 2.0이라는 단어가 전파된 것은 그야말로 순식간에 이루어진 일이었습니다. 마치 어느날 갑자기  모두가 웹2.0을 말하고 있었다는 느낌이었죠. 소수 집단에서 조심스럽게 나오기 시작했던 웹2.0은 개발자, 웹기획자 뿐만 아니라 관리자, 마케터 등 웹을 하는 사람이라면 반드시 알아야 할 것 같은 압박을 주는 단어로 성장했습니다.

 

웹2.0이라는 용어는 O'Reilly사와 MediaLive International사의 컨퍼런스를 위한 브레인스토밍 도중 최초로 도출되었다고 합니다. 이후 유명한 웹2.0의 meme map이 나왔으며 2004년 10월에 웹2.0 컨퍼런스가 개최되어 몇 가지 원칙 등이 정리되게 됩니다.

 

웹2.0의 meme map

 

이 meme map에 있는 말들이 곧 웹2.0에 대한 정의는 아닙니다. 사실 웹2.0이라는 단어는 그 안에 워낙 많은 개념들이 포함되어 있기 때문에 한 마디로 정의하기가 상당히 애매합니다. 단지 2.0이라는 숫자가 주는 새로움에 대한 인상이 워낙 강렬하기 때문에, 어렴풋이나마 이미지를 그려서 이야기 하는 경우가 많죠. 그래서 여기에선 그 의미를 정리하는 것보다는 몇 가지 대표적인 서비스들을 통해 웹2.0의 특징을 설명하도록 하겠습니다.

 

Computing with Google

 

국내에서 Google은 일반 사용자들에게 검색 시장을 정복한 업체 정도로 알려져 있지만, 사실 Google의 진정한 야망은 세계 정복에 있습니다. 지금까지 Google은 강력한 검색 서비스를 필두로 하여 뉴스 서비스맵 서비스, 데이터베이스 서비스, 데스크탑 툴바 등 컴퓨터로 할 수 있는 거의 모든 작업들에 개입하려 하고 있습니다. Google은 과거의 Netscape나 현재의 MS처럼 서버나 소프트웨어를 판매하지는 않지만, 이러한 서비스를 통해 데이터베이스를 수집하고 정보의 흐름을 매개함으로써 독립된 플랫폼을 구축하고 있죠(Services, not packaged software). Tim O'Reilly는 웹2.0의 전략적 포지셔닝으로서 "플랫폼으로서의 웹The Web as Platform"을 제시하고 있는데, Google은 이런 특징을 가장 잘 보여주는 서비스라고 할 수 있습니다.

 

 - Google vs MS

 

Learning with Wikipedia

 

웹2.0을 설명하는데 있어 집단 지성Collective Intelligence은 빼놓을 수 없는 항목입니다. 사실 집단 지성은 인터넷이 시작되면서부터 지금까지 이어져 온 중요한 주제 중 하나입니다. 많은 사람들이 서로의 경험을 커뮤니케이션하며 가치를 만들어낸다는 이 개념은 1994년 프랑스의 사회학자/철학자인 피에르 레비Pierre Revy동명의 책에 등장했습니다. 인터넷의 발전에 따라 오픈소스 프로젝트, 블로그, 그리고 가장 급진적인 방식인 위키위키Wikiwiki까지 이어져 온 이 개념은 Wikipedia에서 가장 극명하게 드러나고 있죠.

 

Wikipedia는 위키의 편집 방식에 따라 누구나 쓸 수 있고 자신이 쓴 글은 물론이고 다른 이가 쓴 글까지도 수정, 삭제할 수 있습니다. 이는 위키를 사용하는 사람들에 대한 집단적인 이성을 극단적으로 신뢰하기 때문에 가능한 것이죠(Trust your users). 누군가에 의해 통제되는 것은 아니지만 사용자들은 스스로 데이터를 올리고 수정하면서 하나의 백과사전을 만들어가고 있습니다. 가끔 악의적인 사용자에 의해, 혹은 사용자의 실수에 의해 어떤 항목이 통째로 사라지는 경우가 발생하기도 하지만, 곧 다른 사용자에 의해 히스토리에서 복구되곤 하죠. 역시 많은 사용자들에 의해 데이터베이스가 쌓이고는 있지만 중복된 지식과 닫힌 구조의 한계를 지닌 지식인 서비스와 비교하여, 보다 신뢰할 수 있고 훨씬 많은 데이터를 제공할 수 있는 것도 Wikipedia이기 때문에 가능합니다.

 

 - 논쟁의 여지가 있는 주제에 대해서는 편집에 제한을 가하기도 하고 토론도 전개하곤 합니다.

 

Tagging with delicious

 

delicious는 태그tag의 사용을 가장 잘 보여주는 서비스입니다. 태그는 말 그대로 뭔가에 붙이는 꼬리표입니다. 이 단순한 행위가 카테고리를 기본으로 하는 기존의 분류법taxonomy을 완전히 뒤집어 놓은 새로운 분류법folksonomy이 되고 있습니다.

 

북마크 서비스를 하는 delicious는 각 링크에 태그를 붙이도록 했습니다. 예를 들면 진보불로그에 진보넷, 블로그... 이런 식으로 말이죠. 저장된 북마크는 이러한 태그에 의해 분류해서 관리합니다. 그리고 이렇게 각 사용자들이 모은 북마크를 공유(소셜 북마크Social Bookmark)합니다. 어떤 사이트가 유용한 곳인지 다른 사람들이 저장해 놓은 북마크를 통해 쉽게 찾을 수 있습니다. 그리고 만약 "블로그"라는 태그를 진보불로그에 붙여 저장한 사람이 많아진다면 진보불로그의 순위도 점점 높아지게 됩니다. 태그를 붙이는 행위인 태깅tagging은 곧 가치있는 사이트를 찾는 일에 사람들을 참여하게 하는 방법이기도 한 것이죠(Architecture of Participation). 지금은 동영상, 사진, 포스트 등 웬만한 컨텐트를 생성할 때 태그를 다는 것은 하나의 추세가 되고 있습니다.

 

Mashing with Google Maps

 

앞에서 Google 서비스들에 대해 얘기했지만, 그 중 가장 웹2.0적인 서비스는 단연 Google Maps입니다. Ajax라는 비동기 처리 기술을 사용한 Rich Interface도 돋보이지만, 무엇보다도 다른 웹 어플리케이션과 쉽게 매쉬업mash-up  가능하다는 점이 가장 웹2.0답다고 할 수 있습니다(Remixable data source and data transformation). Tim O'Reilly의 글에서 소개되기도 한 하우징맵스닷컴의 경우를 보면 Google Maps의 데이터가 다른 데이터들과 어떻게 섞일 수 있는지 알 수 있습니다.

 

Google Maps의 데이터는 그 자체로도 물론 가치가 있겠지만, 사방으로 흘러나가 다른 데이터와 섞여 또 다른 가치를 만들어냅니다. 그 작업을 하는 것은 Google Maps가 아니라 그 사용자들이며, Google Maps는 데이터베이스를 소유하는 것이 아니라 매개하는 역할을 하는 것이죠. 이쯤되면 Google의 세계 정복 야망이 왠지 현실성 있어 보이는 것 같습니다.

 

 - UFO Search

 - e-Bay + Google Maps

 

 

웹2.0은 아직 진행중

 

이렇게 여러 서비스들을 늘어놓고 보면 웹2.0에 대해 어렴풋이 이해가 될 듯 할 것 같지만, 막상 웹2.0을 정의하려면 어떤 설명부터 해야 할지 난감하긴 여전합니다. 웹2.0은 아직까지도 차세대 웹의 모습으로서 각광을 받고 있긴 하지만, 한 편으로는 예전부터 있던 개념을 새삼스레 꺼낸다-한 마디로 뒷북이란 얘기죠-고 생각도 있고, 극단적으로는 단지 마케팅 용어일 뿐이라는 주장도 있습니다. 그러나 어떻게 보면 새로운 기술, 풍부해진 유저 인터페이스 등과 함께 그 동안 주류에서 밀려나 있었던 웹의 진정한 의미를 찾았다는 뜻으로 "2.0"이라는 숫자는 정당하다고 생각합니다.

 

아직 한국에서는 웹2.0 서비스라고 예를 들 만한 곳이 별로 없습니다. 한국에서의 인터넷 환경의 특수성이라는 것이 있기 때문에, 제대로 된 웹2.0 서비스가 탄생하기 위해서 좀 더 시간이 필요할지도 모르겠습니다. 처음에는 생소하기만 했던  RSS 서비스, 태깅 등이 일반화되고 있고 API 서비스 등이 신규 오픈되고 Long Tail의 중요성이 부각되어가는 것을 보면, 머지않아 한국에서도 신선한 웹2.0 서비스라고 부를 만한 것을 볼 수 있지 않을까요?

진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크