저는 이 자리(JavaOne)에 자바 라이센스와 여러 가지 오픈소스 라이센스 사이의 차이점에 대해서 얘기하기 위해서 참석한 것이 아닙니다. 제가 오늘 이 자리에서 말씀드리고자 하는 것은 썬의 슬로건인, "The network is the comptuer"입니다. 그리고 그것이 오픈소스의 역사에 있어서나 미래에 있어서 어떤 식으로 정리되어 나갈 지에 관해서입니다.

생태계 그리고 아키텍쳐

본론에 들어가기 전에 '테크널러지의 전파'를 파악하는 데 있어 기초가 될 몇 가지 개념에 대해서 소개할까 합니다. 첫 번째 개념은 생태학(ecology)으로부터 비롯된 것입니다.

어쩌면 여러분들께서는 우리 오라일리 출판사에서 나온 책들의 커버에 항상 동물이 등장한다는 점 때문에 생태학을 끌어들이고 있다고 생각하실지도 모르겠습니다.^_^ 하지만 그 이상의 이유가 있습니다.

첫째, 생태학은 정말로 풍성한 환경을 창조해내기 위해서는 서로 협동하는 여러 종들로 구성된 웹(그물)이 필요하다는 것을 가르쳐 줍니다. 우리들 모두는 수천, 수백만의 다른 생명체에 의존하고 있습니다. 그들은 각자에게 이익이 되는 목표를 향해서 움직여 가지만 전체적으로는 대체로 모두에게 이익이 되는 협동적인 웹(cooperative web)을 형성하게 됩니다. 저는 오픈소스가 생태학과 많은 유사점이 있다고 믿고 있습니다. 각각의 개발자들은 자신이나 친구들이 사용하기 위해 프로그램을 개발합니다만 그 프로그램이 오픈소스 시스템을 통해서 잘 모르는 다른 사람들의 이익에도 쉽게 보탬이 될 수 있습니다. 오픈 소스 개발자는 심지어 자신의 실수나 실패마저도 '환경'으로 되돌려 주면서 혁신이 자라날 토양을 더욱 더 비옥하게 해줄 수 있습니다.

둘째, 생태학은 풍성한 환경이 조성되기까지는 시간이 걸린다는 것을 가르쳐 줍니다. 하나의 종은 다른 종이 커나갈 기초를 제공합니다. 이끼는 바위를 부스러뜨리면서 흙을 만들어내고 이로부터 보다 복잡한 식물이 자라날 수 있습니다. 생태학적 계승은 시간이 걸립니다. 하지만 단순한 생명체에 의해 만들어지는 물질이 점차 더 풍부해지면서 훨씬 복잡한 종이 나타날 가능성이 늘어납니다.

SF 소설을 좋아하시는 분은 Kim Stanley Robinson의 화성 토양 형성 과정을 다룬 3 부작, "Red Mars, Green Mars and Blue Mars"에 이러한 과정이 놀랄 정도로 잘 표현되어 있음을 아시게 될 것입니다. 그 책을 통해서 저는 어떤 방식으로 생태계가 진화, 변천하고, 오픈소스에서도 하나의 프로젝트가 어떤 방식으로 다음 프로젝트를 보다 더 쉽게 해주는가에 관해 많은 생각을 해볼 수 있었습니다.

한 가지 특이한 점도 있습니다. 최근에 오레곤주의 성헬렌山 주변의 화산폭발로 황폐화된 대지가 회복되는 과정에 관해서 읽었습니다. 거기 보면 생태계가 진화하는 데 있어 '운'이 어떤 역할을 했는지 잘 그려져 있었습니다. 화산 폭발 후에도 살아남은 여러 식물과 동물은 그 지역 생태계를 완전히 다시 창조할 기회를 가졌습니다. 이런 내용을 알기 위해 생태학을 처음부터 공부할 필요는 물론 없습니다. 정원을 가진 사람이라면 누구나 '자원봉사자'들이 항상 출현한다는 것을 아니까요.

요약하자면 주제는 다음의 세 가지입니다.
협동(cooperation), 진화(evolution), 그리고 깜짝쇼(surprise).

오픈소스 소프트웨어에서 가장 멋있다고 생각하는 점 중의 하나는 '운의 힘'과 '의도하지 않은 협동'이 어떻게 컴퓨터 산업을 진화시켜 나가는지 확실하게 보여준다는 것입니다. 이런 내용들을 분명하게 해 줄 얘기를 지금부터 할까 합니다.

또 하나 여러분과 함께 나누고 싶은 개념은 Lawrence Lessig 씨가 쓴 놀라운 책, "Code and other laws of Cyberspace"에 나오는 내용입니다. Lessig 씨는 헌법학자이고 그 책은 싸이버스페이스의 아키텍쳐의 변화에 정부 규제가 필요하다는 시각에 도전하는 것에 촛점을 맞추고 있습니다. 이 자리에서 Lessig 씨의 얘기를 토의할 시간은 없지만 그 책은 꼭 한번 읽어보시기를 추천합니다. 지금 말씀드릴 부분은 그 책을 통해 느낀 컴퓨터 시스템과 네트웍 아키텍쳐의 어떤 본질적 부분이 오픈소스 운동을 가능케 했는지, 그 방식에 관한 내용입니다. 거기에 관해서 생각하면서 발견하게 된 점들이 이번 연설의 주요 주제가 될 것입니다.

서두는 이 정도입니다. 다시 주제로 돌아와 보면 네트웍이야말로 정말로 컴퓨터입니다. 앞으로 하게 될 얘기들은 조금 전에 말씀드린 이끼류가 의미하는 것과 동등한 것입니다. 제가 정말로 흥분되는 부분은 그런 점들이 암시하는 미래입니다.

광역 네트워킹의 확장으로써의 오픈 소스

(Open source as an outgrowth of wide area networking)

여기 계신 분들 대부분 제가 오픈소스 테크널러지의 챔피언^_^ 중 한 명이라는 것을 아실 겁니다. 아파치(Apache), 리눅스 (Linux) 그리고 펄(Perl) 같은. 하지만 제가 할 얘기는 오픈소스 라이센스의 구체적인 부분에 관해서가 아닙니다. 인터넷의 '기초'이자 '표현'인 오픈소스를 얘기하고자 합니다.

현재까지, 어쨌든 인터넷은 오픈소스 위에서 움직이고 있습니다. Bind(Berkeley Internet Name Daemon)는 인터넷 상에 존재하는 프로그램 중 가장 중요한 프로그램입니다. 그 뒤를 잇는 것으로 인터넷에서 가장 널리 쓰이는 애플리케이션 프로토콜 SMTP와 HTTP의 오픈소스 서버인 Sendmail, Apache가 있습니다. 이들 모두 오픈소스입니다.

저는 이런 점을 널리 알리기 위해 노력해 왔습니다. 오픈소스는 '리눅스 그 이상'이라는 것을 알리고자 했었죠.

인터넷과 오픈소스의 관계는 단순히 인터넷 표준을 지원하고 완성하는 프로그램 그 이상입니다. 저는 오픈소스 운동 자체가 광역 네트웍의 확산 속에 깊이 뿌리 박고 있다고 믿고 있습니다.

벨 연구소(Bell Lab)에서 초기 유닉스가 막 쓰이던 때를 생각해 봅시다. 유닉스가 배포되던 라이센스는 자유로왔지만 오늘날의 정의로 보자면 오픈소스는 아니었습니다. 두 가지 점이 중요했는데요.

유닉스의 기초적인 아키텍쳐는 독립적인 개발자들에 의해 유지되고 있었다

Thompson 씨와 Ritchie 씨(역자주: 유닉스를 만든 사람들)는 단일하고 획일적인 시스템을 구축하는 대신 단순한 시스템 서비스를 만든 다음 여러 프로그램이 서로 협동할 수 있는 방법에 관해 파워풀한 개념을 만들어냈습니다. Kerinighan 씨와 Pike 씨가 "The Unix Programming Environment"에서 정말 훌륭하게 묘사했던 것처럼 프로그램은 항상 아스키 텍스트 스트림을 표준입력(Standard Input)으로 읽어 들이고 아스키 텍스트를 표준출력(Standard Output)으로 내보내게끔 만들어졌습니다. 그 결과 단순한 프로그램들이 레고 장난감처럼 하나의 파이프라인을 통해 연결될 수 있었습니다. 단순한 프로그램들이 모여서 복잡한 업무를 해낼 수 있게 되었습니다.

이와 동일한 원칙이 인터넷의 개발 과정에서도 명백하게 적용되었습니다. 공개표준(Open Standard)은 다른 프로그램들과 협동하기 위해서는 어떤 것을 읽어들여야 하고 어떤 것을 내보내야 하는지를 규정하고 있습니다. 그 중간 과정에 무엇을 하는지는 각자에게 맡겨져 있습니다.

이 원칙은 시장 또는 생태계내에서 활동하려는 측에게 진입장벽을 낮춰주는 근본적으로 느슨한 아키텍쳐입니다. 어느 누구나 자신을 위해서 또는 자신이 노리고 있는 작은 틈새시장을 위해서 프로그램을 만들 수 있습니다. 동시에 마술적으로 전체 시스템의 일부에 편입됩니다. "Ecology in action"이라 할 수 있습니다.

소스코드는 다른 사람이 볼 수 있도록 열려 있었다

(Source code was available for inspection)

많은 형태의 라이센스들이 각자 장점을 갖고 있습니다. 분명히 한 라이센스 방식이 다른 것보다 어떤 그룹의 개발자들 및 사용자들의 필요성과 가치를 더 충족시켜줄 수는 있습니다. 하지만 제가 보기에 소스코드를 공개한다는 사실(source availability)이야말로 논쟁의 여지 없이 다른 사람들의 작업물을 기반으로 자신의 일을 해내는 데 가장 큰 역할을 했습니다.

초기의 유닉스의 AT&T 라이센스는 오픈소스가 아니었습니다. 나중에 AT&T가 어처구니 없이 발을 뺄 수밖에 없게 만든 문구들을 달고 있었습니다. 하지만 '소스 공개'라는 부분은 공동 작업을 통해 개발된 최초의 메이져 운영체계가 나타나게 한 창조성을 폭발적으로 이끌어 냅니다.

소스코드를 갖는 것의 키 포인트는 여러분이 다른 사람이 해놓은 일을 들여다 볼 수 있다는 것입니다. 이것은 학습을 가로막는 진입장벽을 파격적으로 낮춰줍니다. 실제 결과물을 통해 배우기 때문에 여러분은 바퀴를 다시 발명할 필요가 없습니다. 모방은 곧 혁신을 점화합니다.

우리는 웹의 초기에 그런 창조성의 폭발을 볼 수 있었습니다. 팀 버너스 리의 오리지널 웹은 단지 오픈소스가 아니었습니다. 공개된 "퍼블릭 도메인(public domain)"이었습니다. NCSA의 웹써버와 모자익 브라우져는 기술적으로 얘기하자면 오픈소스는 아니었습니다. 그러나 여전히 소스는 자유롭게 공개되어 있었고 때문에 NCSA 써버 개발자들이 각자 고유의 프로그램을 개발하기 위해 떠나 버렸던 잿더미 속에서도 "아파치(Apache)"라는 불사조가 탄생할 수 있었습니다.

보다 더 중요한 것은, 팀 버너스 리의 오리지널 브라우져로부터 모자익(Mosaic) 브라우져로, 그리고 넷스케잎 네비게이터와 마이크로소프트 인터넷 익스플로러에까지 이어졌던 "View Source"(소스보기) 메뉴였습니다. 아무도 HTML이 오픈소스 기술이라고 생각하지 않았음에도 "소스보기" 메뉴는 웹이 폭발적으로 확산되는 데 결정적 기여를 합니다. 아마츄어에게 쳐진 진입장벽이 매우 낮아졌기 때문입니다. 누구나 다른 사람이 만든 웹페이지가 어떻게 만들어졌는지 간단하게 들여다볼 수 있었기 때문입니다. 인터프리티드 언어를 이용한 다이내믹 컨텐트 제작 역시 투명성의 전통을 계속 이어나갑니다.

이제 광역 네트워킹의 역사와 오픈소스의 전파에 관해서 얘기해 봅시다.

초창기에는 소스가 테잎에 담겨서 보내졌습니다만 정말로 본격화된 것은 역시 소스가 인터넷을 타고 배포되기 시작하면서부터입니다. 유즈넷(Usenet) -널리 퍼져있던 게시판 시스템- 은 자발성, 그리고 오픈소스의 특징을 규정 지워준 '분산화된 협동'이 거둔 최초의 커다란 성공 사례였습니다. 여러분은 메일을 보내주고 뉴스를 알려주려는 주변 사람을 찾아내서 유즈넷에 "등록"합니다. 유즈넷은 메일과 뉴스가 한 사이트에서 다른 사이트로 이동될 수 있는 진정한 협동적 네트웍이었습니다. 종종 넷의 한쪽 끝에서 다른 쪽 끝까지 전달되는데 수 일이 걸리기도 했습니다만. 허브 사이트(Hub site)는 특별한 목적을 가진 백본을 형성했지만 모든 것은 자발적이었습니다.

uucpnet과 usenet은 이메일(최초의 킬러��)을 위해서 사용되었지만 소프트웨어 배포와 협동적인 기술지원을 위해서도 사용되었습니다. comp.sources.unix 같은 유즈넷 뉴스그룹은 유닉스를 벨 연구소와 UC Berkeley의 개발 센터로부터 끄집어내어 참여할 의사가 있는 널리 퍼져있는 개인과 기관에까지 확산되는 것을 가능케 했습니다. 펄을 만든 래리 월 씨가 만든 "patch" 프로그램은 전체 소스 파일이 아닌 수정된 부분만을 배포하는 것을 가능케 해주어서 상대적으로 낮은 밴드위쓰 연결을 통해서 소스가 퍼져 나가는 것을 가능하게 했습니다.

인터넷 고속 접속이 널리 퍼져나간 뒤에는 협동적 문화가 이미 확실하게 자리 잡은 다음이었습니다. 초기 개발자들이 작업물을 배포하고 지원하기 위해 사용했던 미케니즘은 이제 테크 섹터를 훨씬 넘어선 하나의 문화적 현상이 되었습니다. 그런 현상의 핵심은 사람들을 지리적 위치나 특정 회사와의 관계를 벗어나 관심사를 중심으로 모이는 데에 광역 네트웍이 사용되었다는 사실입니다. 이것이 오늘날에도 여전히 볼 수 있는 거대한 규모의 문화적 이행의 시초였습니다.

광역 네트워킹이 널리 퍼져있는 개개인을 연결하는 힘을 가졌다는 것이 오픈소스 성공의 핵심입니다. "자기 자신의 가려운 곳을 긁기 위해" 만든 프로그램이 (Sendmail을 만든 에릭 올맨이 최초의 오픈소스 서밋에서 밝혔던 것처럼) 똑같은 가려움을 느끼는 다른 사람에게 퍼져나갈 수 있었습니다. 팀을 꾸리기 위해 전혀 돈을 쓸 필요도 없고 마케팅을 위해서 지출을 할 필요도 없습니다. 제품을 소스가 포함된 '프리'한 형태로 배포하고, 똑같은 문제를 갖고 있는 비슷한 생각을 가진 사람들이 쓸모가 있는지 알아보도록 내버려두면 됩니다.

마지막으로 오픈소스 커뮤니티가 IETF에 주장하고 있지는 않지만 분명히 인터넷 표준 프로세스는 오픈소스 소프트웨어 프로젝과 많은 유사점을 갖고 있습니다. 유일한 실질적 차이점은 IETF가 코드 모듈이 아닌 표준적인 문서를 내놓는다는 점 뿐입니다. 둘 다 메일링 리스트에 등록하거나 세 번 정도 열리는 연례 미팅에 얼굴을 비춤으로써 누구나 참여할 수 있습니다. '표준'은 관련 회사와는 상관없이 개별적 참여자들에 의해 결정됩니다. (물론 상업적 목적의 참여 역시 환영받습니다만 회사들도 개인처럼 자본이나 규모가 아닌 아이디어와 임플리멘테이션을 기반으로 경쟁해야 합니다.) IETF는 오픈소스와 오픈 스탠다드가 만나는 곳입니다.

저는 오픈소스가 오픈소스의 성장과 인터넷의 성장이 서로 밀접하게 연계된 네트웍화된 커뮤니티의 "자연어"라는 주장을 하고 싶습니다. 각 개인이 네트웍 채널을 통해 커뮤니케이션하는 방법을 알게 됨으로써 새로운 속도와 새로운 차원으로 정보를 공유할 수 있습니다. 중세 말에 글을 읽는 사람이 늘어남에 따라 전통적 권력구조가 해체되고 르네상스가 꽃 핀 것처럼, 오늘날과 같은 혁신의 폭발은 개개인이 일반적 채널을 벗어나 정보를 나눌 수 있는 능력에서 비롯됩니다. 여행이 손쉬워진 것이 아이디어가 퍼져나가는 데 기여했던 것처럼 광역 네트워킹은 아이디어가 퍼져나가는 것을 가능케 해줬습니다. 아이디어가 새로운 방식으로 뿌리내릴 수 있게 해줬습니다.
오픈소스는 결국 커뮤니케이션입니다.

그것이 우리 오라일리 출판이 "Collab.net"이라는 오픈소스 벤쳐를 지원한 이유입니다. Collab.net은 아파치 프로젝의 Brian Behlendorf씨와 함께 만든 것입니다. 다른 오픈소스 소프트웨어 프로젝과 달리 아파치는 한 사람의 비져너리 개발자에 의해 출발하지 않았습니다. 아파치 프로젝은 오리지널 "vender"(NCSA)에 의해 버려진 일군의 사용자들에 의해서, 그들이 사용하는 툴을 계속 유지하기 위해 함께 작업할 의사를 가진 사용자들에 의해 시작되었습니다. (사실, "Apache"라는 이름이 이런 사실에서 비롯된 것입니다. 개발자들이 각자의 NCSA 서버 프로그램 "팻취(Patch)"를 함께 나누기로한데서 "A patchy server"라는 이름이 나온 것입니다.)

아파치는 심지어 오픈소스 라이센싱을 완전히 받아들이지 않은 회사들도 광역 네트웍을 기반으로한 협동적 소프트웨어 개발이 가능하다는 것을 가르쳐 주었습니다. 외부에 완성된 소프트웨어를 배포하지 않더라도 큰 회사 내부에서 오픈소스 협동 원칙을 적용할 수 있습니다. 더욱 중요한 점은 Collab.net이 오픈소스 라이센스가 단지 개별적 소프트웨어에만 국한된 것이 아니라는 것을 일깨워 줬다는 점입니다. 오픈소스 소프트웨어는 물론이고 커뮤니티도 구축해야 하고 협동적 개발 프로세스 함께 만들어내야 함을 여러 회사에게 보여줬습니다.

오픈소스가 단순히 소프트웨어 라이센스가 아닌, 인터넷을 기반으로 한 협동작업이라는 저의 주장을 받아들인다면 여러분은 보다 더 큰 장이 펼쳐짐을 보게 될 것입니다. 전통적인 오픈소스 프로젝트 외에 Seti@Home이나 아마존 닷컴의 사용자 리뷰와 같은 협동적인 "computing grid" 프로젝트, 협동적 필터링 같은 테크널러지, The Cluetrain Manifesto를 통해 표현된 새로운 마케팅 아이디어, 웹로그(weblogs), 인터넷 게시판이 주식시장을 움직여가고 있다는 점을 확인할 수 있습니다.

하나의 소프트웨어 개발 방법론으로 출발했던 것이 이제 네트웍을 통한 의사소통이 새로운 아이디어의 주된 전달자가 되어감에 따라 점차 여러 분야에서 얼굴을 드러내고 있습니다.

어떤 면에서 인터넷은 컴퓨터간의 네트웍을 이뤄준 것이 아니라 사람과 사람 사이의 네트웍을 만들어준 것이라 할 수 있습니다. 네트웍이 점차 널리 퍼져감에 따라 무엇이 접속되어 있느냐 만큼이나 누가 접속되어 있느냐도 중요하다는 점이 점점 더 명확해져 갈 것입니다.

네트웍 서비스 아키텍쳐로써의 웹

(The Web as a network service architecture)

다른 인터넷 시대의 애플리케이션처럼 오픈소스 프로젝 역시 호스팅되는 형태로 변환되어 갔다는 점이 중요합니다. 지난 몇 년간 나온 컴퓨터 애플리케이션 중에 어떤 것이 가장 유용했었나 잠깐 생각해 보세요. 그 응용 프로그램들 중에 여러분의 로컬 피씨에 설치를 할 수 있는 것은 사실상 몇몇에 불과합니다. 대신, 대부분이 여러분이 마주하고 있는 웹브라우져 창을 통해 전달됩니다: 아마존 닷컴의 전자상거래 애플리케이션을 생각해 보세요. 이베이(eBay)는 어떻습니까. e*trade나 웹기반 지도찾기 프로그램을 생각해 보세요.

이런 변화가 오픈소스나 프리 소프트웨어 커뮤니티에 던져주는 의미는 정말 엄청납니다. 저는 리챠드 스톨만 씨에게, 사용자가 소프트웨어를 사용하게 하기 위해 개발자가 굳이 '배포' 과정을 거치지 않아도 되는 상황에서 GPL(General Public License)은 큰 의미가 없어질 수 있음을 인식시키기 위해 노력해왔습니다. 호스팅 형태로 제공되는 웹 애플리케이션이 처음부터 끝까지 GPL 소프트웨어로 구축될 수 있지만, 소스코드는 전혀 배포될 필요가 없습니다. 애플리케이션 그 자체가 전혀 배포될 필요가 없기 때문입니다. 소스코드가 배포될 필요가 없다는 것은 GPL의 '소스코드 공개' 구절이 별 의미를 갖지 못한다는 것을 뜻합니다.

이 자리에서 라이센싱이 갖는 함의를 얘기하는 데 더 시간을 쓰지는 않겠습니다. 다만 UNIX 디자인의 가장 근본적인 부분이 갖는 놀라운 측면에 관해서 얘기하고 싶습니다: 파이프(pipe)라든지, 작고 독립적인 프로그램을 연결해서 개별 프로그램의 역량으로는 불가능했을 기능을 협동적으로 수행하는 것 같은.

저는 묻습니다.

웹의 시대에 있어서 '파이프'(pipe)는 과연 무엇일까요?

그 질문에 대한 답변으로써 저는 Jon Udell(前 Byte지 편집장) 씨의 얘기를 옮겨볼까 합니다. 죤 유델 씨는 테크널러지가 어떻게 변천할 것인지를 예측하는 데 있어 제가 아는 한 가장 뛰어난 분 중의 한 분입니다. 몇 년 전인데요. 죤은 당시 저로서는 잘 이해하지 못할, 아주 큰 의미를 갖는 개념을 얘기했습니다. 그것은 정말로 거대한 아이디어였습니다. 다가 올 5년-10년 동안의 컴퓨팅의 모양을 잡아나갈 정도로 말입니다.

죤은 아주 단순한 명제로 시작했습니다. 웹을 단순히 웹 서버로부터 웹 페이지를 전달해주는 클라이언트-서버 시스템으로 생각하지 말라는 것입니다. 웹은 분산화된 서비스 아키텍쳐(a distributed service architecture)라는 것입니다. 그 아키텍쳐는 각 서비스를 불러올 수 있는 URL이라는 1세대 "API"로역자주 이뤄져 있다는 것입니다.

죤은 최근에 있었던 파이썬 컨퍼런스의 Zope 트랙에서 다음과 같이 얘기했습니다:

"정말 놀라울 정도로 오늘날의 웹은 이미 거대한 규모의 네트웍 서비스 집합체가 되었습니다. 이제까지 이들 네트웍 서비스들은 주로 웹 브라우져 지향적이었습니다. 여러분의 브라우져는 야후!에 있는 서비스를 "호출"해서 야후! 디렉토리내의 한 페이지를 받아 옵니다. 또는 알타비스타의 서비스 중 하나를 "호출"해서 검색 결과를 전송받습니다.

웹이 정말 매력적인 이유 중 하나는 이들 웹싸이트에서 제공하는 여러 서비스를 불러올 때 웹브라우져외에 다른 것도 사용할 수 있다는 사실입니다. URL을 인식할 수 있는 언어(Python이나 Perl, 자바스크립트, 자바 같은)를 사용해서 만들어진 프로그램이면 다들 웹 써비스를 "호출"할 수 있습니다.

이들 프로그램의 관점에서 웹은 흡사 "호출가능한 컴포넌트를 모아놓은 라이브러리"와 같습니다. 게다가 기존의 컴포넌트들을 참신한 방식으로 엮어서 새로운 웹 써비스를 구축하는 것은 정말 쉽습니다. 저는 바로 이것을 "웹에서의 UNIX 파이프라인"으로 생각합니다."

죤은 계속해서 그가 만든 프로그램을 소개하는 것으로 얘기를 이어나갔습니다. 그 프로그램은 "web mindshare calculator"라는 이름의 프로그램으로, 이런 것이었습니다. 알타비스타에는 한 URL에 얼마나 많은 사이트가 연결되어 있는지를 알려주는 links 키워드가 있습니다. 야후에는 관련된 싸이트들의 카테고리를 제공하고 있습니다. 따라서 죤은 아주 간단한 펄 프로그램을 하나 만들어서, 야후 트리(tree)중 한 시작점을 주면 그 트리의 가장 하부까지 이동하면서 url들을 모아서, 이들 url을 하나씩 알타비스타의 links 키워드로 보내주게 했습니다. 그 결과 야후 카테고리가 하나 주어지면 그 카테고리내에 있는 url을 다른 싸이트로 가장 많이 링크된 순서대로 출력할 수 있었습니다.

그가 말하듯이, "웹에서의 UNIX 파이프라인"입니다. 두 개의 웹 사이트를 사이트를 만든 사람은 전혀 생각지 못했던 방식으로 연결해서 훨씬 더 유용하게 확장해 냈습니다.

이렇게 부가적인, "비공식적인" 여러 웹 사이트로의 인터페이스를 만들어낸다는 아이디어는 우리 오라일리 씨리즈의 주 독자층인 고급 사용자들에게 특히 널리 퍼진 아이디어입니다.

여러 웹 사이트로의 "비공식적인" 인터페이스를 이용한 프로그램 중에 우리(O'Reilly)가 만든 것도 있습니다. 우리는 아마존에서 현재 우리 회사 서적이 어느 정도 경쟁하고 있는지를 편집자나 제품 관리자가 빠르게 접근할 수 있는 프로그램을 만들었습니다. 우리는 이 프로그램을 "amarank"라고 부르고 있습니다. 프로그램은 우리 회사 책들을 몇 가지 검색 기준을 바탕으로 독자들의 호평(positive review)과 아마존 판매 순위에 따라 순위를 매겨서 보여주기 때문입니다. 다른 출판사들이나 서점, 도서관들도 아마존에 있는 관련 도서 목록을 검색할 수는 있습니다. 하지만 웹브라우져에서 이곳 저곳을 클릭하러 다니는 것은 얼마나 시간낭비입니까. "amarank"는 "아마존에 있는 자바 관련 서적 중 탑 30 을 보여달라" 라고 질문을 던지거나 "자바 관련 책에 비교할만한 펄 책은 어떤 것이 있나", "지난 1월 이후 출간된 Jini 관련 서적을 모두 보여달라"라고 질문하면 됩니다.

게다가 amarank가 아마존 싸이트를 뒤지고 다니는 시간을 기다리고 있을 필요없이, 그 결과를 또 다시 다른 형태로 프로세싱할 수도 있습니다. amarank의 결과물은 메일 프로그램으로 보내져서, 최종적으로 엑셀 등의 스프레드쉿 프로그램으로 처리되게 할 수도 있습니다.

다른 예를 들어볼까요?

Finance-QuoteHist Perl 모듈은 The Motley Fool이나 Financial Web과 같은 웹 싸이트에서 과거 주가를 가져올 수 있습니다. YahooChart라는 펄 모듈은 Yahoo! Finance로부터 주식챠트를 가져올 수 있습니다. DeepLeap이라는 프로그램은 새로운 "온라인 어시스턴트"로써, 구글과 야후!무비로부터 각 지역의 영화 정보를 가져올 수 있는 기능을 갖고 있습니다. 이 프로그램은 모든 웹 페이지의 정보를 팜파일럿으로 보낼 수도 있고, 그 페이지를 프린팅하기에 적합한 형태로 포맷할 수도 있으며, 웹페이지가 업데이트 되었을 때 인스턴트 메씬져나 이메일로 알려주는 기능까지도 갖추고 있습니다.

이들 프로그램들은 대개 펄(Perl)로 만들어졌습니다. 웹 쿼리를 던진 후 반환되는 출력물들은 보통 형식이 갖춰지지 않은 html인 경우가 많고, 그런 데이타를 다루는 데 있어 펄이 아주 적합하기 때문입니다.

죤의 주장은, 저의 의견도 마찬가지지만, 이것이 그야말로 이제 막 폭발하려는 단계라는 사실입니다. 이제 막 xml이 뜨기 시작하고 있고, 즉, 여러 데이타들이 보다 더 구조적인 면을 갖춰가고 있고, 여러 웹 싸이트들은 다른 웹 프로그램이 보다 쉽게 접근할 수 있는 API를 더 명시적으로 드러냄으로써 많은 이익을 거둘 수 있다는 점을 인식하기 시작했습니다.

죤이 "객체적 웹의 2 세대(Second generation object web)"라고 명명한 것은, 앞으로의 웹 싸이트가 다른 프로그램과의 인터액션을 용이하게 해 줄 명시적 API를 제공하는 시점을 의미합니다.

죤은 이렇게 이어나갔습니다:

"작년에, Dun과 Bradstreet 씨는 운영하고 있는 온라인 비즈니스 전체를 개편했었습니다. 백엔드 데이타 소스와 middle-tier component를 xml 인터페이스로 포장해서 HTTP나 HTTPS 프로토콜을 통해 접근할 수 있게 했습니다. 원래 D&B 고객들은 원시 데이타(raw data)를 직접 구입하기보다는 패키지화된 보고서를 구입했었고, 맞춤화된 보고서를 만드는 과정은 그야말로 느리고 힘들었습니다. 하지만 새로운 방식은 모든 것을 완전히 바꾸어 놓았습니다. 새 시스템은 데이타 서비스 모음을 미리 정의해 둔 후, 각각의 개발자들은 이들 서비스를 xml-over-http 프로토콜을 통해 여러 가지로 조합해서 사용할 수 있었습니다. 미케니즘 상으로는 webMethods의 b2b 써버에 기반을 둔 것입니다만은 개념적으로는 xml-RPC와 크게 다르지 않습니다. 재작년만 해도 개발자들이 맞춤화된 결과물을 D&B로부터 얻어내기 위해서는 D&B 측에 직접 만들어달라고 요청하는 수밖에 없었습니다. 그 과정은 지루했고, 또 D&B 측과 private 네트웍을 유지하면서 네트웍 상에서 폐쇄적인 프로토콜을 통하는 수밖에 없었습니다. 새로운 방식에서는, D&B에서 여러 가지 데이타 제품군을 카탈로그 형태로 내놓은 다음, 개별 개발자들은 'xml 지향 - http 인식가능' 툴킷을 이용해서 웹을 통해 그 카탈로그를 가져와서, 데이타들을 통합할 수 있는 간단한 글루 코드를(glue code) 이용해 특정 애플리케이션으로 데이타를 집어넣을 수 있습니다."

우리 오라일리에서도 Rael Dornfest 씨가 "Meerkat"이라고 부르고 있는 RSS aggregator를 이용해서 새로운 툴을 만들어냈습니다.

RSS에 관해서 잘 모르는 분들을 위해 조금 말씀드릴까요? RSS는 웹 싸이트에서 컨텐트 신디케이션(content syndication)을 할 때 사용하는 XML 기반의 스토리 처리 방식입니다. 각 웹 싸이트의 '스토리'는 타이틀과 링크(자신의 웹싸이트로 연결되는), 부가적인 설명으로 구성되어 있습니다. 그리고 스토리가 필요하다고 생각되는 사람은 누구나 스토리를 가져다가 자신의 웹싸이트에서 사용할 수 있습니다.

Meerkat은 이것을 몇 단계 더 발전시킨 것입니다. 개별적인 스토리를 여러 웹싸이트에서 가져다 쓸 수 있게 하는 데에 RSS를 사용한다는 차원을 넘어서, Rael 씨는 씬디케이션된 컨텐트들의 흐름을 조절할 수 있는 툴을 만들었습니다. Meerkat의 백엔드는 웹상에 떠 있는 테크널러지/컴퓨터/geek/과학관련컨텐트에 속하는 RSS 파일들을 검색합니다. 검색한 파일들은 각각을 쟝르별/채널별/시간별로 분류해서 mysql 데이타베이스에 저장되고 이 데이타베이스는 편집가능한 인터페이스를 통해 접근할 수 있으며 레귤라 익스프레션을 이용한 검색기능까지 갖춰져 있습니다. 편집자는 인터페이스를 이용해서 여러 '스토리'들을 선택해 가며 개별 타겟 퍼블리에이션으로 보내줄 수 있습니다. Rael 씨는 이 인터페이스를 보다 일반적 목적의 RSS 리더로(general purpose RSS reader) 만들어서 공개하기도 했습니다.

Rael씨는 사람들이 Meerkat 역시 아마존을 이용하는 방식으로 이용한다는 것을 알게 되었습니다. 그의 데이타를 가져다가 자신이 의도했던 것과 다른 방식으로 사용하기 시작했으니까요. 그래서 그런 과정들을 보다 용이하게 할 수 있도록 간단한 API를 만들어내었습니다. 그 API는 데이타를 다양한 형태의 프로그램에 적합한 포맷으로 바꾸어주는 것으로 구성되어 있습니다. 예를 들어 PHP serialized data와 자바스크립트를 애플의 셜락(Sherlock)에 맞는 포맷으로 바꾸어 줍니다.

여기서 더 자세하게 Rael의 API에 관해서 말씀드리지는 않겠습니다. 제가 얘기하고 싶은 것은 아키텍쳐라는 관점에서 보았을 때, 그리고 협동적인 컴퓨팅 문화와 공명할 수 있는 웹싸이트를 만든다는 관점에서 볼 때, 그의 아이디어가 정말 중요한 의미를 갖는다는 것입니다. 단순히 mysql이나 PHP 같은 오픈소스 툴을 이용해서 싸이트를 구축했다는 사실보다는 Meerkat을 엔지니어링할 때 만든 사람의 목적을 충족시키는 것 뿐만 아니라 자신은 모르는 또는 의도하지 않았던 다른 방식으로도 사용 가능하게 했다는 점이 중요합니다.

이 분야가 폭발적으로 성장하려면 xml 기반의 메타데이타 교환과 서비스 검색(service discoveries)을 위한 표준이 등장해야 합니다. 그러면 웹 기반의 서비스들은 자신들의 API를 xml 기반으로 만들어낼 것이며 데이타를 기존의 http나 smtp 프로토콜상에서 xml 형태로 자유롭게 주고 받을 수 있을 것입니다. 이것은 앞에서 제가 말씀드린 느슨하게 연관된 아키텍쳐를 다시 한 번 만들어 낼 것이고, 이 점이 유닉스를 중심으로 오픈소스 문화가 꽃 피는 데 있어서 매우 중요합니다.

다시 한번 존 유델씨의 말을 옮겨보죠:

"웹 프로그래머로서 우리들 모두는 네트웍 서비스를 만들고 사용하는 일을 합니다. CGI 스크립트를 이용한 웹 서버를 통해 만들어낸 ORB(Online Referencing Book)는 아주 초라한 것이었지만, 이것은 1994 년 이전과 비교해보면 놀라운 수준입니다. 그리고 훨씬 더 근본적인 발전이 이뤄지면서 더욱 놀랍게 되어 갈 것입니다. 알타비스트와 야후!, 그리고 자신의 서비스를 웹을 통해 운용하는 다른 모든 웹싸이트들은 서비스를 xml 인터페이스를 이용해서 구축해야 합니다. 클라이언트가 웹브라우져라면 xml은 html로 렌더링될 수 있습니다. 클라이언트가 다른 프로그램이라면 xml은 그 프로그램에 맞게 직접적으로 전달될 수 있기 때문입니다."

물론, 웹에는 보다 협동적으로 사용되기 위해서는 조금 더 손질이 필요한 웹 사이트 역시 매우 많습니다.

그 점과 관련해서 어제 여기 JavaOne 쇼 플로어에서 아주 흥미로운 신생업체를 보았습니다. "Cape Clear"라는 이름의 아일랜드 회사입니다. 제가 이해한 것이 틀리지 않다면 자바빈즈(Javabeans)나 코바(CORBA) 컴포넌트를 내부적으로 살펴본 다음 그것을 xml 인터페이스로 표현해주는 것입니다. 자바빈즈나 코바를 xml-RPC나 SOAP 같은 전송 프로토콜을 통해 접근할 수 있게 해준 것입니다.

썬이 어제 SOAP을 뒷받침하겠다는 발표를 한 것은 정말 좋은 소식입니다. IBM 역시 자바 기반의 SOAP 지원을 발표했고 더 나아가 그 코드를 xml-Apache 프로젝트에 제공하겠다고 했습니다. xml은 여기저기서 힘을 얻어가고 있고 이것은 분명히 좋은 현상입니다.

자동화된 서비스 검색(Automated Service Discovery)

마지막으로 제가 드릴 얘기는 이 질문으로 요약될 수 있을 것입니다:

ICQ와 Jini, 그리고 냅스터가 갖고 있는 공통점은 무엇일까?

제 생각에는, 이들 시스템의 핵심은 계층화된 클라이언트-서버 컴퓨팅이 아닌, 보다 비공식적인, 피어-투-피어 네트워킹을 증진시키는 서비스 디스커버리로의 접근입니다. 냅스터는 "너 지금 온라인에 있니?"라는 질문 대신 "메탈리카의 최신작이 있니?"라는 질문을 할 수 있는 "인스턴트 메씬져"입니다.

중앙 서버의 역할은, 역할이 있기는 하다면, 데이타를 제공하는 것이 아니라 누가 그 데이타를 가지고 있는지를 가리키는 것뿐입니다. (이런 말 할 필요가 있는지 모르겠지만, 이것이야말로 메타 데이타(meta data)의 한 사례입니다.) 다음 수순은 이런 모델을 보다 복잡한 서비스 쪽으로 적용하는 것입니다.

늘 그래왔듯이, 비전을 구체화한 최초의 회사 중 하나는 역시 썬이었습니다. 그리고 썬에서 제공하는 서비스들로의 접근을 허용해주는 기기나 이들 서비스를 검색하고 이용하게 해주는 기기들을 내놓고 있습니다. Jini는 초기에는 네트웍화된 하드웨어 디바이스에 촛점을 맞추고 있었지만 이제는 같은 원칙이 웹의 세계에도 적용되고 있습니다.

앞으로 우리가 보게 될 것은 제공하는 서비스에 직접 질의를 할 수 있을 뿐만 아니라 서비스를 호출하는 방식에 대해서도 알려주는 웹 사이트들입니다. 그런 웹 서비스들을 검색할 수 있는 검색엔진도 등장하게 될 것입니다.

저는 현재 장님 코끼리 만지는 식으로 생겨나는 회사들을 많이 보고 있습니다. 며칠 전, infrasearch라는 기술의 베타 릴리스 발표가 있었습니다. 이것은 누텔라에 기반을 둔 기술입니다. infrasearch 기술이 더 확대될 지 아닐 지는 아무도 모릅니다. 하지만 아이디어 만큼은 아주 제대로 짚은 것입니다. 정적인 페이지를 검색하는 것이 아닌 '서비스'를 검색할 수 있는 검색엔진을 만들겠다는 것입니다. 그 회사가 보여준 간단한 예를 보니까, 검색엔진에 대수식을 입력하면 "계산기"를 찾아 대수식을 입력한 다음 결과를 반환해 주었습니다.

이런 서비스 검색, 퍼블리케이션 아키텍쳐 중 어떤 것이 널리 퍼지고 인기를 얻게 될는 지는 저도 모릅니다. 그리고 꼭 최상의 아케텍쳐일 필요도 없습니다. Clayton Christenson이 "The Innovator's Dilemma"에서 지적한 대로, 종종 "less is more"입니다. 최종 승자는 최고의 기술이라기보다는 어느 정도 쓸 만하고 사용하기 쉬운 것들이 많습니다. 생태학적 계승 측면에서 얘기하자면 이끼류가 최고로 번성할 때가 보다 더 고등 식물, 고등 동물이 나타날 때입니다.

우리는 실패적인 출발(false starts)을 허용해야만 합니다. 그래야 초기 아이디어는 실패하더라도 그것에 기반해서 다른 사람이 다른 길을 찾아낼 수 있기 때문입니다. 그런 방식으로 디자인된 테크널러지는 다른 사람이 그 테크널러지를 사용하는 방식에 의해 만든 사람을 놀라게 할 수 있습니다.

이제, 제가 서두에서 말씀드린 주제로 돌아오게 되었습니다. 오픈소스 말입니다. 오픈소스의 진정한 힘은 진입장벽을 낮추어서 여러 사람이 개발과 창조의 과정에 쉽게 뛰어드는 것을 가능케 한 데 있습니다.

네트웍 시대에서의 최종 승자는 자신들의 개발 스탭들에게만 의존하지 않는, 컴퓨터를 가진 사람이라면 누구나 개선과 발전에 뛰어들 수 있는 길을 열어놓은 기술이 차지할 것입니다.