그 규칙은 말이 됩니다. 그런데 고객에게 어떤 경험을 주나요?
어떤 규칙은 논리적으로 올바르고 잘 동작할 것이 확실합니다. 그런데 고객 관점에서 경험을 고려하지 않으면 논리적으로 분명 올바르지만 실패하는 규칙을 설계하게 됩니다.
마일스톤 계획을 수립하는 일은 만만하지 않습니다. 우리들은 근본적으로 복잡도가 높은 종류의 소프트웨어를 개발하는 일에 참여하고 있으며 종종 그 소프트웨어의 게임으로써 장르는 MMO로 시작하는 복잡계 시뮬레이션일 때도 있습니다. 과거에는 이 장르 게임들을 곧이곧대로 복잡계 시뮬레이션으로 받아들여 개발했다가 실제 세계에서 일어나는 문제가 게임 속에도 똑같이 발생해 큰 어려움을 겪기도 합니다. 가령 어떤 게임에서는 잘못 제작한 스킬의 부가효과가 사람들 사이에 넓게 퍼져 큰 문제를 일으켰는데 이 동작은 마치 실제 세계에서 사람들 사이에 바이러스가 퍼지는 현상과도 비슷해 주목을 받았습니다. 특히 이 사건을 둘러싸고 마치 흑사병이 창궐하던 시대와도 비슷하게 사람들은 문제를 해결하는 가짜 방법을 공유한다며 게임 내에서 사람들을 속여 이득을 취하거나 게임 상의 가상 종교에 의지하는 모습을 보이기도 해 여러 모로 흥미롭습니다. 하지만 이 상황을 수습해야 하는 개발사 입장에서는 이 모든 상황이 그리 달갑지 않았을 테고 이후에는 테스트 절차를 강화하고 또 부가효과가 여러 단계에 걸쳐 플레이어들 사이에 전파될 때 최대 전파 횟수를 제한함으로써 근본적으로 문제가 일어날 가능성을 없앱니다. 이런 사례는 MMO 장르를 근본적으로 복잡계 시뮬레이션으로 받아들여 시스템을 설계하는 일이 우리들의 예상보다 훨씬 어렵다는 사실을 말해줍니다.
한편 이런 문제 해결 방법과 비슷한 흔한 게임 속 사례에는 여러 게임에 같은 이름, 그리고 비슷한 메커닉으로 등장하는 마법 스킬인 체인라이트닝이 있습니다. 게임에 따라 조금씩 다르겠지만 여기서는 설명을 위해 다른 게임을 참고하지 않고 제 기억에 의존해 가상의 게임에 나오는 가상의 체인라이트닝 스킬을 정의해 보겠습니다. 체인라이트닝은 마법력을 사용해 시전자 주변의 사거리 안에 있는 적에게 강력한 전기를 발사해 여기에 맞은 대상에게 대미지를 입히는 스킬입니다. 그런데 이 스킬의 흥미로운 점은 대상에게 스킬이 명중하면 명중한 대상을 기준으로 사거리 안에 있는 다른 적에게 체인라이트닝을 다시 발사하는데 만일 사거리 안에 대상이 여럿 있었다면 한 번에 여러 대상에게 체인라이트닝을 발사해 대미지를 줍니다. 이후 체인라이트닝에 맞은 대상이 늘어나면 새로 체인라이트닝을 맞은 각 대상들이 다시 한 번 사거리 내에 체인라이트닝에 맞지 않은 대상을 찾아 이 대상들에게 체인라이트닝을 다시 한 번 발사하고 설정에 따라 이 과정을 여러 차례 반복합니다. 개발 과정에서 부주의하게 설정한 체인라이트닝 스킬은 플레이어가 처음 사용할 때는 주변의 대상 하나를 향해 발사했을 뿐이지만 피격된 대상의 사거리 안에 있는 다른 대상들에게 전파되기를 반복해 가까이에 있던 여러 대상에게 순차적으로 전파되어 필드에 깔린 몬스터 대부분을 짧은 시간 안에 죽여버리거나 순식간에 아주 많은 몬스터들에게 대미지를 줘 서버에 큰 부하를 일으키고 나아가서는 서버를 크래시 시킬 수도 있습니다.
그래서 이런 스킬을 개발할 때는 체인라이트닝이 주변 적들에게 확산될 최대 횟수를 정해 놓고 각 확산 회차에 한 번만 사용될 체인라이트닝 서브 스킬을 따로따로 제작한 다음 맨 마지막에 수행된 서브 스킬을 끝으로 그 다음 스킬을 호출하지 않도록 하는 식으로 실수 여지를 줄입니다. 로직을 데이터 모양으로 표현한 간단한 스킬 시스템에 설명한 방법에 따라 스킬을 입력한다고 할 때 첫 번째 대상을 피격한 다음 이 대상으로부터 최대 세 차례에 걸쳐 확산되는 체인라이트닝 스킬을 개발한다면 플레이어가 첫 대상을 향해 발사하는 체인라이트닝 스킬, 그리고 이어지는 세 차례에 걸쳐 확산될 때 각각의 확산 때 한 번만 사용될 체인라이트닝 스킬 중 두 개를 만들고 이들이 차례로 다음 스킬을 호출하도록 설정한 다음 마지막으로 사용될 체인라이트닝 스킬을 만들고 이 스킬은 자신이 종료되면 더 이상 아무 것도 호출하지 않도록 합니다. 하지만 누군가는 분명 사거리에 너무 큰 값을 입력해 단 세 번에 걸친 확산에도 불구하고 아주 넓은 영역에 걸친 대상에게 순식간에 전파되는 결과를 만들어 서버 엔지니어들이 깜짝 놀라게 만들 수도 있으므로 엔지니어들이 주로 재귀 모양으로 만들어야 할 것 같은 스킬이 나타나더라도 이를 입력할 때 재귀 모양으로 입력하기를 허용하지 않으며 스킬이 처음 실행되고 나서 그 다음 스킬을 호출하는 최대 횟수를 제한하고 또 서버의 동기화 영역 밖으로는 사거리를 확장하지 않는 방법을 통해 근본적으로 문제가 일어나지 않도록 하기도 합니다. 스킬 입력 시스템이 근본적으로 재귀를 허용하지 않기 때문에 위에서 체인라이트닝스킬을 만들 때 각 확산 회차 별로 다른 대미지를 가진 스킬을 각각 만든 다음 이들 각각이 수행된 후 호출될 다음 스킬을 연결하는 방식으로 만드는 것입니다.
한편 MMO 게임은 현대에 가까워질수록 과거의 복잡계 문제로부터 조금씩 벗어나 게임을 구성한 여러 서브시스템을 나머지 세계와 기본적으로 격리하고 이들 사이에 아주 제한적인 상호작용만을 허용하는 방식으로 보통 미만의 지능을 가진 우리들도 설계하고 통제할 수 있는 수준으로 복잡도를 제어하고 있습니다. 이전 왜 현대 게임에 그렇게 많은 종류의 재화를 사용하나요?에서 이 방식을 설명했는데 고객 관점에서 게임을 구성한 여러 시스템들은 모두 같은 세계에 연동된 것처럼 보이지만 실은 이들 중 상당수는 서로 다른 재화를 사용하고 각 재화가 서로 제한적인 방법으로만 교환되도록 강력하게 통제함으로써 같은 세계에 연동된 것처럼 보이는 각 시스템이 실제로는 전혀 상호작용 하지 않도록 만듭니다. 덕분에 이전에는 게임의 어느 메커닉이 오동작해 골드가 복사되면 순식간에 게임 전체로 퍼져 시스템을 심각하게 망가뜨려 소위 ‘백섭’을 감행할 수밖에 없도록 만들었는데 이는 고객들을 크게 실망시켰지만 최소한 문제를 해결할 수는 있었습니다. 이 역시 현대에 가까워질수록 게임은 사실상 백섭이 불가능해져 게임 일부의 오동작이 게임 전체로 확산되어 게임 속 복잡계를 비가역적으로 파괴해 너무 이른 서비스 종료의 길을 걷게 만든 사례도 알려진 것만 여러 차례 일어났습니다. 게임을 구성한 각 서브시스템이 경제적으로 서로 격리되어 있으면 이런 테크닉을 처음 본 북미권 고객들을 화들짝 놀라게 만들어 소위 ‘독성 경제 시스템’이라며 카메라와 마이크 앞에서 노발대발하게 만들지만 게임을 만드는 사람 입장에서는 어느 서브시스템이 오동작을 일으키더라도 이 오동작이 격리된 경제시스템에 의해 게임의 나머지 부분으로 확산되지 않아 백섭이 불가능한 상황에도 불구하고 현대의 ‘상대적으로 단순한’ 복잡계가 비가역적으로 파괴되지 않도록 해 줍니다.
이런 복잡계를 설계하고 개발하기 위한 마일스톤 계획은 크게 두 가지 차원에서 이를 수립하기 아주 어렵게 만듭니다. 먼저 순수하게 복잡도가 높은 소프트웨어 관점에서 게임을 구성하는 여러 서브시스템이 서로의 기능에 대해 의존성을 가지며 이 의존 관계가 개발 초반에는 온전히 드러나지 않기 때문에 개발 계획을 수립하기 어렵게 만듭니다. 한 기능이 다른 기능에 의존하는 사례는 너무나 흔한데 이런 의존성을 고려해 다른 기능으로부터 많은 의존성을 가진 부분을 먼저 개발하고 이 기능에 의존하는 기능을 나중에 개발하는 식으로 계획을 수립하면 가장 이상적이지만 시간의 흐름에 따라 요구사항이 크게 바뀔 수 있는 게임 소프트웨어의 특성 상 기능의 의존성에 따른 개발 순서 조정은커녕 각 기능의 필요 여부조차 확언하기 어려운 상황에 쉽게 빠질 수 있습니다. 그래서 의존성을 고려해 순서를 결정하는 공학적으로 아름다운 접근 대신 각 마일스톤이 끝날 때 우리가 실행해볼 수 있는 빌드의 동작을 대략 정의한 다음 이 동작에 필요한 기능을 개발하되 기능 사이에 의존성이 필요하지만 이번 빌드의 동작에 직접적으로 필요하지는 않은 동작이 있다면 이 동작에 의존하는 대신 이 부분을 임시 구현으로 마치 동작이 존재하는 것처럼 개발해 의존성이 없는 것처럼 행동하는 개발 계획을 수립합니다.
두 번째 문제는 이미 첫 번째 문제를 설명하면서 살짝 이야기가 나왔는데 게임 소프트웨어는 다른 분야의 소프트웨어와 달리 근본적으로 요구사항이 잘 정의된 채 개발을 시작하지 않을 뿐 아니라 요구사항이 정의되더라도 시간의 흐름에 따라 요구사항이 크게 변경될 수 있는 특징을 가지고 있다는 점입니다. 다른 여러 업계에서 소프트웨어는 요구사항이 설정된 다음 개발을 시작하곤 하는데 이는 개발 기간 동안에 걸쳐 요구사항이 크게 변경되지 않을 거라고 가정할 수 있기 때문입니다. 가령 어느 은행의 차세대 전산 시스템은 그 복잡도에도 불구하고 설계 단계에 이미 전체 시스템의 요구사항을 온전히 정의하고 각 서브시스템의 의존성을 미리 파악할 수 있습니다. 때문에 중간에 요구사항이 변경되지 않는다는 가정 하에 마일스톤 계획을 상대적으로 쉽게 설정할 수 있을 것으로 예상합니다. 반면 게임 소프트웨어는 일단 그 복잡도가 현대에 가까워질수록 점점 더 높아질 뿐 아니라 여러 외부 및 내부 상황에 따라 요구사항이 변경될 수 있는데 이는 종종 그 시점까지 개발한 빌드 거의 대부분을 쓸모 없게 만들어 버리기도 합니다. 게임 소프트웨어는 다른 업계의 소프트웨어와 달리 최종 동작을 예측하기 어려워 요구사항이 느슨하게 정의된 상태에서 개발을 시작하는데 개발 진행에 따라 요구사항이 조금씩 상세하게 정의되는 과정을 거쳐 개발됩니다. 그런데 실제 동작하는 빌드에 기반해 요구사항을 크게 변경하는 의사결정을 할 여지가 크고 또 경쟁이 심한 시장 상황에 따라 요구사항을 변경해야 할 수도 있습니다. 그래서 기본적으로 게임 소프트웨어는 다른 분야에 비해 요구사항의 변화에 유연하게 대응하는 코드를 작성하도록 요구 받습니다.
이런 이유로 특히 개발 초반에 마일스톤 계획을 수립하기는 더더욱 어렵습니다. 여러 기능들이 서로서로에 의존성을 가지지만 그런 기능 각각의 요구사항이 확실하지도 않은 아주 지옥 같은 상태에서 서브시스템 각각을 계획에 포함하려고 하면 각각의 비용과 앞서 설명한 이들 사이의 의존성을 무시하며 발생하는 오버헤드를 귀신같이 눈치 챈 엔지니어들을 손이 발이 되도록 싹싹 빌어 가며 설득해야 간신히 마일스톤을 시작할 수 있습니다. 그나마 몇몇 시스템들이 온전히 구축된 다음에 진행하는 마일스톤은 계획 단계에서 이런 어려움이 서서히 줄어들지만 초반에는 결코 그렇지 않을 뿐 아니라 의존성을 무시한 채 개발한 사실상의 임시 기능이 시간이 흐름에 따라 심지어 이를 개발한 사람들조차 이 기능이 임시 기능이라는 사실을 잊고 이 기능이 존재한다고 착각하는 바람에 비용 예측에 완전히 실패해 분명 여러 달 전에 이미 개발했다고 착각한 기능을 늦게서야 바닥부터 다시 개발하고 심지어 이 기능에 의존하던 여러 기능을 전부 다 고쳐야 하는 상황에 처하기도 합니다.
이런 사례 중 하나를 살펴보면 가령 인벤토리 최대 한도보다 더 많은 아이템을 받을 때 처리가 있습니다. 한때 게임에 따라 인벤토리 칸 수를 제한한 다음 이를 확장하는데 돈을 받기도 했는데 MMO 게임이 좀 더 이전 시대의 형태에 가까웠을 때는 이런 과금 정책이 그럭저럭 동작했던 것 같지만 현대에 가까워질수록 이런 제한은 잘 동작하지 않게 됩니다. 현대에는 인벤토리 칸 수에 대한 제한을 최대한 느슨하게 만들어 고객들이 인벤토리 크기에 따라 게임 사이클을 제어하게 만들지 않는데 가장 큰 이유는 과거 고객들은 시간 보다는 물리적인 인벤토리 크기 제한에 따라 게임 사이클을 형성했던데 비해 현대 고객들은 그들이 사용할 수 있는 실제 세계의 시간의 양에 따라 게임 사이클을 형성하기 때문에 이 사이클보다 더 짧은 사이클을 유도하는 인벤토리 크기 제한은 고객들을 게임으로부터 쫓아내는 결과를 가져옵니다. 가령 이전 시대에는 앞마당을 쓸든 던전을 돌든 어쨌든 인벤토리가 가득 차면 마을에 돌아와 이를 정리하는데까지를 한 사이클로 정의하고 다들 시간에 덜 민감하게 플레이 하곤 했는데 현대에는 고객들의 가용한 실제 시간에 제한을 받기 때문에 설계 시점부터 고객들이 게임에 투입할 수 있는 시간 별로 세그먼트를 나눠 플레이를 설계합니다. 이런 상황에 인벤토리 제한이 빡빡하다면 세그먼트 별로 구분한 플레이 사이클의 동작을 중간에 방해하게 됩니다. 두 시간 플레이를 예상한 고객이 두 시간에 걸쳐 한참 던전을 돌며 아이템을 파밍하고 있을 때 아직 플레이가 끝나지 않았는데도 인벤토리가 가득 차 더 이상 아이템을 획득할 수 없는 상태를 경험한다면 이는 명백히 잘못된 설계입니다. 만약 기술적으로 인벤토리 칸 수 제한을 극도로 느슨하게 만들 수 없다면 던전 중간에 쓰레기를 처리해 주는 NPC 등을 투입해 인벤토리 제한이 문제를 일으키지 않도록 설계해야 합니다. 이런 사례는 균열 끝의 대장장이에 소개한 적 있습니다.
하지만 앞서 인벤토리 최대 한도보다 더 많은 아이템을 받을 때 처리에 잠깐 언급한 대로 인벤토리 칸 수 제한을 사실상 없애자는 요구사항은 이를 표현하는 ‘무한’이라는 말 때문에 엔지니어들의 전두엽에 강력한 전기 자극을 줘 우리들의 요구사항에 필요한 기술적 비용을 실제보다 1억배쯤 크게 평가하게 만들어 분명히 훨씬 느슨한 제한을 개발할 수 있는 기술적 배경에도 불구하고 이도 저도 아닌 1000칸 짜리 인벤토리를 만드는 수준으로 만족한다고 게임디자이너 스스로를 설득해야만 하게 만들기도 합니다. 이전에 경험한 어느 프로젝트의 관련 회의에서는 아주 거대한, 고객 입장에서는 사실상 제한이 없다고 느낄 만한 인벤토리가 필요하다고 말하자 인벤토리는 아무리 크게 만들어도 2,147,483,648칸을 넘길 수 없다는 말을 듣기도 했는데 이 말이 어떤 사고 과정 끝에 나왔는지 이해할 수 없지 않았지만 굉장히 부당하다는 느낌을 받는 것을 피할 수는 없었습니다. 현대에 어지간한 게임을 둘러보면 사실상 인벤토리에 제한을 두지 않는 경우가 많은데 이런 게임들이 과연 2의 32승의 절반에 해당하는 크기로 인벤토리 칸 수에 제한을 둔 채 개발되었을 것 같지는 않습니다. 인벤토리는 플레이에 따라 굉장히 자주 읽고 쓰는 데이터여서 이를 전통의 방법에 따라 아주 빠르게 처리해야만 하고 이에 따라 칸 수에 상당한 제한을 가하는 방법으로 그 동안 속도에 대한 요구사항을 달성해 왔던 것은 사실입니다. 하지만 시간이 흘러 이런 방식으로 우리가 설계한 플레이 사이클이 망가지지 않아야 함은 자명하기에 논의를 쉽게 과장하고 또 논의를 철학적인 문제로 만들어 의사결정 과정을 망가뜨리는 무한과는 아무런 관계도 없음을 설명할 수밖에 없습니다. 물론 이런 설득에도 불구하고 결국 제한이 없는 인벤토리 요구사항은 받아들여지지 않아 이도 저도 아닌 1000칸 짜리 인벤토리 구현을 받아들여야만 합니다.
그런데 그렇게 손과 발을 구분할 수 없을 정도로 싹싹 빌어 간신히 얻어낸 서버에 큰 부하를 줄 지도 모르는 무려 1천칸에 이르는 거대한 인벤토리 공간에도 불구하고 우리는 인벤토리 공간이 가진 근본적인 제약 때문에 그렇게 거대한 크기임에도 불구하고 이 공간이 가득 찰 때 일어나는 온갖 상황을 해결하기 위한 규칙을 정의하는데 시간을 사용해야 합니다. 인벤토리에 보관한 아이템 갯수가 인벤토리 칸 수 제한에 가까워질 때 한 번에 남은 칸 수보다 더 많은 아이템을 획득하려고 하면 어떻게 동작해야 할까요. 인벤토리가 완전히 가득 찬 상태에서 몬스터로부터 아이템을 획득하려는 상황에는 어떻게 동작해야 할까요. 인벤토리가 가득 찬 상태에서 상점으로부터 아이템을 구입하면 이를 어떻게 해야 할까요. 인벤토리가 가득 찬 상태에서 배틀패스에 기반한 일일 보상을 지급 받으려면 어떻게 해야 할까요. 인벤토리가 가득 찬 상태에서 퀘스트를 수행하는 도중 퀘스트 아이템을 받으려면 어떻게 해야 할까요. 인벤토리가 가득 찬 상태에서 던전 보상으로 키 아이템을 획득하려면 어떻게 해야 할까요. 인벤토리가 가득 찬 상태에서 장착했던 장비를 벗으면 인벤토리로 이동해야 하는데 그렇다면 장비를 교체할 수 없다는 이야기일까요? 인벤토리가 가득 찬 상태에서 인벤토리 인터페이스로부터 아이템 하나를 마우스 커서로 클릭해 집은 상태에서 어떤 이유로든 다른 아이템이 그 자리를 차지해버리면 마우스로 집은 아이템은 어떻게 되는 걸까요. 여느 게임들이 인벤토리의 칸 수 제한을 사실상 제거해 현대적인 플레이 사이클을 설계하고 이 플레이가 동작하는데 문제를 일으키지 않으며 앞으로 달려 나가는 사이에 우리들은 그렇게 힘들게 아주 큰 인벤토리를 확보했음에도 이런 모든 문제를 해결하기 위한 각각의 규칙 또는 통합된 규칙을 도출하기 위해 시간을 소모하지 않으면 안됩니다. 기존 인벤토리보다 훨씬 큰 1000칸 짜리 인벤토리를 확보하는데 큰 노력을 기울였지만 정작 이 결정은 게임디자이너들의 어떤 문제도 해결하지 못했습니다.
한편 인벤토리와는 별 관계 없어 보이기 쉬운 우편 기능은 주로 게임 개발의 후반 마일스톤에 개발하는 경우가 많은데 비슷한 시점에 개발하곤 하는 기능으로는 커뮤니티 관련 기능들, 로그인 연동, 튜토리얼 같은 것들이 있습니다. 이런 기능들은 게임이 어느 정도 기반을 갖춘 다음에야 그에 맞춰 요구사항을 정의할 수 있어 보통 후반에 개발하곤 하는데 우편은 이런 조건에 잘 맞지 않으면서도 후반에 개발하는 것이 별로 이상하지 않게 여겨지는 기능이라고 생각합니다. 과거에는 굳이 우편 같은 기능이 없어도 게임이 잘 돌아갔지만 현대에 가까워질수록 여러 이유로 우편 기능이 중요해졌는데 우편 기능의 핵심은 한국 기준으로 유료로 구입한 가상 재화의 환불 관련 법령을 준수하기 위함입니다. 만약 유료 상점에서 구매를 통해 획득한 아이템 각각을 인벤토리에 직접 집어넣는다면 일단 고객 관점에서 방금 구매한 상품이 인벤토리에 어떤 각각의 아이템으로 추가되었는지 인지하기 쉽지 않으며 만약 고객이 이후 플레이를 지속하다가 환불을 요청할 경우 게임으로부터 상품에 의한 아이템을 회수하고 또 아이템에 의한 효과, 효과에 의해 추가로 획득한 보상을 온전히 회수하기는 거의 불가능합니다. 마치 물에 물감을 떨어뜨린 다음 거의 그 즉시 행동한다면 물감 주변의 물을 한번에 떠내며 물감을 대부분 제거할 수 있겠지만 시간이 흘러 물감이 본격적으로 확산된 다음에는 그런 식으로 물감을 제거할 수 없는 것과 비슷합니다. 그래서 상점으로부터 구입한 상품은 일단 우편 모양으로 도착하고 고객이 이 우편을 개봉해 인벤토리로 옮기면 이 시점부터는 환불 의사가 없음을 선언한 것으로 하고 우편을 개봉하지 않은 상태에서는 자유롭게 환불할 수 있도록 하고 있습니다.
그런데 이렇게 아이템을 포함할 수 있는 우편 기능은 이 특징 때문에 앞서 언급한 인벤토리에 일어나는 온갖 문제들을 해결할 수 있는 사실상 만병통치약에 가까운 역할을 할 수 있습니다. 앞서 해봤던 수많은 질문을 다시 끄집어내 우편 시스템의 도움을 받아 해결해봅시다. 인벤토리에 보관한 아이템 갯수가 인벤토리 칸 수 제한에 가까워질 때 한 번에 남은 칸 수보다 더 많은 아이템을 획득하려고 하면 어떻게 동작해야 할까요? 획득하려고 하는 아이템 전체를 우편을 통해 보낸 다음 고객이 인벤토리를 비우고 나서 우편을 획득하게 만듭니다. 인벤토리가 완전히 가득 찬 상태에서 몬스터로부터 아이템을 획득하려는 상황에는 어떻게 동작해야 할까요? 우편을 통해 보냅니다. 몇몇 게임들은 심지어 던전에서 아이템을 줍지 않아도 던전을 클리어 하면 획득한 아이템을 우편을 통해 보내줍니다. 인벤토리가 가득 찬 상태에서 상점으로부터 아이템을 구입하면 이를 어떻게 해야 할까요? 상품을 우편 모양으로 보내주면 됩니다. 인벤토리가 가득 찬 상태에서 배틀패스에 기반한 일일 보상을 지급 받으려면 어떻게 해야 할까요? 배틀패스 아이템을 처음부터 우편으로 지급하면 됩니다. 인벤토리가 가득 찬 상태에서 퀘스트를 수행하는 도중 퀘스트 아이템을 받으려면 어떻게 해야 할까요? 퀘스트 아이템은 별도 인벤토리를 사용하거나 가상 아이템을 사용하는 편이 안전하지만 굳이 인벤토리에 넣어야 한다면 우편을 통해 보내주면 됩니다. 인벤토리에 존재하지 않으니 바로 이어서 퀘스트 진행이 불가능하겠지만 인벤토리를 비우고 우편을 획득하면 진행할 수 있습니다. 인벤토리가 가득 찬 상태에서 던전 보상으로 키 아이템을 획득하려면 어떻게 해야 할까요? 키 아이템을 우편으로 보내면 됩니다. 인벤토리가 가득 찬 상태에서 장착했던 장비를 벗으면 인벤토리로 이동해야 하는데 그렇다면 장비를 교체할 수 없다는 이야기일까요? 맞습니다. 이건 우편으로도 어쩔 수 없습니다. 인벤토리가 가득 찬 상태에서 인벤토리 인터페이스로부터 아이템 하나를 마우스 커서로 클릭해 집은 상태에서 어떤 이유로든 다른 아이템이 그 자리를 차지해버리면 마우스로 집은 아이템은 어떻게 되는 걸까요? 아이템은 그런 빈 칸을 차지하지 않고 처음부터 우편으로 받습니다.
그런데 익숙하게 우편을 개발 계획 뒤쪽으로 미뤄 놓고 인벤토리 기능을 개발하면 지금까지 설명한 이 모든 이상한 상황에서 인벤토리가 가득 찼거나 거의 가득 차 갈 때 일어나는 문제를 온갖 이상한 방법으로 해결해야만 합니다. 가령 어떤 게임은 던전에 입장하려고 할 때 인벤토리가 일정 분량 이상 비어 있기를 요구합니다. 이는 던전을 돌다가 키 아이템을 획득하지 못하는 불상사를 막기 위함이어서 고객을 위한 조치처럼 보이지만 조금만 생각해보면 고객을 이상한 상황에 빠뜨립니다. 가령 파티를 만들어 4인 던전에 입장하려는 순간 고객 3의 인벤토리가 가득 차 있어 모두가 던전에 진입할 수 없거나 이 고객을 제외한 나머지만 던전에 입장한 상황이 일어날 수 있습니다. 물론 고객 3이 마을에 돌아가 상점에 아이템을 팔고 인벤토리를 정리한 다음 돌아올 수도 있겠지만 앞에 언급했다시피 현대 게임 플레이 사이클은 그들의 가용 시간에 근거한다는 점을 기억합시다. 우리들 모두는 시간이 부족하고 고객 3이 인벤토리를 정리하고 돌아올 때까지 기다려 줄 수 있는 사람은 그리 많지 않다는 사실 역시 어렵지 않게 유추할 수 있습니다. 또한 굳이 현대가 아니더라도 여러 게임들이 한정된 시간 동안만 사용 가능한 컨텐츠를 통해 고객들을 끌어모으고 컨텐츠의 동작을 가속한다는 점 역시 고려해보면 고작 인벤토리 제한으로 인한 관리와 문제 해결을 위해 그들의 시간을 허투루 사용하게 해서는 안된다는 점을 알 수 있습니다.
근래 이런 상황을 해결하기 위해 제안 된 방법은 일명 ‘임시 인벤토리’라는 개념인데 인벤토리에 남은 공간이 거의 없는 상황에서 아이템 여러 개를 획득하며 인벤토리 최대 공간을 초과하면 임시 인벤토리라는 공간에 그 아이템을 모두 기록한 다음 고객이 인벤토리를 정리해 빈 칸을 만들면 임시 인벤토리에 있던 아이템이 빈 칸으로 하나씩 빠져나오는 것입니다. 이 규칙은 인벤토리에 그나마 빈 칸이 조금이라도 남아 있을 때 단 한 번만 동작하고 일단 인벤토리가 완전히 가득 찬 상태에서는 동작하지 않으며 어떤 경로로든 인벤토리에 아이템을 추가하려는 시도를 모두 거절합니다. 가령 상자를 열 수 없고 몬스터가 드랍한 아이템을 주을 수도 없습니다. 그러면 던전을 돌던 도중 인벤토리가 가득 차는 바람에 보스가 드랍하는 키 아이템을 획득하지 못할 수 있는데 이 경우 앞서 설명한 다른 게임 사례처럼 인벤토리에 일정 수량의 빈 칸이 남아있지 않으면 아예 던전에 입장 시키지 않는 방법으로 처리할 거라는 말을 들었습니다. 여기까지 이야기를 들은 다음 ‘그냥 우편을 당겨 개발하면 안돼요?’라고 물었고 제가 프로젝트에 참여하기 전에 뭔가의 이유로 우편을 통해 처리하지 말자는 논의 결과가 있었다는 것을 알게 됐지만 왜 그런 결정을 했는지는 아무도 기억하고 있지 않았습니다. 어쩌면 회의록을 회의록끼리 모아두면 안돼요에 언급한 문제 때문일지도 모릅니다. 이 임시 인벤토리 규칙이 여러 상황에 걸쳐 잘 동작한다는 설명을 들으며 우편을 개발할 필요가 없다는 이야기를 듣다가 결국 고약한 성깔을 못 버리고 한 마디 하고 말았습니다. “ㅇㅋ. 이 규칙이 논리적으로 올바르고 잘 동작할 거란 사실은 인정합니다. 그런데 이 상황을 맞은 고객에게 어떤 경험을 주나요?”
앞서 현대 온라인 게임의 플레이 사이클이 과거와 같이 컨텐츠 길이, 인벤토리 크기 같은 요소에 의해 결정되는 대신 고객들 각각의 가용 시간에 의해 결정된다는 이야기를 했습니다. 이런 상황에서 이 임시 인벤토리 규칙은 명백한 두 가지 문제가 있는데 그 중 하나는 일단 고객이 가용 시간 안에서 만들고 있는 플레이 사이클을 방해한다는 점입니다. 고객은 플레이 도중 인벤토리를 정리하기 위해 별도로 시간을 들여 행동해야 하며 이는 분명 핵심 플레이와는 동떨어져 있을 가능성이 높습니다. 앞서 예를 든 4인 파티 던전을 플레이 하는 시나리오를 다시 생각해볼 수 있는데 누군가는 이렇게 말할 수도 있습니다. 그렇게 중요한 던전이라면 당연히 미리 인벤토리도 비우고 준비를 해야 하는 것 아니냐고요. 20년 전에는 게임이 고객에게 그런 요구를 할 수 있었고 고객은 이런 요구를 수용했지만 현대에는 그럴 수 없고 또 그렇게 행동하지도 않을 거라고 생각합니다. 20년 전에는 그런 요구를 하는 게임이 소수였지만 현대에는 게임 뿐 아니라 다른 엔터테인먼트가 너무나 많습니다. 현대의 게임은 엔터테인먼트로써 고양이짤과 경쟁해야 할 뿐 아니라 틱톡과도 경쟁해야 합니다. 이런 상황에서 고객에게 핵심 플레이인 던전 플레이 전에 인벤토리를 비우고 준비하는 절차를 미리 수행해야 한다고 당당하게 이야기할 수 있을까요? 적어도 저 자신은 고객에게 그렇게 말할 자신이 없습니다.
다른 한 가지 명백한 문제는 고객이 직접 인벤토리를 정리하는 바로 그 동작을 고객에게 직접 요구하는 것입니다. 한때 아이템을 바닥에 버리면 아이템이 바닥에 떨어져 한동안 유지되다가 사라지곤 하는 게임이 있었는데 이들은 인벤토리에 빈 칸을 만들고 싶으면 그냥 아이템을 바닥에 버리면 됐습니다. 시간이 지나며 이런 규칙이 이 행동이 가져오는 플레이, 부작용, 기술적인 부하 따위를 고려해 아이템을 바닥에 버리는 대신 인벤토리에서 직접 파괴하는 기능을 넣게 됐는데 대략 파괴할 아이템을 선택하고 파괴 버튼을 누르면 팝업을 하나 띄워 의사를 물은 다음 아이템을 제거하는 방식으로 동작합니다. 사실 앞서 설명한 4인 파티 시나리오에서 인벤토리가 가득 차 던전에 들어갈 수 없었던 고객 3은 마을에 돌아가 대장장이를 만나 장비를 분해하고 상점에 들러 쓰레기를 판매해 돈으로 바꾼 다음 이 자리로 돌아오는 대신 그 자리에서 아이템 파괴 기능을 이용해 즉시 인벤토리에 빈 공간을 만들 수 있습니다. 때문에 인벤토리에 빈 칸을 하나만 만들어도 이어서 획득하는 아이템에 대해 ‘임시 인벤토리’ 기능을 사용할 수 있기에 괜찮지 않느냐는 제안을 들었지만 결코 괜찮지 않습니다. 스스로 인벤토리에 있는 아이템을 하나 하나 선택해 파괴하는 경험은 결코 즣거운 경험이 아닙니다. 우리들은 이성적으로 인벤토리를 가득 채운 온갖 쓰레기와 결국 분해되어 성장 재료로 사용될 장비들이 그리 큰 가치를 가지고 있지 않다는 사실을 이해하며 이는 고객도 마찬가지입니다. 하지만 이들이 인벤토리에 적당한 그래픽을 보이며 자리를 차지하고 있는 이상 이들의 실질 가치가 아무리 낮더라도 이는 고객 입장에서 재산으로 인식됩니다. 이를 스스로 파괴하도록 하는 행동은 이 행동에 의해 더 많은 보상을 받을 수 있는 던전에 입장하기 위함이라 하더라도 결코 좋은 경험이 될 수 없습니다.
여러 게임에 대장장이에게 말하면 가치가 적은 장비를 한 번에 분해한 다음 장비 성장 재료를 돌려주고 상인에게 말하면 인벤토리에 있는 온갖 쓰레기를 모아 한 번에 판매하고 골드를 돌려주는 기능이 있습니다. 또 다른 게임에는 계속된 반복 플레이를 요구하는 던전에 균열 끝의 대장장이를 배치해 플레이 사이클을 방해하지 않고 또 인벤토리를 정리하기 위해 스스로 재산을 파괴하지 않도록 하고 있습니다. 만약 우리들이 이런 심리 트릭을 이해하고 있다면 던전에 입장하기 위해 스스로 아이템을 파괴하도록 인터페이스를 제공하면 된다는 말을 할 수 없습니다. 또한 만약 우리들이 현대 고객의 플레이 사이클이 그들의 가용 시간에 의해 형성된다는 사실을 이해한다면 던전에 들어가기 전에 마을에 들러 인벤토리를 정리하면 된다는 말을 할 수도 없습니다. 시간의 흐름에 따라 게임들이 제각기 도입하기 시작한 이런 여러 기능과 제한이 거의 없는 인벤토리 같은 요소는 그들이 뭔가 이상한 판단을 했기 때문이 아닙니다. 그들은 현대에 게임과 고객의 관계, 그리고 고객의 특성을 이해하고 이에 맞춰 고객의 플레이를 방해하는 요소를 제거하려고 한 결과 그런 특징을 만들어낸 것입니다.
결국 이 이야기는 훨씬 더 먼 미래에 개발할 예정이던 우편 기능을 앞으로 당기는 계획을 수립하게 만들며 끝났습니다. 하지만 이 계획은 단지 게임디자이너들 사이에서 수립된 것이기에 이 계획을 검토할 협업 부서들로부터 이 글에 길게 이야기한 온갖 질문을 받을 테고 이런 질문 하나하나에 잘 답하지 않으면 결국 임시 인벤토리 같은 논리적으로 결함이 없지만 고객에게 이상한 경험을 주는 기능이 아무렇지도 않게 게임에 들어가고 이는 먼 미래에 우편 기능이 개발되더라도 그에 맞춰 수정되지 않을 겁니다. 이런 보조 기능을 출시까지 얼마 남지 않은 먼 미래에 개발하는 건 늘 그렇게 행동해 왔기에 익숙하고 또 직관적인 것은 사실입니다. 하지만 그 기능 중 일부를 앞으로 끌어와 논리적으로는 문제 없지만 고객에게 나쁜 경험을 주는 이상한 의사결정이 발생할 이유를 근본적으로 없애 버릴 수 있다면 익숙하게 먼 미래에 개발하는 것이 편안한 기능을 덜 익숙한 시점에 가져와 개발하는 편이 더 올바르다고 생각합니다.
이제 긴 글 끝에 제목으로 돌아가 “그 규칙은 말이 됩니다. 그런데 고객에게 어떤 경험을 주나요?”라고 스스로에게 질문해볼 때입니다. 논리적으로 올바른 규칙을 만드는 것은 게임 프로젝트에 참여해 일하는 시스템디자이너에게 요구되는 최소한의 소양이라고 생각합니다. 그런데 그 다음은 그 논리적으로 올바른 규칙이 고객에게 어떤 경험을 주는지 생각해보고 고객에게 이입해 미래에 일어날 그들의 경험을 개선하는 것입니다.
이번 65호에도 지난 2주간 공유한 이야기를 함께 보내 드립니다.
작년(2023년) 봄부터 시작해 50주 동안 계속한 뉴스레터 시즌 1을 공개로 바꿨습니다. 이 부분을 읽고 계신 구독자님들은 이미 살펴보셨겠지만 이제 1호에서 50호까지는 로그인 없이 글을 살펴보실 수 있으니 참고 부탁 드립니다. 시즌 1 글은 다음 링크를 참고해 주세요.
지난주에 ☕커피 한 잔 사주세요 멤버십 이야기를 드렸습니다. 이 쪽에는 69호까지 올라가 있으니 두 달 후 미래에 받아보실 수 있는 글을 먼저 살펴보고 싶으신 분은 다음 주소를 참고 부탁 드립니다.
날씨가 크게 변하고 나니 주변에 우울감을 느끼는 분들이 늘어난 것 같습니다. 계절성 우울이라고 하는 것 같은데 계절성이든 뭐든 어쨌든 우울감은 그냥 지나가겠거니 하고 놔두면 좀 더 큰 문제로 바뀔 수 있어 항상 관심을 가지고 지켜봐야 합니다. 마음의 문제에도 관심을 기울이며 짧은 가을을 무사히 보내시기를 바랍니다. 저는 또 2주 뒤에 뵙겠습니다. :)
