개인적으로 사용하시는 wiki 엔진은 어떤것들을사용하시나요??

nettism의 이미지

안녕하십니까??

항상 그리고 스스로 자료라는것을 찾기 시작하면서, 그리고 인터넷환경으로 넘어오면서, 넘쳐나는 자료를 내 품안에 두고픈 욕망이 꿈틀대고 있습니다..

물론 먼저 카테고리를...나만의 카테고리를 확립하는것이 더욱 중요하겠지요...

카테고리는 잡았다고 하고, 이제 그 정리상의 문제를 생각해 보고싶습니다..

다를 나름의 디렉토리 구조 위에 나름의 정리를 하고 계실테지만요...

제가 여쭙는것은, 혹시 이 자료 정리에 wiki라는 방식을 사용하시는 분이 계시면, 어떤게 쓰시면서 좋았는지와...추천하는것들을 여쭙고 조언을 받고자합니다..

필요한 기능을 분류하자면 아래와 같겠습니다.

1. OS : Linux
2. network : 개인 PC에서 설치가 용이하고, 외부에서 접근이 가능할 것
3. 검색 : 저장되어 있는 자료에 대한 검색이 용이할 것
4. 백업 : 주기적 혹은 랜덤한 주기로 데이터에 대한 백업이 용이할 것
5. 구조 : 유연한 구조를 가지고 있어서, 후에 구조 변경등의 작업이 용이할 것.

일반론적으로 필요한 기능을 열거하자면, 저 정도가 될것 같습니다. 물론 저건 위키에 국한된 내용은 아닙니다만, 저 다섯가지중에서 위키가 포용할 수 있는 부분은 어디까지일것이며, 위키에다가 무엇을 추가하면, 상기의 기능을 다 구현할 수 있을까요??

기존에는 그냥 제 윈도우즈 피씨에 설치해 두고, 공유 프로그램을통해서 원격지에서 공유하는 방식을 취했습니다..

조언 부탁드립니다..

감사합니다..

익명사용자의 이미지

http://www.wikimatrix.org/ 를 참고해 보시길 바랍니다.
물론 여기에는 국내에서 비교적 많이 쓰이는 wikiX등은 없습니다만, 모니위키는 있습니다.

hanbyeol의 이미지

'넘쳐나는 자료를 내 품안에 두고픈 욕망'과 '나만의 카테고리를 확립하는것' 목적을 위해 자료 관리와 정리하는 수단으로서 위키를 적극 권해드리고 싶습니다. 반면 두 목적을 위해 자료를 분류하고 정리하는 그 자체에는 좀 회의적인 생각이 듭니다.

학문적 차원이나 반드시 분류를 해서 자료를 관리해야만 한다면 어쩔 수 없겠죠. 그러나 ...
자료를 정리하는 시간에 더 유용한 자료가 생겨납니다. 정리된 자료는 사용 빈도와 유용성 등에서 새로운 자료보다 가치가 떨어집니다. 기존 자료를 보관하느라 정력과 시간을 쏟느니 기존 자료를 더 자신의 것으로 만드는 것(머리속에 두는 것 등)이나 더 가치 있는 자료를 찾는 것이 더 낫다고 봅니다. 꼭 모아야 하고 관리를 해야한다면, 최소 관리비용으로 최대 결과를 얻는 - 관리하지 않는 관리법을 사용하는 걸 권하고 싶습니다.

수많은 자료를 제대로 분류하다 보면 골치 아픈 경우가 있습니다. 어디에 넣을지 애매한 것이 있습니다. 박쥐문제라고 합니다. 또한 설렁설렁 분류하거나 분류 기준이 모호하거나 범주가 넓으면 나누어야할 경우에도 한데 섞어서 찾을 때도 헤매게 되는 일이 생겨납니다. 쓰레기문제라고 할 수 있습니다. 결국 분류수준은 박쥐문제와 쓰레기문제라는 각 비용을 적절하게 균형을 맞추는 수준에서 결정하는 게 경제적입니다.

구글에서는 분류 기준에 따라 자료에 접근하는 방법을 제공하지 않습니다. 다만 사용자/고객이 원하는 최적의 검색 결과를 제공하기 위해 노력합니다. 분류 무용론은 아니지만, 분류를 했을 때 도움되는 측면이 있습니다. 사람이 직관적으로 내용을 파악할 수준이라면 적절한 방식으로 분류해서 자료를 찾을 수 있다면 - 네비게이션 차원에서 꽤나 유용합니다. 그러나 자료량이 어느 수준을 넘어가면 분류의 단계도 많아지고 범주가 폭넓어져서 네비게이션으로는 자료 접근이 불가능해질 수 있습니다. 백억페이지가 훌쩍 넘어갈 인터넷 페이지를 분류체계로 찾아갈 수 없듯이.

저는 자료 관리에 골머리를 앓다가 초정리법을 알게 되었습니다. 분류하지 않고 시간순으로 자료를 정리하는 아주 간단한 원칙으로 아주 훌륭한 자료 관리 방법을 제시합니다. 사무실 책꽂이에 쌓였던 수많은 자료를 단박에 정리해버렸습니다. 아래 링크에서 사용자 리뷰에 초정리법이 잘 요약되어 있습니다.

http://www.aladdin.co.kr/shop/wproduct.aspx?ISBN=8912520830

위키를 알고 나서 위키로 초정리법을 적용할 수 있겠다 싶어 바로 제 사이트를 위키로 엎어버렸습니다. 위키는 아마 4년여전에 노스모크( http://no-smok.net ) 통해 알게되어 MoinMoin으로 시작했습니다. 그 뒤 MoniWiki로 갈아타서 아주 고마워하면 몇년간 계속 쓰고 있습니다. 많은 위키클론이 있지만 지금 MoniWiki를 고집하고 있는 이유가 있습니다. 제 위키로 책목록을 정리하고 있습니다. 모니위키가 알라딘과 연동할 수 있습니다. 제가 책 대부분을 알라딘에서 사고 있어서 ...

위키는 구슬이 서말이라도 꿰어야 보배라는 말처럼 여러 정보와 지식을 연결시키는 데 좋은 수단이 되더군요. 한번 글을 쓰고 나면 내용이 변경될 일이 별로 없는 게시판이나 블로그와 달리 위키 페이지는 계속 업데이트하기 편하고 관련있는 자료(페이지)와 연동하기 쉽습니다. 단편적인 정보에서 연결되어 가치사슬을 만들어 지식으로 진화할 수 있는 위키의 개념이 무척 마음에 듭니다.

저는 아주 뻔한 주제를 갖는 자료(페이지)만 분류합니다. 단편적인 정보나 자료는 일단 분류없이 넣어 두고 유사한 자료들이 모여서 주제를 구성할 수 있거나 묶음으로 만들 필요가 생기면 분류를 하는 방식을 채택하고 있습니다. 분류체계에서 자료를 나누는 게(top down) 아니라 역으로 bottom up 방식을 따릅니다. 위키에서도 블로그나 다른 Web 2.0에서 도입하고 있는 태깅방식처럼 분류하지 않고도 묶음(카테고리)를 만드는 사용할 수도 있으리라 봅니다.

모니위키는 KLDP에서 사용하고 있기도 하고 우리나라에 사용자들이 꽤나 됩니다. 많은 위키 가운데 어떤 걸 선택해도 목적하신 바에 부합하게 위키를 사용한다면 소기의 결과를 얻을 수 있다고 봅니다.

개인위키를 사용하는 곳을 방문해 보시면 많은 도움이 되지 않을까요?
http://moniwiki.sourceforge.net/wiki.php/MoniWikiSites

feanor의 이미지

저는 MoinMoin을 사용하다가 현재는 MediaWiki를 사용하고 있습니다. 둘 모두 추천해드릴만한 훌륭한 위키 엔진입니다.

ktd2004의 이미지

음.. 저도 MoinMoin을 사용하고 있습니다.
그런데 MediaWiki가 계속 저를 유혹하네요..

혹시 MoinMoin에서 MediaWiki로 데이타 변환하는 방법을 알고계시면
알려주시면 감사하겠습니다.

마잇의 이미지

저는 초정리법이라는것은 생소하지만 시간순으로 자료를 정리하는것은 상당히 괜찮은 방법이어서 애용하고 있습니다.

분류별로 폴더를 만들어 집어넣는 것을 그만두고 노틸러스, 탐색기 같은 파일 관리자의 정렬 순서를 시간순으로 해두고 사용중입니다. 열었을때 최근 수정된 파일들이 먼저 눈에 들어올 수 있게 하면 효과적입니다. 이렇게 해두고 모든 파일은 그냥 홈 디렉토리 아래에 다 때려박는거죠. 얼마나 편한지 모르겠습니다. 컴퓨터 성능의 발달로 검색이 일단 쉬워졌기 때문에 이런 방법도 가능하겠습니다.

북마크 같은 것도 분류별 관리는 집어치고 그냥 순서대로 집어 넣습니다. 브라우저 마다 있는 방문 기록을 시간 순으로 보는 것도 좋은 방법입니다.

이런 개념을 다른 정보 관리에도 적용하니 분류로 관리할때의 스트레스와 시간 낭비(박쥐문제라고 언급해주셨네요)가 싹 사라지고 원하는 자료를 찾기도 어렵지 않습니다.

위키도 분류 신경쓰면서 사용하면 은근히 관리할게 많아집니다만 그렇지 않으면 원하는 정보들을 시간 순으로 보기도 좋고 다른 방법들도 제공하므로 괜찮다는 생각이 듭니다.
--
마잇


--
마잇

마잇의 이미지

한별님이 링크하신 초정리법에 대한 소개를 보니 제가 하고 있는 그것과 흡사하군요.

가능한 한군데에
시간순으로
컴퓨터의 검색 능력이 동반되어야 가능

대부분 원하는 자료는 최근의 것부터 훑어 나가면 금세 나오더군요.
--
마잇


--
마잇

nettism의 이미지

저도 폴더의 용도에 따라서 시간순으로 정리하여서 쓸때도 있습니다만, 모랄까요?? 진행형인 작업과 같은 경우에는 시간적인 정렬방식이 아주 편리합니다만...

예를 들어서 백과사전과 같은 개념이라면, 이걸 시간순으로 정리하단는 건 조금 어불성설이지 않을까요??

물론 분류라는게 지극히 개인적이고, 또 개인의 기준이라는게 시간에 따라 변하기 나름인엇기어서 고민이 되는 것이긴 합니다만..

hanbyeol님께선 모든 자료를 시간에 따라 정리하시는요??

만약 그렇게 하셨다면, 그게 현재까지 어떠한 충돌이나, 뒤 엎음이 없이 잘 진행되어오고 있는지 궁금하군요..^^

참...첨언하자면, wiki 엔진들도 시간순으로 정리하는게 가능한건가요?? 구현방법에 따라 다른것인가요??

일신 일일신 우일신


================
일신 일일신 우일신
================

마잇의 이미지

불특정 다수의 다른 사람들과 공동으로 관리, 사용해야 할 자료들이라면 확실히 시간을 기준으로 하는 관리 방법은 단점이 있습니다.

근데 그런 종류의 자료를 관리해야 할 경우가 실제로는 별로 없더군요.

그리고 분류 체계 관리에 끊임없이 주의와 노력을 기울이는 인력이 없으면 무용지물이 되기 십상입니다.
--
마잇


--
마잇

hanbyeol의 이미지

초정리법은 공유를 위한 관리법이라기보다 활용을 위한 개인자료 관리를 위한 방법이라고 봅니다. 종이로된 자료가 넘쳐날 때 초정리법 - 서류봉투에 문서를 넣어 제목을 봉투 가장자리에 써서 사용한 시간순서대로 정리하는 방식을 사용했습니다.

저는 지금은 초정리법의 유용한 면을 사용하지만 모든 자료를 그렇게 정리하지는 않습니다. 원칙은 분명합니다. 제 원칙은 관리하는 시간과 비용을 최소로 하고 가능한 빨리 자료를 찾아쓸수 있게끔 한다는 것입니다. 그 원칙에 따라 자료 유형(문서,파일 등)에 따라서 다음과 같이 정리하고 있습니다.

== 종이문서 ==
종이 문서는 관리를 안 하는 걸 원칙으로 한다. 일정시간 필요할 때까지만 한곳에 쌓아두고 보다가 쓸모없어지만 한번씩 다 갖다 버린다. 사내에서 작성되어 종이로 배포된 것은 가능한 파일로 받아서 보관한다. 종이로 된 거는 이내 outdate되어서 유효성 지나면 버린다. 만약 공문서나 조직단위로 반드시 보관해야할 자료(견적서, NDA, MOU, 계약서 등)는 해당 관리철에다 넣어 둔다. 절대 개인이 소유해서 문서로 책상이 뒤덮히지 않도록 한다. 그다지 중요하지 않거나 1회용으로 참조하고 오래 보관하지 않아도 되는 외부문서는 기안(품의)시 스캔해서 첨부하고 일정 시간이 지나면 버린다.

== 파일 ==
언제든 구해서 참조할 수 있는 자료는 하드에 보관하지 않는다. 참조가 빈번하면 내려받아 저장하고 그렇지 않는 자료는 필요할 때마다 검색해서 보고 끝낸다.

업무유형이나 출처나 프로젝트 등 적절하게 찾아갈 수 있거나 직관적으로 이해할 수 있게 디렉토리 이름을 짓는다. 분류는 심각하게 하지 않는다. 분류는 외우지 않아도 대충 머리에서 이러저러한 업무에 따라 경로를 찾아갈 수 있을 정도로 뻔하디 뻔한 체계나 이름을 갖도록 한다.

팀/부서 단위로 공유해야할 자료는 기안문이나 뭐 그에 준하는 공식 문서함 형태로 해서 조직적으로 배포한다. 파일서버는 엄청나게 신경써서 관리를 하지 않으면 쓰레기로 가득차거나 음악/영화 공유용이 되기 때문에 안 쓴다. 인트라넷/전자결재 시스템에 안 들어갈 수준의 자료는 그냥 필요한 사람에게 메일로 보내서 개인이 알아서 보고 관리하도록 한다.

파일명은 "문서 제목-YYYYMMDD.확장자" 형식으로 쓰고 문서 제목에 해당하는 것은 가능한 길게 써서 키워드로 파일명 검색할 때 걸려들 수 있도록 한다. 경우에 따라서 "문서 제목-v1.0-YYYYMMDD.확장자" 형식으로 버전관리를 하기도 한다.
최신 버전만 해당디렉토리에 나오게 하고 나머지는 그 디렉토리에 old라는 디렉토리를 만들어 옮겨둔다. (실은 문서 갱신할 때면, 파일을 old 디렉토리에다 복사하고 파일 이름에 날짜나 버전을 바꾸고 나서 문서를 읽어서 작업한다.)
\사업계획\2007년 사업계획\2007년 사업계획서-v1.0-20070101.ppt
\사업계획\2007년 사업계획\old\2007년 사업계획서-v0.9-20061231.ppt

== 각종 정보 ==
위키에 올린다.

----
모든 자료가 시간순으로 배열할 필요가 없다고 봅니다. 초정리법은 분류 안 하고 자료를 빨리 찾는 방법으로 시간순으로 자료를 배치하는 것입니다. 최근에 참조한 자료는 가장 가까운 곳에 두는 식입니다. 수년 된 자료까지 참조할 가능성이 거의 없는 것을 책상위에 올려 놓을 필요가 없는 셈입니다.

위키에서는 최근 문서 목록이 나오게끔 되는데 이는 어떤 면에서 초정리법의 원리가 갖은 맥락을 갖습니다. 최근 목록에 안 나오는 거는 이름순, 분류 또는 검색으로 찾아서 보면 됩니다.

lacovnk의 이미지

dokuwiki 사용합니다.

mediawiki가 좋아보이는데, 너무 부실한 아이콘박스(?) 때문에 망설여집니다. 그리고 (최근에 해결되었는지 모르겠는데) 예전에는 namespace 생성이 좀 불편했었고요.

반면 dokuwiki는 (최근에 해결되었는지 모르겠는데) 한글 검색에 문제가 있었습니다.. 인덱서의 문제였던가.. 그랬죠.

저는 생각보다 정리할 자료가 적어서 다행입니다. 델리셔스와 제 개인 위키로 정리하고 있고, 학기마다 자료는 묶어서 보관합니다. 다시 찾을 일이 거의 없거든요.

... 공부를 안해서 그런가 -o-

1day1의 이미지

moniwiki 를 사용하는데, 블로그형식(시간순), 그냥 페이지(?)형식 두가지 형태로 정리합니다.

기본적으로 wiki 는 개인적으로 메모장 처럼 사용합니다.
생각나는 것들을 적습니다.(시간순으로 적기 때문에 나중에 기억하기 쉽더군요.)

그리고, 정리할 자료들은 그냥 페이지 만들어서 적어 놓습니다.
그렇게 페이지를 만들다 보면, 관련되는 페이지들은 상위 그룹으로 묶기도 합니다.
물론 상위카테고리(그룹)을 먼저 나누고 그 하위 내용(페이지)들을 적기도 합니다.

이렇게 정리하다보니, 나름대로 찾기쉽고, 정리가 되는 것 같습니다.
제가 정리한 방법이 다른사람이 보기에도 편해 보이는지는 모르겠습니다.
(지극히 개인적인 내용들이 적혀 있어, 다른 사람들에게 보여주고 확인하기도 뭐하네요. ^^ )

공개된 위키중 잘 정리된 것들을 모아보면 좋을 것 같네요..
혹시 아시는 분 댓글 달아주시면 도움이 많이 될 것 같습니다.

joinc 의 yundream(?) 님도 잘 정리하시는 것 같아요.
http://www.joinc.co.kr/modules/moniwiki/wiki.php/FrontPage

F/OSS 가 함께하길.. (F/OSS서포터즈 : [[FOSS/Supporters]], [[FOSS/Supporters/Group]]) - 블로그 활성화 프로젝트 : 하루에 하나씩 블로그 글 남기기 -

F/OSS 가 함께하길..

문태준의 이미지

문서관리 참 여러운 주제인데 이런 활용방법을 적어놓으니 나중에 참고해야겠네요. 감사~

---------------------------
문태준
http://tunelinux.pe.kr
http://database.sarang.net

---------------------------
문태준
http://groups.google.co.kr/group/sysadminstudy 시스템어드민 공부모임
http://tunelinux.pe.kr
http://database.sarang.net

wkpark의 이미지

보통 한번 익숙해지면 잘 바꾸지 않게 되는게 위키엔진인 것 같습니다.

몇년전까지만 해도 모인모인과 노스모크 변형판 모인모인이 위키엔진으로 가장 많이 쓰였고, 그 자리를 모니위키가 대체한 형국이 되었으며,

MediaWiki는 모인모인과 상당히 유사한 문법을 가지며, 중대규모 위키위키에 적합하고 중대규모 위키에 맞게 다양한 관리기능을 가지며 위키의 한자리를 차지하게 되었습니다.
또 최근에 dokuwiki가 WikiMatrix를 통해 바람을 일으킨 형국입니다.

제가 모니위키를 개발하고 있기때문에 MediaWiki / dokuwiki / pmwiki / 모인모인 모두 써보고 벤치마크를 꾸준히 해보며 각 위키엔진의 장단점을 저울질하며 모니위키 개발에 참고하고 있는데, 각각의 MediaWiki / dokuwiki / pmwiki /모인모인 / 모니위키 이 다섯가지 위키엔진의 장단점을 정리해본다면... (TWiki는 너무 방대해서 솔직히 잘 몰라 제외합니다 :>)

== MediaWiki ==
* 중대규모 위키에 적합 / 유일하게 DBMS사용
* 소스크기: 대 (약 10만줄 이상) / 모듈이 심플하지 않아 확장 어려움
* 느림
* 테마가 많지 않음
* 다양한 관리기능
* 설명서 풍부
== dokuwiki ==
* 중소규모 (flat file) / 자체 버전관리
* 소스크기: 중 (약 2만줄) / 모듈 확장성 용이
* 빠름
* 테마가 비교적 풍부
* ACL 지원및 비교적 다양한 관리기능
* 설명서 풍부
== pmwiki ==
* 중소규모 (flat file) / 자체 버전관리
* 소스크기: 중 / 모듈 확장성 용이
* 매우 느림
* 테마 풍부 / 만들기 쉽다
* 설명서 풍부
== 모인모인 ==
* 중소규모 (flat file) / 자체 버전관리
* 소스크기: 중 / 모듈 확장성 용이
* 보통 속도
* 테마 보통
* ACL 지원
* 설명서 풍부
* WysiWyg 지원 (그러나 매우 미흡함)
== 모니위키 ==
* 중소규모 (flat file) / RCS이용
* 소스크기: 중 / 모듈 확장성 용이
* 빠름
* 테마 보통 / 만들기 쉽다.
* ACL및 비교적 다양한 관리기능
* 설명서 부족
* 개발판에서 WysiWyg 지원

이정도 입니다.

모든 위키엔진들은 사용하다보면 각각 2%씩 부족하며 그 틈새를 공략하는 것이 모니위키의 특징입니다 :>

예를 들자면, 국내 사용자들은 테마 만들기가 쉬운 위키엔진을 선호하며,
기능보다는 예쁜 것을 우선으로 생각합니다. 또 한글을 사용하기때문에 한글 사용에 지장이 없어야 할것이고 (한글 서치 등등), 사용 팁을 얻기 쉬워야 하는 등등.

또 일단 사용에 익숙해 지면 몇가지 기능때문에 계속 처음 선택했던 위키엔진을 쓰게 되더군요. (예를 들어 ISBN기능을 마음에 들어하고, 다른 위키엔진에 그 기능이 없으면 그 기능을 직접 개발하기 보다는, 모니위키를 계속 쓰게 되는 것처럼..)

사용자는 보수적이고, 예쁘고 쓰기 편리한 것을 좋아하고, 여러 기능 보다는 몇가지 주로 쓰는 특별한 기능때문에 계속 쓰고, 그렇게 해서 충성도도 높아지게 되는 것 같습니다.

그런 이유로 모니위키는 더욱 단순하고 쉬워지도록 노력하고 있습니다 :>

다음 버전에 본격적으로 추가될 WysiWyg와 scriptaculous + prototype을 이용한 미려하고 단순해질 UI를 기대해 주세요~

온갖 참된 삶은 만남이다 --Martin Buber

dormael의 이미지

전 아직 위키를 쓸줄 모르고 위키의 좋은점들을 이야기로 많이 듣고 있습니다.
꼭 배워야 겠다고 생각은 하고 있는데 쉽게 접근이 안되네요.

말씀해주신 WysiWyg이 가능해 지는 버전이 나오면 꼭 배워봐야 겠습니다.
기대 만빵입니다. ^^

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

keizie의 이미지

이건 또 무슨 대박 소식이란 말입니까!

wkpark의 이미지

scriptaculous + prototype 도입은 lightbox JS v2와 autocomplete를 구현하면서 기본으로 넣기로
생각을 바꾸었습니다. autocomplete같은 기능은 이미 scriptaculous에 구현되어 있고, 기타 여러 control은 적절히 써먹으면 정말 예쁘더군요 :)

1.1.3을 위해 새롭게 첨가될 기본 테마및 UI에 제안을 주시길~~

온갖 참된 삶은 만남이다 --Martin Buber

익명 사용자의 이미지

이렇게 정리해 주셔서 감사합니다 :")!

익명사용자의 이미지

로그인 기능이 되는 위키가 필요했는데

리눅스는 완전 무식이라서 미디어위키나 모인모인등은 설치중의 에러나

로그인 세팅등의 문제로 포기했습니다.

그런데 도쿠위키는 압축만 풀면 그냥 돌아가더군요. 데이터베이스가 필요없는것도 맘에 들었습니다.

그러나 저만 쓰고 팀원들이 안쓰니까 점점 잊혀지는 분위기...

익명사용자의 이미지

자료는 자꾸 업데이트 되므로 기본적인 리눅스 관련 정보만 따로 폴더 만들어 놓거나
설정파일들은 따로 한테 묶어두는 정도가 좋아 보입니다..
저두 wiki생각 많이했는데 역시 바라마지 않는 이상일뿐인거 같습니다..
번역 하기도 얼마나 시간 걸리는데여..그냥 구글이나 각종 배포판 documentation
등이 훨씬 훌륭합니다..그냥 기본자료만 보관하시는게 좋을꺼 같습니다..
가끔 잘 기억 안나는 명령어는 작은 수첩하나 만들어 각종 중요 에러 및 대처 방법이나
중요 명령어를 간략히 기록해 두는것 만으로 충분하다고 봅니다..
오래되면 다 잊어 버리거든여..감도 잊어버립니다..!!

goforit의 이미지

기본적인 서버 설정이 어렵게 느껴지지 않으면, 개인용 혹은 소규모용으로 Mediawiki 사용을 적극 추천합니다.

저는 개인용 컴퓨터 (MacOS: XAMPP+Mediawik)가 부팅하면 위키가 자동으로 시작합니다.
자료가 복잡해지고 다방면으로 확장되면 이것만큼 자료를 효율적으로 관리 분류하기에 좋은 툴이 없는 것 같습니다. ^^

제가 본,
장점:
#1 플러그인 모듈이 많아, 확장이 용이합니다. 문제가 생겼을 때 관련된 커뮤니티 자료가 많습니다.
- 다른 좋은 위키들도 많습니다. 그런데 문제나 혹은 추가적인 확장이 필요할 때는 가장 범용적인 사용되는 것이 지원받기 용이합니다.

단점:
#1 중소 기업이상으로 사용시 보안상, Access Level을 개인적 설정하기 어렵습니다. 원래 자체가 공개용으로 만들졌기 때문입니다.
#2 플러그인 설치를 일반 유저가 하기에 약간 어려움이 있습니다.

mirheekl의 이미지

그러고보니 요샌 대안이 참 많이 나왔네요. 대표적인 것으로 에버노트가 있겠습니다. 히스토리가 저장되지 않는 게 단점이지만 유료 버전은 히스토리 저장도 되는 것 같더군요. 개인용 자료 저장에는 이런 클라우드 서비스를 사용하는 것이 효율적인 시대가 되었네요.

반드시 위키를 사용해야 한다면 저역시 미디어위키를 추천합니다. 일자무식인 저같은 사람도 오래 걸리지 않고 뚝딱 해서 사이트 구축이 가능하더군요. 디자인이 이쁜 것은 덤이고요.
다만 goforit님이 지적하신 대로 액세스 레벨 지정은 좀 번거로웠던 기억이 납니다.

--

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.