밀피유의 이야기

회사에서 사용하는 PC는 중간에 한 번 기계를 바꾼 적이 있었지만, 하드디스크를 바꾸지는 않았습니다. 하드디스크마저 바꿔버릴 수 있었지만, 교체된 PC도 비슷한 사양이라 그냥 이전 하드 꽂고 드라이버만 잡아 주면 별 무리 없이 사용할 수 있어 보였고, 실제로 그렇게 사용해도 문제가 없었습니다. 그래서, 다른 부품들은 오래돼봐야 1년 남짓이지만 하드디스크는 사용한지 3년 가량이 지났습니다. 사실, 하드디스크를 5년 이상 사용하시는 분들도 계신데, 일단 3년쯤 되면 슬슬 수명에 대한 걱정을 시작할 때입니다. 그렇잖아도 작업들이 무거워서 스왑이 잦다면 더더욱 그렇습니다. 하드디스크에서 나는 소리나, 반응이 평소와 달라진 것 같다고 느껴지면 '아 때가 왔구나'라고 생각하고 얼른 기계를 바꿔야 합니다.

백업을 위해 광학 매체를 사용하지 않습니다. 일단 검색이 불가능하고, 보관도 귀찮고, 생각보다 오래 가지 않기 때문인데요, 그래서 구입한지 한 6년은 된 씨디 라이터가 아직도 현역입니다. 물론 사용하질 않아서 제대로 기록이 되는지는 모르겠지만요. 대신 하드디스크를 추가해서 백업을 했는데, 이나마 PC 한대에 들어가는 디스크 개수에는 언제나 제한이 있었기 때문에 여의치 않았고, 파워 문제나 관리 문제가 있어 요즈음에는 대용량의 하드디스크와 작게 만들어진 서버를 이용해 백업을 하고 있습니다. 그나마 하나로는 안심이 안돼서 백업을 담당하는 기계 두 개를 쓰고 있지요. 벼락이라도 맞아서 모든 기기에 동시에 과전류라도 흐르지 않는 이상은 데이터를 완전히 잃지는 않을 겁니다.

그런데, 회사에서는 백업에 별로 신경을 안썼습니다. 작업한 데이터는 모두 서버에서 버전 관리를 하고 있고, 단위 작업이 끝날 때마다 커밋해두면 데이터를 날릴 일은 없습니다. 최악의 경우 서버에서 데이터를 전혀 건질 수 없다고 해도 그걸 체크아웃 하고 있는 사람이 한가득이라 버전 관리 정보를 잃을 순 있어도 데이터 자체를 잃지는 않습니다. 그래서인지 회사에서는 상대적으로 백업에 대해 신경을 끄고 살았는데, 그러다 보니 서버에 올리지는 않지만 작업에 참고하던 문서나 로그 파일, 아웃룩 데이터 같은 것들은 백업의 사각지대에 남아 있었습니다. 하드디스크 수명이 완전히 끝나 엑세스가 불가능해지고 나서야 이 데이터들은 백업 대상이 아니었다는 걸 생각해냈습니다.

2주쯤 전에 시스템을 새로 세팅하면서 일부 데이터를 백업한 적이 있었습니다. 그래서 모든 데이터를 완전히 날리지는 않았습니다. 다행히도 아웃룩 데이터가 지난 2주어치를 제외하고는 남아있었고, 몇몇 문서파일들도 다행히 제자리에 있었습니다. 하지만, 작업 기록이나 대화 로그, 자주 참고하던 PDF 파일, 그림 파일 같은 것들은 증발해버렸습니다. 백업의 사각지대에 있던 데이터의 데부분이 유실됐는데, 이것들은 입사해서부터 사용해온 것들이라 타격이 꽤 큽니다. 집에서도 작업에 필요한 문서더미를 가지고는 있지만, 회사에서는 작업하면서 바로바로 정리해 두기 때문에 참고하기는 더 쉬웠는데, 이제 어디부터 다시 시작해야 할지 난감한 상황이 되었습니다.

교훈. 회사에서 작업에 직접적으로 사용되지 않는, 개인 데이터에 가까운 파일들은 회사 입장에서는 관리 대상이 아닙니다. 개인도 그 데이터가 백업되지 않고 있다는 걸 잊기 쉬운데, 조심해야 합니다. 회사에서 백업해 주지 않는 데이터는 개인 책임입니다. 보안 문제를 무릅쓰고서라도 백업에 신경을 써야 합니다. :(

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

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

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

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


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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

 암만 생각해도 한국은 참 신기한 나라입니다. 없으면 없는대로 사는게 다른 나라의 방식이라면, 한국에선 없으면 없는대로는 못 삽니다. 게임이 정식으로 들어오질 않습니다. 그럼 어디선가 가져옵니다. 요즘같아서야 인터넷으로 얼마든지 구할 수 있지만, 인터넷은 커녕 PC통신도 가물거리던 시대에 어디서 들여왔는지 알 수도 없는 기판이 국내에 들어와 오락실에 늘어섰습니다. 어던 분은 어떤 게임을 수정해 본국에선 나오지도 않는 수상한 버전을 만들어 팔아 굉장한 부자가 되기도 했습니다. 언어? 그런건 아무런 제약도 되지 못했습니다. 영어? 일본어? 모르면 모르는 대로 플레이했습니다. 모르면 곤란한 게임을 위해 사람들은 언어를 공부했고, 게임 좀 오래 한 사람 치고 외국어 한두개 적당히 못 하는 사람이 드뭅니다.

2년 전에 회사에서 처음 본 한 음악가씨가 한국어를 공부하게 된 이유는 일하러 한국 회사에 왔는데, 자신을 직접 응대하는 사람들 말고도 회사 안에서 만나는 웬만한 개발진들이 모두 그럭저럭 일본어를 구사하는걸 봤기 때문이라고 합니다. 직접 비즈니스 전선에 서 있는 사람들이야 당연히 일본어정도는 해야 회사에 들어왔겠지만, 웬만해서는 외국어와 연관이 없을 것 같은 개발 스탭들이 적당한 의사소통이 되는 수준의 일본어로 덤벼왔으니 일본인 입장에선 이상하게 생각할만도 합니다. 국내에 게임을 발매할 때 한글화해서 내놔도 판매량은 비슷하다든지, 한글화를 하건 안 하건 들어오는 클레임은 비슷하다든지 하는 여러 가지 이유로 국내에 발매되는 게임의 한글화는 안타까운 수준입니다. 요새 몇몇 게임은 한글화가 잘 되어 나오기도 하지만, 수는 많지 않습니다.

그래서인지, 자생적인 문화가 발달했습니다. 위에서 이야기한 것 처럼 게임 좀 했다는 사람들은 최소한 영어나 일본어에 익숙한 경우가 많고, 이건 논란의 여지가 좀 있지만 개발사도, 유통사도 만들지 않은 한글 패치같은게 만들어집니다. 개개인이 언어를 공부하는 것도 대단하지만, 기술적인 부분을 해결해 한글 패치 같은걸 만들어버리는 것도 신기합니다. 얼마 전에 국내 서비스를 종료한 씨티오브히어로 같은 게임에 한국 서비스를 시작한지 1년이 지나도 영어로 떠드는 NPC가 돌아다녀도 아무도 뭐라고 하지 않습니다.

반면에, 한국에서 일본으로 게임을 들고 나갈 때는 이야기가 완전히 달라집니다. 일본은 워낙 많은 게임이 만들어져 소비되는 곳이라서 그런지 로컬라이징이 완료되지 않은 게임은 말 그대로 '완성되지 않은 게임'으로 취급받습니다. 그래서 일본에 게임을 내놓는 영어권 퍼블리셔들은 일본어 텍스트 제공 뿐 아니라 게임 상에 등장하는 그래픽 데이터나, 음성 데이터의 상당 부분을 일본어로 제공합니다. 물론 일본어 이외의 언어로 떠드는 텍스트는 완전히 번역되는 건 기본입니다.

사람들의 인식 차이이거나, 게임 산업이 발전해온 과정, 시장의 구성 같은 여러 가지 이야기를 할 수 있는 이슈라고 생각합니다. 야메 - !?!?!? - 로 일본어나 영어를 배운 사람들의 이야기를 들어보는 것도 꽤 재미있겠네요. :)

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

요즈음에 재밌게 본 책이 하나 있는데, 게임 제작 어쩌구 하는 책입니다. 책 제목이 표지 그림과 뒤섞여 잘 기억이 안나는데, 여튼 표지에 고페츠 그림이 도배돼 있는 이상한 책입니다. 다들 그림책일 거라고 예상하고 책을 펴본 다음, 의외로 글씨 투성이라는걸 알고는 도로 덮고 지나가더군요. 한 2년 사이에 본 게임 기획과 개발에 대해 써 놓은 책 중에서 가장 나은 책입니다.  이전에 나온 책들을 보면 이론적 배경 없이 일단 달려들어 굴러가며 얻은 개인적인 지식을 나열해 놓은 경우가 많았는데, 이 개인적 지식은 이론이 뒷받침되지 않아 꽤 불합리한 부분을 가진 경우도 많았습니다. 반면에 이 책은 일단 저자의 개인적 경험에서 출발하지만 적당한 이론이 뒷받침되기 때문에 불합리한 부분이 비교적 적습니다.

이 책을 보면서 동감한 부분 중 하나는 게임 기획 단계에서 게임의 플레이 모델을 만들어 보는 것입니다. 플레이 모델이라고 해서 플레이 가능한 데모같은걸 말하는건 아닙니다. UI를 만들 때 비주얼베이직 같은걸로 프로세스를 검토할 수 있게 데모 UI를 만들어보는 경우도 있지만, 게임은 일단 코드를 만들기 전에는 아무것도 보여줄 수 없기 때문에 모델을 만드는 건 쉽지 않습니다. 이 책에서는 게임이 완성되었을 때 어떤 식으로 돌아가는지를 기획 단계에서 검토하기 위해 UML 다이어그램을 사용합니다. 유스케이스 다이어그램을 이용해 당장 유저가 게임을 시작하면 뭘 할 수 있는지, 그 할 수 있는 것들 사이에는 어떤 상호적용이 일어나는지를 기록한 다음 기획자들끼리 모여앉아 이걸 리뷰하며 기획을 진행해 나가는 식입니다. UML의 수많은 - -_- - 다이어그램은 재쳐 두고, 클래스 다이어그램과 유스케이스 다이어그램 정도를 가지고도 게임의 플레이 모델을 충분히 검토할 수 있는 부분이 인상적이었습니다.

사람들과 이야기를 해봤는데, 한마디로 종이 위에 게임을 만드는 게임 플레이 모델 제작에 대해 필요성은 공감하지만 방법은 익숙하지 않다는 의견이 많았습니다. 비지오나 파워포인트, 혹은 워드에 들어있는 드로잉 도구를 써서 플로우 차트를 그리는 일에는 어느 정도 익숙해져 있지만 유스케이스 모델이나 클래스 다이어그램 같은걸 만들기는 쉽지 않다는 겁니다. 일단은 배운 적도 없고, 배워서 익숙해지는데까지 걸리는 시간을 무시할 수는 없습니다. 하지만 어떤 식으로든 기획 단계에서, 혹은 라이브 단계에서 기능을 추가하는데도 게임 플레이 모델을 만들고, 이걸 리뷰하는 과정이 필요하다는 건 확실합니다.

그래서, 다이어그램을 그리는데 익숙하지 않은 기획자를 위해 플레이 모델을 글로 작성하는 것을 제안합니다. 기획 단계에서 게임이 어떻게 돌아가는지를 판단하기 위해 게임이 만들어졌을 때 유저가 게임 안에서 당장 뭘 할 수 있는지를 문장으로 기록하도록 합니다. 문장으로 기록한 플레이 모델은 다이어그램에 비해 리뷰하는데 좀 더 피곤하지만, 새로운 다이어그램과 리뷰 방법을 익히는걸 곤란해 하는 경우에 당분간의 해결책이 될 수 있습니다. 물론, 그러는 사이에 새로운 방법을 준비하지 않으면 안되겠지만요. :(