시스템 기획은 뭐 하는 직군인가요

종종 블로그에 게임디자인에 관련된 이야기를 하고 있습니다. 주로 일하면서 든 질문에 대한 대답을 하기 위해 했던 생각을 쓰거나 공개할 수 있는 범위 안에서 널리 알려진 결과물을 만드는데 어떤 시스템을 제안했는지 소개하거나 실제 게임의 사례를 들어 국부 메커닉이 동작하는 방식을 소개하기도 합니다. 이런 이야기들이 도움이 될 지 알 수 없지만 웬만하면 너무 뻔하다고 생각하는 이야기는 하지 않으려고 노력했습니다. 좀 더 흔한 이야기는 이미 다른 분들이 만드신 더 나은 컨텐츠가 널려 있을 것이 분명하기 때문입니다. 그나마 개인적으로 이건 좀 뻔하다는 생각이 드는 이야기들은 튜토리얼 태그를 달아 분류 해 놓았는데 이들은 일하며 든 개인적인 깨달음이라기 보다는 어느 정도 답이 있는 주제들이고 이는 뻔하다고 생각하기 때문입니다.

게임 만드는 회사나 팀에는 여러 직군이 모여 일하는데 각 직군이 정확히 무슨 역할을 하는지 역시 검색하면 수많은 설명을 찾을 수 있을 것이 분명합니다. 적어도 국내에서 게임디자인 직군이 분업화 되어 감에 따라 분리된 시나리오, 시스템, 컨텐츠, 밸런스, 전투 등의 구분에 대한 더 나은 정보를 얻기는 그리 어렵지 않을 거라 확신합니다. 그래서 분명 더 나은 정보가 있을 것이 확실한 이야기를 피하는 대신 게임디자인의 분업이 만들어낸 비 존중처럼 현대에 가까워질수록 더 강하게 일어나는 것처럼 보이는 분업과 이 결과로 일어난 현상에 대해 이야기하는 쪽이 생각하는 제 입장에서도 더 재미있고 다른 곳에서 흔하게 접하기는 어려울 것 같은 이야기여서 만약 읽어 주시는 분이 계시다면 그 분 입장에서도 더 낫지 않을까 싶습니다. 이렇게 생각하면서도 짐짓 뻔한 내용일 것이 분명한 ‘시스템 기획은 뭐 하는 직군인가요’ 같은 제목을 바탕으로 생각하기 시작한 이 글을 작성하는 이유는 이번 백수 생활 도중에 서로 다른 두 곳에서 같은 질문을 받았기 때문입니다. 평소에 제가 뭐 하는 사람인지 정확히 설명할 일도 드물고 또 생각 할 일도 거의 없지만 짧은 기간 안에 같은 질문을 두 번 받은 김에 생각을 정리해 두면 좋겠다 싶었습니다. 다시 한 번 강조하지만 이런 이야기는 이를 잘 설명한 더 좋은 컨텐츠가 분명 있을 테니 그 쪽을 참고하는 것을 추천하며 그 분들과 제 설명이 다를 경우 무조건 제 이야기가 잘못되었습니다.

지난 43호 커버스토리 유년기의 끝 뒷부분에 귀엽지만 좀 마음이 쓰이는 강아지 이야기를 했었는데 이 때 만난 친척과 고기를 먹고 나서 자리를 옮겨 차를 마시다가 이 질문을 받았습니다. 이 분들은 학교를 마친 다음 좀 더 공부하다가 최근 소프트웨어 개발을 시작하신 모양입니다. 유명한 회사에서 커다란 기계에 들어가는 제어 소프트웨어를 작성하는 일을 하고 계신 것 같았는데 같은 기계에 들어가는 여러 가지 서로 다른 소프트웨어를 한 건물에서 개발하고 있다는 것 같습니다. 만약 그 회사 물건을 사용하다가 어떤 점이 마음에 안 들면 같은 건물의 다른 몇 층에 가서 항의하면 되지 않겠느냐는 이야기를 농담처럼 했습니다. 게임 소프트웨어는 항상 결과물에 실체가 없어 게임 콘솔, 컴퓨터, 스마트폰 같은 별도의 기계를 통해서만 가상으로 그 실체를 접할 수 있어 좀 아쉽다는 생각을 한 적이 있습니다. 만약 영화 투모로우에서처럼 인류가 멸망할 때 한정된 사람을 태울 수 있는 구조선이 있고 여기에 다음 세대를 이어 갈 핵심 인원들만 선정해서 태운다면 게임 만드는 사람은 분명 탈 수 없으리라 생각한 적도 있습니다. 멸망한 다음 문명을 재건하려면 실체를 만들 수 있는 사람들이 필요할텐데 게임 만드는 사람들은 결코 그렇지 않기 때문입니다.

그래서 한동안은 실체가 있는 아케이드 기계에서 동작하는 게임을 만들고 싶었습니다. 특히 오락실에 있는 총 컨트롤러를 들고 적을 쏴 맞추는 게임이나 두 사람이 자동차 앞 뒤에 타고 한 사람은 운전하고 다른 한 사람은 뒤에 쫓아오는 공룡에게 총을 쏘는 게임, 또 두 사람이 철로 위에 있는 무동력 차량 위에 달린 레버를 움직여 차량을 움직여 쫓아오는 기차로부터 도망치는 게임 같은 것들을 매력적으로 생각했고 만들 기회가 없을까 한참 찾아본 적이 있습니다. 하지만 제가 구할 수 있는 정보 범위 안에서는 국내에서 이런 게임을 개발하는 곳을 찾을 수 없었고 가장 비슷한 곳이 국내에는 서비스 하지 않는 카지노 게임을 개발하는 곳이었는데 이곳은 분명 실체가 있는 게임을 개발하고 있었지만 제가 생각하는 실체와는 조금 차이가 있어 이 기회를 잡지는 않았습니다. 만들지는 않았지만 제가 생각하는 실체가 있는 게임과 가장 비슷하고 또 제 기준에서 가까이서 접할 수 있는 사례는 인도어 사이클을 탈 때 플레이하는 즈위프트가 있는데 여기는 제 직군을 구인하지 않았습니다. 지난 권고사직 후 다음에 일할 곳을 확정했지만 이곳 역시 실체가 있는 게임을 만드는 곳은 아닙니다. 그런데 실체가 있는 제품에서 돌아가는 소프트웨어를 만드는 일을 시작했다는 분들의 이야기를 들으니 부럽고 또 신나고 이것 저것 궁금한 점들이 많아 이야기하며 즐거웠습니다.

그렇게 차를 마시며 한참 이야기하다가 이번에는 제가 질문을 받았는데 그 분들도 소프트웨어를 개발하는 사람들이고 저 역시 게임 소프트웨어를 개발하는 팀에 참여하는 사람이기에 저는 팀에서 뭘 하는지에 대한 질문입니다. 사실 게임 만드는 사람이라고 하면 대부분 코드를 작성하는 사람이나 아트 에셋을 만드는 사람을 떠올리기 마련입니다. 제가 하는 일을 뜯어 보면 업무 중 코드를 만드는 일이 종종 포함되어 왔기는 하지만 시간이 지날 수록 그런 일은 점점 줄어들고 있고 게임디자인 직군이 프로덕션 코드를 만들 일이 자주 일어나서는 안된다고 생각하고 있습니다. 그러면 소프트웨어 개발 일을 하지만 코드를 만들지 않는 사람이 개발팀에서 할 일을 상상하기는 쉽지 않은 것이 사실입니다. 에셋 제작 역시 이를 만들 일이 아예 없지는 않지만 주로 이미 만들어진 에셋을 조합하는 일이 보통입니다. 다른 회사 사례를 살펴보면 아주 오래된 유명한 게임을 유지보수 하는 팀이 적은 인력으로 운영되다 보니 아트 에셋을 만드는 분들의 일정이 이미 꽉 차 있어 어쩔 수 없이 새 스킬 아이콘을 게임디자인 직군에서 제작한다든지 하는 일이 일어나기도 하지만 보통은 그렇지 않습니다.

그렇다면 ‘형은 팀에서 뭐 하는 사람인가요’라는 질문에 도대체 뭐라고 대답해야 할까요. 이 질문을 받고 어떻게든 대답한 다음 나중에 게임 만드는 지인들이 모여 있는 채팅창에 똑같은 질문을 해 봤는데 가장 많이 나온 답변은 ‘노예’였습니다. 이 질문에 진지하게 답하기 쉽지 않은 이유는 팀에서 게임디자인 직군은 분명 게임디자인 하라고 만들어진 직군이기는 하지만 팀이 처한 상황에 따라 필요한 일이라면 뭐든 수행하는 경우가 많기 때문입니다. 그래서 뭐 하는 사람이냐는 질문을 받으면 순식간에 머릿속에 주마등이 펼쳐지며 회사에서 해 온 온갖 일들이 스쳐 지나가지만 그들 중 어느 하나 저 자신의 전문성을 대표할 만한 일로 정의하기 쉽지 않습니다. 하지만 분명 어떤 역할로 팀과 프로젝트에 기여하고 있고 그 기여를 어느 정도 인정 받고 있기 때문에 아직 까지 직업을 잃지 않고 국민연금에 돈을 넣으며 살고 있을 것이 분명니합니다. 이제 저를 주로 정의하는 직군인 ‘시스템디자인’을 기준으로 회사에서 뭘 하고 있는지 잠깐 생각해 보겠습니다.

일단 저는 프로젝트에서 처음으로 요구사항을 생성하는 사람은 아닙니다. 프로젝트에서 그런 분들을 디렉터 또는 프로듀서라고 하는데 이는 영화에 비해 늦게 산업이 시작된 다음 몇몇 용어들을 영화 산업으로부터 빌려온 결과라고 생각합니다. 주로 디렉터가 프로젝트에 대한 요구사항을 처음으로 만드는 역할과 핵심 의사결정을 내릴 책임을 가집니다. 프로듀서 역시 요구사항을 처음으로 만드는데 관여하고 또 핵심 의사결정을 내리는데 관여하지만 주로 회사와 프로젝트 사이의 관계 조율, 예산 확보 및 집행 같은 행정적인 역할에 좀 더 치우쳐 있습니다. 이 분들로부터 나온 요구사항은 뭘 하자는 말인지 이해할 수는 있지만 이 요구사항 그대로는 개발을 시작하기 쉽지 않습니다. 요구사항은 플레이시나리오, 해야 할 것과 하지 말아야 할 것들의 목록처럼 이해하고 실천할 수는 있지만 어디서부터 일을 시작해야 할 지 이해하기는 쉽지 않은 형태입니다. 게다가 이 요구사항은 불확실한 경우가 많은데 요구사항을 처음으로 만든 분들도 그 요구사항이 올바를지 확신할 수 없는 상태에서 요구사항을 만들기 때문입니다.

프로젝트 팀의 임무는 처음 만들어진 이 요구사항을 개발해 내는 것입니다. 여기서 요구사항을 마일스톤 단위로 구분해 개발팀이 감당할 수 있는 단위로 분리하고 분리한 각 단계 및 마일스톤 마다 달성해야 하는 별도의 요구사항을 최초 요구사항의 범위를 벗어나지 않도록 정의해야 하며 각 마일스톤에 해당하는 요구사항을 분해해 팀의 각 파이프라인이 개발을 시작할 수 있는 단위 기능으로 정의한 다음에야 개발을 시작할 수 있습니다. 요구사항을 마일스톤 단위로 구분하고 마일스토에 해당하는 요구사항을 정의하며 이 요구사항이 최초 요구사항의 범위를 벗어나지 않도록 조율하는 역할은 상황에 따라 디렉터가 직접 담당하거나 게임디자인 직군 중 좀 더 경험이 많은 사람이 담당합니다. 이 때 마일스톤 단위의 요구사항을 정의하기 위해 협업 부서의 책임자들이 함께 의논하게 되는데 팀이 이전에 함께 일해본 적 있다면 이 과정은 꽤 순탄하겠지만 만약 처음 일하는 상황이라면 서로의 퍼포먼스를 잘 모르기 때문에 적어도 한 마일스톤 정도는 요구사항을 마일스톤에 맞춰 확정하지 않은 채로 진행해 퍼포먼스를 파악하기도 합니다.

이제 한 마일스톤에 해당하는 요구사항이 정의되지만 아직 이 요구사항은 서로 다른 파이프라인에 분산해 개발할 수 있는 상태는 아닙니다. 경험 많고 또 게임에 대한 이해가 깊은 엔지니어 조직은 마일스톤 단위의 요구사항 수준에서 서로 다른 파이프라인에 분산해 개발을 시작할 수 있는 단위 기능을 분리해낼 수 있겠지만 지금까지 일해 오면서 그 정도로 이해가 깊은 엔지니어 조직을 만나본 경험은 드뭅니다. 종종 엔지니어들은 약간 수동적인 자세를 취하며 파이프라인으로 전달된 단위 기능 개발에 집중하기를 원하곤 하는데 이런 상황이 훨씬 많기 때문에 시스템디자인 직군이 필요해집니다. 시스템디자인 직군은 주로 마일스톤 단위로 분리된 요구사항을 별도로 구현하고 검증할 수 있는 세부 기능으로 분리하고 각 기능이 재조립 되었을 때 요구사항을 만족하는지 여부를 검토하며 세부 기능에 대한 구체적인 요구사항을 작성하는데 이를 기획서 또는 시스템기획서라고 합니다. 디렉터 수준에서 맨 처음 생성된 요구사항의 달성에 필요하지만 이 요구사항에 구체적으로 언급되지 않은 규칙을 정의하고 서로 다른 단위 기능이 통합된 상황에서 발생할 수 있는 문제점 따위를 미리 예상해 규칙에 포함하곤 합니다. 그런 기획서의 모양은 시스템기획서와 컨텐츠기획서는 어떻게 다른가요?에서 대략 설명한 적 있습니다.

팀에 따라 프로젝트 관리 직군이 별도로 구분되어 동작하기도 하지만 그런 팀은 소수인 것 같습니다. 그런 직군이 있더라도 주로 팀 외부와 의사소통 하는 채널로 활용되거나 회사에 프로젝트 진행 상황을 보고하는 역할을 주로 수행하며 프로젝트 안쪽을 바라보고 개발 진행에 직접 관여하는 경우는 없지는 않지만 상당히 드문 편입니다. 하지만 개발 파이프라인 각각을 구동 시키려면 파이프라인을 관리할 주체가 필요한데 단위 기능의 요구사항을 자신을 포함한 파이프라인에 전달한 시스템디자인이 해당 파이프라인의 관리 주체로 동작해야 하는 경우가 많습니다. 개인적으로 이를 마이크로 PM이라고 부릅니다. 이론적으로는 파이프라인에 속한 각 협업 대상자들이 자신의 작업이 완료되면 다음 사람에게 전달하고 또 이터레이션이 필요할 경우 스스로 필요한 협업자들을 모아 이터레이션을 진행해야 합니다. 이를 위해 지라 같은 도구를 사용해 각자의 업무를 추적하고 있습니다. 하지만 이를 잘 사용하는 사람들과 그렇지 않은 사람들이 섞여 있는 환경, 그리고 적극적으로 협업을 요구하는 사람과 그렇지 않은 사람이 섞여 있는 환경에서 이 이론적인 파이프라인의 동작은 실제와 상당히 다릅니다.

실제로는 작업자가 요구사항을 잘 이해하지 못했지만 이를 표현하지 않고 자신이 생각한 대로 그냥 개발을 진행했다가 요구사항과 결과 사이에 큰 차이가 발생하기도 하고 자신의 작업이 끝난 다음에도 이를 이어 받아야 할 다음 사람에게 전달하지 않아 딜레이가 발생하기도 합니다. 각자가 악의를 가지고 있는 것은 아닙니다. 다만 시야가 좁아 자기 앞에 있는 일에 집중하고 일을 마치고 나면 또 다음 일에 집중하기를 반복할 때 쉽게 일어날 수 있는 상황일 뿐입니다. 또 엔지니어가 에셋을 전달 받아 기능을 구현해 동작을 확인한 다음 이 기능들을 돌려 받아 조립할 게임디자이너에게 이 사실을 전달하지 않아 여러 단위 기능 파이프라인을 동시에 시작한 디자이너가 이를 확인하기 전까지 조립을 시작할 수 있음을 파악하지 못하기도 합니다. 이런 상황을 전문적인 관리 직군의 도움 없이 해결하기 위해 마이크로 PM 개념이 필요합니다. 용어가 거창한데 실은 그냥 시스템디자이너 각각이 자신이 담당한 파이프라인의 상태를 파악하고 문제 발생 여부를 감시하는 것입니다. 각 작업자가 단위 기능의 요구사항을 제대로 이해했는지 확인하고 요구사항에 맞춰 개발되고 있는지 확인하며 완료된 작업이 다음 단계로 넘어갔는지 등등을 파악해 문제가 생길 때 즉시 개입해 수정하고 또 의사소통에 소홀해 일정이 낭비되지 않도록 해야 합니다.

다음으로 파이프라인에서 나온 구현 결과를 테스트 해 요구사항을 만족하는지 확인하고 또 단위 기능 수준에서 개선할 점이 있으면 이를 제안하고 설득해 품질을 올려야 합니다. 그렇게 단위 기능들의 개발이 완료되면 이들을 조립해 마일스톤 단위의 요구사항을 만족하는 형태로 구축해야 하는데 이를 팀에서는 종종 ‘데이터 입력’이라고 부르기도 합니다. 단위 기능을 조립하고 마일스톤 단위의 요구사항을 만족하도록 데이터를 입력해 한 마일스톤 범위 안에서 마일스톤의 목표 달성 여부를 판단할 수 있는 상태의 게임 플레이를 만들어 내야 하는데 이 역시 게임디자인 직군의 책임입니다. 이 과정에서 여러 단위 기능이 통합되며 기술적인 문제가 발생할 수도 있고 또 단위 기능 사이에 서로 통합된 상태를 고려하지 않은 요구사항, 또는 구현에 의해 문제가 생길 수도 있는데 단위기능 별로 테스트할 때는 잘 드러나지 않아 이들을 모두 통합한 상태에서 별도로 테스트 해야 합니다. 이를 별도의 테스터에게 위임할 수도 있겠지만 이 시점에서 테스터들은 마일스톤 목표에 대한 이해가 상대적으로 낮을 수 있으므로 초반 테스트 역시 게임디자인 직군에서 수행해야 합니다.

또 현대의 분업화된 게임디자인 직군 안에서 시스템디자인은 종종 레벨디자인, 컨텐츠디자인, 밸런스디자인 등으로 분류된 다른 직군이 게임을 조립하는데 사용할 환경을 설계하는 역할을 담당하는데 이 환경은 근미래에 컨텐츠 생산 속도에 큰 영향을 끼치므로 마일스톤 별 요구사항을 달성하는 범위 안에서 내부 고객이 컨텐츠를 채울 수 있도록 환경을 구축하고 트러블슈팅을 돕고 환경이 실제로 사용될 때 일어나는 문제점을 엔지니어와 컨텐츠 디자이너들 사이에 의사소통 하는 역할도 해야 합니다. 요구사항을 달성하기 위한 단위 기능의 명세, 단위 기능을 개발하는 파이프라인의 동작 감시 및 문제해결, 단위기능 테스트 및 품질 개선, 단위 기능의 통합과 데이터 입력, 통합된 빌드 테스트, 컨텐츠 디자인의 환경 설계 및 구축과 트러블슈팅 등을 담당하는 직군이라고 말할 수 있습니다. 이렇게 늘어놓고 보면 아주 많은 일을 하는 사람들일 것 같지만 늘어 놓으니 그래 보일 뿐이고 실제로 좀 더 줄이면 단위 기능의 요구사항 정의 또는 시스템기획서 작성과 마이크로 PM 역할이라고 요약할 수 있습니다. 이쯤 되면 여기에 ‘게임디자인’과 비슷한 업무는 별로 없어 보인다는 사실을 눈치 채셨을 수 있는데 맞습니다. 흔히 생각하는 게임디자이너에게 종종 요구된다고 알려진 창의성은 필요한 것은 맞지만 이를 발휘할 대상이 게임 규칙이나 요구사항일 때보다 단위 기능을 설계하고 개발할 때 더 간결하고 단단한 규칙을 설계할 때일 경우가 더 많습니다.

이 날 친척들과 대화에서 제가 하고 있는 일을 저를 주로 분류하는 직군인 시스템디자인의 범위 안에서 대략 이 정도 이야기를 했습니다. 실은 여기까지 이야기하고 나니 이야기를 듣는 분들의 눈빛이 조금 흐려지고 당장 옆에 놓인 카페인 섞인 물을 마셔 정신을 또렷하게 해야 할 것만 같은 느낌이 들었지만 뭐 이야기가 대충은 전달되지 않았을까 싶습니다.

이로부터 시간이 좀 지난 어느 날 오후 동네에서 좀 더 안쪽으로 들어가면 나오는 카페들이 잔뜩 모인 동네의 어느 한 카페에서 그 날 처음 만난 분들과 이야기를 시작합니다. 실은 가족이 알고 있는 분과 그 분의 친구분이었는데 이들 중 한 분은 한국어에 익숙하지 않은 분이어서 어쩔 수 없이 그 분과 우리들 양쪽 모두 모국어가 아닌 영어로 이야기해야만 하는 상황이었습니다. 서로 각자의 가족들이 레스토랑 이름이나 카페 이름을 잘 기억하는 것을 잘 이해하지 못하겠으며 이건 어쩌면 이들이 천재이기 때문일른지도 모르겠다거나 서로의 상사들이 그들의 재산 수준과 관계 없이 항상 돈과 관련된 일에 엄청나게 치사하게 군다는 점에 대해서 서로의 경험을 이야기했는데 비슷한 역할을 하는 사람들은 지역이나 국적에 관계 없이 항상 비슷하게 행동하는 것 같다는 생각이 들었습니다. 이야기 끝에 요즘 게임도 하고 언리얼 엔진으로 이것 저것 만들어 보고 있다는 이야기를 듣고 저는 한국에서 비디오 게임이나 모바일 게임을 만드는 일을 하는 사람이라고 답하며 언리얼 엔진은 적어도 한국에서는 대규모 프로젝트에서 거의 표준처럼 사용되고 있다고 말했습니다. 그리고 바로 이어지는 그 질문. 팀에서 무슨 책임을 지고 있느냐, 혹은 팀에서 무슨 일을 하고 있느냐는 것입니다.

사실 앞에서 소개한 시나리오, 시스템, 컨텐츠, 레벨, 밸런스, 전투 같은 직군이 한국 바깥에서도 통용되는지는 잘 모르겠습니다. 여러 게임을 끝마칠 때마다 스탭롤을 주의 깊게 살펴보며 다른 나라에서는 게임디자인 직군을 어떻게 구분하는지 살펴보곤 하는데 종종 한국과 비슷한 직군 구분을 사용하는 게임도 있는가 하면 아예 게임디자인 직군이 없는 곳들도 있어 널리 사용되는 직군 구분은 아니라는 생각을 하고 있습니다. 이번에도 제가 주로 하는 역할에 기반해 하는 일을 설명해 봤는데 이전에 한 번 설명해본 적이 있어서인지 이번에는 이전보다는 조금 더 간결하게 답할 수 있었던 것 같습니다.

한국 게임 업계에서는 흔히 게임디자인 직군을 위에 소개한 몇 가지 종류로 구분하는데 저는 그 중에서 시스템디자인을 하는 사람입니다. 시스템디자인은 주로 회사, 디렉터나 프로듀서 수준에서 생성된 요구사항을 마일스톤 또는 개발계획에 따라 분리하고 각각의 단위 개발 계획을 세부 기능으로 나눈 다음 세부 기능 각각의 요구사항을 정의하는 업무가 핵심입니다. 그 다음에는 단위 기능의 요구사항을 여러 직군으로 구성된 파이프라인에 보내 개발을 진행 시키는데 이 때 진행 상황을 감시해 문제가 일어나면 해결하는 역할을 합니다. 개발이 완료되면 이들을 조립해 단위 개발 계획의 목표를 달성하고 각 기능이 통합되어 동작할 때 생기는 문제를 해결해 전문 테스터들이 빌드를 테스트 할 수 있게 하고 또 현재 상태가 디렉터나 프로듀서 수준의 요구사항에 얼마나 일치하는지, 또 얼마나 차이나는지, 그리고 이전의 생각과 현재의 생각이 얼마나 달라졌는지 파악해 다음 개발 계획 수립에 반영합니다. 이번에는 내부 고객을 위한 단위 기능 설계, 구축, 개밥 먹기, 트러블 슈팅 같은 주제는 설명하지 않았는데 언리얼 엔진을 만지작 거리고 있지만 아직 소프트웨어 개발을 많이 경험하신 것 같아 보이지는 않아 내부 고객에 대한 이야기는 생략하는 편이 나을 것 같았습니다.

지난번에 비해 훨씬 짧은 문단 만으로 설명할 수 있었는데 이렇게 두 번에 걸쳐 서로 다른 사람에게 거의 같은 질문을 받아 대답하면서 제 스스로가 앞에서 여러 사람들이 답한 ‘노예’ 외에 어떻게 제가 하고 있는 일을 그럴싸한 언어로 설명할 수 있을지 고민하게 해 준 재미있는 경험이었습니다. 사실 여기에 시간이 지나며 스스로 파이프라인의 맨 앞사람이 되는 역할 뿐 아니라 서로 다른 같은 직군인 사람들 각각이 각자의 파이프라인의 맨 앞사람이 되도록 가이드할 뿐 아니라 각자의 파이프라인이 잘 동작하고 있는지 여부 역시 관리하는 중간관리자로써 역할이 포함됩니다. 또 시간이 지날 수록 게임디자인 직군인 사람으로써 발휘할 창의력의 대상이 단위 기능을 개발하는 것, 조립된 게임이 잘 동작하는 것에서 나아가 더 나은 게임이 되는 것으로 변해 가는데 이 역시 당장 설명하려고 시도할 단계는 아니라는 생각이 들었지만 이 역시 빠뜨리면 안된다고 생각합니다. 이렇게 이야기하고 보니 특정 직군이 수행하는 업무를 시간 차원을 추가해 늘어놓은 것 같은데 이는 제가 시간이 지나며 경험한 서로 다른 업무를 나열한 것과 별로 다르지 않기 때문일 것 같습니다.