개함우월주의

워싱턴 군축조약과 런던 군축조약에 의해 건조 가능한 함선 배수량에 제한을 안게 된 일본은 개함우월주의를 내세웁니다. 개함우월주의는 일본과 일본의 적국이 같은 배수량의 군함을 보유하고 있을 때 일본의 군함이 항상 적국의 군함보다 모든 면에서 더 우월해야 한다는 사상입니다. 적국보다 더 많은 무기를 싣고 더 두꺼운 장갑을 탑재하기 위해서는 물리적으로 더 큰 배수량이 필요하지만 이론적으로 충분한 기술력이 뒷받침된다면 같은 배수량일 때 더 우월한 배를 만드는 일이 불가능하지는 않을 겁니다. 가령 현대의 함선이 같은 배수량일 때 스텔스 형상을 적용해 레이더에 더 작게 탐지되고 또 더 유선형으로 만들어져 같은 엔진을 사용해도 더 빠르고 더 강력한 레이더 시스템을 적용해 적을 더 잘 탐지하도록 만들었다면 이는 어쩌면 배수량의 한계를 기술로써 극복한 사례라고 말할 수 있습니다. 하지만 때는 아직 냉전시대의 군비경쟁을 통한 폭발적인 기술 발전이 일어나기 이전으로 강대국들은 확실히 당시 한국과 같은 제 3세계 국가들보다 훨씬 진보 되어 있었지만 일본은 당시 강대국으로 분류되면서도 다른 강대국보다 상대적으로 더딘 발전을 보이고 있었습니다. 우리들이 종종 코미디 소재로 전해 듣곤 하는 경항공모함 류조 같은 웃픈 결과가 바로 이 개함우월주의를 고수한 끝에 나온 것입니다.

당시 일본 입장에서 해군군축조약의 가장 큰 의의는 자신들의 총 배수량을 미국의 60% 수준으로 묶어둔다는데 있었습니다. 당시 일본의 경제력과 공업력은 이미 그 시점의 미국에 상대가 되지 않았기 때문에 이전처럼 함선을 마음껏 찍어낼 수 없더라도 훨씬 더 큰 경제력과 공업력을 가진 미국을 이 정도 수준으로 묶어둘 수 있다면 대서양과 태평양 양쪽에 해군력을 분산해야 하는 미국과 태평양에서 비슷한 영향력을 유지할 가능성이 있습니다. 개함우월주의는 이론적으로 이런 상황에서 경제력과 기술력의 부족을 무시하고 배수량 기준으로 항상 상대 함선보다 모든 면에서 우월해야 한다는 사상으로 이론 상으로는 그럴 듯 하지만 실제 물리적인 세계, 그리고 당시 일본의 경제력과 공업력 기반으로는 달성할 수 없는 목표에 가까웠습니다. 하지만 당시 일본 군부는 이런 사실상 물리적인 한계를 무시하기 일쑤여서 물리적인 한계를 무시하는 목표를 세우고 이를 달성해야만 하는 상황에 자주 놓인 것 같은데 이런 일종의 까라면 까야 하는 상황은 수 십 년이 흐른 다음 체르노빌 발전소 사고를 일으키는데 기여하기도 합니다. 개인적으로 이 앞부분을 쓰기 위해 개함우월주의를 검색했다가 튀어나온 일본의 경항공모함 류조 그림을 보고 이 이야기를 알고 있음에도 빵 터질 수밖에 없었는데 이제 거의 100년 가까이 지난 미래인의 관점에서 이 배가 물 위에 떠 있는 것을 보고 웃지 않기 어렵습니다. 어쩌면 고대 이집트인들이 피라미드를 나일강에 거꾸로 띄워도 저것 보다는 더 멀쩡하지 않았을까 싶을 정도입니다.

지금은 명시적인 중간관리자 역할을 하고 있지 않아 행복한 생활을 하고 있지만 한때 중간관리자 역할을 시작할 때 잘못된 고칭으로 팀원님들을 비탄에 빠뜨린 사례 하나는 지금도 기억에 남습니다. 팀 목표로 이번 마일스톤에 업적 시스템을 만들어야 했습니다. 우리가 해야 하는 일은 업적 시스템에 대한 시스템기획서를 작성해 협업 부서들에게 설명하고 개발을 진행해 컨텐츠 담당자들에게 시스템을 인계해 업적이 입력되도록 하는 것입니다. 여러 게임을 살펴보면 업적 시스템에는 온갖 다양한 조건에 기반한 업적들로 가득하고 각 업적마다 보상을 받기도 하며 업적 수준에 따라 한 가지 업적이 여러 단계로 업그레이드 되어 하위 업적을 달성한 다음에야 상위 업적이 나타나는 등 다양한 방식으로 업적을 제시합니다. 특히 업적 조건은 게임 전체에 걸쳐 온갖 조건에 기반하는데 가령 FPS 게임에서는 종종 한 판에서 가장 먼 거리를 이동한 사람이나 가장 긴 거리를 뛰어내린 사람이 누구인지, 이들이 이동한 거리는 몇 미터인지 측정해 이를 보상하는데서 시작해 적을 얼마나 죽였는지, 아이템을 얼마나 먹었는지, 몇 번 죽었는지, 같은 지역에서 얼마나 오래 있었는지 등등 여간해서 정규화 하기 거의 불가능한 온갖 조건으로 구성되어 있습니다. 여기까지 보면 업적 시스템을 설계하는 일은 대단히 복잡할 것 같아 보이지만 만약 우리가 직접 이 조건들을 게임 코드 곳곳에 입력해야 했다면 그럴 수도 있었겠지만 다행히 우리는 여러 가지 조건, 조건을 지탱할 시스템과 이를 표현할 인터페이스를 제안하고 나면 그 다음은 전문 프로그래머들이 담당해 줄 예정이기 때문에 우리 입장에서 그리 고된 일은 아닙니다.

지금도 여느 게임디자인 부서가 다들 비슷할 것 같은데 프로젝트를 구성한 큰 조직들 사이에도 원활한 정보 공유와 협업이 잘 일어나지 않는 마당에 분업에 기반해 동작하는 게임디자인 조직 안에서도 서로 정보 교환이 잘 일어나지 않는 것은 어쩌면 당연합니다. 이런 상황에서 각각의 게임디자이너들이 단위 기능을 할당 받아 기획서를 작성할 때 이 문서에 기술된 단위 기능이 개발된 다음 게임의 나머지 부분과 함께 동작할 때의 모습을 상상하기 보다는 시야를 좁혀 단위 기능 그 자체에 집중해 단위 기능이 온전히 동작하는데 초점을 맞추기 쉽습니다. 사실 이런 접근이 엄청나게 이상한 것은 아니며 중간관리자 입장에서 마일스톤이 시작되자마자 기획서를 내놓으라고 난리인 협업 부서들을 생각하면 시야를 넓혀 게임 전체 관점에서 조화롭게 동작하는 디자인을 도출하기 위해 시간을 더 사용하기 보다는 시야를 좁혀 단위 기능 수준에서 올바르게 동작하는 디자인을 더 빠른 시간 안에 도출하는 쪽을 선호하기도 합니다. 이로 인해 발생할 것이 확실한 문제는 일단 개발을 진행한 다음 나중에 소위 ‘폴리싱’ 기간에 별도로 대응하는 쪽이 당장의 개발 진행을 위해 더 나은 선택일 때가 있습니다. 여느 개발팀에서 이 ‘폴리싱’이 얼마나 이상하게 뒤틀려 집행되는지를 소개하면 저 위에 붙여 둔 류조 사진만큼이나 웃긴 주제가 될텐데 이 글의 스코프를 벗어나는 것 같으니 언젠가 기회가 될 때를 기다리겠습니다. 여튼 핵심은 주니어 디자이너가 단위 기능을 할당 받으면 전체 게임에서 조화롭게 동작하는 모양을 고안하기 보다는 시야를 좁혀 단일 기능이 온전하게 동작하는데 집중하게 되며 의도적으로 이 상태를 방치한다는 것입니다.

좁아진 시야로 단위 기능이 동작하는데 집중한 디자인을 고안하다 보면 단위 기능 각각이 마치 독립된 시스템처럼 동작하도록 만들기 쉽습니다. 시스템은 구성요소들이 상호작용 할 수 있도록 통합되어 목표를 달성하도록 만들어진 구조를 말하는데 게임디자인에서 각 시스템의 목표는 작게는 시스템 스스로가 자기 역할을 다 하는 것, 그리고 크게는 전체 게임이 올바르게 동작하는데 기여하는 것으로 구분할 수 있습니다. 앞에서 설명했다시피 이미 게임디자이너들의 시야는 좁아져 있어 시스템 스스로 자기 역할을 다 하는데 집중하며 중간관리자 관점에서 이런 좁은 시야는 더 빨리 기획서를 도출할 수 있기에 근미래에 문제가 일어날 것임을 알지만 방치하곤 하며 종종 중간관리자 입장에서 볼 때 너무 뻔한 문제를 안고 있을 경우에 한해 개입해 수정하눈 정도에 머무릅니다. 이런 상황에서 게임 전체를 구성하는 각각의 개별 시스템은 마치 이 게임 세계에 자기 자신만 존재하는 것처럼 행동하도록 설계되기 쉽습니다. 가령 업적 시스템은 인게임에서 여러 가지 행동을 고객에게 인지 시키고 고객이 특정 보상을 목표로 삼아 행동하도록 유도하거나 반대로 게임에 지속적으로 자원을 투입한 고객의 성과를 보상하는 방향으로 동작하기도 합니다. 근본적으로 업적 시스템은 일단 인게임이 그 스스로 온전히 동작하고 그 스스로 순환 가능한 보상을 지급하는 체계가 완전히 갖춰져 있다는 가정 하게 그 위에서 보조 역할로 동작하도록 설계하는 것이 보통입니다. 그런데 좁은 시야로 업적 시스템을 디자인하기 시작하면 마치 업적이 게임의 가장 중요한 시스템인 것처럼 생각하게 됩니다.

업적 시스템이 일단 온전히 동작하는 게임의 일부를 지탱하는 보조 시스템이라면 업적 시스템에 접근하는 경로는 아마도 핵심 인터페이스보다는 우선순위가 낮은 더 깊은 메뉴에 위치해야 할 것 같고 또 업적을 달성했다 하더라도 그 사실을 알려주는 메시지는 게임 상에 그 순간 나타나야 할 여러 다른 메시지에 비해 우선순위가 더 낮을 것임을 예상할 수 있습니다. 가령 보스를 처치했고 레벨업이 일어났고 또 동시에 특정 업적을 달성했다고 해 봅시다. 사실 이런 상황이 자주 일어나도록 디자인 된 업적은 개인적으로는 그리 좋다고 생각하지 않는데 고객이 동시에 여러 메시지를 동시에 받아 어느 것 하나 온전히 전달되지 않을 가능성이 높다고 생각하기 때문입니다. 하지만 별다른 주의를 기울이지 않고 그저 ‘말이 되는’ 방향으로 데이터를 입력하다 보면 당연히 보스를 처치할 때 경험치를 얻어 레벨업이 일어나고 특정 레벨을 달성하는 업적이 달성될 수밖에 없긴 합니다. 또 이런 디테일을 중요하게 여기지 않는 팀에서는 이런 상황을 문제로 정의하는 것조차 어렵습니다. 이런 여러 이벤트가 동시에 발생하는 상황에서 업적이 게임의 나머지 기능과 조화롭게 동작한다면 업적 메시지는 상대적으로 낮은 우선순위에 의해 표시되고 또 업적 보상은 나머지 보상과 분리된 별도 방법으로 지급 되어야 하며 업적은 다른 수많은 인터페이스에 찍혀 있는 빨간점과 마찬가지로 그저 고객의 접근을 기다리고 있는 수준이면 충분합니다. 그런데 이런 상황에서 좁은 시야로 디자인 해 업적이 인게임에서 가장 중요한 시스템인 것처럼 생각하면 이상한 기획서를 작성하게 됩니다.

똑같이 보스를 처치하고 레벨업이 일어나는 상황에서 일단 보스를 처치한 상황은 그 시점에서 가장 중요한 이벤트임에 확실하니 큼직하게 보스가 쓰러졌음을 알리고 이로부터 획득한 보상을 표시하는 부분 까지는 기존과 같이 동작하도록 할 겁니다. 그런데 레벨업부터는 이야기가 좀 달라지는데 과거 MMO 게임에서 레벨업은 거의 유일한 수직 성장 요소였기에 그 위상이 지금과는 상당히 달랐습니다. 가령 처음으로 참여한 MMO 게임에서는 후반부 레벨업은 누군가가 레벨업을 겪으면 멀리서 NPC가 달려와 축하해주고 게임 전체에 이 경사를 알려 모두가 축하해주도록 만들고 몇 십 초에 걸쳐 온갖 시청각 효과를 보여주는 등 온갖 난리 법석을 떨기도 했습니다. 반면 현대의 레벨업은 이 이벤트를 통해 즉시 성장이 일어나기 보다는 고객의 성장 체감 수준을 더 올리기 위해 레벨업 이벤트 자체로는 직접적인 성장이 일어나지 않도록 하고 레벨업을 통해 성장 불가능했던 수직 성장 요소들을 직접 성장 시킬 수 있도록 구성하는 경우가 많습니다. 이전에는 레벨업이 일어나면 즉시 능력치가 상승했다면 이제는 레벨업은 나머지 성장 가능한 요소가 오른 레벨만큼 강해질 수 있도록 제한이 완화되는 역할을 하는데 이를 전통의 레벨업 메커닉과 유사하게 만들어 놓은 결과가 레벨업, 최대레벨 도달, 승급을 통한 최대레벨 증가 메커닉입니다.

그래서 과거라면 몬스터 처치와 같이 차마 손댈 수 없을 만큼 중요한 레벨업 이벤트이지만 현대에는 그렇지 않으므로 시야가 좁아져 보상 시스템이 게임에서 가장 중요한 시스템이라도 되는 마냥 접근하는 게임디자이너 입장에서 레벨업은 그냥 종종 일어나는 이벤트일 뿐 그리 중요한 이벤트가 아니게 됩니다. 심지어 레벨업 이벤트가 일어난 다음 그 결과에 의해 업적 달성이 일어나는데도 말입니다. 다른 프로젝트에서 업적 달성 여부가 화면 구석에 작게 나타났다가 사라지고 보상은 메뉴에 빨간점을 띄워 이를 따라가 수동으로 먹게 만들곤 했다면 시야가 좁아진 상태에서 나온 업적 시스템의 동작은 업적 달성 여부가 마치 레벨업과 같거나 레벨업보다 더 중요한 메시지인 것처럼 레벨업 메시지를 밀어나고 업적 달성 메시지가 튀어나오게 됩니다. 또 보상 역시 보스가 쓰러질 때 보상을 직접 꽂아 주는 것처럼 업적 시스템 역시 업적 달성에 의한 보상을 직접 꽂아 주려고 시도하기도 합니다. 앞에서 빨간점 이야기를 했는데 업적 시스템은 대부분 보조 시스템으로 이로부터 획득한 보상이 게임에 직접적인 영향을 최소화하도록 보상을 설계하기 때문에 업적을 달성했다 하더라도 보상을 지금 즉시 받을 필요가 없습니다. 또 그럴 만한 큰 보상을 넣지 않는 경우가 많습니다. 그런데 좁은 시야에 의해 업적의 중요성을 착각하면 보스를 쓰러뜨리고 획득한 보상이 화면에 표시된 직후 업적 달성에 따른 초라한 보상이 보스를 쓰러뜨리고 획득한 보상을 밀어내고 화면에 나타나 더 오랜 시간 동안 남아 있어 마치 보스를 쓰러뜨리고 획득한 보상이 이렇게 초라한 것인지 착각하게 만들기도 합니다.

이런 접근은 업적이 끼어들 모든 순간에 걸쳐 나타납니다. 업적은 메인 메뉴 구성요소 중 하나여야 하고 업적 시스템에서 업적 하나하나를 달성할 때 더 의미 있는 보상을 획득해야 할 뿐 아니라 업적 시스템 자체가 독립된 게임처럼 동작하게 할 생각으로 업적 시스템 자체에 리텐션을 고려한 기능들이 제안됩니다. 초기 중국 모바일 게임들이 게임의 여러 인터페이스에 리텐션을 유지하기 위해 아주 작은 보상을 온갖 인터페이스에 붙여 놓곤 했습니다. 가령 아무도 공지를 끝까지 스크롤 하지 않는 상황을 완화하기 위해 공지사항을 끝까지 스크롤하면 그 밑에 소량의 골드를 받는 인터페이스가 나타나거나 빨간점을 띄운 공지를 모두 읽어 빨간점을 없애면 보상을 주기도 합니다. 보상 시스템을 포함한 게임의 다양한 부분들이 이 인터페이스에 접근해 아주 작은 행동을 할 때마다 작은 보상을 계속해서 줬는데 아이디어 자체는 나쁘지 않았고 우리들도 이를 보고 영향을 받았지만 이 규칙이 게임 전체에 걸쳐 사용되자 별 의미도 없는 골드 획득 버튼을 매번 클릭하는 행동 자체가 피로감을 일으켜 이 메커닉을 통해 획득하는 골드 분량을 만들기 위해 노력한 밸런스 디자이너의 노력에도 불구하고 결국 아무도 이 골드에 관심을 기울이지 않는 결과로 끝납니다. 하지만 시야가 좁아진 디자이너 관점에서 업적 시스템은 굉장히 중요하며 단일 시스템의 리텐션이 충분히 유지되어야 하고 단일 시스템에 대한 고객들의 의존성 역시 높아야 합니다. 그러니 잠깐 신경을 다른 데 쓰다가 받아 본 문서에는 아무 협의도 없이 특정 업적을 달성하면 캐릭터의 1차 스테이터스를 영구적으로 상승 시켜야 한다는 내용이 포함되어 문서를 읽는 사람들을 깜짝 놀라게 만들었습니다.

그런데 애초에 작은 단위 조직의 중간관리자조차 당황하게 만든 결과가 나온 가장 큰 이유는 바로 중간관리자인 저 자신이 바로 이전에 이 주제에 대해 팀원님께 했던 잘못된 가이드 때문입니다. 사실 기획팀 관점에서 업적 시스템은 여러 업적을 보여주고 진행 상황을 표시하며 업적 달성에 따라 보상을 지급하고 또 다음 단계 업적을 보여주는 등 그리 복잡하지 않은 기능입니다. 여기에 업적을 달성할 때 고객에게 이를 어떻게 고지할지, 보상을 즉시 지급하거나 인터페이스에 찾아와 상호작용을 통해 지급하거나 우편을 통해 지급하는 등의 방식을 결정하면 됩니다. 이에 비해 기능을 구현하는 관점에서 볼 때 업적은 시스템으로 포장되어 있지만 사실상 하드코딩에 가까운데 게임의 온갖 위치에 다양한 조건을 판단할 코드를 추가해야 하기 때문입니다. 시간이 지나 업적들이 어느 정도 규칙적인 모양으로 나타나기 시작하면 이들을 관찰자 모양으로 잘 정리해 유지보수가 그리 힘들지 않은 모양으로 정리하겠지만 하루하루가 급한 초기에는 이런 고려 없이 사실상 하드코드에 가까운 모양으로 게임 코드 아무데나 업적을 확인하는 코드가 나타나 담당자의 멘탈을 박살 내는 역할을 하기도 합니다. 처음에 접한 업적 시스템의 제안은 정말 있는 듯 없는 듯 조용히 인게임 상황을 살펴보고 업적을 달성하면 조용히 보상을 받을 수 있는 모양으로 변해 고객의 상호작용을 기다릴 뿐이었습니다. 업적은 그저 스팀의 그것처럼 기나긴 목록 모양으로 나열되어 있을 뿐입니다. 이 모양이 틀린 것은 아니지만 뭔가 … 아주 작은 포인트라도 있었으면 좋겠다고 생각했고 이 때 단위 기능의 리텐션, 그리고 단위 기능이라도 독립된 시스템으로 동작할 수 있다는 점을 고려해 달라는 피드백을 낸 결과입니다.

제가 드린 가이드 때문에 업적 시스템은 처음에 받은 제안에 비해 훨씬 중요하고 또 요란한 모양으로 변해 있었는데 이는 제 스스로도 원하는 모양이 아니었습니다. 하지만 이런 결과에 도달한 이유가 제 가이드 때문이라는 사실을 인정할 수밖에 없었기에 일단 잘못된 가이드에 대해 사과하고 적당한 선을 찾기 위해 좀 더 직접적으로 힌트를 내야 했습니다. 결국 업적 시스템은 다른 게임에 들어간 것과 비슷한 수준으로 들어갔고 이후 어느 마일스톤에서 업적 시스템을 관찰자 모양으로 정규화하는 태스크가 진행되는 것을 보았습니다. 저는 이 과정에서 제가 처음 제공했던 가이드가 마치 일본군의 개함우월주의 같은 관점이라는 생각을 했습니다. 각각의 단위 기능은 게임 전체 관점에서 볼 대 조화롭게 동작해야 하지만 시야를 좁혀 단위 기능에 집중하다 보면 기능 스스로의 리텐션을 고민하고 기능 스스로의 중요성, 기능 스스로의 독립성을 고민한 끝에 게임 전체 관점에서 볼 때 조화롭지 않은 결과를 쉽게 제안할 수 있게 됩니다. 일정을 줄이기 위해 팀원님들 각각이 더 좁은 시야를 가지더라도 이를 문제 삼지 않는 상황이라면 최소한 중간관리자인 저라도 그보다는 더 넓은 시야를 가지고 제안을 평가해야 하며 그렇지 않으면 경항공모함 류조 같은 어처구니 없는 결과를 팀 바깥으로 내보낼 수밖에 없음을 배웠습니다.

마지막으로 경항공모험 류조의 어처구니 없는 이야기는 이 영상을 살펴보세요.