기획자, 그리고 프로그래머

'일을 만드는 사람', 그리고 '일을 하는 사람'. 그러면서도 동시에 같은 목표를 향해 나아가는 사람. 참으로 애매한 관계다. '게임'이라는 하나의 완성된 작품을 만들기 위해 노력하면서두 두 그룹은 끊임없이 논의하고, 충돌하며, 때로는 눈치도 본다. 일을 나누고, 각자 전문적인 영역을 소화해내는 분업 시스템이 구축된지 벌써 오랜 세월이 흘렀지만, 여전히 팀간의 마찰과 소음은 일어나고 있으니 말이다.

당연한 일일 수도 있다. 정말 사소한 일로도 다른 업무를 맡는 두 팀 사이에는 갈등이 생기는 일이 잦다. 사회 생활을 해본 이들이라면 누구나 여실히 공감하리라. 하지만 하나의 작품이라는 공통된 목표를 향해 가는 과정에서 이런 불협화음은 때때로 굉장히 큰 손해를 불러오기도 한다.

MMORPG '테라'로 유명한 '블루홀'의 이상균 디렉터. 학창 시절 '하얀 로냐프 강'을 집필해 작가로 먼저 이름을 알린 그는 다소 파란만장한 경력을 보유한 게임 디렉터다. 프로그래머로 시작해 기획자를 거쳐, 디렉터까지. 게임업계에서만 햇수로 두 자릿수를 넘어간 베테랑이다.

그런 그가, IGC2015의 연단에 모습을 드러냈다. '기획자'와 '프로그래머'. 두 상반된 집단 사이에 흐르곤 하는 미묘한 불협화음은 어떻게 해결해야 하는가? '프로그래머에게 사랑받는 게임 기획서 작성법'이라는 주제로 시작된 강연. 이상균 디렉터의 목소리는 차분하고 나긋했지만, 그 내용만큼은 기존의 틀을 깨는 '파격'으로 가득했다.

▲ '블루홀' 이상균 디렉터



'기획서' : 어째서 쓰기 어려운가?


일단 생각해볼건, '기획'에 대한 개념이다. 이상균 디렉터는 일반적인 다른 업계에서 빈번히 일어나는 '상품 제조'의 프로세스를 먼저 논했다. 대부분의 제조업에서 '기획'은 '생산'과는 다른, 별도의 선행 과정이다. 상품을 만들기 전, 이 상품을 어떤 식으로 만들 것이며, 어떤 성능을 가지게 될지를 결정하는 아주 지극히 기본적인 과정이다.

하지만 '게임'에서도 그게 가능할까? 이상균 디렉터는 '게임'을 기획하는 과정이 다른 제조업과 달라지는 이유가 여기서부터 출발한다고 말했다. 이상균 디렉터는 '게임 기획'을 확정된 기획으로 상품을 만드는 것이 아닌, '반복적인 통합을 통해 공학적 예술품을 만들어 내는 것'이라고 정의했다. 현시점의 게임업계에서 초기 기획안과 최종 빌드가 일치하는 게임을 찾는 것은 불가능에 가깝다. 변수는 너무나도 많다. 기술의 발전, 혹은 오류, 하다못해 인원 변경 따라서도 개발 단계 게임의 내용은 얼마든지 변할 수 있는 것이다.

▲ 애초에 시스템이 다른 상황

결국 '게임 기획'은 기존의 상품 기획과는 전혀 다른 접근이 필요한 분야라 할 수 있다. 이상균 디렉터는 이 때 필요한 마음가짐을 몇 가지로 나누어 설명했다.



1. '완전성'에 대한 환상을 버리자


이상균 디렉터는 먼저, 과거 본인이 직접 만든 프레젠테이션의 일부를 공개했다. 해당 프레젠테이션에는 이런 내용이 있었다. "게임을 기획하는 핵심은 '규칙'이다. 규칙은 정교해야 하며, '완전함'을 목표로 해야 한다." 살짝 부끄러워한 이상균 디렉터는 이어 '이 때는 나도 어렸던 것 같다'라고 말하며 이 명제를 정면에서 부인했다.

게임 기획서는 완전할 수 없어요. 그 수많은 변수를 뚫고, 완벽한 기획서가 존재할 수는 없죠. 기획서를 쓰는 과정에서 실무진인 '디렉터', '기획자', 그리고 '프로그래머' 모두가 기획서가 수정될 수 있다는 사실을 인지하고, 인정해야 해요. 결국 기획자가 써야 할 최선의 기획서는 '변동 범위를 예측할 수 있는 기획서'죠.

또한 이를 위해 '완전성'에 대한 환상을 버려야 해요. 게임 기획서는 절대로 완전할 수 없어요. 때문에 이 변동 가능성을 받아들이기 위해 유연한 팀 문화를 갖추는 과정이 선행되어야 하죠.


▲ 게임 기획서는 절대 완전할 수 없다.

이상균 디렉터는 가끔 "완전한 사양서를 가져다 달라"는 프로그래머들도 존재한다고 말했다. 물론 이들이 잘못된 것은 아니다. 이상균 디렉터의 말에 따르면 보통 이런 사람들은 라이브 서비스 단계에서 개발쪽으로 넘어온 경우에서 자주 볼 수 있으며, 이는 라이브 서비스를 시작한 이후엔 비교적 높은 정확도의 변수 예측이 가능하기 때문이라고 덧붙였다.

중요한 것은 '환상'을 빨리 떨치는 것이다. 완전한 기획서는 있을 수 없다는 것. 이것을 빨리 인정해야 또 다른 목표, 즉 변동 범위를 예측할 수 있는 기획서를 세우는 쪽으로 선명한 목표의식을 가질 수 있다.



2. '의도'를 파악하라


이어 이상균 디렉터는 본인의 군 시절 이야기로 두 번째 화두를 시작했다. 군 생활을 해본 이들이라면 '전시 행동 강령'에 대해 알 것이다. 전쟁 발발 시, 별도의 지시 없이도 병사가 최우선적으로 해야 할 행동 강령이다. 하지만 이는 중대한 허점을 갖고 있다. 예를 들면 '군장을 챙겨 광장에 집결한다.' 라는 행동 강령을 부여받은 병사의 경우, 광장이 포격을 당해 사라졌을 때 어떤 행동을 취해야 할까?

이를 보완하기 위해 나온 방법이 80년대 미 육군사관학교 '톰 콜티츠' 대령이 만든 '지휘관의 의도'라는 개념이다. 명령서의 서두에, 이 행동을 해야 하는 의도를 짧게 서술함으로써, 병사가 유연한 사고를 할 수 있게끔 하는 것이다.

▲ 직설적인 서술이 효과적일 수도 있다.

이 사례가 중요한 이유는 '게임 기획'의 과정에서도 '의도의 누락'으로 인해 일이 생기는 경우가 굉장히 빈번하게 일어나기 때문이다. 보통의 경우, 기획 과정에서 '왜 이것을 해야 하는가?' 즉 '의도'는 게임 디렉터에게 있기 마련이다. 하지만 가장 중요한 가치일 수도 있는 '의도'는 생각보다 자주 희석되고, 또는 누락된다.

물론 이유는 다양하다. 게임 디자이너가 의도를 실질적인 스펙으로 바꾸는 동안 누락되거나, 복잡하게 짜인 기획서 안에서 희석되는 때도 있는가 하면, 처음부터 의도가 제대로 전달되지 않을 수도 있다. 처음부터 의도 전달이 되지 않은 경우는 '디렉터'의 잘못인 경우가 많지만 말이다.

이런 일들을 일소하는 방법이 앞서 말한 '지휘관의 의도'를 기획서에 적용하는 방법이다. 기획서의 서두에 짧게나마 '왜 해야 하는가'를 알려주는 것. 이는 일선 프로그래머들이 작업할 때도 더욱 효율적인 업무를 가능하게 한다.

동시에 프로그래머에게 '당면 과제'를 주는 것도 효율적인 방법이 될 수 있다. 해야 할 일을 모조리 쌓아서 전달하면 프로그래머는 대부분 이렇게 말한다. "안돼요.' (이 "안돼요."는 밑에서 추가로 더 언급하게 된다.)

하지만 월마다, 혹은 일정 기간마다 해야 할 일을 구분해 표시해 준다면, 프로그래머의 부담도 덜고, 기획자로서도 효율적인 스케쥴 관리가 가능하게 된다.

▲ '기간 구분'이 되어있지 않았다면 프로그래머는 이렇게 말한다. "안돼요!"



3 : '기획서'를 소모품으로 쓰자


이어진 이상균 디렉터의 이야기는 조금 파격적인 내용을 담고 있었다. '기획서' 그 자체를 소모품으로 쓰라는 이야기. 쉽게 이해하기 힘든 내용이 아닐 수 없다. 보통 기획과 개발의 한 주기가 끝나고 나면, 기획서, 사양서, 회의록 등등 다양한 문서, 그리고 코드와 데이터로 이뤄진 빌드가 남게 된다. 여기서 의문이 시작된다. 과연 문서로 남은 자료들과 완성된 빌드의 내용은 일치할 것인가?

많은 현직 게임 개발팀이 개발 과정의 문서화에 시간을 쓰고 있다. 물론 이는 잘못된 것이 아니다. 개발 기간, 혹은 라이브 기간에 팀원이 바뀔 수도 있고 이전의 결정을 되살펴 보며 맥락을 짚어야 할 때도 있다. 혹은 단순히 회의 자리에 없었던 멤버들에게 내용을 공유해 주기 위한 용도로도 문서화는 좋은 방식이다.


하지만 이전의 질문으로 돌아가 보면, 문서와 빌드의 불일치는 피하기 어려운 것이 사실이다. 이는 또 다른 문제들을 파생하게 되는데, 프로그래머로서는 어떤 문서가 최신인지 혼동할 가능성이 크고, 또 누군가는 문서들을 하나로 모아 통제해야 한다. 때로는 문서 업데이트 때문에 업무의 공백이 생기는 경우도 발생한다.

대형 MMORPG나 온라인 게임을 꾸리는 입장에서는 이런 단점들에도 문서화가 필요하긴 하다. 하지만 아니라면? 최근 국내 게임업계의 추세는 30인 이하의 소규모 개발팀들이 점점 더 많이는 실정이다. 변하는 시장 정세에 기민하게 대응해야 하고, 빠른 의사 결정이 필요한 소규모 팀들에게 이런 문서화 및 문서 업데이트 과정은 큰 필요가 없는 과정, 즉 '잉여 업무'가 되어 버릴 수 있다는 뜻이다.

이를 해결하는 방법으론 문서를 세 그룹으로 나누는 방법이 있다. 이미 개발된 '완성된 사양', 현재 눈앞에 닥친 '눈앞의 사양', 그리고 아직 초안 단계에 머무는 '미래의 비전'이 그 세 가지 그룹이다.

▲ 이상균 디렉터는 실제로 이 방법을 시행한 모습을 보여주기도 했다.



4 : 기획서의 '형식'을 없애자


이 역시 의아한 내용이 아닐 수 없었다. 아니 어쩌면, 근간을 흔든다고 해야 할까? 이상균 디렉터는 이 이야기를 시작하면서, 가장 처음 말했던 '상품의 제조 공정'을 다시 언급했다.

우리가 쓰는 기획서들은 보통 양식이 있어요. 근데 그 기획서 양식들이 말이죠. 대부분 자연스럽게 생겨난 것이 아니에요. 보통 다른 업계, 아까 말한 '상품 제조 공정'에 쓰이던 것들을 베껴온 것들이 많죠.

하지만 앞서 말했듯이, 게임 기획의 과정은 상품의 기획 과정과는 전혀 달라요. 결국, 애초부터 맞는 옷이 아니었던 겁니다. 게임 기획은 '발상', '설계', 그리고 '전달'의 세 단계로 이뤄져요. 그 중 '기획서'가 차지하는 부분은 '전달'이죠. 프로그래머가 쉽게 이해할 수 있다면, 그리고 그 의도를 명확히 전달할 수만 있다면 사실 '양식'은 크게 중요한 것이 아니에요.


▲ 프로그래머 개개인의 취향은 모두 다르다. 결국 중요한건 '전달'의 효율

'본질'에 대한 이야기다. '기획서'의 역할이자, 존재 의의인 '의미의 전달'만 제대로 이뤄진다면, 그 방식은 크게 중요한 것이 아니라는 뜻이다. 이는 또 다른 효과도 함께 낼 수 있다. 프로그래머들은 각각 다른 취향을 가진 '개개인'이며, 선호하는 기획서의 형식 역시 다르다. 어떤 프로그래머는 천천히 읽을 수 있는 문서를 좋아하는가 하면, 또 어떤 프로그래머는 직관적인 체크리스트를 선호한다.

결국 '효율'이라는 최고의 명제 아래서 보았을 때, 틀이 잡힌 양식에 따라 기획서를 작성하는 일은 큰 효과를 보기 어렵다는 뜻이다.

▲ 앞서 말한 '소모품'으로서의 기획서 또한 같은 맥락으로 이어진다.



5 : '안돼요'에 대하여


'안돼요.'

프로그래머를 제외한 다른 직군들이 가장 힘들어하며, 동시에 두려워하는 말이다. 이상균 디렉터는 이 '안돼요'를 프로그래머의 '궁극기'라고 재치있게 표현하며, 이 '안돼요'에 대해 심도 있게 생각할 필요가 있다고 말했다.

▲ 안돼요!

프로그래머가 아닌, 다른 직군이 볼 때 '프로그래머'라는 그룹은 그야말로 놀라움 덩어리다. 코드를 짜는 것으로 기획을 실체로 만들어내며, 보통 사람들은 전혀 이해할 수 없는 영역을 다루기 때문이다. 프로그래머의 발언에 따라 게임의 개발 과정이 바뀌는 일도 있는 판국에, 프로그래머의 마지막 대답인 '안돼요.'는 더 이상의 협상 여지가 없다는 것을 뜻한다. 기획 의도가 좌절되었다는 뜻이다.

하지만 이 '안돼요'를 단순히 넘겨서는 안 된다. 왜 안된다고 하는지, 그리고 어떻게 하면 될 수 있게 만들 것인지를 고민해야 더 나은 개발 환경을 만들 수 있기 때문이다. 가끔은 정말 안되는 때도 있다. 마치 마지막과 끝이 이어지는 무한의 계단처럼, 물리적으로 이뤄질 수 없는 일. 그것들은 어쩔 수 없다.

하지만 대부분은 프로그래머가 말하는 '안돼요'는 '시간이 모자란다'라는 뜻을 내포한다. '현재 하는 업무가 있는 와중에, 이 일을 처리하기 위해서는 너무 많은 시간이 필요하다.' 라는 뜻이다. 물론 이렇게 된다면 한 번쯤 좌절하겠지만, 생각을 달리해볼 필요가 있다.

▲ 보통 시간이 모자랄 때 '안돼요'는 가장 많이 나온다.

이미 정해진 업무가 있는 상황에 갑자기 일이 생길 경우가 무엇이 있을까? 보통 이런 경우는 두 가지 경우다. 디렉터가 변덕을 부렸거나, 혹은 예측하지 못한 예외의 상황이 벌어진 경우다. 이 경우 '이런 일이 일어나는 것은 이번이 예외이다.'라는 것을 프로그래머에게 알리는 것이 중요하다. 프로그래머들이 항상 하드 코딩을 피하는 것은 아니다. 그가 '안돼요'를 말하는 이유는, 앞으로 계속 이와 같은 일이 벌어질 것이라는 우려 때문인 경우가 많기 때문이다.

혹은 이런 일도 있다. 게임의 너무 많은 부분을 고쳐나가야 할 경우. 이때도 프로그래머는 '안돼요'라고 말하지만, 실상은 '싫어요'에 가깝다. 대부분의 창작자가 그렇듯, 프로그래머들도 본인이 짠 코드에 애착을 갖게 된다. 이른바 '코드 오너십'이라고 부르는 현상이다. 하지만 앞서 말했듯 게임은 반복적인 통합의 과정을 거쳐 개발되는 '공학적 예술품'이다. 이미 완성된 사양 역시 수정될 수 있다는 사실을 고려해야 하는 것이다.

▲ 공들여 짰으니 갈아엎기 싫을 수밖에 없다.

가장 나쁜 '안돼요'의 경우는 프로그래머가 스스로 생각할 때 '할 수 있는지 없는지 잘 모르는 경우'에 나오는 경우다. 보통 이런 경우 오랜 경력을 갖춘 베테랑보다는 경력을 쌓아가는 과정에 있는 개발자들에게서 주로 볼 수 있다. 이런 일이 일어나는 경우는 '모른다'라고 말하는 그 자체를 프로그래머들이 싫어하기 때문이다.

프로그래머들에게 들을 때 가장 두려운 말이 '안돼요'라면, 반대로 프로그래머들이 가장 싫어하는 말은 '다른 분이 된다는데요?'이다. 이런 대화가 나올 경우, 이미 그 팀은 갈등이 시작된 것이나 마찬가지다. 기획자가 그 사안을 다른 프로그래머에게 물었다는 자체가 프로그래머의 능력을 불신한다는 방증이며, 이는 팀 사이의 신뢰가 이미 무너진 상황임을 나타낸다.

이 경우, 기획자가 할 수 있는 일은 아무것도 없다. 프로그래머만이 해결할 수 있을 뿐.

▲ 이미 신뢰가 깨진 상황.



終 : '소통', 그리고 '팀 간의 호흡'


강연을 마치며 살펴본 프레젠테이션, 인상 깊은 문장이 눈에 들어왔다. "이 발표도 영원한 진리를 담고 있지는 않습니다." 11년. 이상균 디렉터가 게임업계에서 종사하면서 지나간 세월이다. 숙련을 넘어 완숙으로 접어드는 그조차도, 앞으로의 개발 환경이 어떻게 될지 모른다는 뜻일 거다.

'프로그래머들에게 사랑받는 기획서'. 말처럼 쉬운 일은 아닐 거다. 프로그래머 개개인이 다 다른데 어떻게 그 모두에게 사랑받는 기획서를 만들어낼 수 있을까. 아니 그보다 앞서, 아무리 대인군자라도 자신에게 들고 오는 일거리를 마냥 사랑하진 않을 것이다. 비록 그것이 너무나 깔끔하고 읽기 좋아져 있다고 해도 말이다.

대국적 시선에서, 이상균 디렉터는 '소통', 그리고 '팀 간의 호흡'의 중요성을 설파하고 있었다. '기획서'라는 수단 자체는 앞서 말했듯, '전달'의 한가지 형태에 불과하다. 가장 많이 쓰이고 보편적인 방식이기 때문에 소재가 되었을 뿐, 결국 강연의 주제는 기획 의도를 명확하게 프로그래머에게 전달하고, 전체적인 업무의 효율을 증강하는 방법론을 이야기하고 있었다.

'기획자'와 '프로그래머'. 때로는 다투고, 또 때로는 갈등을 빚지만, 미우나 고우나 한배를 타고 같은 목적을 향해 나아가는 '개발'이라는 배를 탄 선원들이다. 더 나은 개발 환경, 더 높은 업무 효율. 그리고 그보다 더 높고 가치 있는 목표. 바로 '더 멋진 게임'을 만들기 위해 밟아나가야 할 스텝. 강연을 듣고 나오는 길에, 어쩌면 그 시작이 생각보다 어렵지 않을지도 모른다는 생각이 들었다.