아는 대로 다 불면 안돼

개인적으로 게임을 직접 개발하는 여러 직군 중에서 게임디자인 역할을 하는 사람들이 종종 가장 존경 받지 못하고 또 대우도 받지 못한다는 생각을 합니다. 가령 엔지니어와 이야기할 때 기술적인 측면을 잘 고려하지 못한 요구사항을 제시하거나 기술적인 개념을 빠르게 이해하지 못하면 쉽게 무시 당할 수 있습니다. 인터넷에 돌아다니는 여러 이야기를 살펴보면 엔지니어들과 더 잘 일하기 위해 그들의 사고방식을 흉내내는 방법을 배운다든지 코딩을 배운다든지 하는 시도가 나타나는 것으로 미루어 꼭 게임 개발이 아니더라도 이런 현상은 더 넓은 범위에서 일어나고 있는 것 같아 보입니다. 아티스트들과 대화할 때도 비슷한 현상이 일어나곤 하는데 종종 3D 그래픽 파이프라인을 잘 이해하지 못한 상태에서 이들과 대화할 때 엔지니어들과 이야기할 때 겪는 것과 비슷한 평가를 받기도 합니다.

개발팀에 소속되어 실제 개발에 참여하는 사람을 구분할 때 개인적으로는 형상관리도구에 커밋하는 방식으로 기여하는지 여부에 따라 가르곤 합니다. 빌드에 뭐라도 기여하는 사람이라면 직접 개발에 참여하는 사람이지만 그렇지 않다면 개발에 참여하고는 있지만 ‘직접’ 개발에 참여하고 있다고 보기는 어렵습니다. 그런데 게임디자인 직군 중에는 종종 문서를 작성해 요구사항을 설계하고 제안하지만 직접 개발에 참여하는 범위에 포함되지 않는 경우가 있고 또 개발에 직접 참여하는데 어려움을 겪는 분들이 있기도 합니다. 형상관리도구에 파일을 커밋하는 방식으로 직접 기여하지 않다 보면 개발을 진행시키기 위핸 다양한 의사소통 과정에서 위에 설명한 대로 사려 깊지 못한 방식의 의사소통을 통해 소외될 가능성이 적지 않습니다. 팀에서 한번 이렇게 평가된 스탭님은 이후 협업을 진행하는데 상당한 핸디캡을 안게 되는데 분명 필요하고 또 올바른 요구사항이지만 팀 밖에서 이 요구사항에 대한 낮은 신뢰를 받기 쉬우며 이 상태를 해소하기는 아주 어렵습니다.

이런 상황을 봐 오다 보니 개인적으로는 같은 팀에서 일하시는 스탭님들께 최대한 조립 과정에 참여하고 직접 빌드에 기여하기를 꺼리지 않는 편이 좋다고 가이드 하곤 합니다. 언리얼이나 유니티 같은 미들웨어를 사용하면서 이전 시대에 비해 비 엔지니어나 비 아티스트가 빌드에 직접 기여할 묵시적인 방법은 훨씬 많아졌습니다. 이전에 모든 것을 직접 만들던 시대에는 명시적으로 엔지니어가 우리들이 손댈 수 있도록 열어준 부분이 아니면 게임에 아무 것도 할 수가 없었습니다. 우리들이 할 수 있는 거라고는 엔지니어가 명시적으로 읽어들이는 엑셀 파일을 편집하고 클라이언트와 서버를 재시작 해 결과를 보는 수준에 머물렀습니다. 시간이 흐르며 어떤 프로젝트에서는 서버 쪽에서 AI 인터페이스를 열어 몬스터가 행동하려 할 때 호출되는 함수 내부를 직접 작성할 수 있을 때도 있었는데 사실 현대의 비헤이비어트리를 문서로 작성한 것과 비슷한 ‘AI 기획서’를 작성해 브리핑 하고 엔지니어가 이를 구현하기를 기다리는 대신 이벤트 함수 내부를 C#으로 직접 만들어 기획서를 건너 뛰고 바로 테스트 할 수 있어 좋았습니다. 하지만 누구나 이렇게 할 수 있지는 않습니다.

미들웨어가 점점 더 좋아지면서 게임디자인 입장에서 기여할 수 있는 일이 더 많아지고 또 기여할 수 있는 방법 역시 다양해졌습니다. 인터페이스에서 포함된 텍스트 하나를 수정하기 위해 인터페이스 개발자를 찾아가 부탁하는 대신 그냥 위젯 블루프린트를 열어 텍스트를 수정하거나 텍스트가 포함된 로케일 파일을 열어 수정한 다음 커밋하면 끝입니다. 특정 상태에 잘못된 애니메이션이 나오거나 잘못된 시점에 피격이 일어난다면 엔지니어에게 요청하는 대신 그냥 애님몽타주를 열어 문제를 수정한 다음 저장하면 됐고 이런 자잘한 직접 수정 가능한 영역은 이전 시대에 비해 엄청나게 넓어졌습니다. 그래서 굳이 나쁜 평가를 받을 수 있는 위험을 감수하고 엔지니어에게 온갖 자잘한 요구사항을 설명하고 설득하고 요청하는 대신 직접 수정해서 테스트 하고 결과가 마음에 들면 그대로 커밋할 것을 권장하고 있습니다. 이 권장사항은 특히 앞에서 빌드에 직접 기여하지 않는 스탭이 종종 협업 과정에서 나쁜 평가를 받을 수 있음을 감안해 할 수 있다면 최대한 빌드에 직접 기여하고 이를 통해 전체 개발 과정에 대한 시야와 지식을 쌓을 수 있다고 생각해 왔습니다.

하지만 작년에 지난 이직을 겪은 다음 남겨진 사람들과 새로 채용된 사람들이 한 부서에서 일하기 시작하며 남겨진 분들이 여러 업무로 고생하고 계신 모습을 보고 새로 채용된 분들이 ‘왜 이런 걸 기획에서 하고 있어요?’라는 질문을 받았다는 이야기를 전해 듣고 과연 제가 생각하는 이런 정책이 올바른가 하는 생각을 해 보게 됐습니다. 개발에 참여하는 여러 사람들은 자신의 지식 수준에 맞춰 여러 가지 방식으로 기여하고 있습니다. 실은 커밋을 기준으로 기여 여부를 평가한다면 일정 수준 이상의 관리자들은 개발에 기여하지 않는 것과 마찬가지입니다. 하지만 실제로 이 분들은 게임의 방향을 결정하고 디테일을 손보는 등 아주 근본적인 기여를 하고 있습니다.

단지 썩 훌륭하지는 않을 것 같은 엔지니어나 아티스트로부터 이들과 편안하게 이야기 할 수 있는 지식을 갖추고 있지 못하다고 해서 나쁜 평가를 받는 것은 올바르지 않습니다. 다만 이 올바르지 않은 상황 자체를 해결하기는 아주 어렵다고 생각한 나머지 이런 상황을 피하기 위해 최대한 빌드에 직접 기여하며 지식을 쌓기를 권장해 온 것일 뿐입니다. 하지만 이는 어느 순간 우리가 해야만 하는 일의 경계를 벗어나 팀에 무리를 줍니다. 제가 팀을 떠나고 나서 다음 분들로부터 그런 평가를 받았다는 점을 전해 듣고 지금까지 제가 접근해 온 팀에서 어떻게 보면 살아 남는 방식이 저 자신에게는 적절했을지 모르지만 저와 함께 일하는 다른 게임디자이너들에게는 적절하지 않을 수 있다는 점을 생각해 보게 되었습니다.

한편 이번에도 이와 비슷한 상황이 일어났다고 생각하는데 지난 서비스 때 인게임 로그를 설계할 사람이 없는 채로 인게임 로그 관련 업무가 표류하고 있어 얼른 주워다가 요구사항을 작성해 넘겨 인게임 로그를 남겼고 이를 바탕으로 오픈서치로 시작한 임시변통 로그 집계 환경을 만들었으며 이를 바탕으로 비즈니스 부서의 여러 요구를 처리하고 또 직접 로그를 이리 저리 만져보며 자잘한 지식을 얻을 수 있었습니다. 개인적인 관점에서는 웬만한 회사에서 서비스 중인 게임의 인게임 로그는 기밀이어서 지정된 사람이나 부서가 아니면 접근할 수가 없습니다. 그래서 가장 기초적인 고객들의 실제 행동을 파악하고 싶어도 이를 직접 파악하는 대신 부서 간 업무협조 과정을 거쳐야 했고 이는 지금 당장 알고 싶은 정보를 2주 뒤에나 알 수 있다는 의미입니다. 그 때는 이미 이 정보가 기여할 수 있었던 업무는 이미 2주 전에 끝나 버렸고 업무협조를 통해 도착한 문서는 아무 짝에도 쓸모가 없어 그냥 열지도 않은 채 다음 일로 넘어가 버리기도 했습니다. 이번에는 직접 쿼리를 날려 볼 수 있었기 때문에 여러 가정을 검증해볼 수 있었고 또 가정을 쿼리 모양으로 바꾸는데도 조금은 익숙해져 더 좋았습니다.

하지만 최근 마감에 코앞에 닥친 상황에서 이번 마일스톤에 새로 추가된 기능에대한 인게임 로그 요구사항을 작성하고 또 지난번 인게임 로그를 집계하며 느낀 문제점을 개선할 또 다른 요구사항을 작성했고 또 이에 기반한 비즈니스 부서의 이벤트 준비에도 대응하다가 문득 지금 빌드에 직접 기여하고 또 결정해야 할 일이 많은데 이 일을 하고 있는 자신의 행동이 올바른가 하는 생각을 해 봤습니다. 물론 인게임 로그를 직접 만져보는 건 정말 재미있는 경험이고 또 앞으로 기회가 되면 또 하고 싶기는 합니다. 하지만 이 일이 시스템디자인을 담당하는 제 핵심 업무는 아닙니다. 지금은 이 업무를 제가 담당하지 않으면 할 사람이 아무도 없기 때문에 담당하고는 있지만 우선순위는 상대적으로 낮으면서도 부서 간 협조가 일어나야 하는 일이어서 마냥 우선순위를 뒤로 미룰 수는 없는 상황입니다.

만약 몇 달 전에 인게임 로그 관련 업무가 표류하고 있다는 사실을 알았지만 이에 반응하지 않았다면 어쩌면 이 업무는 비즈니스 부서의 이벤트 집행 요구사항과 서버 엔지니어 사이의 업무가 됐을 지도 모릅니다. 그러면 저는 인게임 로그를 직접 만져보며 여러 가지를 배울 기회나 로그를 빠르게 조회하는 환경을 구축해본 경험, 그리고 로그를 개선할 기회 역시 얻지 못했겠지만 다른 한편으로는 이렇게 바쁜 기간에 빌드에 직접 기여하고 여러 정의되지 않은 동작을 정의하는 의사결정에 더 집중할 수 있지 않았을까 하는 생각이 들기도 합니다. 실은 이 역할을 포함한 다양한 숫자 관련 업무를 맡길 분을 채용했다가 실패하며 내가 믿던 세계의 붕괴를 겪는 바람에 아직도 이 일을 전담 시킬 스탭을 구하지 못했고 아무도 할 사람이 없다면 저라도 해야 한다는 심정으로 이 업무를 담당하고는 있지만 게임디자인 관점에서는 이보다 우선순위가 높은 일들이 널려 있는 상황에서 이 일을 하고 있다 보니 이 상황은 올바르지 않았다는 생각이 들었습니다.

개인적으로는 여전히 다양한 경험을 쌓고 또 빌드에 실질적인 기여를 하는 범위의 업무가 재미있습니다. 실무에 비해 관리 역할이 늘어나도 여전히 그런 일들을 직접 처리하며 여러 생각을 하고 그런 생각을 글로 남기고 다음에 다른 일을 할 때 도움이 되는 상황을 맞을 때마다 이전에는 좀 고생스러웠지만 그러길 잘 했다는 생각을 합니다. 하지만 앞에서 고백했듯 그런 접근이 저 자신에게는 올바를 지도 모르지만 다른 분들께 권유할 만한 행동이 아닐 수 있으며 상황에 따라 게임디자인에서 더 중요하게 수행할 핵심 업무에 비해 덜 중요한 일에 매몰될 가능성이 있다는 점 역시 고려해야 할 것 같습니다. 할 줄 안다고 아는 대로 다 불면 안됩니다.