주제별 포럼 - 위키
일단 가장 기본이 되는 '위키'가 뭐하는 놈인지 부터 정리해 두었습니다. 다음 문서로는 알려져 있는 위키의 클론과 그들의 특징, 위키모듈 개발을 위한 ZBXE와 위키의 접점을 한번 짚어보겠습니다.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1. 위키의 이해
1.1. '위키'의 이해를 도울 수 있는 몇가지 URL링크
[ 야후 지식에서 찾은 위키의 정의 ]
[ 엠파스뉴스를 검색 한 결과 ] - 한겨레 21에 개제되었던 내용으로 보이는데, 현재까지는 '위키'를 가장 잘 설명하고 있는것으로 보임
1.2. 국내에서 가장 오랫동안 운영되어온 위키사이트인 '노스모크'의 몇가지 문서 링크
[ 위키는 시스템이다 ]
[ 위키는 살아있다 ]
[ 위키에 대한 오해 ]
[ 위키사용의 세가지 양태 ]
2. 위키의 특징
2.1. 공동 작성/편집
- 편집권한을 가진 모든 사람이 달려들어 하나의 문서를 만든다는 점. 기존의 웹보드는 문서를 처음 작성한 사람이나 관리권한을 가지고 있는 사용자가 게시물의 내용을 수정, 편집하는 방식으로 대부분 게시물이 등록되면서 '어느정도 완성된 문서'의 형식을 띄는데, 위키의 경우 어떤 이슈에 대한 페이지가 생성되면 복수의 사용자가 해당 이슈에 대한 내용을 채워나간다는 점이 다르다. 이것은 WEB2.0의 개념 중 '집단지성'과도 연관이 있다고 생각되는데, 가장 성공적인 사례가 위키피디아(http://wikipedia.org) 이다.
(덧: 편집권한과 관련하여) 초기의 위키는 '권한'에 대한 정의가 없이 모든 사람의 참여를 유도하는 방향으로 만들어졌지만, 최근에 들어 ACL과 같은 강력한 권한관리가 도입되고 있는 실정이다.
2.2. 느슨한 컨텐츠간 구조 (자기조직화)
- 웹보드의 경우 정렬(sort)방식에 따라 약간씩 다르지만 대부분 새롭게 포스팅 된 게시물이 상단을 차지하고 기존의 게시물이 아래로 밀려내려가는 형태를 띈다. 개인 blog나 특히 미투데이와 같은 시간에 연관된 '로깅'의 경우 이것이 가장 잘 어울리지만, 라이브러리와 같은 경우엔 약간 무리가 있다고 생각된다. (물론 운용의 묘를 살려서 웹보드로도 라이브러리를 구성하고 있는 경우도 많이 있다) 위키의 경우 보통 FrontPage라고 불리우는 하나의 페이지가 있고 이 페이지에서 다른 페이지를 내부링크를 통해 느슨한 형태로 연결된다. (이것은 많은 수의 위키가 DBMS를 사용하지 않는것과도 연관이 있는것으로 보인다) 즉, 어떤 주제와 해당하는 하위주제들을 작성했다면 주제페이지 하단에 하위주제들의 링크를 달아놓고 주제페이지의 링크를 FrontPage에 달아놓음으로써 (물리적이지 않은)트리구조가 만들어지는 셈이다. 이것은 시간에 무관한 상태로 A/B/D/E 순서로 쌓여있는 링크모음의 한가운데에 C의 주제를 적은 페이지 링크를 끼워넣을 수 있기 때문에 웹보드의 리스팅구조에 비해 느슨하게 구성된다.
2.3. 버젼컨트롤
- 공동편집을 위한 기능으로 해당 페이지의 버젼과 이전버젼의 히스토리를 가지고 있다. 가장 단순한 기능으로는 잘못 작성되거나 편집된 부분을 이전버젼으로 돌아가 바로잡을 수 있다는 점이다. 이외에 해당문서의 버젼컨트롤은 여러가지로 큰 의미를 지니고 있다. 위키의 버젼컨트롤은 RCS / CVS 와 같은 툴을 사용하거나 자체적으로 만들어진 모듈을 통해 이루어지고 있다.
3. 위키의 가능성
위키의 가능성은 '협업과 분업의 자유'와 함께 문서작성을 통해 쌓인 결과물이 '자기조직화'를 통해 하나의 라이브러리를 이루게 된다는 점이다. 이러한 특성으로 인해 주로 기획이나 개발과 같이 '어떤 목적을 설정하고 그것을 세워 나가는 공동작업'에 적합하며 각 문서를 잘 연결하면 해당 주제와 컨텐츠의 가치를 높힐 수 있기 때문에 위키를 WEB 2.0의 한 주역으로 보는 시각이 많이 있다.
4. 알려진 위키 클론들
3.1. 모인모인 - 국내에서는 '노스모크'가 moinmoinwiki를 자체적으로 변경하여 사용하고 있다.
3.2. 미디어위키 - 위키피디아에서 사용하고 있는 위키시스템
3.3. 모니위키 - 개인위키로 많이 알려진 위키
3.4. wikiX - php기반으로 만들어진 위키 DBMS(MySQL)를 사용하는것으로 알려져 있다.
3.5. dokuwiki - 최근 각광받는것으로 알려진 위키시스템
3.6. springnote - 위키를 기반으로 한 서비스.
이외에도 기본이 되는 '위키'는 구현자체가 까다롭지 않기 때문에 수많은 종류의 클론을 가지고 있다.

지금, 언제나 사진에 목마른, 부족한 자신에 좌절하며 도전하는 쌈마이.
길스튜디오 실장 (http://gilstudio.co.kr)
핫셀클럽 운영자 (http://hasselclub.net)
게시판 생성하듯 위키를 생성하면 각각이 하나의 seed로 시작하는..
seed페이지에서 각 문서들의 list up을 하는게 일반적인데 이 방식을 조금더 쉽게 구조화한 것이 스프링노트의 구조인 것 같구요.
개인적으로 위키가 가지는 협업/분업을 위한 공동편집/버전관리등의 기본 기능의 구현이 된다면 여러모로 정말 쓸만할 것 같습니다.
좋은 이야기들 기대합니다. ^^
'집단지성'자체는 훌륭한 것이지만 방향성을 가지지 못한다면 그 자체가 어떤 방향을 포함한 힘(벡터)로 작용하지 못하고 '엔트로피'만으로 끝난다는 점이 위키피디아에서 있었던 일련의 문제들(특정집단이 자신의 이익에 맞도록 위키피디아를 수정하거나 하는 문제)또한 시사하는 바가 있는것 같습니다. 모든 시스템의 설계나 기획에서 생기는 '과연 사용자를 얼마나 믿을것인가'에 대한 고민도 다시금 머리를 들고.. raysoda.com 운영자의 고뇌(추천시스템의 구조적인 문제를 발견하고 괴로워하시더군요.. 추천에 의해 메인페이지에 게시하고 많은 사람들이 보게 하는 구조가 처음엔 집단지성의 실행으로 보였지만 나중에 인맥을 이용한 '붐업-_-' 과 같은 부작용들 때문에 결국 이 부분이 중단된 상태입니다) 가 떠올라서... 물론 대장장이가 만든 칼이 사람을 죽이건 음식을 만들건 대장장이에게 책임을 지울 수 없지만 미리 해 둘 필요가 있는 고민으로 생각되네요.
현재 가장 고민하는 것은 이러한 위키의 이용양태와 함께 위키 그 자체를 ZBXE의 그릇안에 담을 것인가, 아니면 위키의 특성중에서 일부분을 가져올 것인가 하는 점입니다. 욕심이라면 그 자체를 담고 그것을 우리 실정에 맞도록 고치면서 동시에 가이드라인을 제시하는 것인데.. (구현에 대해서는 전혀 걱정하지 않고 있습니다만) 그것만으로 어마어마한 일거리들이 기다리는듯한 예감에 뒷목이 뻣뻣해지네요.. =_= 전문기획자도 아니고 한때 끄적거렸던 가락에 덤벼들어서 무대뽀정신을 발휘하는 중인데.. ^^;;;;
아무튼 꾸준히 이런저런 이슈들을 물어오겠습니다.. >_<



