※ 주: Roger Fisher의 교섭 지침서 Getting to Yes와 수업 중 배우고 교섭 훈련받은 내용 등을 놀이라는 상황에 맞춰 정리한 것입니다.

RPG 등 여럿이서 하며 규칙 외의 영역이 꽤 되는 놀이를 하다 보면 의견 차이가 발생하기도 합니다. 그런 때면 상대가 ‘무엇’을 요구하는지만 다루면서 의견 차이를 좀처럼 좁히지 못하거나 (“아니 외교 중심 캠페인이랬는데 왜 전투귀신이야!”), 충돌하는 요구사항 사이에 타협하기도 합니다(“전투에 투자한 것 중에서 반만 사회 기능으로 돌리자, 응?”). 때로는 상대의 기분이나 팀내 화합을 먼저 고려하는 의미에서 양보하기도 하고 (“알았어, 인정하지.”), 때로는 진행자이니까, 혹은 지난번에는 내가 양보했으니까 등의 이유로 의견을 관철하기도 하지요(“처음부터 그랬지, 외교 중심 캠페인이라고!”).

그러나 한 가지 중요하고 간단한 사실이라면, 요구사항 자체만을 다뤄서는 교섭 결과에 만족하기 어려우며 가치를 창출할 기회를 놓칠 수 있다는 점입니다. 교섭에서 중점이 되어야 할 것은 ‘무엇을 원하는가’ 하는 문제가 아니라 ‘어째서 원하는가‘입니다. 전자가 요구라면 후자는 그 요구의 이유가 되는 관심사이지요. 이 차이를 이해하면 바로 그 요구 말고도 같은 관심사를 충족할 수단을 모색할 수 있고, 그런 수단 중에는 양자 모두의 관심사를 충족할 방법이 있을 수 있습니다. 결관적으로 훨씬 만족스러운 합의사항을 이끌어낼 수 있다는 뜻이죠.

위의 외교 캠페인의 예로 돌아가보면, 사실 참가자 P가 진행자 G의 공지에도 불구하고 전투 중심 인물을 만든 것은 전에 어려운 전투 때문에 인물이 죽은 일이 있어서 어떤 전투에도 대응하려는 생각일지도 모릅니다. 그렇다면 위에서 예를 든 P나 G의 의견 완전 관철은 물론이고 타협책 역시 어느 쪽의 관심사에도 충분히 부응하지 못합니다. 전투능력이 반으로 줄면 P의 위기감은 늘어나기만 할 테고, G도 외교 능력이 부족한 P의 인물 때문에 캠페인에 이런저런 조정을 가해야 할 테니까요. 요구사항의 배후에 있는 관심사를 이해하는 것은 그래서 중요합니다.

의견 차이가 있을 때면 상대의 관심사뿐만 아니라 자신의 관심사 역시 이해하지 못하고 있는 일이 의외로 많습니다. 예를 들어 위의 P는 전투를 잘하는 인물을 만들고 싶다고만 생각했지 굳이 외교 캠페인에 전투에만 치중한 인물을 만들어온 동기는 스스로 깨닫지 못하고 있을지도 모릅니다. 마찬가지로 G도 외교 중심 캠페인이니까 주인공 일행은 외교관이어야 한다고만 생각하고, 그게 정말로 외교 캠페인을 재미있게 돌리는 방법인지는 생각하고 있지 않을지도 모릅니다.

따라서 교섭은 자신과 상대의 관심사를 이해하는 과정이어야 합니다. 어떤 관심사가 있는지 알아야 그 관심사에 만족스럽게 부응하는 해결책을 생각할 수 있으니까요. 놀이에 임하는 자신과 상대의 관심사를 알아내고, 맞수가 아닌 협력자 입장에서 해결책을 함께 찾아나갈 수 있다는 면에서 의견 차이는 문제라기보다는 오히려 기회일 수 있습니다. 그렇다면 관심사를 알아내는 방법에는 어떤 것이 있을까요?

우선 가장 중요한 것은 경청입니다. 그 요구의 이유를 물어보고 귀기울이면서 정리해가는 것이지요. 단순히 자기가 다음에 할 말을 생각하면서 가만히 있는 것이 경청이 아니라, 정말로 상대가 하는 말을 이해하고 소화해서 자기 것으로 만드는 과정을 말합니다. (짐작할 수 있겠지만 실생활에도 큰 도움이 됩니다.)

경청을 침묵으로 끝내지 않고 상대의 관심사를 추출하는 한 가지 중요한 기법으로는 능동적 경청이 있습니다. 먼저 상대가 말을 하면 듣고 인정합니다. (“그렇구나.”) 그 말의 내용에 동의하는 것이 아니라, 상대가 그렇게 생각하고 있다는 사실 자체를 인정하는 것이죠. 그리고 그 말의 배후에 있는 관심사를 정리해서 자기 말로 다시 표현합니다. (“즉, 전처럼 전투가 위험해지면 왠만한 실력으로는 견디기 어려우니까 자기 방어 차원이라는 거?”) 그리고 자신이 정리한 관심사가 옳은지 확인합니다. (“맞나?”) 이들 단계는 함께 하거나 짧게 지나갈 수도 있지만 (예를 들어 다시 표현 단계를 질문형으로 하면 확인의 역할도 하죠), 각자 효용이 다르므로 개념적으로는 따로 생각하는 것이 좋습니다.

경청은 이익을 파악하는 중요한 수단인 한편 감정적으로도 서로 가까워지는 중요한 방법이기도 하죠. 누군가 자기에게 귀기울여주고 정말 이해하려고 노력한다는 느낌은 그만큼 사람과 사람을 가깝게 하니까요. 그러나 이것만으로는 충분하지 않을 수도 있습니다. 놀이에 임하는 교섭의 특수성이라면 요구의 배후에 있는 관심사는 무의식적이거나 내밀한 것도 많다는 점이기에. 그래서 나오는 것이 관찰의 중요성입니다.

요구의 배후에 있는 상대의 관심사를 파악하는 두 번째 주요한 수단인 관찰은 좀 덜 점잖게 말하면 ‘알아서 눈치깔기’라고도 할 수 있고, 결국 사람에 대한 감인 만큼 설명하기도 좀 어렵습니다. 대화를 나눌 때 계속해서 등장하는 주제나 태도, 잘 만드는 인물 유형, 놀이 중에 열성적으로 반응하는 요소 등을 관심있게 보다 보면 이 사람이 왜 그런 선택을 하는지, 무엇을 좋아할 것 같은지 느낌이 오게 마련입니다. 예를 들어 G가 평소 보기에 P는 능력이 튀는 편을 선호하는 것 같다면, 그것 역시 P의 관심사라고 추정할 수 있겠지요.

이렇게 관심사를 파악하면 다양한 해결책을 함께 모색해볼 기반이 생깁니다. P가 원하는 것이 꼭 전투귀신이라기보다는 플레이 중 허무하게 죽지 않는 것이라면 그 욕구를 충족하면서 G의 관심사 역시 충족하는 방법은 많이 생각해볼 수 있습니다. 경호원 조연을 둔다든지, 전투는 어느 정도 난이도가 적합할지 함께 생각해 본다든지, 전투 중 너무 쉽게 죽지 않게 규칙을 고친다든지.

마찬가지로 G가 원하는 것이 반드시 전원 외교 중심 인물로 구성한 일행이라기보다는 즐거운 외교 캠페인이라면 전투 중심 인물이 있는 것이 꼭 외교 캠페인의 재미를 해칠지 생각해보고, P의 인물은 경호원이라든지, 유명한 군인인데 전쟁이 일어날 수 있다는 위협용으로 데려온 인물이라든지 하는 다양한 방법을 생각할 수 있겠죠. P와 G가 각각 처음 내놓은 요구사항만을 다루었다면 생각하기 좀 더 어려웠을 해결책이었을 것입니다.

물론 이 글에서 얘기하고 있는 것은 이미 많은 팀에서 하고 있는 새삼스러운 얘기일지도 모릅니다. 그러나 당연한 얘기라 해도 정리해 두면 의사소통이 잘 안 되고 있는 상황에도 적용할 수도 있고 비판을 통해 발전시킬 수 있는 방법론이 된다는 점에서 이렇게 글로 적어보았습니다. 더 좋은 놀이와 더 많은 토론의 기반이 되었으면 좋겠습니다.

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

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 등일 수 있습니다. 필요한 설정값을 호스팅에 문의해서 알아보는 방법도 있고, 권한을 바꾸고 설치 페이지를 다시고침하면서 메시지가 없어지나 확인해보는 방법도 있습니다.

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

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

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

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를 선택하고 슬래쉬 문자 사용을 선택합니다.

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

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. 기존 접근 권한 수정

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

이 목록을 보면 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. 추가 정보

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

월요일부터 플레이 시작하는 국가의 건설 플레이 바이 위키에 앞서서 이것저것 준비가 진행 중입니다. 이번에 준비한 것 중 하나는 연구 대상 사이 관계도였는데, 저번 글하고는 또 다르게 이런저런 쓰임이 보이더라고요. 반면 한계도 있었지만요. 다음은 글리피로 만들어본 국가의 건설 연구 대상 관계도입니다. (승한님이 좀 더 재밌게 설명까지 붙이신 관계도는 여기에.)

우선 인간관계를 시각적으로 표현한 것 자체가 수정주의 역사 (Revisionist History) 규칙상 많은 도움이 되었습니다. 시작 연구 자금이 연구대상 사이 인간관계의 수에 의존하므로, 연구 대상이 무려 아홉이나 되는 대형 설정에서는 관계를 시각적으로 표현하지 않으면 연구 자금 계산조차 어려웠습니다. 반면 관계도는 그려놓고 화살표만 세면 되니까요. (“검은 화살표 5개에 빨간 화살표 7개는 에…”)

그런 이유로 시작해서 만들고 고치다 보니까 인물 관계를 시각화하는 효용이 보이더군요. 무엇보다 화살표를 그리는 편의상 관계가 밀접한 인물들을 가까이 붙이고 화살표가 많은 인물일수록 중심에 놓다 보니 인물 사이 관계라는 추상이 구체적이고 시각적인 의미를 띠게 되었습니다. 예를 들어서 위의 관계도를 보면 관계도 중심에 가까운 인물일수록 인간관계가 복잡하게 얽혀 있으며, 주변부에 있을수록 관계나 이야기가 비교적 단순하다는 것을 알 수 있습니다. 또한, 상대적인 위치에 따라 인간관계의 구역이나 블록에 의미가 생기더군요. 돈울프-진 뤠이신-자비에르의 ‘건국 공신 클럽’이라든지 칼라인-마그누스-세렌의 우정 등.

한편으로는 시각화라는 목적상 필연적으로 어느 정도 단순화가 필요해져서, 관계도로는 인간관계의 모든 함의를 표현하기는 어렵다는 것도 깨달았습니다. 너무 복잡해지면 시각화의 의미 자체가 희석되니까요. (다닐과 이렌가르드의 관계에는 연심 외에 충성심과 우정도 있는 등.) 그래서 관계도는 복잡다단한 인간관계의 모든 것을 표현한다기보다는 그 대략을 단순하고 굵게 표현하는 시각 자료라는 점을 염두에 두어야 할 것 같습니다. 지난번에 제가 관계도를 작성하면서 그 효용을 그다지 느끼지 못한 것도 시각화의 효용성과 한계를 생각하지 않아서였던 것 같습니다.

결론적으로 관계도는 관계와 감정이라는 추상을 구체화하고 단순화해서 시각적, 공간적 의미를 부여하는 효용은 있지만, 시각화에 따라 어쩔 수 없이 복잡한 함의는 표현하기 어렵다는 한계도 있다는 점을 염두에 두고 활용하면 유용한 도구가 될 수 있다고 생각합니다. 만들고 감상하는 재미도 있고 말입..(퍽)

RPG는 여럿이서 하는 놀이이기 때문에 참가자가 한 사람이라도 빠지는 것은 큰 차질일 수 있습니다. 하지만, 이런저런 사유로 예고 후, 혹은 예고 없이 참가자가 결석하는 일이 생기게 마련이지요. 이럴 때 크게 다음과 같은 네 가지 대응책을 생각할 수 있습니다.

1. 빠진 이유를 갖다 붙이고 속행

개인적으로 가장 선호하는 방법입니다. 제가 각 세션을 될 수 있으면 하나의 단위 (예를 들어 캠페인 시간상 하루)로 진행하는 이유 중 하나이기도 합니다. 그게 잘 안 되면 최소한 세션을 맺을 때 하나의 장면을 완전히 끝낸다거나요. 이렇게 하면 다음 세션에 참가자가 하나 빠져도 그 주인공이 없는 이유를 급조한 후 세션에 나온 참가자들과 계속 진행할 수 있기 때문입니다.

대표적인 예가 포도원의 제다이 8화, 그리고 9화부터 12화였는데, 3인 참가자 중에서 8화에는 이방인님, 9화에는 소년H님이 빠진 연속타를 먹었었죠. (흑흑.. 아카스트님을 붙잡고 웁니(?)) 그래서 8화에서는 ‘일행이 흩어져서 정보를 찾고 있다’라는 식으로 둘러대고 아카스트님과 소년H님 쪽을 진행했습니다. 그다음 9화 첫머리에서 이방인님의 주인공이 별 성과 없이 숙소로 돌아오는 연결부를 짧게 했죠.

9화에서는 소년H님의 주인공인 로어틸리아가 없으니까 ‘정보를 알아보고 돌아오는 길에 바람쐬러(..) 나갔다’라고 한 후 아카스트님과 이방인님과 함께 진행했습니다. 8화 말에 이미 9화의 시간적 배경이 되는 밤은 폭풍이 있을 것 같다고 묘사한 후였으니까, 바람 쐬겠다는 것은 핑계일 뿐이고 사실은 뭔가 일이 있다는 암시를 연결하기도 어렵지 않았습니다.

참가자 결석이 몇 회에 걸쳐 계속되면 주인공이 빠진 이유도 좀 더 길어질 수 있습니다. 소년H님이 나중에야 알게 된 사정으로 9, 10, 11, 12화를 빠지면서 로어틸리아가 일행에서 일탈한 시간도 24시간이 넘었고, 그래서 귀환 후 상의해서 ‘바람 쐬러’ 나간 로어틸리아가 어디서 뭘 하고 있었는지 (바람 쐬러 나갔다가 바람났다…?) 정했습니다. 여기서 나온 로어틸리아 24라는 글은 저와 소년H님만 볼 수 있게 권한 설정을 해서 위키의 장점 또한 십분 활용할 수 있었죠.

이 방법의 또 다른 장점은 참가자의 결석을 전화위복의 기회로 활용해 캠페인의 내용에 깊이를 더할 수 있다는 점입니다. 로어틸리아의 일탈은 졸지에 어미 닭 없는 병아리 나이트 없는 파다완 일행이 된 자락스와 센이 공의회로 귀환하는 중요한 계기가 되었고, 자연스럽게 코루선트의 상황으로 내용이 이어질 이유를 제공했습니다. 또한, 소년H님의 귀환 후 재회 장면을 연출하는 재미도 있었죠.

이렇듯 어느 정도 시간과 노력을 들이면 참가자가 빠진 것은 캠페인의 위기에서 또 다른 기회가 될 수 있다고 생각합니다. 적절한 제약이 창의성을 자극한다는 원칙은 참가자의 부재도 예외가 아니니까요.

2. 외전을 한다

상황에 따라서는 참가자가 한 명이라도 빠지면 본 캠페인 진행이 힘들 수도 있습니다. 지난번 세션에 악당이 ‘훗훗훗 드디어들 나타나셨나’ 하면서 등장하는 걸로 끝났다든지 해서, 갑자기 땅이 갈라져서 주인공 하나를 삼켰다는 식이 아니면 부재를 설명하기 어려울 때도 있죠.

이럴 때 제가 선호하는 방법은 캠페인 본편을 벗어나 외전을 하는 것입니다. 옛날 알데마르 캠페인 때 주인공 셋 중 하나가 빠져서 나머지 둘의 과거에 있었던 일을 진행한 것이 그 예입니다. 아예 두 명이 없었을 때는 남은 한 명의 과거 설정을 RP로 재현한 일도 있습니다.

외전 역시 캠페인에 깊이를 더한다는 면에서 긍정적이라고 생각합니다. 과거 이야기, 인물 간의 관계 등을 통해 본편 캠페인과는 다른 각도에서 인물과 사건을 조명한다는 점이 재미있죠.

외전의 또 다른 효용은 참가자의 결석보다 한결 난감한 경우, 즉 진행자가 빠졌을 때 대응책이 될 수 있다는 점입니다. 이 경우 참가자 중 하나가 부진행자 역할을 맡아서 진행자가 나올 수 없을 때 외전을 진행할 수 있을 것입니다. 언더월드 3기의 경우 진행자 제노시아님이 사정이 있을 때 제가 외전인 브루하 폭주전대를 진행한 경우가 그 예입니다. 그 외에도 참가자가 빠져서 본편 진행이 어려울 때 본편의 진행자인 제노시아님이 제가 진행하는 외전에서 참가자가 되기도 했었죠.

브루하 폭주전대의 경우 비슷한 시간대일 뿐 전혀 다른 캠페인에 가깝기는 했지만, 그 배경이 된 가상의 도시 뉴 세인트 헬렌이 나중에 본편에 합류한 유르겐의 배경에 나오는 등 연계가 생기기도 했습니다. 그 외에 본편의 주인공 하나와 조연 하나가 데이트하는 내용을 연애물 규칙인 얼음깨기 (Breaking the Ice)로 오체스님과 함께 진행하기도 했고요. 이렇듯 똑같이 외전이라고 해도 본편과 연계 정도, 규칙 등에서 여러 가지 변형이 있기 때문에 더욱 다채로운 캠페인이 될 수 있습니다.

3. 주인공을 다른 참여자가 제어한다

세 번째로 생각할 수 있는 대응으로는 다른 참여자, 보통은 진행자가 해당 주인공을 제어하는 방법입니다. 저는 별로 선호하지는 않지만, 주인공의 부재를 설명할 필요 없이 본편을 진행할 수 있다는 장점이 있습니다. 본편을 속행하거나 외전을 하는 방법에서도 부분적으로 사용하기도 합니다. 예를 들어 로어틸리아의 예에서 로어틸리아가 바람 쐰다며 나갔다고 진행자인 제가 서술한 대목이라든지, 로어틸리아가 다른 일행에게 보낸 홀로크론 메시지를 제가 간접 인용으로 전한 부분 등이 그 예입니다.

주인공을 타인이 제어하는 방법에는 소극적인 방법도 있고, 적극적인 방법도 있습니다. 소극적인 방법은 주인공이 그 자리에 있다는 정도만 알리고, 필요한 최소한의 행동만을 하는 것입니다. 반면 가장 적극적으로는 진행자 혹은 다른 참가자가 그 주인공의 모든 연기를 하는 것도 생각할 수 있겠죠. 전투 정도가 아니면 드문 경우겠지만요.

4. 세션을 쉰다

개인적으로는 참가자 한 명이 예고 없이 빠져서 세션을 쉰 적은 없으며, 이는 가장 최후의 수단이라고 생각합니다. 물론 위에 말했듯 참가자가 빠지면 차질이 생기지만, 플레이를 자꾸 쉬면 캠페인의 맥이 끊어지는데다, 성실하게 참여한 다른 참가자들에게 불공평하기 때문입니다.

물론 결석한 사람이 있는 김에 팀원들끼리 다른 활동을 하는 것도 가끔은 좋은 선택이라고 생각합니다. 다른 놀이를 한다든가, 캠페인의 제반 사항을 재점검하는 시간을 갖는다든가. 진행자나 참가자가 빠져서 본편을 진행할 수 없을 때를 대비해 전혀 다른 캠페인을 준비해서 진행하는 것도 가능하겠죠. 이런 방법은 위에서 얘기한 외전의 변형에 가까울지도 모르겠습니다. 그 캠페인의 세션은 쉬지만 플레이는 하니까요.

어쨌든 다른 준비를 한 게 아니면 참가자가 빠져서 세션을 쉬는 것은 원칙이라기보다는 예외인 것이 바람직한 듯합니다. 참가자가 빠지는 것 자체가 예외인 게 바람직하듯 말이죠.

이상과 같이 참가자 (혹은 진행자)가 빠졌을 때 생각할 수 있는 대응책들을 나열해 보았습니다. 제가 생각하지 못한 방법도 있을 것이고, 각 팀과 캠페인 사정에 따라 여러 가지 방법이 있겠죠. 약속은 소중하지만 때로 깨지기도 합니다. (저도 최근에 그런 경우가 있었죠..ㅠㅠ) 이에 대한 대응에 따라 캠페인에 대한 의욕, 나아가서는 캠페인의 존속 여부가 달라질 수 있다는 점에서 참가자 부재에 대한 대응은 진행자에게, 그리고 팀에게 중요한 과제라고 생각합니다.

물론 부재가 잦다면 참가자가 계속해서 참가할 수 있는지, 시간대가 적당한지 하는 의논이 필요하겠지요. RPG에 만병통치약이 있다면 그건 팀원 간의 활발한 의사소통뿐이니까요.