플레잉 하드 Playing Hard (2018)

VOD(Netflix)
2019. 04. 22.
★★★☆☆

2017 년 발매 된 Ubisoft의 트리플 A 액션 게임 For Honor 의 제작 과정을 다룬 다큐멘터리 영화. 게임의 디렉터인 제이슨 반덴베르그(Jason Vandenberghe)와 프로듀서인 스테판 카딘(Stéphane Cardin)을 중심으로 제작 중 벌어진 다양한 일들을 담담하게 쫓아간다.

“이거 진짜 끝내주게 재미있을 겁니다”로 시작하는 프로젝트 제안. 자신들의 피와 땀이 들어간 게임을 재미있어하는 개발자들. 설레임 가득한 첫 게임 공개. 모자라는 개발 시간과 하나 둘 떠나가는 동료들. 약속한 대형 피처를 취소하는 난관. 프로듀서의 장기 잠적. 우여곡절 끝에 넘어간 골드 마스터와 성공적인 발매. 그리고 후속작을 만들 수 없다는 통보를 받은 게임 디렉터의 뒷모습을 끝으로 영화는 막을 내린다.

개인이 되었든, 제작 집단이 되었든. 게임 제작자라면 수차례 겪어봤을 이야기들을 제 3자의 시선으로 담담하게 풀어내고 있는 이야기를 보고 있으니 부러움, 걱정, 공감, 분노가 모두 뒤섞여 복잡한 기분이 되어버렸다. 영화를 보고 ‘누군 안그래?’ 라고 툭 던져버리고 끝내기엔 아마도 스트레스가 쌓일대로 쌓인 모양이다.

게임 개발자를 위한 SVN (1)

들어가기에 앞서

십 수년 전, 혈기왕성하고 의욕만 앞선 친구들과 모여 게임 개발을 위한 팀을 조직하고, 게임 개발의 열정을 소모하고 있었을 때만 하더라도, 게임 개발은 젊은날의 열정과 패기만 가지고도 충분히 매력적이었고 재미있는 일이었다. 하지만 상업적인 목적의 게임 시장이 발전하기 시작하고 산업으로 그 규모가 커지기 시작하면서 부터 게임 개발은 점차 열정과 패기만으로 도전 가능한 일이 아니게 되었다. 모든 산업이 그러했듯 가내 수공업 형태에서 산업화가 이루어지기 시작하면 그에 수반하는 여러가지 새로운 장치들과 기법들을 필요로하기 시작한다. 게임 개발 역시 몇몇 사람이 누군가의 공부방이나, 창고에 삼삼오오 모여 꿈을 펼칠 때는 필요하지 않았던 프로젝트 관리 기법이나 커뮤니케이션 방법론, 프로세스 관리 기법 등이 점차 필요하게 되었다.

대한민국의 게임 산업은 지난 수십년간 다른 기성 산업들에 비하여 급격하게 성장을 하였지만, 게임을 개발하는 조직은 그 성장의 속도에 발빠르게 대처하질 못하고 있다. 대다수의 회사들은 여전히 오래전 아마추어 취미 활동 때의 추억을 가지고 무리하게 개발 팀을 운영하려는 과오를 저지르고, 세상에 알려지지도 못한 수 많은 개발 팀, 회사들이  생성되었다 사라지기를 반복하고 있다. 팀이 유지되지 못하고 사라지는 이유에는 여러 가지가 있을 수 있지만, 방만한 개발 프로세스 관리는 그 중 가장 심각한 원인이라 할 수 있다.

SVN은 보통 버전 관리 시스템 Software Version Control System:SVCS 이라 불리우는 개발 관리 도구이지만, 게임 개발 프로젝트에 동원되는 모든 데이터 리소스-프로그램 소스 코드, 기획 문서, 그래픽 리소스 등-를 관리하는 용도로 많이 쓰인다. 프로젝트의 작업 결과물에 대한 변경 관리, 변경 추적 등이 가능하며, 리소스 데이터의 공유 및 배포 역시 SVN을 통하여 사용이 가능하다.

아직까지는 대다수 의 게임 제작 프로젝트에서 프로그래머 그룹을 중심으로 SVN을 이용하는 경우가 늘고 있으나, 기획, 그래픽, 사운드 등 여타 파트의 경우에는 사용 방법의 난해함 등을 이유로 업무 자료의 관리에 공유 폴더나 메일 등을 이용하고 있는 경우가 대부분이다. 하지만, 점차적으로 SVN 등의 버전관리 시스템을 이용하여 데이터 리소스를 관리하는 프로젝트가 늘어나고 있기 때문에, 이러한 버전관리 프로그램의 개념과 사용법을 익히는 것은 파트를 막론하고 게임 개발자로서 기본적으로 익혀야 할 업무 기술이 되어가고 있다.

국내에서는 여러 블로그나 몇몇 프로그래밍 전문 서적 등을 통하여 SVN 혹은 기타 다양한 버전관리 소프트웨어의 사용법 등이 소개되고 있지만, 프로그래밍을 제외한 다른 파트의 게임 개발자들을 위한 가이드는 아직까지 존재하지 않은 것으로 알고 있다. 시스템의 도입 여부는 전적으로 팀의 의사결정에 따른 일이지만, 이를 도입한다 하더라도 처음 시스템을 접하게 되는 기성 개발자나 혹은 업계에 첫 발을 내딛는 신입 개발자들을 위한 가이드가 없다는 것은 커다란 불편사항 중 하나이다.

이 문서는 SVN을 개발 프로세스에 적용시키는 팀에서 SVN을 처음 접하게 되는 개별 팀원들을 위한 가이드를 목적으로 작성되었다. 전문적인 프로그래머나 오랫동안 버전 관리 시스템을 구축하여 운영하는 사람, 혹은 버전 관리 시스템의 운영에 대해서 배우고자 하는 사람들을 대상으로 한 것이 아니기 때문에 내용은 단순하고 어떤 부분은 편협한 정보만을 제공 할 수 있다. 문서 후반부에, 좀 더 세부적인 개념이나 사용 방법, 관리 운영 방법을 알고 싶은 분들을 위하여 참고 문헌에 서적 및 외부 자료 링크를 수록하였으니 참고하길 바란다.

버전관리 시스템-SVN 소개

프로그래머인 철수와 영희가 있었다. 둘은 얼마 안가 사랑에 빠졌고, 둘만의 사랑의 결실을 확인하기 위해 프로그램을 만들기로 결심한다. 주변 싱글 부대 소속 동료들의 질투 어린 시선에도 불구하고 둘만의 사랑의 프로젝트는 점차 결실을 맺는 것 같았다.

한창 개발이 진행되는 어느날, 두 사람은 서로의 작업물이 얼마만큼의 성과를 내고 있는지 궁금해졌다. 그래서 공유 폴더에 소스 코드를 한번에 몰아 넣고 빌드Build를 진행 해 보기로 결정했다. 모든 프로그래밍 업무가 그렇듯 한번에 되는 일은 그다지 없기 때문에, 둘의 코드는 빌더 안에서 각종 에러와 경고를 내뱉고 있었다. 둘은 이 정도 고난은 사내에서 펼쳐지는 싱글 부대원들의 중상 모략에 비하면 아무것도 아니라 생각하면서 버그를 정리하기 시작했다.

그렇게 빠르게 소스를 정리하기 시작하는 어느날, 철수는 main.cpp에 포함 된 Hero 클래스에 문제-속성 값에 바람둥이가 추가되어 있어 항상 다른 코드와 바람을 피웠다-가 있다는 사실을 발견하고 버그를 슥슥삭삭 잡기 시작했다. 같은 시각 자신의 집에서 코드를 검토하던 영희 역시 main.cpp에 포함 된 Heroine 클래스의 질투 속성이 프로그램의 전체 조화를 망치고 제 기능을 못하고 있다 판단하고 이를 뜯어고치기 시작했다. 둘은 비슷한 시각에 각자 자신의 작업물을 정리하고 이를 작업용 공유 폴더에 덮어씌웠다.

몇 일이 더 지나고 철수와 영희는 코드를 다시 한번 빌드 하기로 했다. 무슨 일이 벌어졌을까? 수정한 코드는 다른 누군가에 의해서 다시 원상 복구되어 이전과 동일한 버그를 발생시켰고, 둘은 서로 상대가 버그를 복구하고 있는 것이 아닌가 의심하기 시작했다. 예민해진 두 사람은 격한 말들이 오가기 시작했고, 결국 큰 소리로 서로를 비난하다 각자 서로의 사랑을 찾기로 했다. 그들의 사랑의 결실이었던 프로젝트는 그렇게 와해되어 버렸다.

위와 같은 경우(물론 농담이지만)는 보통의 상업/비상업적인 소프트웨어 개발 프로젝트에서는 여러 사람들이 모여 작업을 하기 때문에 위와 같은 상황이 자주 발생하곤 했다. 심각한 경우 프로젝트를 좌초시키기도 하는 문제로까지 발전하기 까지 하자, 사람들은 이러한 상황이 발생하는 것을 미연에 방지하고자 소프트웨어 버전 관리Software Version Management 또는 Software Version Control 기법을 탄생시켰다.

소프트웨어 버전 관리 기법을 지원하기 위한 프로그램 및 제반 요소를 버전 관리 시스템Version Control System이라 한다-시스템에 대한 명칭은 다양하게 존재하는데 RCSRevision Control System, SCMSource Code Managemet , SCSSource Control System 모두 동일한 의미로 사용된다. 소프트웨어 버전 관리 기법이 점차 발전하고 확장해가면서 버전관리 시스템 역시 다양하게 개발되었으며. CVSConcurrent Versions System, SVNSubversion, 소스세이프Source Safe 등, 이들 프로그램은 소프트웨어 버전 관리라는 동일한 목적으로 태어났다.

공유 폴더는 안되나요?-왜 버전 관리 시스템인가

위의 이야기에서 철수와 영희는 서로의 작업물을 하나로 합치면서 공유 폴더를 이용하였다. 만약 완벽하고 빈틈없는 업무 절차가 존재했다면 철수와 영희는 공유 폴더를 이용하여 충분히 프로젝트를 완료 할 수 있었을지도 모른다. 그러나 대부분의 사람들이 그러하듯, 철수와 영희 역시 실수를 저지르는 평범한 인간에 불과하다.

공유 폴더를 이용할 때 발생하는 가장 큰 문제는 변경된 작업물에 대한 기록이나 백업 등의 안전 장치가 전혀 존재하지 않는다는 점이다. 이를 막기 위해서 공유 폴더를 이용하여 작업을 할 때 파일명에 일일이 갱신 날짜나 시간, 버전 등을 삽입하는 경우가 종종 있으나, 이는 근본적인 해결책이 안 될 뿐더러, 자칫 잘못할 경우 리소스 관리 자체가 힘들게 된다.

버전 관리 시스템은 작업물에 대한 백업을 제공한다. 때문에 실수로 작업물을 날려버리거나, 잘못 정리된 작업물을 원하는 시점으로 되돌리는 작업을 손쉽게 진행 할 수 있다. 또한, 각 갱신 시점 별로 데이터를 누적하고 있기 때문에, 필요한 시점의 데이터를 거슬러 복구 할 수 있다.

최신 작업물의 유지와 배포에 대한 문제도 버전 관리 시스템을 이용하게 될 경우 깔끔하게 처리 할 수 있다. 버전 관리 시스템의 저장소와 각 클라이언트Client 가 연결되어있다면, 언제나 어디서든 모든 팀 구성원들은 서로 동일한 최신의(그리고 안전한)작업물을 가지고 작업을 진행 할 수 있다.

작업물에 대한 간단한 기록 및 검색 역시 버전 관리 시스템을 이용하면 관리가 가능하다. 변경 이력Change Log의 입력, 검색 기능을 이용하여 해당 작업물에 대한 변경내역을 파악하기 쉬워진다. 이 역시 공유 폴더에서는 사용할 수 없는 기능이다. 또한, 각 작업자 간 중복되는 작업물이나 동시에 작업한 작업물에 대한 병합Merge 기능을 제공함으로써, 위의 철수와 영희의 사례와 같은 일을 막아주기도 한다. 버전 관리 시스템은 각 작업자 간의 작업물을 하나로 취합할 때 발생할 수 있는 문제점들을 최소화 할 수 있다.

SVN Subversion 이란?

SVN은 오픈 소스 프로젝트 Open Source Project 로 제작된 버전 관리 시스템 구축 프로그램이다. 버전 관리 시스템의 운영에 필요한 모든 기능들을 갖추고 있으며, 대부분의 OS에서 구동이 가능하다. 다수의 프로젝트에 쓰이고 있기 때문에 다양한 통합 개발 환경 IDE: Integrated Development Environment 에 플러그 인을 지원하고 있다. 국내의 경우, IT 업계를 중심으로 프로젝트에 SVN을 도입하는 사례가 급증하고 있으며, 각종 게임 제작 프로젝트에서 전방위적으로 쓰이는 경우가 점차 증가하고 있다.

사후 검토: 포커스 그룹 테스트 Focus Group Test

얼마전 회사에서 끝난 포커스 그룹 테스트 FGT: Focus Group Test 와 관련한 간략한 사후 검토.

 * 이번 테스트 조사에서도 정확한 목적이나 목표도 없이 날림으로 테스트가 진행되었다-그나마 갑자기 ‘내일 모레 FGT 한다’는 말도 안되는 소리를 일주일이나 연기 시키느라 고생했다. 그래도 ‘고작’ 일주일 뿐이라 사실 제대로 준비 된 건 아무것도 없다.

 * 설문지 작성과 실험 환경 조성에 좀 더 많은 공을 들여야 한다. 꽤 많은 설문 문항(68 문항)과 인터뷰 준비, 실험 통제에 심혈을 기울였지만, 설문 분석을 하다 보니 이것 저것 놓친것이 상당히 많았다. 준비 기간을 넉넉하게 잡고 실험 설계는 검토에 검토를 거쳐 짜야 할 듯. 다음번에도 동일한 테스트 및 설문조사를 진행한다고 하면 일단 한달은 걸린다고 이야기 할테다.

 * 명색이 포커스 그룹 테스트인데 정작 포커스 그룹 모집은 개발자들의 지인으로 구성하였다는 것도 아이러니. 제대로 목표한 포커스 그룹인지 검증이 되지 않은 상태라면 역시 조사 결과의 신뢰도에 영향을 미칠 수 밖에.

 * 적은 표본 수는 언제든 문제의 여지가 될 수 있다.

 * 공짜로 해 먹으려고 들지 마라. 최소한의 성의는 테스트 참가자들에 대한 기본 예의이다.

 * 마지막으로, 기껏 FGT로 결과를 뽑아내었는데 테스트에서 나온 문제 말고 엉뚱한거 고치려면 애초에 테스트를 하지 말던가. (크앙!)