Tag Archives: 정보관리

도쿠위키 설치와 설정

현재 각종 캠페인 위키로 사용하고 있는 도쿠위키를 제가 설치하고 설정한 방법입니다.

0. 필요한 것

– 웹 계정: 우선, 위키를 올릴 계정이 필요합니다. 도쿠위키는 PHP 기반이므로 아파치 (Apache) 등 PHP를 지원하는 웹서버여야 합니다.
– FTP 프로그램: 원격 서버 호스팅이라면 FTP 프로그램이 필요합니다. 저는 파일질라 (FileZilla)를 사용하지만, 알FTP 등 여러 가지 프로그램이 있지요. 최소한 업로드와 권한 설정이 되는 프로그램이어야 합니다.

1. 도쿠위키 받기

도쿠위키 홈페이지에서 도쿠위키 최신 버젼을 내려받아 압축을 풀어둡니다. 직접 올려서 압축을 푸는 방법이 시간이 덜 들지만, 그렇게 했을 때 파일이 누락되는 일을 겪어서 저는 다 풀어서 올리는 편을 선호합니다.

2. 계정에 도쿠위키 올리기

계정의 원하는 폴더에 도쿠위키 파일을 올립니다. 그림과 같이 컴퓨터 쪽에서는 도쿠위키 압축을 풀어둔 폴더로, 사이트 계정 쪽에서는 도쿠위키를 설치할 폴더로 이동한 다음 전부 선택해서 업로드하면 됩니다.

도쿠위키 업로드

파일질라로 도쿠위키를 업로드하는 예


3. 설치하기

업로드가 끝났으면 브라우저로 원격 사이트의 설치 페이지로 이동합니다. 예를 들어 http://lokasenna.pe.kr/testwiki/ 에 설치했다면 http://lokasenna.pe.kr/testwiki/install.php로 들어가면 됩니다.

처음 이 페이지에 들어가면 설치를 할 수 없는 문제가 있다고 알려올 것입니다. 주로 도쿠위키가 필요한 폴더나 파일을 변경할 수 없다는 메시지인데, 이것은 FTP 프로그램을 통해 권한 설정을 해주면 됩니다. 필요한 권한 설정은 755, 775, 777 등일 수 있습니다. 필요한 설정값을 호스팅에 문의해서 알아보는 방법도 있고, 권한을 바꾸고 설치 페이지를 다시고침하면서 메시지가 없어지나 확인해보는 방법도 있습니다.

도쿠위키 설치 페이지

초기 설치 오류 메시지


권한 설정을 고치려면 파일질라에서는 해당 파일이나 폴더를 오른쪽 클릭하고 파일 속성을 고른 다음 원하는 숫자가 밑에 나타날 때까지 체크박스를 선택하거나 선택 해제하면 됩니다. (이 단순한 설명..(…))

오른쪽 클릭!

파일질라에서 권한 설정례 (1)

체크박스 대화상자

파일질라에서 권한 설정례 (2)


이렇게 설치 페이지에 뜬 모든 폴더에 권한을 잡아주고 페이지를 새로 고칩니다. 제대로 되었다면 다음과 같이 위키 관련 정보를 입력할 수 있는 설치 화면이 나옵니다.

사용자 삽입 이미지
여기까지 하면 첫 설치가 끝납니다. 이제부터는 설정을 해보도록 하죠.

4. 간단한 보안 절차

우선 설정의 시작점이자 꼭 필요한 보안 절차 두 가지를 실행합니다. 첫 번째는 bin 폴더 삭제입니다. 셸로 접속할 일이 없으면 (즉 bin이 왜 있는지 모르면) 작동에 아무 지장 없으므로 그냥 지워버리면 됩니다.

두 번째는 디버그 모드 해제입니다. 이것은 설정 변경 페이지에서 해제할 수 있습니다. 먼저 위키 메인 페이지로 이동한 뒤 (예를 들어 http://lokasenna.pe.kr/testwiki/) 페이지 아래 있는 버튼을 누르고 로그인합니다. 로그인은 3번 단계에서 설치할 때 입력한 관리자 아이디와 암호로 하면 됩니다. 로그인하고 나면 페이지 밑에 Admin 버튼이 보입니다. 그 버튼을 누르고 Configuration Settings 링크로 들어가면 설정 페이지가 나옵니다. 여기서 디버그 모드 체크박스가 선택 해제되어있는지 확인합니다.

디버그 모드 체크박스

디버그 모드 해제하기


이것이 최소한의 보안 절차입니다. 추가 보안 조치에 대해 알고 싶으시면 해당 페이지 (영문)를 참고하시기 바랍니다.

5. 각종 설정

각종 설정 방법입니다. 제가 한 설정사항대로 설명하겠습니다만, 다른 설정도 얼마든지 할 수 있으니 각자 제일 잘 맞는 설정이 어떤 것인지는 시행착오를 통해 발견해갈 수 있을 것입니다. 설정 페이지 접속법은 위의 4번 단계를 참조하세요.

또 하나, 가끔은 설정 페이지가 아니라 파일 수정과 FTP 업로드로 해야 하는 설정도 있습니다. 이들 파일 수정은 반드시 UTF-8 모드로 해주세요. 그렇지 않으면 글씨가 깨져 나옵니다. 또한, 파일을 수정할 때는 원본 파일을 백업해두는 것이 안전합니다.

5.1. 언어 설정

위키 언어를 한국어로 설정하려면 설정 페이지의 Language를 ko로 선택해줍니다. 한국어 번역은 inc/lang/ko/ 폴더의 lang.php 파일을 고쳐서 수정할 수 있습니다. 그 외에 편집창 위에 나오는 메시지 등 이것저것 ko 폴더에 있는 파일들을 수정하면 바꿀 수 있습니다. 제가 몇 가지 고친 lang.php 파일이 있으니까 원하시면 원래 lang.php 파일을 덮어씌우셔도 좋습니다. (원본은 백업하는 게 좋겠죠.)

2008/04/16 업데이트: 도쿠위키 새 버전에 맞추어서 lang.php 파일에 ‘선택한 버전끼리 비교’를 추가했습니다.

1048150611.xxx


5.2. 위치 추적 링크 설정

도쿠위키는 위키 내에서 최근 방문한 페이지 링크를 상단에 표시하는 것이 기본 설정입니다만, 개인적으로는 계층형 위치 추적을 선호합니다. 계층형 위치 추적이란 폴더 구조상 현재 페이지는 어느 위치에 있는지 링크로 보여주는 것을 말합니다.

계층형 위치 추적 링크

계층형 위치 추적 링크의 예


계층형 위치 추적을 하고 최근 방문 링크 목록을 없애려면 위치 추적 수는 0으로 해주고 계층형 위치 추적을 선택하면 됩니다.

계층형 위치 추적 설정

계층형 위치 추적 설정 방법


5.3. 주소 설정

‘진보된 설정’ 란에 보면 URL 다시쓰기를 할지 설정할 수 있습니다. 다시쓰기와 슬래쉬 사용을 하면 위키 페이지 주소가 깔끔해지므로 개인적으로 추천하는 설정입니다. 우선 설정 페이지 URL 다시쓰기에서 .htaccess를 선택하고 슬래쉬 문자 사용을 선택합니다.

URL Rewriting

URL rewriting 설정


다음, 위키 루트 폴더에 있는 .htaccess를 수정합니다. (원격 호스팅이라면 컴퓨터에서 편집해서 업로드합니다.) 16, 21, 23~30번째 줄 첫머리에 있는 # 표시를 제거해서 코멘트 상태를 해제하고, 21번째 줄의 폴더명은 자신이 도쿠위키를 실제 설치한 폴더 이름에 맞게 고치면 됩니다. (2007월 6월 26일판 기준. 이후 버젼은 파일이 달라질 수 있으니 파일 자체에 있는 설명을 참조하세요.)

.htaccess 파일 예시

대충 이런 모습이 되게 고쳐주면 됩니다.


5.4. 페이지 제목 설정

설정 페이지에서 ‘페이지 이름으로 첫 헤드라인 사용’을 선택합니다. 이렇게 하면 페이지 주소로는 인코딩 문제가 없는 영문을 사용하면서 RSS 피드나 위키 링크에 표시되는 페이지 제목은 페이지 첫머리에 설정한 제목이 됩니다.

페이지 이름으로 첫 헤드라인 사용

설정한 모습


5.4. 가입 설정

설정 페이지에 보면 이메일이 유효한지 확인하려고 가입하면 자동 제조 암호를 이메일로 보내주는 설정이 있는데, 저는 귀찮을 것 같아서 이 선택은 해제했습니다. 스샷 찍기 귀찮으니까 찾아보시길. (불친절)

5.5. HTML 내장 허용 여부

제 위키는 비공개이므로 저는 편집창에 HTML을 포함하는 것을 허용했습니다만, 이것은 보안 위험이 될 수 있으므로 신중해야 할 문제입니다. 특히 공개 위키라면 안 하는 것이 좋습니다.

6. 플러그인

도쿠위키에는 이런저런 플러그인이 많은데, 그중 가장 유용한 것은 위키 페이지 밑에 댓글 상자를 달아주는 discussion 플러그인과 최근 댓글 피드를 제조하는 feed 플러그인입니다. 플러그인은 아니지만 위키 파일을 수정해서 버젼 비교 기능을 강화하는 multidiff 패치도 유용하며, (2008/04/16 업데이트: 이제는 코어에 들어있는 기능입니다) 다양한 색깔 상자를 만들 수 있는 boxes 플러그인도 쓸모가 많습니다. 먼저 플러그인 설치 방법을 얘기하고 여기서 소개한 플러그인 별로 간단한 사용법, 제가 수정한 사항 등 특이점이 있으면 얘기한 후 multidiff 패치 방법을 다루겠습니다.

6.1. 플러그인 설치 방법

도쿠위키 플러그인 소개 페이지에 각종 도쿠위키용 플러그인이 나옵니다. 설치하려면 플러그인을 받아서 lib/plugins 폴더에 하위 폴더로 업로드한 후, 관리에서 플러그인 관리 페이지로 들어가 플러그인을 활성화하면 됩니다. 참 쉽죠? (..)

6.1.1. Discussion 플러그인

이 플러그인은 설치하면 위키 페이지에 ~~DISCUSSION~~ 문구를 넣어서 댓글 상자를 달 수 있는데, 자동으로 모든 페이지에 댓글 기능을 달려면 설정 페이지로 들어가서 (방법은 위의 4번 단계 참고) ‘discussion section on every page by default’를 선택해주면 됩니다. 그 외에 저는 coComment 트래킹을 비활성화하고 댓글에 위키 구문 허용, 닉에 링크할 URL 입력 허용, 그리고 스팸 방지용으로 로그인한 사용자에게만 댓글 허용 등을 설정했습니다. 그 외에도 할 수 있는 설정은 많습니다.

6.1.2. Feed 플러그인

이 플러그인은 댓글 외에 몇 가지 다른 플러그인용 피드 역시 제조하지만, 저는 discussion 플러그인만 설치했으므로 댓글 플러그인 피드 주소를 얻는 법만 간단히 설명하겠습니다. 예를 들어 어떤 위키의 category라는 분류에 올라오는 댓글 피드 주소를 얻고 싶다면 위키 페이지에

{{commentsfeed>category}}

라는 문구를 넣은 다음에 저장하면 링크가 생깁니다. 이 링크 주소가 category 분류에 올라오는 댓글의 피드 주소입니다. 그 외에 피드 형식이나 제목 등도 설정할 수 있으니 자세한 것은 해당 플러그인 페이지를 참조하세요.

6.1.3. Boxes 플러그인

이 플러그인을 설치했을 때 구문을 어떻게 하는지는 제가 만든 구문 페이지를 참조하세요. 그 외에 이 플러그인 스타일을 고쳐서 보라색과 흰색 상자를 추가했는데, 이 부분을 하시려면 다음 파일을 lib/plugins/box/style.css에 덮어씌우세요. (위에서 말했듯 백업을 하시는 편이 좋겠죠.)

1274256055.css


6.2. Multidiff 패치
(2008/04/16 업데이트: 2008-03-31 발표 후보 이후 이제는 선택 버전 비교 기능이 도쿠위키 코어에 있으므로 이 패치는 필요없습니다)

도쿠위키 버전 비교 기능은 현재 버전과 비교하는 기능만 있지만, 이 패치를 사용하면 같은 페이지에 있는 어떤 버전이라도 서로 비교할 수 있습니다. 위키 루트 폴더에 있는 doku.php 파일, inc/html.php 파일, 그리고 inc/lang/ko/lang.php 파일을 수정하면 됩니다.

6.2.1. doku.php 파일 수정

위키 루트 폴더에 있는 doku.php 폴더에 가하는 수정은 간단합니다.

$REV = $_REQUEST[‘rev’];

라고 되어 있는 줄 아랫줄에

$REV2  = $_REQUEST[‘rev2’];

이 한 줄을 추가하면 됩니다

6.2.2. html.php 파일 수정

inc/html.php 파일은 수정 사항이 좀 복잡하므로 다 적지는 않고, 아래 파일을 덮어씌우시면 됩니다. 역시 백업은 하시고요.

1086320312.xxx


6.2.3. lang.php 파일 수정

inc/lang/ko 폴더에 있는 lang.php 파일에는 다음 한 줄을 추가하면 됩니다. (제가 위에 옮겨붙인 lang.php 파일을 사용하셨다면 이미 추가되어 있으니 안 하셔도 됩니다.)

$lang[‘compareselected’] = ‘선택한 버전끼리 비교’;

7. 스타일 변경

도쿠위키 디폴트 스타일 글씨는 영문에는 적당한 크기인데 한글에는 약간 작다 싶어서 제가 고친 게 몇 가지 있습니다. 줄 간격도 좀 키웠고요. 특히 익스플로러 6에서는 줄 간격을 그대로 두면 댓글 출력이 이상해지는 현상이 있어서 줄 간격 키우는 건 나름 강추입니다 (?). 버튼에 입체 효과 없애고 그냥 평범한 하얀 버튼으로 바꾸기도 했고요. 이런 방향으로 변화를 주고 싶으시다면 다음 파일로 lib/tpl/default/design.css 를 덮어씌우시길.

2008/04/16 업데이트: 2008-03-31 발표 후보 이후로 design.css도 조금 달라져서 새로 올립니다. 크게 달라진 건 없는 것 같지만, 어쨌든 위에 적은 수정 사항은 여전합니다.

1307380780.css


8. 접근 권한 관리

2008/04/16 업데이트: 2008-03-31 발표 후보 이후 ACL 인터페이스가 많이 달라져서 설명을 다시 합니다.

설치와 설정에 대해 설명했으니 접근 제어 목록 (ACL, Access Control List)에 대해 간단하게 설명하겠습니다. 관리자 권한으로 로그인한 ‘관리’ 버튼 -> ‘접근 제어 목록 관리’ 링크로 들어가면 접근 제어 페이지가 나옵니다.

설정해줄 수 있는 권한에는 읽기, 수정, 생성, 업로드, 삭제가 있습니다. (None이면 해당 페이지나 해당 분류에 속한 페이지를 읽을 수
없습니다.) 읽기와 수정 권한은 페이지와 분류별로 적용할 수 있으며, 나머지 셋은 분류별로만 관리할 수 있습니다. 생성은 그
분류에서 새로운 페이지를 만들 권한, 업로드는 그 분류에 파일을 올릴 권한, 삭제는 그 분류에 업로드한 파일을 지울 권한을
말하니까요. 수정 권한은 읽기 권한을 포함하고, 생성 권한은 수정 권한을 포함하는 식으로 이 다섯 가지 권한은 순서대로 더 높은
권한입니다. 따라서 읽기만 하고 수정을 못할 수는 있지만 수정만 하고 읽지 못할 수는 없죠.

분류의 접근 권한은 원칙적으로 상위 분류를 따라가며, 페이지의 접근 권한은 원칙적으로 소속 분류를 따라갑니다. 따라서 *
(전체) 분류 하위의 planescape_pbw 분류는 따로 설정하지 않는 한 * 분류와 같은 접근 권한이며,
planescape_pbw 분류에 속한 페이지는 따로 접근 권한을 설정하지 않으면 planescape_pbw 분류와 권한 설정이
같습니다.

8.1. 새로운 접근 권한 설정

페이지나 분류에 새로운 접근 권한을 설정하려면 페이지 위쪽에 있는 메뉴를 사용합니다. 왼편에는 위키에 있는 모든 분류가 나오며, + 표시를 클릭하면 그 분류의 페이지가 나옵니다.

새로운 권한을 설정하려는 분류나 페이지를 선택한 후 오른쪽에서 그룹 혹은 사용자별로 권한을 설정합니다. 현존하는 그룹과 그룹에
속한 사용자는 선택 메뉴에 나오며, 아니면 ‘사용자:’ 혹은 ‘그룹:’을 설정해서 수동으로 사용자 아이디나 그룹명을 입력할 수도 있습니다.

접근 제어 목록 관리 스크린샷

새로운 접근 권한 설정하기


분류 혹은 페이지와 그룹 혹은 사용자를 선택했으면 권한을 지정해줍니다.  예를 들어 planescape_pbw 분류에 대해 plane_research 그룹에 ‘생성’ 권한을 주면 그 그룹에 속한 사용자는 planescape_pbw에 있는 페이지를 읽고 수정하고 새로 만들 수 있지만, 첨부 파일을 올리거나 삭제하지는 못합니다.

8.2. 기존 접근 권한 수정

이미 설정한 접근 권한을 변경하려면 접근 제어 목록 관리 페이지에 나온 목록에서 수정하면 됩니다. 해당 분류 혹은 페이지의 권한 설정을 찾아 바꾼 후, 아래로 내려가서 ‘변경’을 누릅니다. 권한 설정을 없애려면 맨 오른쪽의 체크박스를 선택하고 ‘변경’을 누릅니다.

접근 제어 목록 관리 스크린샷 2

기존 권한 설정 변경하기


이 목록을 보면 beasthunters 분류에 대해 hunters 그룹은 읽기, 수정, 생성, 업로드, 그리고 삭제 권한이 있습니다. beasthunters 하위의 rules 페이지에 대해서 hunters 그룹은 읽기와 수정 권한이 있고, hunters 그룹을 제외한 비관리자 사용자 (ALL)는 rules 페이지를 읽을 수 없습니다. (그러나 그 외에는 상위 분류에서 계승하므로 rules 외에 beasthunters의 다른 페이지는 읽을 수 있습니다. 그림에서 * 분류에 대한 ALL의 권한 참조.)

위에서 hunters 그룹이 beasthunters:rules 페이지를 읽을 수는 있되 수정할 수는 없게 바꿀 방법이 두 가지 있습니다. 그 두 가지가 뭔지 알 수 있으면 권한 설정과 계승 개념은 이해가 됐다고 보면 될 겁니다.

[#M_해답 보기|해답 닫기|
1. beasthunters:rules의 @hunters 권한을 ‘읽기’로 바꿉니다.
2. beasthunters:rules의 @hunters 권한을 지웁니다.
_M#]
8.3. 사용자 그룹에 대하여

권한 설정은 개별 사용자에게도 할 수 있고, 사용자를 그룹으로 묶어서 그룹별로 권한을 줄 수도 있습니다.

기본 설정 사용자 그룹은 ALL, user, admin이 있습니다. ALL은 관리자만 제외한 등록, 미등록 사용자 모두를 가리키며, user는 등록한 사용자를 가리킵니다. 따라서 예를 들어 ALL이 특정 분류의 글을 읽을 수 없다면 그 분류의 글은 관리자만 읽을 수 있다는 뜻이며, ALL은 읽을 수 없고 user만 읽을 수 있다면 등록한 사용자와 관리자만 읽을 수 있다는 뜻입니다.

관리자는 user 그룹 내에 새로운 그룹을 정의할 수도 있습니다. 예를 들어 jedi 그룹을 정의해서 공화국의 그림자 분류는 누구나 읽을 수 있지만 jedi 그룹만 수정할 수 있게 하는 식이죠. 사용자 그룹을 정의하려면 ‘관리’ -> ‘사용자 관리’로 들어가서 그 그룹에 추가하려는 사용자 이름 왼쪽에 있는 정보 수정 아이콘을 클릭합니다.

사용자 수정 아이콘

사용자 수정 화면 들어가기


다음 화면 오른편에 있는 ‘사용자 정보 수정’에서 그룹들 란에, user 그룹과 쉼표로 구분해서 추가하려는 그룹명을 입력합니다. (아마 그룹명은 영어로 하는 게 좋을 겁니다. 한글로 해본 적은 없지만, 혹시 있을지 모르는 인코딩 문제를 피하려면 말이죠.)

사용자 정보 수정

사용자 정보에 사용자 그룹 추가


이렇게 하면 jedi 그룹을 설정한 것이 되며, 같은 방법으로 이 그룹에 다른 사용자를 추가하고 분류나 페이지별로 권한 설정을 해줄 수 있습니다. 특히 캠페인 참여자를 이런 식으로 관리하면 편합니다. 스타워즈 캠페인 참가자는 jedi, 별이 지다 참가자는 starfall 그룹 하는 식으로 말이죠. 마찬가지로 개별 사용자별로 접근 제어 목록을 관리할 수도 있으므로 특정 사용자만 읽을 수 있는 분류나 페이지도 만들 수 있습니다.

9. 추가 정보

이상과 같이 도쿠위키 설치와 설정, 관리에 대한 기본적 사항을 적어보았습니다. 정확히는 ‘도쿠위키, 난 이렇게 했다’에 가깝습니다만… 여기서부터 조사와 시행착오를 통해 더 알고 활용해가는 건 각자의 몫이겠지요. 도쿠위키 위키에 물론 가장 많은 정보가 모이고, 제가 한글로 만든 간단한 사용설명서와 편집 구문 설명서도 있습니다. (구문 설명 중에 색깔 글상자와 미디어 삽입은 플러그인에 의존하므로 주의하시길.) 도쿠위키를 편하게, 재밌게 사용하는 데 도움이 되었으면 좋겠습니다.

정보관리에 대한 단상 4: 위키

옛날옛적에 썼던 홈페이지, 게시판, 블로그에 대한 글에 이어 위키를 다루어 보았습니다. 이전 호스팅에서 쫓겨나면서 위키 자료를 날린 후 실의에 빠져(..?) 못쓰고 있다가 이제야 올리면서 정보관리에 대한 단상 시리즈를 마칩니다.

제 경험으로 위키는 크게 두가지 다른 목적이 있다고 봅니다. 첫번째는 위키가 본래 시작된 목적에 보다 가까운 것으로, 불특정 다수의 지식과 노력을 동원하여 정보를 축적하는 것입니다. 대표적인 예가 엄청난 양의 정보를 축적한 위키피디아라고 할 수 있습니다. 위키피디아에서 사용하는 미디어위키가 그런 쪽에 특화된 위키 도구라고 할 수 있죠. RPG 쪽에서는 TRPG 위키가 대표적인듯 합니다.

하지만 다수가 같은 페이지를 관리할 수 있는 위키 기술은 비단 정보의 축적 뿐만 아니라 정보의 관리에도 응용되기 시작했고, 페이지 혹은 분류에 따른 접근과 편집권한 설정이 추가된 위키 역시 생겨났습니다. 이런 형태의 예로는 도쿠위키가 있습니다. 캠페인 관리 도구로 사용하고 있는 로키네 위키도 정보의 축적보다는 관리를 목적으로 하고 있습니다. 이 글은 이쪽 유형의 위키에 중점을 두고 있습니다. 불특정 다수에 의한 정보의 축적은 홈페이지, 게시판, 블로그로는 구현이 힘든 위키 고유의 기능이라 비교 자체가 무의미하니까요.

위키의 본질이자 특징인 다수에 의한 페이지 수정은 캠페인 관리에 특히 유용하다고 봅니다.  단적인 예로 캐릭터 시트를 들 수 있습니다. 웹페이지, 게시판글, 블로그글 등은 기본적으로 관리자 혹은 글쓴이 한사람에게 수정 권한이 주어지기 때문에 진행자가 경험치를 추가해 주고 참가자가 그 경험치를 사용하는 식의 편의를 확보하기 힘듭니다.(주:여기에도 물론 많은 변형과 예외가 있어서, 제로보드 같은 경우 관리자가 글 수정이 가능하므로 진행자가 관리자로 있는 게시판에 참가자가 시트를 글로 올린다든지 하면 동시 수정이 가능합니다. 블로그 도구인 태터툴즈팀블로그 플러그인을 통해 다수가 글을 수정할 수 있죠.) 반면 위키는 기본적으로 여러 사람이 수정 권한을 가집니다. 이러한 권한을 제한할 필요가 있다면 권한 설정 기능을 이용할 수 있고요.(주:위에서 말했듯 위키 도구도 목적에 따라 기능이 달라서, 정보의 축적을 목적으로 하는 미디어위키는 권한설정 기능이 비교적 약하고 정보관리를 목적으로 한 도쿠위키는 매우 체계적으로 되어 있습니다.)

권한 제한도 이래저래 유용하게 쓸 수 있어서, 캠페인 설정 중 참가자들에게 보여주고 싶지 않은 페이지는 저만 볼 수 있게 권한을 잠가놓기도 합니다. 그리고서 나중에 점진적으로 공개한다든지 하는 방식을 쓰고 있습니다. 포도원의 제다이 캠페인에서 참가자들이 이미 클리어(?)한 마을인 셀렌은 권한을 열어놓고 아직 진행중인 카론은 닫아놓은 것이 그 예입니다. 물론 아예 웹상에 올리지 않는 것도 한 방법이지만, 웹에 올리되 권한 설정을 이용하면 모든 캠페인 정보를 한곳에서 관리하는 편의 또한 확보할 수 있다는 것이 장점입니다. 나중에 필요하다면 특정 참가자와 저만 볼 수 있는 페이지를 만든다든지 하는 것도 가능할 것입니다.

DokuWiki ACL management

도쿠위키에서 권한 설정례


자주 수정되는 정보, 특히 다수가 수정하는 정보에서 발생할 수 있는 혼란을 완화하는 것이 위키의 또다른 특징인 버젼 관리 기능입니다. 위키에서는 모든 변화가 기록에 남으며, 필요하면 언제든지 글을 이전 버젼으로 되돌릴 수도 있습니다. 다시 캐릭터 시트의 예를 들자면 얼마만큼의 경험치를 언제 받았는지, 언제 어떻게 썼는지 모두 확인할 수 있고 오류나 중복이 있었다면 고칠 수 있습니다. 편집내용을 요약해서 적어두면 특정 페이지의 변천을 한눈에 알아볼 수 있는 점도 편리하지요. (저 말고는 어째 잘 안쓰는 기능인듯 하지만…)

위키는 또 홈페이지와 비슷하게 정보의 구조화에도 강한 편입니다. 블로그나 게시판처럼 시간순서 역순으로 나열하는 구조 대신 정적인 페이지 단위를 기본으로 하고 있으므로 차례 페이지를 만들어서 필요한 링크를 정렬할 수 있죠. 도쿠위키 같은 경우는 네임스페이스 기능을 통해 항목을 논리적으로 조직할 수 있고, 미디어위키는 각 페이지에서 사용하는 태그에 따라 자동으로 분류 페이지를 생성해 줍니다. 또한 많은 위키의 경우 RSS 피드 기능을 제공함으로써 홈페이지의 정보 구조력 뿐만 아니라 블로그 혹은 게시판의 시의성까지 갖추고 있습니다.

위키 도구는 대체로 오픈소스이기 때문에 확장성 또한 뛰어납니다. 많은 경우 배포 홈페이지와 게시판, 메일링 리스트 등을 통해 개발자와 사용자의 모임이 형성되어 있으며, 이들이 제공하는 기술적 지원과 플러그인을 통해 위키의 기능을 발견하고 확장할 수 있는 것도 큰 장점입니다. 이런 식으로 위키를 자신에게 맞는 도구로 만들어가는 유연성은 위키의 또다른 매력이라고 할 수 있지요. 물론 이는 비단 위키만의 장점은 아니며, 태터툴즈 같은 오픈소스 블로그도 마찬가지입니다.

이와 같이 많은 장점이 있지만 위키는 사용 편의가 그다지 높은 매체는 아닙니다. 무엇보다 대개의 사용자에게 생소하다는 점이 문제가 될 수 있습니다. 블로그나 게시판에 익숙한 사용자는 이들 도구와 개념이 다른 위키에 익숙해지는데 어려움을 겪을지 모릅니다. (개인적으로는 별로 어렵지 않았기 때문에 추측으로..(..))

또한 많은 기능과 뛰어난 확장성을 자랑하지만 이러한 장점을 살리는데는 종종 기술적 어려움, 그리고 시간과 노력이 따릅니다. 파일과 폴더 권한 설정, 플러그인 설치와 테스트, 스킨 수정, 피드 구독 등등. 아직 기술적으로도 불안정한 데가 많고, 필요한 정보를 얻으려면 스스로 검색과 문의를 꽤 해야 합니다. 어느정도의 지식이 없으면, 그리고 위키를 장난감처럼 가지고 노는 재미를 느끼지 못하면 힘들 수도 있습니다. 호스팅 형태의 위키, 그리고 미디어위키처럼 비교적 오래된 위키 도구는 기술적으로도 비교적 안정되고 문서화 작업도 잘 돼있는 것으로 알고 있으니 상황이 좀 다를 수도 있지만요.

마지막으로, 역시 사용 편의하고도 연관된 문제이지만 위키는 아직 다른 웹기술에 비해 정착이 안된 관계로 한글화가 불완전한 경우도 많습니다. 위키 도구는 상당히 많이 나와 있지만 UTF-8 인코딩을 지원하는 것은 많지 않으며, 필요한 정보의 문서화 상황은 더욱 열악합니다.  미디어위키가 위키 자체와 문서작업 모두 한글화가 제일 많이 된 경우로 알고 있으며, 도쿠위키도 UTF-8 인코딩 지원과 더불어 인터페이스 한글화와 한글 문서화가 부분적으로 된 경우입니다.

이와 같이 정보관리 수단으로서의 기능을 중심으로 위키를 다루어 보았습니다. 한마디로 요약하자면 지금까지 다룬 정보관리 수단 중에 기능성은 최고, 사용편의는 꽝(…)이랄까요. 개인적으로는 재미있게 사용하고 있지만, 아직 발전의 여지는 많아보입니다. 그만큼 앞으로 어떤 식으로 발전해갈지 기대되는 매체이기도 하고요.

덧: 제가 도쿠위키 설치하고 설정한 얘기를 올렸습니다.

정보관리에 대한 단상 3: 블로그

홈페이지가 정적인 정보의 고정적 게시수단, 게시판이 커뮤니티 형성과 토론의 도구라면 웹로그, 혹은 블로그는 공개 일기, 내지는 넋두리랄까요. 언제나 예외나 혼합형은 존재합니다만…

블로그의 장점

블로그의 장점이라면 첫째로, 게시판과 마찬가지로 웹에 대한 아무 지식이 없어도 웹상에서 바로바로 글을 올리고 편집할 수 있는 편의성입니다.

두번째, 가장 최근 글이 중심적인 위치를 차지하고 최근에는 어떤 답글이 달렸는지 알 수 있는 등 시사성 내지는 현재성이 뛰어납니다. 빠르게 흐르는 관심사와 의식의 흐름, 일상의 현재상태를 포착하는 사진과 같은 것이 블로그이지요.

세번째로, 게시판과 구분되는 특징이라면 그 개인성을 들 수 있을 것입니다. 블로그 작성자의 글은 중심적인 위치를 차지하고 답글은 밑에 작게 달리는 등 인터페이스 면에서도 그렇고, 보통 한 사람의 명의로 되어 있고 들리는 사람들은 그야말로 잠시 들려가는 손님이라는 점에서 ‘자기 공간’이라는 느낌이 훨씬 강하달까요.

하지만 온라인이라는 특징 때문에 그 개인성을 기반으로 사회성 또한 뚜렷이 드러납니다. 타인의 블로그에 꼬리글을 남기고 아는 사람 블로그에 링크를 거는 등… 가장 정형적인 형태의 게시판은 커뮤니티의 공간이라는 느낌이 강하고, 관리자는 자기 공간을 관리한다기보다는 커뮤니티에 봉사하는 관리자입니다. 하지만 블로그 작성자는 자기 공간을 꾸미고 만들어 가며, 그러는 와중에 손님 접대(?)도 한다는 인상이 더 강합니다. 비유하자면 게시판은 휴게실, 블로그는 가정집의 응접실이나 부엌이라는 생각도 드네요. (웃음) 사회적인 공간이지만 그 영역과 색깔이 누구의 것인지는 분명하니까요.

다섯번째, 위의 세 장점의 결과로 블로그는 굉장한 자유성을 누릴 수 있는 매체입니다. 홈페이지 글을 작성할 때는 그 전체적인 성격과 정보 구조를 고려해야 하고 게시판 글을 작성할 때는 게시판 공동체에 비추어 그 적합성을 생각해야 한다면, 가장 기본적인 블로그는 신변 잡기에 대한 어떤 얘기든지 할 수 있는 일기장에 가깝습니다. 역시 공개 일기장이라는 점에서 최소한 지켜야 할 기준들은 있겠지만, 다른 웹 매체에 비해 글의 내용이나 질에 덜 얽매이는 것은 사실입니다.


블로그의 단점

이와 같이 효용이 많은 매체인 블로그도 만능은 아니라서, 대표적인 허점이라면 게시판과 비슷하게 정보의 구조화에 약하다는 점일 것입니다. 검색이나 분류 등의 기능을 많은 블로그가 제공하고 있지만 위에서 말한 자유성 같은 특징들의 결과로 그 효용은 불완전한 경우가 많습니다. 따라서 정보의 저장과 열람 수단으로는 부적합합니다.


적합한 용도

이상과 같은 이유로 블로그가 가장 적합한 용도는 그때그때 떠오르는 생각들을 쏟아낼 수 있는 온라인 일기로서가 아닌가 합니다. 그리고 일기나 사진첩과 같은 이유로 나중에 블로그를 훑어보는 것은 그 자체로 새로운 자극이라고 생각합니다. 삶 속에서 지나간 순간들, 그리고 시간의 틈새 속에서 느끼고 생각하는 자기 자신과 마주할 기회가 되니까요.

정보관리에 대한 단상 2: 게시판

게시판은 특히 인터넷상에서 공동체를 형성하고 토론하기에 좋은 매체입니다. 장점이라면 글이나 파일을 올리기가 쉽다는 점, 글과 그 글에 대한 답변이 하나의 보기 쉬운 단위로 묶이기 때문에 토론의 맥을 잡기가 좋다는 점 등이 있을 것입니다. 또 글을 쓴 다음에 FTP로 따로 올리는 게 아니라 넷상에서 바로 글을 작성하고 수정할 수 있다는 점도 편합니다. 포맷을 자동으로 넣어주기 때문에 HTML 지식이 필요없다는 점도 장점이지요.

반면 단점이라면 정보의 구조화에 약하다는 점일 것입니다. 분류 기능을 사용한다고 해도 기본적으로는 시간 순서 역순으로 늘어놓은 글들의 집합이고, 따라서 글이 많을수록 검색에 의존하게 되는데 사용하는 용어가 늘 일정한 것은 아니기 때문에 정보의 회수에도 의외로 틈새가 많죠. 결국 게시판 글은 오래될수록 그 가치가 떨어지게 되는 것 같습니다. 활발한 게시판일수록 그때그때 서로 의견을 주고받기는 좋지만 정보의 장기 보관에는 부족한 점이 있지요.

그래서 게시판 형태가 적합한 용도라면 역시 토론과 의견교환, 친목도모(?)의 장으로서일 것입니다. 또 반드시 토론이 목적인 글이 아니어도 일반적인 홈페이지 제작에서 느끼는 어려움이나 번잡함을 피하기 위해 게시판에 글을 작성하기도 하죠. 저같은 경우도 세계관 자료라든가 번역 자료 등 많은 글을 게시판에 올린 바 있습니다. 게시판 규모가 크지 않으면 나름대로 편한 방법입니다만…역시 최선의 수단은 아니라는 생각이 듭니다.

정보관리에 대한 단상 1: 홈페이지

RPG를 즐기는데 중요한 요소 중 하나는 정보의 공시와 관리라고 생각합니다. 홈페이지, 게시판, 블로그, 위키 등 웹상에서 정보를 관리하는 도구를 사용하면서 느낀 장단점과 효용을 간단히 살펴보고자 합니다. 그중 첫번째는 가장 기본적인 정보관리 도구라고 할 수 있는 홈페이지입니다.

홈페이지

홈페이지 혹은 사이트는 인터넷에 정보를 게시하는 가장 기본적인 형태로, 대체로 내용은 정적이고 내용변환 권한자는 사이트 주인 한명이나 소수의 관리자로 제한됩니다. 제가 생각하기에 홈페이지의 장점이라면 다음과 같은 것이 있습니다.

1. 만들고 관리하기가 용이

홈페이지의 기본 형태는 정적인 HTML 문서이기 때문에 만드는 입장에서 이해하기가 좋고, 고치려면 문서를 고쳐서 다시 올리기만 하면 되므로 만드는 사람이 한두사람이라면 관리하기도 어렵지 않습니다.

2. 내용이 안정적이어서 항상 일정한 정보를 내보냄

정적이라는 점은 홈페이지의 단점이기도 하지만 한편으로는 장점이기도 하다고 봅니다. 같은 내용의 정보를 일정한 곳에 게시하기 때문에 그만큼 어떤 정보를 어디서 찾을지 정확히 알 수 있습니다.

3. 다른 많은 정보관리수단으로 통하는 관문 역할

홈페이지라는 매체의 안정성은 여러가지 다른 매체로 가는 관문으로서의 기능으로 이어집니다. 위키, 블로그, 다른 사이트 등으로 연결되는 링크를 한곳에 모아놓고 필요할 때마다 접속하기에 좋지요. 물론 위키와 블로그도 제공하는 기능입니다만, 인터페이스상 보통 홈페이지 매체가 각 링크에 대해 짧은 설명을 제공하고 링크를 내용별로 분류하기에 더 좋습니다.

반면 홈페이지의 약점이라면 다음과 같은 점이 있을 것입니다.

1. 공동작업에 부적합

관리자가 소수일 때는 괜찮지만 여러 사람이 공동작업을 진행하려고 할 때 홈페이지 형태는 불편한 경우가 많습니다. 홈페이지의 기본 형태는 문서를 작성해 FTP로 올리는 것인데, FTP 아이디와 비밀번호를 여러 사람이 가지고 있을 경우 보안에 문제가 생기기 쉽고 한두사람만 FTP 권한을 가질 경우 다른 사람들은 올리고 싶은 내용이 있을 때 일일히 관리자에게 부탁해서 올려야 하는 불편이 있습니다. 이 점을 해결하는 여러가지 도구가 있는 것으로 알고 있지만 취미 용도의 개인 사이트 수준에서 쉽게 접할 수 있는 것은 아니라는 단점이 있습니다.

2. 갱신의 불편성

관리자는 소수라 하더라도 기본적으로 홈페이지의 내용을 바꾸는 방법은 문서를 작성하고 FTP로 문서를 올리는 것입니다. 내용을 웹상에서 고쳐서 바로바로 반영되는 것보다는 훨씬 불편하고 손이 많이 가는 작업이죠. PC를 곧 서버로 사용하는 경우라든지 일정한 시간이 지나면 자동으로 올리는 방법 등 역시 예외는 있겠지만 일반적으로 홈페이지 내용을 자주 변경하는 것은 귀찮은 일이라고 할 수 있습니다.

그렇다면 홈페이지는 어떤 용도에 적합할까요? 제가 생각하기에는 크게 다음과 같은 쓰임입니다.

1. 정적 정보의 제공

연락처나 시간대, 크게 고칠 필요나 토론의 여지가 없는 글, 이미지 등 고정된 정보를 제공하기에 좋은 방법입니다. 캠페인 사이트인 Aldana Steel (영문) 같은 경우가 좋은 예입니다.

2. 정보의 관문

게시판, 블로그, 위키 등 사이트 내외의 다른 많은 정보로 링크하는 중앙 관문으로 사용하기에 좋은 수단이기도 합니다. 거의 어떤 사이트의 링크란을 봐도 그 효용을 알 수 있습니다. 블로그나 위키의 메뉴보다 넓은 공간을 사용할 수 있기 때문에 링크의 목적지에 대한 설명문이나 배너 등을 넣을 수 있는 점이 특히 눈에 띄는 장점이라고 생각합니다.

3. 스크립트 도구

게시판, 블로그, 위키 등은 모두 기본적인 스크립트 틀을 제공하고 그 속에서 정보를 올리게 되어 있기 때문에 독립적인 기능을 가진 스크립트를 만들기에는 적합하지 않은 형태입니다. 따라서 웹상에서 스크립트 기반 도구를 만들려면 완전히 백지 상태에서 시작하는 홈페이지 형태가 적합합니다. 제가 만든 겁스 경량판 CP 분배기 같은 경우가 그 한 예입니다.