밀피유의 이야기

위키에 문서를 정리하다 보면 더 이상 사용하지 않고, 어느 문서에도 연결되지 않는 문서들이 생깁니다. 사실은 애초부터 계획적으로 문서를 작성한다면 이런 일이 일어나지 않거나 덜 일어나겠지만, 제가 문서를 만드는 이상 문서를 체계적이거나, 계획적으로 만들지는 않습니다. 덕분에 금방이라도 사용할 것 같은 문서들이 우수수 생겨났다가, 순식간에 모두 사용하지 않게 됩니다. 이런 일이 반복되다 보면 위키는 실제로 참고할 수 있는 페이지는 몇 개 안되는 문서의 쓰레기장이 되어 버립니다.

한번은 위키를 함께 사용하는 동료분으로부터 '위키를 리셋해버리자'라는 제안을 들었습니다. 기존에 사용하는 위키로부터 현재 사용하는 것이 확실한 문서들을 수동으로 새로운 빈 위키에 옮기자는 것이었습니다. 거대한 문서의 쓰레기장으로부터 사용 가능한 문서를 끄집어내기에 가장 적절한 방법입니다. 더 이상 사용하지 않는 문서를 구분해 문서에 표시하거나, 삭제하는 수고 보다는 하나하나 사람이 읽어 옮기더라도 사용하는 문서만 추려내는 쪽이 훨씬 적은 수고가 듭니다. 하지만 이런 식으로 위키를 리셋하는 일도 만만한 일이 아니고, 제가 생각하는 것과도 약간 차이가 있어 좀 생각해봤습니다.

제 입장은 위키에 문서가 적당히 뒤엉키더라도 그대로 놓고 쓰자는 쪽입니다. 위키는 블로그와는 달리 문서들이 아주 느슨한 구조로 연결되어 있기 때문에 문서를 특별히 삭제하지 않아도 연결 관계를 통해 사용되는 문서와 사용되지 않는 문서를 구분할 수 있고, 위키를 아주 계획적으로 사용하지 않는 이상은 사용하지 않는 문서가 계속해서 발생하는 것을 막을 수 없다고 생각하기 때문입니다. 그래서, 애초에 막을 수 없다면 그런 특성을 인정해야 한다고 생각합니다. 하지만, 여전히 문서를 일괄적으로 조회해 보면 사용하고 있는 문서와 사용하지 않는 문서를 구분할 수 없기 때문에 문제는 남아있습니다.

뭔가 기술적인 방법으로 해결할 수 없을지 고민해 보다가, 어느 문서에도 연결되지 않았거나, 연결이 고립된 문서들 중에서, 액세스 기록을 남겨 장기간 액세스 되지 않은 문서를 더 이상 사용하지 않는 문서로 판단해 문서에 무슨 표시를 해준다든지 하는 방법은 어떻까 하는 생각이 들었습니다. 어쩌면 가능성이 있을지도 모르겠네요.

그런 의미에서, 위키를 사용하시는 다른 분들께서는 이렇게 위키에 더 이상 유효하지 않은 문서들이 생겨날 때 어떻게 관리하시는지 궁금합니다. :)

파일을 관리하는데는 파일 이름과 카테고리가 전부입니다. 사실, 파일에 메모를 붙여 두고 싶다든지, 파일 내부에 갱신 이력을 입력해 두고 싶은 욕망도 있고, 방법도 있지만, 파일 이름과 디렉토리 분류를 통한 카테고리 관리는 가장 원초적이고, 어떤 플랫폼에서도 사용 가능한 관리 방법입니다. 예전에 'mdir'을 사용할 때는 파일에 간단한 태그를 달아둘 수 있었습니다. 방향키로 파일 위에 커서를 갖다 대면 화면 한쪽에 파일에 달아 둔 태그가 보였는데, 그때는 파일 이름에 8글자가 한계였으나까, 그것만으로도 상당한 도움이 됐습니다. 하지만 그때는 변변한 검색 방법이 없었고, 파일 갯수가 좀 늘어나자 순식간에 넉다운됐지요. :)

카테고리는 파일 이름으로 만든 것을 해결할 수 없고, 한 디렉토리에 파일 갯수가 늘어나면 방금 이야기한 것 처럼 넉다운되기 쉬우니까 웬만하면 해야 합니다. 카테고리는 보통 파일시스템의 디렉토리에 의존할텐데, 파일의 용도에 따라 디렉토리를 구분하는 식으로 이루어집니다. 아이템 기획서는 '아이템' 디렉토리 아래에 두고, NPC 기획서는 'NPC' 디렉토리 아래에 둡니다. 또, 이 디렉토리들은 다시 '시스템 기획서' 디렉토리 아래에 두는 식입니다. 간단하고, 논리적인 구조와 물리적인 구조가 똑같기 때문에 아무데나 복사해도 유실되는 정보가 없기 때문에 사용하기도 편리합니다. 물론, 카테고리를 유지하는데는 관리자의 사용자들의 상당한 노력이 필요합니다. 일하다 보면 다른 디렉토리에 파일을 넣는 건 일도 아니거든요.

처음에 소스세이프로 문서를 관리하기 시작하면서 가장 좋았던 점은 여러 카테고리에 포함되는 파일을 복사해 놓을 수 있었다는 점입니다. 아이템 데이터 파일인 'ItemData.xls'가 있다고 합시다. 이 파일은 아이템 관련 파일이라서 '아이템' 디렉토리 아래에도 들어가 있어야 하고, 데이터 파일이기 때문에 '데이터' 디렉토리에도 들어가 있어야 합니다. 시스템 기획자는 기획서와 이 데이터 파일을 동시에 꺼내 일하고 싶어하고, 프로그램 작업자들은 데이터 디렉토리에서 이 파일을 다른 데이터들과 동시에 꺼내 작업하고 싶어합니다. 파일과 디렉토리만으로 구성된 물리적인 구조에서는 이런걸 하려면 유닉스 계열에서는 링크를 걸거나, 윈도우 계열에서는 보기 싫은 '바로가기'를 사용해야 했습니다. 보통 데이터 파일은 데이터 디렉토리에 넣고 기획서쪽에서 바로가기 아이콘을 사용하는 식이었지요. 하지만 소스세이프의 'Share' 기능을 사용해 간단히 이런 문제를 해결할 수 있었습니다.

소스세이프에서 '프로젝트'로 관리하는 단위는 파일시스템의 '디렉토리'와 똑같습니다. 그래서 문득 물리적인 구조와 논리적인 구조가 다르다는 점을 착각하기 쉬운데, 소스세이프에 보이는 프로젝트의 트리 구조는 노리적인 구조입니다. 실제 파일이 보관되는 디렉토리를 열어보면 알 수 없는 알파벳으로 구성된 디렉토리와 파일이 늘어서 있을 뿐이지요. 물론, 파일 사이즈로 검색하면 원하는 파일이 어느 파일에 기록되어 있는지 알 수 있기는 합니다. 소스세이프가 중간에서 물리적인 파일과 논리적인 파일 사이의 기록을 알아서 관리해주고 있기 때문에 편안하게 논리적인 구성만 잘 조율하면 파일을 카테고리별로 그럭저럭 잘 관리할 수 있습니다. 이전에 이야기했던 마인드매니저를 이용해 임시로 문서를 관리하는 것 보다 더 좋은 '평소에 실천하면 좋은' 방법입니다.

단, 제 의견은 파일 이름에 버전 번호나 날짜를 기록하는 것은 권장하지 않습니다. 어느 버전 관리 시스템도 파일 이름과 파일 해시코드에 의존하는데, 둘 중 하나가 변경되면 버전관리에 문제가 생깁니다. 파일 내용이 변경되면 해시코드가 변경되어 파일이 변경된 것으로 인식되지만, 파일 이름이 변경되면 이 파일은 '새로운' 파일입니다. 파일의 이전 버전과 아무런 연관관계도 만들어지지 않고, 이런 파일이 늘어나면 버전관리 시스템의 원래 목적을 수행할 수 없게 됩니다. 함께 일했던 기획자들도 이렇게 파일 이름에 날짜와 버전 번호를 붙이는 일이 많았는데, 날짜는 파일 정보에 함께 기록되고, 버전 번호는 오피스 문서라면 파일 자체에 '리비전' 번호가 기록되기 때문에 따로 기록할 필요가 없습니다. 또, 버전 관리 시스템을 사용한다면 버전 관리 시스템이 알아서 관리해 주는 버전 번호도 있지요. 누군가가 '아이템 기획서 최신 버전이 뭐야?'라고 물으면 '5513' 이라고 대답해줄 수 있습니다. 그래서, 어차피 따로 기록되고, 알아서 관리되는 이상 파일 이름에 이들을 기록해서 버전관리 시스템에 혼란을 일으키는 건 지양해야 한다고 생각합니다.

단, 날짜를 이렇게 관리할 때는 주의할 점이 하나 있습니다. 종종 파일 날짜를 유지해 주지 않는 전송 프로토콜이 있기 때문인데, 대표적인 것이 FTP입니다. FTP를 통해 작업 파일을 전송해야 한다면 압축하거나, 다른 방법을 사용하는 편이 좋습니다.

제 의견을 정리하면, 문서 관리를 할 때 논리적인 구조와 물리적인 구조를 다르게 하면 카테고리를 보다 유연하게 관리할 수 있다는 것과, 파일 이름에 버전 번호나 날짜를 기록하면 버전 관리에 상당한 애로사항을 겪게 된다는 것입니다.

이 글은 스프링노트에서 작성되었습니다.

며칠 전에 이야기한 마인드 매니저를 이용한 문서관계관리 실험에 적당히 포함되는 이야기입니다. 문서 하나를 만들면 문서를 완성한 상태로 유지되는 시간은 그리 길지 않습니다. 여러 가지 이유로 문서는 반드시 수정되어야 합니다. 잠깐 프로그래머와 나눈 이야기의 결과만으로도 많은 것들이 변할 수 있는데, 이것들을 기록해 두지 않으면 며칠 못 가서 문서는 완전히 쓸모 없는 딴 세상 소리를 지껄이게 되고 맙니다. 무슨 이야기를 하건, 무슨 변경사항이 있건 간에 문서에 기록을 남겨야 합니다. ... 다들 알고 있지만 생각처럼 잘 되지는 않습니다. 이야기를 나눈 직후에 파일을 열어 문서를 수정할 수 있을 정도로 문서 작성의 고수라면 게임 회사에서 기획서나 정리하며 박봉에 시달리지도 않을 겁니다.

워드프로세서에는 참 다양한 기능이 있습니다. 문서에 메모를 첨부하거나, 이전 버전과 현재 작업 버전을 비교해 변경된 부분에만 밑줄을 그어뒀다가 검토자가 변경사항을 승인해야만 문서에 실제로 반영되는 기능을 사용할 수도 있습니다. - 일단 MS워드에선 그렇습니다. - 하지만 어째서인지 이 기능을 제대로 활용하는 경우를 몇번 못 봤습니다. 이 기능을 아는 사람들은 기능을 유용하게 사용하곤 하지만, 작업자 중에 한명이라도 이 기능에 익숙하지 않은 사람이 있다면 분명 이렇게 말할 겁니다. '이거 이상해. 서식 적용도 안했는데 빨간 밑줄이 그어져.'

며칠 전에 이야기한 문서관계관리에서 중요하게 생각한 점은 웬만하면 기존 작업자들을 괴롭히지 말아야 한다는 것입니다. 물론, 회사 내의 어떤 부서들처럼 강력한 문서관리 정책을 작업자들에게 제시해서 목차와 수정사항까지 깔끔하게 정리된 문서를 받아볼 수도 있겠지만, 그 정도 문서작업에 투입됐을 인적 자원을 생각하면 감탄 이전에 눈물이 앞을 가립니다. 마치 민방위에 처음 나가서 받아온 안내 책자를 볼 때와 비슷한 느낌입니다. 작업자들에게 강력한 문서관리 정책을 지키도록 하는 것도 중요하지만, 일단은 작업자들이 웬만하면 작업 방식을 그대로 유지한 채로 정리만 할 수 있으면 좋겠습니다.


일단, 이런식으로 문서 파일을 정리하고 있습니다. 카테고리와 파일은 아무렇게나 배치해도 상관 없기 때문에 필요한 아무 장소에 새로운 카테고리를 추가하거나, 설명을 붙일 수 있습니다. 파일은 다들 svn에서 체크아웃해 똑같은 디렉토리 구조로 다운받아서 들고 있어서 워드 아이콘을 누르면 바로 문서를 구경하거나 편집할 수 있습니다. 사실, 문서를 이렇게 논리적인 구조로 관리하기 시작하면 물리적인 구조에 신경을 덜 쓰게 되고, 나중에 물리적인 구조에 신경써야 하는 시점이 됐을 때 꽤 고달프게 될 수도 있습니다. 일단 정리가 잘 된 것 같아 보였지만, 위에서 이야기한대로, 문서에 수정을 가하기 시작하면 어떨까요.


문서를 수정해야 하는 상황은 정말 자주 일어납니다. 며칠 전에 읽었던 게임 개발 서적에서는 수정사항이 발생했을 때 빡세게 정성을 들여 문서를 다시 수정해 놓을 것을 권장합니다. 문제를 찾을 수 없는 훌륭한 방법인데, 쉽지는 않습니다. 다음 프로젝트에서는 꼭 그렇게 할 수 있기를 바라지만, 일단 지금의 문제를 수습하는데 초점을 맞춰 보겠습니다. 문서의 수정사항은 여러 가지 경로를 통해 나타나는데, 이것들은 원래 문서와 잘 통합되지 않습니다. 휘갈겨 적은 노트, 포스트잇, 다른 사람에게 날아온 메일이나 메신저 메시지들. 바로바로 문서에 통합하기에는 수고가 많이 들고, 그대로 쌓아두자니 답답합니다만, 제 아이디어는 이렇습니다. 변경사항을 당장 문서에 반영할 수 없다면, 일단 그냥 날아온대로 쌓아두자는 겁니다.

쌓아 둔 수정사항은 또 다른 문서파일이 될 수도 있고, 아웃룩 메모나, 메일이 될 수도 있습니다. 아니면 해외에서 날아온 수정이나 확인사항이 가득히 적힌 엑셀 파일일 수도 있지요. 이것들을 깔끔하게 통합할만한 관리 솔루션을 본적이 없기 때문에, 마인드 매니저에서는 이것들을 원래 문서 뒤에 서브 토픽으로 그냥 붙여둡니다. 원래 '문서.doc'를 참조하려는 사람들은 뒤에 붙어있는 파일을 함께 읽어야 합니다.


그대로 언제까지 놔둘 수는 없습니다. 예전에 저런 식으로 원래 문서의 수정 없이 계속해서 수정사항을 쌓아버린 사례 하나를 오래 전에 사용하던 공유디렉토리에서 발견했는데, 정말 대단했습니다. '수정사항', '또 다른 수정사항', '최신 수정사항', '오늘자 수정사항' ...... 연구해볼 만한 사례입니다만, 저런식으로 일이 처리된 걸 보면 신기하기 짝이 없습니다. 당연히, 작업 중간에 작성된 저 모든 문서들이 '잘못된 사례 분석' 이외에는 아무런 용도로도 사용될 수 없었습니다. 절대 저렇게 해선 안되고, 저 상태로 방치해서도 안됩니다.

그러면, 시간이 났을 때 '문서.doc'를 작성한 담당자가 문서 뒤에 서브토픽으로 달려 있는 내용들을 원래 문서에 병합해야 합니다. 물론 이것도 귀찮긴 하지만, 그때그때 병합하지 않는 정도로도 꽤 타협할만 하다고 생각합니다. 단, 병합이 끝났다고 해서 바로 서브 토픽을 지워버릴 필요는 없을 것 같습니다. 병합이 완료되었다는 표시를 해두고, 서브토픽들이 모두 병합될 때까지 잠시 그대로 놔둡니다. 아니면 기간을 정해놓고 그 기간이 지난 병합이 완료된 서브토픽만을 선택적으로 지울 수도 있겠죠.

만족할만한 깔끔한 방법은 아닙니다만, 일단 당장의 상황을 수습하기에는 적당하다고 생각합니다. 문서가 자기 역할을 다하기 위해서는 개발 상황에 따른 변경사항의 철저한 업데이트만큼 훌륭한 방법은 없습니다 ... 만, 그걸 실천하기 너무너무너무너무 힘들다면 이런 방법도 고려해볼 '수'는 있습니다. :(

문서가 문서 자체만으로 완결성을 가진다면 참 좋겠지만, 그렇지 않은 경우가 더 많습니다. 문서는 문서 외부로부터 참조해야 하는 여러 가지 자료를 포함합니다. 보통 표나 그림인 경우가 많은데요, 워드프로세서에 많은 기능이 추가되면서 표나 그림을 워드프로세서 자체에서 해결할 수 있게 되었지만 여전히 전문적으로 표나 그림을 다루는 프로그램을 사용해야 하는 경우에는 문서가 파일 하나만으로 완결되지는 않습니다. 거기에, 다른 문서와 상호 의존적인 부분이 있는 경우에는 문서 하나를 이해하기 위해 많은 부속 문서들이 필요해집니다.

이렇게 많은 연결 관계를 가진 문서를 편리하게 관리하기 위한 방법이 바로 하이퍼링크이고, 하이퍼링크를 잘 구현해놓은 곳이 바로 웹입니다. 웹에서 HTML을 이용해 작성한 문서는 별다른 어려움 없이 다른 문서에 연결되거나, 다른 문서를 연결할 수 있습니다. 또 원한다면 음악 파일이나 그림파일을 문서에 집어넣어 문서를 보는 도중에 재생할 수 있습니다. 요즈음에는 여러 가지 방법으로 다른 프로그램에서 만든 파일들을 웹 페이지에서 바로바로 볼 수 있습니다. PDF 파일이나 플래시 파일 같은 것들이 대표적입니다.

그런 이유로 기획서를 웹으로 관리하는 시도를 몇 번인가 했습니다. 왜 몇 번이냐면, 몇 번이나 실패했기 때문입니다. 기획서를 웹으로 관리했을 때 생기는 장점으로는 문서를 열람하기 쉽고, 여러 사람이 편집할 수 있는 환경을 비교적 쉽게 구성할 수 있으며, 문서의 유지보수가 용이하기 때문입니다. 'NPC 기획서' 라는 거창한 타이틀 안에 NPC에 관한 모든 내용을 언급한 다음 수백페이지에 걸쳐 인쇄해 양장본으로 만들어 다른 팀에 돌리는 것도 좋은 생각입니다. 기획서를 게임 만들 때까지 더 이상 고칠 생각이 없다면 말이죠. 하지만 기획은 상황에 따라 계속해서 변경되어야 합니다. 일정에 따라 변하기도 하고, 기술적인 원인이나 다른 외적인 요인에 따라 변하기도 합니다. 그에 따라 문서를 유지보수해야 하는데, 수백페이지짜리 양장본으로 만들어진 거창한 기획서는 그 거대한 몸집만큼이나 보수가 힘듭니다.

반면에 웹문서는 비록 거창하고 거대한 기획서 뭉치같은걸 만드는건 어렵지만, 문서 사이의 연관관계를 하이퍼링크로 편리하게 나타낼 수 있고, 문서를 잘개 쪼개면 쪼갤수록 각 부분을 여러 사람이 편집하기 쉬워집니다. 당연히 유지보수도 편리해집니다.

이런 장점에도 몇 번이나 실패한 이유는 기존에 사용하던 워드프로세서의 편리한 기능을 잊을 수 없기 때문입니다. 워드프로세서에서는 간단히 할 수 있던 일들이 웹에서 문서를 작성하면서 귀찮고 복잡해졌습니다. 대안 오피스가, 웹 오피스가 아무리 잘 나온 요즘이라고 해도 웬만해서 도입하기 힘든 이유도 여기에 있습니다. 온갖 리뷰에는 '대단하다. 근데, 간단한 업무 정도에 도움이 될 거다'라고만 써있습니다. 기본적인 문단 편집같은건 꽤 편리합니다. 하지만 링크를 만들거나, 그림을 집어넣거나, 표를 편집하는데쯤 가면 웹으로 문서를 만드는게 얼마나 힘든 일인지 알게 됩니다. 교육을 통해 익숙해질 수도 있겠지만, 그걸 교육할 사람도, 교육에 응할 사람도 없습니다. 결국 다시 워드프로세서를 사용해 문서를 만들기 시작합니다. 이번에는 문서간의 연관관계에 따른 유지보수가 힘들어집니다.

한동안은 소스세이프를 써봤습니다. 소스세이프의 'Share' 기능을 사용하면 여러 범주에 속하는 하나의 문서를 이곳 저곳에 복사해놓고 사용할 수 있습니다. 당연히 복사된 모든 문서는 어느 하나를 수정하면 모두 수정됩니다. 대신 이쪽은 동시에 참조하는 과정이 좀 피곤합니다. 소스세이프는 일단 작업을 위해 원격 스토리지에서 파일을 가져온다는 느낌이 강해서인지 여러 파일을 동시에 참고하기 위해 파일을 체크아웃 하는 작업이 꽤 귀찮게 되어 있습니다.

그간에 고민해본 결과는 문서는 문서대로, 문서의 연관관계는 연관관계대로 따로 관리해야 한다는 것입니다. 작업자들에게 어떤 규칙이나, 새로운 방법을 제시하는 것은 정말 어렵습니다. 그래서, 문서의 버전을 표시하고 수정사항을 문서에 기록하게 하는 대신 소스세이프나, svn같은 버전관리도구를 사용하도록 하고, 문서의 연관관계 기록이 필요할 때는 마인드매니저같은 프로그램을 사용하는게 낫습니다. 작업자들에게 아무것도 강요하지 않아도 되고, 연관관계는 연관관계 나름대로 관리할 수 있으며, 마인드매니저로 만들어진 맵을 보고 있으면 어느 부분의 문서가 취약한지, 혹은 유지보수가 잘 안 되고 있는지를 쉽게 파악할 수 있습니다.

일단은 마인드 매니저를 문서관계관리에 사용할 작정이지만, 다른 좋은 방법이 있을지 계속해서 고민해보는 중입니다. 거창하지 않고, 쉽게 익숙해질 수 있고, 마이그레이션에 많은 비용이 들지 않는 방법이 어디 없을까요. :(

이 글은 스프링노트에서 작성되었습니다.

문서를 공유하고 관리하는데 현존하는 최상의 도구는 위키라고 생각한다. 만일 새로운 프로젝트를 시작하게 된다면 적어도 기획팀에서만은 모든 문서를 위키로 관리하자고 강력하게 요구할 생각이다. 위키는 모든 사람들이 동일한 문서로 작업할 수 있도록 해 줄 뿐 아니라 신경쓰지 않아도 자연스럽게 문서의 최신 버전이 유지된다. 또한 문서를 특별히 체계적으로 관리하지 않아도 체계가 필요할 때마다 새로운 체계에 따른 링크를 생성하면 이전 체계와 호환성을 고려할 필요도 없다. 또한 문서를 업데이트하는데 따른 모든 과정이 기록으로 남기 때문에 누가 어떤 변경을 가했는지에 대해서도 정확한 추적이 가능하다.

하지만 프로젝트가 막바지로 치닫고 있는 상황에서 문서 관리 체계에 변경을 가하는 것은 자살행위이다. 저 대단한 에일리언 브레인 조차도 국내 판매원에서 보내온 자료에 따르면 개발 과정의 40%가 진행되었을 때에도 유연하게 개발 시스템을 이전할 수 있다고 되어 있다. 개발 과정이 80% 이상 진행된 상황에서 함부로 다른 솔루션을 도입하는 것은 위험하다.

기존의 파일시스템을 이용한 문서관리의 큰 틀을 변경하지 않고 사용할 도입할 수 있는 문서 관리 방법은 코드를 만들 때 사용하는 버전 관리 도구를 사용하는 것이다. 이를테면 소스세이프 같은 것을 간단히 사용할 수 있을 것이다. 소스세이프를 오피스 문서 관리에 사용할 경우 Diff나 Branch 같은 기능을 포기해야 하지만 기존의 틀을 변경하지 않는 안에서 좋은 결과를 얻을 수 있다. 비교를 할 수는 없지만 모든 문서의 변경 과정에 나타난 카피를 보관하고 있고, 원한다면 이를 오피스 자체의 비교 기능을 이용해 비교할 수 있다. 또, 문서의 충돌이 애초에 일어나지 않는다. 결정적으로 위키와 유사하게 파일을 여기 저기에 복사해도 같은 파일의 최신 버전을 유지할 수 있어 각 작업에 필요한 파일들을 효과적으로 분리할 수 있다.

하지만 여전히 현존하는 최상의 공유 문서 관리 방법은 위키이다. 그리고 기존에 만들어진 문서 파일이 너무 많아 위키로 이전할 수 없을 때 대안으로 사용할 수 있는 방법은 프로그램 팀에서 사용하고 있을 버전 관리 도구를 사용하는 것이다.