게임 디자이너를 위한 변명

얼마전 트위터 타임라인에서 이런 트윗을 발견하였다.

“저 기획자는 구현중인 기획을 중간에 끊임없이 고쳐서 율법을 어겼습니다. 저런자는 돌로 쳐야 마땅하지 않겠습니까?” “너희 가운데 cpp 를 만들다가 다시 h 를 고쳐본적이 한번도 없는 자가 먼저 돌을 던져라” – 링크

(물론 이 이야기가 게임 개발에 국한된 이야기는 아니다)

게임 개발 중 많은 손실이 발생하는 이유는 게임 디자이너가 머릿속에서 생각하는 것과 그것을 구현 한 이후 결과물이 지구에서 안드로메다까지의 거리 정도로 차이가 있다는 점에 기인한다. 이런 일이 왜 발생하는가? 인간의 두뇌에서 벌어지는 수많은 상상들은 세부 항목을 제거 한 후 ‘좋고 편한 것만’ 골라 상상하는 못된 버릇이 있다-즉 결국 현실과 동떨어진 생각을 하게 되는데, 게임 제작은 이 ‘보기에 좋더라’ 하는 상상을 현실화 하는 것. 당연히 상상 속에서는 생각하지 않았던 갖가지 문제들이 들러붙게 되고, 이를 해결하다 보면 처음의 아이디어와 유사하지만 기대한 결과와는 전혀 다른 그런 물건이 자주 탄생한다. 그리고 이 간극은 게임에 다양한 형태의 게임 시스템(Game Systems)이 붙을수록 그 거리를 기하급수적으로 벌려나간다. 처음에 예상하지 못한 문제와 이를 수정하기 위한 기획과 디자인들이 추가 되기 시작하면서 사람들은 서로에게 짱돌을 던질 준비를 하게 된다.

왜 한번에 완벽한 게임 디자인은 안나오는건데? 한번에 완벽한 게임 디자인을 만드는 것은 한번에 버그 하나 없는 프로그램을 짜내려가는 것, 선 하나로 완벽한 그림을 그리는 것과 같은 일이다-게다가 아무리 완벽한 게임 디자인을 작성하였다 하더라도 ‘항상 가장 좋은 아이디어는 프로젝트 막바지에 나오는 법’이다.

게임 개발이 손가락 하나로 된다면 당신은 인간도 창조 할 수 있습니다

물론, 게임 디자이너의 능력 중 하나는 좀 더 세밀한 가공을 통하여 자신의 상상과 현실의 결과물을 일치시키는 것이라 생각한다. 경험이 많은 게임 디자이너들은 이런 능력을 일정 수준 갖추고 있기도 하지만, 완벽한 수준(일필로 완벽한 게임 디자인을 작성합니다)에 오르는 것은 평범한 인간의 능력과는 거리가 있다. 때문에 최근의 게임 디자인 트랜드는 역시 빠른 프로토타이핑을 통한 게임 디자인의 검증으로 흘러가고 있다.

프로토타이핑 기법을 통한 게임 디자인은 ‘실패’를 용인하는 것에서 출발한다. 위에서 언급했듯 인간의 사고 능력으로는 상상속의 게임은 절대 현실속의 게임과 일치 할 수 없다. 때문에 어차피 실패 할 것이라면 ‘지금 당장 실패’하고 이를 고쳐나가는 것이 개발 자원의 낭비를 막는다는 개념이다. 이러한 개념을 제대로 이해하지 못한 팀이나 개인의 경우 프로토타이핑 기법을 도입하고도 프로젝트를 실패하는 경우가 왕왕 발생하는데 그 이유를 프로토타이핑 기법에서 찾기보다는 과연 우리 팀이 실패에 관대했는가를 먼저 뒤돌아봐야 한다.

물론 이런 것 까지 프로토타이핑 할 필요는 없습니다

보통의 경우 프로토타이핑 기법이 실패하는 경우는 프로토타입에 대한 과도한 집착에서 발생하게 된다. 근본적인 프로토타입 실패를 인정하기 싫어서 빨리 프로토타입을 포기 못하는 경우는 프로토타입의 기본 사고인인 실패를 용납한다는 것과 정면으로 대치되는 행동이다. 사실 프로토타입 실패는 전체 프로젝트의 실패해 비하여 정말 사소한 문제임에도 불구하고, 실패 자체를 용납하지 못하기 때문에 실제에 가까운 완벽한 프로토타입의 모순에 빠지게 되고 이는 오히려 전체 프로젝트에 엄청난 낭비를 가져온다.

프로젝트가 최종 단계에 진입했는데도 기획이 자주 바뀌어 짜증이 나는가? 상대에게 짱돌을 던지기 위해 와인드 업을 하기 전에 잦은 기획의 실패도 과정의 일부가 되도록 개발 프로세스를 개선하는 것은 어떨까?-디버깅 역시 개발 프로세스의 일부가 된 것 처럼. 서로에게 관용의 마음을 가지고 프로젝트를 위해 한발짝 뒤에서 바라보는 자세는 개발자가 기본적으로 가져야 할 미덕이 되어가고 있는 요즘이다.

p.s. 게임 디자인에 국한하여 이야기를 하였지만, 이는 경영진의 의사결정 실패-프로젝트에 영향을 미치는 각종 의사 결정 행동들 역시 마찬가지 범주의 이야기이다. 물론, 이러한 개발 프로세스의 개선은 능력 없는 개발자/경영진을 보호하기 위한 것이 아니다.