UI 조작 중 공격을 받으면 어떻게 처리해야 할까요?

종종 제가 어떤 결정을 내릴 때 다른 사람이 보면 아무 생각 없이 그냥 1초 만에 결정을 내리는 것처럼 보일 때가 있습니다. 가령 ‘보상을 지급하는데 사용된 보물상자는 사라져야 하나요?’ 같은 질문을 받고 1초도 안 되어 ‘네'라고 답하고 또 ‘파티 던전에서 파티로부터 탈퇴되면 쫓겨나야 하나요?’ 같은 질문에도 1초도 안 되어 '네’라고 답합니다. 여러 가지 다른 질문에도 어지간하면 순식간에 답하기 때문에 답을 들은 상대는 종종 ‘아니 우진님. 이거 좀 생각도 해 보고 다른 부서들 이야기도 들어봐야 하는 거 아니에요?’라고 묻기도 하지만 그럴 생각도 없고 답변을 바꿀 생각도 없습니다.

어떤 질문에 순식간에 답할 수 있는 두 가지 이유가 있는데 하나는 이전에 다른 프로젝트에서 같은 상황을 경험해본 다음 나름의 결론을 내렸기 때문이고 다른 하나는 이런 질문은 거의 대부분 이미 정답이 있는 문제이기 때문입니다. 그래서 제 선에서 순식간에 답할 수 있고 그 답을 바꿀 필요가 거의 없으며 다른 부서의 의사를 물어볼 필요도 없습니다. ‘아니 그래도 혹시 다른 부서는 이런 걸 하고 싶어하지 않을까요?’라는 질문을 다시 받을 때도 있습니다. 여기에는 ‘그럼 그렇게 동작하는 게임이 하나라도 있으면 말해보세요.’라고 되묻는데 이 질문에 답을 받아본 적이 없습니다.

이전에 여러 MMO 개발팀에서 일하며 겪던 문제 중 하나는 애초에 회사가, 프로젝트가 어떤 제품을 만들어야 할지 잘 모르는 상태에서 일단 프로젝트를 승인해 버리는 바람에 단순한 요구사항을 정의하는 단계에서조차 어려움을 겪는 것입니다. 이전에 희미한 비전에 비슷한 이야기를 한 적이 있는데 프로젝트 리더십을 포함한 고위 의사결정자 중 그 누구도 세부 기능의 요구사항을 정의하기 위한 미래에 완성되어야 할 제품의 모습을 상상하고 있지 않을 때가 많았고 어쨌든 이미 시작된 프로젝트에 고용된 우리들은 아주 간단한 동작 하나를 정의하는 것조차 힘들어했습니다. 가령 인벤토리 한 칸에 아이템을 몇 개 까지 겹칠 수 있나요? 같은 질문에 즉시 답할 수가 없었고 또 인벤토리 최대 한도보다 더 많은 아이템을 받을 때 처리 방법을 정의하는데도 어려움을 겪었습니다. 이런 결정은 근본적으로 우리들이 인벤토리 크기를 제한함으로써 고객들에게 인벤토리를 관리하는 플레이를 하게 만들지 그렇지 않을지에 대한 결정에 근거해야 합니다. 게임에 따라 인벤토리 크기를 제한해 고객들에게 어느 시점에 몬스터가 드랍한 아이템을 가질지 말지를 결정하거나 더 중요한 아이템을 가지는 대신 들고 다니던 덜 중요한 아이템을 버리는 의사결정을 하게 만들 수도 있습니다. 반대로 어떤 게임은 사실상 인벤토리 크기에 거의 제한을 두지 않고 보상을 획득하는 족족 인벤토리에 신경 쓰지 않고 보관하게 하는 대신 이 아이템들을 갈아 다른 장비 성장에 경험치로 사용하도록 하고 이 과정을 매끄럽게 만들어 인벤토리에 수많은 아이템이 끝없이 들어오든 말든 고객은 신경 끄고 그저 자신의 성장 목표에 집중하는 경우도 있습니다. 이런 상황 속에서 아무 것도 결정되지 않았을 때 기획팀 실무자에게 저런 인벤토리에 대한 질문이 들어오면 쉽게 답할 수가 없습니다.

이런 상황에서 인벤토리의 동작 같은 가장 근본적이고 기초적인 동작 요구사항을 정의하는 과정은 너무나 지난한데 요구사항의 구렁텅이에서 빠져나오기에 소개한 것처럼 일단 아무 근거도 없는 초안을 작성한 다음 온갖 사람들이 자신만의 추측에 근거해 내뱉는 사실상 의미 없는 요구사항을 받고 이를 반영하고 또 다른 의견이나 다른 경험을 가진 사람들의 의견을 받고 수정하기를 반복한 끝에 그나마 여러 협업 부서들이 합의한 제안이 만들어지기 때문입니다. 이 요구사항을 기록한 기획서에는 어느 순간 실무자의 의견이나 실무자의 게임 경험 같은 것은 전혀 남아 있지 않으며 그저 수많은 사람들이 아무런 근거 없이 내 뱉은 말들을 아슬아슬하게 엮어 그나마 구현 가능하도록 만든 결과가 적혀 있을 뿐입니다. 이런 상황에서 기획서를 작성한 담당자조차 기획서에 언급되지 않은 코너 케이스 처리 방법에 대한 질문을 들으면 자기 자신이 그동안 이 요구사항을 작성하는데 짧지 않은 시간을 사용했음에도 불구하고 쉽사리 대답할 수가 없습니다. 가령 인벤토리에 같은 아이템을 한 칸에 여러 개 쌓을 수 있는데 이렇게 한 칸에 쌓인 아이템을 두 칸 이상에 걸쳐 분해할 수 있는지에 대한 질문을 받을 수 있습니다. 과거에는 한 칸에 쌓인 같은 아이템 여러 개를 선택한 다음 이를 서로 다른 수량의 두 칸에 걸친 같은 아이템으로 분해할 수 있었고 이 기능의 존재가 당연했습니다. 하지만 이 기능이 왜 필요했는지, 그리고 현대에 가까워질수록 이런 기능을 제공하는 게임이 점점 더 줄어드는 이유가 무엇인지 고민해보지 않았거나 우리가 만드는 게임이 인벤토리에 이런 기능을 필요로 하는지에 대한 정보를 입수한 적이 없다면 이 간단한 질문 조차 답할 수가 없습니다.

이런 상황은 간단한 요구사항을 쉽게 복잡하게 만듭니다. 한 칸에 쌓인 같은 아이템을 두 칸 이상으로 분리하는 기능이 필요한지 그렇지 않을지 답할 수 없는 상황에서 좋은 방법은 그냥 필요하다고 답하는 것입니다. 물론 질문을 한 엔지니어나 질문에 답한 게임디자이너 양쪽 모두 이 답변이 그리 만족스럽지 않을 겁니다. 게임디자이너는 근거 없는 답변을 했기 때문에 만족스럽지 않을 것이고 답변을 들은 엔지니어는 자기 자신도 고객인 관점에서 최근 그런 기능이 있는 게임을 접한 기억이 거의 없기 때문입니다. 하지만 아주 먼 과거에 그런 기능이 있는 게임을 경험한 적이 있기에 질문을 하긴 했는데 엔지니어가 기대한 답변은 분명 게임 전체에 걸친 요구사항에 근거한 답변이었을 겁니다. 엔지니어는 답변을 얻기는 얻었지만 뭔가 찜찜한 기분을 지울 수 없을 수 있습니다. 하지만 요구사항을 정의하는데 필요한 미래에 프로젝트가 갖춰야 할 모양을 아무도 상상하고 있지 않은 상황에서 이런 질문은 대체로 그 기능이 필요하다는 쪽으로 답변될텐데 이유는 기능이 없어서 나중에 곤란해지는 것 보다는 기능이 있지만 사용하지 않는 쪽이 미래에 구성원 전체에 걸쳐 더 안전하기 때문입니다. 이런 결정들이 쌓이면 한 2년이면 충분히 만들 수 있을 만한 빌드를 개발하는데 훨씬 더 긴 세월이 걸리고 그러는 사이에 시장이 바뀌고 우리 프로젝트를 담당하는 임원이 바뀌고 또 프로젝트 구성원들이 바뀌면서 의견이 바뀌고 또 누군가의 상상이 바뀌는 과정을 거치며 개발 비용은 계속해서 증가해 운이 아주 아주 아주 아주 좋다면 10년의 밤과 같은 상황을 맞을 수 있지만 그렇지 않다면 이력서에 아무 것도 쓸 수 없는 긴 세월을 보낸 신세가 되고 말 겁니다.

어느 늦겨울에 피면접자로 참여한 어떤 면접 자리에서 그들의 프로젝트를 살펴보고 어떻게 이렇게 빨리 만들었나요?라고 질문했었는데 이 질문에 대한 리더십의 답변은 정말로 인상적이었습니다. 이 분은 이전에 다른 회사에서 MMO 게임을 개발하며 이 장르 게임 개발이 왜 그렇게 힘들고 또 오랜 세월이 걸리는지 이미 잘 알고 계셨습니다. 회사에서 우리 프로젝트를 담당한 임원 뿐 아니라 프로젝트 리더십, 고위 의사결정자들 중 그 누구도 미래에 실제 제품이 동작할 모습에 대해 깊이 고민하지 않고 또 깊이 상상하지 않았기에 우리들은 항상 희미한 비전 속에 일할 수밖에 없는데 이런 상황에서 우리들의 기능 요구사항은 만약을 대비해 더 많은 기능을 준비하는 쪽으로 치우칠 수밖에 없습니다. 만약 누군가 뚜렷한 비전에 근거해 우리들이 개발해야 할 빌드가 미래에 어떤 모양으로 동작할 작정인지 상상하고 이를 우리들에게 전달할 수만 있다면 우리들은 세부 기능을 정의할 때 필요하지 않은 기능에 대해서는 완전히 관심도 기울이지 않은 채 정확히 필요한 기능만을 요구할 수 있습니다. 가령 인벤토리에서 아이템을 나눌 수 있을지 같은 질문에 정확히 필요하다, 또는 필요하지 않다고 답할 수 있게 됩니다. 사실 현대에 이 기능은 그리 필요하지 않은데 과거에 이 기능이 필요했던 이유는 아이템을 수량 별로 분리해 이 분리된 아이템 스택을 개인 간 거래, 거래소 판매, 상점 판매, 필드에 떨어뜨리기 등 여러 가지 목적으로 사용해야만 했기 때문입니다. 현대의 여러 게임이 더 이상 이 기능을 제공하지 않는 이유는 여러 가지 이유로 개인 간 거래가 없고 아이템을 수량 별로 나눠 어딘가에 전달해야 할 필요 자체를 만들지 않기 때문입니다.

이런 질문에 대답하다 보면 과거에서 현재에 이르는 시간 속에서 고객들이 게임에 요구하는 경험과 우리들이 게임을 통해 고객들에게 부여하려는 경험이 서서히 변해 가고 있음을 읽을 수 있습니다. 여러 게임을 직접 플레이하고 또 다른 사람들이 게임을 플레이 하는 모습을 살펴보고 또 시장의 다른 플레이어들이 그들 나름의 고민을 통해 출시한 새로운 게임의 형태를 살펴보며 이런 변화를 감지하고 나면 설사 우리들에게 부여된 비전이 희미하다 할지라도 여러 가지 문제는 사실 이미 시장의 흐름에 따라 정답이 있음을 알 수 있습니다. 가령 맨 처음 이미 보상을 지급한 보물상자가 사라져야 할 지, 아니면 그렇지 않아야 할 지에 대해서는 당연히 ‘보물상자는 사라져야 한다’고 답했는데 이는 이미 이렇게 동작하는 것이 현대에 정답이기 때문입니다. 이전 시대에 보물상자는 종종 보상을 지급한 다음에도 그 자리에 그대로 남아 있었는데 이는 현실 세계의 동작을 모방한 동작이기에 딱히 이상하다고 볼 수 없지만 실은 기술적인 제약 때문에 남아 있어야만 합니다. 보물상자는 게임 속 세계에 놓인 단단한 물체이기 때문에 플레이어는 보물상자를 뚫고 지나갈 수 없습니다. 사람이 보물상자를 뚫고 지나갈 수 없다는 요구사항은 간단히 클라이언트에서 사람과 보물상자가 서로 충돌하게 하면 간단히 해결할 수 있습니다. 그런데 서버로부터 명령을 받아 움직이는 몬스터들은 서버가 알려주지 않는 한 보물상자의 존재를 알 수 없기 때문에 보물상자를 뚫고 이동할 겁니다. 이는 고객 입장에서 명백히 이상한 동작이기에 서버에게 보물상자의 존재를 알려주되 보물상자가 사라지지 않는다고 정의함으로써 서버가 보물상자의 존재 여부에 따라 내비게이션을 수정하지 않아도 되는 이점을 만들어 줍니다.

하지만 현대에 가까워지며 보상을 지급한 보물상자, 이미 파괴한 바리케이트, 상호작용을 마친 스위치 따위를 종종 세계에서 없애기 시작합니다. 이는 과거 관점에서 보면 서버에게 더 많은 부담을 지우는 행위입니다. 서버 입장에서 과거에 이미 보상을 지급한 보물상자가 뚜껑이 열린 채 그 자리에 남아있으면 보물상자가 결코 사라지지 않기 때문에 그 위치의 내비게이션을 변경할 필요가 없습니다. 한 번 생성한 고정된 내비게이션 정보만으로 플레이어와 몬스터 양쪽 모두의 이동을 자연스럽고 저렴한 비용으로 제어할 수 있습니다. 그런데 현대에 가까워질수록 고객들의 집중력이 낮아지고 또 우리들 스스로가 고객들로 하여금 보물상자에 더 강하게 반응하도록 게임 속 상황을 만들어 온 덕분에 고객들은 이미 보상을 수령한 보물상자가 사라지지 않고 그 자리에 남아있으면 종종 아직 받을 수 있는 보상이 남아 있다고 생각하고 게임을 더 진행하는 대신 그 자리에 머무는 경향이 생겼습니다. 이에 따라 여러 게임들이 이미 보상을 수령한 보물상자, 이미 필수 상호작용을 끝내고 더 이상의 상호작용을 일으키지 않는 물체 따위를 세계에서 제거함으로써 고객에게 이 곳에는 더 이상 기다릴 만한 요소가 없으니 다음으로 진행하라는 신호를 주기 시작합니다. 서버 입장에서는 과거에는 보물상자가 사라지지 않아 보물상자가 항상 존재하는 상태로만 내비게이션을 생성하면 됐지만 이제 보물상자의 현재 상태에 따라 내비게이션을 동적으로 제어해야만 하는 상황에 놓입니다. 때문에 게임디자인에 이에 대한 문의를 할 수 있는데 게임디자인에서 할 수 있는 답변은 하나 뿐입니다. ‘보물상자는 보상을 먹고 나면 사라져야 합니다.’

이런 답변을 빨리 하려면 이미 그 이전에 우리에게 부여된 게임의 비전에 관계 없이 과거로부터 현재에 이르는 세월에 따라 게임이 어떻게 변해 왔는지 생각해본 상태여야 합니다. 이런 변화를 감지하고 있다면 비록 우리들에게 부여된 비전이 흐릿하다 할지라도 어지간한 자잘한 동작에 대해 바로바로 답할 수 있습니다. 이렇게 즉시 정확한 요구사항을 정의하고 이를 답변할 수 있는 질문들의 공통점은 이미 어느 정도 정답이 있는 문제라는 점입니다. 만약 본격적으로 창의성을 요구하는 종류의 질문은 아무리 단단한 비전에 근거해 요구사항을 정의하는 상황이라 할 지라도 그렇게 빨리 답할 수 없습니다. 하지만 이미 오랜 세월에 걸친 고객들의 변화와 이에 대응하는 게임의 변화, 이런 변화가 현실과 만나 출시된 시장의 다른 플레이어들이 개발한 결과들을 살펴봤다면 어지간한 질문은 고민하지 않고 즉시 답할 수 있습니다. 생각 없이 아무 대답이나 그냥 막 하거나 그냥 둘 중 하나를 찍는 것처럼 보일 수 있지만 이 때 생각하고 고민하는데 시간을 전혀 쓰지 않을 수 있는 이유는 이미 이 질문을 받기 전 오랜 시간에 걸쳐 미리 생각해 놨기 때문이고 이런 생각 끝에 어지간한 질문은 이미 정답이 정해진 문제로 정의해 놓았기 때문입니다. 그러니 질문하면 생각 없이 답하는 것처럼 보이는데 이미 생각은 오래 전에 해놨습니다. 또한 정답이 있기에 다른 부서에 의향을 물어볼 필요가 없습니다.

이런 관점에서 종종 듣곤 하는 질문에는 전체화면 UI를 조작하는 도중 누군가로부터 공격을 받을 때 어떻게 동작해야 하는지에 대해서입니다. 경우가 약간 다르기는 하지만 이전에 전체화면 팝업의 위험성에서 전체화면 인터페이스를 다루는 한 가지 방식을 설명한 적 있는데 한때 모바일 게임에서 여러 인터페이스를 팝업 모양으로 만들다가 본격적으로 인터페이스가 복잡해지며 언리얼 엔진 기준으로 '씬'이라고 부르는 전체화면 인터페이스에 기반한 인터페이스를 만들어 왔습니다. 전체화면 인터페이스는 게임을 잠시 중단하고 여러 가지 정보를 한 번에 받아들이며 여러 가지 조작을 한 번에 집중해서 할 수 있다는 점에서 장점이 많습니다. 가령 세 가지 신화에 소개한 어쎄신크리드 시리즈는 어지간한 성장, 전투 설정 변경, 퀘스트 선택, 인벤토리 관리, 암살 대상 관리 같은 여러 행동들을 전체화면 인터페이스를 통해 차례로 살펴보고 조작할 수 있습니다. 일단 전체화면 인터페이스를 열면 탭을 차례로 넘기며 퀘스트를 선택하고 다음 죽일 사람을 결정하고 다음 모험 지역을 살펴보고 인벤토리를 정리하고 정비를 교체하고 또 전투 스킬을 변경하는 등 여러 가지 준비 작업에 집중할 수 있습니다. 이 과정이 끝나면 세계 지도를 보여주는 탭으로 넘어와 다음 임부를 수행할 장소로 이동하며 인터페이스 조작을 마칠 수 있고 이 시점부터 다시 인게임에 집중하게 됩니다.

사람들이 주로 콘솔 게임에서 이런 인터페이스를 사용한다고 생각하고 콘솔 게임을 개발하려 한다면 으레 이런 전체화면에 모든 기능을 갖춘 인터페이스 모양을 만들어야 한다고 여기는 경향이 있는 것 같습니다. 그런데 실제로는 전체화면 인터페이스와 콘솔 게임은 서로 별 관련이 없습니다. 이런 게임이 전체화면 인터페이스를 사용할 결정을 편안하게 할 수 있는 가장 큰 이유는 이들 게임이 대부분 싱글플레이 게임이어서 전체화면 인터페이스를 열고 있는 동안 그 뒤에 있는 게임이 멈추기 때문입니다. 어쎄신크리드에서 한창 적과 싸우다가도 전체화면 인터페이스를 열어 여러 설정을 살펴보거나 그저 게임을 일시정지 하는 용도로 사용할 수 있습니다. 이는 전체화면 인터페이스로 전환하면 게임이 정지하고 이는 이 게임이 싱글플레이 게임이기 때문에 가능한 것입니다. 내가 게임을 멈추고 싶다 하더라도 결코 게임을 멈출 수 없는 온라인 멀티플레이 게임들을 생각해보면 상당히 많은 인터페이스가 화면 전체를 가리지 않는 모양으로 설계되어 있다는 점을 알 수 있습니다. 이는 인터페이스를 열어 조작을 하는 동안에도 게임이 멈추지 않기 때문에 게임 속 상황을 계속해서 지켜봐야만 하기 때문입니다. 특히 다른 플레이어나 몬스터로부터 죽을 수 있는 환경에 자주 노출 시키는 특성이 있는 온라인 멀티플레이 게임의 경우 상당히 많은 정보를 한 번에 제공해야 하기 때문에 어지간한 게임에서 전체화면 인터페이스를 사용해 표현하는 경우조차 인터페이스를 반투명으로 만들어 인터페이스 뒤에 계속해서 동작하고 있는 게임 상태를 계속해서 보여주도록 만들기도 합니다.

종종 이런 인터페이스에 대한 핵심 의사결정이 아트 부서에 의해 일어날 때가 있습니다. 그림 한 장에 예쁘게 표현된 전체화면 인터페이스가 포함된 문서를 통해 제안을 받으면 우리에게 전체화면 인터페이스가 어울리는지 깊이 고민해본 적 없는 어지간한 고위 의사결정자들은 딱히 이를 거절하지 않고 적당히 순응함으로써 사실상 이를 승인하곤 합니다. 이런 행동은 게임의 전체 인터페이스에 걸쳐 결코 돌이킬 수 없는 결과를 만들어버립니다. 게임 전체의 핵심 인터페이스를 단순히 시각적 아름다움만을 고려해 전체화면 인터페이스로 만들고 나면 이는 대체로 멀티플레이 온라인 게임에 어울리지 않기에 이 상태를 해결하기 위한 온갖 다른 장치들을 필요로 하게 되기 때문입니다. 가령 인벤토리가 전체화면 인터페이스를 통해 표시되는 게임은 포션을 사용하기 위해 인터페이스를 여는 상황을 만들 수 없거나 그런 상황을 만들면 죽지 않기 위해 포션을 사용해야 하지만 포션을 사용하려고 인벤토리 인터페이스를 열면 죽고 마는 이상한 상황을 만듭니다. 같은 상황에서 오래된 온라인 멀티플레이 게임처럼 인벤토리가 화면 일부를 가리는 모양으로 나타난다면 게임 상황을 관찰함과 동시에 인벤토리에서 포션을 사용할 수 있기에 죽지 않기 위해 포션을 사용하는 목적을 달성할 수 있습니다. 하지만 단지 시각적 아름다움만으로 결정된 전체화면 인터페이스로부터 포션을 사용하다가 의도와 반대되는 결과를 얻었지만 이를 전체화면 인벤토리 인터페이스의 문제로 정의하기 보다는 도리어 전체화면 인터페이스에 진입하지 않아도 포션류 아이템에 접근할 수 있는 별도의 작은 인터페이스 또는 퀵슬롯 따위를 만들어야 한다는 결정으로 이어지기 쉽고 이게 명백히 이상하다는 사실을 눈치채는 사람은 거의 없을 겁니다.

이런 맥락에서 제목의 ‘UI 조작 중 공격을 받으면 어떻게 처리해야 할까요?’ 라는 질문 역시 질문의 본질을 이해하고 근본적인 문제를 해결하려는 접근 대신 현재 우리가 맞닥뜨린 상황 그 자체만을 해결하려고 집중하고 또 이전에 이 상황이 왜 일어나는지, 이 상황이 오랜 세월에 걸친 게임의 어떤 변화 때문에 발생하는지에 대해 딱히 고민해본 적이 없다면 즉시 답할 수 없거나 이상한 답을 하게 됩니다. 먼저 이 질문은 단어가 생략되어 있는데 정확한 질문은 ‘전체화면 UI 조작 중 공격을 받으면 어떻게 처리해야 할까요?’입니다. 아마도 전체화면이 아닌 다른 인터페이스를 조작하는 도중에는 공격을 받기 전에 공격이 임박했다는 정보를 이미 얻었을 것이기에 고객은 상황이 일어나기 전에 조치를 취할 수 있어 문제가 생기지 않을 겁니다. 그렇다면 이 질문을 유발한 상황은 전체화면 인터페이스를 조작해야 하는 상황임과 동시에 플레이어가 다른 뭔가로부터 공격 받을 수 있는 위험한 장소에 위치하고 있다는 사실을 말해 줍니다. 누군가가 즉시 나를 죽일 수 있는 PvP가 가능한 필드에 서 있다가 문득 항상성 유지를 위한 어떤 아이템을 사용하려고 잠깐 전체화면 인벤토리 인터페이스를 여는 순간 누군가가 은신을 풀고 다가와 나를 공격하는 상황을 상상해볼 수 있습니다. 만약 인터페이스로 화면 전체를 가리지 않았다면 공격 받기 전에 나를 죽이려 다가오는 누군가를 분명 보고 즉시 조치를 취할 수 있었겠지만 항상성을 유지할 아이템을 사용하기 위해 인벤토리를 뒤적이는 사이에 상황이 발생해 버렸습니다.

이 상황은 여러 가지 관점에서 해석해볼 여지가 있습니다. 먼저 게임이 플레이어로 하여금 여러 아이템을 사용해 항상성을 유지하기를 요구하는 것입니다. 어떤 게임은 플레이어의 현재 성장 상태보다 더 강한 상태를 유지할 다양한 방법을 제시하고 플레이어가 항상 이 다양한 방법에 근거해 자신의 실제 성장 상태보다 더 강한 상태를 지속적으로 유지하기를 요구합니다. 꽤 귀찮아 보일 수 있지만 고객에게 이런 요구를 하는 게임들은 항상성을 유지하는 여러 방법들을 자동으로 적용해 고객은 항상성 유지의 근거가 되는 아이템들을 인벤토리에 적당히 채워 넣기만 하면 알아서 항상성이 유지되며 거의 대부분 인벤토리를 열어서 이들의 적용 상태를 확인할 필요 조차 없게 만들어 줍니다. 때문에 항상성 유지를 위해 아이템을 사용할 목적으로 위험한 지역에서 인벤토리를 열었다면 이 때 어떻게 처리할지의 문제가 아니라 이 상황이 일어난 것 자체를 문제로 지목해 이를 해결하는 쪽이 올바릅니다. 다른 하나는 게임을 멈출 수 없는 멀티플레이 온라인 게임이 전체화면 인벤토리 인터페이스를 사용하는 것입니다. 사실 앞서 설명한 대로 여러 사람들은 콘솔 게임과 전체화면 인터페이스를 연결해 잘못된 방향으로 전체화면 인터페이스의 필요성을 생각하는 경향이 있기에 이미 전체화면 인벤토리 인터페이스 그 자체가 문제입니다. 하지만 처음부터 게임의 특성과 플레이 상황에 근거하지 않고 오직 시각적인 아름다움에 기초에 재시된 전체화면 인터페이스는 이미 상황을 되돌릴 수 없을 만큼 게임 깊숙이 들어와 온갖 문제를 일으키고 있을 겁니다.

제목의 질문을 받으면 사람들은 크게 두 가지 방법을 제안합니다. 하나는 공격을 받기 시작하면 고객의 조작 없이 인터페이스를 닫고 고객에게 지금 처한 상황을 즉시 대면하게 하고 상황을 모면할 조작을 하도록 하는 것입니다. 언뜻 보면 말이 되는 것 같고 또 실제로 여러 게임디자이너들이 이런 제안을 별 생각 없이 말했다가 엔지니어에게 가루가 되도록 까이게 됩니다. 고객에게 지금 가장 중요한 상황에 즉시 대변하도록 하는 것 자체는 틀린 접근은 아닙니다. 가령 현대의 제트여객기들은 전방의 지형과 충돌이 임박하면 다른 모든 경고에 우선해 전장 충돌 경고를 시연하고 조종사가 즉시 개입해 상황을 해결할 때까지 경고를 계속합니다. 보잉 비행기는 조종사의 개입 전까지 계속해서 모든 경고에 우선해 전방 충돌 경고를 시연하고 에어버스 비행기는 일정 시점을 넘어서면 조종사 개입 없이 기수를 들어 충돌을 회피하려고 시도합니다. 이는 이 충돌 회피 조작에 따라 거대한 인명 손실을 마주할 수 있는 상황이기에 이런 경고와 조작이 일어나도록 시스템을 설계해도 이상하지 않습니다. 하지만 우리가 개발하는 것은 비디오 게임 소프트웨어로 오히려 고객은 게임의 생애주기에 따라 플레이를 거듭할 때마다 여러 차례에 걸친 죽음을 맞이합니다. 이런 소프트웨어의 특성 상 고객은 가상 세계 속 플레이어의 임박한 죽음보다 지금 전체화면 인터페이스를 통해 조작하려고 하는 작업이 더 중요할 가능성이 없지 않습니다.

앞서 피격을 받으면 전체화면 인터페이스를 닫아야 한다는 게임디자이너의 결정이 엔지니어에 의해 가루가 될 때까지 까이게 된다는 이야기를 했는데 엔지니어 입장에서 고객의 조작 없이 인터페이스를 닫는 행동이 온갖 문제를 유발할 수 있다는 사실을 잘 알고 있을 겁니다. 대체로 인터페이스 상에서 어떤 작업을 실행하기 위해 사전 정보를 입력하고 작업을 시작하려는 순간, 어떤 작업이 완료되기를 기다리는 도중, 인터페이스 플로우 상 여러 단계를 거치는 도중일 때, 어떤 선택을 해야 하는 상황에서 선택을 마치지 않았을 때 등 함부로 인터페이스를 닫기 아주 어려운 상황이 수없이 많습니다. 대략 짚어보면 죽지 않기 위해 포션을 사용하기 위해 포션에 마우스 커서를 대고 사용 메뉴를 클릭하려는 순간 피격을 받아 인터페이스가 닫힐 수 있습니다. 만약 포션을 사용하고 고객이 스스로 인터페이스를 닫았다면 죽지 않을 수 있는 상황이었겠지만 게임이 인터페이스를 직접 닫아버림으로써 고객은 필요 없는 죽음을 경험합니다. 만약 자정이 되면 더 이상 구입할 수 없는 배틀패스 아이템을 구입하려고 23시 59분 52초에 배틀패스 상품을 열고 이를 구입하려는 순간 피격 받아 인터페이스가 닫히고 그저 지나가는 별 것 아닌, 플레이어에게 대미지를 거의 주지 못할 몬스터가 애드 되어 받은 공격일 뿐이었는데 이제 배틀패스 아이템을 다음 달까지 구입할 수 없게 되어 버립니다. 무기 레벨을 올리기 위해 성장 재료를 갈아 넣어 한 번에 레벨 5에서 레벨 9까지 성장할 아이템을 투입한 다음 이제 레벨업 버튼을 클릭하기만 하면 되는 상황이었는데 또 다시 피격으로 인해 모든 인터페이스가 닫혀 버렸습니다. 몬스터야 잡으면 그만이지만 방금 4레벨어치 성장 재료를 투입하는 과정을 처음부터 다시 해야 합니다. 이런 문제는 게임디자이너의 멘탈이 완전히 파괴될 때까지 계속해서 나열할 수 있습니다.

이런 상황이 발생한 근본적인 이유는 게임을 멈출 수 없고 플레이어가 위험한 상황에 뛰어들도록 만드는 게임이면서도 별 생각 없이 전체화면 인터페이스를 자주 사용하도록 만들었기 때문입니다. 근본적으로는 플레이어가 위험에 처할 수 있는 환경에 자주 노출되는 게임은 플레이어를 확인할 수 없는 전체화면 인터페이스를 함부로 사용해서는 안됩니다. 하지만 이미 앞서 설명한 여러 가지 이유로 인해 돌아올 수 없는 다리를 건너버렸다면 퀵슬롯 같은 부가적인 방법으로 안전하지 않은 환경에서 전체화면 인터페이스에 접근해야 할 일을 최소화하고 만약 전체화면 인터페이스를 열고 있는 상태에서 상황이 발생하면 고객에게 이 상황을 인지시키되 절대로 인터페이스를 고객의 조작 없이 닫아서는 안됩니다. 앞서 인터페이스를 고객의 조작 없이 닫을 때 일어날 수 있는 몇 가지 상황을 살펴봤는데 고객은 이런 상황에서 경고를 받고 스스로 인터페이스를 닫은 다음 상황에 대처할 때 불편하고 또 만족스럽지는 않지만 게임에 대한 통제감을 유지할 겁니다. 하지만 같은 상황에서 게임이 인터페이스를 닫아버리고 고객에게 위협과 대면하도록 하면 고객은 똑같이 결국 위협을 해결하고 죽지 않은 상태를 유지하겠지만 게임에 대한 통제감을 대폭 상실하고 상당히 실망한 상태가 될 겁니다. 한참 자고 있는데 누군가가 너무 순식간에 깨워 가장 깊은 수면 상태에서 순식간에 현실 세계로 끌려 나온 것 같은 불편한 감정과 비교할 수 있지 않을까 싶습니다.

제목으로 돌아가 이 질문을 받으면 즉시 ‘위협을 알려주되 인터페이스에는 손대지 않는다’고 답할 수 있습니다. 이 역시 지금까지의 맥락 대로 지난 오랜 시간 동안 일어난 게임의 변화, 싱글플레이 게임과 멀티플레이 온라인 게임의 차이, 이 차이에 기반해 시장의 다른 플레이어들이 출시한 게임들이 같은 상황에 대처하는 방식 따위를 미리 살펴봤다면 생각할 것도 없이 이미 정답이 있는 문제라는 사실을 질문이 끝나기도 전에 알 수 있습니다. 그러면 답변은 하나 뿐입니다. 이 답변을 들은 상대가 ‘그러다 플레이어가 죽으면 어떻게 해?’라든지 ‘전투 부서의 의견도 들어봐야 하지 않을까?’ 같은 질문을 할 수도 있습니다. 상대가 엔지니어라면 이 질문을 이해할 수 있지만 게임디자이너라면 조금은 실망할 것 같습니다. 그러다 플레이어가 죽을 수 있습니다. 하지만 분명히 경고했고 플레이어는 스스로 전체화면 인터페이스를 닫고 위협에 대응해야만 했습니다. 만약 이 죽음을 우리가 반드시 막아야만 한다면 전체화면 인터페이스를 열고 있는 동안은 죽지 않게 하든지 - 끔찍하게 잘못된 방법이지만 - 전체화면 인터페이스를 열고 있는 동안에는 자동으로 전투하게 하는 등 완전히 달리 접근해야만 합니다. 또한 전투 부서에 물어볼 필요도 없습니다. 이는 이미 어느 정도 잘못된 현재 상황에도 불구하고 정답이 있는 문제이기 때문입니다. 그래서 이 질문에 순식간에 답할 수 있고 다른 곳에 물어볼 필요도 없다고 단언할 수 있습니다.

여전히 개발에 실무자로 참여하며 이런 정답이 있는 문제에 대한 질문을 받기도 하고 때로는 정답이 있는 문제 때문에 필요 없는 논의, 필요 없는 협의, 필요 없는 의사결정의 딜레이를 겪어야 할 때가 없지 않습니다. 이런 슬픈 상황들의 근본적인 원인은 프로젝트 리더십이 충분한 상상을 통해 우리들이 만들어야 하는 제품이 미래에 동작할 모습을 제시하지 못한 데서 출발하지만 프로젝트에 참여한 구성원 각각의 관점에서는 굳이 그런 모습을 알지 못하더라도 과거에서 현재에 이르는 세월에 걸쳐 게임이 변화해 온 모습을 생각해보면 상당수의 질문은 이미 정답이 있다는 사실을 알 수 있습니다. 우리들이 게임디자이너로써 프로젝트의 다른 구성원들에게 존중 받으려면 이런 관점에서 우리들의 전문성을 좀 더 갈고 닦을 필요가 있으며 그 결과로 이런 정답이 있는 질문에 거의 생각하지 않고 순간 답하고 그 정답의 유효성을 의심하지 않으며 개발 비용을 줄일 수 있습니다.