없는 게임으로 의사결정 하면 안돼요

이전 인벤토리 인터페이스 설계 철학과 왜 인벤토리에 전체화면 인터페이스를 사용하려고 하나요?에서 인벤토리 모양을 결정하는 의사결정 방법을 설명했습니다. 사실 비슷한 이야기를 여러 글에 걸쳐 한 것 같은데 이 주제를 여러 번 다시 생각하게 되는 이유는 게임의 인터페이스를 고안하는 의사결정이 실제 인터페이스의 필요에 따르지 않고 그 시대의 유행이나 어떤 개인의 취향을 따르는 경우가 종종 있다고 생각하기 때문입니다. 물론 이런 의사결정 방법이 틀린 것은 아닙니다. 근본적으로 우리들은 스폰서가 원하는 게임 개발을 대행하는 역할을 할 뿐 우리들이 원하는 모양의 게임을 만드는 일을 하고 있지는 않기 때문입니다.

하지만 용도와 의도에 맞는 의사결정을 하지 않으면 의사결정을 하는 시점에는 잘 드러나지 않지만 잘못된 의사결정의 결과가 게임에 적용된 상태로 개발을 계속하다 보면 이전의 잘못된 의사결정의 영향을 받아 점점 더 이상한 의사결정을 반복하게 될 수 있습니다. 가장 나쁘고 위험한 점은 뒤에 가서 하는 더 이상한 의사결정들은 이전에 수행한 첫 번째 잘못된 의사결정으로부터 비롯되었다는 사실을 알기 어렵다는 겁니다. 앞서 의사결정에 참여한 사람들이 팀을 떠나기도 하고 기록을 제대로 남기지 않기도 하며 스스로 의사결정의 기억을 잊어버리면서 팀은 과거에 일어난 이상한 의사결정의 존재를 완전히 잊고 지금 당장에 닥친 문제를 해결하는데 집중해 결국 문제를 해결하기는 하겠지만 적지 않은 비용을 지불해야 하고 그 결과가 만족스럽지 않을 가능성이 높습니다.

한번은 모바일 MMO 게임을 만드는데 참여했는데 극 초반에 프로토타입을 만들면서 아무 생각 없이 인벤토리를 팝업 모양으로 만들었습니다. 이 때는 아직 이 MMO가 어떤 게임이 될 지 잘 몰랐습니다. 리더십은 개발팀을 세팅하는 사이에 경영진을 대상으로 한 소위 비전 피티를 준비하는 중이었고 나머지는 우리들이 여느 잘 세팅 된 개발팀처럼 길지 않은 시간 안에 꽤 괜찮은 빌드를 개발해낼 역량이 있음을 경영진에게 빌드를 통해 증명해 내야 했습니다. 그래서 게임에 맞는 메커닉을 선택하고 여기 맞는 인터페이스를 고안하기 보다는 그 시대에 가장 괜찮아 보이는 게임 또는 가장 큰 경제적 성과를 달성하고 있는 게임의 인터페이스를 거의 무지성으로 복제했는데 이 과정을 통해 만들어진 것이 팝업 모양의 인벤토리 인터페이스였습니다.

이렇게 급하게 만든 우리들의 의도 보다는 우리들의 가능성을 보이기 위한 빌드는 경영진의 그렇게 높지는 않은 것 같았던 눈높이를 무사히 만족해 본격적으로 개발을 시작합니다. 그런데 이번에는 프로젝트 리더십으로부터 이번 마일스톤 목표로 인벤토리 인터페이스를 ‘개선’하라는 요구를 받습니다. 이런 종류의 요구사항은 ‘개선’이라기 보다는 ‘취향에 맞게 수정’하는데 더 가까운데 앞에서 우리들이 근본적으로 수행하는 일은 스폰서의 요구사항을 만족하는 게임을 개발하는 거라고 말했듯 그 주체적인 과정은 서로 모순되더라도 리더십의 취향을 만족하는 게임을 개발하고 이들 사이의 충돌을 정리하는 것입니다. 또한 우리들이 해야 하는 일은 리더십이 우리들의 목을 날리려고 호시탐탐 기회를 노리는 경영진에게 우리들의 생계를 유지해야 하는 이유를 설명할 때 체면을 세워 주는 것으로 리더십의 취향에 맞는 개발을 하면 경영진에게 보고할 리더십의 자신감을 북돋아 더 강한 설득력을 가지도록 하는 효과도 있습니다.

인벤토리 인터페이스는 이전의 팝업 모양에서 그 시점에 혜성처럼 갑자기 나타나 꽤 훌륭한 경제적 성과를 거둔 게임이 도입한 전체화면 인벤토리 인터페이스를 복제한 모양으로 바꾸기로 합니다. 그 시점까지 사용하던 팝업 모양 인벤토리 역시 극 초반에 무지성으로 결정한 결과가 이 시점까지 이어지고 있어 전체화면 인벤토리 인터페이스를 도입하라는 목표 역시 비용이 좀 비싸 제한된 기간 안에 달성하기 부담스럽다는 점 외에는 별다른 반발도 없었습니다. 전체화면 인벤토리는 화면을 반으로 갈라 한 쪽에는 캐릭터 외형과 장착 장비를, 오른쪽에는 탭 인터페이스를 통해 아이템을 필터링 할 수 있는 인벤토리 인터페이스를 표시한 모양이었는데 기존 팝업 모양 인벤토리 인터페이스를 통해 제공하던 정보에 비해 훨씬 더 많은 정보를 한 번에 제공해야 했고 장비 탈착 기능과 캐릭터 외형 정보를 함께 보여주려고 보니 이 기능들 역시 기능 각각이 다양한 기능을 요구해 화면은 예상보다 훨씬 복잡해집니다.

이런 복잡한 상황 속에서도 다행인 점은 시장에서 꽤 큰 경제적 성공을 거두고 있던 바로 그 게임의 전체화면 인벤토리 인터페이스를 거의 그대로 참고할 수 있어 방금 소개한 어려운 점들을 반쯤은 무지성으로 복제해 온 덕분에 개발 시간을 크게 단축할 수 있었다는 것입니다. 오히려 우리들 입장에서는 처음에 무지성으로 선택한 팝업 모양 인벤토리 인터페이스에 비해 현대적인 요구사항에 의한 여러 인벤토리 연관 기능을 한 화면 안에 넣을 충분한 공간을 확보할 수도 있게 됐습니다. 가령 게임에 따라 인벤토리 안에서 직접 인첸트를 할 수 있거나 인벤토리 안에서 직접 아이템을 강화하거나 파괴할 수 있는데 인벤토리 인터페이스 공간이 넓어지며 이런 기능을 인벤토리 인터페이스에 직접 포함할지 여부를 이전에 비해 훨씬 편하게 결정할 수 있게 됩니다. 물론 이런 결정에는 근본적으로 그 버튼들이 정말 필요한지, 또 그 버튼들이 필요하다 하더라도 인벤토리 인터페이스와 함께 위치하는 것이 맞는지 같은 고민은 충분히 이루어지지 않은 것이 사실입니다.

한편 이렇게 반 쯤 무지성으로 개발을 계속하던 어느 날 새로운 경영진의 결단으로 새로운 리더십이 팀에 나타났는데 어떻게 이 사람을 데려왔는지 모르겠지만 이 사람은 업계에서 굉장히 큰 경제적 성공을 달성하는데 큰 기여를 한 것으로 알려진 분이었습니다. 이 분으로부터 분명 배울 것이 많을 거라고 예상해 기대했는데 결론부터 말하면 분명 배울 것이 많았고 많이 배웠으며 게임을 바라보는 시각 자체를 바꿔 놓습니다. 하지만 그 과정은 굉장히 고통스러웠고 그 과정의 끝에는 사람이 완전히 망가져 팀을 이탈하게 된 계기가 되기도 했지만요. 이 분으로부터 얻은 가장 큰 자산은 게임의 여러 구성요소는 핵심 메커닉을 지원하는 일관된 의도에 기반해 설계되어야 하며 핵심 메커닉과 따로 노는 구성요소로 가득한 게임은 핵심 메커닉이 재미 있거나 말거나 제대로 동작하지 않을 수밖에 없다는 사실을 제대로 인식하게 된 것입니다. 이런 인식에 기반해 모바일 MMO 게임을 만들며 인벤토리 인터페이스에 관심을 가지고 특히 전체화면과 팝업 모양의 인터페이스에 집중하게 됩니다.

이 분과 함께 맨 먼저 시작한 일은 주요 인터페이스를 게임의 성격에 맞게 고치며 동시에 게임의 성격을 제정립하는 일이었습니다. 그때 까지는 솔직히 우리가 만든 이 빌드가 근본적으로 고객에게 어떤 경험을 주게 될 지 잘 설명하지 못했습니다. 그저 여느 수집형 게임처럼 MMO 게임도 일단 시작하면 퀘스트 밀고 중간 중간에 PvP 맛보기 시키고 일정 수준 이상 성장하면 스포츠 PvP 모드를 제공하고 필드 PvP 제공하고 또 대규모 팀 PvP를 제공해 플레이어들이 서로 경쟁하게 만들 어렴풋한 계획을 가지고 있을 뿐이었습니다. 경영진은 퀘스트에 아주 큰 관심을 가지고 있어 이 부분은 꽤 깊이 연구했지만 다른 부분은 충분히 연구하고 있다고 말하기는 어려웠습니다. 이런 상황에서 새로운 리더십은 우리 게임이 고객들에게 줄 경험을 필드 PvP와 대규모 팀 PvP로 정의하고 이 방향으로 경영진을 설득함과 동시에 팀에는 여기 맞는 인터페이스를 고안하라는 명령을 내립니다.

사실 이 시점까지 솔직히 우리들은 게임의 핵심 경험에 어울리는 인터페이스가 어떤 것인지 잘 이해하지 못했는데 이 때 장시간 노동과 인간성이 망가지는 과정을 통해 핵심 메커닉에 어울리는 인터페이스를 고안하는 요령을 배웠습니다. 과정은 거칠었지만 결과는 아주 간단한데 이 분이 이전에 고안한 게임은 고객들에게 필드 PvP 경험을 제공해 강한 경쟁 상태를 만들고 필드를 이동할 때 PvP의 패널티로부터 고객을 긴장 상태로 만들며 이 긴장 상태를 계속해서 유지하기 위한 일종의 항상성 유지를 매니지먼트 요소로 만들어 인벤토리 인터페이스를 사용하게 하는 겁니다.

이전에는 인벤토리를 팝업 모양으로 만들건 전체화면 모양으로 만들어도 게임 플레이에는 별 차이가 없었습니다. 플레이 중 사용할 아이템은 포션류 아이템이 거의 전부였고 그나마 포션류 아이템은 별도 자동사용 인터페이스에 설정되어 있어 인벤토리를 열어 아이템을 사용할 이유가 없었습니다. 그런데 필드 PvP를 감안해 플레이어의 항상성 유지가 핵심 경험의 일부가 되면서 그저 자동으로 포션을 사용하는 수준의 항상성 유지만으로는 필드 PvP가 요구하는 더 높은 수준의 항상성 유지를 달성할 수 없었습니다. 새로운 세계에서 플레이어들은 필드를 지나다닐 때 설정에 따라 자동으로 사용할 포션을 가방 가득 들고 다녀야 할 뿐 아니라 일정 시간 동안 능력치를 올려 주는 여러 종류의 물약을 사용하고 이들의 남은 수량과 남은 쿨타임을 별도로 관리해야 했고 즉시 지정된 스킬을 사용하는 ‘주문서’류 아이템들을 인벤토리로부터 즉시 사용할 준비를 해야 했습니다.

그래서 다른 그럴싸해 보이는 게임을 복제해 전체화면 모양으로 만들었던 인벤토리 인터페이스를 초기에 그랬던 것처럼 팝업 모양으로 바꿔 인벤토리를 연 상태로 게임을 플레이 할 수 있게 하고 인벤토리가 차지하는 화면 영역을 좀 더 좁게 만들어 인벤토리를 연 상태에서도 게임 상황을 최대한 많이 확인할 수 있게 만들었습니다. 이와 동시에 기존에는 별도의 자동사용 슬롯에 설정되어 자동으로 사용되던 체력포션류 아이템 외에도 여러 능력치의 항상성을 유지하는 아이템들이 추가되었으며 이들이 전용 슬롯에 설정되어 있지 않더라도 그냥 인벤토리 안에서 쿨타임마다 자동 사용되는 기능을 도입합니다.

기존 인벤토리에서 아이템을 사용하면 한 번 사용하고 끝나는 식이었지만 이 시점부터는 인벤토리에서 아이템을 한 번 사용할 수도 있고 아이템을 토글하면 자동 사용이 시작되어 아이템이 사라질 때까지 쿨타임마다 아이템이 자동 사용되어 항상성을 유지할 수 있게 됩니다. 이런 변화에 따라 이전에는 아이템 갯수가 0이 되면 인벤토리에서 아이템 아이콘이 사라졌지만 인벤토리 슬롯 하나하나가 플레이어의 항상성을 유지하는 자동사용 슬롯으로 사용할 수 있게 되면서 아이템에 따라서는 갯수가 0이 되더라도 아이템 아이콘을 없애지 않고 0개가 된 상태로 인벤토리에 아이콘을 남겨두기도 합니다.

이런 경험에서 얻은 가장 큰 자산은 앞에서 설명한 게임의 여러 구성요소를 설계할 때는 게임의 핵심 메커닉을 이해하고 핵심 메커닉을 보조할 수 있는 모양으로 구성요소를 설계하려는 의도가 필요하다는 겁니다. 인벤토리를 만들어야 한다고 해서 그저 다른 게임의 리퍼런스를 가져와 그들 중 좀 더 시각적으로 그럴듯해 보이는 모양을 선택해 인벤토리 디자인을 시작할 때 운이 좋으면 이 의사결정이 미래에 문제를 일으키지 않을 수도 있지만 운이 나쁜 대부분은 문제를 일으키거나 이게 문제라는사실 조차 잊어버려 뭔가 게임 전체가 잘 안 맞는 느낌이 들기는 하지만 뭐가 문제인지 잘 알아낼 수 없는 상태에 빠질 수도 있습니다. 다시 말하면 구성요소를 설계하려고 할 때 반드시 게임의 핵심 메커믹이 일관성 있게 정의된 상태여야 합니다. 게임이 아직 잘 정의되지 않은 상태에서는 구성요소 설계에 대해 이러쿵 저러쿵 이야기해 봐야 아무런 의미가 없습니다.

근래에 왜 인벤토리에 전체화면 인터페이스를 사용하려고 하나요?에 소개한 의사결정을 하며 비슷한 상황을 겪을뻔 했습니다. 이번에도 인벤토리 인터페이스를 설계해야 했는데 게임의 핵심 메커닉은 인벤토리와 같은 마일스톤에 동시에 개발되고 있었습니다. 기획서 상으로는 어떤 모양이 될 지 이해했지만 실제로 그 모양 대로 개발되지 않으리라는 사실은 너무 당연합니다. 개발하다 보면 여러 가지 문제, 새로운 아이디어, 더 나은 방법을 배우게 되고 이 과정에서 처음 기획서에 제안한 모양과는 꽤 다른 결과가 나올 겁니다. 이런 상황에서 인벤토리 인터페이스는 당장 팀 안에서도 그런 모양을 선택해야 하는지 의문을 제기 받을 수밖에 없었습니다.

이런 상황에서는 아직 게임이 없는 상태에서 인벤토리 구조를 제안한 이유를 설명해야 하기 때문에 아주 작은 문제 제기에도 쉽게 확고한 이유를 설명하지 못하고 흔들릴 수 있습니다. 누군가 인벤토리를 열고 있다가 총 맞아 죽으면 기분 나쁘니 인벤토리를 팝업 모양으로 만들어야 한다고 말할 때 여기 동의하거나 동의하지 않을 수가 없습니다. 아직 게임이 없는 상태여서 이 의견을 받아들일지 그렇지 않을지 자체를 결정할 수가 없기 때문인데 그렇다고 대놓고 의견을 무시하기에는 인간관계나 여러 사람의 의견을 경청하는 자세를 요구 받는 상황 상 어렵습니다. 그래서 이런 일이 주니어 스탭님께 일어나면 서로 배타적인 여러 가지 의견을 받아 이들 모두를 만족해야 하는 불가능한 시도를 하다가 혼자 고통 받고 면담을 요청하는 상황에 도달할 수 있습니다.

이런 상황을 해결하는 방법은 간단한데 지금 게임이 없고 없는 게임을 기준으로 의사결정을 할 수 없다는 사실을 선언하는 겁니다. 이건 주니어 스탭님이 직접 하기는 어렵고 위에서 선언해 줘야 합니다. 아직 우리가 직접 만져볼 수 없는 빌드가 없는 상황에서 인벤토리에 대해 쏟아지는 여러가지 우려와 ‘좋은’ 의견은 지금 받아들일 수가 없습니다. 지금 받아들이려고 해도 게임이 아직 없는 상태에서는 그게 좋은 의견인지 아닌지 평가할 수가 없기 때문입니다. 다만 현 시점에서 가장 유효한 제안을 하기 위해 아직 개발되지는 않았지만 우선 기획서 상에 제안된 게임에 근거해 게임이 이대로 만들어진다고 가정하고 여기에 가장 적합한 제안을 하는데 집중하게 해야 합니다. 만약 여기서 시니어 스탭이나 중간관리자가 모호한 입장을 취하면 팀 안팎에서 날아오는 옳고 그름을 평가할 수 없는 ‘좋은’ 의견에 파묻혀 스탭님들이 고통 받게 됩니다.

결론. 게임의 여러 구성요소는 철저히 게임의 핵심 메커닉에 근거해 이를 보조하는 관점에서 설계되어야 합니다. 그렇지 않으면 어딘가 아귀가 잘 맞지 않는 이상한 게임을 만들고도 어디가 이상한지 찾을 수 없는 불행한 상태가 됩니다. 하지만 실제로는 핵심 메커닉이 아직 확고하지 않은 상태에서 구성요소를 개발해야 할 때가 많습니다. 이런 상황에서 중간관리자가 핵심 메커닉이 없는 상태에서는 의견을 평가하기 어렵다는 사실을 선언하고 현 시점에 가장 유효한 근거인 핵심 메커닉 기획에 기반해 이를 가장 잘 지원하는 구성요소 설계를 채용해야 합니다. 만약 팀에서 주니어 스탭님이 이런 구성요소를 설계할 때 중간관리자가 모호한 태도를 취하면 상화 배타적인 요구사항을 만족하는 불가능한 시도를 하느라 스탭님들이 다칠 수 있어 구성요소 설계에 실패할 수 있습니다. -없는 게임에 근거해 의사결정을 하게 놔 두면 안됩니다.