우리는 아직도 바퀴를 재발명하고 있다

항상 피드백은 너무나 소중합니다. 이 블로그와 블로그 글에 기반한 뉴스레터를 시작한 이유는 한참 전 혹시 거기 계시면 제게 알려주세요에 소개한 것처럼 암흑의 숲 속에서 한국어를 사용하는 제가 어딘가에서 일하며 여러 가지 생각을 하고 있음을 드러내기 위해서입니다. 시간이 지나며 종종 피드백을 받지만 긍정적으로 기대한 것 보다는 훨씬 적은 피드백을 받을 수밖에 없었는데 현대에 이미 로그인 되어 있는 커다란 기업의 서비스 이외에 어딘가에 로그인을 요구하는 행위 자체가 사용자들에게 너무 큰 불편을 야기했기 때문입니다. 제 스스로가 어딘가 계정을 만들고 로그인하기를 얼마나 귀찮아하는지 생각해 보면 제 자신이 다른 사람들에게 그런 행동을 요구하고 있다는 사실이 얼마나 이율 배반적인지 쉽게 생각할 수 있습니다. 그럼에도 아주 드물지는 않게 종종 피드백을 받고 제가 늘 반복하는 생각 말고 다른 생각을 해 볼 기회가 생겨 피드백이 너무나 소중합니다. 여러 주 전 그 규칙은 말이 됩니다. 그런데 고객에게 어떤 경험을 주나요?를 공유했는데 임시 인벤토리 처리 규칙을 계속해서 유지하려는 디자이너님께 그 규칙이 얼마나 이상한지 설명하는 것이 핵심입니다. 하지만 여기에는 여러 프로젝트에 걸쳐 똑같은 기능을 반복해서 개발하는 내용이 깔려 있었고 더 오래 전 왜 뻔한 기능을 항상 다시 개발할까에 설명한 것과 똑같은 상황을 너무나도 당연하게 또 다시 겪고 있었습니다. 그러다가 지난 글에 대한 피드백을 발견하고 어쩌다 우리는 여전히 똑같은 상황을 반복하며 개발비용을 널럴하게 낭비하고 있는지, 또 이번에는 어떻게 했는지 생각해 보기로 합니다.

여러 게임에 걸쳐 거의 비슷하거나 사실상 똑같은 부분은 생각보다 훨씬 많습니다. 맨 처음 게임을 다운로드 한 다음 실행하는 과정부터 생각해보면 앞서 너무나도 귀찮아하던 계정 생성과 로그인을 시킨 다음 클라이언트를 다운로드 하고 인스톨하고 실행합니다. 종종 이 과정을 웹이나 별도 런처로부터 시작하기도 하기 때문에 이들로부터 로그인 정보를 받아 재확인하고 게임을 실행합니다. 캐릭터를 생성해야 하는 게임이라면 캐릭터 이름을 만들어야 하는데 이미 만들어진 이름과 충돌하는지 확인하고 충돌한다면 다른 이름을 만들도록 하거나 충돌하는 이름을 허용하되 이름 뒤에 임의의 구분자를 붙여 서로를 구분할 수 있도록 하기도 합니다. 인게임에서 만약 인벤토리에 아이템을 모으는 기능이 있다면 그리드 모양으로 표시된 인벤토리에 아이템을 적재하되 어떤 아이템은 아이템 하나가 반드시 인벤토리 한 칸을 차지하지만 또 다른 아이템은 아이템 여러 개가 인벤토리 한 칸에 쌓여 그 수량으로만 표시되기도 합니다. 인게임에는 상점 기능이 있고 상점은 판매하려는 인게임 아이템을 진열하고 이를 인게임 재화와 교환한 다음 플레이어의 인벤토리에 넣어 줍니다. 유료 상점은 이와 비슷하지만 종종 아이템 여러 개가 묶인 패키지 단위로 판매하고 인게임 재화가 아닌 실제 세계의 재화와 교환해야 하며 여러 나라의 법령 준수를 위해 구입한 상품을 직접 인게임에 연동된 인벤토리에 넣어 주는 대신 우편을 통해 전달합니다. 아주 오래된 머드 게임으로부터 계승되어 현대에 이르기까지 발전이 거의 없는 여러 가지 채팅 기능과 고객들을 일시적인, 좀 더 항구적인 단위로 묶어 주는 이름만 다른 여러 가지 파티와 길드 기능, 또 고객들을 비슷한 수, 혹은 비슷한 수준에 따라 구분해 팀을 만들어 주는 매치메이킹, 운영을 위한 공지사항 송출 등 지금 이 문단을 타이핑하며 아무렇게나 생각해봤는데도 서로 다른 여러 게임에 걸쳐 비슷하거나 거의 똑같은 기능이 이렇게 많습니다.

지난번 보통은 훨씬 나중에 개발하곤 하는 우편 기능을 더 빠른 시점에 개발하자는 의견을 내고 이 근거로 인벤토리가 가득 차는 등의 다양한 상황에 임시 규칙을 만들어 여러 사람이 고통 받게 만들지 말고 근본적으로 임시 규칙이 필요 없게 만드는 우편 기능을 통해 이런 고민으로부터 빨리 벗어날 수 있다는 이야기를 했습니다. 우편 기능은 더 나중에 만들 뿐 아니라 종종 주니어 디자이너님께 할당하는 종류의 업무로 분류되곤 합니다. 게임디자이너들이 선망하며 워너비들의 필독서처럼 소개되곤 하는 여러 업계의 전설들이 게임디자인을 구축한 책들을 개인적으로 추천하지 않는데 이들은 게임디자이너로써 생각하는 방법과 고민을 소개해 고양감을 주지만 실제로 우리들이 직장을 구해 프로젝트에 속한 다음 출근해서 처음 하게 되는 업무와는 거리가 너무 멀어 실제 업무에는 거의 아무런 도움도 주지 못하기 때문입니다. 주니어 디자이너님들이 첫 이직을 준비하시면서 보여주시곤 하는 이전 프로젝트에서 수행한 업무를 살펴보면 우편을 포함한 개발 후반에 주로 개발되곤 하는 소위 커뮤니티 기능들, 게임을 처음 실행해 첫 전투에 도달하는 로그인을 포함한 프로세스 정립, 그 시점까지 시니어 디자이너들이 아무렇게나 싸 놓은 똥을 치워야만 하는 ‘무슨무슨 기능 개선 기획서’ 등이 있습니다. 이 기능들을 주니어 디자이너님들께 주로 할당하게 되는 이유는 이런 기능들은 게임의 나머지 부분들로부터 제법 독립적이어서 게임 전체에 대한 이해가 부족한 상태에서도 업무를 시작할 수 있고 게임 전체에 대한 이해가 부족하다는 사실이 업무 결과에 큰 영향을 끼치지 않을 가능성이 높기 때문입니다. 가령 ‘무슨무슨 기능 개선 기획서’를 작성하려고 할 때 게임 전체에 대한 이해나 이 기능이 지금 이 따위로 만들어져 제 기능을 전혀 못 하고 있는 멍청한 상태에 도달한 이유 따위에 관심을 가질 필요가 없습니다. 그저 지금 이 기능이 원래 게임 상에서 수행해야 하는 행동을 정의하고 기 구축된 기능과 목표로 하는 행동 사이의 차이를 정의하기만 하면 됩니다. 때문에 주니어 디자이너님들의 초기 시행착오에 적합한 업무로 쉽게 생각하곤 합니다.

하지만 지난번 우편 문서를 위임하는 대신 제가 후다닥 써버린 이유는 일단 다른 사람이 이 업무의 맥락을 판단하고 요구사항을 준비하는데 분명 시간이 걸릴 텐데 여러 가지 이유로 이 문서는 최대한 빠른 시점에 준비되어 있어야 한다고 생각했기 때문입니다. 물론 다른 프로젝트에서 해 온 대로 주니어 디자이너님께 업무를 할당할 수도 있었겠지만 그렇게 시간을 쓸 만한 상황이 아니라고 생각했습니다. 놀랍게도 여러 프로젝트에 걸쳐 팀 전체는 프로젝트를 개발해 출시하고 고객에게 평가를 받는 행동에 그리 큰 관심이 없을 때가 많고 보통 프로젝트 후반에서야 개발하곤 하는 기능을 미리 만들어야 한다고 설득하려면 계획 뿐 아니라 온전히 정립된 요구사항이 완전히 준비된 상태여야만 한다고 생각했습니다. 이렇게 행동해야 하는 이유에 대해서는 게임디자인 직군의 슬픈 점은 나머지 부서들과 목표가 다르다는데 있다에 설명해 놓았습니다. 어쨌든 제 관점에서 프로젝트의 나머지 구성원들이 그리 협조적이지 않은 상황이 그리 낯설지 않았고 이런 상황에서 어떻게 행동해야 하는지 알고 있었습니다. 그래서 기능을 훨씬 후반에 개발하지도 않고 또 기능을 주니어 디자이너님께 위임해 시간을 더 쓰지도 않기로 결정합니다. 기왕 후다닥 요구사항을 정의해 내면서 당장의 문제를 근본적으로 해결할 생각을 하는 김에 미래에 일어날 문제를 함께 해결할 수 없을까 하는 생각이 들었는데 이건 회사의 운영 부서에서 자신들의 컨플루언스 일부를 제가 볼 수 있는 상태로 설정해 놓았기 때문에 할 수 있는 생각이었습니다. 의도인지 실수인지 모르겠지만 회사 컨플루언스에 제가 하려는 일에 대한 몇몇 키워드를 넣고 검색해보니 운영 부서에서 우편 기능과 관련해 겪었던 문제 기록을 볼 수 있었습니다. 여기에는 여러 가지 이유로 고객들이 보상을 수령하지 못한 상황에 대한 처리, 고객이 보상을 수령했지만 수령하지 못했다고 생각해 문의해 온 상황에 대한 처리 기록들이 있었는데 이들은 우편의 요구사항을 보완해서 상당히 해결할 수 있을 것 같아 보였고 요구사항에 반영합니다. 이 사실은 별 것 아닌 요구사항은 앞으로 몇 년 정도 지난 다음에 소개할 수 있지 않을까 싶습니다.

하지만 이런 제 행동은 근본적으로 이전에 왜 뻔한 기능을 항상 다시 개발할까를 고민했던 상황으로부터 별로 개선되지 않았습니다. 그나마 저 이야기를 했던 지난번에는 같은 회사에서 이미 서비스 중인 다른 프로젝트가 오랜 기간에 걸쳐 작성한 거의 모든 문서에 접근할 수 있었습니다. 덕분에 그들의 초기 고민, 그들이 겪은 기술적인 어려움과 이를 극복하기 위한 기술적 접근과 게임디자인적 접근, 그들이 이미 한번 해 본 실패의 기록, 그들이 하고 싶었지만 결국 현실적인 한계에 부딪쳐 달성하지 못한 이상적인 요구사항 등등을 살펴볼 수 있었는데 개인적으로 이는 굉장히 독특한 경험이었습니다. 여러 회사에 걸쳐 다른 프로젝트가 생산한 문서에 이렇게 자유롭게 접근할 권한을 준 사례는 거의 없었다기 보다는 사실상 그냥 없었습니다. 기껏해야 다른 프로젝트에 아는 사람이 있으면 회사 메신저로 질문하고 답변을 얻는 수준에 그치곤 했고 이런 행동이 프로젝트에 참여하는 한 사람의 생산성을 개선할 여지는 그리 크지 않습니다. 이전에 아마 이 블로그에 쓴 어떤 글에서 소개한 적이 있을른지도 모르는데 어떤 보안을 굉장히 중요하게 생각하는 회사에서는 팀원 입장에서 다른 프로젝트가 생산한 문서에 접근하는 절차가 마련되어 있었지만 저 자신을 포함해 여덟 단계의 결재선이 필요했습니다. 저는 그저 회사에서 서비스 중인 다른 프로젝트에 분명 있을 것 같은 특정 기획서를 참고해 지금 제가 작성하려는 요구사항을 빠르게 작성할 수 있을 거라고 예상해 절차에 따라 문서를 요청했지만 팀원인 저 자신, 팀장, 실장, 제 부서의 본부장, 저 쪽 부서의 본부장, 저 쪽 부서의 실장, 저 쪽 부서의 팀장, 저 쪽 부서의 문서 작성자인 팀원의 결재를 받는데 2주가 걸렸고 문서 접근 권한이 부여되었다는 이메일을 받았지만 저는 이미 오래 전에 그냥 제 기억에 근거해 요구사항을 작성해 협업 부서에 전달해 이미 개발이 끝난 상태였습니다. 그리고 다시는 이런 시도를 하지 않습니다. 이와 비교할 때 이전에 같은 회사에서 서비스 중인 문서에 자유롭게 접근할 수 있던 경험은 꽤 충격적이었고 저는 그들이 여러 해에 걸쳐 쌓은 엄청난 양의 시행착오를 회사와 맺은 보안 계약을 깨지 않는 선에서 최대한 습득하기 위해 열심히 읽고 머릿속에 넣어 구조화 하기 위해 노력합니다.

한편 이번에도 비슷하면서도 조금은 다른 상황에 놓입니다. 어쩌다 보니 저는 커리어 전반에 걸쳐 이미 존재하는 게임의 후속작을 만드는 프로젝트에 참여할 때가 자주 있었는데 이번에도 마찬가지입니다. 그런데 다른 회사에서 이미 서비스가 중단된 게임의 후속작을 개발할 때 이 게임의 아트 에셋에 접근할 수 있는 경우는 많았지만 문서에 접근할 수 있는 경우는 거의 없었습니다. 개발 중단이 선언된 날 오후가 되면 컨플루언스와 퍼포스 디포에 권한이 사라지고 그걸로 끝이었습니다. 이 데이터는 회사 어딘가의 기계나 회사가 관리하는 회사 밖의 클라우드 어딘가에 보관 되어 있겠지만 회사가 큰 돈을 들여 만들었던 이 바이너리 덩어리는 그저 의미 없는 비트의 집합일 뿐 회사가 이를 만들어내기 위해 들인 시간과 돈에 비하면 아무 짝에도 쓸모 없는 상태로 방치되곤 했고 우리들도 이런 데이터가 분명 있으리라는 예상을 했지만 굳이 회사에 요구하지 않습니다. 앞서 간단한 문서 하나를 읽을 권한을 얻기 위해 2주를 기다려야 했던 경험은 저 혼자만의 것이 아니었으리라 생각합니다. 그런데 이번에는 흥미롭게도 전작을 개발했던 사람들이 남겨 놓은 문서에 접근할 수 있었습니다. 다만 이전에 같은 경험을 했을 때와 마찬가지로 개발팀의 웬만한 사람들은 다른 프로젝트의 문서에 자유롭게 접근할 수 있다는 사실을 대수롭지 않게 여기는 것 같았습니다. 지난번에도 우리의 요구사항에 대하 논의하다가 다른 층에서 개발해 서비스 중인 게임이 오래 전에 겪었던 사례를 설명하고 이에 기반해 우리가 해야 할 일을 제안하면 사람들은 그런 정보를 어디서 얻었느냐고 묻곤 했는데 ‘아니 그냥 컨플루언스에 검색하면 나옴요’ 라고 실망스럽게 답했습니다. 이번에도 마찬가지입니다. 프로젝트에 참여하고 나서 현 프로젝트가 생산해낸 문서를 살펴봄과 동시에 이 프로젝트의 전작이 생산한 문서 역시 열심히 살펴봤고 제 플레이 경험과 비교해 이들이 왜 고객으로써 제가 느꼈던 이상한 의사결정들을 하게 됐는지, 이들이 그 사실을 알고 어떻게 이를 수습하려고 했는지 같은 제 관점에서 너무나 흥미로운 정보에 제한 없이 접근합니다.

저는 제 커리어의 첫 프로젝트가 제가 고객으로써 플레이 하던 게임의 후속작을 개발하는 것으로 시작했는데 제가 일하는 곳과 같은 건물에 제가 퇴근하고 나서 플레이 하는 게임을 만드는 사람들이 일하고 있다는 사실을 알고 있는 것 만으로도 기묘한 느낌을 받았습니다. 물론 그들이 생산한 문서를 볼 수는 없었지만요. 그런데 고객으로서 의미 있는 경험을 얻은 게임이 여러 가지 고객 입장에서는 이해할 수 없는 이상한 의사결정을 반복한 끝에 저를 포함한 고객들이 떠나고 회사로부터 서비스 중단 결정을 받은 과정을 알고 있는 프로젝트 구성원들이 생산한 문서들을 살펴보며 이들이 왜 그런 규칙을 만들었는지, 왜 그런 의사결정을 했는지, 그들이 자신들의 문제를 고객 입장에서 제가 느낀 것과 같이 생각했을지 아니면 달리 생각했을지 같은 여러 질문에 대해 비록 온전하지는 않았지만 힌트를 얻을 수 있는 문서 더미를 보고 이번에도 회사와 맺은 보안 계약을 깨지 않는 선에서 열심히 읽고 머리 속에서 구조화 하는데 시간을 보냅니다. 비록 이번에는 이들이 여러 논의 과정에 문서를 만들고 이를 유지관리하는데 별 관심이 없었다는 사실을 알 수 있기는 했지만 그렇다고 문서가 아예 없는 것은 아니었습니다. 저는 이들이 자신들이 처한 문제를 늦게나마 고객들과 비슷한 눈높이로 파악해 문제로 정의하고 있었고 이를 해결하기 위한 방법을 모색하고 있었다는 점을 알게 됩니다. 그들의 계획은 게임 규칙의 꽤 많은 부분을 손 대야 하는 실행을 결정하기에 쉽지 않은 규칙 모양으로 만들어지는 중이었습니다. 어쩌면 이들의 계획이 온전히 준비되고 실행되었다면 당시 고객 입장에서 제가 겪던 그리 유쾌하지는 않았던 여러 가지 경험을 개선할 수 있을지도 몰랐지만 회사는 더 이상 이 서비스의 개선을 기다려 주지 않았고 이들의 기록은 이제 새 문서를 작성할 수 없는 컨플루언스 스페이스에 보존되어 있게 됩니다.

이런 상황에서 저는 회사의 운영 부서가 여러 게임을 운영하며 고객들과 직접 이야기하면서 겪은 몇 가지 문제를 우편 인터페이스를 보완해 상당 부분 해소할 수 있을 거라는 점을 알게 됩니다. 이건 제 아이디어가 아니라 운영 부서에서 일하는 누군가가 작성한 문서로부터 알게 된 것입니다. 그 문서는 운영 부서에서 개발팀에 ‘이런 기능이 있으면 좋겠다’는 제안을 하고 있었는데 그냥 쓱 봐도 운영팀은 고객을 편하게 하기 위한 우편 기능의 일부로부터 문제를 겪고 있었는데 사실 이건 문제가 아니어서 고객들이 그들 스스로 상황을 확인할 수 있게 만들 여지가 있었습니다. 그렇잖아도 적은 인원으로 엄청난 양의 서비스 요청을 상대해야 하는 운영 부서에게 우편 인터페이스의 개선은 자신들의 업무를 크게 줄여줄 수 있었을 겁니다. 하지만 개발팀은 이미 다음 여러 마일스톤에 걸쳐 팀의 퍼포먼스 거의 전부를 쏟아내야 하는 양의 계획에 파묻혀 있었고 팀은 이 계획을 긍정적으로 받아들였지만 결국 실현되지는 않습니다. 하지만 우리는 아직 개발 중이었고 미래에 대비해 미리 정말 그리 대단하지도 않은 우편 인터페이스 일부를 수정해 장차 운영 부서의 로드를 줄일 수 있을 것 같았습니다. 그래서 아무렇지도 않게 요구사항에 그런 인터페이스 개선을 포함합니다. 시장에 나와 있는 다른 게임에 비해, 그리고 회사에서 서비스하는 여러 다른 게임에 비해 더 낫게 동작할 수도 있을 겁니다. 하지만 여전히 근본적인 문제는 전혀 개선되지 않았습니다. 우편 기능은 지금 만드는 게임에도, 회사에서 서비스 중인 여러 다른 게임에도, 시장의 다른 플레이어들이 서비스 중인 온갖 게임에도 거의 비슷한 모양으로 존재하지만 모르긴 몰라도 우리 모두는 또 다시 개발 후반에 팀의 주니어 디자이너님께 우편 기능의 요구사항을 작성해 달라는 업무를 할당할 겁니다. 이 근본적인 문제를 개선할 수 없는 것일까요?

이미 지난 왜 뻔한 기능을 항상 다시 개발할까에 어지간한 이유를 설명했으니 반복하지 않을 겁니다. 또 게임 업계의 고용 형태는 프로젝트 단위 계약직에 가깝습니다에 설명한 대로 우리들은 회사에 고용되어 있다기 보다는 프로젝트에 고용된 상태에 가깝기 때문에 새 프로젝트를 시작하면 마치 바이오스를 바닥부터 개발한 컴팩처럼 행동할 수밖에 없는 것도 사실이며 이 역시 굳이 다시 길게 이야기하지 않을 겁니다. 다만 이번에는 실제로 게임마다 거의 똑같은 기능을 개발해 여러 게임에 SDK를 제공해 순식간에 같은 기능을 여러 게임에 걸쳐 배포할 수 있었던 사례를 잠깐 돌아보고 왜 회사기 이 부서에 힘을 실어 더 오랫동안 유지할 수 없었을지 추측해 보려고 합니다. 사실 우리들이 우편을 매번 다시 만드는 것 같은 상황이 이상하다고 생각해 회사 차원에서 이 문제를 해결하려는 접근을 오래 전 경험한 적이 있습니다. 여전히 저는 어느 게임의 캐릭터를 활용한 다른 장르 게임을 만들고 있었는데 게임에 뻔한 채팅 기능과 뻔한 길드 기능이 필요한 상황이었습니다. 팀은 아주 작았고 우리들이 이런 기능을 바닥부터 개발하기는 정말 쉽지 않을 상황이었지만 회사는 이미 회사가 서비스하는 거의 모든 게임을 관장하는 웹서비스를 개발하는 부서에서 여러 게임에 걸쳐 이런 기능을 제공하는 SDK를 개발해 배포하고 있었습니다. 덕분에 이를 바닥부터 개발했다면 시간을 얼마나 사용했을지 알 수 없지만 매뉴얼 하나, dll 파일 몇 개, 사용할 서버 정보를 받은 다음 고작 며칠 안에 인게임에 그 뻔한 기능들을 구현했고 이들은 이미 만들어져 있었던 기능 답게 별 문제 없이 멀쩡하게 동작합니다. 사소한 문제가 있었다면 이들이 제공한 인터페이스 컬러 스킴은 이 기능이 어떤 게임을 개발할 때 함께 개발되었는지 알 수 있도록 너무나 독특했고 이 인터페이스가 게임에 나타나자 우리들은 기능이 정상 동작한다는 사실에 기뻐하면서도 우리 인터페이스와 새로 붙인 기능의 인터페이스 색상이 너무 안 어울려 입은 웃으며 눈은 찡그린 이상한 표정을 지었습니다. 당연히 이 문제는 몇 시간 안에 해결됩니다.

저는 이 기능을 붙이는데 직접 관여한 엔지니어가 아니지만 이 과정을 지켜보며 희망적인 감정을 가졌습니다. 여러 게임에 걸쳐 뻔한 기능을 이렇게 순식간에 붙일 수 있다면 시간이 지나 이 기능이 여러 게임의 요구사항을 받아들여 발전한다면 게임마다 똑같은 기능이 인터페이스만 달라 보일 뿐 사실은 거의 똑같다는 사실에 기반해 상당히 달라 보이는 요구사항도 잘 받아들일 수 있는 확장성 있는 기능으로 발전해 모르긴 몰라도 개발비용을 상당히 절약할 수 있을 거라고 희망적으로 예상합니다. 하지만 시간이 흐른 다음 살펴보니 더 이상 그 부서는 존재하지 않았고 그 회사의 여러 프로젝트들은 또 다시 며칠 사이에 순식간에 붙일 수 있었던 그 뻔한 기능들을 바닥부터 다시 만드는 시대로 돌아가 있었습니다. 똑같이 개발 후반에 기획팀의 주니어 디자이너님께 요구사항을 정의해 달라고 요청해 그들의 관점에서는 꽤 정성 들였지만 사실은 그냥 시장의 다른 플레이어들이 이미 만든 기능을 모방해 우리의 와이어프레임 문법에 맞춰 작성한 인터페이스가 나열된 문서는 말끔했지만 항상 전혀 인상적이지는 않았습니다. 이번에도 그 뻔한 기능에 아주 작은 개선 사항을 붙인 요구사항을 작성하면서도 왜 우리는 오래 전 그런 말끔한 경험을 안 해본 것도 아닌데 왜 아직도 이러고 있을지 잠깐 생각해봤고 사실은 그 이유를 이미 알고 있다는 사실을 인정할 수밖에 없었습니다. 실은 그들이 회사에 여러 게임에 걸쳐 똑같은 기능을 아주 빨리 붙일 수 있게 하는데 기여하고 있었지만 이들은 회사에서 직접 프로젝트를 개발하는 부서에 비해 그리 좋은 대우를 받지 못합니다. 그들의 기능을 사용한 프로젝트가 상업적으로 큰 성공을 거둬 프로젝트 구성원들이 그에 따른 보상을 받더라도 이들은 지원 부서로써 그런 보상으로부터 완전히 동떨어져 있었습니다. 그러면서도 이들의 업무 난이도는 결코 낮지 않았는데 개발팀의 요구사항을 받아들여 개발하려면 이를 완전히 별도로 개발할 때는 별 것 아닐 수 있는 요구사항이 회사의 여러 제품에 걸쳐 같은 기능을 제공하는 입장에서는 상당히 까다로운 요구사항일 수 있습니다. 요구사항에 대한 대응은 지연되고 개발팀으로부터 받는 평가는 낮아질 수밖에 없습니다.

사실 서로가 이런 상황을 모르지 않았기에 회사가 그 부서를 좀 더 지원하고 프로젝트 팀이 매번 프로젝트가 종료될 때마다 겪는 고용 위기를 겪지 않는다는 사실을 주지 시키고 이들의 업무 난이도를 감안해 회사 차원에서 문제를 해결하는데 집중했다면 개발팀의 아무리 까다로운 요구사항이라도 실은 그냥 설정 파일에 옵션 몇 개를 수정하고 클라이언트를 재시작 하기만 하면 해결되는 수준의 단순한 문제로 바꿔 오랜 세월에 걸쳐 수많은 프로젝트의 개발 비용을 극적으로 절약했을른지도 모릅니다. 하지만 딱히 그런 지원은 없었던 것 같고 부서를 책임지던 임원의 자리가 바뀌자 부서는 흐지부지 사라지고 그 시점까지 개발해 이미 사용되던 기능의 유지보수 인력만 남겨진 채 더 이상의 신규 개발과 기능 대응이 일어나지 않게 됩니다. 사실 이런 상황은 업계 전반에서 찾아볼 수 있습니다. 어느 회사는 그 회사에서 개발 중인 수많은 프로젝트로부터 요구 받은 엄청난 양의 아트 에셋을 생산하는 역할을 맡았지만 이들은 각 프로젝트에 속하지 않고 별도 부서로 존재합니다. 이들은 프로젝트가 런칭 단계에 도달할 때마다 프로젝트 팀과 마찬가지로 엄청난 노동 시간을 불사하며 일했지만 프로젝트가 경제적 성과를 달성하더라도 이에 따른 보상을 공유하지는 않습니다. 어쩌면 이런 접근이 아주 이상하지는 않을 수 있습니다. 일종의 공용 지원 부서는 이미 회사로부터 그 댓가를 받았고 그 이상의 댓가를 바랄 여지는 많지 않습니다. 또 앞서 설명한 고용 안정성 관점에서도 요즘은 이런 행태를 개선하려는 노력이 여러 곳에서 나타나는 중이지만 지원 부서는 프로젝트 각각의 흥망성쇠에 관계 없이 계속해서 비교적 안정적인 고용 상태를 유지할 수 있는데 비해 프로젝트 구성원들은 회사의 프로젝트 중단 결정에 의해 한 방에 모가지가 날아가는 위험을 감수하고 있으니 그에 합당한 보상을 기대할 수 있을지도 모릅니다. 하지만 그렇다 하더라도 이러한 지원 부서들의 기여를 무시할 수 없습니다. 이들은 여러 관점에서 개발 비용을 극적으로 감소 시키는데 기여하고 있기 때문입니다.

실은 이미 다음 마일스톤 계획을 수립하며 딱 봐도 개발 후반에 수행해도 괜찮을 것 같은 우편 기능은 저보다 훨씬 높은 분들의 마일스톤 계획 수립 과정에서 사라져 버렸고 앞서 소개한 개선을 담은 요구사항은 DOA 상태가 됩니다. 제 다른 업무에 영향을 주지 않기 위해 최선을 다해 빨리 작성해 논의 과정에 이미 요구사항이 완전히 정의되어 있음을 어필할 수 있기를 바랬지만 전혀 그렇지 못했습니다. 사실 이 결과를 예상하지 못한 것은 아니기에 제가 너무 순진하게 행동하고 순진한 기대를 한 것은 아닐까 싶은 생각이 들었습니다. 하지만 이 과정에서 여전히 우리들은 여러 프로젝트에 걸쳐 바퀴를 재발명 하고 있고 시간이 지나며 매번 조금 더 나은 바퀴를 발명하고는 있지만 근본적으로 우리들이 바퀴를 재발명하고 있다는 사실이 달라지지 않았음을 부정할 수 없습니다. 회사는 수많은 프로젝트에 걸쳐 똑같은 우편 기능을 개발하며 개발 비용을 낭비하고 있지만 딱히 신경 쓰지 않을 겁니다. 문서나 에셋을 재사용하려 할 때 난이도에 비해 재사용 가능한 기능을 만들어 회사 전체에 걸쳐 유지하는 일은 기술적 난이도 관점에서나 개발 부서와 지원 부서의 관계 관점에서나 그리 만만한 일은 아닌 것 같습니다. 이론적으로, 그리고 이상적으로 회사는 바퀴를 재발명하지 않는 접근을 통해 거대한 비용을 절약할 가능성이 있습니다. 하지만 이를 실행하기는 오랜 세월이 지나 경험이 쌓인 지금도 쉽지 않아 보입니다.