따라할 때는 왜 그랬는지 알고 따라해야 합니다
덮어놓고 베끼다 보면 나 자신이 뭘 하고 있는지조차 잊어버리게 됩니다. 매 순간 매가 무엇을 위해 이 짓을 하고 있는지 잊지 않는데 집중합시다. 그렇지 않으면 완전히 이상한 말을 하게 됩니다.
오늘은 어떤 면으로는 굉장히 부끄러운 이야기이고 또 다른 면으로는 적어도 당당하지는 않을 것 같지만 또 부끄럽다고만 이야기하기도 어려운 주제로 시작하려고 합니다. 제 직업은 게임디자이너이고 조금 더 구체적으로는 지금까지 주로 온라인 게임을 개발했으며 그 상당수는 기반 장르가 MMO입니다. 또 그런 소프트웨어 프로젝트에서 주로 여러 세부 기능을 설계하고 협업 부서 중 주로 엔지니어들과 의사소통을 담당해 왔습니다. 이렇게 말하면 뭔가 있어 보일 수도 있는데 사실 게임디자이너로써 가장 많이 해 온 일은 다름 아닌 다른 게임을 플레이 하며 그들이 우리가 만들어야 하는 기능을 어떻게 만들었는지 살펴보고 만약 그들의 결정이 우리 마음에 든다면 그들의 동작을 복제해 문서로 만든 다음 이를 개발하는 것입니다. 우리들은 이런 작업을 종종 리서치 혹은 벤치마크라고 불렀지만 좀 더 현실에 가깝도 더 쉬운 단어를 사용한다면 그 게임을 베낀다고 표현할 수도 있습니다. 가령 우리가 만드는 게임에 어쩌다 보니 야만용사라는 클래스가 등장한다고 해 봅시다. 그렇다면 이와 비슷한 클래스가 등장하는 다른 게임을 살펴본 다음 야만용사의 핵심 전투 메커닉을 설계한다 하더라도 크게 이상하지 않을 가능성이 높습니다. 만약 아주 우연하게도 야만용사라는 클래스가 있는 다른 게임을 살펴보니 그 게임의 야만용사는 양 손에 도끼를 들고 빙글빙글 돌아 주변의 적들에게 대미지를 주는 공격 스킬을 사용하는데 생각해보니 우리 게임에 등장할 우연하게도 이름이 같은 야만용사가 같은 스킬을 사용한다 하더라도 별로 이상하지 않을 것 같습니다. 그렇다면 당당하게 우리 게임의 야만용사의 스킬 기획서 중 하나에 똑같은 스킬 메커닉을 설명하고 이를 개발하고 있어도 분명 이상하지 않을 겁니다.
이런 작업 방식은 꼭 이런 핵심 전투 메커닉에만 해당되는 이야기는 아닙니다. 가령 우리 게임에 들어갈 우편 기능을 설계해야 하는 상황을 생각해 봅시다. 이 업계 밖에서 볼 때 우편 기능을 설계하려면 먼저 게임에 우편 기능이 왜 필요한지, 우편이 어떤 방식으로 사용될지 등을 파악한 다음 이 요구사항에 근거해 우편 기능을 설계할 거라고 예상할지도 모릅니다. 하지만 실제로는 이미 우편 기능에 의도하는 바는 게임마다 거의 비슷하고 앞서 소개한 야만용사와 마찬가지로 우리 게임에 들어갈 우편 기능 역시 우연히 우리 게임에 들어갈 비슷한 기능 역시 우편이라고 정의할 작정이기에 같은 우편 기능이 들어있는 다른 게임을 살펴보고 그들이 여러 가지 기능을 어떤 모양으로 제공하고 있는지 살펴보는데서 시작하면 훨씬 빨리 일할 수 있습니다. 가령 제2의나라 우편 인터페이스로부터 얻은 교훈은 팀에서 수행하던 우편 기능을 설계하는 일을 지켜보며 다른 게임의 우편 기능을 살펴보다가 든 생각을 적은 글인데 제가 직접 수행하는 일이 아니더라도 팀에서 수행되는 일을 알고 있기에 만약 제가 우연히 플레이 하던 다른 게임으로부터 지금 우리 팀이 수행하고 있는 것과 연관된 종류의 기능과 마주치면 이를 평소와는 달리 좀 더 잘 살펴보곤 합니다. 이런 업무 방식은 경쟁이 심한 장르 게임을 개발할 때 생각보다 유용한데 다른 게임과 우연히 이름이 같은 우편 기능은 이미 여러 게임에 걸쳐 널리 사용되고 있기에 고객들이 같은 이름을 보고 예상하는 기능과 예상하는 인터페이스가 대체로 비슷한 모양이기 때문입니다. 만약 우리들이 시장의 다른 플레이어들이 그들 역시 어떤 고민을 통해 개발했을 우편 기능을 참고하지 않고 우리들의 요구사항에 기반해 독자적인 우편 기능을 만들면 종종 고객들이 같은 이름의 기능에 예상하는 기능과 모양으로부터 상당히 동떨어진 결과를 만들어낼 가능성이 있습니다. 고객들은 우리들의 독창적인 우편 기능을 보고 만족할까요? 대체로 그렇지 않습니다. 고객들은 이름이 같으면서도 낯선 모양의 기능을 보고 당황하거나 실망하며 나아가서는 분노를 느낄 수도 있습니다.
그래서 똑같은 우편 기능을 만들더라도 근본적으로는 우리 게임이 우편 기능을 필요로 하는 요구사항을 만족하기는 해야 하지만 그 모양과 표현 방식은 시장에 다른 플레이어들이 이미 서비스 하고 있는 여러 사지 사례를 살펴보고 이들의 발전 방향을 파악한 다음 이에 기반해서 설계할 때 가장 나은 결과를 얻을 수 있습니다. 기왕 우편을 예로 든 김에 조금 더 이야기 해 보면 게임의 우편 기능은 근본적으로 세 가지 측면의 요구사항을 만족하기 위한 기능입니다. 먼저 인벤토리 제한 규칙을 완화하기 위한 도구로써 동작해야 합니다. 게임디자이너, 그 중에서도 주로 시스템디자이너로 일하다 보면 어느 프로젝트에서나 항상 받는 질문 중 하나에 ‘인벤토리가 가득 찬 상황에 어떻게 동작해야 하는가’입니다. 사실 먼 옛날부터 인벤토리가 가득 차는 상황은 여러 게임에 걸쳐 일어났고 각자 자기 나름대로의 방법을 통해 이 상황을 매끄럽게 만들기 위해 노력해 왔습니다. 일단 인벤토리가 가득 차면 필드에서 몬스터를 사냥한 다음 몬스터가 드랍한 아이템을 획득하려 할 때 이 동작에 실패할 겁니다. 이 상황에서 게임은 고객에게 지금 아이템을 획득하지 못했으며 원인은 인벤토리가 가득 찼기 때문이고 이 상태로는 앞으로 게임을 계속해서 플레이 하더라도 아이템 모양으로 된 보상을 획득할 수 없다는 사실을 알려야 합니다. 그리고 고객은 스스로 인벤토리에 쌓여 있는 아이템을 정리하도록 유도합니다. 가령 인벤토리의 아이템을 살펴보고 필요 없다고 생각되는 아이템을 바닥에 버리거나 마을에 돌아가 마르지 않는 돈줄에 기반해 모든 플레이어들로부터 어떤 쓰레기라도 기꺼이 구입해 주는 상인에게 아이템을 판매해 인벤토리에 남은 공간을 확보함과 동시에 약간의 금화를 얻을 수도 있습니다. 이런 플레이는 인벤토리 크기를 적당한 수준으로 제약함에 따라 고객이 게임을 플레이 할 때 일정 시점마다 재정비 해야 하는 상황을 만들어 게임에 리듬을 만들어내는 효과를 주기도 합니다. 만약 이 때 아무 처리도 하지 않고 그냥 아이템 획득에 실패한다면 이를 너무 늦게 눈치 챈 고객에게 큰 실망감을 줄 수 있습니다. 이에 대해서는 이전에 그 규칙은 말이 됩니다. 그런데 고객에게 어떤 경험을 주나요?에 설명한 적 있습니다.
그런데 인벤토리가 가득 찬 상황에서 몬스터 사냥과 같이 고객이 능동적으로 수행한 행동에 의해 아이템을 획득하려는 행동이 실패할 경우 방금 설명한 대로 어렵지 않게 가이드 할 수 있고 또 고객이 이 상황을 해결할 방법 역시 그리 복잡하지 않을 수 있습니다. 그런데 만약 고객이 능동적으로 어떤 행동을 수행하지 않았음에도 게임이 직접 고객의 필요 여부에 관계 없이 인벤토리에 아이템을 넣어야만 하는 상황이 발생한다면 어떻게 처리해야 할까요? 이전에 인벤토리 최대 한도보다 더 많은 아이템을 받을 때 처리에 이 주제를 소개한 적이 있는데 비슷한 이야기를 이어가 보겠습니다. 아주 오래 전 서비스를 시작한 어떤 MMO 게임은 종종 비둘기가 날아와 퀘스트 스크롤을 떨어뜨리고 사라지곤 했습니다. 현대에는 이런 내러티브 없이 무작정 어떤 지역에 들어가면 퀘스트 목록에 퀘스트가 추가되곤 해서 너무 기계적이라는 느낌을 받곤 하기 때문에 비둘기가 물어다 주는 퀘스트 스크롤을 꽤 마음에 들어 했습니다. 하지만 이런 퀘스트 부여 방법은 근본적으로 퀘스트를 받을 플레이어의 인벤토리에 공간이 있다는 가정에 기반하고 있습니다. 만약 비둘기가 아이템 모양으로 된 퀘스트 스크롤을 플레이어에게 떨어뜨렸을 때 플레이어의 인벤토리가 가득 차 있어 퀘스트 스크롤을 받을 수 없다면 어떻게 처리해야 할까요. 앞서 몬스터가 드랍한 아이템이 바닥에 떨어져 있고 인벤토리를 비운 다음 이를 다시 주울 수 있는 규칙이 있는 게임이라면 인벤토리에 들어가는데 실패한 퀘스트 스크롤이 플레이어 옆 바닥에 떨어지고 이를 본 플레이어가 인벤토리를 정리해 공간을 만든 다음 퀘스트 스크롤을 주울 수 있을 것입니다. 하지만 이런 규칙은 여러 모로 위험합니다. 일단 인벤토리에 마땅히 버릴 만한 아이템이 없을 수 있고 또 바닥에 떨어진 아이템은 성능 문제를 완화하기 위해 일정 시간이 지나면 사라질 수도 있습니다. 또 바닥에 떨어진 아이템에 적절한 소유권 개념이 없다면 다른 플레이어가 지나가다가 퀘스트 스크롤을 집어 가 버릴 수도 있고 또 내가 어떤 탈것을 타고 빠르게 이동하던 도중 같은 문제가 일어나면 바닥에 떨어진 퀘스트 스크롤을 아예 못 본 채 지역을 떠나 버릴 수도 있습니다.
이런 온갖 문제를 해결하기 위해 당시 그 게임이 선택한 방법은 임시 인벤토리를 부여하는 방법입니다. 비둘기가 퀘스트 스크롤을 플레이어에게 떨어뜨릴 때 플레이어의 인벤토리가 가득 차 있다면 일단 이 퀘스트 스크롤은 ‘임시 인벤토리’에 들어갑니다. 임시 인벤토리는 플레이어에게 일정 시간 동안 부여되는 여분의 인벤토리인데 이 인벤토리는 항상 인벤토리가 부족한 상황에서 수동적으로 획득한 아이템의 종류 수만큼만 확장됩니다. 임시 인벤토리는 정해진 시간 동안만 유지되고 이 시간 안에 인벤토리를 정리해 임시 인벤토리로부터 아이템을 인벤토리로 옮기고 나면 사라집니다. 사실 임시 인벤토리 개념은 아이템을 그냥 바닥에 떨어뜨리는 것과 별로 다르지 않습니다. 하지만 아이템이 소유권 개념이 불분명한 상황에서 다른 사람이 바닥에 떨어뜨린 아이템을 집어 가는 문제를 해결할 수는 있습니다. 또한 빠른 속도로 이동 중일 때도 일단 아이템을 받을 수는 있기 때문에 일정 시간 안에 마을에 돌아가 인벤토리를 정리하거나 이동을 잠시 멈추고 바닥에 다른 아이템을 버린 다음 퀘스트 스크롤을 인벤토리로 옮겨 인벤토리가 가득 찬 상황에서 수동적으로 획득한 아이템을 획득할 수도 있습니다. 시간이 지남에 따라 이런 방법은 규칙을 복잡하게 만들고 또 다른 여러 가지 예외상황을 만들곤 했으며 근본적으로 여러 게임들이 성능 문제를 돌파하고 또 경제시스템을 통제할 목적으로 바닥에 아이템을 떨어뜨릴 수 없도록 규칙을 변경하면서 다른 게임에서는 더 이상 사용하지 않게 됩니다.
현대에는 같은 상황에 주로 우편 기능을 활용합니다. 인벤토리가 가득 한 상황에서 능동적인 플레이 혹은 수동적인 게임의 동작에 따라 아이템을 획득하려 한다면 그냥 이럴 때 사용할 템플릿 우편에 방금 인벤토리를 통한 획득에 실패한 아이템을 담아 우편으로 보내버리면 됩니다. 아이템이 인벤토리에 들어오지는 못했지만 우편에 도착해 있기 때문에 고객은 인벤토리가 가득 찬 상태에 신경 쓰지 않고 플레이를 계속하다가 적당한 시점에 인벤토리를 정리한 다음 우편 인터페이스를 열어 그 동안 우편으로 도착한 획득하지 못한 아이템을 획득할 수 있습니다. 우편 기능이 도입되면서 인벤토리가 가득 찬 상황에 대한 처리가 훨씬 간단해졌을 뿐 아니라 인벤토리가 가득 찬 상황의 플레이를 정의하기 위해 여러 가지 상황마다 적절한 동작을 고안하기 위해 머리를 싸맬 필요가 없어집니다. 물론 이 방법이 완벽하지는 않습니다. 인벤토리가 가득 찬 상태에서 획득하는 모든 아이템을 계속해서 우편으로 받을 수 있다면 인벤토리의 존재 자체, 그리고 인벤토리의 빈 공간을 관리해야 하는 목적이 크게 희석될 수 있을 뿐 아니라 기술적인 이유로 인벤토리에 크기 제한이 있는 것과 마찬가지로 우편 역시 기술적인 이유로 제한이 있을 수밖에 없습니다. 그래서 인벤토리가 가득 찬 상태에서 플레이 할 때 아이템을 획득하더라도 아이템 획득이 일어날 때마다 모든 아이템을 우편으로 보내주지는 않습니다. 가령 필드에서 자동사냥을 돌리는 게임이라면 인벤토리가 가득 찬 상태로 계속해서 일어나는 자동사냥에 의해 획득하는 아이템은 우편으로 보내지 않고 그냥 사라집니다. 이런 아이템들은 일반적으로 가치가 높지 않기 때문입니다. 만약 이 상황에 전역 드랍 규칙 같은 것이 동작해 가치 있는 아이템이 드랍되었지만 이를 인벤토리에 넣을 수 없다면 이런 경우에 한해 우편을 통해 아이템을 받을 수 있습니다.
우편 기능을 과거의 임시 인벤토리 기능과 비교해 보면 우편은 사실 임시 인벤토리가 체계적으로 확장된 모양이라는 사실을 알 수 있습니다. 과거의 임시 인벤토리 기능은 우편과 비슷하지만 우편을 단 한 번만 받을 수 있고 이 우편은 일정 시간이 지나면 사라지는 제약을 가지고 있는데 그 시간이 꽤 짧은 형태입니다. 반면 우편은 임시 인벤토리를 체계적으로 관리할 수 있고 시간 제한이 있지만 훨씬 관대할 뿐 아니라 우편 시스템이 기술적으로 가능한 범위 안에서는 아이템을 계속해서 받을 수 있기 때문에 당장의 플레이를 크게 방해하지도 않고 인벤토리를 정리하기 위해 마을에 돌아가는 행동을 통해 플레이에 적당한 리듬을 만들어낼 수 있었던 것처럼 우편을 정리하는 행동 역시 이와 유사한 리듬을 만들어낼 수 있는 행동이 되기도 합니다. 어떤 고객들은 현대 게임들은 뭘 하든 일단 우편으로 보냈다고 말할 뿐 인벤토리에 바로 들어오지 않는 동작에 불만을 가져 ‘요즘 게임은 우편 없으면 죽기라도 하냐?’ 같은 말씀을 하기도 하는데 사실 죽는 정도는 아니지만 우편을 통해 온갖 이상한 문제를 단순하게 만들고 있기 때문에 어느 정도는 죽기라도 하는 것 맞긴 합니다. 우편을 통해 이전까지 우리들을 지독하게 괴롭혀 온 인벤토리가 가득 찬 상태에서 맞이하는 온갖 동작의 예외 상황을 부드럽게 해결할 수 있게 된 것 단 하나만으로도 우편은 인벤토리가 있고 인벤토리 크기에 제한이 있는 게임에 커다란 혁신이라고 볼 수 있습니다. 요즘에도 게임에 따라 클리어에 성공하면 큰 보상을 받을 수 있는 던전에 진입하기 전에 인벤토리에 일정 수준 이상의 공간이 남아 있지 않으면 던전에 진입 자체를 금지하는 게임이 있기도 한데 이 역시 고객이 나중에서야 아이템을 획득할 수 없거나 획득하지 못했다는 사실을 깨달아 깊은 실망감을 느끼도록 하지 않기 위한 장치이기는 하지만 같은 게임에 우편 기능이 공존하고 있다면 어쩌면 우편 기능의 필요성을 깊이 고민하지 않은 증거로 볼 수도 있습니다.
다음으로 우편 기능은 마이크로트랜잭션에 기반한 유료 상점을 운영하며 각 국가의 법령을 준수하기 위해 필요한 장치이기도 합니다. 현대에 여러 게임은 이미 오래전부터 무료로 플레이를 시작해 인게임에서 마이크로트랜잭션을 통해 과금하는 모델을 사용해 왔습니다. 물론 현대에도 풀 프라이스를 지불하고 시작해야 하는 게임이 있지만 이들을 시작하기 위해서는 풀 프라이스를 당장 지출해야만하는 장벽에 있는데 비해 무료 게임으로 시작하면 일단 아무것도 지출하지 않고서도 게임을 시작할 수 있기에 적어도 경제적인 관점에서는 아무런 진입 장벽이 없는 것과 마찬가지입니다. 만약 스팀에서 게임을 구입한 다음 게임이 마음에 들지 않거나 생각과 다르다면 환불할 수 있지만 만약 이미 두 시간 이상 플레이 했다면 정책에 따라 환불할 수 없습니다. 반면 무료 게임은 일단 게임을 시작한 다음 같은 상황에 처하더라도 환불하고 자시고 할 필요가 아예 없습니다. 그냥 게임을 종료하고 언인스톨 하고 나면 모든 것이 끝나기 때문입니다. 그래서 여러 게임들이 일단 무료로 게임을 시작하게 만든 다음 게임 상에서 맞닥뜨리는 다양한 요구사항을 해결하는 방법으로 유료 상점으로부터 구매를 유도해 선택적으로 지불할 수 있도록 하고 있습니다. 게임을 처음 시작할 때 풀 프라이스를 요구하지 않아 일단 시작해볼 수 있고 게임이 예상과 다를 때 환불 실패에 대한 위험성이 전혀 없으며 선택적으로 소액을 지불하는 방식으로 동작하기에 선택에 따라 지불하지 않거나 최소한의 비용만 지불하고 플레이를 이어 갈 수 있어 풀 프라이스 게임에 비해 상업적으로 장점이 많습니다.
하지만 인게임에 이런 유료 상점을 운영하며 법률을 준수하기 위해서는 우편이 반드시 필요합니다. 인게임에 유료 상점을 도입한 초기 게임들은 청약철회에 대해 숙고하지 않았기에 상점에서 구입한 아이템을 바로 인벤토리에 넣어 주곤 했습니다. 다행스럽게도 모든 상품이 아이템 모양이라면 나중에 청약철회가 일어나더라도 인벤토리로부터 아이템을 제거하고 구입 금액을 환불하기가 그렇게까지 까다롭지 않을 수 있습니다. 하지만 게임 규칙이 복잡해지며 한 가지 상품에 따라 획득한 결과가 아이템 모양이 아닌 경우가 나타납니다. 가령 상품이 아이템 뿐 아니라 구입 시점부터 시작되는 효과라면 청약철회가 일어날 때 이 효과를 어떻게 게임으로부터 제거해야 할 지는 굉장히 어려운 문제입니다. 또한 상품이 아이템 모양이라 하더라도 이를 사용해 지속적인 효과를 얻는 형태로 동작할 경우 어디까지를 이 상품의 사용 범위로 봐야 할 지 역시 굉장히 모호합니다. 가령 어떤 물약은 사용 순간부터 일정 시간에 걸쳐 파티원 모두의 보상을 일정 비율만큼 올려 주는 역할을 할 때 이 아이템이 포함된 유료 상품을 구입한 다음 이 물약을 사용하고 던전을 돌아 파티원 모두가 평소보다 높은 보상을 획득했습니다. 그 다음 청약철회가 일어날 경우 인벤토리에 남아 있는 상품을 제거하고 또 적용 중인 효과 역시 중단할 수 있지만 상품의 일부를 사용해 얻은 부가적인 이익을 정확히 판단해 게임으로부터 제거하기는 거의 불가능합니다. 이런 복잡성 때문에 과거에는 종종 게임에 소위 ‘백섭’이 일어날 수 있었지만 현대에는 백업이 불가능해졌기도 합니다.
만약 우편이 있다면 청약 철회 단계를 복잡한 판단 없이 깔끔하게 정의할 수 있습니다. 일단 유료 상품을 구입하면 상품을 인벤토리에 직접 넣거나 즉시 효과를 적용 시키는 대신 일단 상품을 우편 모양으로 고객에게 전달합니다. 인벤토리와 달리 우편은 이를 통해 아이템을 보유하고 있더라고 그 효과가 동작하지도 않고 우편으로부터 아이템을 직접 사용할 수도 없습니다. 모든 아이템과 효과는 우편 시스템을 벗어나 인벤토리 혹은 인게임 시스템에 적용될 때부터 동작하기 시작하며 그 전까지는 그저 받은편지함에 보관 되어 있을 뿐입니다. 고객은 이 상태에서 환불을 요청할 수 있습니다. 아직 어떤 아이템도 사용되지 않았고 어떤 효과도 적용되지 않았기에 환불은 고객 입장에서, 그리고 회사 입장에서도 아주 깔끔하고 빠르게 이루어질 수 있습니다. 그저 우편을 제거하고 지불한 금액을 환불하기만 하면 됩니다. 하지만 우편으로부터 아이템을 획득해 인벤토리 및 인게임 시스템으로 효과를 이전하는 행동은 청약 철회가 가능한 경계를 넘는 구매 확정 행동으로 정의해 이 때 청약 철회 조건을 안내하고 이에 동의하게 만들 수 있습니다. 만약 아직 환불할 가능성이 있다면 우편을 열어 인벤토리와 인게임 시스템으로 아이템과 효과를 옮기는 대신 우편 시스템에 이를 묶어 두고 좀 더 생각해볼 수 있습니다. 하지만 우편으로부터 상품을 받아 인벤토리 및 인게임 시스템으로 아이템과 효과가 이전되면 이는 일종의 구매 확정으로 평가해 이 시점부터는 청약 철회를 할 수 없도록 하고 있습니다. 만약 우편을 통해 이런 경계를 정확히 정의할 수 없었다면 고객에게 다양한 형태의 서비스를 제공할 여지가 크게 줄어들었을 것입니다.
마지막으로 우편 시스템은 운영 편의를 위해 사용되기도 합니다. 현대에는 지표를 유지하기 위해 주로 이벤트를 사용하고 있습니다. 가령 고객이 감소하는 것 같으면 복귀 고객 이벤트를 통해 이탈 고객을 복귀 시키거나 플레이 시간이 감소한다면 플레이 시간을 유지할 동인이 될만한 보상을 집행하는 이벤트를 하기도 합니다. 또한 고객들도 이전과 달리 게임이 그저 동작하고 있으면 분명 게임에 여러 사람들이 활발하게 플레이 하고 있음에도 게임 서비스가 중단되었거나 게임이 죽어간다고 느끼기도 합니다. 그래서 라이브 도중에는 여러 가지 목적으로 이벤트를 일으키는데 어떤 모양의 이벤트든 결국 결과는 보상으로 끝나기 때문에 보상을 우편 모양으로 지급하는 것은 어쩌면 당연한 결정입니다. 그런데 지금까지 설명한 여러 목적을 위해 우편 시스템을 적극적으로 사용하다 보면 자연스럽게 우편에는 수많은 우편이 쌓여 있게 되고 고객 입장에서는 쌓여 있는 우편을 정리하는 일 자체가 부담이 될 지경이 이르렀습니다. 인벤토리가 가득 찬 상태에서 던전을 돌아 획득한 핵심 보상도 우편에 들어 있고 유료 상점에서 구입했지만 아직 구매 확정 하지 않은 상품도 우편에 들어있으며 온갖 이벤트 참여 보상도 우편에 들어 있습니다. 이들을 하나 하나 확인하고 보상을 획득하는 것은 분명 고객에게 이익이 되는 행동이지만 고객이 수많은 우편 목록 앞에 질리게 만들 수도 있습니다. 그래서 누군가 처음으로 ‘모두받기’ 기능을 넣기 시작했고 이제 아주 흔하게 사용됩니다. 우편이 아무리 많이 쌓여 있더라도 모두받기 버튼 한 방이면 모든 보상을 획득하고 우편을 한 방에 정리할 수 있기 때문입니다.
하지만 이런 편리함의 이면에는 운영 이슈가 도사리고 있는데 고객에 따라 특정 이벤트 보상을 모두받기를 통해 획득했지만 그 이벤트 보상을 획득하지 않은 것 같다고 느낄 수 있습니다. 실제로 어떤 이벤트는 참여자에 따른 보상을 이미 개발된 게임 시스템에 의해 자동으로 부여하는 대신 이벤트가 종료된 다음 데이터베이스를 조회해 이벤트 참여자들을 확인하고 이들 각각에게 보상을 지급하는 쿼리를 작성해 점검 시간에 지급하기도 합니다. 어지간하면 이벤트 시스템을 구축해 수동으로 참여자를 선정하고 수동으로 이들에게 보상을 지급하는 상황을 만들지 않으려고 노력하지만 사업적 이유에 따라 이런 상황 모두를 미리 예측하고 시스템을 개발해 놓기는 정말 쉽지 않습니다. 가령 인게임이 아닌 장소에서 일어나는 이벤트가 있을 수 있습니다. 가령 게임을 부스팅 하기 위해 인스타그램에 해시태그를 달아 달라는 이벤트를 수행했다면 이는 게임 시스템이 이를 예측한 기능을 미리 개발할 수 없습니다. 이벤트를 수행하면 직접 사람이 해시태그를 검색해 이벤트에 참여한 고객을 확인하고 이들의 계정 이름을 운영 부서에 전달하면 이들이 직접 이벤트에 참여한 고객들에게 보상을 부여하는 쿼리를 작성해 테스트 해 놓은 다음 점검 시간을 노려 쿼리를 실행해 보상을 지급하곤 합니다. 이 과정에 실수가 일어날 여지가 너무나 많기 때문에 분명 이벤트에 참여하고도 보상을 받지 못한 고객들이 있을 수 있으며 이들은 주로 커스터머 서비스에 확인을 요청해 상황을 바로잡습니다. 그런데 우편의 모두받기 기능을 통해 보상을 획득했지만 이를 인지하지 못하는 일도 자주 발생합니다. 만약 이런 상황 하나하나마다 고객들이 보상을 획득하지 못했다는 커스터머 서비스를 요청하면 운영 부서에 아무리 많은 사람을 채용하더라도 서비스를 이어갈 수 없을 겁니다.
이런 상황을 완화하기 위해 한때 아이템을 획득하면 성능 문제를 완화하기 위해 즉시 우편을 삭제하던 게임들이 일단 아이템을 획득한 다음에는 우편을 일종의 ‘보관함’으로 옮겨 일정 시간 동안 유지한 다음 삭제하도록 바뀌고 있습니다. 보관함에 있는 메일은 내용을 확인하는 것 외에는 어떤 상호작용을 할 수 있지는 않지만 이런 내용의 우편이 도착했었고 언제 보상을 획득했는지 기록을 표시하기 때문에 고객이 이벤트 보상을 받지 못했다고 생각할 때 일단 보관함을 열어 보고 정말 우편을 찾을 수 없는지 확인한 다음 커스터머 서비스를 이용하도록 할 수 있습니다. 이런 상황은 대체로 모두받기 기능을 통해 보상을 획득했지만 이를 인지하지 못한 경우여서 보관함 기능을 통해 보상이 도착했는지 여부, 그리고 획득 시점을 확인하고 인벤토리를 살펴보며 보상 아이템을 확인하는 과정을 통해 대체로 해결할 수 있습니다. 만약 우편 시스템을 설계할 때 프로젝트 스스로의 요구사항에만 기반해 설계한다면 이런 여러 가지 우편함의 발전 방향과 새로운 요구사항을 알지 못한 채 설계하게 됩니다. 그렇더라도 우편은 멀쩡히 만들어져 동작하겠지만 결국 어느 시점에는 시장의 다른 플레이어들을 보고 이들이 이미 적용한 기능을 가져올 수밖에 없고 이는 미래에 우편 기능을 다시 한 번 만들어야 한다는 의미이기도 합니다. 그래서 각 기능을 설계할 때 우리 프로젝트의 요구사항에 기반해 완전히 바닥부터 개발할 수도 있지만 다른 여러 게임의 비슷한 기능을 살펴보고 이들로부터 힌트를 얻을 뿐 아니라 이들의 변화를 참고하는 것도 중요합니다.
실은 마치 이 글의 핵심이 우편인 것처럼 지금까지 이야기 해 왔지만 하고 싶은 이야기는 사실 우편이 아닙니다. 한번은 인게임에서 플레이어와 물체가 상호작용 하는 방법을 정의해야 했습니다. 지금까지 설명한 업무 방식에 따르면 비슷한 장르 게임들을 살펴보고 다른 게임에서 플레이어가 여러 가지 물체와 상호작용 하는 방법을 살펴본 다음 이들로부터 방법을 구축해 규칙을 설계하면 됩니다. 게임에 따라 게임 속 물체와 상호작용 할 때 꽤 그럴싸한 플레이어 애니메이션을 함께 재생하기도 합니다. 가령 던전에 어떤 기계를 작동시키는 레버가 있을 때 레버와 상호작용 하면 플레이어는 묵직한 레버를 힘껏 잡아당기는 애니메이션을 재생하며 레버와 상호작용 합니다. 과거 MMO 게임에서는 이런 물체와 상호작용을 훨씬 단순한 모양으로 만들곤 했는데 가장 큰 이유는 게임 상에 캐릭터가 굉장히 다양하고 이 다양한 캐릭터에 따라 물체와 상호작용 할 때 필요한 아트 에셋을 제각각 만들어야만 했기 때문입니다. 가령 키가 작은 드워프 캐릭터와 키가 큰 엘프 캐릭터가 공존하는 게임에 던전에서 잡아당겨야만 하는 레버가 등장한다면 각 캐릭터의 특징, 물리적인 형태 등에 따라 어울리는 애니메이션을 제작해야만 합니다. 만약 우리들이 만드는 게임이 언처티드 시리즈처럼 주인공 캐릭터 한 명 만이 상호작용을 수행하는 게임이라면 거의 모든 상호작용마다 서로 다른 완벽히 어울리는 애니메이션 에셋을 만들 결정을 할 수 있겠지만 그런 캐릭터가 수 십 종류라면 같은 결정을 하기는 어렵습니다. 그래서 주로 MMO 장르 게임들은 상대적으로 어설픈 애니메이션 에셋 만으로 여러 상황을 처리하곤 했습니다. 하지만 현대에는 실시간 애니메이션 기술이 발전했고 또 같은 상황에 사용하는 눈속임 기법들도 정교해져 이전만큼 대충 처리하지 않을 수 있습니다.
한편 이런 상호작용은 이를 시작하는 조작 방식에 따라 큰 차이가 있습니다. 가령 게임에 따라 상호작용 대상을 마우스커서나 게임패드로 가리키기만 해도 바로 상호작용이 일어나 그 결과를 확인할 수도 있고 또 다른 게임들은 상호작용을 할 대상에 가까이 간 다음 별도로 구분된 상호작용 조작을 해야만 상호작용을 하기도 합니다. 게임에 따라 서로 다른 방식을 선택해 일관적으로 유지하기도 하고 게임에 따라서는 같은 게임에 등장하는 서로 다른 상황마다 각기 다른 상호작용 방법을 사용하기도 합니다. 가령 전투 동작을 중요하게 여기는 게임에서는 전투 조작과 상호작용 조작을 서로 멀리 떨어뜨려 놓고 이들을 실수로 입력하지 않도록 배려합니다. 만약 한창 적들과 목숨을 건 아슬아슬한 전투를 하고 있는데 그저 가리키기만 해도 상호작용을 하는 물체가 가까이 있어 상대방의 공격을 회피하려다가 실수로 바닥에 놓인 약초를 채집한다면 게임 속 캐릭터가 죽기 전에 이를 조작하는 고객이 고혈압으로 사망할 수도 있습니다. 그래서 전투가 얼마나 인텐시브한지, 그리고 조작에 실패할 때 패널티가 어느 정도인지에 따라 전투 조작과 상호작용 조작을 떨어뜨려 놓거나 그렇지 않거나를 결정하곤 합니다. 같은 게임 안에서 전투 조작과 상호작용 조작이 서로 분리된 형태와 그렇지 않은 형태를 모두 사용하기도 하는데 이는 주로 전투 행동이 그만큼 인텐시브 하지 않아 조작 실패에 따른 패널티가 적은 경우 간단한 상호작용은 모두 별도의 상호작용 조작 없이 그저 상호작용 할 대상을 가리키기만 해도 상호작용이 일어나도록 합니다. 하지만 같은 게임이라도 상호작용에 의해 게임에 큰 변화가 일어나는 경우에는 일관성을 깨고 상호작용에 별도로 분리된 조작을 요구하기도 합니다. 가령 특정 게임 모드에 진입하거나 다른 레벨로 이동하거나 되돌릴 수 없는 보상 조작을 실행하는 등의 결과가 일어나는 상호작용은 실수로 이를 조작하지 않도록 같은 게임이라도 별도의 상호작용 조작을 사용합니다.
그런데 이런 기반을 잘 모른 상태로 우편에서 그랬던 것처럼 그저 다른 게임의 동작을 살펴보고 이들을 복제하려고만 하면 일단 기능을 설계하고 개발을 진행 시킬 수는 있겠지만 근본적으로 우리가 복제한 대상들이 그렇게 만든 이유를 모르기에 우리들은 기능을 흉내낼 뿐 이 개발의 결과가 우리들의 요구사항을 만족하는지, 우리들의 문제를 해결하는지 여부를 평가할 수가 없습니다. 우리가 만드는 게임의 전투가 꽤 인텐시브하고 실수에 의한 패널티가 작지 않다면 다른 게임이 어떻게 하든지 간에 상호작용 조작은 전투 조작과 분리되어 있어야 하고 조작 도구가 키보드와 마우스이든 게임패드이든 각 조작은 서로 최대한 멀리 떨어져 있어야 합니다. 반면 이와 반대 상황이라면 각 조작을 서로 멀리 떨어뜨려 놓는 것은 불편을 유발하기만 할 뿐 이익이 없을 수 있습니다. 이럴 때는 전투 대상을 가리키는 조작과 상호작용 대상을 가리키는 조작을 동일하게 만들어도 별 상관 없습니다. 물론 그러면서도 같은 게임에서 중요한 던전에 진입하거나 중요한 대사를 말해야 하는 NPC에게 말을 걸어야 하는 등의 상황에는 별도의 상호작용 조작을 요구할 수 있습니다. 이렇게 우리들의 상황을 이해하고 또 시장의 다른 플레이어들이 각 장면을 왜 이런 모양으로 만들었는지 이해하지 못한 채 그저 다른 게임을 살펴보기만 하면 스스로 설명할 수 없는 동작을 설계한 문서를 만들게 됩니다. 이를 통해 개발할 수는 있겠지만 협업 부서들로부터 질문을 받을 때 올바르게 답할 수 없어 신뢰를 구축하기 어렵고 또 예외 상황이 발생할 때 올바른 의사결정을 하기도 어렵습니다. 특히 기능이 완성된 다음에는 이 기능이 우리 게임의 툭수성에 기반한 요구사항을 만족하는지 여부를 평가할 수 없어 만들기는 했으나 얻은 것은 없는 힘 빠지는 상황에 빠질 수 있습니다.
지금까지 우편과 상호작용 사례를 살펴보며 서로 약간 어긋나는 이야기를 했습니다. 우편에서는 우리 스스로의 요구사항에 기반해 설계하고 개발할 수 있으나 비슷한 기능이 시장에 다른 플레이어들이 개발한 여러 제품에 걸쳐 존재하기 때문에 이들을 살펴보면 다른 플레이어들이 어떤 생각을 하고 또 어떤 문제를 겪고 있는지, 그리고 장기적으로 어떤 모습으로 변화해 가고 있는지 파악할 수 있기 때문에 다른 게임을 살펴봐야 한다고 이야기했습니다. 상호작용 사례에서는 우리들이 다른 게임의 사례를 살펴보더라도 서로 다른 게임의 서로 다른 동작이 왜 그런 모양으로 만들어졌는지 정확한 이유를 설명하지 못하거나 우리가 해결하고자 하는 문제, 우리들의 요구사항이 명확하지 않은 상태에서는 다른 게임을 살펴보고 그에 기반해 요구사항을 작성해 개발할 수는 있겠지만 결국 그 결과가 우리들의 요구사항을 만족하는지, 우리들이 해결하고자 했던 문제를 실제로 해결했는지 평가할 수 없게 됩니다. 서로 다른 이야기를 했지만 이들의 공통 맥락은 어떤 기능을 설계할 때 우리 요구사항에 맞춰 바닥부터 설계하는 것 보다는 시장에 있는 다른 플레이어들의 결과를 살펴보는 것이 좋지만 만약 우리들의 요구사항이 불확실하거나 시장에 있는 다른 플레이어들의 결과를 보고도 그들이 왜 그런 결정을 했는지 이해할 수 없다면 다른 게임을 살펴보는 것이 좋기만 하지는 않다는 것입니다.
이번 71호에도 지난 2주간 공유한 이야기를 함께 보내 드립니다.
Woojin Kim
Woojin Kim
Woojin Kim
Woojin Kim
일주일 전 제가 일하는 조직의 다른 부서의 누군가가 제 블로그의 어떤 글을 보고 불편한 감정을 느끼셨다는 말씀을 하셨다는 이야기를 전해 들었습니다. 저는 익명으로 글을 쓰고 있지는 않기에 노출되어 있고 불편함을 느끼셨을 분의 자초지종을 알 도리가 없으니 어떤 글로부터 불편함을 느끼셨을지 제가 알 방법은 없습니다. 다만 '조직에 대한 부정적 평가', '특정 인물에 대한 저격' 같은 말이 함께 나온 것으로 미루어 어림 짐작 할 수 있을 뿐입니다.
Woojin Kim
너무나 당연하게도 저는 '조직에 대한 부정적 평가', '특정 인물에 대한 저격' 같은 행동들을 생각한 적 없고 또 그럴 의사도 그럴 용기도 없습니다. 하지만 제 의도와 무관하게 제 행위로 인해 누군가 불편한 감정을 느끼신 것은 사실입니다. 그래서 이 사실을 알게 된 지난 2024년 1월 14일에 사과문을 게시했습니다. 저는 노출되어 있고 불편함을 느끼셨을 분은 그렇지 않기에 고작 이렇게밖에 할 수 없다는 점은 부디 너른 양해를 부탁 드립니다.
다만 저는 앞서 두 번 언급한 단어들, 하지만 굳이 또 언급하고 싶지는 않은 그런 단어로 표현될 수 있는 행동에 전혀 관심이 없습니다. 만약 제가 그럴 생각이었다면 제 이름을 걸고 글을 쓰는 블로그에 그런 짓을 하지는 않을 것 같습니다. 현대에는 제 신원을 숨기고 유사한 행동을 안전하게 할 수 있는 매체가 많으니까요. 2주 전 악의 평범성 끄트머리에 말씀 드린 대로 제가 이 블로그에 하는 이야기는 모두 시공간 상 현재 일어나는 이야기가 아닙니다. 모든 이야기는 현재의 경험으로부터 생각을 시작하지만 글은 시공간 상 현재가 아닌 과거 시점의 이야기를 언급하고 있어 굳이 말하자면 현실의 이야기가 아닙니다. 때문에 제가 현재 속한 조직에 대한 이야기를 하고 있다는 평가에 동의하지 않습니다. 만약 제 이야기가 현실의 어떤 사례와 유사해 보인다면 우리들이 과거의 실수를 현재에도 반복하고 있는 지극히 당연한 세계에 살고 있다는 것을 의미합니다.
이번 피드백을 통해 제 이야기들이 어떻게 읽힐 수 있는지 조금 더 생각해볼 계기가 되었습니다. 지난 한 주 내내 이 주제에 대해 생각해 보았습니다. 그런데 아마도 딱히 뭔가 달라지지는 않을 것 같습니다. 저는 제가 그리 똑똑하지 않다는 사실을 깊이 이해하지만 제가 속한 현실의 조직에 대한 이야기를 해 회사와 맺은 계약을 위반하거나 안전하지 않은 방법으로 누군가를 저격할만큼 아둔하지는 않기 때문입니다. 만약 제가 그 정도로 아둔하다면 회사가 저를 고용하지 않았을 겁니다. 모든 이야기는 시공간 상 현재 일어나는 이야기가 아니며 이런 이야기들이 마치 현실의 누군가와 비슷하게 느껴지는 이유는 우연 또는 우리들이 제가 과거에 겪은 것과 비슷한 일을 반복해서 겪고 있기 때문입니다.
이런 생각을 하며 과연 저 자신은 여러 프로젝트를 경험하며 과연 앞으로 나아가고 있는지 돌아보게 됩니다. 과거에 일어난 생산적이지 않을 수 있는 어떤 사건이 개선되지 않고 현재에도 일어나고 있다면 이는 좀 더 관심을 가지고 들여다 봐야 할 문제가 발생하고 있다는 의미로 해석할 수 있기 때문입니다. 또 개인적으로 주창하는 '어차피 같은 실수를 반복할 거라면 뭐하러 경력자를 채용하는가'로 연결되곤 합니다.
이번 경험은 여러 가지 생각을 해볼 수 있는 계기가 되었습니다. 제 행위로 인해 불편한 감정을 느끼셨을 분께 다시 한 번 사과 드립니다. 다만 제 의도와는 큰 차이가 있기에 앞으로 뭔가 달라지지 않을 겁니다. 지금까지와 똑같이 시공간 상 현재와 멀리 떨어진 이야기를 글로 만들고 또 누군가를 저격하려는 등의 저급한 행동에 관심 없이 행동할 작정입니다.
이제 지난 한 주 내내 계속해 온 이 생각을 마무리하고 또 2주 뒤에 뵙겠습니다.
