내가 믿던 세계의 붕괴

얼마 전부터 지금까지 내가 옳다고 생각한 일하는 방법을 맨 밑바닥부터, 밑바닥은 물론이고 그 바닥 아래까지 뭔가 완전히 잘못됐을 가능성이 있다는 생각을 하기 시작했습니다. 커다란 MMO 게임을 만들 때 주로 사용하던 전통적인 3팀 체제 기반에서 기획팀은 다른 팀들이 담당하는 업무 외에 담당자가 모호한 업무가 있으면 이들을 담당하곤 했습니다. 가령 PM이 있더라도 아주 적은 PM 자원이 전체 프로젝트의 업무와 일정, 요구사항 조율을 담당하는 것은 불가능했기 때문에 각 기능의 기획자가 마이크로 PM 역할을 담당했습니다.

협업 부서 분들이 자신의 업무를 완료하고 다음 사람에게 전달하지 않아 생기는 공백을 찾아 이들을 연결해 이터레이션이 동작하게 만들기도 하고 마일스톤의 큰 목표와 비교해 빠진 요구사항을 발견하면 일을 만들어 마일스톤 목표를 달성하는데 기여하기도 했습니다. 이렇게 전체를 보고 또 프로젝트 구성원 전체의 사이사이를 챙기다 보면 이 역할을 하는 사람들이 문제를 더 잘 찾아내는 능력이 생기는 것도 어쩌면 당연합니다.

한편 새로 세팅한 오피스에 간이 의자가 없을 때 법인카드를 들고 회사 근처 다이소에 가서 플라스틱 의자 수 십 개를 사 오는 것도 보통은 기획팀 몫이었고 화분이 말라 죽고 있으면 거기 물을 주는 것도, 커피머신을 청소한 지 오래 돼 커피 맛이 이상하면 그걸 뜯어 청소하는 것도, 커피를 채워 놓는 것도 종종 기획팀이 담당하곤 했습니다. 명시적으로 누군가 지시하지 않았지만 이 빈 틈을 채울 수록 프로젝트 전체가 잘 돌아간다는 사실을 몸으로 체득하고 있었습니다.

이런 행동 방식은 프로젝트 전체 뿐 아니라 기획팀 안에서도 비슷한 요령으로 동작했는데 개발이 진행되며 구성원들에게 업무가 골고루 분배된다면 참 좋겠지만 실제로는 어느 한 담당자에게 일이 미친 듯 집중되기도 하고 또 누군가 에게는 일이 잘 할당되지 않는 상황이 일어나기도 합니다. 이 때 개인적으로 배운 것은 업무 영역을 넓혀 구성원 중 누군가가 위기에 처하면 그 사람의 덜 중요한 일을 가져와 내가 처리하는 것입니다. 이를 위해서는 정말로 업무 영역이 넓어야 했는데 필요하면 위젯 블루프린트를 만들고 또 필요하면 빨리 스크립팅을 하고 또 필요하면 파티클 시스템을 만져 이펙트를 만들거나 애니메이션 몽타주 시스템을 만져 빨리 스킬을 만들어낼 수 있어야 했습니다. 또 숫자를 채워 넣고 누군가가 규칙에 맞춰 바꿔야 할 수많은 파일 이름을 자동으로 바꾸는 뭔가를 만들기도 하고 심지어 라이브 대응 대문에 자리를 뜰 수 없는 누군가가 목이 마를 것 같아 물을 떠다 주는 것 역시 업무 범위의 일부였습니다.

그렇게 프로젝트와 팀을 잘 살펴보며 누군가 어려움에 처해 있으면 얼른 뛰어들어 위기를 해결하고 다시 내 자리로 돌아오곤 했습니다. 다만 이런 행동은 자세히 관찰하지 않으면 전혀 표가 나지 않습니다. 팀은 원래 잘 돌아가고 커피머신에 커피는 항상 잘 채워져 있으며 오피스에 식물들은 항상 말라죽지 않고 당연히 잘 살아있습니다. 또 어째서인지는 모르겠지만 팀에 간이 의자는 항상 적당한 갯수가 돌아다니고 있고 의자가 부서지면 또 새 의자로 당연히 교체되고 있습니다. 이런 결과에 어떤 인력이 동원되었으리라 상상하기는 쉽지 않습니다. 마일스톤 마감 때 마일스톤 목표 수립 때 생각지 못한 요구사항이 이미 반영되어 동작하고 있어도 이 정도는 우리 프로젝트 구성원들의 역량으로 충분히 극복한 것으로 볼 수 있습니다.

개인적으로 지금까지 살아 온 세계는 이런 세계였습니다. 솔직히 표가 나지 않아 작은 노력이 딱히 인정 받지 못할 때 마음이 아프긴 했지만 결국 런칭 하고 나면 누군가에게 자랑할 만한 이력이 생겼고 전체적으로 볼 때 그리 나쁘지 않았습니다.

한번은 기획팀이 새 멤버를 충원했고 한동안 함께 생활하다가 두어 번 고개를 갸웃 거린 적이 있었습니다. 한 번은 이 분이 포트폴리오로 제출해 주신 자료로 미루어 비록 직접 코드를 다루고 있지는 않았지만 개념을 잘 이해하고 있는 것 같아 보였고 굳이 기형적인 엑셀 파일과 이를 뒷받침하는 코드를 개발할 필요가 없을 것 같아 우리가 사용하는 스크립팅 환경을 익힐 것을 주문했는데 결국 내 해석으로는 ‘적극적인 거부’에 해당하는 답변을 주셨습니다.

이 때 답변이 틀리지 않았다고 생각합니다. 직업 프로그래머가 아닌 우리들이 코드 만드는 방법을 익혀 봤자 학부생 수준에도 도달하지 못할 것이 뻔한데 뭐 하러 우리들이 고생해서 코드 만드는 방법을 배우느냐는 것이었고 우리들을 위한 개발 환경을 별도로 갖추면 우리들이 익숙한 방법으로 일할 수 있지 않느냐는 것이었습니다. 틀리지 않았습니다. 어쩌면 개인적으로 업무 영역을 넓히는데 관심을 가지면서 굳이 우리가 직접 할 필요 없는 일을 담당해 기획팀을 고통스럽게 만들고 있었을 수 있었습니다. 다들 괴로운데도 내게 이야기하지 않고 그저 고통 받으며 익숙하지도 않고 또 할 필요도 없는 일을 떠맡고 있었을 수 있었습니다.

한번은 게임에 로그를 만들어 넣으면서 로그 생성에 선택한 스택이 이전에 다른 프로젝트에서 사용해본 것과 조금 다른 환경을 제공하고 있었습니다. 물론 이전에는 이미 데이터 분석에 필요한 조회, 통계 환경이 이미 잘 갖춰진 바탕 위에서 로그를 개발했고 게임이 달라지더라도 항상 이미 잘 정리된 동일한 조회 환경에서 작업할 수 있었습니다. 하지만 우리는 그런 잘 갖춰진 환경의 도움을 받을 수 없는 상황이었고 로그를 적재하는데 선택한 스택에 호환되는 조화 환경을 학습해야만 하는 상황이었습니다. 대강 살펴보니 몽고DB에 조회하는 형식과 비슷해 보여서 아주 나쁜 상황은 아니라고 생각했고 당장 내가 이 환경을 익히고 있으면 안 될 것 같아서 담당자에게 업무 지시를 했습니다. 일단 학습해 보고 막히는 부분이 있으면 함께 학습해서 익숙해지면 될 거라고 생각했습니다.

하지만 이번에도 적극적인 업무 거부 의사 표현을 마주하게 됐는데 이번에도 납득할 수 있는 이유였습니다. 잘 갖춰진 로그 조회 환경을 개발하는 것은 우리 업무가 아니며 업무가 진행되지 않은 상태에서는 업무에 착수할 수 없는 상황으로 판단해야 한다는 것이었습니다. 사실 이런 이야기는 지금 하는 표현보다는 좀 더 거친 상황에서 진행되었지만 내용을 정제하면 굳이 우리가 할 필요 없는 업무를 제시하고 있으며 아직 다른 부서의 업무가 완료되지도 않은 상황에서 일을 만들어내고 있다는 평가를 받았습니다. 사실 이 일은 업무 지시의 부당함을 느끼신 스탭님의 문제 제기로 범위가 조금 더 넓어졌고 그리 부드러운 결말을 맞이하지는 못했습니다.

이 사건을 겪으면서 개인적으로 내가 믿고 살던 세계의 붕괴를 겪었다고 평가합니다. 지금까지 일을 해 오면서 딱히 이유 없이 빈 자리가 보이면 알맞은 사람을 연결해 주거나 알맞은 사람이 없지만 제한 시간이 촉박한데 마침 내 손이 비어 있다면 당장 뛰어들어 문제가 생기지 않도록 하는 행동이 당연하다고 생각해 왔습니다. 그게 내 전문 분야가 아닐 수 있습니다.

하지만 개인적으로는 프로젝트 전체에 걸쳐 모든 업무가 항상 한 분야의 높은 전문성을 요구하지는 않습니다. 당장 스킬에 붙일 애님몽타주가 없으면 스킬에 아무 것도 안 나가지만 이미 완성된 애니메이션을 얼른 조합해 에셋을 만들면 최소한 고장나지는 않은, 보기는 좀 그렇지만 동작은 하는 결과를 만들어낼 수 있었습니다. 당장 로그 조회 환경이 준비되지 않은 상황이라면 자주 사용되는 통계를 구하는 스크립트를 재빨리 만들어 내 비즈니스 부서가 짧은 기간 안에 올바른 의사결정을 하는데 도움을 줄 수 있었고요. 이런 일에는 특정 분야의 전문성 보다는 전반적으로 기술적인 방법을 알고 있는 쪽이 더 중요했고 어쩌다 보니 이런 방법들을 빨리 익힐 수 있었기 때문에 전문성을 가진 원래 업무 말고도 아무데나 뛰어 들어 일을 진행 시키곤 했습니다.

하지만 그런 일이 정말로 프로젝트 전체에 도움이 되었는지는 냉정하게 다시 생각해볼 필요가 있습니다. 먼저 내 이런 행동으로 팀이 필요 이상의 일을 떠맡아 고통 받고 있었지만 내게는 말할 수 없는 상황에 항상 처해 있었을 수 있습니다. 또 이런 행동이 모여 다른 부서가 기획팀을 대상으로 한 업무를 깔끔하게 완결하지 않는 습관을 만들었을 가능성이 있고 만약 그렇다면 거기에 상당히 기여했을 수 있습니다. 다른 스킬을 익히느라 정작 게임디자이너로써 갖춰야 할 적합한 전문성을 갖추는데 소홀한 나머지 올바르지 않은 의사결정을 반복했을 수 있습니다.

사실 이 일은 중간에 잠깐 이야기했다시피 그리 예쁜 모양으로 끝나지는 않았습니다. 일은 어떻게든 마무리 되었지만 지금까지 옳다고 생각하며 살던 세계는 붕괴했고 앞으로 자신의 행동에 대해, 자신이 행동하려고 하는 그 순간마다 과연 이 행동은 붕괴한 다음의 새로운 세계에서 올바른 의미를 가지는지, 팀에는 올바른 행동인지, 또 프로젝트에는 올바른 행동인지 계속해서 의심해보게 될 것 같습니다.