내 지능과 한 번 만들어 끝까지 가는 정책

로드맵 상으로 실제 런칭까지는 아직 머나먼 시간이 남았지만 그 전에 프로젝트에 큰 관심을 표시해 주실 고객 분들께 플레이 가능한 빌드를 공개할 준비를 하고 있습니다. 여기에는 왜 뻔한 기능을 항상 다시 개발할까에서 설명한 적 있는 프로젝트에 참여한 여러 사람들이 이전에 다른 프로젝트에서도 이미 개발해본 적이 분명히 있을 기능을 다시 개발하는 과정을 포함합니다.

프로젝트마다 비슷비슷한 기능을 바닥부터 다시 개발하는 이유에 여러 가지가 있겠지만 가장 큰 이유는 회사와 프로젝트가 영속적으로 유지되고 또 그 안에서 얻은 노하우가 문서화를 통해 전혀 전달되지 않기 때문입니다. 그런데 이전에 뻔히 만들어본 적이 있는 기능인데도 입퇴장 메시지 사례로 보는 비용예측의 어려움에서 소개한 것처럼 간단한 기능조차도 비용을 예측하기 쉽지 않은데 비용 뿐 아니라 비용을 요구하게 될 정책 자체를 수립하기도 쉽지 않습니다.

이번에는 MMO로 개발되고 있는 프로젝트의 작은 공개 버전에 어떤 캐릭터 네이밍 정책을 수립해야 할 지 생각해본 사례를 소개하고 수많은 프로젝트에 캐릭터 네이밍 정책을 수립해 왔음에도 여전히 한 번에 끝까지 가는 네이밍 정책을 수립하기 어려워 테크에 미안한 말을 할 수밖에 없었던 상황을 소개하겠습니다.

여느 온라인 게임의 캐릭터 네이밍 정책은 사실 오랫동안 아무런 변화도 없었습니다. 물리적으로 여러 서버 군으로 구성되지만 보통은 ‘한 서버’라고 부르는 서로 겹치지 않는 단위 안에서 서로 겹치지 않는 캐릭터 이름을 결정하면 끝이었습니다. 한 번 정하면 게임 서비스가 종료되는 순간까지 사실상 영원히 이름을 바꿀 수 없었기 때문에 게임을 시작하기 전에 이름을 정하는데 크게 공을 들이곤 했습니다. 만약 캐릭터 외형이나 능력치를 게임을 시작하기 전에 설정해야 하는 게임이라면 마지막 단계에서 이름을 정하지 못해 그때까지 시간을 들인 설정을 날리는 경험을 하게 만드는 게임도 있었고요. 또 서비스를 시작한 지 오랜 시간이 흐른 게임은 어지간한 흔한 단어와 단어의 조합은 모두 이미 사용 중이어서 게임을 시작하기도 전에 ‘중복된 이름입니다.’ 팝업을 수 없이 보다가 이 단계에서 이미 지쳐 게임을 시작하기도전에 그만 두게 만들기도 합니다.

시간이 흐르며 캐릭터 이름을 바꿀 수 있는 장치가 생기고 또 게임에 따라서는 서버 군을 이전할 수 있게 되면서 어떤 문제는 해결되고 또 어떤 문제가 새로 생기기 시작합니다. 이름을 바꿀 수 있게 되자 기존에 게임을 시작하기 위해 어쩔 수 없이 즐겨 사용하던 이름 뒤에 마음에 안 드는 접미사를 붙여 사용하던 이름을 수정하거나 그 시대의 새로운 밈을 반영한 재미있는 이름을 만들 수 있게 되었습니다. 한편 서버 군을 이전할 수 있게 되자 그 동안 서버 군 단위로 이름 중복을 확인하던 정책에 문제가 생기기 시작했는데 서버 군 이전은 고객이 자발적으로 이전하는 경우도 있지만 서비스를 시작하고 시간이 흘러 전체 사용자 수가 줄어들면서 서버를 통합하면서 비 자발적으로 이전 되는 경우도 있습니다.

자발적인 이전은 이전할 대상 서버 군에 지금 고객이 사용 중인 이름이 이미 사용 중이라면 그 이름을 피해 이름을 새로 만들도록 강제하면 간단히 해결할 수 있습니다. 하지만 비 자발적인 이전은 어떤 고객은 이 이전 이벤트에 반응해 이름을 수정하겠지만 이전에 반응하지 않는 휴면 고객이나 하필 이 이벤트가 일어나는 기간에 접속하지 않은 고객의 중복되는 이름을 어떻게 처리할지 결정해야 합니다. 게임에 따라서는 캐릭터를 비활성 상태로 만든 다음 중복되지 않는 이름을 설정한 다음에야 활성화 시켜 이전 된 서버에서 사용할 수 있게 하기도 하지만 이런 절차를 만들고 앞으로 오랜 기간에 걸쳐 유지할 자신이 없는 팀에서는 한 번에 모든 절차를 마치기 위해 제한된 이벤트 기간 안에 이름 중복 문제를 직접 해결하지 않는 고객들은 임의로 이름을 바꿔 버리기도 합니다. 그 결과로 이름이 바뀐 고객들은 잠깐 게임에 돌아왔다가 영원히 게임을 떠나기도 하고요.

지금까지 계속해서 서버 군 단위로 중복되지 않는 이름을 설정하는 규칙을 이야기했는데 이 규칙은 아주 오랫동안 별 의심 없이 유지되어 왔지만 프로젝트 구성원들 스스로가 다른 게임의 고객인 입장에서 이 정책은 간단하고 익숙하지만 한편으로는 굉장히 마음에 안 드는 정책입니다. 물론 깊이 생각할 것 없이 평소 하던 대로 만들면 되니까 딱히 소리 내서 이 정책이 구리다고 말하지는 않지만 그런 사람들 하나하나는 다른 게임을 시작하기도 전에 이름 중복으로 게임을 시작하지도 못하는 상황을 맞으며 짜증 내기 일쑤임입니다. 게다가 여러 게임들이 극 초반 고객 이탈을 줄이기 위해 시작하자 마자 캐릭터 이름을 정하게 하지 않고 멋진 프롤로그를 보고 그 안에서 내가 선택한 캐릭터가 대단한 활약을 한 다음 갑자기 정신을 잃고 외딴 마을에서 눈을 뜨며 시작할 때 까지 가서 이름을 정하게 만들곤 하는데 여기서 중복된 이름으로 이름을 정하지 못하면 이는 실망이 아니라 분노에 해당하는 감정으로 발전하기도 합니다.

한편 게임 설정에 따라 캐릭터 이름 외에 캐릭터를 묶는 계정 단위의 이름을 정하는 게임도 나타났는데 이런 게임들 덕분에 한동안 여러 프로젝트에서 그냥 남들이 하는 수준의 뻔한 이름 설정 규칙을 만들면서도 리뷰 단계에만 가면 지금까지 단 한 번도 논의한 적 없는 가문 이름이나 계정 단위 이름 같은 걸 정할 계획은 없는지 질문을 받으며 쓸 데 없는 시간 낭비를 하곤 했습니다. 또 캐릭터 뿐 아니라 게임 내 다양한 요소에 중복되지 않는 이름을 요구하는 사례도 생깁니다. 이런 상황을 돌파하는 단순한 방법으로 이름 뒤에 게임에 정한 아무 번호를 붙이기 시작했는데 전통적인 온라인게임은 아니지만 디센트럴랜드 네임 사례가 있습니다. 여기서는 게임 내 다양한 요소에 이름을 붙일 수 있는데 이 이름은 중복될 수 있습니다. 그런데 이름을 NFT 형태로 발급하고 나면 이 이름은 따로 표시되며 NFT화 된 이름은 게임 상에서 더 이상 중복되지 않습니다. 이런 사례를 포함해 그냥 뻔하디 뻔한 규칙을 만드는데도 상당한 시간과 스트레스가 필요했습니다.

이런 상황을 회피할 힌트를 준 사례가 배틀넷의 배틀태그 사례인데 여러 게임을 통합해서 운영하는 서비스 전체에 걸쳐 고객의 이름 하나를 결정하게 하고 그 이름은 서비스 전체에 걸쳐 중복될 수 있지만 이 이름 뒤에 서비스가 임의로 정한 고유한 숫자를 붙여 이름과 숫자를 합친 문자열에 대해서는 서비스 전체에서 고유한 모양이 되도록 하는 것입니다. 이메일처럼 이름 뒤에 뭔가 다른 문자열을 붙여 중복을 회피하자는 아이디어는 이전에도 있었지만 항상 그런 사례를 본 적 없는 모든 사람들의 걱정으로 인해 리뷰 단계를 통과한 적이 없었습니다. 하지만 유명한 회사가 비슷한 방법을 사용한 순간 이전과 똑같은 아이디어를 들고 가도 이제 다들 군소리 없이 그렇게 만들어 주기 시작합니다.

이제 지금 개발하는 프로젝트 이야기로 돌아와 이번에는 서비스에 참여할 고객 수가 아주 많지 않을 상황에서 중복되는 이름 때문에 게임을 시작하는데 좌절을 겪지 않기를 원했으며 고객 중 상당수는 NFT 보유자들이기 때문에 NFT에 대응하는 인게임 캐릭터가 있다 하더라도 이 캐릭터에 이름을 붙이지 않으면 게임을 시작할 수 없는 기묘한 상황을 예상했습니다. 그래서 모든 캐릭터에 이름 기본값을 붙이고 이 이름은 모두가 중복될 수 있도록 하되 그 뒤에 배틀태그처럼 캐릭터 별로 고유한 일련번호를 붙이기로 합니다.

이 규칙은 정확히는 이름 뒤에 네 자리 숫자를 붙이되 이 숫자는 이름이 다른 캐릭터 사이에 중복될 수 있으며 캐릭터에 한 번 설정되고 나면 고유 번호처럼 이름을 바꿔도 따라 다니게 되는데 이런 규칙을 처음부터 설계하기에 기획에 주어진 시간이 부족해 일단 이름 중복을 허용하고 그 이름 뒤에 제로패딩 하지 않은 일련번호를 증가 시켜 붙이는 선으로 규칙을 정했습니다. 제로패딩 하지 않는 이유를 여러 번 질문 받았는데 배틀태그처럼 번호끼리는 중복 가능한 구성이 아니기 때문에 항상 중복되지 않는 여러 자리 숫자를 만들어 유지하면서도 적은 저릿수를 유지하기는 쉽지 않을 거라고 생각했고 또 전체 고객 수를 지금으로는 예측할 수 없었기 때문에 함부로 자릿수를 정할 수 없었기 때문입니다.

하지만 제한 시간 안에 만든 이 규칙은 당연히 여러 예상되는 문제가 있었습니다. 가령 이름은 중복을 허용하지만 이름 뒤에 붙는 숫자는 중복을 허용하지 않으며 이름 뒤에 붙는 숫자가 제로패딩 없이 캐릭터마다 새로 생성되는 중복되지 않는 숫자라면 이 숫자는 캐릭터를 생성하고 삭제함에 따라 계속해서 증가할 수 있어 이론적으로는 아주 거대한 숫자가 될 수도 있습니다. 또 앞에서 설명한 한 번도논의되지는 않았지만 만약 미래에 계정 단위의 요소가 생긴다면 계정 단위로는 숫자를 공유하게 만들어야 할 수도 있고 이 때 지금의 숫자 생성 규칙은 문제가 생길 여지가 큽니다.

이런 미래까지 반영해 한 번 만들어 놓으면 아주 오랫동안 신경 쓸 일 없는 규칙을 한 번에 만들어 내고 싶고 또 그런 압력을 항상 받지만 냉정하게 현 시점에 우리가 가진 제한적인 정보와 제한된 시간 안에서 만들어낼 수 있는 최선의 규칙은 지금 수준이 한계가 아닐까 싶었고 이런 측면에 불만을 가지는 분들을 설득해야만 했습니다. 지금 단계에서 미래를 예측해서 규칙을 만들면 한 번만 만들어 두면 손 댈 일 없으니 좋겠지만 우리가 만드는 소프트웨어는 계속해서 변화하고 우리 소프트웨어를 둘러싼 환경 역시 계속해서 바뀌므로 지금은 지금까지 주어진 정보와 상황에 기반해 규칙을 만들고 미래에 상황이 변하면 그 때 가서 그 시점의 정보에 기반한 규칙을 만들어야 할 거라고 설명했습니다.

하늘로 날아간 아바타에서 이야기한 것처럼 소프트웨어는 우리가 생각하는 것보다 훨씬 복잡하고 우리들은 그 복잡도를 한 번에 지탱하기에는 부족한 지능을 가지고 있기 때문에 우리가 만드는 소프트웨어는 한 번 만들어 놓고 단단히 돌아가기를 기대하기 보다는 상황에 따라 정책과 동작을 수정해 가는 편이 옳다고 생각합니다. 한편 그런 정책을 수립하는 입장에서 우리들의 지능이 부족한 이유로 팀 전체가 같은 기능을 여러 번 재개발 해야 하는 상황을 만들고 있다는데 미안함을 느끼지만 이는 지능의 한계로 미안하기는 하지만 어쩔 수는 없다고 생각하고 있습니다.