입퇴장 메시지 사례로 보는 비용예측의 어려움

게임디자인은 종종 재미있는 게임의 규칙을 설계하고 실험해 재미 있는 플레이를 만들어 내는 역할에 국한된다고 생각할 수 있습니다. 미디어에서 주로 보여주는 게임디자인의 가장 흥미로운 역할이 이 부분이기도 하고 회사에서 모든 사람들이 기회가 될 때마다 이 일을 하고 싶어 하기 때문에 이런 일만 있다고 생각하는 것도 무리가 아닙니다. 하지만 현대의 게임 소프트웨어는 핵심 플레이와 이를 지탱하는 나머지 시스템, 그리고 인프라 등으로 구성된 아주 복잡한 모양이고 이 전체를 지탱하기 위해서 게임디자이너는 주로 전통적인 소프트웨어 개발 과정에서 설계 역할을 담당하는 경우가 더 많습니다.

게임디자이너를 소프트웨어 설계 역할을 하는 사람으로 생각해 보면 게임 개발이 다른 소프트웨어 개발에 비해 왜 그리 어렵고 힘든지 추측할 수 있습니다. 다른 소프트웨어 개발 분야에서 설계는 가장 경험이 많은 사람들이 담당하곤 하지만 게임 소프트웨어 개발에서는 기묘하게도 바로 위에서 설명한 가장 재미 있는 일일 수록 경험 많은 사람이 담당하지만 이를 지탱하는 나머지 부분은 팀에서 경험이 가장 적은 사람이 담당하게 하는 경우가 많기 때문입니다.

실은 시간이 지날 수록 게임 서비스 전체에 대한 시야가 넓어지며 서비스 전체 설계를 조금씩 더 편하게 할 수 있게 되는데 비해 언제까지나 에이스로 살 수는 없다에서 설명했던 것처럼 팀이나 회사에서는 그런 제가 전체 서비스를 설계하는 역할 보다는 프로젝트와 팀을 관리하고 위에서 말한 게임디자이너로써 더 잘 알려진 역할에 집중하기를 원합니다. 그러면 다시 핵심 게임디자인을 제외한 나머지 부분을 경험이 적은 사람이 설계하는 악순환이 반복되곤 합니다.

하지만 시간이 지나 경험이 쌓여도 여전히 자잘한 부분을 설계하고 이들의 개발 비용과 복잡성에 끼칠 영향, 미래에 발생할 문제 따위를 예상하는 일은 비슷한 일을 여러 번 해봤음에도 여전히 쉽지 않습니다. 어쩌면 이런 절차들을 철저하게 문서화 했다면 기억에 의존하며 어려움을 반복할 가능성이 훨씬 줄어들겠지만 거의 모든 프로젝트는 기획서 류를 문서화하는데 집중하기는 하지만 각자의 업무 방식이나 여러 프로젝트에 걸친 비슷한 업무 절차를 문서화 하는 데는 거의 관심이 없습니다.

그래서 개인적으로는 업무 기록을 최대한 많이 남겨 여러 프로젝트에 걸친 개인 수준의 노하우를 과거의 자신으로부터 온 기록으로부터 도움 받으며 일하고 있습니다. 위키 같은 기록 도구에 큰 관심을 가지고 항상 컨플루언스의 개발 방향에 발문을 표하곤 하는 이유가 이것 때문인데 실상은 개인적인 업무 기록을 다른 사람들과 비교해 엄청나게 많이 남기고 일을 시작하기 전에 먼저 이전에 했던 비슷한 업무 기록을 검색해 보는데서부터 일을 시작하며 큰 도움을 받습니다.

하지만 꽤 단순한 동작임에도 비용을 예측하는데 실패하기도 하는데 오늘은 최근에 겪은 채팅창에 입장 및 퇴장 메시지를 표시하는 간단한 기능의 비용 예측에 실패한 사례를 통해 간단한 기능이고 또 이전에 충분히 여러 번 만들어봤음에도 여전히 비용 예측은 개개인이 감당하기에는 만만치 않다는 이야기를 해보겠습니다.

Open

언리얼 개발환경에서 다국어 대응은 로케일 테이블에서부터 시작하는데 코드나 블루프린트에서 텍스트를 가져다 사용할 때 로케일 테이블에 텍스트를 입력한 다음 텍스트의 키를 가져다 사용하고 다른 언어로 동작해야 하는 상황에 대비해 로케일 테이블을 언어 별로 만들어 대응합니다. 실제 다국어 대응은 텍스트 뿐 아니라 텍스트를 포함하는 언어 별 인터페이스, 서비스 되는 지역 별 법률에 따라 구분되는 동작, 데이터 저장 방법, 버전에 따라 동작하거나 동작하지 않아야 하는 시스템, 언어 별 아트 에셋 구분 등 훨씬 복잡하기는 하지만 여기서는 오직 텍스트만 다국어화 대상이라고 가정하겠습니다.

기존에 동작하는 채팅은 지역 단위로 구분된 채널에 따라 동작하고 있었는데 여느 게임처럼 채널에 사람들이 입장하거나 퇴장할 때 이를 채팅창을 통해 알리는 기능이 필요했습니다. 동작은 간단했고 정의하는데 시간이 많이 필요하지도 않았습니다. 이미 레벨 이동에 따라 채널에 입장과 퇴장이 일어나고 있었고 이 때 채팅창에 아무개 님이 입장했거나 퇴장했다고 메시지를 표시해 주기만 하면 되는 일입니다. 구현 담당자도 이 정도면 딱히 비용이 크지 않다고 예상했고 우선순위가 높지는 않아 다른 일 하다가 지루해지거나 비는 시간이 생기면 그 때 잠깐 준비하면 될 것 같다고 판단했고 저도 여기에 동의했습니다.

그런데 막상 잠깐 비는 시간 동안에 개발을 시작하고 보니 기능을 정의할 때 제가 당연히 구현 담당자도 알고 있을 거라고 생각하고 이 메시지가 플레이어 개인에게 표시되는 것이 아니라 채널에 있는 모든 사람들에게 표시되어야 한다는 점을 정의에 언급하지 않았습니다. 그래서 구현 담당자와 이야기를 하다가 뭔가 자꾸 어긋나는 느낌이 들어 의도를 처음부터 정확히 설명했을 때 서로 이 메시지가 누구에게 어떤 방식으로 표시되어야 하는지 달리 이해하고 있었다는 점을 알게 됩니다. 저는 이 메시지가 채널에 있는 모든 사람들에게 표시되기를 원했고 구현 담당자님은 채널에 입장하거나 퇴장하는 개인에게 표시되는 거라고 생각했습니다. 그래서 구현이 훨씬 단순할 거라고 예상한 것이었습니다.

그런데 채널 안에 있는 모든 사람에게 메시지를 보여주려는 순간 이 일은 단순히 클라이언트 프로그래머 한 명이 잠깐 동안 수행할 작업이 아니게 됩니다. 여느 MMO 게임에서 하듯 캐릭터가 채널에 입장하거나 퇴장할 때 서버가 채널에 있는 모든 사람들에게 메시지를 뿌려 주도록 만들어야 하는 완전히 다른 구현과 완전히 다른 비용이 필요한 일이었습니다. 현재 빌드의 단계 상 이 기능을 위해 다른 담당자를 할당하거나 추가 비용을 얻기 위해 의사결정권자들을 불러 모으는 대신 적당히 구현 담당자 선에서 상황을 해결하기로 했지만 여전히 아주 단순해 보이는 기능 조차도 이 기능을 개발하는데 필요한 비용을 예측하는 일은 그리 간단하지 않다는 교훈을 얻은 사건이었습니다.

앞에서 개인 수준에서 업무 기록을 충분히 남겨 미래의 저에게 도움을 주기 위해 노력하고 있다는 이야기를 했는데 지금 이 글 역시 현재 이런 사건을 겪은 자신이 이런 사례를 잘 기억하게 만들기 위함이기도 하고 또 미래의 자신이 비슷한 상황에 처하기 전에 이 기록을 통해 그 때도 비슷하게 저지를 실수를 최소화하는데 도움을 주기 위함이기도 합니다. 그런데 정말 이런 단순한 기능에 그런 중요한 동작 특성을 정의하지 않는 건 이쯤 되면 치매가 아닌가 의심스럽긴 합니다.