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