위키의 계층을 관리하는 방법

계층형 위키를 쓰며 느끼는 관리방법의 충돌에서 종종 ‘위키를 정리하려는’ 시도에 대해 느끼는 불편함을 이야기했습니다. 위키 소프트웨어가 처음 만들어졌을 때 위키는 그저 같은 위치에 여러 문서를 생성하고 연결하는 기능을 가지고 있을 뿐이었습니다. 도쿠위키의 네임스페이스나 컨플루언스의 트리 같은 기능은 없었는데 위키가 처음 만들어질 때로 돌아가 보면 이런 기능은 사실 위키에 별로 필요하지 않았습니다. 위키의 핵심은 같은 공간에 문서를 생성한 다음 이 문서가 다른 문서와 연결되는 것입니다. 다른 문서가 새로 생성한 문서를 향한 링크를 포함하거나 새로 생성한 문서가 기존 문서를 가리키는 링크를 포함하고 있으면 이걸로 충분합니다. 위키 문서는 다른 문서와 연결, 그리고 검색을 통해 존재를 알 수 있었고 다른 문서와 연결을 통해 그 위상과 분류, 계층 따위를 파악할 수 있었습니다.

이런 관점에서 위키에 어떤 주제에 따른 여러 문서를 나열하고 싶으면 문서를 나열한 모습을 표시할 새 문서를 하나 만든 다음 검색이나 링크 클릭을 통해 확보한 그 주제에 대한 문서 링크를 나열한 다음 저장하기만 하면 됩니다. 미래의 자신, 그리고 현재의 다른 사람들에게 조금 더 친절할 작정이라면 왜 이 목록의 문서들로 이동하는 링크를 이 페이지에 모아 뒀는지 맥락, 목적, 분류 기준 따위를 서술해 둘 수도 있습니다. 그러면 같은 위키를 사용하는 미래의 자신이나 다른 누군가가 이를 읽어본 다음 이 문서를 생성한 다음 추가된 같은 조건에 맞는 문서 링크를 추가해줄는지도 모릅니다. 위키는 이렇게 검색과 링크를 통해 여러 문서들이 같은 공간에 아무 문제 없이 서로 간에 관계를 맺으며 의미를 유지할 수 있었고 위키가 어지간히 커져도 같은 규칙으로 수많은 문서와 이들 사이의 관계를 통해 굳이 정리하지 않고도 수많은 문서들을 유지하고 또 사용할 수도 있습니다. 그런데 이런 모습은 위키 대신 컴퓨터의 디렉터리와 파일 구조를 기반으로 문서를 관리해 온 사람들에게는 익숙하지 않을 수 있고 또 정리되지 않은 것처럼 보일 가능성이 없지 않습니다. 이들은 어떤 목적이나 분류에 따라 디렉터리를 만들고 그 안에 파일을 넣어 두기를 좋아하는 것 같은데 윈도우나 맥 같은 환경에서 파일시스템에 파일 사이의 관계를 정의할 방법은 없기 때문에 디렉토리야말로 거의 유일한 문서 정리 방법이라고 할 수 있습니다.

서기 2024년 현재에도 맥에서 기껏해야 파일에 태그를 다는 정도의 기능을 제공하지만 이 정도로는 여전히 디렉토리를 만들고 그 안에 파일을 두는 정리 방식에 근본적인 변화를 일으키거나 개선할 수 있는 수준의 변화는 아닙니다. 물론 다행스럽게도 시간이 흐르며 점점 더 컴퓨터 로컬에 파일을 작성하는 경우가 줄어들고 있으며 특히 기업 단위에서는 규모가 커질수록 문서를 파일과 디렉토리 단위로 관리하는데 한계에 다다라 더 이상 문서를 파일 단위로 관리하지 않도록 컨플루언스 같은 기업용 위키를 도입합니다. 덕분에 로컬에 디렉토리를 만들어 문서를 분류할 일은 점점 줄어들고 있지만 그렇다고 해서 그 습관이 사라지지는 않아서 애초에 디렉토리 같은 계층구조를 만드는 기능을 제공하지 않고 시작한 위키 조차도 이런 기능을 제공하기 시작했는데 어쩌면 전통의 디렉토리와 파일에 기반한 관리 습관을 위키에서도 비슷하게 유지하기를 원하는 사용자들의 요구 때문이었을지도 모릅니다. 덕분에 위키는 근본적으로 문서들 사이의 연결에 의해 문서가 의미를 가지고 그 자체로 분류됨에도 불구하고 계층구조를 만들어 문서를 어떤 계층에 위치 시키느냐에 따라 문서가 잘 정리되었거나 그렇지 않은 상태라고 판단하는 사람들이 나타나는 것 같습니다.

하지만 아무리 계층구조 기능이 생겨도 위키는 위키라고 생각해 지금 이 글을 계층구조 기능이 있는 컨플루언스 위키의 적당한 위치에 문서를 생성한 다음 타이핑 하고 있지만 이 문서가 어떤 계층구조 상에 잘 분류되어 있지는 않습니다. 그저 한 달 단위로 생성하는 새 계층 하위에 있을 뿐입니다. 이 문서가 실제로 의미를 가지기 위해서는 특정 뉴스레터 회차에 들어갈 글을 모아 놓는 또 다른 페이지에 연결되기 때문입니다. 제 개인 위키는 이렇게 계층구조 기능이 있는 위키임에도 계층구조에 크게 신경 쓰지 않고 제가 편한 대로 느슨하게 관리하면서도 아무 문제도 겪지 않을 수 있습니다. 하지만 회사 단위에서 사용하는 위키는 여러 사람들이 사용하기 때문에 개인 위키처럼 느슨하게만 사용할 수는 없는 것 같습니다. 가령 최근에 수행한 업무는 그 동안 오랜 기간에 걸쳐 문서를 마구 작성해 대충 쌓다 보니 문서가 팀 공간 하위에 잘 정리되지 않은 상태로 아무렇게나 배치되어 있어 문서를 찾기 힘들기 때문에 문서 구조를 좀 정리해서 찾기 쉽게 만들라는 것입니다.

듣는 순간 이 업무는 모든 사람들의 마음에 들도록 수행할 수 없는 업무라는 사실을 바로 인식했지만 그렇게 말할 수는 없었는데 자신도 모르게 회사에서 컨플루언스를 사용하며 오랜 기간에 걸쳐 위키를 익숙하게 사용하는 사람들도 이 시스템이 먼 옛날 위키위키로부터 만들어진 도구이며 위키위키의 규칙에 따르면 굳이 계층구조를 관리하거나 정리하지 않아도 된다는 사실을 설명해낼 자신이 없었기 때문입니다. 그래서 마음 속으로는 모든 사람들을 만족 시킬 수 없고 또 사실상 불필요한 업무이며 제 관점에서 의미 없는 업무임에도 불구하고 일단 어떻게든 진행해 결과를 내기로 마음 먹습니다. 한편으로 이 과정을 통해 위키위키에 익숙한 사람 관점에서 디렉토리와 파일 구조에 익숙한 사람들을 만족 시키는 적절한 계층구조 관리 방법에 접근할 수 있을른지도 몰랐습니다.

일단 그 동안 팀이 생산한 문서들이 포함된 공간 전체를 살펴봅니다. 컨플루언스에는 페이지 트리 매크로가 있는데 계층구조 기능을 제공하는 거의 모든 위키에 같은 기능이 있을 것 같습니다. 문서를 하나 만든 다음 여기에 페이지 트리 매크로를 넣고 정리하기를 원하는 공간의 맨 위에 있는 문서를 넣으면 이 문서 하위에 포함된 모든 문서를 트리 모양으로 정리해 주는 기능으로 이 덕분에 정리해야 하는 공간에 포함된 모든 문서 목록과 이들의 계층구조를 한 번에 확보할 수 있습니다. 사실 어느 조직이나 이렇게 전체 계층구조를 살펴보면 사람 사는 거 다들 비슷하다는 사실을 잘 알 수 있는데 처음에는 문서를 어떤 명시적이지 않은 규칙에 따라 조금씩 생성하다가 문서가 늘어나자 이들을 명시적인 규칙에 따라 조금 정리해야 한다고 생각해 이를 시도한 흔적이 보입니다.

하지만 이런 문서 정리는 이를 충분히 고민하지 않았다면 명시적인 규칙을 만들었음에도 순식간에 이 규칙으로 커버할 수 없는 상황이 발생하면 규칙이 깨지고 한 번 규칙이 깨지면 문서는 다시 문서를 작성하는 각자가 편안하게 생각하는 명시적이지 않은 규칙에 따라 정리 아닌 정리가 이루어집니다. 이런 상황에서 어떤 문서는 현재 유효하지만 또 다른 문서는 현재 더 이상 유효하지 않게 되기도 하는데 같은 공간에서 링크만으로 연결된 위키에서는 아무 것도 안 해도 되지만 계층 구조로 관리되는 위키에서는 유효하지 않은 문서를 어딘가 눈에 안 띄는 다른 트리로 치워야만 할 것 같은 압력을 느끼는 것 같습니다. 이런 문서들은 주로 ‘기타’, ‘창고’, ‘고대문서’ 같은 문서 하위에 나열되는데 어느 순간 현 시점에 유효한 문서보다 이런 분류 없는 분류에 분류된 문서가 더 많은 시점이 찾아오기도 합니다.

한번 이런 ‘창고’에 분류된 문서는 정말 더 이상 이 문서를 찾아볼 일이 없지만 그렇다고 삭제할 수는 없는데 일단 이 문서의 존재 자체가 팀이 여태까지 해 온 일을 나타내는 증거이기도 하고 또 미래의 누군가가 이 문서들을 살펴보고 기존 업무 진행 과정을 파악할 일이 있을지도 몰랐습니다. 실제로 그런 일이 일어날 거라고 아무도 생각하지 않았지만 지난 따라잡기에서 저 자신에게 실제로 그런 일이 일어났고 현재 유효하지 않은 문서이지만 현재 빌드 상태를 만드는데 기여한 온갖 문서들을 살펴보고 이들로부터 서서히 현재에 가까워지며 무슨 일이 일어났는지 행간을 파악할 수 있어 좋았습니다. 그렇다 보니 이 문서들을 함부로 없앨 수 없습니다. 그러면서도 이런 사실상 분류를 포기한 현재 유효하지 않은 문서들이 계층구조의 일부를 차지하고 있다는 사실이 디렉토리와 파일 기반으로 문서를 관리해 오던 사람들에게 그리 편안하지는 않은 상태를 만드는 것 같습니다. 그러므로 이 문서들은 삭제해서는 안되지만 그렇다고 또 ‘기타’, ‘창고’, ‘지하창고’ 같은 분류를 사실상 포기한 분류에 그대로 방치하자니 또 마음이 편안하지는 않은 기묘한 상태가 되어 어떻게 해야 할 지는 잘 모르겠지만 어떻게든 해야 한다고 생각하는 상태를 만들게 됩니다. 이 업무를 맡은 다음 계층구조를 살펴보고 그저 다른 여느 프로젝트나 팀에서 겪는 것과 똑같은 상태일 뿐이며 사실 위키를 사용하는 이상 이런 상태를 피하기 어렵고 사실은 현대적인 검색과 링크를 통해 정리할 필요도 없음을 설명할까 하는 충동을 잠깐 느꼈지만 이번에도 잘 참아냅니다. 그러니까 제 스스로는 동의하지 않지만 어쨌든 계층구조를 만들고 이를 통해 문서를 정리할 계획을 도출해야 하는 상황입니다.

문서를 디렉토리 구조로 분류하고 싶어하는 사람의 마음에 본격적으로 빙의하기 전에 개인적으로 어떤 분류가 분류에 실패한 증거로 보는 가장 큰 증거는 ‘기타’라는 분류가 있다는 것입니다. 처음에는 팀에서 생산하는 여러 가지 문서를 분류할 적당한 분류가 있었을 겁니다. 그리고 이 시점에는 어쩌면 문서를 새로 만들 때 지켜야 하는 명시적인 규칙이 있었을는지도 모릅니다. 하지만 앞에서 설명한 대로 상황을 충분히 고려하지 않은 채 대강 만든 규칙은 아주 간단한 예외에도 쉽게 깨집니다. 가령 프로젝트를 처음 시작할 때 팀에서 할 업무에 따라 위키에 ‘마일스톤 계획', ‘전투’, ‘시스템’, ‘컨텐츠’ 등으로 구분한 다음 문서를 생성할 때 맞는 분류의 하위 계층에 문서를 만들라고 했다 치면 아주 잠깐 동안은 이 규칙이 잘 동작할 겁니다. 그런데 본격적으로 퀘스트 시스템을 개발하기 위해 가칭 퀘스트 TF를 구성하고 보니 매일매일 TF로부터 생산되는 문서를 빠르게 작성할 계층구조가 필요했는데 기존 계층에 따르면 퀘스트 시스템에 해당하는 문서는 시스템 하위에, 퀘스트 컨텐츠에 해당하는 문서는 컨텐츠 하위에 넣어야 할 것 같습니다. 하지만 TF의 생명은 빠른 의사결정과 실행에 있으므로 매번 짧은 논의를 할 때마다 이를 적당한 위치를 고민해 생성하는 대신 그냥 ‘퀘스트 TF'라는 새로운 상위 계층을 만들어 그 안에 TF에서 생성한 문서를 적재하기로 합니다. 이미 명시적인 계층구조 관리 규칙이 깨졌습니다.

이런 과정을 몇 번 반복하다 보면 이제 처음 만들어진 고착화된 계층구조에는 전혀 맞지 않는 문서들이 나타나기 시작하는데 가령 회의록, 회의록의 액션 플랜을 수행한 기록, 리서치 문서, 리서치 결과에 의한 액션 플랜 등등의 문서가 나타나고 또 개발팀 역시 사람 사는 곳이기에 근처에 회식으로 갈만한 술집 목록, 일정 기간마다 수행하는 자산 실사 관련 문서 따위를 만들 곳도 필요해지는데 이 때마다 적당한 계층 구조를 정의하지 않으면 순식간에 ‘기타’ 문서가 생기고 이 아래에 온갖 문서가 주렁주렁 달리게 됩니다. 위에서 ‘기타’라는 분류가 있다는 사실은 분류에 실패했다는 사실을 보이는 증거라고 설명했는데 이 ‘기타’는 한 번 생기면 이제부터 사람들은 새 문서를 만들 때 이 문서가 들어갈만한 계층을 고민하는데 시간과 자원을 사용하는 대신 그냥 일단 기타 하위에 문서를 만들어 시간과 고민을 절약합니다. 순식간에 기타가 나머지보다 커지고 모든 문서가 기타 하위에 있으며 나중에는 중요한 보고 문서조차 기타 하위의 ‘중요 보고 문서’ 계층 하위에 있는 지경에 이르지만 사실 여전히 이런 상황에서도 위키는 문제 없이 동작하며 수 없이 많은 사람들이 생산한 문서를 저장하고 연결하고 검색해 팀 뿐 아니라 회사의 업무 전체를 지탱하는데 아무런 문제가 없습니다. 다만 한동안 계층구조 관리를 게을리 한 누군가가 어느 날 문서들이 나열된 트리를 살펴보고 거대해진 ‘기타’를 본 다음 마음 한 구석에 ‘이 문서를 정리해야 할텐데…’라며 걱정하기 시작하게 만들 뿐입니다.

사실 문서를 디렉토리 기반으로 관리하는 사람의 마음에 빙의해 팀이 생산한 온갖 문서를 살펴본 다음 이들의 업무 분류를 만드는 것은 그리 어렵지 않습니다. 팀은 굵직굵직한 몇몇 업무에 집중하고 있으며 이에 따라 분류를 만들면 사실상 거의 모든 문서를 커버할 수 있습니다. 만약 이 계층구조에 맞추기 애매한 문서가 나타나 ‘기타’를 만들어야 할 것 같은 충동이 든다면 ‘기타’를 만들기 전에 기존 계층구조가 그 사이에 변화한 팀의 업무 범위를 커버하지 못할 가능성을 의심해 봐야 합니다. 그래서 충동에 따라 ‘기타' 분류를 만들어 분류에 실패하기보다는 기존 계층구조를 개편할 때가 왔다는 신호로 받아들여 이 업무의 등장을 팀에 알리는 편이 더 좋습니다. 그래서 이번에도 맨 먼저 시작한 일은 ‘기타’, ‘창고’, ‘지하창고’, ‘고대문서’ 같은 분류에 명백히 실패한 증거들을 모두 파괴하고 이 안에 있던 문서를 끄집어내 각자의 올바른 분류에 따라 위치를 조정한 것입니다. 아무리 오래되고 또 현재 유효하지 않은 문서라도 이 문서들은 명백히 특정 분류에 해당하는 업무를 수행하는데 사용했기 때문에 이 문서들이 특정 분류의 하위에 있어야만 이 분류의 업무 히스토리를 파악하는데 도움을 받을 수 있습니다. 만약 오래된 문서가 전혀 엉뚱한 ‘창고’에 들어가 있으면 창고 바깥 분류로부터는 업무 히스토리를 파악할 수 없을 겁니다.

그런데 이렇게 창고를 파괴하고 그 안에 있던 문서를 전부 끄집어내 다시 정리하기 시작하면 바로 이어 나타나는 문제는 한 계층 하위에 오래된 문서와 새 문서, 현재 유효하지 않은 문서와 현재 유효한 문서가 동시에 나타나게 된다는 점입니다. 히스토리를 파악하려는 입장에서는 그저 문서들이 계층 하위에 시간 순서대로 나열되어 있기만 하면 그만이지만 당장 업무에 집중해야 하는 사람들 입장에서는 현재 유효하지 않은 문서들이 동시에 나타나면 헛갈릴 수 있고 또 정리되어 있지 않다고 느낄 수도 있습니다. 사실 위키위키의 특징 중 하나는 문서를 수정함에 따라 모든 이전 버전을 저장해 원한다면 문서의 최초 상태로 돌아갈 수도 있다는 점입니다. 간단한 오타 하나를 수정하기만 해도 이 수정 전 문서와 수정 후 문서가 따로 저장되어 각 버전을 살펴볼 수 있습니다. 이를 활용해 위키위키를 처음 만든 천재들은 사람들이 한 가지 업무를 수행하며 문서 하나를 계속해서 업데이트 해 한 주제에 대한 한 문서만 존재하고 이 문서의 과거 상태를 보고 싶으면 문서의 이전 버전을 살펴보면 된다고 생각했을지도 모릅니다. 하지만 거의 모든 위키의 검색 기능이 문서의 이전 버전을 대상으로 하지 않으며 사람들은 그런 천재들과는 달리 매 시점마다 새로운 문서를 만들기를 반복해 문서가 버전에 의해 관리되는 대신 새로운 문서와 오래된 문서로 나뉘는 모양을 만듭니다.

이런 상황에 제가 제 개인 위키에 사용하는 방법은 별로 좋아하지 않았고 위키위키의 정리 방법이라고도 생각하지 않았지만 계층을 사용하는 것입니다. 어떤 계층을 열면 최상위에는 현 시점에 유효한 문서들만이 나열됩니다. 그러면 오래된 문서, 그리고 현 시점에 유효하지 않은 문서들은 어디 있을까요. 바로 현 시점에 유효한 최상위 문서들의 하위 계층에 있습니다. 위키위키는 한 문서의 버전을 관리해 주지만 실제 여러 사용자들은 새 문서를 만들며 이전 문서를 오래된 문서로 만드는 방법으로 본의 아니게 위키 시스템이 제공하지 않는 방식으로 문서를 관리하고 있으니 이 문서들을 계층구조의 더 안쪽에 배치하는 방식으로 버전을 관리하려는 시도입니다. 최상위에 현재 유효한 문서, 그 하위에는 그 문서에 기반해 현재 진행 중인 논의 문서, 그리고 현재 문서가 있게 만든 그 이전 버전 문서나 팀 내 피드백에 사용한 문서, 또 그 하위에는 그 문서를 만들게 한 업무 지시, 하이컨셉, 방향성 문서 따위가 나열되어 계층구조의 더 깊은 곳으로 이동할수록 더 오래된, 더 근본의 문서들이 나타납니다. 이렇게 문서를 배치하면 당장 현 시점에 가장 유효한 문서에 빨리 접근할 수 있고 또 히스토리를 파악하려면 문서 계층의 점점 더 깊은 곳으로 접근해 감에 따라 오래된 문서를 만날 수도 있으며 이 과정에서 문서를 창고에 넣을 일도 잘 일어나지 않습니다. 창고에 넣는 대신 그저 계층구조의 더 깊은 곳으로 옮기면 그만이기 때문입니다.

또 하나, 이런 식으로 기존 구조를 고치려 한다면 처음부터 실제로 문서를 옮기면 안됩니다. 드라이 런이라고 부를 수 있을 것 같은데 앞에서 위키위키 개념을 설명할 때 특정 주제의 문서를 나열한 문서를 만드는 과정을 설명했습니다. 이와 비슷한 요령으로 처음부터 실제 문서를 옮기면 중간에 생각이 바뀌거나 다른 피드백을 받음에 따라 이미 옮겨 버린 문서의 이전 상태를 파악하지 못해 큰 어려움에 빠질 수 있습니다. 도쿠위키는 문서 위치를 이동할 때 위치 이동 역시 버전 기록에 표시되어 원하면 이전 위치로 되돌릴 수 있지만 컨플루언스는 위치 이동을 버전으로 기록하지 않아 만약 이전 상태로 되돌려야 하는 상황을 맞는다면 이 요구 처리가 불가능할 수도 있습니다. 그래서 먼저 새 페이지를 하나 만들고 그 안에 이전 상태와 변경된 상태 제안을 함께 만들어 제안하면 피드백을 받을 수도 있고 또 변경된 상태를 점검하며 미리 문제를 파악해 수정할 수도 있습니다. 그리고 최대한 많은 사람들의 동의와 피드백을 받은 다음 - 모든 사람의 동의를 얻기는 불가능함 - 그 결과를 반영하고 이를 기록한 페이지의 계획에 따라 실제 이동을 수행해야 합니다.

이렇게 해서 다음 주 한가한 시간을 찾아 계획에 따라 문서 재배치를 실행할 작정입니다. 개인적으로는 처음 이 일을 시작할 때 위키를 정리한다는 행동 자체에 동의하지 않았으며 이 행동의 필요성에 대해서도 전혀 동의하지 않았습니다. 하지만 문서를 디렉토리 모양으로 관리하기를 원하는 사람의 요구가 존재한다는 사실을 부정할 수는 없었기에 일을 시작했고 팀의 업무 단위에 따라 카테고리를 구분해 문서를 옮겼고 오래된 문서를 ‘창고’에 넣는 대신 창고를 파괴하고 오래된 문서를 트리의 더 깊은 곳에 인과관계에 따라 배치해 명백한 분류 실패의 증거인 ‘기타’ 분류를 제거합니다. 덕분에 팀에서 수행하는 굵직굵직한 업무 거의 전체를 파악할 수도 있었고 또 저 같은 일종의 위키 순수주의자 관점에서 계층구조를 관리하려는 요구사항에 대응한 사례 하나를 만들었습니다.