나의 노트

위키를 통한 탐험

Exploring with Wiki

번역 워드 커닝햄(Ward Cunningham)과의 대담, 1부 빌 베너스(Bill Venners) 작성 2003년 10월 20일 www.artima.com/articles/exploring-with-wiki ↗

요약 워드 커닝햄이 빌 베너스와 함께 협업적 탐험을 위해 위키(Wiki)를 사용하는 방법과 위키 작성자와 독자 간의 트레이드오프(상충 관계)에 대해 이야기합니다.

소프트웨어 커뮤니티에서 워드 커닝햄은 아이디어의 원천으로 정평이 나 있습니다. 그는 객체 발견을 돕는 기법인 CRC 카드를 고안했습니다. 또한 소프트웨어 패턴의 발견과 문서화를 돕기 위해 세계 최초의 웹 기반 협업 저작 도구인 위키를 발명했습니다. 가장 최근에 커닝햄은 익스트림 프로그래밍(XP)의 여러 기법에 주된 영감을 준 인물로 꼽힙니다.

2003년 9월 23일, 빌 베너스는 덴마크 오르후스에서 열린 JAOO 컨퍼런스에서 워드 커닝햄을 만났습니다. Artima.com에 여러 회에 걸쳐 연재될 이 인터뷰에서 커닝햄은 위키와 익스트림 프로그래밍의 여러 측면에 대한 통찰을 제공합니다. 이번 첫 번째 연재분에서 커닝햄은 협업적 탐험을 위한 위키의 사용과 위키 작성자와 독자 간의 트레이드오프에 대해 논의합니다.

왜 위키인가? (Why Wiki?) 빌 베너스: 위키를 만들 때 어떤 목표를 가지고 계셨나요?

워드 커닝햄: 위키를 만들 때 달성하고 싶은 몇 가지가 있었습니다. 첫 번째 위키의 구체적인 목적은 서로의 경험을 연결하여 프로그래밍의 패턴 언어(pattern language)를 발견할 수 있는 환경을 만드는 것이었습니다. 저는 이전에 같은 목표를 달성하기 위해 설정된 하이퍼카드(HyperCard) 스택 작업을 한 적이 있습니다. 사람들이 그 하이퍼카드 스택에서 읽고 쓰는 것을 좋아한다는 걸 알았지만, 그건 단일 사용자용이었습니다. 우리가 PLoP(Pattern Languages of Programming) 컨퍼런스 시리즈를 시작하고, 우리가 정말 하고 싶은 일이 새로운 문헌을 만드는 것임을 깨달았을 때, 저는 그 하이퍼카드 스택을 웹으로 옮겨올 방법을 찾아야겠다고 결심했습니다.

위키에 대한 더 일반적인 목표들도 있었습니다. 첫째, 저는 '말하기'에는 사람을 끌어당기는 본질적인 힘이 있다고 생각합니다. 사람들은 이야기하는 것을 좋아합니다. 위키를 만들면서 저는 우리 모두에게 내재된 그 스토리텔링 본능을 북돋워 주고 싶었습니다. 둘째, 어쩌면 가장 중요한 것인데, 평소라면 글을 쓰지 않았을 사람들이 편안하게 글을 쓸 수 있게 함으로써, 그들이 하려는 이야기의 구조를 우리가 발견할 기회를 만들고 싶었습니다.

빌 베너스: 위키의 어떤 점이 글쓰기를 편안하게 만드나요?

워드 커닝햄: 글쓰기에 익숙하지 않은 사람에게 어떤 아이디어가 떠올랐는데, 그게 딱 한 문단 정도의 분량이라고 해보죠. 잡지에 사설을 쓴다면 한 문단은 너무 짧습니다. 잡지에 글을 쓰려면 맥락을 설정하고, 중요한 내용을 말하고, 다양한 사람들이 이해할 수 있는 방식으로 서술한 뒤, 결론을 맺어야 합니다. 그건 대부분의 사람이 투자하고 싶은 노력 이상을 요구합니다.

하지만 다른 사람의 글을 읽다가 "맞아, 하지만 다른 관점도 있어"라는 생각이 들 때, "글쎄요, 맞아요. 하지만 사실 이런 점도 있습니다"라고 한 문단을 덧붙일 수 있다면 어떨까요? 위키에는 "맞아요, 하지만..." 식의 반론이 엄청나게 많습니다. 토론 그룹(게시판)에서도 같은 일이 일어나지만, 토론 그룹에서는 그 모든 내용이 묻혀버립니다.

빌 베너스: 왜 토론 그룹에서는 내용이 묻혀버리나요?

워드 커닝햄: 내용을 따라갈 수가 없기 때문입니다. 맥락이 없어요. 토론 그룹은 사람들이 이전에 했던 말을 잊어버리기 때문에 같은 내용을 계속해서 반복하는 경향이 있습니다. 저는 자주 묻는 질문 모음인 FAQ의 발명이 이에 대한 대응이었다고 생각합니다. 많은 경우 토론 그룹에 참여하는 것보다 그냥 FAQ를 읽는 게 더 가치 있습니다. 제가 처음 위키를 만들 때 FAQ-O-Matic이라는 시스템이 있었는데, 위키와 같은 아이디어였지만 실제로는 FAQ를 만드는 데 초점이 맞춰져 있었습니다. 그걸 보고 "그래, 같은 아이디어네"라고 생각했습니다. 하지만 곧 "아니야, 나는 질의응답 형태보다 문서 지향적인 형태를 더 선호해"라고 생각했죠. 우리가 문헌으로 만들려고 했던 패턴들은 FAQ와 비슷했지만, 그 이상이 될 수 있었습니다. 지금 위키에는 아마 10,000개에서 15,000개의 패턴이 25,000개의 페이지에 걸쳐 기록되어 있을 겁니다.

빌 베너스: 위키의 좋은 적용 사례는 무엇이라고 생각하나요? 위키는 어디서 가장 빛을 발하나요?

워드 커닝햄: 위키는 쉽게 제기할 수 없는 질문에 답하려고 할 때, 즉 알아야 할 내용에 대해 미리 알려진 자연스러운 구조가 없을 때 가장 잘 작동합니다. "프로젝트가 어떻게 돌아가고 있는가?"와 같은 질문을 위해 데이터베이스를 설계할 수도 있습니다. 하지만 우리가 데이터베이스에 어떤 필드를 넣든, 결국 그 필드들은 프로젝트 진행 상황에서 중요하지 않은 것들로 판명 날 겁니다. 프로젝트에서 중요한 것은 예상하지 못한 것들이니까요.

위키 페이지는 매우 자유로운 형식입니다. 위키 전체에 걸쳐 하이퍼텍스트 구조가 있지만, 특정 페이지 내에서는 당신이 구사할 수 있는 자연어의 융통성 안에서 필요한 말은 무엇이든 할 수 있습니다. 그래서 위키는 프로젝트 상태를 추적하는 데 좋은 방법입니다. 예를 들어 우리의 패턴 작업을 하나의 장기 실행 프로젝트라고 생각할 수 있습니다. 우리는 목적지가 어디인지 몰랐지만, 진행하면서 그 과정을 포착하고 싶었습니다.

또한, 위키는 시스템 사용자에게 제어권을 위임하는 것이 편안한 환경에서 가장 잘 작동합니다. 위키에는 누가 언제 무엇을 할 수 있는지에 대한 로직이 별로 없습니다. 위키는 당신이 무엇을 하는지 실제로 이해하지 못하기 때문입니다. 그저 당신을 위해 페이지를 보관할 뿐이죠. 적절한 사용법에 대한 많은 관례가 확립되지만, 그것들은 애플리케이션의 비즈니스 로직이 아니라 사용자들의 마음속에 존재합니다. 이는 컴퓨터가 어떤 행동을 강제하기를 기대하지 않는, 신뢰하는 커뮤니티가 있다면 잘 작동합니다. 가끔 위키가 기업 환경에 적합한지 질문을 받곤 합니다. 저는 직원들을 신뢰할 만큼 단합된 기업도 있고, 분명 그렇지 않은 기업도 있다고 생각합니다. 웹 사이트를 유지 관리할 수 있도록 직원들을 신뢰하지 않는 기업이라면 위키 말고 다른 것이 필요할 겁니다.

큰 그림 파악하기 (Getting the Big Picture) 빌 베너스: 독자는 위키에 있는 모든 내용에 대한 큰 그림을 어떻게 파악하나요?

워드 커닝햄: 먼저 이해해야 할 점은, 우리가 작성자에게 위키를 더 쉽게 만들었기 때문에 실제로는 독자에게 더 어렵게 만들었다는 것입니다. 조직화가 되어 있고 개선될 수도 있지만, 고도로 조직화된 것은 아닙니다. 그래서 독자가 느끼는 기분은 정보의 조각을 찾아 황무지를 헤매는(foraging) 것과 같습니다. 훌륭한 정보를 우연히 발견하면 "이거 환상적인데, 누군가 훌륭한 조각들만 모아서 리스트를 만들어 주면 나머지는 안 봐도 될 텐데"라고 말하게 되죠. 다시 말해, "내 질문에 대한 답을 빨리 찾을 수 있게 누군가 이것 좀 정리해 주면 안 되나?"라고 생각합니다. 그러다 조만간 그들은 "이런, 내가 할 수도 있겠네"라고 깨닫습니다. 그들은 한두 달 동안 관심 있는 내용을 찾고, 위키의 구조에 대한 자신의 견해를 담은 페이지를 만듭니다.

저는 분류(classification)를 좋아하지 않습니다. 가장 흥미로운 것이 틀에 맞지 않는 것, 예상치 못한 것일 때 유용한 분류 체계를 만드는 것은 매우 어렵습니다. 하지만 어떤 사람들은 모든 페이지에 분류가 있어야 한다고 결정했습니다. 그들은 페이지 이름을 기반으로 위키의 분류 구조를 확립하는 체계를 고안했습니다. 그리고 분류를 중요하게 생각하는 사람들이 이것을 유지 관리합니다. 누군가 페이지를 작성하고 분류를 하지 않으면, 다른 누군가가 "아, 이건 위키 유지보수나 디자인 패턴으로 분류해야 해"라고 말합니다.

빌 베너스: 페이지를 '위키 유지보수'로 어떻게 분류하나요?

워드 커닝햄: 그냥 'WikiMaintenanceCategory'라는 이름의 페이지에 대한 링크(참조)를 만듭니다. 그 링크를 클릭하면 해당 카테고리와 그 카테고리가 존재하는 이유를 설명하는 페이지로 이동합니다. 즉, 페이지를 카테고리에 넣으려면 카테고리를 설명하는 페이지에 대한 링크를 넣는 것이 관례입니다. 그러면 그 페이지는 태그가 붙은 셈이 됩니다. 카테고리가 무엇인지 이해하고 싶으면 카테고리 페이지로 가는 링크를 따라가면 됩니다. 그 카테고리에 어떤 페이지들이 있는지 보고 싶으면, 그 카테고리 페이지를 참조하는 모든 페이지를 검색하면 됩니다.

빌 베너스: 검색은 새로운 위키를 탐색하기 시작하는 한 가지 방법이겠군요. 어떤 면에서 위키는 인터넷의 아주 작은 축소판 같습니다. 모든 것이 여기저기에 흩어져 있으니까요. 내가 찾는 것을 어떻게 찾을까요? 키워드 검색으로 시작할 수 있겠네요.

워드 커닝햄: 맞습니다. 사람들은 이름이 "Category"로 끝나는 모든 위키 페이지는 검색할 가치가 있는 검색어라고 정했습니다. 구글에서 소설을 검색할 때, 사람들이 자신의 작품에 '소설'이라는 라벨을 붙이지 않았다면 찾지 못할 수도 있습니다. 카테고리 시스템은 카테고리의 근거를 설명하는 페이지들의 집합이며, 당신은 그 페이지들을 읽을 수 있습니다. 그들은 네임스페이스(이름 공간)의 작은 부분, 즉 "Category"라는 단어로 끝나는 모든 단어를 가져와서, 그 페이지들이 다른 페이지들의 범주에 대해 이야기한다는 선례를 확립했습니다. 훌륭합니다. 균형이 잡혀 있어요. 제가 해결책을 공학적으로 설계하려 했다면 이렇게 간단하거나 훌륭하지 못했을 겁니다. 그리고 제가 정말 마음에 드는 점은, 카테고리의 집합이 무엇인지 관리하는 활발한 커뮤니티가 있다는 것입니다. 때때로 그들이 카테고리를 잘못 설정하기도 하지만, 이내 수정합니다.

위키의 시간적 요소 (The Temporal Element of Wiki) 빌 베너스: 설명해주신 내용은 브레인스토밍을 떠올리게 합니다. 명확하게 보이지 않는 무언가를 구체화하기 위해 사람들을 모으는 것이죠.

워드 커닝햄: 위키는 브레인스토밍의 느낌이 있긴 하지만, 그렇게 상호작용적이지는 않습니다. 10분간 브레인스토밍하고, 30분간 그 결과물을 분석해서 45분 만에 무언가를 얻을 수 있습니다. 위키의 속도는 더 느립니다. 아이디어 하나에 대한 페이지를 쓰거나, 여러 아이디어 뭉치에 대한 페이지를 쓸 수도 있습니다. 그리고 일주일 뒤에 와서 그 페이지가 어떻게 발전했는지 볼 수 있습니다. 하지만 15분 뒤에 다시 온다면 별일 없을 겁니다. 위키에서는 며칠이나 몇 주 단위로 일이 일어납니다. 사람들은 하루나 일주일 단위로 훑어보는 경향이 있기 때문입니다.

위키에는 흥미로운 시간적 요소가 있습니다. 뉴스 그룹이나 이메일 리스트를 읽으면, '지금 당장'은 리스트에서 당신의 위치에 있는 것입니다. 그리고 뒤처지면 따라잡기 힘듭니다. 저는 위키에 연대기가 존재하는 것을 원치 않았습니다. 위키에서 무언가를 읽을 때, 그것이 1년 전에 쓰였든, 하루 전에 쓰였든, 방금 전에 쓰였든 독자에게 중요하지 않기를 바랐습니다. 이는 맥락을 파악할 어떤 방법이 필요하다는 것을 의미했습니다.

만약 당신이 페이지 하나를 쓴다면, 그 페이지는 다른 무언가에 대한 반응이어야 합니다. 그래서 문단 안에 이 페이지가 다른 모든 페이지의 맥락 속에서 무엇에 관한 것인지 설명합니다. 사람들은 그 페이지 이름들에 매우 익숙해집니다. 새로운 페이지를 발견하고 맥락 페이지들로 연결된 링크가 있는 문단을 읽게 되겠죠. 이미 그 페이지들을 안다면 계속 읽을 것입니다. 모른다면 "아, 이 페이지는 말이 안 되네. 저 다른 페이지들을 읽고 와야겠어."라고 할 겁니다. 즉, 맥락을 안다면 찾아볼 필요가 없습니다. 하지만 맥락을 모른다면 가서 읽으면 됩니다. 맥락은 그 자리에 계속 있으니까요.

빌 베너스: 위키 사이트를 좀 알아가야 할 것 같군요. 시간을 보내면서 익숙해지는 거죠. 처음 들어가서 독자를 위해 정리되지 않은 채 여기저기 흩어져 있는 것들을 보면 꽤 어리둥절하고 유익하지 않을 수도 있겠습니다.

워드 커닝햄: 맞습니다. 위키는 항상 정리되는 과정 중에 있습니다. 하지만 정리하는 데 1시간을 쓰면, 새로운 자료를 추가하는 데 2시간이 쓰입니다. 그래서 위키의 현상 유지 상태는 항상 '부분적으로 정리된' 상태입니다.

위키와 가독성 (Wikis and Readability) 빌 베너스: 저는 위키라는 아이디어를 정말 좋아하지만, 많은 위키 페이지를 읽기가 어렵습니다. 가독성 문제는 제가 Artima.com에 위키를 도입하지 않은 주된 이유입니다. Artima.com도 일종의 웹 기반 협업 문서이지만 더 구조화되어 있습니다. 위키에는 독자를 위해 자료를 정리해주는 단일 편집자가 없습니다. 모든 페이지가 협업으로 만들어집니다. 구조도 협업이고, 편집도 협업입니다. 가독성이라는 트레이드오프를 감수할 만큼 위키의 협업에서 얻는 것은 무엇입니까?

워드 커닝햄: 위키 독자로서 얻는 것은 이전에는 목소리를 낼 수 없었던 사람들에게 접근할 수 있다는 점입니다. 우리가 목소리를 부여하는 사람들은 컴퓨터 프로그램을 작성하고 출시(ship)하는 것이 어떤 것인지에 대한 본능적인 감각을 가지고 있습니다. 우리 업계는 출판물에서 특정 전통을 존중합니다. 예를 들어 과학 저널에 기고하려면 동료 검토(peer review)를 거쳐야 합니다. 동료 검토의 일부는 다른 모든 문헌에 익숙해야 한다는 것입니다. 그런데 그 '다른 문헌'들이 어쩐지 현실과 동떨어진 방향으로 흘러가 버렸습니다. 프로그래밍에 대해 쓰인 글들은 현업 프로그래머들이 느끼는 바와 일치하지 않았습니다. 위키를 통해, 문헌을 통달할 시간이 없고 읽힐 만한 저널에 칼럼을 실을 시간도 없는 현업 프로그래머들이 자신에게 중요한 이야기를 할 수 있는 공간을 갖게 되었습니다. 위키는 다른 관점을 제공합니다. 사실 누군가가 자신의 개인적 경험에서 우러나와 위키에 글을 쓰고 있는지, 아니면 최근에 읽은 내용을 인용하고 있는지 구별할 수 있습니다.

빌 베너스: 어떻게 구별하죠?

워드 커닝햄: "메리 앤은 이 부분을 도저히 제대로 작동시킬 수 없었어"와 같은 이야기를 하는지 보면 알 수 있습니다. 과학적 전통에는 없는 화법이죠. 누군가 저자를 인용하며 "아무개 씨가 이러이러하다고 말했는데, 당신들이 듣지 않는 건 어리석은 거야"라고 한다면, 그는 책을 숭배하는 사람입니다. 반면에 누군가가 "있잖아, 지난 세 번의 프로젝트에서 이걸 시도해봤는데 한 번도 성공한 적이 없어. 제품을 출시하려면 항상 억지로 다른 방법을 써야만 했어"라고 말한다면, 그 사람은 제품을 출시해본 사람이고 저에게 뭔가 심오한 이야기를 해주는 것입니다. 그것을 어떻게 해석할지는 제 몫입니다. 그건 그저 그의 경험이니까요. 그러고 나서 "맞아, 나도 그랬는데 우리는 이런 다른 방법으로 해결했어"라는 문단을 몇 개 더 볼 수도 있습니다. 자, 이제 제품을 출시하는 두 가지 방법이 생겼습니다. 갑자기 당신은 소프트웨어 출시에 대해 '이야기만 하는' 사람이 아니라, 실제로 소프트웨어를 '출시하는' 사람들과 대화하게 되는 것입니다. 이것은 아주 큰 차이입니다.

다음 주 10월 27일 월요일, 버트란드 마이어(Bertrand Meyer)와의 대담 첫 번째 편을 보러 오십시오. Artima.com의 새 기사 알림을 매주 이메일로 간단히 받아보고 싶으시면 Artima 뉴스레터를 구독하세요.