아는 대로 다 불면 안돼
넓은 영역의 업무를 처리할 수 있으면 좋기는 하지만 때때로 이 사실이 자기 자신이나 팀에 악영향을 끼칠 수도 있으니 주의해야 합니다.
개인적으로 게임을 직접 개발하는 여러 직군 중에서 게임디자인 역할을 하는 사람들이 종종 가장 존경 받지 못하고 또 대우도 받지 못한다는 생각을 합니다. 가령 엔지니어와 이야기할 때 기술적인 측면을 잘 고려하지 못한 요구사항을 제시하거나 기술적인 개념을 빠르게 이해하지 못하면 쉽게 무시 당할 수 있습니다. 인터넷에 돌아다니는 여러 이야기를 살펴보면 엔지니어들과 더 잘 일하기 위해 그들의 사고방식을 흉내내는 방법을 배운다든지 코딩을 배운다든지 하는 시도가 나타나는 것으로 미루어 꼭 게임 개발이 아니더라도 이런 현상은 더 넓은 범위에서 일어나고 있는 것 같아 보입니다. 아티스트들과 대화할 때도 비슷한 현상이 일어나곤 하는데 종종 3D 그래픽 파이프라인을 잘 이해하지 못한 상태에서 이들과 대화할 때 엔지니어들과 이야기할 때 겪는 것과 비슷한 평가를 받기도 합니다.
개발팀에 소속되어 실제 개발에 참여하는 사람을 구분할 때 개인적으로는 형상관리도구에 커밋하는 방식으로 기여하는지 여부에 따라 가르곤 합니다. 빌드에 뭐라도 기여하는 사람이라면 직접 개발에 참여하는 사람이지만 그렇지 않다면 개발에 참여하고는 있지만 ‘직접’ 개발에 참여하고 있다고 보기는 어렵습니다. 그런데 게임디자인 직군 중에는 종종 문서를 작성해 요구사항을 설계하고 제안하지만 직접 개발에 참여하는 범위에 포함되지 않는 경우가 있고 또 개발에 직접 참여하는데 어려움을 겪는 분들이 있기도 합니다. 형상관리도구에 파일을 커밋하는 방식으로 직접 기여하지 않다 보면 개발을 진행시키기 위핸 다양한 의사소통 과정에서 위에 설명한 대로 사려 깊지 못한 방식의 의사소통을 통해 소외될 가능성이 적지 않습니다. 팀에서 한번 이렇게 평가된 스탭님은 이후 협업을 진행하는데 상당한 핸디캡을 안게 되는데 분명 필요하고 또 올바른 요구사항이지만 팀 밖에서 이 요구사항에 대한 낮은 신뢰를 받기 쉬우며 이 상태를 해소하기는 아주 어렵습니다.
