밀피유의 이야기

여러 사람이 함께 진행하는 작업에서, 누가 무엇을 하고 있는지는 중요하다. 자신의 작업 내역을 다른 사람들에게 알리고 싶지 않아 하는 사람이 있을 수도 있지만, 여러 사람이 작업하고 있고, 이 공동작업이 효율적으로 진행되기 위해서는 조직에 속해있는 사람 모두가 다른 모든 사람들 각각이 지금 이 순간 무슨 일을 하고 있는지 알아야 한다. 관리자라면 이 각각의 작업들이 어떤 순서로 모여 어떻게 완성될지를 완벽하게 파악하고 있어야 하겠지만, 각각의 작업자들이 그럴 필요는 없다. 하지만, 다른 사람들이 어떤 작업을 하고 있는지 살펴보면서, 자신의 작업이 전체의 어느 부분에 속해 있는지를 스스로 파악해볼 수 있다.

가시성이란, 조직 내의 역할 수행에 대한 관찰이 가능한 정도를 말한다. 여기서 조직이란 개발 팀을 이야기하는데, 개발 팀 내에서 일하는 각각의 작업자들의 작업 진행상황에 대해 관리자나, 작업자 각각이 어디까지 다른 사람의 작업을 관찰할 수 있는지를 말하는 정도로 수정해서 사용할 수 있다. 조직 내에서, 작업자들의 가시성을 확보하고 있다면 작업에 이상이 발생하는 징후를 쉽게 포착할 수 있다. 예정에 없는 리소스가 제작되고 있다든지, 이번에 당장 급하지 않은 사항이 기획되고 있다는 것을 미리미리 파악할 수 있다. 운이 좋다면 분명 나중에 쓸모 없게 될 이런 작업들이 시작되기 전에 관리자가 들이닥쳐 일을 멈추게 하고, 꼭 필요한 다른 일을 진행하도록 할 수 있다.

가시성이 확보되어 각각의 작업자들이 다른 작업자들이 하는 일의 진행상황을 파악하게 되면 작업자들이 스스로 업무강도를 조절할 수 있게 된다. 관리자가 작업의 전체 진행상황을 알려주지 않아도 다른 사람들의 작업에 조금이라도 관심을 가지고 있고, 다른 작업자들의 작업 진행상황에 대한 가시성이 확보되어 있다면 스스로 자신의 작업의 위치를 파악할 수 있게 된다. 관리자가 알려주거나, 복잡한 회의나 고지 과정을 거치지 않아도 자신의 이전 작업과 다음 작업을 파악할 수 있게 되고, 각각의 담당자들의 일정에 맞춰 자연스럽게 일정을 맞출 수 있게 된다.

가시성이 확보되면 디렉터가 엉뚱한 비전을 제시할 가능성이 낮아진다. 디렉터는 누구나, 언제나 최상의 게임에 대한 의견을 내놓는다. 훌륭한 기획과 좋은 구현, 완성도 높은 리소스가 어우러진 좋은 게임에 대한 의견이다. 언제나 문제는 이상과 현실 사이의 괴리이다. 디렉터가 내놓은 훌륭한 비전도 개발 중인 게임과 거리가 멀다면 작업자들은 자연스럽게 디렉터의 의견을 듣지 않게 된다. 종종 우린 현실과 거리가 먼 디렉터의 의견을 '똥 싼다'고 말했고, 우리가 하는 작업을 '똥 치우기'라고 말하곤 했다. 이런 일이 계속되면 디렉터는 본의 아니게 팀을 제어할 수 없게 될지도 모른다. 가시성이 확보된다면 디렉터는 비전을 제시하기 전에 자신의 비전을 작업 상황에 맞춰 점검해볼 수 있다. 헛소리가 입 밖으로 나가기 전에 단속할 수 있고, 비교적 현실과 괴리가 적은 괜찮은 의견을 내놓게 될 것이다.

이런 현상은 디렉터 뿐 아니라, 종종 기획팀에서도 나타난다. 흔히 '기획팀 또 헛소리 하네 현상'으로 불리는 이 현상은 제안과 기획을 하고, 실무자들과 회의를 거쳐 세부기획과 데이터 구조를 만들고, 데이터를 만들고, 작업자들을 이해시켜 작업을 진행시키고, 테스트와 조율을 거쳐 마침내 본섭에 들어갈 때까지 일어나는 모든 일들을 관리한 기획자가 난데없이 중간 작업자들이 아무도 모르는 헛소리를 내뱉는 것을 말한다. 분명 기획자가 저질러 놓은 일인데, 일이 진행되다 보면 기획자도 모르는 일이 있다. 프로그래머가 중간에 그래픽 작업자와 새로운 파일 포멧에 대한 이야기를 진행시켰다고 하면, 이게 기획자한테 전달되지 않으면 기획자가 모르는 것도 당연하다. 이 상태로 놔두면 기획자는 어느날 예전 포멧에 맞춘 데이터를 들고와 프로그래머를 곤경에 빠뜨릴 것이다. 이런게 반복되면 기획팀의 신뢰가 무너질 뿐 아니라, 우리가 디렉터의 헛소리를 '똥'이라고 부르듯, 다른 팀이 기획서나 기획자의 의견을 '똥'으로 인식해버릴 것이다. 가시성이 확보되지 않은 작업 진행의 지저분한 최후이다.

가시성을 확보하기 위해 일정 관리와 작업 관리에 대한 개념이 준비되어 있고, 수많은 복잡한 방법론과 귀찮은 솔루션들이 있다. 사실, 툴은 어느 것이나 다 똑같다. 장점과 단점이 있고, 개발팀에 따라 어울리는 방법론과 솔루션이 있는 반면, 어울리지 않는 것도 있다. 하지만 어느 툴이나 똑같다는 건, 사용 대상자들이 똑같이 약속하고 성실하게 사용한다면 나쁜 툴은 없다는 의미이다. 아무리 좋다는 외계인 할아버지를 데려다 놔도 아무도 앞장서서 사용하지 않는다면 그냥 쓰레기일 뿐이다.

도구를 이용해 가시성을 확보하기로 마음먹었다면, 신경 써야 할 것들이 몇 가지 있다. 중요하다고 생각되는 것은 일단 도구는 사람을 괴롭히지 않아야 한다. 아무리 훌륭한 도구가 있다지만 사람들이 사용하기에 불편하거나, 체계가 맞지 않는다면 쉽게 익숙해지기 어렵다. 익숙해지지 않으면 성실하게 사용할 수도 없고, 이건 규제만으로는 해결하기 힘든 문제이다. 물론 규제만으로도 해결할 수는 있지만, 여러 사람이 피곤할 각오를 해야 한다. 가급적 사용에 대한 부담이 적고, 적은 교육으로 사용을 시작할 수 있으며 여러 체계에 적용될만큼 유연해야 한다.

가시성을 확보하기 위해 사용할 도구는 도구를 이용하기 위한 모델이 고정되어 있거나, 지나치게 복잡한 체계 설정을 요구하는 것은 피하는 것이 좋다. 꽤 괜찮다는 엔터테인먼트를 위한 일정관리와 리소스 관리 도구를 구경해봤는데, 도구 자체는 훌륭했지만 도구를 사용하기 위해 가정한 개발 체계가 지나치게 한정적이라 아무데나 도입할 수 없는 경우가 있었다. 또, 어떤 도구들은 현재의 개발 시스템에 대한 강도 높은 분석을 요구하는 경우도 있다. 물론, 현재 개발 체계에 대한 강도높은 분석은 장기적으로 프로젝트와 팀과 회사 전체에 엄청난 이득이다. 분석 작업 만으로도 게임을 출시하지 않아도 충분할 만한 굉장한 노하우를 습득할 수도 있다. 하지만 이미 개발에 들어가버렸고, 어쨌든 게임을 팔아야 하는 입장에서 강도높은 분석은 상당한 부담으로, 가시성을 확보하기 위한 노력 자체를 포기하게 만들 수도 있다. 때문에, 가시성을 확보하기 위한 도구는 적당히 느슨한 체계를 허용할 필요가 있다.

가시성을 확보하기 위한 도구는 작업자 스스로가 작업 방식을 탐색할 수 있도록 구성되어야 한다. 가끔 간트 차트를 만들어놓고 그걸 개발 상황과 일치시키기 위해  기를 쓰며 노력하는 사람들을 봤는데, 웬만큼 익숙한 사람들이 아니면 결국 성공하지 못했다. 하루에도 몇십명의 작업자들의 일정이 하루이틀씩 조절되는 마당에 하루 웬종일 간트 차트만 붙들고 있을 수는 없는 노릇이다. 작업자들에게는 최소한의 역할을 분배하고, 디렉터나 프로듀서 정도의 사람들이 개발을 위해 필요한 대단위 작업들을 설정하고 나면 이 작업들을 가시성 확보 도구를 이용해 작업자들이 자신의 위치를 설정할 수 있어야 한다. 마치 trac 같은 도구에서 마일스톤에 티켓들을 포함해 놓으면 작업자들이 달려들어 적당한 티켓을 자신에게 분배하는 것과 비슷하다. 물론 trac을 직접 코드를 다루지 않는 사람들이 포함된 개발팀에서 사용하는건 꽤 힘들거다.

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