올바른 도구 사용하기

일을 처음 시작할 때는 지금 같은 시스템디자인 역할이 아니라 퀘스트 라이터 역할이었습니다. 퀘스트 라이터는 게임 시스템과 스토리를 잘 살펴본 다음 이들에 기반해 그 세계에서 일어날 법한 더 짧은 이야기를 만들고 이를 게임 안에서 다양한 방법을 통해 고객이 체험하도록 하는 역할을 합니다. 처음에는 그저 거의 소설에 가까운 텍스트와 일러스트 몇 장만 있는 상황에 제대로 구축된 게임 플레이나 보조 시스템, 그리고 결정적으로 퀘스트 시스템이 아예 없었기 때문에 퀘스트 라이터로 채용된 사람들은 미리 ‘소설’ 텍스트를 읽고 등장인물과 이야기를 상상한 다음 나중에 퀘스트 시스템이 구축되고 나면 퀘스트를 만들 생각으로 글을 규격화 해서 준비해 놓았습니다. 결말을 미리 말씀 드리면 이렇게 준비한 텍스트는 결코 퀘스트 모양으로 만들어지지 못했는데 이유는 크게 두 가지로 보고 있습니다.

일단 우리가 퀘스트에 사용할 작은 이야기를 쓰기 위해 참고한 이야기는 보다 이 세계 전체의 역사적 사건에 가까운 내용이었습니다. 흔히 태초에 빛과 어둠이 있었다로 시작하는 400페이지 짜리 기획 포트폴리오를 보는 느낌과 비슷했는데 분명 제목에는 게임 제목과 같은 텍스트가 적혀 있었지만 이 이야기는 게임의 배경이 되는 현실로부터 꽤 먼 과거의 이야기, 그리고 다른 차원의 이야기를 다루고 있었습니다. 이야기에 등장하는 인물 거의 대부분은 게임 기준 현대에 마을 광장을 장식한 동상, 지명, 전설에 지나지 않았습니다. 하지만 우리가 해야 할 일은 그런 과거의 이야기에 기반해 퀘스트를 만드는 일이 아니라 그 과거의 사건에 기반해 만들어진 게임 기준 현대 세계를 살아가는 사람들이 겪는 현대의 이야기를 쓰는 것입니다. 그러려면 과거 이야기 말고 현대의 설정이 훨씬 더 많이 필요했는데 설정은 계속해서 과거 이야기에 집중되어 있었고 여러 설정들이 현대에 도달하는 속도는 우리가 필요로 하는 현대의 이야기에 비해 너무 느렸습니다. 결국 우리는 대충 아무렇게나 지어낸 현대의 이야기를 만들었는데 이런 이야기들은 하나같이 사사로워서 이야기가 어떻게 되든 말든 과거로부터 이어지는 거대한 이야기를 거스르지 않았지만 결코 서로 어울리지 않았습니다.

우리가 작성한 퀘스트 문서가 퀘스트 모양으로 만들어지지 못한 다른 이유는 퀘스트 시스템을 구축하지 않은 상태에서 퀘스트를 쓰기 시작했기 때문이고 퀘스트 시스템을 구축하기 위한 기반인 캐릭터, 성장, 아이템 기반 따위가 준비되지 않았기 때문입니다. 어느 회사나 비슷한데 회사를 만들고 게임 하나를 크게 성공 시키면 많은 사람들이 더 성공적인 다음 게임을 만들고 싶어 합니다. 다음 게임을 성공 시키기 위해 이전에는 없었던 충분한 인력을 처음부터 모집하고 전작에서 가장 부끄럽게 생각했던 부분에 필요 이상으로 집중하곤 하는데 이전에 경험했던 회사에서는 그 부끄러운 부분이 바로 퀘스트였습니다. 전작은 퀘스트가 없지 않았지만 시스템이 충분히 훌륭하지 않았고 당시는 MMO의 퍼시스턴트 월드에서 플레이어 개개인에게 개인화된 경험을 주는 방법을 잘 몰랐습니다. 우리들 역시 싱글플레이 기준의 퀘스트 경험을 상상하기는 쉬웠지만 이런 상상이 다른 플레이어들에게 실시간으로 모든 행동이 동기화되는 퍼시스턴트 월드에서 어떤 문제를 일으킬지 깊이 고민하지 않았습니다.

전작에 비해 훨씬 훌륭한 퀘스트 경험을 부여하기 위해 아직 핵심 메커닉(aka 전투)이 정립되기도 전에 퀘스트라이터들을 모집해 퀘스트 스크립트부터 작성하기 시작합니다. 그런데 퀘스트 시스템은 게임의 나머지 체계가 어느 정도 갖춰져 있을 때 이들을 퀘스트에 의해 제어하는 시스템을 구축하면서 만들어 나가는 것이 개발팀에 무리를 가장 적게 주는 개발 방식이라고 생각합니다. 퀘스트는 게임을 광범위하게 제어합니다. 가령 퀘스트에 따라 플레이어의 이동 목표를 지정하고 목표 몬스터를 스폰 시키고 플레이어를 퀘스트가 없는 사람은 들어올 수 없는 던전에 입장 시키고 전용 컷씬을 보여주며 평소에는 싸울 수만 있었던 몬스터와 대화를 하고 퀘스트 아이템을 인벤토리에 넣어 주고 많은 경험치를 줘 갑자기 1레벨을 올려주는 등등 퀘스트에서 하려는 여러 가지 행동은 거의 게임 전체를 제어하기에 이릅니다. 그래서 퀘스트는 퀘스트로 제어하려는 나머지 시스템이 어느 정도 구축된 다음 이들을 제어하는 기능을 추가하면서부터 개발하기 마련입니다.

이 순서를 지키지 않으면 사실상 퀘스트 개발을 할 수가 없습니다. 가령 아직 인벤토리가 없다면 퀘스트 보상을 줄 수 없고 아직 몬스터와 전투하는 기능이 없다면 그 흔하디 흔한 몬스터 몇 마리 사냥해 오는 퀘스트를 만들 수도 없으며 NPC가 없다면 NPC와 대화할 수도 없고 PC에 상점 기능이 없다면 NPC 한 마리를 상점 전용으로 만들지 퀘스트 대화 및 상점 역할을 하도록 만들지 결정하고 이에 맞는 인터페이스를 설계할 수도 없습니다. 이런 상황에서 핵심 메커닉을 구축해 나가는 상황에서 초보적인 전투 외의 동작이라곤 여러 레벨을 건너다니는 기능 밖에 없을 때 퀘스트 라이팅을 시작한데다 그 퀘스트의 기반이 되는 시나리오는 소설 모양에 먼 과거 이야기를 다루고 있었으니 제대로 된 결과물이 나올 수가 없습니다. 참고로 이런 순서를 지키지 않고서 엄청난 비용을 낭비하며 퀘스트 먼저 개발해 낸 사례를 알고 있는데 이건 나중에 다시 기억 나면 이 이야기만 별도로 해 보겠습니다. 여기서 그냥 하기엔 굉장히 신나고 재미있기 때문입니다.

한편 놀랍게도 지금까지 한 이야기는 이 이야기의 본론이 아닙니다! 사실 본론은 그 퀘스트 라이팅을 하는데 사용한 도구가 다름아닌 엑셀이었다는데서 시작합니다. 사실 지금까지 한 퀘스트 만드는데 실패한 이야기는 지금부터 할 이야기와 아무런 상관도 없고 그 퀘스트 라이팅 할 때 텍스트를 타이핑 해 넣던 도구가 엑셀이었다는 사실이야말로 이 이야기에 본격적으로 연결됩니다.

그 이전까지는 무지성으로 글자는 워드, 숫자와 표는 엑셀, 그림을 포함하면 파워포인트로 문서를 만들어야 한다고 생각해 왔습니다. 종종 문서 하나에 글자 중간에 스프에드시트가 들어가면 이걸 워드로 만들어야 할 지 아니면 엑셀로 만들어야 할 지 조금 고민 되기는 했는데 그때까지만 해도 그런 고민을 할 기회는 드물었습니다. 상급자는 퀘스트 라이터들에게 엑셀 포멧을 나눠 주고 퀘스트 하나가 엑셀 워크시트 하나에 표시되도록 테이블을 채우기를 요구했는데 퀘스트 이름, 요약, 스텝 번호, 스텝 내용 요약, 스탭에 일어나야 할 일을 차례로 작성했습니다. 특히 스탭 번호, 스탭 내용 요약, 스탭에 일어나야 할 일은 한 줄에 적어야 했는데 지금에 와서 생각해 보면 이는 아마도 온전한 퀘스트 시스템이 있는 상황에서 퀘스트 스탭 하나하나를 정의하기 위한 의도였던 것 같습니다. 하지만 퀘스트 시스템은 없었고 이를 개발할 상황도 아니었으며 우리는 빛과 어둠 수준의 고대 시나리오에 기반해 현대 이야기를, 그것도 퀘스트 시스템이 어떻게 생겼는지도 모르는 상태로 한 가지 이야기를 스탭 단위로 구분해 타이핑 하고 있었으니 이쯤 되면 회사에 대한 배임이 아닌가 싶습니다.

한참 그렇게 의미 없는, 그리고 미래에도 의미 없을 것이 분명한 퀘스트를 작성하다가 이전에 작성한 다른 퀘스트를 찾으려고 엑셀 워크시트 사이를 뒤적거리다가 문득 왜 우리들은 글자를 타이핑하기에 가장 편안하게 만들어진 워드를 놔두고 엑셀에다 이러고 있는지 의문이 들기 시작합니다. 이 엑셀 파일은 우리들이 타이핑 한 사람이 읽을 수는 있지만 기계에게는 아무런 의미도 없는 텍스트 조각을 셀 단위로 구분하고 있었는데 글자 사이에 개행하려면 Alt + Enter를 눌러야 했고 셀 안에서는 들여쓰기와 내어쓰기, 블릿포인트 같은 문자 사용이 제한되었으며 셀 높이에 최대치가 정해져 있어 그보다 긴 텍스트는 입력할 수는 있었지만 읽을 수는 없었습니다. 사실 특정 양식을 지키도록 하고 싶으면 관공서에서 그렇게 하듯 워드 문서에 테이블로 마술을 부려 훨씬 작성하기 편한 포멧을 만들 수도 있었을 텐데 굳이 문서를 엑셀로 작성하게 만들어 엑셀의 용도에 맞는 장점을 살리지도 못하고 글자를 타이핑 하기에는 불편한 환경을 만들어 놓고 이 기반에 작업하게 하는 이유를 짐작하기 어려웠습니다. 이 경험 끝에 이전에도 그랬지만 더더욱 엑셀에 문서를 작성하는 것은 이상한 행동이라는 선입견을 가지게 됩니다.

한편 같은 팀에서 3개월 만에 퀘스트 라이팅을 그만 두고 지금 같은 소위 ‘시스템 디자이너’ 역할을 하기 시작했는데 이번에는 문서를 워드로 작성했지만 문서 중간에 표와 플로우차트를 그릴 일이 생깁니다. 주변을 둘러보니 표는 워드 자체의 표 기능을 사용하거나 엑셀에서 만든 다음 붙여 넣고 있었고 플로차트는 회사에서 기본 지급한 마이크로소프트 오피스 스위트에 포함된 파워포인트를 사용해 그리는 분위기였는데 정확한 이유는 기억나지 않지만 이 때 이미 플로우차트를 그리기에 굉장히 편리한 마이크로소프트에서 나온 비지오라는 도구가 있다는 사실을 알고 있어 회사에 비지오를 사달라고 요청해 봤습니다. 지금 생각하면 그냥 있는 도구나 잘 쓰라며 거절할 수도 있었을텐데 비지오 구매 요청이 승인되어 고가의 그림 그리는 도구를 사용할 수 있게 됩니다. 당연하지만 비지오와 파워포인트 사이에는 건널 수 없을 만큼 넓고 깊은 생산성의 차이가 있습니다. 파워포인트는 화면에 보이는 페이지 하나를 만드는데 집중하는 도구이기 때문에 그 안에 들어간 그림, 플로우차트, 텍스트박스가 페이지 범위를 초과하면 이를 잘 핸들링하지 못합니다. 애초에 그러라고 만든 도구가 아닙니다. 반면 비지오는 겉보기에 사용할 수 있는 드로잉 도구 종류는 비슷해 보이지만 페이지 하나를 꾸미는데는 아무런 관심이 없고 드로잉 하나를 온전히 작성하는데 집중하는 도구입니다.

그래서 플로차트를 그리다가 페이지 범위를 넘기면 바로 이어지는 페이지가 나타나 플로우차트를 끝까지 그리는데 집중할 수 있습니다. 또 다이어그램을 서로 정렬하고 이들을 연결하고 연결된 상태를 유지하면서 정렬을 변경하고 연결된 상태를 데이터에 기반해 검증하는 등의 작업은 시각적인 한 페이지를 만드는데 집중하는 파워포인트와는 완전히 다른 접근이고 또 완전히 다른 기능입니다. 하지만 이후 회사에 비지오를 사 달라고 하려면 왜 이미 비슷한 도구인 파워포인트를 지급했는데도 또 다른 고가의 도구를 구입해야 하는지 정말 눈물 없이는 볼 수 없는 사유를 기입해야만 했고 나중에는 똑같은 내용을 복사해 놨다가 여러 회사에서 비지오를 안 사 주려고 할 때마다 붙여 넣어 제출하곤 했습니다. 그러면 구입할 수 있었거든요. 핵심은 파워포인트로도 비지오로도 네모와 네모를 그린 다음 이들 사이를 화살표로 연결해 플로우차트를 그릴 수 있지만 두 도구의 특징과 목표는 완전히 다르며 이에 따라 생산성에도 완전히 차이가 난다는 것입니다. 비지오는 여러 가지 차트 그리는데 사용하는 도구이고 파워포인트는 슬라이드 페이지 하나하나를 꾸미는 도구입니다.

시간이 지나 자리 근처에 있는 다른 팀이 일하는 모습을 봤는데 이 팀도 문서를 엑셀에 작성하고 있었습니다. 다른 팀이 어떤 선택을 하든 제 알 바는 아니어서 그냥 구경하다가 텍스트를 좌우 폭에 맞춰 자르고 다음 줄로 내려가는 CRLF를 사람이 직접 Alt + Enter를 눌러서 하고 있길래 모른 체 하고 왜 그렇게 엑셀로 문서를 힘들게 작성하고 있느냐고 여쭤봤습니다. 그랬더니 자신들의 작업에는 공식을 많이 사용하기 때문에 엑셀을 사용해야 하고 그 댓가로 문서 역시 엑셀로 작성하며 인간이 직접 셀마다 CRLF를 하는 행동은 너무 당연하다는 설명을 듣고 잠깐 멍해집니다. 이 분들은 다른 부서에 비해 수식을 작성할 일이 더 자주 있었던 것은 사실입니다. 엑셀에서 =로 시작해 자동으로 계산되는 그 수식 말고 여러 변수에 값을 대입해 계산하면 답이 나오는 그런 수식 이야기입니다. 플레이어가 든 무기의 공격력에 의한 대미지는 몬스터의 방어력에 의해 감소돼 최종 대미지가 계산되는데 이런 계산에 사용하는 수식을 엑셀에 표현한다는 겁니다. 그런데 암만 생각해도 그 식에 값을 대입해 실제 계산이 일어나는 곳은 서버이고 이 수식이 입력될 곳 역시 서버 코드 어딘가일 텐데 왜 실제 적용되지도 않을 식을 엑셀에 입력하는지, 또 식을 그렇게 입력하기 위해 식을 포함한 나머지 문서를 인간이 셀에 직접 CRLF를 해 가며 입력하고 있어야 하는 이유를 이해하기는 쉽지 않았습니다.

또 한번은 업계에 제품을 성공적으로 출시했지만 경제적인 성공을 이루지는 못해 어려움을 겪다가 인원이 서서히 이탈하는 팀이 있었는데 이 팀으로부터 이력서가 워낙 많이 나타났기 때문에 이 팀에서 모든 기획서를 엑셀에 정말 공들여서 작성한다는 사실을 파악하고 있었습니다. 이 팀으로부터 나온 기획서는 하나같이 엑셀에 아주 가지런하게 정리되어 있었는데 딱 보면 그 아름다움에 감탄할 수밖에 없었습니다. 시각적인 아름다움 뿐 아니라 엑셀로 이런 문서 모양을 만들어내기 위해 가로, 세로를 구성한 모든 셀 너비가 1픽셀로 조정되어 있고 이 안에서 거의 그림을 그리다시피 한 글자 배치, 단락 기호, 그림과 표가 어우러진 문서들은 정말 기획서라기 보다는 예술에 가까웠습니다. 엑셀로 그런 문서를 작성한다니 엑셀로 더블버퍼링을 통한 3D 그래픽을 셀 위에 그려낸 것 만큼이나 신기하고 놀라웠습니다. 우연히 그런 문서를 제출해 주신 분 중 일부를 인터뷰 할 기회가 있어 나중에 여쭤봤는데 그렇게 작성하는 것이 팀 방침이라는 것 같았습니다. 분명 강한 의지를 가진 누군가가 밀어붙인 결과인 것 같아 보입니다. 대단하기는 하지만 저 문서에 무슨 의미가 있을지 이해하기는 어려웠지만요.

기획팀에서 나가는 모든 기획서를 검수해 각 기획서에서 요구하는 인터페이스 요구사항을 정규화 하고 인터페이스 제약사항이나 인터페이스 규격에 맞지 않는 인터페이스 요구사항이 팀 밖으로 바로 나가지 못하도록 하는 역할을 하는 팀에 속한 적이 있었는데 이 때는 다행히도 기획서를 워드로 작성했습니다. 하지만 기획서에 포함할 인터페이스를 워드 자체 기능만으로 그리기에는 대단한 노동력과 참을성이 필요했기 때문에 거의 모든 사람들은 이를 시도조차 하지 않고 바로 파워포인트로 넘어가 그림을 그려 워드에 붙여 넣고 문서를 완성하곤 했습니다. 이건 비밀인데 워드만으로 모든 인터페이스 기획서를 그리는 장인을 한 분 알고 있는데 언젠가 기회가 되면 그 이야기도 해보겠습니다. 개인적으로는 여전히 파워포인트로 인터페이스 와이어프레임을 그리는 상황이 그리 탐탁찮았는데 분명 이 그림을 그려내는데 상당히들 고생했겠지만 다른 더 용도에 맞는 도구를 사용하면 같은 그림을 네 시간에 걸쳐 그리는 대신 30분이면 다 그렸을 것 같았기 때문입니다.

가령 게임에 흔히 활용되는 탭 인터페이스를 생각해봅시다. 탭은 근본적으로 작은 버튼들의 조합이고 여러 버튼 중 동시에 어느 하나만 누를 수 있으며 눌린 버튼에 따라 버튼 하단(주로 하단)에 표시될 인터페이스 종류가 바뀌는 컨트롤입니다. 그런데 파워포인트의 기본 드로잉을 사용해 탭을 그럴듯하게 보이도록 그려내려면 사각형 버튼 여러 개를 그리고 각 사각형에 탭 이름을 적은 다음 눌린 탭과 안 눌린 탭을 구분하기 위해 사각형의 아래쪽 변의 색상을 배경색과 동일하게 맞추기 위해 상당한 노력을 해야 합니다. 만약 기획서를 작성하며 서로 다른 탭을 누를 때 서로 다른 인터페이스를 표시하고 또 서로 다른 동작을 해야 함을 설명하려면 파워포인트 기본 드로잉 도구로 아슬아슬한 줄타기를 해야 그럴듯한 탭을 그릴 수 있고 여기에는 엄청난 노동력이 필요합니다. 하지만 애초에 인터페이스를 전문적으로 그릴 수 있는 발사믹 와이어프레임 같은 도구를 사용하면 하이라이트 된 탭과 그렇지 않은 탭, 활성화된 탭과 비활성화된 탭을 1초 안에 옵션과 체크박스만 조절해 그럴듯하게 만들어낼 수 있고 여기에는 노동력이 거의 필요하지 않습니다.

과거에는 미련한, 혹은 정신나간 개인이 강한 압력을 만들어 팀 전체가 용도에 맞지 않는 도구를 억지로 사용할 것을 강요할 수 있었다고 생각합니다. 만약 처음에는 개발팀에서 일하다가 성공을 겪으며 경영진으로 올라간 누군가가 자신이 일을 배울 때 엑셀에 문서를 작성하도록 배웠기 때문에 앞으로 그 회사에서 개발하는 모든 프로젝트의 기획서는 엑셀에 작성해야 한다고 주장한다면 회사 규모가 훨씬 더 커지기 전에 이런 기괴한 요구를 막을 방법은 없습니다. 또 도구마다 다른 핵심 용도와 이 용도 차이에 따른 생산성 차이는 이를 실제로 겪어보기 전에는 이해할 수 없을 수도 있습니다. 가령 워드, 파워포인트, 비지오에 있는 플로우차트 그리는 도구는 스크린샷으로 볼 때 모두 완전히 똑같아 보이는데 이 때문에 굳이 엄청나게 비싼 비지오를 별도로 구입해야 할 이유를 설득하기 어려울 수 있습니다. 그리고 이런 시각을 바꾸기는 … 사실 불가능합니다. 바꿀 수 있다 하더라도 엄청나게 피곤해 차라리 그 시간에 그냥 파워포인트로 그림을 그리고 있는 편이 낫겠다고 생각하며 후회할 수도 있습니다. 제가 후회해본 적이 있거든요.

하지만 현대에는 이런 어처구니 없는 일로 인한 생산성 저하를 방치하기에 업계의 경쟁은 너무 치열하고 우리들의 노동력은 너무나 소중합니다. 우리들은 프로젝트 개발을 완수해 시장에 출시하고 고객들로부터 평가를 받으며 나아가 경제적인 성공을 거두기 위해 고용되었습니다. 누군가의 괴상하게 왜곡된 과거의 경험에 기반해 엉뚱한 장소에 엉뚱한 도구로 일하느라 아까운 노동력을 낭비하는 사실상의 배임 행동을 방치하기 위해 고용되지 않았습니다. 현대에는 온갖 신기한 도구가 나타나고 사라지기를 계속하고 있습니다. 앞에서 파워포인트에 비해 플로우차트 및 여러 가지 종류의 차트를 훨씬 적은 노동력으로 작성할 수 있는 도구로 비지오를 언급했지만 이 밖에도 인터페이스 와이어프레임을 순식간에 그릴 수 있는 전문 도구, 데이터베이스 관련 다이어그램을 그릴 수 있는 전문 도구, 규격화된 데이터를 관리하기 위한 전문 도구가 널려 있습니다. 조금이라도 더 업무 성격에 잘 맞는 도구를 사용해 우리들의 소중한 노동력이 보다 의미 있게 사용되도록 관심을 가져야 합니다.

그러기 위해서는 습관적으로 여러 가지 용도에 사용하던 한 가지 도구가 실은 이 도구로 해결할 수 있는 핵심 문제 형태가 있고 그 형태를 벗어나면 생산성이 급격히 떨어질 수 있으며 이런 상황에 적용할 수 있는 다른 더 좋은 도구가 있을지도 모른다는 사실을 끝없이 의심해야 합니다. 또한 애초에 말도 안되고 의미도 없는 완전히 잘못된 도구로 완전히 잘못된 작업을 하기 위해 엄청난 노동력을 낭비하는 대표적인 사례인 엑셀로 문서를 작성하는 등의 극단적으로 잘못된 지시에는 저항해야 하고요, 이건 명령에 따르지 않는 행동이라기 보다는 상사의 배임에 대한 문제 제기에 가깝다고 생각합니다. 다시 한 번 강조하지만 우리들의 노동력은 소중하고 우리는 회사에 노동력을 이렇게 의미 없게 사용하기 위해 고용되지 않았습니다. 우리는 회사에 완성된 제품을 성공적으로 출시하기 위해 고용되었으며 이 목적을 충실히 이행하기 위해 항상 같은 작업을 더 잘할 수 있는 도구가 있을지도 모른다는 사실을 기억하고 끝없이 의심해볼 필요가 있습니다.