기획서를 ○○로 작성하지 않는다고?

한번은 팀에 새로 오신 중니어님과 면담을 하다가 그 분이 느끼는 팀의 여러 문제점에 대한 이야기가 나왔습니다. 문제점 설명에는 제 기준으로 꽤 선정적인 단어들이 나타났고 그 단어들 만큼이나 문제점들 역시 선정적이라는 느낌을 받았습니다. 한편으로는 그 지적들이 아주 틀리지는 않으며 중장기적으로 개선해 나갈 여지가 있습니다. 하지만 다른 한편으로는 이런 문제 제기는 팀이 처한 상황과 맥락을 고려하지 않은 경우가 많기 때문에 이를 고려해 평가할 필요는 있습니다. 선정적인 문제 제기는 반성할 기회를 주기도 하고 또 상황과 맥락에 대한 코칭이 필요한 순간이기도 합니다.

별로 만족스럽지 않은 면담을 마친 다음 두 가지 주제에 대해 생각해 보기로 합니다. 하나는 프로젝트가 전통적인 MMO 개발팀에 비해 효율이 낮은 방식으로 일하고 있다는 점, 그리고 다른 하나는 기획팀이 너무 오래된 방식으로 문서를 작성하고 있다는 점입니다.

여느 MMO 게임 프로젝트는 여러 모로 보수적인 의사결정을 할 때가 많습니다. 일단 한국 시장에서 MMO를 개발하기로 한 결정 자체가 보수적입니다. 개발 난이도와 이에 수반되는 위험성은 엄청나게 높지만 다른 한편으로는 이 장르에서 상업적인 성공을 거둔 사례가 많기 때문에 잘 모르는 장르를 개발하려고 시도하는 것 보다는 훨씬 안전한 선택이라고 할 수 있습니다. 또 인력 시장에서 MMO 좀 만들어 본 사람을 구하기는 아직까지는 다른 장르에 비해 어렵지는 않은 편입니다.

MMO 장르는 개발에 시간이 많이 걸리고 또 컨텐츠를 양산하는데 비용이 많이 들며 기술 수준이 다른 여러 직군이 섞여서 일하고 그들을 교육하는데 비용을 거의 쓸 수 없을 때가 많기 때문에 온라인에서 흔히 마주치는 팬시한 방법이나 도구를 적용하기 어려울 때가 많습니다. 방법이 낡고 현대에는 그리 안전하거나 효율적이지 않더라도 과거 방식에 익숙해진 스탭들과 일하려면 오래된 방식을 선택할 수밖에 없을 수도 있습니다. 그렇다 보니 익숙한 팀에서 MMO 개발은 초기에 빠른 속도로 개발이 진행됩니다. 모두가 익숙한, 그리고 검증된 방식으로 개발하고 있기 때문인데요, 그러다가 높은 분이나 스폰서의 거절할 수 없는 모호한 요구사항이 비집고 들어오면 순식간에 아수라장이 되며 이 상태를 극복하느냐 그러지 못하느냐에 따라 게임의 런칭 여부가 결정되곤 합니다.

이런 상황으로 MMO 팀에서 현대적인 뭔가를 적용하려는 시도는 아무리 사소하더라도 항상 거대한 장벽에 가로막히곤 했고 처음엔 여기에 저항하려고 노력해 봤지만 아무도 달가워 하지 않았습니다. 심지어 이 저항의 결과에 따라 업무 환경이 개선될 것이 확실한 사람들조차도요. 영화 매트릭스 처음 부분에 모피어스가 시뮬레이션에서 네오에게 착취당하는 구성원들이라도 사회의 변화에 자항할 가리고 설명하는 장면을 떠올리게 합니다.

한편 참여하고 있는 MMO 프로젝트는 이전보다는 좀 더 현대적인 뭔가를 시도해 볼 여지가 있는 상황입니다. 어쩌다 보니 그게 가능할 것 같은 스탭들이 모였고 또 프로젝트 의 목표 자체가 이전의 여느 MMO와는 상당히 달라 전통적인 방식 만으로는 개발을 완수할 수 없을 것 같았고 또 우리가 이전처럼 충분한 자원을 사용할 수 있는 상태도 아니어서 익숙하고 안전하지만 자원이 더 필요한 방법 대신 생소하더라도 자원을 절약할 수 있는 방법을 찾아야만 했습니다. 이런 시도 중에는 언리얼 엔진의 개발환경을 이전에 비해 훨씬 더 적극적으로 사용하는 것이 있었습니다.

언리얼 엔진을 상업 게임 개발에서 처음 접한 건 언리얼 토너먼트 2004가 출시될 즈음에 사용 가능하던 언리얼 엔진 2.x였는데 기획자 입장에서 본 언리얼 개발환경의 변화에서 대략 설명한 것처럼 개발팀의 언리얼 엔진에 대한 이해도는 낮은 편이었습니다. 언리얼에 기반해 개발하려면 언리얼이 제안하는 개발 환경에 적응해야 했지만 당시 우리들은 이 방식에 적응하기 보다는 언리얼을 우리가 익숙한 방식으로 고치려 했고 언리얼 엔진과 비슷한 수준에 도달하기 위해 상당한 자원을 소모해야만 했고요. 비슷한 일은 이후에도 일어나 업계에 들려오는 ‘언리얼 엔진 마개조의 결과’로 출시된 전설적인 게임들로 나타나곤 합니다.

하지만 이번에는 우리에게 익숙한 방식으로 언리얼 개발환경을 고치기 보다는 언리얼이 제공하는 개발 방식에 최대한 적응해 비용을 최소화 하는데 집중하고 있습니다. 가령 이전에는 여러 프로젝트에서 언리얼이 제공하는 i18n 기능을 사용하는 대신 익숙하게 사용하던 별도 테이블에 기반한 텍스트 매칭을 개발해 사용했고 언리얼에서 제공하는 데이터 입력 방식 대신 전통적인 엑셀에 기반한 데이터 변환 파이프라인을 구축하는 대신 언리얼 개발환경이 제공하는 데이터 기술 방법을 최대한 활용하도록 했습니다.

이런 맥락에서 초반 개발은 이전처럼 빠른 속도로 진행되지는 않았고 데이터를 입력하는 입장에서 이전에 겪은 다른 프로젝트에 비해 속도가 충분히 나지 않는 것처럼 보이는 것도 사실입니다. 이런 상태를 보고 비효율적인 데이터 핸들링을 지적 받는 것도 이상하지는 않습니다. 한편 그럼에도 불구하고 이번에는 정말 필요하지 않은 이상 엑셀 기반의 데이터 변환 파이프라인을 구축하지 않으려고 노력할 작정인데 이유는 이를 개발하고 유지보수할 자원을 다른 개발에 활용하고 데이터 입력 자체는 언리얼 엔진이 제시하고 또 포트나이트를 통해 검증된 파이프라인을 적용하려고 하기 때문입니다.

한편 기획이 너무 오래된 방식으로 문서를 작성한다고 평가된 점은 제 관점에서 이전의 맥락을 생각해볼 때 아주 틀리지는 않으며 개선할 여지가 있고 다른 면으로는 중니어님의 맥락의 연장에서는 별 필요 없는 사항을 기획서에 기술하는데 시간을 쓰고 있다고 느낄 수도 있을 것 같습니다. 기획서의 형식은 항상 골칫거리였습니다. 사수가 없는 환경에서 기획서를 어떻게 써야 할 지 잘 알 수 없어 기획서를 읽을 사람들의 요구사항을 들어 재구성할 수밖에 없었습니다. 이런 과정을 거치며 이 직업을 지망하는 분들이 모여 계신 커뮤니티에 나타나곤 하는 기획서 포멧은 일상적인 경험과는 너무 동떨어진 뭔가 이상한 형식일 때가 많아 신뢰하기 어려웠습니다.

기획서는 크게 세 가지 요구사항을 함께 충족해야 했습니다. 첫째. 기능이 완성되었을 때의 모습과 이 모습이 게임에 미치는 영향 따위를 설명하는 일종의 하이컨셉, 둘째. 기능의 핵심 동작과 플로우를 설명해 문서를 읽는 사람이 기능을 이해하게 만드는 프리젠테이션 용도에 가까운 문서, 마지막으로 기능을 개발하며 나올 것으로 예상되는, 그리고 실제로 나오곤 하는 여러 요구사항에 대한 의문을 예상해 이를 체계적으로 기입한 문서입니다.

이들을 ‘기획서’라는 이름으로 퉁치다 보니 상황에 따라 다른 문서를 다른 형식으로 작성해야 할 지 아니면 한 가지 문서를 작성해 여러 가지 용도로 사용할 수 있어야 하는 건지 판단하기 쉽지 않습니다. 결국 세월이 흐르며 각 상황에 맞는 문서를 따로 만들 만한 자원을 절대로 확보할 수 없다는 사실을 깨달았고 항상 세 번째 용도를 커버하는 문서를 작성하되 나머지 요구사항을 적당히 커버할 수 있는 내용을 언급한 한 가지 문서를 만드는 쪽으로 굳어졌습니다.

문서 포멧 역시 시간이 흐르며 바뀌었는데 몇 곳에서는 워드 문서로 작성해 형상관리도구에 올려 공유했고 다른 몇 곳에서는 트랙 위키나 도쿠위키, 컨플루언스, 노션 같은 도구를 사용했습니다. 전자는 주로 아주 오래 일한 분들이 리딩하는 팀에서 나타났고 후자는 주로 문서가 URL 형태로 관리되고 서로 연결되어야 함을 인식하는 분들이 리딩하는 팀에서 주로 나타났습니다. 개인적으로는 후자를 선호하는데 문서를 더 단순하고 쉽게 작성하도록 강제될 뿐 아니라 버전 관리에 완전히 신경을 끌 수 있고 공동작업이 단순해지며 아무 환경에나 URL 형태로 공유할 수 있기 때문입니다.

한편 이런 문서 포멧은 앞에서 이야기한 컨셉을 설명하는 문서에는 썩 적합하지 않을 수 있습니다. 이런 문서는 글보다는 그림이 더 많이 들어가는데 그런 형식의 문서는 확실히 전통적인 문서 보다는 프리젠테이션 문서에 더 잘 어울리기 때문입니다.

중니어님의 지적으로 돌아가 기획팀이 너무 오래된 방식으로 문서를 작성하고 있다는 말의 구체적인 사례와 비교할 만한 오래되지 않은 방법은 프리젠테이션을 감안한 컨셉 문서와 엑셀에 작성한 문서였습니다. 사실 컨셉을 효과적으로 설명하기 위한 프리젠테이션 형식의 문서에는 공감하는 바가 있었습니다. 하지만 결코 그 문서만으로는 개발을 진행할 수 없다고 생각해 왔는데 그 문서만으로 개발이 가능했다고 답하시는 것으로 미루어 누군가 그 문서의 낮은 정보량을 중간에 보이지 않는 곳에서 피똥 싸며 메워 주던 사람이 있지 않았을까 싶었습니다. 우리는 그런 사람을 중간에 둘 생각이 전혀 없기에 이 제안을 받아들이지 않을 작정입니다.

한편 엑셀에 작성한 문서는 개인적으로 좀 충격적이었는데 종종 채용을 검토할 때 받은 포트폴리오 문서에 엑셀의 여러 셀 사이를 아슬아슬하게 오가며 작성한 문서를 제출하시는 분들을 보며 받았던 충격이 다시 떠올랐기 때문입니다. 그런 문서를 보며 도대체 왜 문서 모양을 엑셀에 작성하는지 전혀 이해할 수가 없었습니다. 그런데 이번에 이 분께 상황을 좀 더 여쭤 보니 엑셀 파일이 데이터 역할을 하며 동시에 그 데이터 파일의 다른 워크시트에 기획서를 작성해 데이터와 문서가 통합된 형태의 문서를 작성해 업무를 진행한 경험이 있었던 것 같습니다. 그렇다면 기획서를 프리젠테이션 형식으로만 작성한 것은 아니지 않느냐고 여쭤봤는데 엑셀에 작성된 기획서는 거의 데이터 작성 방법만을 기술한 형태였고 정보 밀도가 개발에 필요한 수준만큼 높은 문서는 정말로 없었습니다.

그렇게 기획서를 써서 개발이 가능했다는 사실을 부정할 생각은 없습니다. 하지만 동시에 이 분 눈에 보이지 않는 누군가가 피똥 싸며 일했을 것이 확실한 방법에 대한 제안을 받아들일 생각 역시 없습니다. 이런 스토리 전체를 설명하는 대신 모호하지만 개발의 역사를 존중하고 맥락을 고려해 달라고 설명하며 자리를 마무리했지만 데이터와 문서의 형식에 대한 이 대화는 앞으로도 한동안 고민할 거리라고 생각합니다.

추신. 이 글의 제목은 선정적 ○○ 만들기의 실험에 의한 것입니다.