"참여의 아키텍처(Architecture of Participation)"는 팀 오라일리가 2003년 경부터 사용한 용어입니다. 한글 용어를 "참여의 '아키텍처'"라고 한 이유는, "참여의 '구조'" 라고 하게 되면, 팀이 애초에 의도한 바가 잘 드러나지 않기 때문입니다. (이 점은 이 글을 끝까지 읽어보시면 파악하실 수 있으리라 생각합니다.)
"참여의 아키텍처" 는 쉬운 단어의 조합이기 때문에 자의적으로 해석되고 오용되기 쉽습니다. 사람들이 참여하게 만드는, 또는 참여할 수 있는 구조라고 단순히 이해해 버리면 사람들이란 누구인지, 개발자인지, 사용자인지. 참여한다고 하면, 단순히 덧글을 다는 정도인지, (
SETI@home 처럼) 리소스를 내어 주는 건지. 또는, 어떤 방식으로 참여하게 하는 건지. 아키텍처 즉 구조 내지는 구성이라고 하면 또 무얼 말하는 건지. 오픈소스와는 어떻게 다른 건지. 여러가지 질문이 생기게 됩니다. 더욱이, 웹 2.0 애플리케이션이라는 문맥으로 생각해 보면 더 많은 의문이 떠오릅니다.
팀은 자신이 처음 쓰기는 했지만 "Architecture of Participation"에 대해서 명확하고(crystal-clear) MECE(Mutually Exclusive Collectively Exhaustive)한 개념화를 아직 이루어내지 못한 것 같습니다. 물론 개념화가 시작된지 얼마 되지 않아 그럴수도 있겠습니다만, 전반적으로 팀은 생각을 끝까지 끌고나가 정확하고 견고하게 규정하는 것보다, 세상의 흐름과 특이한 현상을 포착하여 사람들에게 잘 어필하는(catchy한) 용어로 그럴듯한 이름을 붙이는데에 더 소질이 있는 것 같습니다. 미디어 회사의 대표답습니다. (사실 개념과 제반사항의 정리는 업계가 아닌 학계에 있는 사람의 몫일 것입니다). 다르게 생각하면, 인터넷 세상에서 벌어지는 모든 일이 다 아직 진행형이기 때문에 어쩔 수 없기도 한 것 같습니다.
위키피디어의 정의
위키피디아에서 architecture of participation을 찾아보면,
"The phrase architecture of participation describes the nature of systems that are designed for user contribution, such as open source and Wikipedia itself. It was coined by Tim O'Reilly, who described it at length in a 2003 speech and later in several of his online writings.
The phrase has come to define one of the key elements of what's been called Web 2.0, which describes the collection of companies, technologies and projects that are designed around the culture and economics of openness."
라고 써 있습니다. 실망스럽게도 현재까지 위의 내용이 위키에서 찾을 수 있는 설명의 전부 입니다. 게다가 "사용자의 공헌을 위해 디자인된 시스템이 가지는 본질적인 속성(describes the nature of systems that are designed for user contribution)" 이란 말은 팀의
"The Architecture of Participation" 에 나오는 말을 그대로 베낀 것입니다. (아마 팀이 위키피디어에 올린 것일지도...)
사용자의 공헌(user contribution)을 위해 디자인된 시스템의 본질적인 속성(nature)이라... 의미가 명확하지 않습니다. 사용자가 누구인지, 어떻게 공헌한다는 건지, 본질적인 속성(Nature)이란 건 어떤 의미인지 정확히 알 수 없습니다. 더해서 그것의 예로 든 오픈 소스나 위키피디아는 "참여의 아키텍처"를 구현한 예 중 일부일 뿐 입니다. (추후에 설명합니다.) "참여의 아키텍처"의 개념은 이것들을 넘어 섭니다.
아마 "본질적인"이라는 의미를 강조하기 위해 "사용자의 참여"나 "오픈소스 어프로치"라는 말을 버리고 "architecture" of participation 이라고 썼나 봅니다.
팀이 어떤 과정을 통해서 이런 용어를 생각해 내게 되었나를 추적해 보면 더 이해가 깊어질 것 같습니다.
용어의 기원과 변천
사실 오픈소스, 특히 Perl에 깊이 관여해 있던 팀은 오래 전부터 "참여"의 중요성을 말하고 있었습니다. 1999년의 "Open Source: Voices from the Open Source Revolution"에 발표된 그의 아티클
"Hardware, Software and Infoware"를 보면 그는 소프트웨어 개발에 있어서의 참여의 중요성 (즉, 오픈소스 운동) 뿐 아니라, 인터넷 시대에서의
오픈소스 어프로치의 중요성에 대해서 역설하고 있습니다. 이때 까지만 해도 "참여" 그 자체에만 의미를 두었고, 특히 "개발자"들의 자발적인 참여(Volunteerism)가 중요한 명제 였습니다.
그런데, 그가 리누스 토발즈와 98년 했던 인터뷰에서 아키텍처라는 말이 대두되게 됩니다.
즉,
"소스코드보다 아키텍처가 더 중요하다.",
"내가 리눅스를 가지고 했던 것을 윈도우즈를 가지고는 못할 것이다. 심지어 나한테 (윈도우즈의) 소스코드를 다 열어준다고 하더라도. 왜냐하면 (윈도우즈의) 아키텍처가 (내가 리눅스로 했던 일을 하도록) 지원하지 않으니까."
이말이 팀의 머리를 때렸습니다. 아키텍처가 소소코드의 공개보다 더 중요하다...
시간이 지나면서 "아키텍처" 라는 말이 구조/설계라는 사전적 의미에 더하여, "내재되어 있는" 또는 "구조에 녹아 들어 있는" 이라는 속성의 의미가 팀에게 점점 더 부각된 것 같습니다. 팀은 점차로 "오픈소스 어프로치"가 중요하다 거나, "개발자와 사용자의 참여"가 중요하다 라고 말하지 않고, "참여의 아키텍쳐"가 중요하다 라고 쓰기 시작합니다.
또 한가지, 팀의 생각에 영향을 준 것은 댄 브릭클린(Dan Bricklin) 이었습니다.
그는 2001년 2월 팀이 주최한 P2P 컨퍼런스에서 "거대한 DB를 만드는 데는 세 가지의 방법이 있다. 첫 번째는 야후처럼 사람을 고용해서 그 일을 맡기는 것이다. 두 번째는 오픈 디렉토리 프로젝트나 위키피디어 처럼 자원 봉사자(volunteeer)가 그 일을 하게 하는 것으로, 이것은 오픈소스 진영에서 영향을 받은 어프로치이다. 냅스터는 그 세 번째 방법을 보여준다. 사용자들이 내려받은 음악을 자동으로 다른 사람과 공유하게 만들어 거대한 음악 DB를 자연스럽게 구축한다" 라고 말했습니다.
이를 듣고 팀은 오픈소스 진영의 성공도 자발적 참여(volunteerism) 자체 보다 참여가 가치를 만들어내도록 할 수 있는 구조적인 부분(architectural insights)의 영향이 더 큰 것이 아닐까 하고 생각하게 됩니다. 즉, "리눅스, 인터넷, 월드와이드웹의 '아키텍처'의 디자인이 애당초 사용자들이 자신의 흥미/이득(interest)을 위해 수행한 지극히 개인적이고 이기적인 활동의 부산물(byproduct)이 자동적으로 모든 사람에게 이익을 줄 수 있도록 되어 있었다" 라고 보게 됩니다. (이런 시각으로 오픈 소스를 바라보면, 매우 철학적으로 들리게 됩니다. 애덤 스미스의 "보이지 않는 손". 익숙하지요) 다시 말해서, "이런 기술들은 그 시스템이 애초에 디자인된 방향이 이베이나 냅스터의 네트워크 효과와 어느 정도 비슷한 특징을 가지도록 되어 있는 것이 아닐까" 라고 생각합니다.
2004년 6월 팀은
"Open Source Paradigm Shift" 라는 글에서 "참여의 아키텍처"에 대해 따로 섹션을 할애하여 자신이 제안한 용어에 대해 어느 정도 구체적인 설명을 시도합니다.(
"Open Source Paradigm Shift"는 웹 2.0의 개념화의 진행 초반에 쓰여진 글로 웹 2.0에 대한 팀의 초기 생각과 그 진화를 전체적으로 엿볼 수 있는 좋은 자료입니다. 일독을 권합니다). ) 그리고, 이후 해당 부분만 떼어서
"The Architecture of Participation"라는 포스트를 블로그에 올립니다. 하지만, 그의 스타일대로 명확한 정의보다는 두리뭉실한 자신의 생각의 흐름과 몇가지 예시를 통해서만 주제를 설명하고 있습니다 (마치 웹 2.0에 대한 설명처럼^^) 여하간 그 안에서, 오픈소스에서 언급된 "참여의 아키텍처"에 사용했던 "참여자"의 개념을 개발자에서 사용자까지 확장시키고, "아키텍처" 의 개념도 컴퓨터 시스템이나 소프트웨어 아키텍처에서, 더 일반적이고 비즈니스적인 의미로 넓혀서 설명합니다. 동시에, 한 두가지 기능의 존재 여부가 아닌, "구조상에 내재된" 의 의미를 더욱 강조합니다.
또 팀은 2004년 10월 1차 웹 2.0 컨퍼런스의 마지막 날 "참여의 아키텍처"라는 제목으로
공개 대화 세션을 마련하여 사람들과 논의해 보려고 합니다. 하지만 패널이나 청중이 아직 팀이 말하고자 하는 바를 구체적으로 정확히 이해하지 못하고 서로 자기가 이해하는 대로 짐작하고 말하는 듯 보입니다. 그래서 대화가 많이 떠돕니다.
또한, 2005년 6월 열린 Where 2.0 컨퍼런스에서도
"참여의 아키텍처"라는 제목으로 야후의 폴 레빈이 프레젠테이션을 하도록 부탁합니다. 하지만, 그도 역시 아키텍처라는 면보다 기능이라는 면에 더 초점을 맞추어 이야기 하여 팀의 생각이 잘 전달되지 못했음을 알게 합니다.
결국 사람들이 팀이 의도하는 바를 정확히 이해하지 못하는 것은 "아키텍처"라는 개념, 즉 "참여하는 아키텍처"나 "참여를 불러오기 위한 아키텍처"가 아니라 P2P와 같이 사람들의 일상적인 사용이 전체 시스템의 가치를 증가시키게 되는 메트칼프의 법칙과 같은 것이 구현되도록 하는 "아.키.텍.처."의 개념인 것 같습니다. 물론 팀과 자주 이야기 하는 존 바텔이나 데일 도허티는 이해할 수 도 있겠습니다만, 결국 사람들의 이해를 구하지 못한 것은 세상에 명확히 자신의 생각을 글로서 전달하지 못한 팀의 잘못도 크다고 하겠습니다.
어쨌든, 말이 너무 쉬워서 그렇다고 생각했는지 팀은 2005년 2차 웹 2.0 컨퍼런스에서부터는 "Architecture of Participation" 대신 "Harnessing Collective Intelligence"라는 말을 더 많이 쓰고 있습니다. 그리고, 개념도 조금 더 진화한 것 같습니다.
그래서, 결국 참여의 아키텍처란...
사용자의 공헌을 위해 디자인된 시스템이 가지는 본질적인 속성입니다. ^^
(죄송합니다. 꾸벅)
너무 긴 글은 역시 블로그 포스트에는 잘 안맞나 봅니다. 여기까지 쓰고 제가 읽어보아도 너무 장황하군요.
그래서 따로 문서를 준비 했습니다. 읽어보시기 바랍니다.
[
"참여의 아키텍처" PDF 보기]
