전통적으로 게임업계에 내려오는 미신중에 하나는 “기획자와 프로그래머는 사이가 좋지 않다”는 것이다. 물론 실제로 보면 기획자와 개발자 사이가 좋은 팀도 있고, 사이가 나쁜 팀도 있을 수 있다. 같은 직군 안에서도 다 제각기 다르리라 생각된다.
종종 기획자들의 입에서는 프로그래머에 대한 험담이 들려오고는 하는데, 그 이유는 주로 “내 기획을 귀찮다고 안 해줘요”다. 물론 프로그래머가 대놓고 귀찮다고 말했을 리는 없다. 아마 프로그래머는 “이거 시스템 때문에 안 돼요”라고 말했을 것이다.
“안 돼요”라는 말의 속마음
뭐, 시간이 많이 걸려요… 어려워요… 완전히 다시 짜야 해요… 등등의 다른 이유로 대체될수도 있지만, 기획자인 당신은 프로그래머가 프로그램에 관한 이야기를 하면 그다지 할 말이 없다. 안 된다는데 어쩔 것인가?
남은 방법은 두 가지인데, 직급으로 찍어 누르든가, 프로그래밍을 배우는 거다. (후자 추천. 프로그래밍을 배워라! 우와! )
커뮤니케이션에서 중요한건 행간을 읽는거라고 생각하는데 프로그래머의 “안 돼요”라는 말에는 사실 굉장히 중요한 부분이 숨겨져 있다.
당신의 기획은(혹은 당신이) 맘에 안들어서, 내가 굳이 그런 수고로움을 감수하면서 일할 가치를 못느끼겠군요… 그러니까 안 돼요.
이미 잘돌아가고 있는 것을 수정하는 기획일수록 이런 대답이 나온다. 만약 정말 인정할 수밖에 없는 문제가 있다면 (흔한 케이스로 버그) 야근을 하든 뭘 하든 고친다. 어쨌든 저 대답에서는 ‘기획(혹은 기확자)이 맘에 들지 않는다.’ 와 ‘수고로움을 감수하고 싶지 않다.’ 라는 두가지 이유가 있다.
실제 작업은 기획자의 생각보다 매우 복잡하다
우선 수고로움을 일단 생각해 보자. 기획자가 생각하는 기능을 추가하는 시간과 프로그래머가 직접 개발해야하는 시간이 항상 같지는않다. 아니, 대부분 굉장히 다르다. ‘이거 하나 추가하는데 시간이 얼마나 걸리겠어?’라고 생각하는 게 실제로는 한 달, 두 달, 혹은 프로그램을 전부 뜯어 고쳐야 하는 사태가 벌어질 수도 있다(주니어 개발자는 욕심에 그걸 다 뜯어고치다가 사고가 터진다).
또 해당 기능 추가에 개발자마다 걸리는 시간도 같지 않다. 프로그램 개발의 초기에 참여했던 사람이라면 이미 있는 구조들을 이용해서 쉽게 처리할수 있을지도 모르지만, 중간에 들어온 개발자라면 해당 기능이 돌아가는 코드파악부터 시작해야 하니 얼마나 걸릴지 알기도 힘들다.
게다가 기능이 추가되면서 기존 구조가 바뀌게 된다면 테스트는 처음부터 끝까지 다시 다 해야할수도 있다. “고레벨존의 몬스터가 날아다녔으면 좋겠어요”라고 해서 수정 후 고레벨존만 테스트하고 룰루랄라 게임에 넣었더니, 초보자 존에 있는 상자들이 모두 날아다니는 사태가 벌어질 수도 있다.
요약하자면 이미 잘 돌아가고 있는걸 바꾼다는건 굉장히 리스크가 큰 작업이란 것이다. 게다가 그런식으로 버그가 나오고 패치가 연장되면 보통 다 프로그래머가 책임을 지게된다. ‘야근’ ‘초과근무’ 등으로 말이다. 그럼 프로그래머는 신기술에 대한 공부도, 가족과 함께 지낼 시간도, 친구들과 놀 시간도 모두 뺏긴 채 일을 수습하기 위해 야근을 해야 한다. 게다가 저런 분위기면 꼭 새벽에 들어가서 조금 자다가 늦으면 지각했다고 윗선부터 갈구지.
명령하지 않고 질문으로 프로젝트를 풀어가는 법
이런 리스크가 있음에도 불구하고! 프로그래머가 자신의 게임에 대한 애정이 있고, 당신의 기획이 정말 재밌어 보여서 이 기획을 구현하면 막 우리 게임 동접도 뛰고 (실제로는 어떨지 모르지만) 보너스도 나올것 같다 싶으면 리스크를 지고 개발을 한다.
그래서 우리는 일단 프로그래머가 “안 돼요”라고 말하지 않을 첫 번째 방법을 찾아냈다. 우선 프로그래머가 납득할만한 기획을 하는 데서 시작해야 한다. 이걸 위해서는 평소에 프로그래머와 이야기를 자주 하면서 게임의 비전을 공유하고 애정도 식지 않게 잘 관리해주고, 기획도 기획서만 던져주는 게 아니라 직접 이야기하면서 상세하게 설명을 할 필요가 있다.
그런데 이건 기꺼이 프로그래머가 게임을 위해 자신을 희생할수 있다는 가정이 깔려있어야 성립되는 방법이고, 팀의 모든 구성원이 게임에 비전과 애정을 가지고 있으면 좋겠지만, 현실적으로는 그렇지 못할 수도 있다. 사실 모든 구성원이 비전과 애정을 완벽하게 공유하면 저런 말이 안 나올 것이다. 그리고 설사 그런 팀이라고 하더라도 개발자를 희생시키면서 게임을 만드는건 좋지 못하다. 그래서 우선 질문을 바꿀 필요가 있다.
- 이러이러한 기능을 추가해주세요. (X)
- 이러이러한 기능을 넣는데 얼마나 걸릴까요. 그리고 테스트는 얼마나 해야 할까요. (O)
“안 돼요”라고 답하는 프로그래머가 잘 하는 건 아니지만, 리스크를 져야 하는 입장이라는 것을 조금 감안해주도록 하자. 이 상황에서도 당신이 개발기간을 묻는다면, 프로그래머가 어떻게 대답하든 개발기간과 필요인력을 확인한다면 다른 대안을 찾을 수도 있다. 혹은 이번 패치가 아니라 다음 패치까지 개발한다든가 하는 식으로 진행을 할 수도 있고.
그럼 프로그래머는 적어도 대략 얼마나 걸릴지 설명을 해줄 것이다(그리고 기획자는 프로그래머가 말한 그 기간보다 더 걸린다고 생각하는 게 좋다). 많은 프로그래머는 해당 기능 작성 뿐 아니라 다른 업무도 한다. 유지보수부터 시작해서 다른 기획자의 요청이나 검토 등.
기획자는 이제 해당 기능을 넣는데 걸리는 개발기간을 듣고, 프로그래머 자원을 그 기간만큼 사용할 만큼 우선순위와 가치가 있는 기획인지 판단을 할수 있게 되었다. 꼭 필요하다면 리스크(=야근)를 기획자가 함께 질 수도 있다. 만약에 기획자가 일 던져주고 혼자만 도망간다면, 아마 다음부터는 그런 리스크를 져주고 싶지 안을 것이다. 프로그래밍을 못 해도, 테스트를 함께 한다든가 하는 방식으로 기여를 할 수 있다.
기획자와 프로그래머, 이렇게 변해 보자
기획자는 자신의 기획에 목표를 확실하게 정하고, 목표를 위해 그 기능이 필요하다는 것을 전달한다. 앞서 이야기한 것처럼 이때 일방적으로 전달하지 않고 프로그래머에게 질문해서 목표를 위한 더 좋은 솔루션이나 적절한 솔루션, 혹은 다른 기능과 충돌하는지까지 프로그래머에게 답을 얻을 수 있다.
이러이러한 문제가 있어서 해결하기 위해서 이러이러한 기획을 했어요. 다음 패치 때까지 넣고 싶은데 개발기간이 얼마나 걸릴까요.
그런 기능을 추가하면 도저히 다음 패치까지는 각이 안 나오는데요. 그런 문제 해결 방법이라면 저번에 구현해놓은 이런 기능을 사용해서 해결할 수 있지 않을까요.
그럼 그런 기능을 이러이러하게 사용할 수 있을까요.
그건 저 기능보다 훨씬 적게 작업해서 해결할 수 있습니다.
이것만 잘 돼도 해피엔딩을 맞을 수 있다. 물론 이건 가장 이상적인 케이스에 가깝고 실제로는 그냥 답이 안 나와서 더 자원을 투입해야 할 수도 있고, 작업을 못 할 수도 있겠지만, 기획자가 프로그래머에게 뭘 원하는지 정확하게 설명한다면 프로그래머가 현실적인 대안을 제시해줄 수 있다는 점을 항상 생각하자. 그걸 하려면 기획을 위한 기획을 하면 안 되는 데다가, 자신의 기획이 왜 필요한지 항상 설명할 수 있도록 고민을 많이 해야 할 것이다.
또한 해당 목표를 위한 기능 추가에 프로그래머가 매달린다면 그동안 다른 일을 못 한다는 기회비용도 항상 고려하는 게 좋다. 사실 엉뚱한 기능에 개발력을 소모함으로써 정작 필요한 기능을 추가 못하는 경우도 많다(욕만 먹지…). 물론 저렇게 대화를 하기 위해서는 평소에 프로그래머와 관계를 좋게 유지해야 하는 건 기본이다.
프로그래머에게도 몇 가지 이야기하고 싶은데, 모든 기획자가 합리적으로 이야기해줄 수 있다면 좋겠지만 그렇지 않더라도 무조건 “안 돼요”라고 대답하지 말고 왜 안되는지 설명하고 가급적 기획자가 뭘 원하는지 물어보자. 물론 이렇게 물어보더라도 여러분이 한번쯤 봤을 거라 생각하는 프로젝트 카툰을 보면 알 수 있듯이 제대로 된 물건이 나오리란 보장은 없다.
그 외 테스트에 대한 리스크를 줄이기 위한 TDD 같은 것을 개발에 적용시켜보는 것도 방법일수 있겠고, 처음부터 기능 추가를 어느정도 고려하면서 작업하는 것도 방법일수 있겠다.
원문: gamemook
