개인적으로 온라인 게임에 소액결제가 도입된 이후 가장 흥미로운 유료 상품이라고 생각하는 것은 계약 형태의 상품입니다. 이걸 정확히 뭐라고 부르는지 잘 모르겠습니다. 업계에서 어지간한 개발 용어들은 사람을 주고받으면서 자연스럽게 공유되어 표준 용어를 사용하는 편인데 유료 상품 관련 용어들은 제 기준에서는 생각보다 널리 표준화 되지 않은 것 같습니다. 일단 저는 ‘계약 상품’이라고 부를 겁니다. 구입 즉시 상품 전체의 가치를 한번에 받을 수 있는 상품과 달리 계약 상품은 상품에 포함된 가치를 전달 받는데 조건이 있습니다. 조건을 만족할 때마다 가치를 받을 수 있지만 만약 조건을 만족하지 않으면 가치를 받을 수 없습니다. 같은 돈을 지불했지만 플레이에 따라 상품으로부터 받을 수 있는 가치가 달라집니다.

이런 계약 상품은 돈을 지불하고 즉시 전체 가치를 얻어 게임에 적용하고자 하는 고객들에게는 전혀 매력적이지 않습니다. 하지만 여러 이유로 이 게임에 당분간 정착하기로 마음 먹은 고객이라면 상당히 매력적인 조건입니다. 상품의 전체 가치를 받을 수 있는 조건들은 계단식으로 구성되어 있고 이 조건의 대부분은 게임을 플레이 하면서 자연스럽게 달성할 수 있는 것들이기 때문입니다. 이는 마치 연금처럼 게임을 플레이 하는데 따라 차례로 지급되기 때문에 내가 앞서 지불한 돈이 계속해서 나에게 영향을 끼치고 있음을 느껴 더 나은 만족감을 느끼도록 합니다. 이런 상품은 모든 계약을 이행해 받는 가치가 상당히 크기 때문에 다른 상품에 비해 시작 비용이 높은 편입니다. 스크린샷의 사례에서 무료로 플레이 할 수 있는 게임에 한 번에 2만5천원을 지불하기로 결정하기는 상당히 어렵습니다. 반면 게임의 구성을 이해한 다음에는 이 금액에 비해 내가 받을 수 있는 가치가 훨씬 높음을 알게 됩니다.

이 상품에 이야기할 특별한 점 두 가지가 있습니다. 하나는 이 상품을 구입하는 순간 플레이어는 이 상품이 제시하는 모든 계약 조건을 달성해야 할 것 같은 압력을 강하게 느끼게 된다는 점입니다. 사실 이 상품에 돈을 냈건 말건 게임을 할 지 말 지는 플레이어의 결정에 달려 있습니다. 언제라도 게임을 할 수도 있고 또 언제라도 게임을 그만 둘 수도 있습니다. 하지만 플레이어는 이 계약에 돈을 지불했고 일부 가치를 이미 받기 시작했으며 법률 상 고지된 청약철회기간을 지난 다음에는 처음 지불한 비용을 단순히 매몰 비용으로 인정하기 어려운 상태가 됩니다. 다른 게임을 플레이 하게 됐거나 다른 할 일에 시간을 사용하게 되더라도 게임을 플레이할지와 비교해 이런 결정들을 내리기 훨씬 어렵게 만듭니다. 개발자 입장에서는 플레이어에게 주는 압력의 정도에 따라 기간, 가격, 가치를 조절해 상품을 구성합니다.

다른 한 가지 특별한 점은 이 상품이 이를 구입하지 않은 플레이어에게도 영향을 끼친다는 점입니다. 이런 형태의 계약 상품이 특별한 점은 이 상품 판매 페이지 자체가 상품의 가치를 습득하는데도 사용되는 것입니다. 상품을 구입한 플레이어도 구입하지 않은 플레이어도 이 페이지를 통해 보상을 받습니다. 이 상품을 구입하지 않기로 결정한 플레이어도 게임을 진행함에 따라 계속해서 보상을 받는데 시간이 흐르면서 상품을 구입할 때 한 번에 얻을 가치가 점차 증가하는 모습을 보게 됩니다. 위 스크린샷에서 레벨업을 진행함에 따라 전설 문장을 받을 수 있는데 이 상품을 구입하지 않은 플레이어는 꽤 많은 전설 문장을 한 번에 받을 수도 있음을 계속해서 보게 됩니다. 그리고 전설 문장 구입 페이지에서 전설 문장 하나가 얼마인지 살펴보고 이 페이지에 돌아와 상품 가격 2만 5천원을 현재 레벨에 받을 수 있는 전설 문장 갯수로 나눠본 다음 고민에 빠지게 됩니다.

계약 상품에는 이런 스타일 외에도 기간 단위로 혜택을 제공하는 형태도 있는데 이는 전통적인 월정액제와 유사한 형태입니다. 이런 계약 상품도 비슷한 특징이 있지만 플레이어에게 미치는 감정적 효과는 약간 다른데 그건 다음에 이야기해 보겠습니다.

현대 F2P 게임에서 상점은 그 자체만으로도 게임의 나머지 부분과 비교해도 의미 있을 만큼 상당한 시간과 노력을 들여야 개발할 수 있는 것이 되었습니다. 초기 상점은 주요 재화를 판매하는 역할을 했다면 이제 상점은 그 자체가 작은 게임 메커닉처럼 동작하고 그 자체로 리텐션을 유지해야 하는 어떻게 보면 작은 게임이라고 볼 수 있습니다. 모바일 게임에서 게임 자체가 리텐션을 유지해야 하고 초기 리텐션에 따라 개발팀의 단기적 운명이 결정된다면 이제 상점은 그 스스로의 리텐션 유지에 따라 개발팀의 중장기적인 운명을 결정합니다.

그래서 상점은 그 스스로가 마치 게임인 것처럼 행동합니다. 실제로 결제를 하는지 여부와 관계 없이 상점에 방문할 이유를 만듭니다. 게임에 등장한 새로운 아이템을 상점 내부에서 소개하기도 하고 성장에 따른 보상을 계약 상품 페이지를 통해 주기도 합니다. 인게임에서도 상점 방문을 가이드 퀘스트 목표로 제시하기도 하고 상점 안에 있는 물건을 사용하는 내러티브를 사용하기도 합니다. 말이 상점일 뿐 실제로는 업적 시스템과 비슷하게 행동합니다.

상점에서 리텐션을 유지하기 위해 가장 흔하게 사용하는 장치는 무료 상품입니다. 일일 접속 보상을 주는 방법 중 하나로 상점을 사용합니다. 일일 접속 보상은 별도 메뉴를 통해 지급하기도 하는데 지난번에 이야기한 적이 있는 일일 최초 처치가 그렇습니다. 게임을 실행해 몬스터 한 마리를 처치하면 보상을 받을 수 있는데 이 보상은 메인 메뉴에 큼직하게 나타납니다. 반면 거의 똑같은 접속 보상은 상점 안에 ‘무료 상품’ 형태로 들어 있습니다. 사실 이 보상은 일일 최초 처치와 비슷하게 ‘상점에 들어오면’ 보상을 주는 형식으로 해석할 수 있습니다. 상점 입장에서는 리텐션을 만들어냈으니 보상을 지급합니다. 또 플레이어 입장에서는 무료 상품이 있는 페이지에 이 게임 전체에서 가장 비용 효율적인 상품을 파악할 수도 있습니다. 만약 이 게임에 조금이라도 과금할 의사가 있다면 이 페이지에 보여주는 상품들이 가장 돈을 절약할 수 있는 방법입니다.

정리하면 상점은 그 스스로가 리텐션을 유지해야 하는 게임의 큰 구성요소이며 이를 위해 상점을 통해 게임의 주요 보상을 지급합니다. 이때 상점은 업적 시스템의 일부처럼 작동합니다. 또 플레이어 입장에서 과금 의사가 있다면 무료 상품 페이지에 최고로 비용 효율적인 상품을 배치해 의사결정을 돕습니다.

사실 ‘위험성’이라고까지 할 건 아닙니다. 그냥 단점이라고 하면 적당할 것 같은데 이렇게 시작했으니 이대로 가보죠. 스크린샷처럼 한방에 화면 전체를 덮는 인터페이스를 전체화면 팝업이라고 합니다. 언리얼 UI에서 이렇게 전체화면을 덮는 인터페이스를 씬이라고 하는데 그 씬 위에 다시 전체화면을 덮는 뭔가를 올리려면 팝업으로 만들어야 합니다. 그래서 화면 전체를 덮지만 팝업이라고 부릅니다. 플레이어에게 뭔가 중요한 메시지를 전달해야 할 때, 또 플레이어가 이 메시지를 중요하다고 느끼도록 만들기 위해 주로 사용하는 것으로 알려져 있지만 사실 이런 팝업을 사용하는 가장 큰 이유는 달리 이 정보를 전달할 마땅한 장소가 없어서 입니다. 이 정보는 그림자단 인터페이스를 통해 전달하거나 버프 인터페이스를 통해 전달할 수 있지만 모두 썩 마음에 드는 장소는 아닙니다. 그림자단 인터페이스에는 이 정보를 전달할 곳이 마땅찮고 버프 인터페이스에 넣자니 이름은 버프와 비슷하지만 속성은 버프라고 보기엔 애매합니다.

하지만 그럼에도 전체화면 팝업은 썩 좋은 선택이 아닙니다. 일단 이 화면을 통해 중요한 정보를 전달하더라도 플레이어는 이 정보를 빠르게 지나가 버릴 가능성이 높습니다. 모바일 환경에서 플레이어는 이런 인터페이스가 나타날 때 빠르게 터치해서 넘기도록 훈련되어 있습니다. 인게임에서 레벨업 토스트가 튀어나오면 얼른 터치해서 없애고 그 뒤에 있는 자동이동 버튼을 터치하고 싶어합니다. 이 팝업이 그냥 넘어가기를 원하지 않는다면 화면 아무데나 터치해서 없애도록 하는 대신 버튼을 만들어 버튼을 터치할 때만 없앨 수도 있지만 그럼 이 팝업에 대한 평가가 엄청나게 나빠질 겁니다. 화면을 계속해서 터치하는데 팝업이 바로 안 없어지면 굉장히 답답합니다. 리뷰에 별 하나를 받을 만큼 답답합니다. 그래서 중요한 정보를 이런 팝업을 통해 보여주면 이 정보는 거의 전달되지 않는다고 보면 됩니다.

개발자 입장에서도 이런 팝업은 함부로 사용하기 어렵습니다. 이 팝업은 일시적으로 게임 전체의 조작을 막기 때문에 아무데서나 쓸 수도 없습니다. 이 팝업 뒤에서 무슨 일이 일어나고 있을지 알 수 없기 때문입니다. 전투 중에는 절대로 띄울 수 없습니다. 안전지역이라도 팝업 뒤에서 일어나는 정보를 통제하므로 잠재적으로 플레이어캐릭터를 의도하지 않은 상황에 처하게 할 수도 있습니다. 가령 파티 던전 입구에 사람들이 몰려오는 광경을 못 보고 지나쳐 파티를 만들 기회를 놓칠 수도 있어요. 그나마 이 스크린샷은 다른 씬 위에 띄운 팝업이고 이 인터페이스는 대부분 안전지대에서 조작하므로 큰 문제가 일어나지는 않겠지만 이 게임이 필드 PvP를 허용한다면 이런 팝업은 심각한 문제가 될 겁니다.

그래서 필드 PvP를 허용하는 게임은 전투 중에 조작할 가능성이 있는 주요 인터페이스가 절대로 화면을 가리지 않도록 설계합니다. 장착한 장비는 화면에 반투명으로, 인벤토리는 화면 한쪽만 가리도록 만듭니다. 이런 게임에서는 화면을 넓게 사용하는 인터페이스가 반투명이라면 전투 도중에 사용할 가능성이 있는 것, 불투명이라면 안전지대에서 조작할 것을 가정하고 만든 것으로 의도를 파악할 수 있습니다. 물론 위 스크린샷을 찍은 디아블로 이모탈은 PvP가 있긴 하지만 필드 PvP는 없어 화면을 가리는데 상대적으로 부담이 적습니다.

자. 그러면 전체화면 팝업을 피하려면 뭘 해야 하는가. 일단 전체화면 팝업의 정보가 플레이어에게 전달될 가능성이 낮기 때문에 이 인터페이스를 사용하더라도 팝업을 닫으면 팝업이 그냥 사라지는 대신 팝업이 접혀 화면 어딘가에 들어가는 애니메이션을 보여주고 이 ‘어딘가’를 조작해 이 팝업을 다시 띄울 수 있어야 합니다. 또 이 팝업을 불러낸 씬 안에 이 팝업이 제공한 것과 같은 정보를 상시 제공해야 합니다. 그러면 팝업 대신 ‘레벨업’ 같은 토스트 형식으로 표현할 수도 있게 됩니다. 더 이상 화면 전체를 가릴 필요가 없어집니다. 요약하면 전체화면 팝업은 중요한 정보를 플레이어에게 전달하려는 의도와 달리 잘 작동하지 않으며 게임의 종류와 상황에 따라 온갖 문제를 일으킬 수 있으니 가능하면 피해야 합니다. 끝.

여름이고 또 비가 안 오는 날이 이어지고 있지만 그래도 즈위프트를 결제했습니다. 실은 바깥에 나가는 것이 훨씬 재미있다는 건 잘 알고 있는데 막상 나갈 생각을 하면 준비하기도 귀찮고 너무 덥고 평일에 집에 돌아가면 지쳐 있고 에너지도 없어 여간해선 라이딩을 나가기 힘들었습니다. 이러다가 새다리 되겠다 싶었습니다. 연초부터 시작한 감량은 어느 정도 성과를 보이고 있지만 오르막을 오를 파워도 함께 사라지는 퍼포먼스 저하가 함께 찾아왔습니다. 그래서 요즘 즈위프트 라이딩은 페이스 파트너와 함께 살살 타는 정도로만 하고 있습니다. 창문을 열어야 해서 본격적으로 힘내기에는 너무 덥기도 하고요.

원래 페이스 파트너 라이딩은 화면 위쪽에 표시된 페이스 그래프를 보고 달렸습니다. 페이스 그래프가 길어지면 좀 더 파워를 내고 그래프가 짧아지면 파워를 떨어뜨리고요. 그런데 이것도 계속 하다 보니 좀 지루했습니다. 화면에 그래픽이 나올 뿐 즈위프트 없이 가민 엣지에 나오는 매일 훈련 프로그램을 따라하는 느낌과 비슷했습니다. 다른 접근이 없을까 생각하다가 HUD를 꺼봤습니다. 컴페니언 모바일 앱을 사용하면 원래 화면에 표시할 정보 중 일부를 모바일 기계 화면에 표시하고 원래 화면에 HUD를 숨길 수 있습니다.

HUD를 숨기고 나자 페이스 파트너 라이딩은 상당히 다른 양상이 되었습니다. 이전에는 단순히 페이스 그래프를 보고 달렸다면 이 정보가 없어지자 페이스 파트너와 주변 사람들의 위치에 신경을 쓰기 시작했습니다. 주변을 보고 내가 너무 앞으로 나갔다 싶으면 페이스를 떨어뜨리고 너무 뒤쳐졌다 싶으면 페이스를 올리고 또 옆에 페이스 파트너가 나타나면 비슷한 파워와 케이던스를 유지하려고 노력했습니다. 타다 보니 이건 뒤를 바로바로 돌아볼 수 없을 뿐 바깥에서 달리는 느낌과 비슷하다는 생각이 들었습니다.

물론 페이스 파트너가 내 뒤에 있을 때 화면 하단에 나타나는 인디케이터 UI도 함께 사라져 살짝 답답할 때도 있기는 하지만 ‘뒤롤 돌아보지 않는 아웃도어 라이딩’ 경험처럼 느껴져서 이전보다 더 재미있었습니다. 한동안은 이렇게 타 볼 작정입니다.

외장식 드라이브를 파일 히스토리에 사용하고 있습니다. 비트락커로 암호화 하고 있고요. 아직까지는 암호화가 도움이 되는 상황을 겪지는 않았지만 장차 그런 일이 일어날 수 있다는 생각을 합니다. 동시에 패스워드를 기억하지 못해 내 스스로도 드라이브에 접근할 수 없는 끔찍한 상황도 종종 상상합니다.

소프트웨어를 사용해 패스워드를 저장하고 있어 내가 직접 기억할 필요는 없지만 비트락커 패스워드처럼 오랫동안 사용할 일이 없는 패스워드는 종종 원패스워드에 등록된 이 패스워드가 내가 필요로 하는 바로 그 패스워드가 맞는지 자신이 없어질 때가 있습니다. 패스워드를 시험해 보고 싶지만 절차가 좀 복잡합니다. 이동식 드라이브는 드라이브를 뺐다가 다시 연결하면 잠긴 상태로 패스워드를 묻습니다. 하지만 이것도 ‘자동 잠금 해제' 옵션이 꺼져 있을 때만 그렇습니다. 자동 잠금이 켜져 있으면 패스워드를 시험해볼 수 없습니다. 한편 ‘암호 제거’는 훨씬 편리한데 드라이브 잠금이 해제된 상태에서 ‘암호 제거’ 링크를 클릭하면 클릭하자마자 바로 암호가 제거됩니다. 그럼 내가 원패스워드에 등록했던 패스워드로 바꿔주면 되니 나쁘지는 않지만 나는 다만 올바른 패스워드를 보관하고 있는지 시험해보고 싶을 뿐인데 이때마다 패스워드를 제거했다가 추가하는 건 뭔가 이상하고 불안합니다.

한편 가끔 텔레그램 메신저가 패스워드를 확인하는 동작은 꽤 부드럽습니다. 가끔가다 ‘혹시 패스워드 기억하고 있니?' 하고 묻는데 기억하고 있다, 모르겠다, 한번 시험해보자의 세 가지 답변을 할 수 있습니다. 기억하고 있다고 하면 거기서 끝납니다. 모르겠다고 답하면 패스워드를 복구할 수 있고요. 제가 주목하는 옵션은 세번째, 한번 시험해보자는 건데요, 바로 패스워드를 물어봅니다. 물론 여기 답하든 답하지 않든 메신저 사용에는 아무런 지장이 없습니다. 하지만 원패스워드에서 패스워드를 찾아 입력해보고 내가 올바른 패스워드를 보관하고 있는 것이 맞는지 확인해볼 수 있습니다. 패스워드를 바꾸거나 인증을 새로 하는 등의 행동 없이도요.

꽤 좋은 아이디어라고 생각합니다. 더욱이 비트락커는 사용하는 기계가 늘어나면 여러 기계와 여러 드라이브에 걸친 복구정보와 패스워드를 각각 관리해야 해서 계정 하나를 운용하는 메신저에 비해 패스워드를 테스트해 보고 싶은 욕구가 더 큽니다. 하지만 비트락커는 그런 기능을 제공하지 않고 있고 이 점이 많이 아쉽습니다. 반면에 텔레그램 메신저의 패스워드 테스트 기능은 인상에 남았습니다.

계약 상품을 소개하면서 게임을 처음 플레이 할 때는 무료 게임에 2만5천원을 내는 결정을 하기 어렵지만 게임을 이해하고 나면 이 금액이 굉장히 저렴한 금액임을 알게 된다는 이야기를 했습니다. 또 레벨을 올릴 수록 결제 시점에 받게 될 아이템이 늘어나므로 매번 이 화면에 무료 보상을 받으러 왔다가 이 상품을 구입할 때 한번에 받게 될 아이템의 가격을 계산해보게 된다고 했었는데 제가 딱 그 시점이 됐습니다. 계획은 이번달 배틀패스 기간이 끝나면 거기까지만 하고 게임을 접으려고 합니다. 그때까지는 게임을 계속할 테고 그럼 기왕 플레이 하는 거 이 상품을 구입하는 것이 좋지 않을까 심각하게 고민하고 있습니다. 그래서 이번에는 실제로 이 상품을 2만5천원에 구입하면 실제 어느 정도 가치를 얻게 되는지 계산해 보려고 합니다.

계산을 편하게 만들기 위해 몇 가지 가정을 하겠습니다. 현재 저는 정복자 레벨 65까지 보상을 받았지만 최대 레벨 보상까지 한 번에 다 받을 때 얻는 아이템을 기준으로 가격을 계산할 겁니다. 또 왼편 ‘숙련가의 포상’은 무료 보상으로 이미 다 받았으니 이쪽의 가치는 0으로 보고 유료 보상인 ‘영재의 포상’ 부분만 계산하겠습니다. 그리고 같은 아이템이라도 상품에 따라 가치가 다르게 설정되어 있을 수 있는데 이때는 추측한 가격 중 높은 쪽 가격을 기준으로 계산하겠습니다.

영재의 길을 구입하면 ‘영재의 포상’으로부터 전설문장 20개와 화산용암재 65개를 받을 수 있습니다. 전설문장 하나 가격이 얼마인지와 화산용암재 하나 가격이 얼마인지 추측해 내면 이 상품의 실제 가치를 알아낼 수 있습니다. 이 상품만 보고서는 각각의 하나 당 가격을 추측할 수 없으니 다른 상품을 둘러보며 힌트를 얻어 보겠습니다.

‘균열 질주자의 보급품'은 전설 문장을 단독으로 판매하고 있습니다. 상품의 의도는 균열 뺑뺑이를 돌 사람들이 구입하라고 만든 거지만 여기서는 전설 문장 하나 가격을 편하게 계산하라고 만든 상품인 것 같습니다. 상품 왼쪽 위에 할인률이 정확하다고 가정하면 이 상품의 할인 전 가격은 16,800원입니다. 이를 전설 문장 수량 6으로 나누면 전설 문장 하나는 2,800원입니다.

다음으로 넘어가기 전에 잠시 영원의 보주 가격을 알아야 합니다. ‘통화’ 페이지에 가서 계산하면 됩니다. 영원의 보주 60개를 1,200원에 팔고 있으니 영원의 보주 하나 가격은 20원입니다.

이제 화산용암재 하나 당 가격을 추측해야 하는데 마침 ‘키쿠라스 여울 보물 상자’에 화산용암재가 포함되어 있습니다. 이렇게 한 번만 구입할 수 있는 상품은 실제 가격보다 더 많이 할인된 경우가 많아 제시된 가격을 그대로 신뢰하면 부정확하지만 여기서는 재미로 구해 보는 거니까 이 가격과 할인율을 신뢰하겠습니다. 왼쪽 위에 표시된 할인율은 240%이니 할인 전 가격은 40,800원입니다. 위에서 영원의 보주 420개 가격은 위에서 구한 개당 가격을 곱한 12,000원이고 전설 문장 7개 가격은 19,600원입니다. 그러면 전체 가격 40,800원에서 이 둘의 가격을 빼면 화산용암재 12개 가격은 9,200원, 개당 가격은 약 767원입니다.

그런데 ‘영재의 길’ 상품은 400% 할인되어 있어 전설 문장 20개 가격인 56,000원을 빼면 화산용암재 65개 가격은 69,000원이고 이를 기준으로 계산하면 화산용암재 하나 당 가격은 1,062원입니다. 앞에서 설명한 대로 한 번만 구입할 수 있는 상품은 표시된 할인율보다 더 많이 할인되어 있을 수 있습니다. 그래서 화산용암재의 두 가지 가격 중 높은 쪽인 1,062원을 선택하겠습니다. 그러면 영재의 길 상품의 실제 가치는 표시된 400%와 동일한 125,000원입니다. 실은 이렇게 멀리 돌아올 필요도 없었습니다.

사실 저는 지금 당장 전설 문장이 여러 개 필요합니다. 문장 20개를 한 번에 산다고 하면 할인율이 적용된 가격 기준으로 ‘균열 질주자의 보급품’을 기준으로 4만원을 내면 문장 20개를 살 수 있는데 ‘영재의 길’을 결제하면 2만5천원만 내면 똑같이 문장 20개를 얻을 수 있을 뿐 아니라 화산용암재 약 7만원어치를 함께 얻을 수 있습니다. 이제 남은 건 배틀패스 남은 기간 안에 이 상품을 살지 말지 고민하는 것 뿐이네요.

전에 디아블로 이모탈의 재화구조 이야기를 하면서 균열을 돌 때 필요한 일반문장, 전설문장, 영원의 전설문장 이야기를 했었습니다. 균열이라는 던전이 있고 던전을 돌 때 이 문장들을 추가하면 균열에 속성이 생기고 또 보상이 달라집니다. 특히 전설문장과 영원의 전설문장은 보상에 전설 아이템을 추가해 줍니다. 오케이. 문장을 추가하면 던전에서 더 좋은 보상이 나온다. 그리고 문장은 게임 내 여러 경로를 통해 얻을 수 있으며 특히 영원의 전설문장은 상점의 독립 공간을 통해 구입할 수 있다. 규칙을 이해한 것 같습니다. 어. 그러면 문장 추가 없이 도는 균열에는 무슨 의미가 있는 걸까요?

어차피 전설을 얻지도 못할 거면 균열을 돌 의미가 없는 것 아닌지, 또 그렇다면 문장을 균열에 추가해서 입장하도록 하는 대신 문장 자체를 균열 입장권으로 만들어야 하는 것 아닌가 하는 생각이 들 겁니다. 그렇게 설계해도 됩니다. 하지만 이들은 그렇게 설계하지 않았는데 문장 없이 균열을 돌 때는 보상으로 경험치와 꺼져 가는 잉걸불을 얻을 수 있습니다. 또 여전히 확률이 낮기는 하지만 희귀 또는 전설 아이템이 나올 수도 있습니다. 그러면 이제 반대로 생각할 수 있는데 ‘횟수가 충분하면 문장이 없어도 되는 것 아닌가?’ 하는 겁니다. 맞습니다. 균열 던전에서 문장은 표면적으로 전설 드랍 확률을 보정하는 역할을 하고 동시에 전설 획득에 필요한 시간을 단축합니다. 그럭저럭 널리 양해된다고 알려진 P2W 모델 중 하나인 시간을 구입하는 모델입니다.

또 게임 자체의 규칙과 과금 모델에 익숙하게 만드는 역할도 합니다. 만약 문장을 균열 입장권으로 설계하면 균열은 시험 삼아 들어가볼 수 있는 던전에서 입장재화와 보상을 맞바꾸는 성장 크리티컬한 메커닉으로 위상이 바뀝니다. 더 민감한 던전으로 성격이 완전히 바뀌게 됩니다. 균열은 성장에 필요한 핵심 자원인 전설 아이템과 꺼져가는 잉걸불을 드랍하지만 동시에 덜 민감한 메커닉 역할을 합니다. 이건 슬롯머신의 프로그래시브 베팅과 논 프로그래시브 베팅의 차이이기도 합니다.

강원랜드에서 가상의 낡은 슬롯 앞에 앉았습니다. 한 게임을 하는데 필요한 최소비용은 10년 전 기준 500원입니다. 기왕이면 같은 돈으로 더 오래 놀겠다는 생각으로 500원을 넣고 한 줄에 베팅하고 버튼을 누르지만 예상 대로 아무것도 얻을 수 없었습니다. 이렇게 몇 판을 하는 내 모습을 보고 옆에 앉아 게임을 하던 다른 분이 한심하다는 눈길로 나를 쳐다봅니다. 500원을 추가할 때마다 최대 세 줄 까지 베팅할 수 있고 한 번에 2000원을 내면 프로그래시브 베팅이라는 메커닉으로 다섯 줄을 베팅할 수 있습니다. 당첨 확률은 더 올라가지만 단위시간 당 더 많은 돈을 쓰게 됩니다. 베팅 확률만 생각하면 처음부터 게임비를 2000원씩 받도록 설계할 수도 있습니다. 그러면 저처럼 이곳에 처음 와 본 사람들이 주머니 속에 지폐를 만지작거리며 저걸 해볼까 말까 좀 더 오래 고민하겠죠. 하지만 500원은 그보다 훨씬 덜 고민할 겁니다. 저는 결국 슬롯에 2000원을 내지는 않았지만 일어나 좀 더 화려해 보이는 다른 게임을 찾아 나섰고 새벽에 남은 칩 하나를 기념 삼아 교환하지 않고 들고 나왔습니다.

다시 주제로 돌아가면 균열에 투입한 단위 시간 당 유효한 보상을 얻기 위해서는 문장을 추가해야 하지만 필수는 아닙니다. 문장을 던전 입장 재화로 설계하지 않은 이유는 그렇게 할 때 던전이 좀 더 성장 크리티컬한 형태로 바뀌기 때문이며 균열은 그 역할만 하기에는 플레이어가 게임에 익숙해지도록 하기에도 적당한 메커닉이기 때문입니다. 아. 그리고 위에서 문장 모델이 비교적 널리 양해되는 P2W 모델이라고 이야기했지만 그럼에도 불구하고 커뮤니티 반응은 썩 좋지 않아 보입니다. 사실 여기에도 이유가 있는데 이 이야기는 제목의 범위를 벗어날 것 같으니 다음에 따로 이야기해 보겠습니다.

현대의 모바일 MMO 게임을 플레이 해보면 플레이어에게 여러 가지 버프, 디버프가 항상 걸려있음을 볼 수 있습니다. 버프는 주로 플레이어와 파티원들에게 이로운 것, 디버프는 해로운 것으로 해석할 수 있습니다. 이들은 바쁜 전투 상황 속에 쉴 새 없이 적용되었다가 사라지기를 반복합니다. 어떤 것들은 그냥 지나가도 딱히 게임에 지장을 주지 않지만 어떤 것들은 디버프 메시지를 놓치면 플레이어캐릭터가 죽거나 아이템을 잃거나 피할 수도 있었던 불리한 상황을 맞이할 수도 있습니다.

때문에 버프와 디버프로 구분되는 플레이어캐릭터에 적용된 여러 효과 표시는 플레이어캐릭터의 남은 체력 정보만큼이나 중요한 정보입니다. 그래서 아주 특수한 경우가 아닌 이상은 체력 정보 근처에 효과 정보도 함께 표시합니다. 그런데 체력 정보는 최대 체력과 현재 체력으로 이루어진 막대그래프 하나로 나타낼 수 있는 반면에 효과는 그 중요성에 비해 정보 자체가 상당히 복잡한 요소들로 이루어져 있습니다. 체력은 하나 뿐이지만 효과는 게임에 따라 다르겠지만 적어도 수 백 개는 될 겁니다. 이제 이 많은 버프와 디버프를 표시할 때 생각할만한 주제들을 늘어놓아 보겠습니다.

아이콘이 너무나 작습니다. 사실 현대 모바일 기계들은 해상도가 무시무시해서 아무리 작은 아이콘이라도 잘 들여다보면 아이콘의 디테일들이 살아있습니다. 하지만 버프, 디버프 아이콘들은 대체로 비슷비슷하게 생긴데다가 이런 아이콘들 여럿이 한 곳에 옹기종기 모여있으면 빠르게 인지할 수가 없습니다. 그렇다고 아이콘 대신 효과 이름을 써 줄 수도 없습니다. 아이콘도 작은데 텍스트는 더 작아 도저히 볼 수 없을 겁니다. 게다가 아이콘은 이 인터페이스에 나타날 것을 고려하지 않고 만들어져 여러 색상을 기준 없이 사용했고 이게 버프인지 디버프인지 아이콘을 보고는 구분할 수가 없습니다. 아이콘의 역할은 거의 이 효과가 다른 효과와 구분된다는 사실만을 전달할 수 있을 뿐입니다. 모든 정보를 빠르고 정확하게 전달할 방법은 사실 없습니다. 이 상황에서 최선은 그나마 버프와 디버프를 구분하는 것입니다. 그래서 아이콘에 얇은 테두리를 둘러 버프와 디버프를 구분합니다. 버프에는 녹색 테두리, 디버프에는 적색 테두리를 두릅니다. 이제 아이콘은 전보다 더 눈에 잘 띄지 않지만 적어도 지금 내게 적용 중인 효과들의 경향을 파악할 수는 있게 됐습니다.

공간이 좁을 겁니다. 모바일 인터페이스를 설계하면서 고통스러운 점 중 하나입니다. 그렇잖아도 화면이 좁은데 그 안에 터치 조작계도 넣어야 하고 PC에서 넓은 화면에 가득 채워 보여주던 정보들도 잘 정리해서 욱여 넣어야 합니다. 이런 정보를 생각 없이 욱여 넣다 보면 스페이스 셔틀 콕핏 정도는 우스울 지경입니다. 이 난리 속에 플레이어에게 적용될 효과를 표시하려고 보니 체력 막대그래프 근처 어딘가에 정말 한계 크기에 가까운 아이콘들을 다닥다닥 표시하게 될 겁니다. 공간이 좁습니다. 때문에 가장 먼저 결정할 것은 이 좁은 공간에 효과를 몇 개 까지 보여줄지 결정하는 겁니다. 보통 이 질문을 바로 받으면 답할 수가 없습니다. 대강 공간이 허락하는 만큼 넣을 수 있는데 그럼 같은 공간에 효과 다섯 개를 한 번에 표시할 건지 아니면 아이콘 크기를 줄여 여덟 개를 한 번에 표시할 건지 등을 정해야 합니다. 질문을 받고 바로 정할 수는 없습니다. 여기 답하려면 전투시스템에 대하 경험과 이해가 바탕이 되어야 합니다. 전투 하며 중요한 효과가 몇 개 쯤 되는지에 대한 감각이 필요하고 이 수량을 결정하기에 앞서 공간 제한 없이 아이콘을 띄우는 테스트 환경에서 플레이 하며 어느 정도 정보가 유효한지 감각을 쌓아야 합니다. 즉시 진행할 수는 없습니다.

어떤 순서로 보여줘야 할 지 고민일 겁니다. 남은 시간이 긴 것을 우선 보여줄 수 있습니다. 나쁘지 않은 규칙 같네요. 그런데 보스가 나에게 2초 후 발동하는 즉사기를 걸었습니다. 이 디버프 앞에 남은 시간이 30초 이상 남은 버프 여러 개가 늘어서 있어 이 디버프가 표시되지 않았습니다. 나는 무슨 일이 일어났는지도 모르고 바닥에 눕고 말았고 짜증이 날락말락 합니다. 아무래도 버프보다는 디버프 정보가 더 중요한 것 같습니다. 그럼 이번에는 디버프 정보를 앞에, 버프 정보를 뒤에 보여주기로 합니다. 또 이번 즉사기처럼 시간이 짧으면서도 중요한 정보를 앞쪽으로 정렬하기 위해 게임디자이너가 직접 계산한 중요 순서에 따라 정렬되도록 합니다. 이번에는 시간 크리티컬한 디버프 정보를 인지할 수 있게 됐지만 효과 목록 자체가 직관적이지 않게 됐습니다. 뭔가 순서가 있는 것 같기는 한데 잘 모르겠습니다. 상점에서 구입한 7일짜리 버프 상품이 적용되는 중인지 확인하려면 반드시 효과 아이콘을 눌러 효과 목록에서 따로 확인해야만 하니 좀 불편한 것도 같습니다.

오랫동안 사라지지는 않지만 궁금하기는 한 효과 정보를 처리할 방법을 정해야 합니다. 길드에 가입했더니 한 주 단위로 적용되는 길드 버프가 생겼습니다. 이 정보는 전투에 크리티컬한 정보는 아니지만 지금 길드 효과가 적용되고는 있는지, 그게 무슨 효과인지 정도는 가끔 궁금합니다. 또 잠깐 이야기한 유료 효과는 앞으로 28일 동안 적용될 예정이지만 또 가끔 이게 잘 적용되고 있는지 궁금해집니다. 이런 정보는 전투 크리티컬 하지는 않아 앞쪽으로 정렬하지 않아도 되지만 전투 중이 아니라면 가끔 궁금해지므로 너무 뒤에만 있으면 불편합니다. 내가 지불한 돈이 잘 쓰이고 있는지 표시하는 역할을 하므로 항상 '…'을 눌러 이 정보를 확인하는 것은 P2W 게임 입장에서 썩 좋은 아이디어가 아닙니다. 적당한 규칙을 찾아야 합니다.

이 외에도 각 효과가 중첩될 때 규칙도 정해야 합니다. 같은 계열의 디버프가 중첩될 때 중첩된 각 디버프 별 남은 시간이 모두 다르다면 이를 어떻게 축약해서 보여줄 것인지 혹은 디버프를 통합할 것인지 정해야 합니다. 후자의 결정은 전투 규칙에 영향을 주게 됩니다. 전투 담당자가 이 규칙을 먼저 선언하거나 효과 인터페이스 담당자가 규칙을 선언 또는 제안할 수도 있습니다. 버프와 디버프를 표시할 때 생각할만한 주제를 대강 늘어놓아 보았습니다. 이런 주제들이 항상 그렇지만 파고들기 시작하면 고려할 온갖 자잘한 디테일들이 끝도 없이 이어지기 때문에 시작할 때 목표를 잘 선언해 두지 않으면 상당히 고통스러울 수 있습니다. 하지만 시작하기 전에 이런 주제들이 나타날 것임을 미리 알고 있으면 좀 덜 고통스러울 수도 있을 거라고 생각합니다.

흔히 시스템기획자로 분류되는 사람에게 규모가 큰 일 덩어리를 맡기면 종종 일어나는 일 중에는 이 일에 관련된 여러 사람들로부터 쉴 새 없이 흔들린 나머지 일이 진행되기도 전에 지쳐 버리는 것입니다. 일의 덩어리가 클수록 일에 관련된 사람들도 많고 이 사람들 각각은 모두들 자신의 의견을 가지고 있습니다. 특히 게임은 개발에 참여하는 사람들 각각이 서로 다른 게임의 고객인 경우가 많아 의견의 종류는 더더욱 많아집니다. 모두들 더 잘 됐으면 하는 생각으로 한 마디 씩 거들지만 이들을 모두 듣고 어떻게든 결정을 내려야 하는 기획자 입장은 하루하루 곤란해집니다. 운이 좋다면 의욕적으로 피드백을 준 누군가는 자신의 말 자체를 잊어버리지만 그렇지 않은 누군가는 왜 자기 의견이 반영되지 않았는지 이후 이 일에 관련된 모든 공적인 자리에서 기획자를 공격할 수도 있습니다. 어떻게 하면 좋을까요.

세션 단위로 플레이 하는 가상의 PvP TPS 게임을 만든다고 해 보겠습니다. 팀을 꾸려 핵심 플레이를 만들고 대강 이어붙인 위젯을 통해 이제 게임이 돌아갑니다. 세션도 만들 수 있고 게임도 되고 승패 판정도 됩니다. 테스트해보니 생각보다 재미있는데다가 발전시킬 요소도 많아 보입니다. 또 한편으로는 대강 만든 UI 위젯 뭉치만으로는 서비스할 수 없으니 본격적으로 게임 바깥을 만들어야 합니다. UI로만 세션을 생성하는 것은 어째 좀 심심하니 인게임의 분위기를 잘 드러내고 근미래에 상점에서 판매할 꾸미기 아이템을 더 자주 노출하기 위한 로비 레벨과 여기 어울리는 UI를 개발하기로 합니다. 에픽 이름은 로비 개발이라고 해보겠습니다.

이 일은 그리 단순하지 않습니다. 로비 배경의 레벨도 디자인해야 하고 그 위에 UI도 설계해야 합니다. 이들이 잘 합쳐져 아름답게 동작하려면 연출에도 신경 써야 하고 세션 생성, 플레이어 검색 등 지금까지는 없었던 다양한 기능을 추가로 제공해야 할 겁니다. 익숙한 시스템기획자는 비슷한 게임들을 살펴본 다음 인터페이스 와이어프레임을 그리기 시작합니다. 이 과정을 지켜보던 사람들이 지나가며 한마디씩 거들기 시작합니다. 내가 본 다른 게임에서는 이렇게 답답한 인터페이스를 사용하지 않더라, 지금 내가 플레이하는 이 게임을 봐라. 나는 이런 점이 마음에 들었다 등등의 이야기를 거들기 시작합니다. 또 누군가는 UI 와이어프레임 위에 대강 올려놓은 버튼을 보며 이 버튼은 전체 UI의 밸런스를 깨니 이 아래쪽으로 옮겨야 한다거나 세션 목록의 플레이어 포트레이트는 너무 구식이 아니냐는 이야기를 하기도 합니다. 그렇잖아도 신경 쓸 부분이 많고 협업해야 할 사람들도 많은데 모든 사람이 지나가며 각자의 의견을 말하는 통에 어디까지 받아들여야 할 지 모르겠습니다. 모든 사람들의 의견을 목록에 적어 놓고 하나씩 반영도 해보지만 시간이 지날수록 불행해집니다.

저는 이런 상황이 일을 시작하는 방법에 문제가 있었기 때문이라고 생각합니다. 인터넷을 둘러보면 온갖 개발팀에 유능한 디렉터가 마일스톤을 시작할 때 마일스톤에 필요한 각 기능의 하이컨셉을 충분히 설명하고 시작할 것 같은 느낌이 있습니다만 그게 가능한 스탭은 업계 전체를 통틀어도 드뭅니다. 대부분은 기능 이름만 있고 나머지는 그냥 알아서 해야 합니다. 때문에 업무의 기능 명세 기준으로 접근하기 쉬운데 기능의 나열과 이에 기반한 UI 와이어프레임은 지나가는 사람들이 생각 없이 건넨 한마디 한마디에 쉽게 망가지기 마련입니다.

규모가 큰 기능 이름만으로 업무를 시작했다면 기능 명세가 머릿속에 떠오르더라도 잠깐 멈춰 이 기능을 지탱할 단단한 컨셉을 생각해내야 합니다. 다시 가상의 게임에 필요한 로비를 만드는 시점으로 돌아가 봅시다. 이 로비는 어떻게 생겼을까요. 여러 사람들이 레벨에 보여 돌아다니는 모습을 보고싶기도 하고 또 세션 목록을 표시하는 인터페이스도 필요할 것 같습니다. 사람들이 어디에 모여있을까요. 싸우기 위한 사람들이니 임무를 수행 중인 군 병력이 나오는 영화나 사진을 찾아보며 적당한 분위기를 찾아냅니다. 마침 우리 전투 레벨 중에 시가전 레벨이 있는데 이 레벨의 무너진 광장에 사람들이 모여 있으면 어울릴 것 같습니다. 이 안에 사람들이 모여있다면 가운데 분수를 둘러싸고 모여 앉아 이야기를 나누거나 천막 안에 물건을 가지러 가거나 드럼통 주변에 모여 담배를 피우고 있을 것 같습니다. 저 구석에 게시판이 있는데 거기 같이 출발할 사람을 모집하는 쪽지들이 붙어있을 것 같네요. 자. 이제 다음 단계로 넘어갈 준비가 됐습니다.

이번에는 상황이 조금 달라졌을 겁니다. 누군가 와서 UI의 작은 버튼 이야기를 하거나 어제 밤에 플레이 한 게임 스크린샷을 보여주더라도 그 의견을 바로 피드백 목록에 추가할 필요가 없습니다. 이제 뭘 만들 건지 전체 이미지를 설명할 수 있게 됐으니까요. 아직 기획서는 없지만 내가 생각하는 완성된 모습을 시각적인 표현을 사용해 설명해봅니다. 이전에는 내 생각을 지탱하는 컨셉이 없었기 때문에 지나가는 모든 사람들의 의견이 피드백이었지만 이번에는 내 생각을 지탱하는 컨셉이 있어 사람들의 의견은 내 컨셉과 비교해 취하거나 버릴 수 있는 의견으로 바뀝니다. 그 망할놈의 몬헌을 플레이하는 사람들이 와서 집회소 이야기를 꺼내더라도 그걸 피드백 목록에 올리지 않아도 됩니다.

기획을 기능 단위로 접근하려고 할 수록 이런 함정에 더 잘 빠지는 것 같습니다. 큰 팀에서 시스템 기획자 타이틀을 달고 일하기 시작하면 뭐든지 기능 단위로 접근할 때 일하기 더 쉽기 때문에 더더욱 이런 상태가 되는 것도 같고요. 하지만 기능의 크기가 클수록 컨셉은 중요합니다. 내 의견 전체를 단단히 지탱하는 컨셉을 만들고 이를 근거로 의견에 대응해보세요.

전에 잠깐 현대로 오면서 던전 플레이가 변했다는 이야기를 했었습니다. 퍼시스턴트 공간이 인스턴스 공간으로 바뀌고 MMO 장르이지만 던전은 싱글플레이나 소규모 멀티플레이에 가깝게 변했다는 이야기였습니다. 이로써 여러 효과와 시도가 있었는데 그 중 하나는 던전 플레이 경험을 좀 더 몰입적으로 바꾸는 강력한 연출을 채용한 것입니다. 많은 사람들과 공유하는 공간에는 이런 일을 함부로 하기 어렵습니다. 하지만 싱글플레이에 가까워질수록 던전에 강력한 연출을 하기 상대적으로 쉬워집니다. 이런 연출은 던전 경험을 더 깊이 있게 만듭니다. 또 이 경험은 더 오랫동안 플레이어들의 마음 속에 남아 있을 겁니다.

온라인 게임에서는 이런 연출을 할 때 몇 가지 고민거리가 있습니다. 던전에서는 플레이에 따라 플레이어캐릭터가 죽을 수도 있다는 점, 네트워크 순단이나 클라이언트 종료가 일어날 수 있다는 점, 또 소규모 멀티플레이 환경에서 플레이 경험에 동시성을 확보해야 하는 상황 같은 것들이 인스턴스 던전 메커닉을 설계하기 어렵게 만듭니다. 오늘은 방금 나열한 몇 가지 문제들을 특히 ‘이동경로를 파괴하는 연출’을 사용하는 사례를 들어 이야기해 보겠습니다.

가상의 던전이 있습니다. 진행해 감에 따라 던전이 흔들리며 무너질 것 같은 느낌을 줍니다. 위에서 돌이 떨어지기 직전에 바닥에 장판이 깔리고 피하지 못하면 대미지를 입기도 합니다. 충분히 긴박한 느낌을 주네요. 이제 앞에 있는 다리를 건넙니다. 다리를 건너는 순간 드래곤이 나타나 다리를 파괴합니다. 플레이어캐릭터는 아슬아슬하게 불덩이가 되어 다리와 함께 무너져내리는 신세를 피했습니다. 이제 뒤로 돌아갈 방법은 없습니다. 앞으로 나아가 던전을 탐험하고 던전 끝에 있을 던전의 주인을 처치할 수밖에 없습니다.

먼저 소규모 멀티플레이 상황에서 사건의 동시성을 생각해 봅시다. 상대성이론의 동시성과는 굉장히 다른 이야기이니 긴장할 필요가 없습니다. 다리는 무너지기로 약속되어 있습니다. 혼자 플레이 할 때는 플레이어캐릭터가 다리 중간에 쳐 놓은 볼륨에 진입하면 그때부터 드래곤이 나타나 다리를 파괴하고 아슬아슬하게 피해 무너지는 다리에 매달려 건너편으로 기어올라가는 연출을 한 다음 플레이어캐릭터에게 다시 제어권을 돌려주는 방법을 쓸 수 있습니다. 그런데 만약 이 던전을 두 명이 플레이한다면 어떻게 해야 할까요. 첫 번째 플레이어캐릭터가 다리를 건너며 볼륨에 진입해 드래곤을 불러들여 다리가 이미 무너지고 있습니다만 두 번째 플레이어캐릭터는 아직 다리에 진입하지도 않았습니다. 연출이 끝나고 다리는 파괴된 상태가 됐지만 두 번째 플레이어캐릭터는 진행할 방법이 없군요. 미안하지만 이제부터 이 던전은 혼자 진행해야겠습니다.

근래에 시도한 방법은 다리 위 볼륨을 다리 중간부터 건너편 너머까지 길게 쳐 놓고 모든 플레이어캐릭터가 이 안에 들어있을 때 연출을 시작하는 것입니다. 첫 번째 플레이어가 다리 중간을 지나갈 때 아무 일도 일어나지 않습니다. 하지만 마지막 플레이어가 다리 중간을 지나가기 시작하면 이때에 맞춰 드래곤이 나타나 다리를 공격하기 시작합니다. 이 볼륨을 길게 쳐야 하는 이유는 누군가 드래곤이 다리를 공격하기 시작하는 시점에 맞춰 볼륨을 벗어날 수 있는데 이 벗어나는 방향이 진행방향과 반대일 수도 있기 때문입니다. 두 번째 플레이어가 볼륨에 진입하는 사이에 첫 번째 플레이어가 볼륨을 빠져나가 던전 입구쪽으로 돌아갈 수 있습니다. 이 때는 마지막 플레이어가 볼륨에 진입했다 해도 연출을 시작하면 안됩니다. 아니면 명시적인 발판을 만들어 모든 플레이어캐릭터가 발판에 올라서기 전까지는 연출을 시작하지 않는 방법도 있습니다. 물론 이 드래곤 케이스에 적용하기에는 좀 어울리지 않긴 합니다.

플레이어캐릭터가 전투 중 죽는 상황을 생각해봅시다. 던전 중간 중간에 부활 지점이 있어 이곳부터 재시작 할 수 있습니다. 방금 플레이하던 곳으로부터 약간 떨어져 있지만 오히려 강한 몬스터들이 부활하자마자 달려들지도 않고 잠깐 서서 재정비할 시간도 있으니 조금 달려가야 한다고 해도 별로 나쁘지 않습니다. 그런데 이 부활 지점이 드래곤이 부숴버린 다리 건너편이라면 어떻게 해야 할까요. 이미 다리는 파괴되어 걸어서 건너올 방법이 없어졌는데요. 포악한 던전의 주인은 여전히 던전 가장 깊은 곳에서 괴성을 질러대고 있지만 나는 그에게 갈 방법이 없고 이제 그만 던전 공략을 포기해야 할 것 같습니다.

간단히 부활 지점을 파괴된 자리의 진행 방향 건너편에도 설치하면 간단히 해결할 수 있습니다. 물론 온전한 해결 방법은 아닌데 부활 규칙이 이 부활 지점을 망가뜨릴 수 있기 때문입니다. 게임에 따라 즉시 부활, 부활 지점에서 부활, 던전 입구에서 부활, 마을에서 부활 같은 여러 옵션을 제공합니다. 옵션에 따라 재화를 요구하기도 하고요. 즉시 부활이나 부활 지점에서 부활하는 경우에는 무너진 다리 건너편에 부활 지점을 만들어 두면 문제를 해결할 수 있지만 던전 입구나 마을에서 부활한다면 여전히 문제가 있습니다. 게임에 따라서는 던전 진행상황에 따라 던전 입구나 마을 부활을 금지하기도 하고 좀 깨긴 하지만 다리가 무너진 다음에 던전 입구부터 달려올 플레이어들을 고려해 보스전이 시작되면 던진 입구 쪽에 보스룸 앞까지 바로 이동할 수 있는 게이트를 제공하기도 합니다.

해결 방법은 여러 가지가 있지만 ‘이동 경로를 파괴하는 던전 연출’을 사용하기로 마음먹었다면 게임의 나머지 규칙들에 의해 플레이가 불가능해지는 상황이 일어나지 않도록 연출을 지탱하는 규칙을 꼼꼼하게 설계해야 합니다. 사실 이 연출은 연출의 멋짐과 비교해 나머지 시스템들이 지러야 할 댓가가 상당하기 때문에 게임 전체의 방향성과 비교해 신중하게 선택해야 합니다.

이번에도 지난번에 이어 그리 복잡하지 않은 주제를 이야기해 보겠습니다. 여러 MMO 게임에서 게임의 최 하단에 경험치 게이지를 둡니다. 게임에 따라 게이지에 마디를 만들어 알아보기 쉽게 표현하기도 하고 또 어떤 게임은 한 덩어리로 만들되 게이지에 그라데이션을 넣어 멀리서 쳐다봐도 대강 어디 쯤인지 파악하기 나쁘지 않게 만들어 놓습니다. 또 이 경험치 게이지 근처에는 현재 레벨, 현재 경험치, 다음 레벨이 일어나는 상태를 100%로 할 때 현재 경험치 비율을 함께 표시하곤 합니다. 모바일 기계에 버튼이 없어지기 이전 시대에는 이 경험치 게이지를 터치하면 팝업을 통해 정보를 제공하기도 했지만 모바일 기계에 버튼이 없어지면서 더이상 아무 입력도 받지 않게 됐습니다.

그러면 이 경험치 게이지는 왜 화면 맨 밑에 있을까요. 만약 경험치 게이지를 조작하는 기능을 남겨두고 싶었다면 이를 화면 다른 곳으로 가져갈 수도 있었을 텐데요. 이미 예상하셨겠지만 경험치는 게임이 그라인디 할 수록 변화가 적지만 동시에 플레이어가 가장 관심을 기울이는 숫자 중 하나이기 때문입니다. 게임을 적극적으로 플레이 하는 플레이어 입장에서 가장 중요한 숫자는 내 체력과 상대의 체력일 겁니다. 매니지먼트 장르를 플레이 한다면 획득한 주요 재화의 양이나 남은 포션의 양일 수 있겠네요. 이런 플레이어들 모두가 궁금해하는 숫자가 바로 다음 레벨에 도달하는데 필요한 경험치량입니다. 이 숫자는 변화가 적지만 대부분 플레이어들의 관심거리이기 때문에 화면에 항상 표시해야 합니다. 그런데 변화가 적기 때문에 최대한 넓은 공간에 나타내야만 하고 덕분에 이 조건들을 만족하는 가장 적당한 공간이 화면 최하단입니다. 그래서 이곳에 경험치 게이지를 나타냅니다.

게임에 따라 다른 선택을 할 여지는 있습니다. 좀 더 그라인디 한 게임이라면 화면 하단에 배치하고 현재 경험치 비율을 소수점 여러 자리로 표시하기도 합니다. 잡몹 한 마리를 잡더라도 소수점 셋째 자리에서는 경험치가 올라가는 모습을 볼 수 있습니다. 반면에 덜 그라인디할수록 경험치 게이지를 화면 하단의 가장 긴 공간에 표시할 이유는 상대적으로 적습니다. 위 스크린샷은 사실 경험치 게이지를 하단에 표시해야만 하는 사례로 들기에 적당한 게임은 아닙니다. 다만 요즘 플레이 하고 있어 스크린샷을 찍기 쉬워서 이걸로 정했습니다.

화면 상의 여러 구성요소들은 처음으로 구성요소가 그 자리에 배치될 때 이유를 가지고 그 자리에 배치된 경우가 많습니다. 그래서 ‘이게 왜 이 자리에 있지?' 같은 의문을 가지고 생각해보면 흥미로운 주제들을 많이 만날 수 있어요.

바로 앞에서 약간 민감할 수도 있는 이야기를 했으니 이번엔 가벼운 이야기를 해보죠. 지역 타이틀. 프로젝트마다 부르는 이름이 다를 것 같습니다. 제가 속한 프로젝트에서는 지역 타이틀이라고 불렀습니다. 플레이어캐릭터가 이동하다가 어느 지역에 진입할 때 화면 중앙 상단에 이 지역 이름과 지역의 상태를 보여주는 인터페이스입니다. 간단한 장치처럼 보이지만 설계하는 사람 신경을 긁는 자잘한 디테일이 있습니다.

가장 간단한 단계부터 시작하겠습니다. 지역에 진입하면 지역 타이틀 인터페이스를 띄우는 거니까 간단히 에디터에서 레벨을 열어 미리 약속한 볼륨을 친 다음 볼륨에 지역 이름, 상태 데이터를 연결해 두고 런타임에 플레이어가 이 볼륨에 들어갈 때 인터페이스를 띄우면 될 것 같습니다. 동기화할 필요도 없으니까 클라이언트에서만 처리하면 되겠어요. 지역 타이틀 인터페이스는 이런 인터페이스가 나타났다 사라지는 공통 규칙에 따라 일정 시간 동안 유지되다가 사라질 겁니다. 이 공통 규칙 역시 단순하지는 않은데 이건 다음에 기회가 되면 이야기해보죠. 오늘은 지역 타이틀 인터페이스가 나타나면 별 문제 없이 평화롭고 안전하게 사라질 거라고 가정하겠습니다. 자. 이제부터 이 간단한 상태에 문제를 하나 씩 제기해 보겠습니다.

만약 플레이어캐릭터가 뭔가의 이유로 혹은 아무 이유 없이 볼륨 가장자리를 오가면 어떻게 될까요. 위 스크린샷에서 ‘중앙 광장’에 해당하는 영역에 볼륨을 쳐 놨다고 가정하겠습니다. 플레이어캐릭터가 볼륨 바깥쪽과 안쪽을 짧은 시간 안에 오락가락 하는 겁니다. 그럼 방금 정의한 규칙만으로는 좀 꼴사납게 동작할 겁니다. 볼륨에 새로 진입할 때마다 지역 타이틀이 반복해서 나타나겠죠. 만약 인터페이스 공통 시스템이 잘 구축되어 있다면 꼴은 좀 사납겠지만 어쨌든 지역 타이틀 인터페이스 자체는 안전하게 나타날 겁니다. 하지만 그렇지 않다면 같은 지역 인터페이스가 여러 개 겹치거나 같은 UI 위젯의 나타나고 사라지는 애니메이션이 꼬여서 이상하게 보이는 등의 문제가 생길 겁니다. 그럼 어쩌죠? 지역 타이틀 인터페이스에는 쿨타임이 있는 것이 좋겠습니다. 지역 타이틀을 한 번 표시하면 10초 동안은 다음 지역 타이틀을 표시하지 않는 거죠. 이제 지역 타이틀은 한 번에 하나만 나타나고 UI 시스템이 견고하지 않아도 망가질 일이 줄어들겠네요. 하지만 이 쿨타임은 지역 타이틀 측면이 아니라 UI 시스템 측면에서 접근해야 합니다. 안 그러면 지역 타이틀 데이터 어딘가에 쿨타임을 따로 입력하는 안타까운 결과로 끝날 수도 있습니다. 이게 왜 안타까운지 역시 다음에 기회가 되면 이야기해 보겠습니다.

이렇게 만들어 두면 QA로부터 오동작 보고가 올 겁니다. 순간이동 해서 중앙 광장에 도착했는데 지역 타이틀이 뜨지 않는다고요. 사실 요구한 대로 구현된 상태이기 때문에 버그라고 볼 수는 없습니다. 애초에 요구사항이 부족한 결과입니다. 분명 볼륨에 진입할 때 지역 타이틀을 띄우기로 했습니다. 그런데 볼륨 진입 이벤트는 실제로 볼륨에 걸어서 진입할 때 발생합니다. 때문에 순간이동을 통해 볼륨 안에 플레이어캐릭터가 나타나면 진입 이벤트가 일어나지 않아 지역 타이틀이 나오지 않습니다. 앞선 문제보다는 훨씬 간단해 보입니다. 요구사항을 정의할 때 이 지역에 진입할 수 있는 경로를 조사해 이들 모두를 처리하면 됩니다. 사실 기획자가 이 모든 경로를 파악하지 못하고 있을 수도 있습니다. 이 때는 담당 엔지니어와 상담하거나 만약 코드를 읽을 수 있는 환경이라면 진입을 호출하는 곳들을 기계적으로 검색해볼 수도 있습니다. 참고로 걸어 들어가는 경우, 순간이동을 통한 경우, 전투 등에 의한 물리연산에 의해 이동 당하는 경우 등이 있고 이동 형태 역시 걸어서 이동처럼 틱 연속적인 것과 순간이동, 빠른 속도로 이동처럼 틱 불연속적인 것도 있음에 유의해야 합니다.

앞에서 간단히 넘어간 쿨타임도 조금은 더 신경 써야 합니다. 이건 지역 타이틀이 아니라 UI 시스템에서 다룰 문제여서 지역 타이틀을 담당자를 따로 설정했다면 난이도가 낮지는 않은 업무가 될 겁니다. 각 존 별로 지역 타이틀이 뜨도록 설정해 놨다 칩시다. 레벨디자이너는 존 전체를 덮는 볼륨을 쳤을 겁니다. 이제 이전 존에서 지역 타이틀을 보고 쿨타임 10초가 지나기 전에 로딩을 거쳐 다음 존에 도착했습니다. 어. 지역 타이틀이 안나오네요. 이 역시 요구사항대로 동작했으므로 버그는 아닙니다. 하지만 마음이 불편하죠. 해결 방법은 여러 가지입니다. 반사적으로 생각하면 존을 이동할 때는 UI 쿨타임을 초기화할 수도 있습니다. 이는 UI 시스템 관점에서 평가되어야 합니다. 또 정책적으로 존 전체를 덮는 지역 타이틀 볼륨을 만들지 않는 것도 방법입니다. 로딩이 끝나자마자 다른 지역 타이틀 볼륨 안에 들어간 상태라 바로 지역 타이틀 인터페이스를 띄우는 것은 썩 좋은 아이디어는 아닙니다. 이유는 기기에 따라 로딩 직후 프레임이 떨어진 상태일 수 있어요. 내 테스트 장비에서는 아무 문제 없겠지만 누군가의 장비에서는 로딩 직후 나타나는 인터페이스들이 전부 다 버벅거리고 있을 수도 있습니다. 그래서 볼륨을 실제 존보다 작게 쳐서 로딩이 끝난 다음 플레이어캐릭터를 이동시켜 몇 발자국 걸은 다음에야 존 타이틀이 나타나게 설정할 수 있고 이는 문제를 부드럽게 해결합니다.

실은 아직 이야기하지 않은 문제들이 더 있지만 그럼 지역 타이틀 같은 간단한 주제를 다루는데 텍스트가 너무 길어져 지금보다 훨씬 지루해질 것 같으니 여기서 끊겠습니다. 어느 날 심심하면 이 다음 이야기도 해볼께요. 미래의 저를 위해 힌트를 조금 남기자면 ‘볼륨은 볼록다각형 모양인가?’, ‘큰 지역 안에 작은 지역이 중첩되어있다면?’, ‘복층 레벨이라면?' 같은 문제들이 있습니다.

지금까지 여러 프로젝트에 기획팀 입장으로 참여하면서 자주 들었던 주문 중 하나입니다. 마일스톤을 2개월 단위로 운영하는 프로젝트가 있다고 하겠습니다. 지난 마일스톤이 끝나고 이제 이번 마일스톤을 시작하는 첫 날이 되었습니다. 다행히도 이번 마일스톤은 마일스톤 시작 첫날 전에 이번 마일스톤의 목표가 합의되어 공유된 상태입니다. 마일스톤을 시작하자마자 일어날 일은 기획팀에서 이번 마일스톤 목표의 요구사항을 기획서에 작성하기 시작하는 겁니다. 이런 마일스톤 운영은 바쁜 팀에서 다른 팀이 불만을 가지게 만듭니다. 마일스톤 기간은 두 달이지만 실제로 기획서가 넘어가 일할 수 있게 되는 시점은 마일스톤 시작 시점으로부터 시일이 훨씬 지난 다음이고 두 달 중 실제 개발이나 에셋 제작에 사용할 수 있는 기간은 훨씬 짧기 때문입니다. 심지어 우선순위가 높고 규모가 큰 기능들은 마일스톤 시작과 함께 기획서 작성에 착수하지만 온갖 사람들의 피드백과 불확실한 요구사항 사이를 허우적거리다 보면 첫 달을 모두 소모한 다음에야 간신히 기획서가 넘어가는 일도 자주 일어납니다. 불만이 없을 수가 없어요.

기적적으로 기획서가 첫 두어 주 안에 작성되어 협업 부서에 전달되어 본격적인 개발을 시작하게 됐다고 가정하겠습니다. 여전히 마일스톤 기간 전차를 오롯이 개발에 사용할 수가 없는데 이유는 마일스톤 끝에는 마감이 기다리고 있기 때문입니다. 마감 이전에 개발을 마쳐 기능을 조립하고 테스트하고 컨텐츠를 입력해 실제 동작하게 할 시간이 필요하기 때문입니다. 프로젝트 관리를 꽤 오래 하셨다고 말씀하시는 분들도 이 기간을 과소평가하는 경우를 자주 겪었습니다. 심지어는 이 기간은 기본적인 기능 개발 단계까지 도달하는데 필요한 기간일 뿐이고 본격적인 컨텐츠 입력을 통한 게임화 과정은 다음 마일스톤으로 넘어갈 만한 규모일 때가 많은데 보통 이를 잘 고려하지 않습니다.

마감은 약 2주 정도 잡습니다. 마감 첫주에는 실제로 기능 개발을 마쳐 기능을 발주한 주체 - 보통 기획팀의 누군가 - 에게 돌아가 기능과 에셋을 조립해 이제 겨우 테스트할 수 있는 상태로 만듭니다. 마감 둘째 주에는 이 상태로 QA에 넘어가 본격적으로 통합 테스트를 합니다. 아직 제대로 된 게임화 작업이 일어나지도 않았지만 문제는 수두룩하고 아무리 초과근무를 해도 마일스톤 마지막날까지 만족할만한 빌드를 만들어내기 어렵습니다. 마일스톤 마지막 날은 항상 월 최대근무시간에 걸려 출근하지 못한 사람들과 이 사람들에게 가야 할 이슈를 대신 처리하는 사람들의 허둥댐으로 가득합니다. 이제 토요일과 일요일이 지나고 월요일이 찾아오면 다시 다음 두 달 짜리 마일스톤의 첫날이 시작됩니다.

다시 원래 하려던 이야기로 돌아가 보겠습니다. 마일스톤 시작할 때 기획서가 완성되어 있으면 좋겠습니다. 기획자인 제가 생각해도 그러면 참 좋겠습니다. 마일스톤 시작하자마자 기획서를 협업부서에 리뷰하고 바로 개발을 시작하면 기획자 입장에서도 너무 좋습니다. 마일스톤 시작하자마자 바로 개발대응으로 넘어갈 수 있고 이전보다 훨씬 더 이른 시점에 개발이 진행되어 기능을 조립해볼 수 있을 뿐 아니라 더 이른 시점에 QA를 진행해 시간에 쫓기지 않아 기본 기능 뿐 아니라 이게 실제로 재미있긴 한지 의견을 들어볼 수 있을 뿐 아니라 운이 좋다면 실제 컨텐츠로 구성해 게임화하는 단계에까지 도달할 수 있을지도 모릅니다. 그러면 게임화 과정이 다음 마일스톤으로 넘어갈 필요도 적어지고 프로젝트 매니저의 ‘아니 이건 지난 마일스톤에 개발 끝난 거 아닌가요? 왜 이번 마일스톤에 또 진행하나요?’ 같은 질문에 답하거나 다음 마일스톤 계획에 ‘길드 2차’, ‘길드 3차’, ‘길드 4차’, ‘길드 추가개발’ 같은 멍청한 목표 이름을 넣지 않아도 될 겁니다.

악순환이 반복되는 원인을 크게 세 가지로 봅니다. 첫째. 폭포수 개발 관점에서 기획서 작성이 끝나면 기획팀이 할일이 끝났다고 보기 때문입니다. 실제로는 그렇지 않습니다. 기획서 리뷰가 끝나면 협업부서들의 피드백을 받아 수정하기 시작하고 협업부서들은 본격적으로 설계에 착수합니다. 여전히 문서를 수정하고 있고 협업부서들의 개발 진행에도 대응해야 합니다. 하루에 여러 차례 질의응답을 하고 테스트데이터를 만들고 그날그날의 개발 진척에 따라 단위테스트를 하는 등 여전히 할 일이 있습니다. 저는 이 단계를 ‘개발대응’이라고 불렀는데 이 개발대응이 실제로 기획팀의 자원을 소모하는 일임을 매니저에게 설득하기 굉장히 어려웠습니다. ‘아니 기획서 넘어가면 바로 다음 기획서 써야 하는 거 아니예요?’ 라는 말을 눈앞에서 육성으로 여러 번 듣고 나면 남은 수명만큼 세상을 살 의지가 꺾이곤 합니다. 이 작업이 실제로 프로그래머가 1근무일을 사용할 때 기획자는 최소한 0.2근무일은 사용한다고 측정, 증명해서 주장해도 잘 먹히지 않을 정도였습니다. 자. 이러는 사이에 일정표에 오늘 리뷰 끝나면 당장 내일부터 작성을 시작하는 걸로 계획된 다음 기획서 작성이 밀리기 시작했습니다.

둘째. 개발 후반 작업을 무시하기 때문입니다. 에셋이 준비되고 개발이 진행되어 테스트 가능하다는 상태로 기획자에게 작업이 넘어왔습니다. 높은 확률로 실제 빌드에서 테스트 가능하지 않은데 담당자가 자기 자리에서는 동작을 확인했겠지만 커밋 할 때마다 통합이 일어나는 환경에서 정상 동작하는지는 테스트하지 않기 때문입니다. 퍼포스 단일 스트림 환경에서는 서브밋 하고 CI에 의해 빌드가 돌고 나면 원하든 원하지 않든 이미 이 기능은 전체 빌드에 통합되어 있습니다. 이 상태에서도 과연 기능이 정상 동작할까요? 높은 확률로 그렇지 않습니다. 기획자에게 넘어온 작업을 테스트하기 위해 업데이트 받은 다음 첫 단위 테스트에서 바로 실패합니다. 안되는데요? 이렇게 일을 주고받는 사이에 반나절이 사라집니다. 자. 어떻게든 해서 간신히 동작하는 빌드가 기획자 손에 도착했지만 이제 마감에 맞춘 최소한으로 말이 되는 상태롤 만드는데 시간을 쓰기 시작합니다. 이 작업 역시 만만치 않은데 기획자에게 넘어온 동작은 하는 수준의 원시 기능은 기획자가 데이터를 입력해 구동해 봄에 따라 기초적인 문제들을 해결해야 하기 때문입니다. 컨텐츠를 조립하고 데이터를 입력해 나가며 차근차근 문제를 해결하는 사이에 며칠이 순식간에 지나갑니다.

셋째. 여러 작업자들이 멀티태스킹 환경에 놓여있다는 점을 무시합니다. 기획서 작성을 마치고 리뷰 대기 중인 기획자 입장으로 잠깐 돌아가 봅시다. 다른 일정, 휴가자 고려, 회의실 섭외 등의 문제를 해결하다 보면 리뷰 일정이 늦어집니다. 그러는 사이에 다음 기획서 작성으로 넘어갑니다. 사람의 주의력과 기억력은 한계가 있어 다른 주제로 넘어간 다음에는 다시 이전 주제로 돌아오는데 어려움이 있습니다. 이번 주 수요일에 작성한 기획서 리뷰가 다음 화요일 오전에 잡혔군요. 그 사이에 다른 기획서를 쓰다가 화요일 아침에 출근해서 리뷰할 문서를 보니 무슨 소린지 모르겠습니다. 오늘 리뷰를 순조롭게 진행하기는 쉽지 않을 것 같습니다. 위에서 이야기한 개발대응 이슈도 있습니다. 기획서를 쓰고, 다음 기획서를 쓰기로 예정된 시간에 개발대응을 합니다. 기획서 일정이 늦어지고 세상 평화로운 매니저는 왜 기획서 작성 일정이 늦어지는지 물어보러 옵니다. 협업부서에도 똑같은 일이 일어나고 있습니다. 통합테스트를 하기 전 상태를 급하게 기획팀에 돌려보낸 프로그래머는 바로 다음 작업을 시작합니다. 몇 시간 뒤 기획자가 아예 기능이 동작하지 않는다고 보고하지만 단일 스트림 환경에서 이미 다른 작업을 시작한 다음이라 수정하기가 까다롭습니다. 내일 고치겠다고 말하고 작업을 계속합니다.

주제와 상관 없어 보이는 이야기를 하며 멀리 돌아왔습니다. 기획팀 입장에서도 마일스톤을 시작할 때 기획서가 준비되어 있으면 좋겠습니다. 그럼 바로 개발대응으로 넘어가거나 이전 마일스톤에서 간신히 기본 기능만 만드는데 성공한 원시 기능들을 게임화하는데 시간을 쓸 수 있게 됩니다. 하지만 현실은 기획팀을 포함한 모든 부서가 소프트웨어 개발과정에 대한 몰이해, 실제 비용이 드는 작업 무시, 멀티태스킹 환경 미 고려 같은 문제로 이전 마일스톤이 끝날 때까지 다음 마일스톤 기획서는 고사하고 다음 마일스톤 목표가 뭔지에도 관심을 두기 어려운 환경에서 이 요구사항을 달성하기는 쉽지 않아 보입니다.

가상의 바쁜 개발팀을 상상해봤습니다. 마일스톤 목표는 서로 다른 자잘한 기능 목록으로 분리되어 있고 각 기능마다 기획팀 구성원들에게 할당되어 기획서를 작성하는 중입니다. 이번 마일스톤에 개발해야 하는 기능의 수는 기획팀 구성원 전체보다 더 많습니다. 하지만 각각의 기획서를 작성하는데 마일스톤 전체 기간이 필요하지는 않으므로 구성원 한 명이 연이어 서로 다른 기획서를 작성하게 됩니다.

회사마다, 프로젝트마다, 또 팀마다 정책이 다르겠지만 대략 기획서를 작성하고 나면 기획팀 내에서 확인 과정을 거쳐 기획서 작성 완료를 선언합니다. 그러면 담당 기획자가 직접 또는 조금 더 사정이 나은 팀이라면 PM이 리뷰 일정을 수립합니다. 리뷰는 주로 회의 형식으로 이루어지는데 기획서 내용을 담당 기획자가 브리핑하면 이 업무를 담당할 협업팀 구성원들이 질의응답을 하는 형식으로 이루어집니다. 아쉽게도 리뷰는 회의 시간에 주로 진행되므로 회의에서 피드백이 나왔다면 이를 반영하는데 시간이 더 필요합니다. 때때로 리뷰 회의에서 이 계획을 이대로 진행할 수 없다고 판단할 때도 있는데 이때는 이 기능 자체의 요구사항과 일정 등에 대한 재검토가 필요합니다.

여기부터 종종 슬픈 일이 일어나곤 하는데 개발 진행을 폭포수 방식으로 해석할 때 주로 이 슬픈 일이 일어나는 것 같습니다. 폭포수 관점에서 기획서 리뷰 회의는 기획서 작성이 완료되었음을 의미한다고 해석되곤 합니다. 하지만 실제로 리뷰 회의는 협업팀 구성원들이 이제부터 기획서가 제시한 목표에 대한 이해도를 올리기 시작하는 자리일 뿐이고 이 자리에서 제시된 반사적인 피드백 외에도 회의가 끝난 시점부터 본격적으로 여러 채널을 통해 피드백이 나오기 시작합니다. 이를 문서에 반영하는 일은 ‘문서에 한 줄만 추가하면 되는 일’로 쉽게 폄하되곤 하지만 실제로는 그렇지 않은 경우가 훨씬 많습니다. 피드백을 받아들이려고 보면 요구사항을 전면적으로 재설계해야 할 수도 있습니다. 하지만 전체 프로세스 상 이 기획서는 리뷰 단계를 거쳤으므로 작성이 완료되었다고 평가되므로 이 기획팀 구성원은 서둘러 다음 기획서 작성 업무로 진행해야만 합니다. 그렇지 않으면 꽉 짜인 일정을 준수하지 못하고 책임을 추긍당하게 될 겁니다.

사실 요구사항을 정의하는 단계가 이렇게 진행되면 안된다는 점을 이미 모두가 눈치채셨을 겁니다. 마일스톤을 구성하는 각 목표들이 팀 전체에 공유되어 이미 협업팀 구성원들 전체가 대략 무슨 일이 일어날 것인지 예상할 수 있어야 하고 각 요구사항을 기획서에 정의하기 전에, 또는 정의하는 과정에서 이미 결정된 협업팀 구성원들과 사전 협의를 거쳐야 합니다. 하지만 종종 이런 과정을 개개인의 역량으로 치부하곤 합니다. 실제로는 필요한 과정이지만 결코 공식적인 과정에는 드러나지 않습니다. 시간을 아껴 협업팀 구성원들과 사전 협의하는 자리 또는 회의는 분명 있지만 관리되지 않습니다. 이 과정을 거친 기획서는 리뷰 회의가 수월하게 진행되고 그렇지 않은 기획서는 리뷰 회의에서 종종 탈탈 털리게 됩니다.

기획서 리뷰 회의는 기획서의 완성 확인 및 구현 시작을 의미하지 않습니다. 공식적으로 리뷰 회의는 처음으로 요구사항의 실체를 협업팀 구성원들에게 알리는 자리일 뿐이며 기획서를 통한 요구사항 정의는 이제부터 시작합니다. 만약 리뷰 회의를 기획서 작성 완료라고 평가하고서도 그럭저럭 개발이 진행되고 있다면 분명 누군가는 공식적인 업무로 인정받지 못하는 사전 협의를 개인의 역량을 통해 수행하고 있을 가능성이 있다는 의미입니다. 이는 관리되지는 않지만 실제로 존재하는 과정을 일정 예측에 포함하지 않고 또 개발 과정을 개개인의 역량에 지나치게 의존하게 되어 위험합니다.

지난 ‘파괴적 행동 재확인’에 사용한 스크린샷의 ‘추출’ 버튼을 가만히 쳐다보다가 버튼에 적힌 필요 재화 종류와 재화량에서 멈췄습니다. 주로 게임에서 쓰는 방법입니다. 버튼 자체에 재화 종류와 가격을 직접 표시합니다. 다른 사례로는 버튼의 위쪽에 이 버튼을 터치할 때 사용될 재화 종류와 재화량을 표시하기도 합니다. 모든 게임이 항상 같은 정책을 사용하지는 않지만 제가 경험한 범위 안에서 행동 버튼과 행동에 필요한 재화 및 재화량을 표시하는 요령을 설명하겠습니다.

먼저 행동 버튼에 재화를 직접 표시할 때는 주로 행동에 필요한 재화가 게임의 주 재화에 가깝고 요구하는 재화 종류가 하나일 때입니다. ‘주 재화’는 게임에 가장 흔한 재화를 말합니다. 주로 ‘골드’일 겁니다. 게임의 여러 곳에서 보상으로 획득하며 여러 곳에 사용합니다. 이 주 재화는 워낙 흔하게 통용되어 아이콘을 보고 이 재화가 뭔지 바로 알 수 있습니다. 또 행동에 필요한 재화 종류가 하나여야 합니다. 사실 한 가지 행동에 재화를 둘 이상 사용하도록 설계하는 건 설계하다 보면 종종 필요할 때가 있지만 가능하면 회피해야 하는 설계이기는 합니다. 하지만 어쩔 수 없다면 한 가지 행동에 재화를 동시에 둘 이상 요구하기도 하는데 이 때는 버튼에 직접 재화를 표시하지 않습니다. 버튼 자체에 행동 이름, 둘 이상의 재화 종류와 요구량을 표시하려고 하면 이미 버튼이 길어져 인터페이스를 망칠 겁니다.

행동에 요구하는 재화가 게임의 주 재화와 거리가 멀고 요구하는 재화 종류가 둘 이상일 때는 행동 버튼에 직접 표시하는 대신 버튼 위쪽이나 버튼 근처에 표시합니다. 주 재화와 거리가 먼 재화는 특정 컨텐츠에서만 얻을 수 있고 게임의 특정 행동에만 사용하는 재화입니다. 이 그림에서 찾아본다면 불가사의한 수정이 있겠네요. 이런 재화는 골드만큼 흔하게 얻을 수도 없고 또 골드만큼 다양한 곳에 사용하지도 않습니다. 신경 쓰지 않고 플레이한다면 이런 재화가 있음을 이 재화를 사용할 때가 되서야 파악하게 될 수도 있습니다. 당연히 아이콘을 보고 무슨 재화인지 구분하지 못할 가능성이 있습니다. 그래서 이 재화 아이콘은 버튼 바깥에 있어야 하고 아이콘을 터치해 이 재화 이름이 뭔지, 어디서 얻을 수 있는지 등에 대한 정보를 얻을 수 있어야 합니다. 그래서 버튼 안에 들어갈 수 없습니다.

한번에 재화를 둘 이상 요구할 때도 행동 버튼 바깥에 재화 종류와 요구량을 표시해야 합니다. 위에서 잠깐 이야기했지만 행동 버튼은 상당히 좁은 공간입니다. 이 안에 재화 둘 이상을 표시하면 이미 인터페이스를 망가뜨리게 됩니다. 또한 근본적으로 이런 버튼은 모바일 환경에서 손가락으로 버튼을 가리게 되어 버튼에 들어있는 많은 정보를 받아들이기도 어렵습니다. 특히 각 재화 별로 현재 얼마나 가지고 있고 이 버튼을 터치한 다음에는 얼마나 남게 되는지를 파악하기는 상당히 어렵고 이 정도로 복잡하게 생긴 버튼을 터치하는데는 꽤 큰 용기가 필요합니다. 우리는 플레이어가 이 버튼을 터치하기를 원하므로 버튼 자체가 복집하지 않도록 해야 합니다. 그래서 둘 이상의 재화를 요구할 때 버튼 바깥에 표시합니다.

마지막으로 요구 재화가 하나이더라도 이 재화가 ‘횟수 제한’에 가까운 속성을 가질 때 버튼 바깥에 표시합니다. 가령 주간 입장횟수가 3번으로 제한된 던전이 있다면 이 던전 입장 버튼에 이를 직접 표시하지 않습니다. 대신 버튼 위쪽 또는 다른 어딘가에 ‘3 / 3’이라고 표시합니다. ‘입장 가능 횟수 / 기간 당 최대 입장 가능 횟수’인데 이 표현을 버튼 안에 직접 넣지 않는 이유는 위에서 설명한 것과 비슷합니다. 버튼이 누르기 무섭게 변하고 더 많은 공간을 요구해 인터페이스를 망가뜨리며 이미 버튼 안에 들어있어 터치에 의한 추가 설명을 할 수 없기 때문입니다.

지난번에 '내가 노션을 싫어하는 이유'를 소개한 적이 있습니다. 비슷한 시기에 트위터를 통해 컨플루언스를 개인적으로 활용하는 이유와 장단점을 소개한 적이 있는데 시간이 지나고 보니 이 상태로 두면 균형이 잘 안 맞는다는 생각이 들었습니다. 어쩔 수 없이 노션도 컨플루언스도 적극적으로 사용하는 입장에서 한쪽의 단점만 이야기해 놓고 아무것도 안 하고 있는 건 문제가 있다는 생각이 들었습니다. 그래서 오늘은 제가 컨플루언스를 싫어하는 이유를 소개합니다.

일단 가격이 싸지 않습니다. 프리미엄 버전은 세금을 제외하고 월 10.5달러인데 파일 스토리지를 무제한으로 사용할 수 있고 완전관리되기는 하지만 비슷한 수준의 노션 퍼스널 프로는 월 4달러입니다. 노션이 컨플루언스의 반값보다 쌉니다. 또 컨플루언스는 마켓플레이스에서 플러그인을 구독해 사용할 수 있는데 널리 알려진 플러그인들은 가격이 낮거나 10명 이하 사이트에 무료로 제공되지만 그렇지 않은 플러그인도 있습니다. 유료 플러그인을 붙이면 월 지출 비용이 순식간에 높아질 수 있습니다.

지난번 노션 이야기 할 때도 지적했는데 컨플루언스도 마찬가지로 검색이 충분하지 않습니다. 노션에 비해서는 검색 결과를 전체 페이지에 보여줘 검색 결과로부터 힌트를 얻거나 검색을 재시도할 여지를 충분히 주기는 하지만 띄어쓰기 없는 합성어의 일부가 잘 검색되지 않습니다. 때문에 이 사실을 알고 있는 상태에서 문서를 작성하면 일부러 합성어에 띄어쓰기를 하거나 명사와 조사의 조합에서 명사를 인용부호로 감싸곤 하는데 썩 좋은 경험이 아닙니다. 흥미로운 점은 지라는 합성어의 일부만 검색할 수 있다는 점입니다.

미디어를 처리하는 방법이 많이 낡았습니다. 플러그인을 추가해 많은 이미지에는 갤러리를 사용할 수 있기는 하지만 이 정도는 기본 기능이 대응해야 한다고 생각합니다. 영상으로 넘어가면 상황은 좀 더 나빠집니다. 가령 mp4 파일을 첨부하면 그럭저럭 웹 플레이어에 예쁘게 보여주지만 mov 파일을 첨부하면 끔찍한 모습이 됩니다. 그럭저럭 볼만하게 보여주는 미디어 타입과 그렇지 않은 미디어 타입들이 있어 문서 모양을 그나마 봐줄만한 모양으로 만들고 싶다면 미디어 파일을 직접 첨부하는 대신 변환한 다음 첨부해야 합니다. 만약 이 도구가 로컬에서만 돌아간다면 납득할 수도 있겠지만 이 도구는 웹에서 동작하며 클라이언트 환경에 독립적으로 돌아가야 한다는 점을 감안하면 납득하기 어렵습니다.

문서 간의 연결관계가 지라만큼 정교하지 않습니다. 한 문서에서 다른 문서의 링크를 언급하면 이들은 자동으로 들어오는 링크와 나가는 링크로 구분되어 페이지 정보에서 확인할 수 있게 되는데 이게 전부입니다. 사실 전통적인 위키 역시 백링크를 표시하는 수준에 머물고는 있지만 규모가 큰 위키를 만드는데 사용하도록 디자인 된 제품이 아직도 문서 간 연결 관계를 전통적인 위키 수준으로밖에 제공하지 않는 점은 아쉽습니다. 반면 자매 제품인 지라에서는 태스크 사이에 관계를 설정할 때 이 관계의 맥락을 설정할 수 있습니다. 가령 한쪽이 다른 쪽의 진행을 방해한다거나 중복되었거나 그저 관계가 있다는 등으로 설정할 수 있습니다. 이 요구사항을 만족하기 위해 지라에 함께 의존하게 됩니다.

문서는 퍼블리시 버튼을 클릭하지 않아도 서버에 자동 저장되지만 여러 문서를 중간 편집하고 있을 때 중간 저장 상태인 문서를 찾기 어렵습니다. 특히 한번도 발행한 적이 없는 문서는 문서 트리에 나타나지 않습니다. 대시보드에서 ‘편집 중인 문서’목록에 나타나는데 이곳 이외에는 어디에도 나타나지 않습니다. 그래서 여러 문서를 한번에 발행해야 할 때는 개인공간에서 발행을 반복해가며 작성한 다음 이를 공개된 공간으로 옮기거나 복사해서 붙여넣기도 하는데 방법에 따라 또 다른 여러 단점으로 이어집니다.

이것도 규모가 큰 사이트를 운영하는데 부족한 점이라고 생각하는데 모든 문서는 ‘문서’ 단위로만 관리됩니다. 같은 목적을 달성하기 위해 여러 문서를 함께 수정해도 이들이 ‘같은 목적’을 위해 수정되었음을 표시할 방법이 없습니다. 위에서 잠깐 이야기한 ‘같은 목적’에 해당하는 지라 태스크에 의존하거나 태그를 사용할 수는 있지만 이들이 히스토리 화면에는 나타나지 않으므로 같은 목적에 의해 수정된 문서들의 맥락을 보존하려면 다른 문서를 만들어 관리해야 합니다.

노션의 강력한 특징인 데이터베이스를 직접 지원하지 않습니다. 최근에 플러그인이 발표되면서 이 요구사항을 좀 충족할 수 있게 됐습니다. 이전까지는 상당히 낡았고 사용하기 어려운 페이지 프로퍼티 매크로를 사용해야만 했습니다. 하지만 여전히 컨플루언스가 기본으로 지원하는 기능이 아니어서 노션 수준으로 컨플루언스 본체에 잘 통합되어 동작하는 상태는 아닙니다.

‘사이트 전체 백업’을 제외한 모든 종류의 배치 익스포트가 정상 동작하지 않습니다. 컨플루언스는 원래 서버에 설치하는 제품에서 클라우드 제품으로 변했는데 과거 서버 제품일 때 사용하던 사이트 전체 백업 기능이 아직 클라우드에도 남아있습니다. 기본적으로 클라우드 제품은 백업 관리와 재해 복구 역시 서비스 주체가 스스로 관리해야 하는데도요. 다행히 이 기능은 정상 동작합니다. 제 경우에는 백업을 요청하면 거의 이틀이 지난 다음 거대한 zip 파일 하나를 던져줍니다. 그런데 이 기능을 제외한 다른 (거의) 모든 배치 익스포트 기능이 동작하지 않습니다. 오프라인에서 찬찬히 살펴볼 목적으로 스페이스 전체를 HTML로 익스포트 할 수 없습니다. 분명 기능이 있고 익스포트를 시작할 수는 있지만 영원히 끝나지 않습니다. 비슷한 모든 익스포트 기능이 동일한데 이 관련 지라 태스크가 만들어진지 몇 년이 지났지만 수정되지 않고 있습니다.

지라에는 이미 지원하며 원래 로드맵 상으로 작년 3분기에 지원 예정이던 오토메이션을 아직 지원하지 않고 있습니다. 지라는 거의 오토메이션 이전과 이후로 구분할 수 있다고 생각합니다. 오토메이션을 통해 여러 반복 작업을 드라마틱하게 줄일 수 있고 사람의 기억에 의존하는 작업들을 외부화 및 자동화할 수 있었습니다. 물론 찬찬히 생각해보면 지라에 비해 비정형 데이터를 다루는 컨플루언스에는 비슷한 수준의 오토메이션을 제공하는 일이 그리 간단하지 않을 거라는 점은 이해하지만 이전 로드맵에서 이제 거의 1년째 늦어지고 있습니다. 프로젝트 관리 측면에서 아쉽습니다.

모바일 지원이 형편없습니다. 상당수 매크로가 모바일에서 동작하지 않습니다. 모바일 앱은 편집이 기능하기는 하지만 거의 뷰어로밖에 사용할 수 없는데 그나마 모바일에서 동작하지 않는 매크로를 별도 브라우저를 통해 사용할 수 있게는 해줍니다. 그 모양이 여전히 형편없기는 하지만요. 구글 서치 콘솔에 등록해 테스트해보면 모바일 친화적이라고 뜨는 점이 그나마 위안이 되지만 실제로 모바일에서 페이지를 사용해보면 내비게이션이 불가능해 ‘그 페이지 자체’를 읽는 것 외에는 사용할 수가 없습니다.

마지막으로 기대한 만큼 안정적이지는 않은 것 같습니다. 체감 상 한달에 한 번은 다양한 형태로 서비스 중단을 겪는 것 같습니다. 어느 날은 읽기만 되고 쓰기가 안된다거나 어느 날은 사이트 전체가 느려진다거나 합니다. 사이트 전체가 완전히 사용 불가능하게 되는 일이 드물긴 하지만 이런 자잘한 장애를 생각하면 이들이 SLA를 보장하고 있는지 조금 걱정스러울 때도 있습니다. 당장 이 글을 쓰는 지금도 팀캘린더가 약간 고장났는데 이건 언제 고쳐줄지 모르겠습니다.

굳이 게임 뿐만이 아니라 컴퓨터를 사용하다 보면 중요한 결정을 내릴 일이 많습니다. 메일을 삭제할지 말지 결정하거나 물건값을 결제할지 말지 결정하는 일이 대표적입니다. 또 모두가 하는 거짓말로 ‘약관을 모두 읽었으며 동의합니다’ 버튼이나 체크박스를 누르는 일도 마찬가지입니다. 이런 행동은 이후 만드는 사람이나 사용하는 사람 모두에게 큰 영향을 끼치기 때문에 중요합니다. 그래서 귀찮지만 한번 더 묻곤 합니다. ‘정말로 삭제하시겠습니까?’라고요. 하지만 어떤 동작에 이렇게 다시 물어야 할 지 명확하지 않기 때문에 어떤 앱들은 작은 행동 하나하나에도 정말 그 행동을 할 지를 다시 묻기도 하고 그 반대 경우도 있습니다. 누군가 게임을 하다가 ‘어??!!?!?’ 하고 외친다면 당연히 한번 더 확인을 할 거라고 예상한 어떤 행동이 확인 없이 바로 수행되어 버렸을 겁니다.

이런 재확인을 똑똑하게 하는 여러 가지 방법이 있는데 그 중 하나는 동작을 되돌릴 수 있게 하는 겁니다. 메일을 지울지 말 지 물어보는 대신에 일단 지운 다음 휴지통에서 다시 꺼낼 수 있게 하면 삭제 행동을 재확인 할 필요도 없고 사용자가 뭔가 잘못 되었음을 느낄 때 심박이 올라가지 않도록 할 수도 있습니다. 게임에서는 상점에 ‘되사기’ 기능이 있습니다. 내 인벤토리에는 여러 아이템들이 있는데 이 중에는 상인에게 팔거나 분해해야 할 아이템부터 지금 당장은 장착할 수 없지만 2레벨 뒤에는 장착할 수 있게 될 전설 아이템이 섞여 있습니다. 상인에게 아이템을 팔 때 별 생각 없이 인벤토리에 장비 전체를 선택해서 팔아버리는 순간 전설 아이템을 팔아버렸다는 사실을 깨닫게 되면 머릿속이 하얗게 변할 겁니다. 이런 상황을 대비해 화면 어딘가에 상인의 인벤토리를 보여주고 일정 기간 동안 내가 팔았던 아이템을 보여줍니다. 실수로 팔면 안되는 아이템을 팔아버렸다면 상인으로부터 아이템을 되살 수 있습니다. 다행입니다.

게임마다 여러 접근방법을 사용합니다. 내 인벤토리에서 팔아야 할 아이템을 선택할 때 아이템의 등급에 따라 일괄선택하는 기능을 제공하기도 합니다. 이 일괄선택에는 의도적으로 전설 등급을 선택할 수 없게 되어 있습니다. 이 일괄선택을 통해서는 전설 등급 아이템을 의도하지 않게 팔아버리는 실수를 하기 어렵습니다. 애초에 전설 등급은 상점에 팔 수 없기도 합니다. 고급이나 희귀 아이템은 상점에 팔거나 대장장이에게 분해하지만 전설은 아예 다른 NPC의 다른 기능을 통하게 합니다. 사실 이건 실수를 대비한 기능이라기보다는 전설 아이템이 플레이어캐릭터의 성장에 다른 방식으로 영향을 끼치게 만들기 위한 장치이기는 합니다. 하지만 여전히 실수에 대비하는 기능으로도 잘 동작합니다.

최근에 경험한 ‘정수 추출’ 인터페이스를 살펴보면 파괴적 행동을 수행하기 전에 실수를 방어하는 메커닉을 볼 수 있습니다. 이 사례에서 정수 추출은 사용하지 않을 전설 아이템을 없애는 행동입니다. 이미 정수 추출을 담당하는 NPC는 다른 기능과 완전히 분리되어 있어 다른 행동과 헛갈릴 가능성이 낮지만 전설 아이템을 함부로 선택할 수 없게 만들어져 있습니다. 정수를 추출할 아이템을 선택해야 하는데 이 때 내 인벤토리 전체를 보여주는 대신 전설 아이템만 필터링한 별도 리스트를 보여주고 이들 중 하나를 선택하게 되어 있습니다. 물론 이 인터페이스에서는 이것으로도 충분하지 않다고 생각했는지 ‘추출’ 버튼을 클릭하면 팝업을 띄워 한번 더 확인합니다. 그 다음에야 전설 아이템을 파괴합니다.

이 사례에서 정수 추출 기능은 실수를 방지하도록 크게 세 단계로 구성되어 있습니다. 첫째. 정수 추출은 완전히 분리된 NPC가 수행합니다. 이미 기능이 많은 대장장이에 섞여 있지 않습니다. 둘째. 아이템을 선택할 때 표준 인벤토리가 아닌 전용 리스트를 보여줍니다. 표준 인벤토리를 보고 플레이어가 반사적으로 할 행동에 대항합니다. 셋째. 마지막 단계에서 전통적인 팝업을 띄워 한번 더 행동을 확인합니다. 그저 ‘정말 정수를 추출하시겠습니까?’ 한 단계로 실수에 대항하는 것 보다 훨씬 나은 접근이라고 생각했습니다.

반복해서 플레이 해야 하는 던전을 만들었다면 이 던전을 반복해서 플레이 하기 위한 편의기능을 함께 만들어야 합니다. 전통적인 MMO에서는 여러 기능을 담당하는 NPC들이 마을에 모여있습니다. 장비를 분해하거나 업그레이드 하는 일은 대장장이가 해야 할 것 같고 보석을 제작하거나 분해하거나 업그레이드 하는 일은 세공사가 해야 할 것 같습니다. 포션 같은 소모품 역시 상인이 해야 할 것 같네요. 이들은 모두 NPC로 표현됩니다. NPC는 일단 사람에 가까우니 마을에 모여 있어야 할 것 같네요. 이 마을에는 이 NPC들의 기능을 사용할 다른 플레이어캐릭터들이 모여 있습니다. 사실 이런 전통적인 마을의 모습이야말로 MMO 게임이 지향하는 모습 중 하나라고 할 수 있다고 생각합니다.

현대에 가까워질수록 MMO 게임의 지향점이 조금씩 달라졌는데 점점 더 최상의 컨텐츠에 PvP를 배치하고 있습니다. 최상위에 PvP가 배치되어 있으면 만드는 입장에서 큰 장점이 있습니다. 결정적으로 플레이어들의 수직 성장에 따른 컨텐츠를 계속해서 개발할 부담을 덜 수 있습니다. 한때 플레이어들의 수직 성장에 발맞춰 분기마다 대규모 업데이트를 하던 시대도 있었습니다. 하지만 만드는 사람들은 결코 플레이하는 사람들의 속도를 감당할 수 없었고 아무리 초과근무를 해도 ‘할 게 없다’는 피드백을 받을 수밖에 없었습니다. 반면 최상의 컨텐츠를 PvP로 만들면 수직 성장 시스템을 관리하고 플레이어들 간의 밸런스를 조정하며 신규 스킬 출시 같은 수평성장을 관리하며 이전에 비해 더 섬세함이 필요하지만 대규모 물량은 상대적으로 덜 필요하도록 개발 방식을 바꿔 운영할 수 있습니다. 물론 이 방법이 전통적인 물량에 비해 쉽다는 이야기는 전혀 아닙니다.

그러면서 게임을 크게 성장구간과 상위 컨텐츠로 구성하게 되었는데 다시 성장구간은 메인퀘스트와 특정 던전의 반복 플레이로 구성됩니다. 전통적인 MMO에서는 필드와 던전을 모두 퍼시스턴트 공간으로 만들어 놓고 반복 사냥을 하게 만들었다면 어느 시점부터는 던전을 인스턴스 공간으로 만들어 반복 플레이를 하게 했는데 만드는 입장에서 효율이 좋은 편이었습니다. 인스턴스 공간은 싱글플레이와 비슷해 보상 수준을 조절하기도 편하고 실수가 게임 전체에 급속도로 퍼지는 일도 줄일 수 있었으며 플레이어 입장에서도 성장의 복잡성을 줄일 수도 있었습니다. 대신 플레이어 입장에서 같은 던전을 반복해서 돌아야 하게 됐고 만드는 입장에서는 이를 최대한 편하게 만들 필요가 생겼습니다.

균열은 성장구간에서 일정 수준 이상의 장비와 보상을 갖출 때까지 반복해서 돌아야 하는 던전 컨텐츠입니다. 던전을 클리어 하고 나면 대장장이가 스폰되는데 균열 입구가 배치된 서부원정지에서 대장장이는 30초 이상 걸어가야 하는 광장에 있고 인벤토리 크기에는 제한이 있어 던전을 연속으로 플레이할 수 없는 상황을 없애기 위한 편의 장치입니다. 이 대장장이는 마을에 있는 대장장이와 달리 분해 기능만 가지고 있습니다. 오직 던전을 연속해서 돌 때 의미있고 실제 대장장이에게 필요한 기능을 사용하려면 플레이를 멈추고 광장으로 이동해야만 합니다. 단순하지만 게임 플레이를 망가뜨리지 않고 또 설정 상 크게 이상해 보이지도 않습니다.

한번은 반복해서 플레이 할 던전을 개발하면서 이런 편의 장치를 만들고 싶었습니다. 비슷한 상황이었습니다. 던전 입구는 마을에서 멀리 떨어져 있었고 던전을 플레이 할 때마다 인벤토리에 보상이 쌓였습니다. 인벤토리를 비우고 포션을 구입하기 위해 반복 플레이 중간에 플레이를 멈추고 마을로 돌아가야 했는데 마을까지는 순간이동 해서 로딩만 거치면 바로 이동할 수 있었지만 이 반복 플레이를 깨고 싶지 않았습니다. 그래서 분해 기능을 넣으려고 했는데 다른 게임은 위 사례처럼 단순하게 해결하고 있었지만 정작 우리들이 해결하기에는 그리 간단한 문제가 아니었습니다. 대장장이 NPC를 배치하자니 설정에 맞지 않았습니다. 우리의 대장장이는 특정 마을에만 있어야 했습니다. 새로운 대장장이를 만들어내기에는 비용이 너무 높았습니다. 현대 MMO처럼 상당히 많은 기능을 NPC 대신 인터페이스로 만들기에는 인터페이스가 이미 충분히 복잡했고 분해 기능이 던전에서만 인터페이스에 나오는 것도 굉장히 작위적이었습니다.

온갖 문제에 부딪친 끝에 던전은 반복 플레이를 요구했지만 인벤토리가 가득 차면 마을에 돌아가야 하게 됐습니다. 문득 던전 끝에 있는 대장장이와 마을로 돌아가는 포탈을 터치할 때 나타나는 ‘던전 입구로 돌아가기’와 ‘주요 성장 NPC들이 있는 광장으로 이동하기’ 버튼이 화면을 가득 채우는 것을 보며 이 결정은 왜 그렇게 어려웠을까 하는 생각을 하며 바로 이어서 다음 던전 플레이를 시작했습니다.

지난번에 던전 클리어 후 타이머에 대한 이야기를 하다가 던전 입장횟수 차감 이야기가 잠깐 나왔습니다. 클리어 한 던전에서 플레이어들을 쫓아내야 하는 이유 중 하나는 단위 기간 안에 입장 횟수가 정해져 있는 던전에 들어간 다음 나오지 않고 버티며 던전 입장횟수 초기화 경계를 지난 다음 던전에서 나오면 던전 입장횟수를 던전에서 나오는 시점에 차감할 경우 문제가 생긴다는 이야기였습니다. 이건 던전 입장횟수를 어느 시점에 차감해야 하는지에 대한 문제인데요, 몇 가지 접근방법을 늘어놓겠습니다.

먼저 가장 전통적인 던전에 입장할 때 차감하는 방법입니다. 플레이어 입장에서도 직관적이고 만드는 입장에서도 단순합니다. 가장 전통적인 방법입니다. 단순한 반면 문제도 있는데 만약 던전을 플레이 하던 도중 원하지 않게 던전을 클리어 할 수 없는 상황이 일어나면 입장횟수를 날리게 됩니다. PC MMO 시대에는 던전 세션이 지금보다 훨씬 길었기 때문에 이런 일이 자주 일어났습니다. 문제를 완화하기 위해 파티 플레이로 던전에 들어가 누군가 튕기면 나머지 인원이 던전을 유지하고 있다가 다시 초대해서 플레이를 이어가기도 했습니다. 시간이 흘러 성장구간 던전이 싱글플레이 위주로 재편되고 모바일 환경으로 넘어오면서 던전 세션은 이전에 비해 훨씬 짧아졌지만 여전히 전화가 걸려온다든지 앱이 크래시된다든지 네트워크 순단이 일어난다든지 하는 온갖 이유로 던전을 클리어 하지 못하면 입장횟수가 사라집니다.

여기서 잠깐 입장횟수가 사라지는 문제에 왜 예민하게 대응해야 하는지 잠깐 이야기하면 성장구간에서 던전 입장횟수는 시간과 보상의 교환수단 역할을 하기 때문입니다. 던전 입장권 아이템이 있다면 이 아이템은 단순한 입장권이 아니라 던전을 클리어한 다음 받을 수 있는 기대 보상과 동일합니다. 입장권은 곧 전설 아이템입니다. 플레이어는 입장횟수와 시간을 투입해 보상을 얻어 성장합니다. 현대 MMO 게임들은 최상위에 PvP 컨텐츠를 배치한 경우가 많아 이런 시간에 따른 기대보상 교환수단은 이전에 비해 훨씬 더 중요하며 이런 보상을 플레이어가 의도하지 않은 이유로 얻지 못하는데 훨씬 민감하게 반응할 수밖에 없습니다.

두번째 방법은 던전이 클리어 될 때 차감하는 방법입니다. 던전에 입장해도 입장횟수나 입장재화를 차감하지 않습니다. 던전을 끝까지 플레이한 다음 던전을 클리어하는 시점에 차감합니다. 여기서 다시 어떤 상태를 던전 클리어로 볼 것인지를 결정해야 하는데 보통 던전 보스로 설정된 몬스터가 죽을 때를 클리어 시점으로 삼습니다. 만약 던전을 플레이하다가 전화가 걸려 와서 긴 통화를 마치고 돌아와보니 클라이언트가 종료되어 던전을 클리어하지 못하게 됐다고 칩시다. 이번에는 던전 입장횟수가 아직 차감되지 않은 상태입니다. 앞서 던전을 플레이하는데 사용한 시간이 조금 아깝기는 하지만 다시 한 번 시도할 기분이 듭니다. 게다가 던전 세션이 그리 길지 않으므로 부담이 크지도 않습니다. 반면 이 방법은 만드는 사람 입장에서는 썩 단순하지 않은데 던전 안에 있는 몬스터들이 필드보다 높은 보상을 주도록 설정했다면 마음이 불편할 겁니다. 던전 입장횟수가 보스를 처치할 때 차감된다는 점에 집중해 던전을 보스 앞까지만 플레이한 다음 던전을 나가기를 반복하면 필드 사냥에 비해 더 많은 경험치를 얻을 수 있습니다. 사실 현대 모바일 게임의 던전은 시간과 입장권을 보상으로 바꿔주는 형태이므로 보스 이외의 몬스터들은 보상을 거의 주지 않고 단지 시간을 소모시키는 역할을 하도록 설정해서 이런 문제를 회피할 수 있습니다.

마지막으로 던전에서 핵심 보상을 획득한 시점에 차감할 수도 있습니다. 게임을 플레이 할 때 온갖 문제가 생깁니다. 가령 보스를 처치했는데 보스 뒤에 스폰된 보상 상자를 열기 전에 클라이언트가 크래시되거나 네트워크 순단이 일어났을 때를 생각해 보겠습니다. 이번에는 심지어 보스도 처치했지만 입장횟수는 횟수대로 차감되고 보상은 보상대로 못 받았습니다. 이번에야말로 이 플레이어는 카페에 무서운 글을 남기거나 앱스토어에 별 하나를 주며 리뷰에 ‘보상 드랍도 똑바로 안되는 쓰레기 똥껨’이라고 쓸 것 같습니다. 그래서 던전에 설정된 핵심 보상을 획득하는 시점에 던전 입장횟수를 차감하기도 합니다. 위에서 던전이 클리어된 시점을 결정하기 위한 조건으로 삼을 던전 보스를 설정한다고 했는데 이번에는 특정 보상을 설정하는 식입니다. 이 보상을 플레이어캐릭터가 획득하면 던전이 클리어 된 것으로 판단하고 입장횟수를 차감합니다. 이 방법도 구린 면이 있습니다. 보스를 처치하는 순간 던전을 클리어했다는 플레이어의 기분을 좋게 만들 메시지를 뿌리고 싶은데 내부적으로는 아직 던전이 클리어되지 않은 상태입니다. 던전이 클리어되지도 않았는데 클리어 메시지를 뿌리는 건 겉보기에는 괜찮아 보이지만 이렇게 동작한다는 사실을 알고 있는 입장에선 영 불편한데다가 이렇게 화면에 표시되는 동작과 실제 동작이 다르면 또 다른 문제가 일어나기 십상입니다.

최근에 본 동작은 던전을 클리어하지 않고 종료하면 던전 입장에 사용한 재화를 우편을 통해 돌려주는 것입니다. 이 사례에서 던전 입장재화는 던전에 입장할 때 차감되지만 던전 보스를 처치하지 않고 던전을 끝내면 우편을 통해 재화를 돌려줍니다. 또한 보스를 처치한 다음 드랍되는 보상을 안 먹고 던전을 끝내면 ‘분실물’ 우편을 통해 내가 안 먹고 나온 보상을 보내줍니다.

오래 전에 MMO 게임에서 인스턴스 던전을 플레이한 기억을 떠올려봤습니다. 이 시대의 던전은 현대에 비해 꼼수를 사용할 여지가 더 많았습니다. 가령 던전 내부 공간은 서로 길게 연결되어 있어 한번 지나간 길을 다시 돌아올 수 있었습니다. 여기에 몬스터들의 추적 거리가 아주 넓게 설정되어 있어 만약 몬스터들을 상대하기 벅차면 던전 길이 전체를 이용해 몬스터를 먼 곳까지 끌고 다니며 긴 시간을 들여 천천히 상대할 수도 있었습니다. 플레이어를 공간 안에 고립시키는 ‘보스룸’ 개념이 확립되기 이전에는 보스조차도 비슷한 방법으로 플레이 할 수 있었습니다.

이렇게 긴 시간을 들이는 플레이를 플레이어들만 사용하는 것은 아니었습니다. 개발자들 역시 던전 플레이어들이 얼마나 긴 시간을 투자해야 할지 현대보다 훨씬 덜 신경 쓴 것 같습니다. 플레이어들이 던전에서 몇 시간을 쓰든 던전을 설정에 맞도록 길고 어렵게 만들었습니다. 덕분에 던전을 함께 클리어한 플레이어들의 경험은 깊은 추억이 되어 게임에 더 깊게 몰입하게 만들곤 했습니다. 플레이어들은 보스가 사라진 적막한 던전 안에서 모여 스크린샷을 찍고 바로 나가기 아쉬워 채팅을 하며 머물기도 합니다.

어느 시점부터인가 던전을 클리어 하고 나면 타이머가 나타나 그 시간이 지나면 던전 밖으로 쫓겨났습니다. 다시 들어갈 수 있으니 딱히 쫓겨났다고 하긴 뭣 할 수도 있지만 내 의지와 관계 없이 시간이 끝나면 나가야 하니 쫓겨났다고 해도 크게 이상하지는 않다고 생각합니다. 이전 시대에 인스턴스 던전은 나와 우리 파티가 온전히 소유한 공간이었다면 클리어 하자마자 타이머가 나타나 남은 시간을 보여주는 던전은 마치 노래방 기계의 타이머 마냥 보는 사람을 불안하게 만듭니다. 사실 현대의 모바일게임에 던전은 이전 시대에 비해 한 세션이 훨씬 짧고 경험은 이전 시대에 비해 훨씬 옅습니다. 때문에 내가 던전 안에 머물 미련이나 이유가 별로 없기는 합니다. 또 게임을 구동하는 기계는 정보통신기기 역할을 해야 하니 던전 안에 머물기보다 다른 앱으로 전환할 일이 훨씬 많기도 합니다. 이 타이머가 필요한 정확한 이유는 저도 잘 모르겠습니다. 하지만 개발하면서 추측한 이유는 크게 두 가지 입니다.

첫째. 동시에 유지할 수 있는 인스턴스 던전 갯수에 제한이 있습니다. 흔히들 ‘게임 서버’ 하면 기계 한 대를 생각할 수 있지만 실제로는 수많은 서버들로 이루어진 ‘서버 군’을 서버 하나로 부릅니다. 이 안에는 로그인 서버, 게임 서버, 데이터베이스 서버, 던전 서버 등 여러 역할을 하는 서버가 포함되는데 이들 중 던전 서버가 있습니다. 이들은 주요 던전 인스턴스를 실행하는데 모든 던전 플레이어들에게 적당한 수준의 응답을 하려면 한 던전 서버 군이 호스팅 할 수 있는 최대 던전 수에 제한을 둬야 합니다. 그렇지 않으면 던전 안에서 몬스터들의 응답이 늦어져 플레이 경험을 망가뜨립니다. 만약 던전이 시간 제한 없이 계속해서 유지될 수 있고 유저들이 던전 안에 들어가 나오지 않게 되면 던전 서버에 던전이 누적되어 던전 서버가 호스팅하는 던전 전체에 영향을 끼칠 수 있게 됩니다. 그래서 던전 서버 군이 호스팅하는 던전 갯수를 통제하기 위해 클리어 된 던전을 일정 시간이 지나면 없애 전체 던전의 성능을 유지합니다.

둘째. 기간 당 진입 횟수에 제한이 있는 던전의 횟수 제한을 통제하기 위해서 입니다. 가령 일주일에 한 번만 들어갈 수 있는 던전이 있다고 합시다. 이제 던전 입장 횟수를 언제 셀 것인지 정의해야 합니다. 던전에 입장하면 횟수를 차감할 수 있습니다. 그런데 던전 플레이 중에 뭔가 문제가 일어나 던전을 클리어하지 못하면 억울하게 입장횟수 한 번을 날린 셈이 됩니다. 모바일에서는 특히 이런 일이 일어날 가능성이 높습니다. 아직 던전을 클리어하지 못한 상태에서 전화가 왔고 통화가 길어지는 사이에 게임 앱이 종료된다면? 재접속 할 때 바로 앞에서 이야기한 이유 때문에 던전이 사라졌을 수 있습니다. 그럼 이제 이번 주에 이 던전에 더이상 입장할 수 없게 됐군요. 만약 이 던전이 성장 크리티컬한 던전이라면 이 플레이어는 분노에 가득 차 카페에 무서운 글을 남길 겁니다.

상당수 게임 서비스들은 매주 특정 요일에 정기점검을 하는데 이 때 모든 플레이어들의 접속을 종료시킵니다. 이 때 주 단위로 동작하는 카운터들도 함께 초기화됩니다. 일주일에 한 번만 들어갈 수 있는 던전은 이 때 횟수가 초기화 됩니다. 그런데 만약 게임을 서비스 한 지 오래 되어 몇 주에 한 번만 정기점검을 해도 되거나 데이터 패치 정도는 무중단으로 할 수 있다면 오히려 문제가 생깁니다. 누군가 던전에 들어가서 일주일 내내 나오지 않고 있습니다. 이 상태로 주 단위의 횟수들의 초기화 시점을 통과합니다. 그런데 우연히 던전 횟수 차감을 ‘던전에서 보상을 획득할 때’ 또는 ‘던전을 나갈 때’로 설정했다면 문제가 될 수 있습니다. 나는 지난 주에 던전에 들어가서 이번 주에 나왔는데 횟수 차감은 이번 주 횟수가 차감 됐기 때문입니다. 나는 지난 주에 던전을 플레이 했을 뿐인데 이번 주에 플레이 할 수 없게 됐습니다.

서버의 무중단 여부와 관계 없이 이런 상황을 근본적으로 없애기 위해 던전의 최대 유지 시간을 제한하고 클리어 된 던전의 유지 시간 역시 제한합니다. 가령 클리어 하는데 10분이 걸릴 것으로 예상하는 던전이 있다면 던전의 최대 유지 시간은 약 60분 가량으로, 클리어 후 유지 시간은 약 5분으로 설정합니다. 이제 한 주 단위로 입장 횟수를 통제하는 던전 인스턴스가 오랫동안 남아 이상한 문제를 일으키지 않게 됐습니다. 동시에 오래된 게임의 던전에서 느끼던 추억도 함께 사라지게 됐네요. 하지만 크게 걱정하지 않아도 됩니다. 현대의 모바일 MMO 게임들은 현대인들의 조각난 시간에 맞춰 던전 한 세션의 길이를 점점 더 줄이고 있습니다. 이전 시대처럼 던전에서 몇 시간씩 플레이하고 중간에 멈춰 다 같이 밥을 먹고 다시 모일만큼 긴 던전은 더이상 만들지 않습니다. 대신 점심시간에, 화장실 다녀오다가, 출퇴근 사이에 잠깐씩 던전 한 바퀴를 돌 수 있게 됐습니다. 장단점이 있다고 생각하고, 또 이게 제가 알고 있는 던전을 클리어 한 다음 플레이어들을 쫓아내는 장치가 있는 이유입니다.

개인적으로 디아블로3의 아트 스타일을 썩 좋아하지 않습니다. 왜 그런 스타일을 선택했는지 머리로는 이해하지만 플레이 하는 내내 아쉽다고 생각했습니다. 그 이전 디아블로들은 전체적으로 어둡고 우중충한 색감을 보여줬습니다. 첫 디아블로는 256색상을 사용해야 했으니 어쩔 수 없이 어둡고 칙칙한 느낌에 머물 수밖에 없었다면 디아블로2는 상대적으로 밝은 액트2 그래픽도 특유의 제한된 색감으로 표현해냈습니다. 반면 디아블로3은 상당히 화려해졌는데 덕분에 온갖 던전의 다양한 모습을 폭넓게 표현할 수 있었습니다. 대신 디아블로 특유의 분위기를 썩 성공적으로 살려내지는 않았다고 생각합니다.

디아블로 이모탈은 디아블로3의 색감에 훨씬 가깝습니다. 일단 그래픽에서 보이는 아쉬움을 뒤로 하고 게임을 플레이해보면서 마음에 드는 색감을 보여주던 디아블로2와 비교해 전투에서 보여주는 차이 중 하나는 포션입니다. 이전에는 마을에서 포션을 잔뜩 구입해 허리띠에 여러 줄 쟁여 놓고 플레이 했습니다. 포션의 종류에 따라 차이가 좀 있긴 하지만 기본 포션은 쿨타임이 없어 사용 즉시 체력을 회복했습니다. 보스전에 허리띠 인벤토리에 쟁인 포션을 다 쓰면 재빨리 화면 구석으로 도망쳐 보스가 나에게 달려들기 전에 재빨리 인벤토리를 열고 포션을 허리띠로 옮기는 짜릿함이 있었습니다. 그런데 이번 모바일 디아블로는 이럴 수 없게 됐습니다. 체력포션 갯수가 고정되어 있고 이를 내가 구입해서 늘릴 수도 없습니다. 마을에 돌아가거나 중간 보상을 통해 다시 채울 수 있을 뿐입니다. 이전과 비교해 왜 이런 차이가 있는지 이야기해 보겠습니다. 크게 두 가지 접근에 따른 결과입니다.

첫째. 컨텐츠에 도전하는 방법을 달리 정의합니다. 허리춤에 찬 포션을 쿨타임 없이 소모하는 방식은 컨텐츠에 좀 더 공격적으로 접근하게 합니다. 위에서 이야기한 보스전에서 구석으로 도망쳐 체력을 회복하는 꼼수를 사용할 여지를 주고 마을에서 한 번 재정비한 다음 포션을 완전히 소모할 때까지를 한 세션이라고 할 때 플레이하는 목적을 한 세션 안에 최대한 먼 곳까지, 최대한 오랫동안 사냥해 최대한의 보상을 획득하는 것으로 만듭니다. 반대로 이모탈처럼 포션 수량이 고정되어 있다면 한 세션의 목적은 포션을 완전히 소모하기 전에 이번 세션을 마치는 것입니다. 현상금 사냥을 통한 필드 플레이나 균열을 통한 던전 플레이 모두 1회 플레이 시간이 상당히 짧게 설정되어 있습니다. 게임을 모바일로 만들면서, 또 현대의 플레이어들의 성향에 맞추면서 일어나는 당연한 변화인데 여기에 클래식 디아블로 스타일로 포션을 제공하면 짧아진 세션의 난이도를 조절하기 어렵게 됩니다. 그래서 포션을 이모탈 스타일로 제한합니다.

둘째. 기본적인 골드 사용처가 변화했습니다. 클래식 디아블로에도 디아블로 이모탈에도 겜블링을 통해 골드 대량 소모처를 마련해 놓았습니다. 하지만 클래식 디아블로에서는 허리춤에 포션을 가득 채워넣으면서 골드를 쏠쏠하게 사용합니다. 한 세션에 최대한 멀리까지 이동하려면 마을에서 남은 골드를 탈탈 털어 포션을 사야 합니다. 그렇지 않으면 인벤토리의 모든 포션이 장비로 바뀌기도 전에 어중간하게 포탈을 타고 마을에 돌아와 재정비해야 합니다. 상당히 귀찮은데다가 파티 플레이 중이라면 민폐도 이만저만이 아닙니다. 긴 세션에 대비해 골드를 털어 포션으로 바꾸면서 겜블링을 시도하기 전에도 골드를 쏠쏠히 사용할 수 있습니다.

반면 이모탈에서는 컨텐츠 별로 확보할 수 있는 재화를 최대 20가지 이상으로 구분해 놓고 컨텐츠 종류에 따라 정확히 설정된 재화를 보상으로 주고 이 재화의 사용처 역시 정확히 구분되어 있습니다. 또한 플레이어캐릭터들 사이에 재화를 주고받을 수도 없습니다. 때문에 클래식 디아블로에서처럼 포션을 통해 기본적으로 공통 재화인 골드를 소모하도록 설계할 필요가 없습니다. 만약 골드를 공통재화 관점으로 접근했다면 이모탈에서 그 많은 종류의 업그레이드마다 서로 다른 재화를 요구함과 동시에 골드를 요구했을 겁니다. 무기 업그레이드에도 골드를, 보석 제작에도 골드를 요구했겠지만 굳이 그럴 필요가 없습니다. 여러 성장 액션마다 요구 재화가 완전히 구분되어 있고 골드를 사용하게 하고 싶으면 이번에도 겜블링을 통하면 됩니다. 아니면 골드를 쌓아두도록 그냥 놔둬도 인플레이션 문제가 일어나지 않습니다. 때문에 굳이 골드로 포션을 구입하게 해 계속해서 골드를 소모하게 할 필요도 없습니다.