밀피유의 이야기

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

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

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


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


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

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


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

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

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

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

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

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

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

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

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

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

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

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