왜 뻔한 기능을 항상 다시 개발할까

트위터 타임라인에서 게임마다 비슷하거나 솔직히 거의 똑같은 아웃게임을 왜 재사용하지 않고 매번 다시 만드는지에 대한 의문을 보았습니다. 그래서 이유를 생각해 보기로 했습니다.

정말 부끄러운 일이지만 비슷한 기획서를 서로 다른 팀에서 매번 다시 쓰고 비슷한 기능을 다시 구현하기를 반복하고 있습니다. 만약 이런 기간을 줄이면 게임의 핵심 플레이를 여러 번에 걸쳐 재작업 하면서도 전체 개발 기간을 줄이는데 크게 기여할 수 있을 겁니다. 하지만 현실은 오랜 기간 동안 같은 기능을 문서부터 다시 작성하며 비용을 소모하곤 합니다. 서로 다른 게임마다 거의 비슷한 기능을 재사용하려는 시도가 없었던 것은 아닙니다. 경험해본 두 가지 사례를 소개합니다.

본부 별로 서로 다른 여러 프로젝트를 개발하는 어떤 큰 회사에서는 커뮤니티 시스템이 이미 구축되어 있고 이를 각 게임에 붙여 개발했습니다. 메신저, 길드 같은 시스템이 이미 완성되어 있고 게임 개발팀이 준비되어 커뮤니티 관련 부서에 요청하면 기능을 붙이는데 필요한 바이너리와 매뉴얼을 받을 수 있었습니다. 지금 와서 생각해보면 그 메신저와 길드 기능이 아주 훌륭하지는 않았고 또 게임 개발팀의 요구사항이 잘 받아들여지지도 않았습니다. 하지만 이 각 기능을 개발한다면 적어도 한 마일스톤을 소모했겠지만 매뉴얼에 따라 기능을 붙여 며칠 만에 테스트를 시작할 수 있었습니다.

커다란 성공을 거둔 원작의 후속작을 개발하던 회사에서는 원작 개발팀과 모든 문서를 공유하는 환경을 제공했습니다. 후속작을 개발하던 우리가 작성한 문서 역시 원작 개발팀에 공유되고 있어 상당히 부담스러웠습니다. 하지만 우리는 원작 개발팀이 오랜 기간에 걸쳐 겪은 모든 삽질 기록을 살펴보고 이를 미리 피할 수 있었습니다. 원작의 기능을 우리가 만드는 후속작에 추가하면서 기획서를 아예 안 쓴 것은 아니었지만 원작 개발팀에서 공유한 여러 정보에 기반해 처음부터 요구사항 수준을 끌어올릴 수 있었습니다. 원작과 우리 사이에 사용하는 엔진이 달랐지만 게임 엔진 특징이 다들 비슷비슷해서 원작 개발팀이 겪었던 기술적인 문제는 우리가 사용하는 엔진에서도 비슷하게 나타났는데 이때 원작 개발팀이 공유한 문서를 통해 이 문제를 미리 예상하고만 있어도 큰 도움이 되었습니다.

항상 이렇게 일이 잘 되는 건 아닙니다. 프로젝트를 시작하려고 초기 멤버를 모으고 팀을 빌딩하면 사실은 팀 뿐만 아니라 팀을 둘러싼 모든 시스템을 새로 구축하게 됩니다. 이는 팀이 서서히 바뀌어 가는 이야기에서 설명한 적이 있습니다. 회사에 그나마 개발 지원 경험이 있다면 우리가 구매를 요청하는 자원에 큰 의문을 가지지 않고 선선히 승인해 주는 정도가 우리가 기대하는 수준입니다. 만약 회사에 이전 개발 지원 경험이 없다면 시스템을 재구축하는데 필요한 자원에 의문을 재기하며 개발팀을 피곤하게 만들기도 합니다.

새로 채용한 모든 개개인은 각자의 개발 경험을 가지고는 있지만 각자가 이전 회사나 이전 팀과 맺은 계약 때문에 이 경험을 직접적으로 활용할 수가 없습니다. 게임마다 비슷한 기능 요구사항을 작성하기 위해 다른 프로젝트에서 작성한 문서를 참고하는 일은 종종 일어납니다. 회사도 이런 행동까지 통제하기에는 필요한 자원에 비해 효용이 너무 작으므로 눈감아 주는 편인데요, 이전 요구사항을 직접 재사용하면 법적인 문제를 겪을 수도 있습니다. 이 사례를 이야기하긴 좀 그렇지만 사례를 언급한 책이 있습니다. (물론 이 사례를 읽으려고 책을 살만한 가치는 없습니다. 필요하면 제가 빌려드립니다.)

정리하면 게임마다 비슷한 기능을 프로젝트마다 다시 개발하고 있고 이건 큰 낭비입니다. 적어도 회사 수준에서 이 비용을 줄일 시도를 할 수 있을 겁니다. 다만 개인 수준에서는 이전 회사와 맺은 계약 때문에 함부로 이런 시도를 하기 어려운 한계가 있습니다.