마스토돈을 시작하고 또 아예 서버를 만들어 운영하기 시작한 이유는 트위터에서 아무 말을 하며 그럭저럭 평화롭게 살던 삶에 일론님이 찾아와 변화를 겪기 시작했기 때문입니다. 트위터에 많은 것을 바라지 않았습니다. 그냥 누구인지 잘 모르는 분들과 적당히 느슨하게 연결되어 아무 말을 주고 받거나 아니면 그냥 주기만 하면서 여러 가지 욕구를 충족하는 정도면 충분했습니다. 그 사이에 광고를 좀 보거나 유료 옵션이 생기면 이 느슨하고 안정적인 아무말 수단이 사라지는 사고를 막기 위해 돈을 낼 준비가 되어 있었습니다. 하지만 트위터는 딱히 우리들로부터 직접 돈을 받지는 않았고 그렇게 세월이 흘렀습니다.

트위터가 공개 회사에서 일론님의 사유물이 되면서 아무래도 일론님 처럼 말하는 사람들에게 더 유리한 환경이 될 거라고 예상하기는 했습니다. 가령 계정을 정지당한 미국 전 대통령이 돌아올 수도 있을 거라고 예상했고요. 하지만 그런 사람들은 일단 나와 언어가 직접 통하지도 않고 직접 팔로우 하고 있지도 않으니 당장 내 아무말 생활에 별 영향을 끼치지 않으리라 생각했습니다. 하지만 당장 서비스의 기술적인 근간을 이루는 사람들과 그나마 트위터가 서로를 고통스럽게 만드는 말로 완전히 도배 되지 않도록 관리하던 사람들을 완전히 지워 버릴 것을 예상하지는 않았습니다. 적어도 자동차 회사 경영인이 자동차 개발자들을 한방에 날려 버릴 것을 예상하지 않은 것 처럼요.

하지만 그런 일이 실제로 일어났습니다. 서비스가 물리적으로 불안해졌고 그 외에는 아직 까지 뭔가가 직접 사라지지는 않았지만 충분히 그럴 가능성이 있으며 아무 말을 하게 만드는 환경 자체에 근본적인 변화가 있으리라는 예상을 하게 되었습니다. 그래서 너무 늦기 전에 원활하게 아무 말을 계속할 수 있는 기술적인 환경과 그 환경을 둘러 싼 사람들과의 느슨한 관계를 별도로 만들어 두지 않으면 안 되겠다는 생각을 하게 되었습니다. 하지만 마스토돈을 시작하고, 또 서버를 운영하기 시작한 다음 시간이 지나면서 도망친 곳에 낙원은 없다는 어디서 나온 말인지는 잘 모르겠지만 이 말이 적용되지 않는 사례를 찾기 힘든 이 말을 다시 한 번 떠올리게 됩니다.

마스토돈 환경은 분명 일론님의 방해에 영향 받지 않고 계속해서 아무 말을 할 수 있었을 뿐 아니라 몇 년 전부터 마스토돈 커뮤니티를 바닥부터 만들어 낸 운영자 분들의 엄청난 노력 덕분에 이제 트위터를 덮은 혐오로부터 어느 정도 거리를 둔 커뮤니티의 수고를 거의 공짜로 얻었습니다. 하지만 이런 노력이 깊어지자 마스토돈에 참여한 지 얼마 안 된 사람 관점에서는 긍정적이라고만 평가하기는 쉽지 않은 현상들이 눈에 띄기 시작했습니다. 트위터에서도 무서운 사람들의 깽판을 피하기 위해 적극적으로 많은 사람들을 블록하고 또 필요하지 않은 사람을 팔로잉 하지 않았던 것처럼 이곳에서도 원하지 않는 정책을 피하기 위한 적당한 조치는 필요하다고 생각합니다. 그래서 오늘은 마스토돈 커뮤니티를 아주 조금 겪으며 느낀 기묘한 특징과 특징을 피하기 위한 개인적인 노력을 함께 설명하려고 합니다.

먼저 주제에 제한이 있는 서버가 있습니다. 트위터에서도 특정 주제를 언급하는 사람들에게 예상되는 독특한 자세 덕분에 프로필에 특정 단어나 해시태그를 언급한 사람들이 하는 말을 처음부터 왜곡해 읽거나 어처구니 없이 느껴지는 말을 하면 아예 블록하기도 했습니다. 마스토돈 커뮤니티에서는 종종 서버 단위로 어떤 주제에 대한 언급을 금지하는데 이 규칙을 위반할 때 계정 단위로 경고를 받기도 하지만 종종 이 규칙을 지키지 않는 다른 서버를 서버 단위로 차단하기도 합니다. 어떻게 보면 서버 하나 단위로 특정 주제를 금지할 수 없지는 않다고 생각합니다. 애초에 마스토돈은 자유 주제 서버가 아닌 이상 서버 운영 주체가 생각하는 어떤 이상적인 커뮤니티의 형태가 있을 겁니다. 이를 위해 주제를 제한하는 것은 있을 수 있는 일입니다. 또 이에 동의하지 않으면 다른 서버를 이용하면 되니 마찰이 일어날 이유가 크지도 않습니다.

하지만 규칙을 따르지 않는 다른 서버를 서버 단위로 차단하는 것은 생각할 여지가 있습니다. 인터넷 세계에서 마음에 들지 않는 뭔가를 아예 안 보는 것은 개개인의 당연한 권리입니다. 뉴스에 나오는 꼴 보기 싫은 사람을 보고 싶지 않아 뉴스를 안 볼 수 있습니다. 하지만 누군가 나를 대신해 자신이 보고 싶지 않은 사람을 안 보기 위해 내게 뉴스를 볼 권한을 임의로 없앤다면 이건 생각해볼 만한 문제입니다. 서버를 사용하는 개개인은 서버의 규칙에 동의해 서버를 사용하겠지만 그 개개인의 의견에 반해 서버 사용자들이 봐도 되는 것과 보면 안 되는 것을 운영자 임의로 설정하는 행동이 올바른지 고민해 보게 됩니다.

특정 도메인을 사용하면 서버 단위로 차단하기도 합니다. 도메인 중 무료로 사용할 수 있는 도메인을 이용해 스팸을 보내는 사례가 있는 것으로 알려졌습니다. 도메인을 구입해 유지하는 데는 연 단위로 적어도 몇 십 달러는 들기 때문에 비용을 최소화 하고 싶은 입장에서 무시할 수 있는 부담이 아닙니다. 하지만 인터넷 상에서 서버를 운영하려는 요구사항을 조금만 파고 들면 도메인이 반드시 필요합니다. 이럴 때 무료 도메인은 꽤 합리적인 선택이 될 수 있습니다. 한때 .com, .net, .org 같은 최상위 도메인을 보유하지 않으면 서비스의 신뢰성을 구축하는데 어려움을 겪기도 했지만 현대에는 다양한 국가와 다양한 산업군의 도메인을 활용해 독특한 브랜딩을 만들기도 하고 주소가 정확히 보이지 않는 모바일 브라우징 환경이 대중화되면서 도메인의 중요성이 이전보다는 크게 감소했습니다. 때문에 무료 도메인을 사용하는 것 만으로 서비스의 신뢰성을 판단하기는 쉽지 않습니다.

그런데 특정 도메인 사용자들이 이를 주로 스팸에 사용한다는 이유로 도메인 전체를 차단하는 사례를 봤는데 스팸을 방어하는 입장에서는 쉽고 효과적인 선택이었겠지만 이 결정에 의해 피해를 입은 입장에서는 돌이킬 방법이 없습니다. 마스토돈 커뮤니티는 중앙화 구조를 피하기 위해 설계되었지만 근본적으로 이들 사이의 연결에 의해 커뮤니티가 형성됩니다. 때문에 차단되어 서로 끊어진 구조가 늘어날 수록 커뮤니티 전체의 연결성은 약해집니다. 이는 마치 네트워크 일부를 사용할 수 없는 상황에도 데이터를 주고 받을 수 있도록 설계된 인터넷이지만 대형 네임 서버 두 개가 고장나면 인터넷 전체가 고장나게 된 현실과 비슷합니다.

또 서버에 속한 개인 간의 문제로 서버 전체가 차단되기도 합니다. 한 서버 운영자가 자신의 권한을 남용해 공격적인 행동을 한 사례가 있었습니다. 이 행동이 일어나고 시간이 조금 지나자 동시에 여러 다른 서버에서 서로 같은 공지사항을 붙여 넣으며 그 서버를 차단하기 시작했는데 굉장히 불편한 감정이 들었습니다. 관리자의 권한 남용과 공격적 행동은 비판과 비난을 받을 수 있습니다. 그런데 이 행동이 그 서버와 그 서버에 속한 모든 사람들을 마스토돈 커뮤니티의 상당 부분으로부터 제거할 만한 이유인지는 납득하기 어려웠습니다.

바로 위에서 대형 네임서버 두 곳이 고장나면 전체 인터넷이 고장난다는 이야기를 했는데 현재 마스토돈 커뮤니티 상황도 크게 다르지 않습니다. 사용자가 아주 많은 커뮤니티들이 있고 이들과 연결이 끊어지면 사실상 나머지 커뮤니티는 텅 비게 됩니다. 때문에 규모가 큰 커뮤니티들과 관계를 유지하기 위해서는 이런 개개인의 행동 하나하나에도 관심을 기울여야만 하는 상태가 됩니다.

어떤 서버는 주기적으로 다른 서버의 규칙을 확인해 규칙이 호환되지 않으면 서버 전체를 차단하기도 합니다. 이쯤 되면 조그만 이유라도 발견하면 즉시 서버 단위로 차단하는 것 같은 인상을 받는데 마스토돈 서버들은 서버마다 가입할 때 동의해야 하는 규칙이 있습니다. 가령 범죄나 혐오에 가담하지 않는 것 같은 어떻게 보면 안전하게 인터넷을 사용하기 위해 인간으로써 지켜야 할 최소한의 규칙입니다. 한편 이 규칙을 통해 앞에서 소개한 특정 주제를 금지하기도 하고 특정 사용 방식을 금지하기도 하는데 서버 안에서 이런 규칙을 적용하는 것은 서버 운영자의 권한이고 또 사용자들 역시 이에 동의하고 서버를 사용할 테니 딱히 문제 되지 않지만 종종 이 규칙이 호환되지 않는 서버를 임의로 차단하기도 합니다.

이 역시 위에서 이상하게 생각한 점과 별로 다르지 않은데 근본적으로 마스토돈은 커뮤니케이션 서비스이고 어떤 대상과 의사소통하거나 하지 않을 결정을 내릴 권한은 어느 정도 개개인에게 있다고 생각합니다. 그런데 아직 무슨 일이 일어나지도 않았고 아직 누군가 혐오 표현을 하지도 않았으며 누군가 아직 범죄를 저지르지도 않았지만 일단 서버 전체를 차단하고 보는 행동은 이게 바로 마이너리티 리포트의 세상인가 하는 생각을 하게 만듭니다.

일론님의 이상한 정책에 영향을 받으며 무력함을 느끼던 세계에서 적어도 일론님의 이상한 행동을 강 건너에서 바라보며 웃을 수 있는 환경을 만들었지만 이전에는 일론님 한 명의 눈치를 봐야 했다면 이번에는 커뮤니티의 일원으로써, 또 커뮤니티에 속한 여러 사용자들이 온전히 커뮤니티에 접근하기를 원하는 운영자 입장에서 눈치를 봐야 할 대상이 훨씬 많아진 세계라는 점을 깨달았습니다. 지금은 주소를 인용할 때도 혹시 이 분이 자신의 타임라인에 핀 해 놓은 공지사항에 인용하면 차단하겠다고 해 놓지는 않았는지 확인해야 하고 다른 서버 운영자님들로부터 서버 단위로 차단될 만한 행동을 하지는 않는지 스스로 검열해야 하며 내가 모르는 사람들이 나와 같은 도메인을 사용해 스팸을 보내지는 않는지에도 관심을 가져야 할 뿐 아니라 내가 관심 없는 주제라도 이 주제를 명시적으로 금지해야 하지는 않는지 끊임 없이 살펴야 합니다.

일론님과는 다른 또 다른 세계를 경험하고 있습니다. 개인적으로는 생각해볼 만한 주제가 많은 상황이라고 생각합니다. 하지만 마스토돈 커뮤니티에서 원만하게 아무말을 계속하기 위해 이런 느슨하지만 한 번 실수하면 피해가 상당한 규칙들을 적극적으로 준수할 작정입니다.

참여하고 있는 프로젝트는 머지 않아 첫 번째 비공개 테스트를 준비하고 있습니다. 전통적인 프로젝트였다면 훨씬 더 많이 개발한 상태에서 비공개 테스트를 했겠지만 지금 개발하는 게임 분야에서는 훨씬 더 이른 시점에 비공개 테스트를 해 잠재적인 고객들과 투자자들에게 관심을 받고 또 앞으로 개발을 계속해 나가는 동안 의견을 주고 받으며 고객의 의사를 더 잘 반영한 결과를 만들려는 목표가 있습니다. 또한 이 분야에는 널리 알려진 대로 소위 스캠으로 알려진 가짜 프로젝트들이 워낙 많았기 때문에 우리들이 가짜가 아니라는 점을 확실히 하기 위해 만들고 있는 상태를 그대로 보여줄 필요도 있습니다.

개발을 계속해 나가는 것은 별 일이 아니지만 그 중간 과정마다 최소한으로 서비스가 가능한 상태로 마무리를 짓는 일은 생각보다 간단하지는 않습니다. 처음에 누군가 ‘그저 만들고 있는 상태를 그냥 열어 비공개 테스트를 하면 되는 것 아니냐’는 말을 해서 저 주둥이를 뭘르 틀어 막아야 앞으로 영원히 저런 말을 하지 않을 지 진지하게 생각해봤습니다. 종이, 모래, 시멘트, 열화우라늄 따위를 생각했지만 왼쪽으로 갈수록 효과가 떨어지고 오른쪽으로 갈수록 범죄여서 결국 아무 것도 하지 못했습니다.

이번에도 비공개 테스트를 수행하기 위해 전통적인 개발 과정에서는 지금 필요하지 않지만 최소한 서비스를 진행하기 위해서 필요한 기능을 개발하는데 시간을 쓰고 있습니다. 이 상황이 부정적이지는 않습니다. 어차피 이런 서비스를 위한 기능은 언젠가는 개발해야 하고 또 다른 기능에 의해 우선순위가 낮아지면 미래에 서비스 직전에 가서야 급히 만들어 완성도가 떨어지기 쉬우니 미리 부터 만들어 가면 완성도를 어느 정도 유지할 수 있습니다.

그래서 이번 테스트에는 지금 당장은 필요하지 않은 NPC를 만들고 이 NPC와 대화해 기록을 열람하는 장치를 만들기로 했습니다. 게임에서 NPC는 종종 인격을 가지고 유저들과 강한 상호작용을 일으키는 요소이지만 기술적으로는 그리 복잡하지 않습니다. 세계에 서 있고 적당한 애니메이션을 통해 우리들에게 익숙한 사람처럼 행동하고 또 다가가서 상호작용을 시도하면 게임 문법으로 우리들에게 익숙한 상호작용 방식에 따라 기능을 사용할 수 있습니다. 필요하다면 이 때 플레이어와 대화 하는 모양을 연출할 수도 있는데 임밀히 말해 이런 연출은 대화라기 보다는 NPC에게 설정된 대사를 글과 소리를 통해 일방적으로 전달하는 장치에 더 가깝습니다.

이번 비공개 테스트에서는 대화 자체가 중요하지 않습니다. 핵심은 NPC 모양을 한 상호작용 대상이 레벨에 배치되어 있고 상호작용을 하면 기록을 읽을 수 있는 인터페이스를 제공하는 것이 주 기능입니다. 그래서 NPC에게는 최소한의 대화 기능만 필요했습니다. 비공개 테스트까지 개발 기간이 얼마 남지 않았기 때문에 구색을 갖추는데 필요한 핵심 기능만을 포함한 요구사항을 작성해 브리핑을 진행했습니다.

브리핑 때 여러 가지 질문이 나왔는데 그 중 가장 인상적인 질문은 이 최소한의 구색을 갖춘 NPC 대화 기능에 명백히 빠져 있는 당연한 기능이 왜 빠져 있느냐는 것입니다. 가령 대화창에 리치텍스트 표현, 인라인 이모지 또는 이미지 표현, 자연스러운 줄바꿈, 텍스트 표시 속도를 인라인에서 어절 단위로 제어하는 기능, 인라인에서 대화창에 움직이는 연출을 표현하고 또 대화창 안에서 선택지를 표시하는 기능은 없는지, 또 대화창 인터페이스 색상을 제어하는 기능은 없는지 같은 질문을 듣고 거의 같은 답변을 되풀이하며 심지어 개발에 참여하는 사람들 조차 단기 목표와 장기 목표를 구분해 생각하지 않는 점이 재미있다고 생각했습니다.

우리 목표는 가까운 시일 안에 비공개 테스트를 하는 것입니다. 비공개 테스트라는 말에는 공개, 테스트라는 단어가 포함되어 있습니다. 한정된 인원이라 하더라도 어쨌든 개발팀 밖의 인원들이며 테스트라고는 하지만 이들은 최소한 사용 가능한 동작 범위 안에서는 기능이 매끄럽게 동작할 것을 예상할 겁니다. 때문에 이들의 기대에 부응하기 위해서는 기능을 제한하고 이 안에서는 매끄럽게 동작하도록 만들어야 합니다. NPC 대화는 구색을 맞추기 위한 기능이고 구색을 맞추는 하한선을 달성하면 그걸로 충분합니다. 때문에 지금 당장 구색을 맞추는데 필요하지 않거나 지금 시점에 미래를 예상한 요구사항을 미리 말하기 어려운 주제는 생략하고 이 시점에 가장 확실한 기능을 모아 요구사항을 작성했습니다.

하지만 이를 보는 사람들은 기획서 상의 요구사항 뿐 아니라 여기에 언급되지 않은 자신들의 게임 경험에 비춘 이 모든 기능이 완성된 미래의 모습을 기준으로 하는 질문을 받았습니다. 한편 이들은 자신이 이와 비슷한 인터페이스를 본 가장 잘 만들어진 사례를 기준으로 생각하기 때문에 NPC 대화 인터페이스가 가장 정교하게 만들어진 텍스트 어드벤처 장르를 기준으로 질문을 했는데 이를 예상할 수 있는 질문에는 선택지의 유무, 대사를 통한 연출 제어, 인라인에서 어절 단위 텍스트 출력 속도 제어 같은 것이 있습니다.

텍스트 어드벤처 장르는 종종 대사에서 게임 전체를 제어하게 만들곤 했습니다. 그래서 대사 안에 분기, 연출, 화면 제어 등 게임 전체를 통제할 수 있었습니다. 그런데 우리는 텍스트 어드벤처 장르가 아니며 NPC 대화 인터페이스는 전체 게임의 일부에 불과합니다. NPC 대화 인터페이스는 이 인터페이스 바깥의 통제 수단에 의해 제어되는 여러 요소 중 하나일 뿐이어서 분기, 연출, 화면 제어를 대화를 통해 할 이유가 없습니다.

이런 답변을 반복해서 하다가 브리핑을 마치기 전에 모두에게 이번 마일스톤의 목표를 다시 한 번 상기 시켰습니다. 각 기능이 완전히 완성된 상태까지 한 번에 도달하는 것이 이번 마일스톤의 목적이 아니며 이번 마일스톤은 비공개 테스트를 무사히 치르고 뒤 이은 개발을 진행할 발판을 만드는 것입니다. 하지만 한편으로는 요구사항에 이 기능의 로드맵, 완전히 개발 되었을 때의 상태, 이번에 한 번에 그 단계까지 도달하지 않는 이유에 대해 좀 더 설명해 두면 좋겠다는 생각이 들었습니다.

전에 미래의 눈높이와 현재의 목표에서 지금 참여하고 있는 프로젝트 이야기를 했는데요, 생각 난 김에 이번에는 개발을 하며 겪은 적이 있는 상호작용 개발 사례를 소개하겠습니다. 게임에서 상호작용을 개발하는 방법은 전에 인터랙션 오브젝트 설계 (1), 인터랙션 오브젝트 설계 (2), 인터랙션 오브젝트 설계 (3)을 통해 다룬 적이 있습니다. 이 때는 멀티플레이어 론라인 게임에 흔히 사용하는 단순한 형태의 상호작용 가능한 대상을 만들어 관리하는 방법을 설명했는데 아직 우리는 게임에 이런 대상을 집어 넣을 단계는 아닙니다.

오히려 싱글플레이 슈터 장르에 자주 등장하는 상호작용 가능한 대상에 더 가까운 특징을 가진 뭔가를 만들어야 했습니다. 단순한 요구사항은 복도에 문이 있는데 이 문은 문 옆에 있는 버튼을 눌러야 열립니다. 버튼에 가까이 다가가 상호작용 입력을 하면 플레이어가 버튼을 누르고 이에 따라 문이 열리는 겁니다. 만약 이 상황이 사람이 아주 많은 멀티플레이 환경에서 일어나야 했다면 이 상황 자체가 필요하지 않도록 플레이 시나리오를 바꿨을 겁니다. 플레이어가 아주 많은 환경에서 열리고 닫히는 문처럼 상태가 바뀌고 이 상태가 플레이에 직접적으로 영향을 미치는 대상을 함부로 사용하면 아주 많은 문제에 시달리게 됩니다. 그래서 이런 요소가 플레이에 핵심 요소가 아니라면 개발 비용을 줄이기 위해 웬만하면 피하곤 합니다. 하지만 싱글플레이와 유사한 환경이거나 이 상태 변화에 영향을 받는 사람 수가 적은 인스턴스 공간이라면 이런 상태 변화는 환경을 재미있게 만들어 주기 때문에 피할 이유가 적습니다.

이 상호작용 기능을 준비하면서 자주 겪은 상황은 이 기능과 요구사항을 들은 사람들이 상상하는 모습이 내가 상상한 모습과 상당히 다르다는 점이었습니다. 제 머릿속에서는 우리가 만드는 게임은 멀티플레이 온라인 게임이기 때문에 게임에서 일어나는 모든 상호작용을 상상할 때 아 상호작용이 일어나는 순간 그 주변에 항상 여러 다른 플레이어들이 서 있는 모습을 포함합니다. 그래서 이 상호작용이 일어날 때 상호작용을 직접 수행하는 플레이어 본인 뿐 아니라 주변의 다른 플레이어들에게 이 상황이 어떻게 보여야 하는지, 또 이 상황에 따른 상태 변화가 여러 플레이어들에게 어떻게 영향을 끼쳐야 하는지를 자연스럽게 생각하게 됩니다.

그런데 비슷한 상황을 주변에 서 있는 다른 플레이어들을 생략하고 이야기하면 종종 이런 상호작용 사례는 그들이 경험한 가장 훌륭한 싱글플레이 게임의 한 장면을 상상하는 것 같은 인상을 받았습니다. 위에서 소개한 버튼을 눌러 문을 여는 사례를 설명하면 내가 조작하는 플레이어가 문에 다가가 상호작용을 시작하면 아주 자연스럽게 문 손잡이를 잡고 이를 돌려 문을 열고 그 사이로 몸을 집어 넣어 문을 통과하는 상상을 합니다. 그러면서 요구사항에는 언급하지도 않은 문을 열 때 일어나는 온갖 상황에 대한 걱정을 늘어 놓기 시작하고요. 여기에는 가장 자연스럽게 문을 여는 상황이 멀티플레이 환경에서 일어날 때 우리가 겪게 될 온갖 어려움을 포함하기도 합니다.

이쯤 되면 우리들 모두가 경험 많은 게임 개발자들이라는 사실을 잠깐 뒤로 한 채 멀티플레이 환경에서 상호작용과 싱글플레이 환경에서 상호작용이 어떻게 다른지, 또 싱글플레이 환경에서 경험한 가장 완벽한 상호작용이 실은 기술적인 상호작용이 아니라 완벽하게 만들어진 컷씬일 경우가 많다는 점을 상기 시킬 수밖에 없습니다. 싱글플레이 환경에서 일어나는 가장 완벽한 상호작용 상당수는 이 상호작용 전체를 컷씬으로 만들기도 합니다. 문 여는 사례에서 이 동작이 게임플레이에 핵심적인 장치가 아니라면 그저 문을 열고 지나가기만 하면 되는데 여기에 기술적인 노력을 기울일 필요가 별로 없습니다.

플레이어가 문을 여는 도중에 몬스터들이 플레이어를 공격하지 않도록 잠깐 기다려 줄 필요도 없고 플레이어가 문 여는 모습을 주변에 다른 플레이어들에게 동기화하고 또 문이 닫히거나 열린 상태에 따라 주변 다른 플레이어들의 공격이 문을 통과할 지 가로 막힐 지 판정할 규칙을 만들 필요도 없으며 다른 문은 강한 공격으로 파괴되지만 상호작용이 일어나는 도중의 문은 갑자기 강철로 바뀌어 파괴되지 않는다는 예외를 만들 필요도 없습니다.

그런데 온라인 멀티플레이 환경에서는 방금 말한 이 모든 상황을 신경 써야만 합니다. 가령 문과 상호작용하는 플레이어가 아직 상호작용을 다 끝내지 않아 문이 완전히 열리지 않은 상태에서 누군가 반쯤 열린 문 사이로 총을 쏘면 어떻게 해야 할까요. 이 문제를 MMO 장르나 슈터 장르에서 해결하는 방법이 조금씩 다르지만 별로 고려하고 싶지 않은 상당히 골아픈 문제입니다. 여러 번 이야기했듯 이 동작이 게임의 핵심 플레이와 관련이 크지 않다면 우리들이 각자 생각하는 가장 완벽한 싱글플레이 게임의 상호작용보다 훨씬 못한 모습이라 하더라도 어느 정도 선에서 타협해야만 합니다. 그렇지 않으면 기껏해야 가장 완벽한 싱글플레이 환경의 상호작용을 만들어 남들과 비슷한 수준에 도달했을 뿐인데도 엄청난 비용을 소모하며 또 핵심 플레이와 관련이 적어 핵심 플레이의 변경에 따라 기능 전체를 들어내야 하는 상황에 쉽게 처하게 됩니다.

우리들이 각자 집에서 경험한 싱글플레이 환경의 가장 완벽한 상호작용과 회사에서 개발하는 그저 그런 멀티플레이 환경의 상호작용 사이에 괴리를 이해하지 않으면 한정된 개발 비용을 엉뚱한 곳에 낭비하는 결정을 할 수 있습니다. 우리가 경험한 가장 멋진 사례와 우리가 개발하는 사례 사이의 차이에 항상 주의하고 핵심 플레이와 관계가 깊은 것과 그렇지 않은 것을 상시 구분하고 헛갈리지 않도록 노력해야 합니다.

이번주에도 마스토돈에서 글 쓰는 날을 보내고 있습니다. 특별한 건 아니고 일주일 중 어느 하루에 날을 잡고 몇 시간에 걸쳐 그 동안 쌓아 둔 여러 가지 주제로 최대한 빨리 글을 써 여러 가지 주제에 대한 글 여러 개를 작성해 공개하는 행동입니다. 이런 일정을 만들어 반복해서, 또 착실하게 수행하려고 노력하게 된 이유를 2022년 글쓰기 회고를 통해 소개한 적이 있는데 오래 전부터 몇 년 단위로 글이 잘 써지는 해가 있는가 하면 도무지 아무 것도 쓸 수 없는 해를 겪기를 반복하곤 했습니다.

개인적으로 스트레스를 해소하는 방법에는 크게 두 가지가 있는데 하나는 장거리 자전거를 타는 것, 다른 하나는 자리에 앉아 머릿속의 생각을 타이핑 하는 것입니다. 그런데 이 중 한 쪽을 잘 못 하게 되자 다른 한 쪽을 하는데도 스트레스가 충분히 풀리지 않는다는 느낌을 받아 왔습니다. 그러다가 반 년 정도 완전히 야근을 하지 않는 환경에 놓이자 조금씩 글을 쓸 수 있게 됐는데 이번에는 언제 또 다시 글을 못 쓰는 상태에 놓이게 될 지 모르니 쓸 수 있을 때 최대한 많이 써 보자는 생각을 하게 되었습니다.

그래서 2022년 7월부터 지금까지 일주일에 다섯 번 어떤 글이라도 트위터와 마스토돈을 통해 공유하는 실험을 시작했습니다. 그리고 이 공개 주기를 맞추기 위해 주말에 시간을 내 다음 번에 매일 공개할 글을 어떤 주제로라도 미리 적어 놓는 일정을 만들어 지키고 있는데 이게 바로 글 쓰는 날 일정입니다. 이렇게 한번에 써 놓은 글은 달력에 적어 놓고 이 일정에 따라 자동으로 공유되도록 해 놨지만 글을 만드는 족족 공유하는 것도 재미있다고 생각해서 매주 글 쓰는 날에 글을 하나 쓸 때마다 스레드를 만들어 실시간으로 공유하고도 있습니다. 이 때 공유한 글은 달력 맨 끝에 예약해 몇 달 뒤에 다시 한 번 타임라인에 나타나게 됩니다.

다시 글을 쓸 수 있게 되면서 이 기회를 최대한 활용해 볼 생각으로 최대한 여러 가지 주제에 대해서, 최대한 글을 여러 개 쓰는 일종의 속도 중심 방법을 사용하다 보니 문제점이 없지는 않습니다. 글을 빨리 완결 짓기 위해 온전한 문장으로 글을 쓰는 대신 음슴체로 쓴 다음 이를 문어체로 바꾸다 보니 어색한 문장이 자주 나타나는데다가 종종 몇 달 뒤에 타임라인에 나타난 글을 다시 읽어 보니 결론이 이상하다든지 이상한 소재를 근거로 제시했음을 늦게서야 발견하기도 합니다.

처음에는 이런 상황이 문제라고 생각했는데 또 한편으로는 몇 달 뒤에 내 글을 다시 읽고 그때서야 문제를 발견하면 문제를 해결한 새로운 글을 만들기를 반복하면 이것도 나름 조금씩 나아지는 방법 중 하나가 아닐까 하는 쪽으로 생각을 바꿨습니다. 내 마음에 드는 글을 만들기 위해 시간을 많이 써야 함은 당연하지만 한편으로는 이 글이 어디 기고될 것도 아니고 기껏해야 개인 블로그에 올려 둘 뿐인데 처음부터 너무 큰 노력을 기울이기보다는 글 하나에드는 노력을 조금 줄이고 더 다양한 주제에 더 다양한 글을 쓰는 쪽이 몇 년 만에 글을 쓸 수 있게 된 이 기회를 놓치지 않는 방법이다 싶었습니다. 그러다가 또 스트레스가 도져 글을 쓸 수 없게 되더라도 이전에 쓴 글의 이상한 점을 발견해 그걸 수정한 새 글을 작성하며 그나마 글을 아예 안 쓰는 상태에 도달하지 않고 버틸 수 있을 거라는 기대도 하고 있습니다.

최근에는 이렇게 한 주에 작성하는 글을 모은 가칭 ‘주간 글 쓰는 날’ 페이지를 만들고 있습니다. 누군가에게 한 주 마다 글을 쓰겠다고 약속한 것도 아니고 또 주간지 모양으로 글을 쓴 것도 아니지만 한 주 마다 쓴 온갖 주제의 글을 묶어 한 주 단위로 발행해 놓으면 이런 묶음 페이지가 여러 개 생겨 한 주 단위로 돌아볼 수 있게 되면 다른 사람들보다도 글을 쓴 자신에게 도움이 될 거라는 생각을 하고 있습니다.

결론. 마스토돈에 가끔 주말마다 글 쓰는 날이라며 글을 마구 토해낼 때가 있는데 이 글은 개인적인 스트레스 해소를 위해 주말에 시간을 내 글을 쓸 때마다 실시간으로 공유하는 것입니다. 글을 쓰는데 드는 시간을 최소화해 각각의 퀄리티가 떨어지는 대신 더 다양한 주제에 대한 글을 써 놓고 시간이 흐른 다음 다시 읽어 부족한 점을 고친 새 글을 쓰기를 반복하고 있습니다. 한 주마다 쓴 글을 모아 둔 페이지를 만들어 놓고 있는데 이들이 많이 쌓이면 뭔가 지금은 생각하지 못한 다른 용도나 재미가 생길 여지가 있지 않을까 생각해 봅니다.

지나가다가 게임 업계에서 게임을 서비스할 때 고객들과 직접 의견을 주고 받는 커뮤니티를 직접 만들어 생기는 여러 가지 부작용을 줄이기 위해 지금이라고 커뮤니티를 회사가 직접 만들지 않아야 한다는 의견을 읽었습니다. (원래 이 의견을 내신 분의 의견에 따라 글을 직접 링크하지 않았습니다.) 회사가 커뮤니티를 직접 만든 덕분에 게시판 너머에 있는 사람이 회사 직원이라는 점이 확실해지자 고객들은 이전에 비해 더 적극적으로, 때로는 공격적으로 요구사항을 표현하기 시작했습니다.

한편으로 이는 회사 입장에서 도움이 됩니다. 회사 밖에서 상상하는 것처럼 우리들이 하루 종일 게임을 플레이 하며 월급을 받지 않습니다. 오히려 우리들은 온갖 일에 치여 오히려 스스로 만드는 제품을 사용할 시간이 많지 않습니다. 그래서 종종 회사는 업무시간 외에도 직원들이 게임을 플레이 하게 만들기 위해 자사 게임에서 높은 레벨을 달성한 직원들에게 명예 보상을 하기도 하고 또 그렇지 않은 직원들에게 압력을 가하기도 하지만 높은 업무강도 때문에 스스로 개발한 게임에 스스로 애착을 가지고 플레이 하기를 요구하기는 아주 어렵습니다.

다른 한편으로는 커뮤니티를 통해 의견을 전달 받는데 관여하는 모든 직원들은 상당히 강한 멘탈이 필요합니다. 고객들은 종종 게시판 너머의 상대가 직원이라고 생각하는 순간 공격적으로 변하는데 이 표현들을 읽으며 이 글이 제품에 대한 것이라고 쿨하게 받아들이기는 쉽지 않습니다. 고객들은 이런 직원들의 특징을 파악해 제품 보다는 제품을 개발하는 직원 다수를 공격하거나 특정 가능한 직원 개인을 공격하기도 합니다. 그러다 보니 게임 커뮤니티로부터 항상 잡음이 일어나고 이 잡음이 커뮤니티 바깥에 긍정적으로 받아 들여지기는 어려울 겁니다. 게임 커뮤니티 때문에 이런 부정적인 효과가 일어난다고 생각하는 것도 너무나 당연합니다.

한편 회사가 이런 부정적인 문제에도 불구하고 게임 커뮤니티를 직접 운영하는 이유를 설명하겠습니다. 먼저 회사가 직접 커뮤니티를 운영하지 않더라도 커뮤니티는 생기기 마련인데 회사가 직접 관여하지 않는 커뮤니티는 게임 사용자가 늘어나고 커뮤니티 역시 활성화 되면서 고객들의 의견이나 회사의 의견과 거리가 있는 제 삼의 의견을 만들어내는 역할을 합니다. 커뮤니티가 활성화 되면서 커뮤니티 스스로 무게감 있는 의견을 말할 수 있는 주체가 되면 분명 회사의 다음 업데이트에 의견을 제시해 고객들에게 더 바람직한 방향으로 의사결정을 하는데 큰 기여를 할 수 있습니다.

그런데 종종 커뮤니티는 커뮤니티에 속한 핵심 인원들에게는 분명 직접적인 도움이 되지만 나머지에게는 도움이 되기 어려운 의견을 커뮤니티의 목소리를 빌려 말하곤 하는데 이런 상황을 깊이 이해하지 않은 여러 고객들은 쉽게 이 의견이 옳다고 생각해 버립니다. 그래서 회사가 판단할 때는 분명 문제가 있는 의견이지만 압력에 못 이겨 어쩔 수 없이 옳지 않다고 생각하는 의사결정을 하기도 하는데 이는 당연히 미래에 더 큰 문제를 일으킵니다.

오랜 세월에 걸쳐 이런 사례를 여러 차례 겪던 회사는 기존 서드 파티 커뮤니티를 직접 운영해야겠다는 교훈을 얻었습니다. 회사가 직접 제어하는 커뮤니티는 적어도 분명히 문제가 있는 의견이 큰 목소리를 빌려 압력으로 변하지 않도록 제어할 수 있습니다. 처음에는 직접 설명하겠지만 어느 정도 통제할 수 없는 상태에 도달하면, 혹은 도달하기 전에 이 의견을 가진 개인에게는 죄송하지만 이 개인으로부터 의견을 더 이상 듣지 않을 선택을 할 수 있습니다. 이전 서드 파티 커뮤니티에서는 불가능한 대응입니다.

또 한동안은 게임 웹진 사업자들이 직접 서드 파티 커뮤니티를 만들기도 했습니다. 게임 웹진 커뮤니티에는 이미 다양한 게임 고객들이 모여 있기 때문에 이 곳에 게임 전용 커뮤니티를 만들면 초기에 고객을 모으기 편리합니다. 그래서 게임 웹진이 먼저 커뮤니티를 만들고 커뮤니티가 일정 궤도에 도달하면 높은 월 이용 요금을 받고 회사가 커뮤니티를 운영할 수 있게 해 주기도 했습니다. 표면적으로는 회사가 커뮤니티를 통제할 수 있어 보였지만 시간이 흘러 커뮤니티가 서서히 하향하기 시작할 때 회사가 커뮤니티 통제 권한을 더 이상 구입하지 않기로 결정하면 웹진 사업자가 스스로 커뮤니티의 목소리를 자처하며 문제가 있는 의사결정을 강요하거나 프로젝트에 피해를 주는 행동을 하기도 했습니다.

이런 경험을 한 회사는 이제 직접 카페를 만들어 커뮤니티를 운영하기 시작합니다. 회사 입장에서 커뮤니티를 직접 운영하는 비용 역시 만만치 않습니다. 여전히 공격적인 고객들과 직원이 직접 마주치는 환경을 만들어 직원들의 멘탈을 갈아 넣어야 할 뿐 아니라 이전에 비해 고객들이 더 공격적으로 변하기도 했습니다. 또한 이번에는 웹진 사업자 대신에 카페 서비스 운영 회사에 카페 사용 요금을 지불해야 하기도 하고요. 물론 이번에는 요금을 지불하면 운영에 직접 관여하지 않으니 이전보다는 상황이 더 나아졌습니다.

이 환경을 통해 회사가 치러야 할 댓가는 여전하지만 이전에 비해 서드 파티 커뮤니티가 고객의 의견이나 이익과 무관한 의견을 큰 소리로 말해 곤란한 상황에 처할 위험을 줄일 수 있습니다. 그래서 온갖 문제에도 불구하고 직접 커뮤니티를 운영합니다.

아무리 자신이 있어도, 또 아무리 미래를 볼 수 있었더라도 회사 이름까지 바꿀 것은 아니었습니다. 여러 뉴스를 통해 메타버스에 돈을 냈던 회사들이 아무 것도 달성하지 못하고 사업을 철수한다는 소식을 접하곤 합니다. 고작 한 두 해 전만 해도 아무 사업에나 메타버스만 붙이면 돈을 받을 수 있었다고 전해지는 분위기와는 달리 시간이 조금 흐르고 보니 아주 많은 사람들이 걱정하던 대로 메타버스가 뭔지, 무엇을 할 수 있는지, 왜 사람들이 이 설명할 수 없는 뭔가에 열광하고 사용하기 시작할지 설명할 수 없는 이상 사업에 돈을 내던 사람들조차 설득할 수 없다는 사실을 이제야 깨달은 것 같습니다.

메타버스라는 키워드가 나타났을 때 이를 최대한 긍정적으로 받아들이려고 노력하며 스스로 이개념을 설명하기 위해 노력했습니다. 실제로 메타버스와 비슷한 뭔가를 개발하며 여러 세계 사이에 물건 호환방법을 생각해 보거나 메타버스는 스스로 자신이 메타버스임을 입증할 수가 없다 같은 주제로 생각해보기도 했습니다. 한편으로는 여러 사람들이 갑작스레 시장에 나타나 주장하는 메타버스는 적어도 20년 이상 전부터 게임 업계에서 만들어 온 개념과 별로 다르지 않음에도 기존 게임과는 다르다는 주장을 바라보며 긍정적으로 바라보고 또 이해하려고 노력하는데 한계가 있다는 생각을 하기도 했습니다.

이제 모든 사람들의 주머니에서 돈이 사라지고 회사 이름을 바꾼 그 회사마저도 주주들로부터 매 분기마다 압력을 받고 있는 상황을 지켜 보며 메타버스 키워드에는 무슨 문제가 있었는지, 또 여전히 메타버스에 발을 담그고 있는 입장에서 이 상황을 어떻게 이해하고 있는지 설명하겠습니다.

메타버스를 정의하기 어려웠던 이유는 이 말이 기존에 게임 업계가 20년 넘게 만들어 온 가상 세계와 뭔가 다른 점을 억지로 만들어 내야 했기 때문입니다. 겉으로는 아무리 봐도 극도로 초보적으로 만들어진 삼차원 공간일 뿐인데 거기에 기존의 가상 세계와 다른 특징을 억지로 부여하려는 순간 다리도 꼬이고 혀도 꼬이고 손가락도 꼬입니다. 메타버스는 가상세계와 똑같은 말입니다. 게임 업계에서 지난 20년 넘는 세월에 걸쳐 만들어온 그것과 전혀 다르지 않습니다. 가상 세계에는 그 세계의 규칙이 있고 플레이어들은 이 규칙에 적용을 받으며 게임을 플레이 합니다. 이를 가상 세계에서 생활한다고 표현해도 전혀 틀리지 않은데 이 가상 세계가 곧 메타버스입니다. 메타버스는 새롭게 나타난 개념이 아니라 기존 게임 업계가 하던 비즈니스 중 하나를 다른 말로 표현해 이 같음을 구분하지 못하는 투자자들에게 돈을 얻어내기 위한 말입니다.

그러면 왜 사람들은 메타버스라는 말에 그렇게 쉽게 열광했을까요. 전통적인 온라인 게임 업계가 20년이 넘는 세월에 걸쳐 도달한 위치에 지금부터 진입하기에는 난이도가 엄청나지만 시각적으로 그와 비슷한 뭔가는 상대적으로 쉬워 보였을 수 있습니다. 게임 개발에 처음으로 돈을 투자하는 주체들이 종종 게임 개발에 예상보다 훨씬 더 큰 고정비용이 들어간다는데 놀라곤 합니다. 대충 사무실 임대하고 책상의자 놓고 컴퓨터 놓고 사람들 월급 주며 한 2년 기다리면 대박을 터뜨리는 제품이 나올 줄 알았는데 갑자기 들어본 적도 없는 온갖 하드웨어와 온갖 소프트웨어를 사달라고 하기 시작하는 데다가 수익을 떼 가는 주체들은 또 왜 그리 많으며 사람들은 왜 그리 쉽게 다른 팀으로 옮겨 가는지 이해하기 쉽지 않을 겁니다. 이런 문제를 해결하는 간단한 방법은 더 많은 돈을 사용하는 것이지만 책상, 의자, 컴퓨터만 사 주면 될 거라고 생각한 입장에서 돈을 더 낼 결정을 하기는 쉽지 않을 겁니다.

하지만 메타버스는 게임 개발의 그런 어려움을 건너뛰고 손쉽게 대박을 터뜨릴 수 있는 완성된 상태에 도달할 수 있어 보입니다. 게임 프로젝트는 반 년 전이나 지금이나 별로 달라진 것이 없어 보이는데도 개발팀 전체가 강행군을 하며 앓는 소리를 내는데 비해 메타버스는 레벨 안에 사람들이 동기화된 상태로 돌아다니는 상테에 도달하기만 하면 완성된 상태처럼 보입니다. 하지만 메타버스 역시 메타버스 추종자들 - 제 스스로도 어느 정도 그렇다고 생각합니다. - 의 기대처럼 전통적인 게임과 비교할 때 높은 자유도와 상호운영성 따위를 갖추려면 닫힌 규칙으로 동작하는 게임의 가상 세계와 비교해 엄청난 개발 비용이 필요합니다. 이 비용을 듣는 순간 돈이 아무리 많아도 뭔가 예상과 다르다고 느꼈을 겁니다.

메타버스와 가상현실 장치가 서로 연결되어 시너지를 낼 수 있을 거라고 예상했을 겁니다. 아이폰 이후 하드웨어 하나가 시장 전체를 바꿀 수 있으리라는 기대는 곳곳에 있어 왔습니다. 잡스가 죽은지 십 년도 넘었지만 여전히 그가 화면에 펏 번째 아이팟을 띄우고 음악 산업 전체를 바꿨으며 아이맥을 띄우고 컴퓨터 업계 전체를 바꿨고 이제 시장을 바꿀 세 가지 제품을 한 번에 소개한다고 하던 그 순간을 추억하곤 합니다. 어쩌면 가상현실 장치는 아이폰이 이루어 낸 그런 위업에 근접할 가능성이 있을 수도 있습니다. 게다가 그런 장치와 기존 게임 업계의 위치에 한 번에 도달할 수 있을 것 같은 메타버스가 함께 움직인다고 생각하면 이들의 시너지를 평가할 만한 사용 경험이 없더라도 돈을 걸 생각을 해볼 만 한 조합일 수 있습니다.

하지만 가상현실 장치는 마치 배터리처럼 물리적인 장벽에 부딪쳐 발전을 거듭하고는 있지만 시장 밖에서 보기에는 거의 발전하지 않는 것처럼 보이는 상태에 도달했습니다. 장치는 여전히 엄청나게 비싸고 장치를 사용하기 위한 설정은 여전히 복잡하며 하루 종일 들여다 보고 나서도 피곤한 눈을 좀 깜빡인 다음 주머니에 넣어 두면 그만인 스마트폰과 비교해 가상현실 장치는 이런 사용경험 근처에도 도달하지 못했습니다. 때문에 가상현실 장치의 발전은 이전 시대에 비해 더 더뎌졌고 가상현실 장치의 흥행에 어느 정도 의존한 메타버스 역시 발전이 더뎌질 수밖에 없었습니다.

가상세계에는 세계의 목적이 필요합니다. 전통적인 게임 회사들이 지난 20년이 넘는 세월에 걸쳐 가상 세계를 만들며 중요하게 여긴 것은 이 가상 세계를 살아가는 삶의 목적이었습니다. 플레이어들이 이 세계를 플레이어 한 명으로 받아들이기 시작해 자신의 현실 세계의 생활과 함께 이 가상 세계에서 생활을 영위해 나가기 위해서는 실질적인 이유가 필요합니다. 가상 세계에서 체험할 수 있는 시청각적 경험, 이 세계의 장대한 역사와 그 역사의 현장을 직접 체험할 수 있는 방법을 제공했고 세계 속에서 플레이어 개인이 시간을 투자함에 따라 점점 더 강해지며 더 넓은 세계를 탐험할 수 있고 그런 경험들이 가상 세계 안의 플레이어와 유저 자신의 추억으로 남으며 이런 경험을 공유할 수 있는 실제 세계의 다른 유저들이 있었기 때문에 꽤 큰 시간과 비용을 들이면서도 가상 세계의 생활을 계속합니다.

메타버스 업계에서는 가상 세계를 구축해 놓으면 그 안에 플레이어들이 모여들어 가상 새계의 존재 목적이 자생적으로 생겨날 거라고 생각했지만 현실은 전혀 그렇지 않았습니다. 학교 다닐 때 친구와 PC방에 가서 처음으로 리니지를 접했는데 그 전까지는 스토리가 있고 게임이 내게 할 일을 권해주는데 익숙해져 있다가 리니지를 접하니 뭘 해야 할 지 잘 알 수가 없었습니다. 친구에게 ‘뭐 해야 함?’ 하고 물었더니 그가 짧게 ‘몹 쳐’ 라고 말했고 저는 마우스로 몹을 찍기 시작했습니다. 그때는 리니지의 이 경험이 어처구니 없다고 생각했지만 시간이 지나 메타버스와 함께 생각해보니 리니지는 적어도 몹을 쳐서 내가 강해지는 최소한의 목표가 있는 가상 세계입니다.

반면 메타버스는 정말로 아무 것도 할 일이 없는 완전히 목적이 없는 가상 세계였습니다. 심지어 억지로 만들어 낸 목적 역시 플레이어들을 설득하기 어려웠습니다. 전통적인 게임이 가상 세계에서 용을 때려잡기 위해 강해져야 한다고 설득한다면 설득될 것 같지만 가상 세계에서 전시회를 보고 주민등록 등본을 뗄 수 있다고 하면 고개를 갸웃거릴 수밖에 없습니다. 용은 가상 세계 안에서만 때려 잡을 수 있습니다. 반면 주민등록 등본은 지하철 역에 있는 무인 장치에 몇 백원을 내면 발급 받을 수 있는데 뭐 하러 위에 설명한 복잡한 가상현실 장치를 동반해 메타버스에서 이 행동을 해야 할까요? 메타버스가 제안한 메타버스를 사용할 이유는 현실 세계와 비교할 때 경쟁력이 없습니다.

메타버스라는 개념은 어쩌면 가상현실 장비와 함께 세계를 바꿀 수 있을지도 모릅니다. 하지만 그러려면 먼저 지난 20년이 넘는 세월에 걸쳐 게임 업계가 고민해 온 가상 세계의 존재 이유와 이 세계가 실제 세계와 비교해 경쟁력이 있음을 고객들에게 납득 시킬 수 있도록 충분히 고민해야 합니다. 또한 메타버스가 전통적인 가상 세계와 별로 다르지 않으며 비슷한 고민과 설득이 필요하고 또 전통적인 게임에 맞먹거나 이를 상회하는 시간과 노력과 돈이 필요하다는 점에 동의하기 전에는 결코 메타버스 개발로 성공할 수 없을 겁니다.

배달 앱을 통해 포장 주문을 한 다음 가게에 가면 이런 말을 듣곤 합니다. 배달 앱을 사용하는 대신 직접 전화 주문을 하면 가격을 할인해주거나 원래는 포함되지 않는 커피를 받을 수 있는 등의 이익이 있으니 다음 부터는 전화 주문을 해 달라고요. 목적이 너무 잘 이해되는 데다가 전화 주문을 할 때 내가 얻을 수 있는 이익 역시 확실합니다. 이 이익만 고려한다면 전화 주문을 하지 않는 내가 오히려 이상할 지경입니다.

아직 까지는 배달 앱을 사용한 포장 주문에 별도 요금을 부과하지 않고 있다고 알려져 있지만 오래 전부터 포장 주문에 요금을 부과할 예정이라는 간보기 목적이 강해 보이는 기사가 여러 차례 나온 바 있습니다. 포장 주문에 비용이 부과되고 나면 분명 배달 앱 서비스 회사는 이익을 얻게 되겠지만 마치 택시 요금을 올리자 수요가 극적으로 줄어들어 이익 역시 줄어든 것 처럼 주문 수요 자체에 영향을 줄 가능성이 없지는 않습니다. 그런 상황에 대비해 가게들은 두 번째 선택을 준비해야만 하는 상황일 겁니다. 하지만 다른 노력 없이 전화주문을 우대하는 정책 만으로는 포장 주문이 유료화될 시대에 전화 주문이 두 번째 선택이 될 가능성은 낮습니다. 앱을 통한 주문은 이미 이전 시대에 전화 주문이 가진 단점을 해결했기 때문입니다.

먼저 주문하기 전에 메뉴를 미리 알고 있어야 하는 부담이 없습니다. 전화를 통해 주문을 하다 보면 주문하는 사람이 이미 가게의 모든 메뉴를 알고 있다고 가정할 때가 있습니다. 대뜸 ‘뭘로 하시겠어요?’ 라고 말할 때 느끼는 당혹스러움을 표현하기는 쉽지 않습니다. 주문하기 전에 미리 지도 앱이나 웹사이트를 검색해 메뉴를 알아낸 다음 주문할 준비를 마친 다음에야 전화를 할 수 있는데 이미 스마트폰을 통해 메뉴를 조회했는데 그 옆에 주문 버튼이 달려 있다면 이를 사용하지 않을 이유가 없습니다. 또 주문을 받는 사람들은 대체로 아주 바쁜 상태인데 주문하는 사람이 메뉴를 숙지하지 못하고 있을 때 이 상태에 짜증을 내기도 합니다. 이 분들을 이해하지 못하는 것은 아니지만 당연히 주문할 사람은 그 가게의 메뉴나 현재 사정을 인지하지 못하고 있을 수 있고 그런 상태를 기대할 수도 없습니다. 배달 앱을 사용하면 이런 상황을 완전히 피할 수 있습니다.

복잡한 옵션을 전화를 통해 주문하는 어려움을 겪을 필요가 없습니다. 이전 시대에 메뉴의 옵션이라고 해 봐야 보통과 곱배기 정도가 다였습니다. 하지만 지금은 앱을 통한 주문을 가정하면서 옵션이 이전에 비해 훨씬 복잡해졌습니다. 메뉴 하나를 주문하려면 메뉴 자체와 함께 매운 정도, 조리 정도, 토핑, 음료, 서브메뉴 따위를 여러 번 선택해야만 메뉴 한 가지의 주문을 마칠 수 있는데 옵션을 선택할 때마다 가격이 바뀔 경우 이를 전화를 통해 주문하다 보면 문제가 생길 수 있습니다. 앱을 통해 주문하면 변경되는 가격을 바로바로 알 수 있지만 전화를 통해 별 생각 없이 옵션을 선택하다 보면 순식간에 가격이 올라가 가격을 듣고 주문을 다시 하기를 원할 수도 있습니다. 이 때 앞에서 이야기 한 항상 바쁜 주문 받는 분의 짜증을 온 몸으로 받아내야 할 수 있는데 이번에도 앱을 통하면 이런 문제를 완전히 피할 수 있습니다.

전화를 통하면 보안 사고에 의한 범죄에 쉽게 노출될 수 있습니다. 전화를 통해 주문하면 가게는 내 전화번호와 주소를 확보하게 됩니다. 이는 배달을 수행하기 위한 최소한의 핵심 정보이지만 종종, 또 생각보다 자주 이 정보가 유용되어 범죄에 사용되기도 합니다. 또한 명백한 범죄 단계에 도달하지 않더라도 분쟁이 발생할 때 주문한 사람에게 위협이 되는 상황에 쉽게 놓입니다. 배달 앱을 통하면 여전히 내 연락처와 주소를 노출하기는 해야 하지만 이 두 가지 정보가 동시에 가게에 넘어가지는 않습니다. 배달 앱 서비스가 중간에서 이 정보의 도달을 통제하며 직접 연락을 최소화 합니다. 이는 문제가 생길 때 수습을 어렵게 만들기도 하지만 주문 과정에 관여하는 각 주체들의 익명성을 어느 정도 유지해 개인정보가 범죄에 유용되거나 위협을 가할 여지를 줄이고 있습니다.

이런 이유들 때문에 단지 전화 주문이나 전화 포장 주문을 우대한다고 해서 이 방법이 근미래에 다가올 배달 앱을 통한 포장 주문 유료화 시대에 두 번째 선택이 되기는 쉽지 않을 겁니다. 가게 혼자서는 전화 주문 우대 이외의 방법을 상상해내기 쉽지 않겠지만 이 방법이 별 효과가 없으리라는 점을 인정하지 않으면 효과가 있는 방법에 접근할 수 조차 없을 겁니다.

개발하다가 일어나는 일을 종종 미래의 눈높이와 현재의 목표, 온라인 멀티플레이 게임과 가장 완벽한 상호작용 같은 글을 통해 소개하곤 하는데 이번 프로젝트는 과거의 다른 프로젝트와 비교해 개발하며 일어나는 일을 공유하는데 더 약한 제한이 있기 때문입니다. 다른 프로젝트 같으면 당연히 회사 밖에서는 입이 없고 회사 전체에 유일한 입은 PR 부서에 있을 뿐이었으며 개발 관련된 어떤 정보도 실수로라도 공유해서는 안되는 강한 보안 규칙을 적용 받고 있었습니다. 그런데 이번에는 흥미롭게도 개발하며 일어나는 사건 사고, 또 우리들의 개발 상황 같은 주제에 대해 상대적으로 느슨한 제한에 따라 이야기할 수 있게 됐습니다

덕분에 이전에 비해 좀 더 편안하게 프로젝트에 참여하며 겪는 여러 가지 일을 소개할 수 있게 되어 개인적으로 나쁘지 않다고 생각합니다. 아주 오래 전에 겪은 일을 그 때 일기를 동원해 이제 와서 소개하려고 해도 요즘 시대에 잘 어울리는 정보나 사례가 아니기가 쉽기 때문에 소개하기 어려운데 이번에는 지금 당장 일어나는 일을 소개하고 또 문제를 해결하거나 의사결정을 하는 과정 자체를 설명할 수 있어 설명하는 입장에서도 재미있고 또 현재 시점에 어느 정도는 어울릴 거라 예상합니다.

MMO 장르의 흔한 PvE 환경을 준비하며 레벨에 스폰 된 플레이어가 목표를 찾아 이동하고 행동하게 할 방법을 마련해야 했습니다. 모든 준비를 갖춘 이미 출시된 게임을 생각해 보면 화면에 지금 수행해야 하는 목표가 퀘스트 모양으로 나타나고 또 바닥에 이동 경로를 그려 주거나 화면 어딘가에 미니맵을 표시하거나 화면 상에 인디케이터를 띄워 방향과 거리를 안내해 주기도 합니다. 우리는 이런 방법 모두를 남은 기간 안에 채용할 수 없는 상황이기 때문에 이들 중 비용 대비 효율이 너무 떨어지지 않는 방법을 선택해야 했습니다.

우선 퀘스트 모양은 꽤 괜찮기는 하지만 개발에 참여하는 우리들 스스로도 일부만 완성된 상태를 상상해 그 수준까지 개발하기 쉽지 않기 때문에 고려하지 않았습니다. 일단 퀘스트처럼 보이는 인터페이스가 화면에 나타나는 순간 개발팀 전체가 그걸 이미 완성된 퀘스트라고 착각하고 완성된 퀘스트를 통해 경험한 온갖 기능의 부재를 문제 삼기 시작하는데 제한 시간 안에 완결된 빌드를 만들어내는데 심각한 문제를 일으키기 때문입니다.

미니맵도 고려하지 않기로 했습니다. 미니맵은 꽤 단순해 보이지만 본격적으로 이걸 잘 만들려고 마음먹으면 결코 간단하지 않습니다. 우선 미니맵에 표시할 에셋를 별도로 제작해야 하는데 단순히 레벨을 탑뷰에서 찍은 이미지를 미니맵 에셋으로 사용할 수는 없습니다. 물론 탑뷰에서 찍은 이미지를 기준으로 시작하기는 하지만 의도를 가지고 리터칭을 한 다음에야 미니맵에 사용할 수 있습니다. 하지만 우리는 지금 미니맵에 아무런 의도를 가지고 있지 않았기 때문에 그저 보기 좋은 모양으로 만들기 위한 리터칭은 재작업 가능성이 너무 높았습니다. 또한 미니맵 상에 표시할 대상과 표시하지 않을 대상, 정적으로 존재하는 대상과 동적으로 존재하는 대상의 표시 방법 결정, 특정 지점과 범위를 표시할 정책과 방법 같은 단시간 안에 동작을 정의하고 이를 구현하기 쉽지 않으리라 판단했습니다.

카메라 방향과 대상의 방향이 일치하면 화면 안에 그 대상의 위치와 거리를 표시하는 수준으로 구현하기로 했습니다. 물론 대상과 반대 방향을 바라보면 화면에 아무 표시도 나타나지 않겠지만 게임 안에서 목적을 잃었을 때 주변을 둘러보며 인디케이터를 찾은 다음 그쪽으로 이동하기 시작하면 지금 싸움이 일어나고 있는 위치에 도달할 수 있습니다. 인디케이터 인터페이스만 결정하면 중요한 결정 요소가 거의 없습니다. 중간에 뭔가 문제가 생겨도 기획적 문제보다는 대부분 기술적 요소일 가능성이 높아 부담이 적었기도 했고요.

한편 이런 의사결정을 뒤로 하고 슈터 장르 게임에서 PvE 또는 PvP 모드에서 상황에 따라 지금 수행해야 할 목표를 그때그때 플레이어에게 알려주는 기능을 게임 규칙 자체에 내장한 모드는 CTF입니다. 데스매치나 팀 데스매치 같은 규칙은 상황에 따라 목표가 달라지기는 하지만 개개인마다 우선시 하는 목적이 다르기 때문에 상황마다 서로 생각하는 목적이 다를 수 있습니다. 나는 내 눈 앞의 적을 죽이는데 관심이 있지만 팀 전체 관점에서는 누구든 빨리 새로 스폰 된 헬스를 먼저 먹어 상대 팀이 먹지 못하도록 하는 것이 더 중요할 수도 있습니다.

반면 CTF는 상황에 따라 각자가 수행해야 할 목적이 꽤 잘 일치됩니다. CTF의 상황은 한 쪽 팀을 기준으로 우리 팀 깃발이 제 자리에 있거나 누군가가 탈취한 상태이거나와 상대 팀 깃발이 제 자리에 있거나 우리 팀 누군가가 탈취한 상태인 네 가지 상태가 있습니다. 상황을 좀 더 정확히 보려면 각 상황이 상대 팀에 어떻게 해석되는지를 추가로 생각해 보면 되지만 그러면 본격적으로 복잡해지니 한 팀의 네 가지 상태가 있다고 보면 됩니다. 이 네 가지 상황에서 플레이어들의 마이크로퀘스트는 굳이 알려주지 않아도 규칙을 이해하고 있다면 비교적 명확합니다.

우리 팀 깃발이 탈취 당한 상태라면 그 깃발이 상대 진영에 도달하기 전에 깃발을 든 플레이어를 죽여야 합니다. 이보다 중요한 목표는 없습니다. 반대로 우리 팀이 상대편 깃발을 탈취한 상태라면 그 플레이어를 보호해야 합니다. 누군가를 죽이더라도 이 행동은 상대편 깃발을 들고 있는 우리 편 플레이어를 보호하기 위한 행동이어야 합니다. 만약 상대 팀의 약한 플레이어가 눈 앞에 있더라도 이 플레이어를 함부로 죽여 자기 진영으로 돌아가 무기를 먹고 돌아오지 않도록 적당히 통제하는 선에서 놔 두는 결정이 더 나을 수 있습니다.

현대의 슈터 장르는 종종 지금 해야 할 일을 게임 규칙 차원에서 알려주는 사례가 많습니다. 한때는 퀘스트나 미니맵 모양을 사용했지만 작위적이고 익히기 쉽지 않으며 창발적인 플레이를 제한합니다. 반면 자기장을 피하거나 시점에 따라 모르는 상대와 협동하거나 경쟁하거나 전투를 그만 두고 탈출하는데 집중하는 등 시점에 따라 달라지는 목적은 작위적이지 않아 상황에 몰입하게 만들며 창발적인 플레이를 하도록 압력을 가합니다. 개인적으로 이런 플레이의 기초는 CTF 규칙이라고 생각하며 슈터 장르의 작위적이지 않은 플레이 규칙을 만들려고 할 때 여기서부터 시작하면 도움이 될 거라고 생각합니다.

이미 마스토돈에서 아무말을 계속할 수 있을까를 생각해 보면서 이 사례를 소개한 적이 있는데 마스토돈의 인용 부재는 따로 생각해볼 만 하다는 생각이 들었습니다. 처음 마스토돈을 사용하기 시작하면서 아주 불편하다고 생각한 점은 인용과 검색이 없다는 점이었습니다. 트위터도 처음에는 인용 기능 뿐 아니라 심지어 리트윗 기능도 없었습니다. 사람들이 리트윗을 하기 시작하자 원래 글 쓴 사람 대신 리트윗 한 사람의 글이 더 널리 인용되는 사례가 자주 일어났고 결국 정식 리트윗 기능이 추가됩니다.

인용 역시 처음에는 그저 트윗 주소를 글 안에 붙여 넣었을 뿐이었는데 이런 방식으로 인용을 한 글에 의한 상호작용은 원문을 작성한 사람에게 전혀 전달되지 않아 오히려 원문을 작성한 사람은 이후 논의에 참여할 수 없었고 심지어 논의가 일어나고 있다는 사실을 알 수도 없었습니다. 인용 기능이 추가되면서 주소를 붙여 넣는 방식의 인용에도 원문을 쓴 사람은 무슨 일이 일어나고 있는지 파악할 수 있게 됩니다.

이런 기능은 의견을 주고 받거나 글에 대한 긍정이나 부정을 편리하게 표현할 수 있게 만들었지만 한편으로는 글 쓴 사람을 공격하는 방식으로 사용되기도 했습니다. 인용은 상호작용을 통한 논의를 원문을 작성한 사람이 파악할 수 있도록 하는 의도로 만들어졌지만 인용문에 의해 부정적인 의견이 나타나기 시작하면 원문을 작성한 사람이 이 모든 부정적인 의견과 대면해야 했기 때문에 이 상황을 불편하게 생각하는 사람이 이 사실을 표현하는 순간 이를 공격하는 방법으로 전용됩니다.

그래서 어떤 사용자들은 인용을 원하지 않는다고 별도의 트윗, 프로필, 핀 트윗에 기입해 두기는 했지만 이런 요구사항은 실질적인 효력을 기대하기는 어렵습니다. 접근성이 떨어지기도 하고 공격하기로 마음 먹은 사람들 입장에서 이런 글은 오히려 글 작성자의 약점을 노출하는 행동에 지나지 않기 때문입니다. 공격을 피하려는 행동이 오히려 약점을 드러내는 행동으로 나타나는 점은 따로 생각해볼 주제입니다.

검색 역시 비슷한 결과로 이어졌는데 검색 자체가 필요한 이유를 굳이 설명할 필요는 없을 겁니다., 하지만 검색 역시 종종 누군가를 공격하는 상황에서 이전에 그 사람이 했던 말, 상호작용 등을 찾아내 현재에 다시 소환시킴으로써 같은 인물의 과거와 현재 사이에 생각의 변화에 따른 행동의 불일치를 추긍하는 용도로 쉽게 전용 됩니다. 그래서 아카이빙과 검색의 유용함에도 불구하고 오래된 트윗을 삭제하거나 계정을 비공개로 만들기도 합니다.

이런 과거를 알고는 있지만 마스토돈에 인용이 없다는 점은 그냥 그 자체로 불편하고 또 이해하기 쉽지 않았습니다. 이런 상황을 만족하는 분들도 있는 반면 개인적으로는 어처구니 없었고요. 마치 자동차에 의해 말이 치여 죽는 사고가 빈번해지자 적기조례를 발표한 것과 별로 다르지 않다고 생각합니다. 인용이 일어나더라도 원래 글 작성자에게 이를 알리지 않음으로써 미래에 발생할 수도 있는 공격을 막을 수 있지만 한편으로는 원래 글 작성자가 참여할 수도 있었을 의견 교환으로부터 완전히 배제되는 결과를 가져오기도 합니다.

한편 최근에는 원래 글 작성자에게 알림이 가지 않는 인용을 원하지 않으며 하고 싶은 말이 있으면 멘션을 하라고 적어 둔 분의 글을 실수로 인용한 적이 있었는데 트위터에서와 똑같은 생각이 들었습니다. 저는 그 분께 말 하고 싶은 생각이 없었습니다. 그저 그 분의 글에 의견을 말하고 싶었을 뿐인데 졸지에 그 분이 정해 놓은 규칙을 지키지 않은 사람이 됐고 개인적으로 차단 당할 위기 뿐 아니라 마스토돈에서 아무말을 계속할 수 있을까에서 소개한 유명 인스턴스로부터 인스턴스 전체 단위로 차단 당할 수 있는 위기에 노출됐습니다. 별로 긍정적인 상황이라고 생각하지 않습니다.

앞으로 다른 분의 글에 대한 의견을 말할 때는 아예 원문을 인용하지 않고 ‘그런 글을 지나가다 읽었는데요'로 시작하며 글을 쓰고 있는데 이는 마치 리트윗이 없던 시대에 원래 글을 쓴 사람의 글을 훔치는 것 같은 기분이 들어 여전히 마음이 편하지는 않습니다. 하지만 적어도 인스턴스가 통째로 차단 될 위험을 감수하는 것 보다는 훨씬 낫습니다.

마스토돈에 검색이 없다는 점은 이 서비스가 장기적으로 마이크로블로깅 도구로써 역할을 수행하는데 강한 제약으로 작용할 거라고 생각합니다. 글을 쓰는 개개인의 기억력에는 한계가 있기 때문에 글을 남기더라도 미래에 이 사실을 잊을 수 있습니다. 때문에 검색을 통해 자기 자신이 과거에 작성한 글, 또 다른 사람이 과거에 작성했던 글에 검색을 통해 접근함으로써 개개인의 기억력의 한계를 극복하고 또 그저 오래된 글이라고 해서 스토리지를 차지한 채 전기를 낭비하는 데이터 쓰레기가 되는 대신 현대에 글을 다시 소환해 의견을 계속해서 교환하거나 현재의 의사결정에 활용할 수도 있습니다.

하지만 마스토돈에는 검색 기능이 사실상 없는 것과 똑같고 굳이 마스토돈에서 뭔가를 검색하고 싶으면 마스토돈 웹사이트를 크롤링 한 검색 사이트를 통해 검색할 수밖에 없는데 서로 다른 인스턴스로 분리되어 있는 마스토돈의 특성 상 검색 사이트를 통해 검색하기는 대단히 어렵습니다. 마스토돈이 지원하는 엘라스틱 서치 역시 서비스를 관리하는데 드는 비용에 비해 형편 없는 수준의 결과밖에 보여주지 못합니다. 이런 형편 없는 검색 기능으로부터 안전함을 느끼는 분들이 있음을 알고 있으며 이 안전함은 인터넷에서 다른 사람들과 연결될 때 가장 중요한 요소입니다. 반면 검색 기능이 없기 때문에 마스토돈이 안정적인 마이크로블로깅 도구로써 미래로 이어질 수 없을 겁니다.

결론. 마스토돈에 인용과 검색 기능이 없는 특징은 분명 어떤 분들께 안전한 느낌을 받게 해 좀 더 편안하고 또 적극적으로 인터넷에서 사람들과 연결될 계기를 제공합니다. 한편 이 기능이 없음으로써 마스토돈이라는 마이크로블로깅 플랫폼이 긴 시간에 걸쳐 의미를 가지고 발전해 나가는데 어려움이 있을 겁니다.