Posted by 이후 After
간만에 칼럼으로 돌아온 이후입니다. 이하는 편의상 경어를 사용하지 않았으니 양해해주세요.




전통적으로 게임업계에 내려오는 미신중에 하나는 기획자와 프로그래머는 사이가 좋지 않다. 는 것이다.

물론 실제로 보면 기획자와 개발자 사이가 좋은 팀도 있고, 사이가 나쁜 팀도 있을 수 있다. 같은 직군 안에서도 다 제각기 다르리라 생각된다.

종종 기획자들의 입에서는 프로그래머에 대한 험담이 들려오고는 하는데, 그 이유는 주로 프로그래머들이 일을 안한다 라는 것이다.

정확하게 콕 집자면,

'내 기획을 귀찮다고 안해줘요.'

물론 프로그래머가 대놓고 귀찮다고 말했을리는 없고.. (있을수도 있지만.)

아마 프로그래머는 이렇게 말했을 것이다.

'이거 시스템 때문에 안돼요.'

뭐 시간이 많이 걸려요. 어려워요. 완전히 다시 짜야해요. 등등의 다른 이유로 대체될수도 있지만, 기획자인 당신은 프로그래머가 프로그램에 관한 이야기를 하면 그다지 할말이 없다. 안된다는데 어쩔것인가.

남은 방법은 두가지인데, 직급으로 찍어누르던가, 프로그래밍을 배우는 거다. (후자 추천. 프로그래밍을 배워라! 우와! )

커뮤니케이션에서 중요한건 행간을 읽는거라고 생각하는데 프로그래머의 안돼요. 라는 말에는 사실 굉장히 중요한 부분이 숨겨져있다.

((나는) 당신 기획은(혹은 당신(기획자본인)이) 맘에 안들어서 내가 굳이 그런 수고로움을 감수하면서 일할 가치를 못느끼겠군요. 그러니까 )안돼요.

이미 잘돌아가고 있는 것을 수정하는 기획일수록 이런 대답이 나오는데 만약에 문제가 있는 거라면 (흔한 케이스로 버그) 어지간한 프로그래머라면 야근을 하던 뭘 하던 고쳐놓는다.

물론 이런식으로 대화하는 프로그래머가 잘한다는건 아니고.. 컴퓨터랑 대화하는 족속들이니 결과값만 제대로 나오면 됐지 뭘..

어쨌든 저 대답에서는 '기획(혹은 기확자)이 맘에 들지 않는다.' 와 '수고로움을 감수하고 싶지 않다.' 라는 두가지 이유가 있다.

우선 수고로움에 대해서 일단 생각해두어야 하는데,

기획자가 생각하는 기능을 추가하는 시간과 프로그래머가 직접 개발해야하는 시간이 항상 같지는않다. 아니 대부분 굉장히 다르다.

이거 하나 추가하는데 시간이 얼마나 걸리겠어. 라고 생각하는게 실제로는 한달, 두달. 혹은 프로그램을 전부 뜯어 고쳐야하는 사태가 벌어질수도 있다. 그리고 종종 벌어지기도 하고.. 주니어 개발자는 욕심에 그걸 다 뜯어고치다가 사고가 터질 때도 있다.. 그 가끔 보이는 10시간이 넘어가는 패치 같은거 말야..

게다가 해당 기능 추가에 대해서 개발자마다 걸리는 시간도 같지가 않고 프로그램 개발의 초기에 참여했던 사람이라면 이미 있는 구조들을 이용해서 쉽게 처리할수 있을지도 모르지만 중간에 들어온 개발자라면 해당 기능이 돌아가는 코드파악부터 시작해야하니 얼마나 걸릴지 알수 없을 수 밖에..

게다가 기능이 추가되면서 기존 구조가 바뀌게 된다면 테스트는 처음부터 끝까지 다시 다 해야할수도 있다. 고레벨존의 몬스터가 날아다녔으면 좋겠어요. 라고 해서 날아다니게 하고 고레벨존만 테스트하고 룰루랄라 게임에 넣었더니 초보자 존에 있는 상자들이 모두 날아다니는 사태가 벌어질수도 있다.

요약하자면 이미 잘 돌아가고 있는걸 바꾼다는건 굉장히 리스크가 큰 작업이란 것이다.

게다가 그런식으로 버그가 나오고 패치가 연장되면 보통 다 프로그래머가 책임을 지게된다. '야근' , '초과근무' 등으로 말이다.

그럼 프로그래머는 신기술에 대한 공부도, 가족과 함께 지낼 시간도, 친구들과 놀 시간도 모두 뺏긴채 일을 수습하기 위해 야근을 해야한다. 게다가 저런분위기면 꼭 새벽에 들어가서 조금 자다가 늦으면 지각했다고 윗선부터 갈구지.

이런 리스크가 있음에도 불구하고!

프로그래머가 자신의 게임에 대한 애정이 있고, 당신의 기획이 정말 재밌어 보여서 이 기획을 구현하면 막 우리 게임 동접도 뛰고 (실제로는 어떨지 모르지만) 보너스도 나올것 같다 싶으면 리스크를 지고 개발을 한다.

그래서 우리는 일단 프로그래머가 안돼요라고 말하지 않을수 있는 첫번째 방법을 찾아냈다.

1. 우선 프로그래머가 납득할만한 기획을 한다.

이걸 위해서는 평소에 프로그래머와 이야기를 자주 하면서 게임의 비전에 대해서 공유하고 애정도 식지않게 잘 관리해주고, 기획에 대해서도 기획서만 던져주는게 아니라 직접 이야기하면서 상세하게 설명을 할 필요가 있다.

그런데 이건 기꺼이 프로그래머가 게임을 위해 자신을 희생할수 있다는 가정이 깔려있어야 성립되는 방법이고, 팀의 모든 구성원이 게임에 대해 비전과 애정을 가지고 있으면 좋겠지만, 현실적으로는 그렇지 못할수도 있다. (특히 라이브팀) 사실 모든 구성원이 비전과 애정을 완벽하게 공유하면 저런 말이 안나오지..

그리고 설사 그런 팀이라고 하더라도 개발자를 희생시키면서 게임을 만드는건 좋지 못하다. 그래서 우선 질문을 바꿀 필요가 있다.

2. (X) 이러이러한 기능을 추가해주세요.
   (O) 이러이러한 기능을 넣는데 얼마나 걸릴까요. 그리고 테스트는 얼마나 해야할까요.

그럼 프로그래머는 적어도 대략 얼마나 걸릴지에 대해서 설명을 해줄 것이다. (그리고 고려할 때는 그 기간보다 더 걸린다고 생각하는게 좋다.) 많은 프로그래머는 해당 기능 작성 뿐만 아니라 다른 업무도 하게 된다. 유지보수부터 시작해서 다른 기획자의 요청이나 검토등

기획자는 이제 해당 기능을 넣는데 걸리는 개발기간을 듣고, 프로그래머 자원을 그 기간만큼 사용할만큼 우선순위와 가치가 있는 기획인지 판단을 할수 있게 되었다.

하지만 보통 요청은 이렇게 된다.

3. D: 다음 패치까지 이 기능이 필요해요.
    P : 안돼요.

기간에 대해서 물어볼수가 없다. 프로그래머가 당신을 위해서 리스크를 질 생각이 없다면 당연히 거절을 하는데. 사실 저렇게 안돼요. 라고 답하는 프로그래머가 잘하는건 아니지만 리스크를 져야하는 입장이라는 것을 조금 감안해주도록 하자.

이 상황에서도 당신이 개발기간에 대해서 묻는다면, 프로그래머가 어떻게 대답하던 개발기간과 필요인력에 대해서 확인한다면 다른 대안을 찾을수도 있다. 혹은 이번 패치가 아니라 다음 패치까지 개발한다던가 하는 식으로 진행을 할 수도 있고.

꼭 필요하다면 리스크(=야근)를 기획자가 함께 질수도 있다. 만약에 마음 좋은 프로그래머가 기획자가 이렇게 일 던져주고 혼자만 도망간다면 아마 다음부터는 그런 리스크를 져주고 싶지 안을 것이다. 테스트를 함께 한다던가 하는 방식으로 기여를 할 수도 있고.

하지만 이렇게 하는 것보다 더 좋은 방법이 있다.

자신의 기획에 목표를 확실하게 정하고, 목표를 위해 그 기능이 필요하다는 것을 전달하다면 프로그래머가 그 목표를 위한 더 좋은 솔루션이나, 적절한 솔루션. 혹은 다른 기능들과 충돌하는지에 대해서 알려줄수도 있다.

4. D: 이러이러한 문제가 있어서 해결하기 위해서 이러이러한 기획을 했다. 다음 패치때까지 넣고 싶은데 개발기간이 얼마나 걸릴까요.
  P: 그런 기능을 추가하면 도저히 다음 패치까지는 각이 안나오는데요. 그런 문제 해결 방법이라면 저번에 구현해놓은 이런 기능을 사용해서 해결할수 있지 않을까요.
  D: 그럼 그런 기능을 이러이러하게 사용할수 있을까요.
  P: 그건 저 기능보다 훨씬 적게 작업해서 해결할 수 있습니다.

이걸로 해피엔딩.

물론 이건 가장 이상적인 케이스에 가깝고 실제로는 그냥 답이 안나와서 더 자원을 투입해야하 할 수도 있고, 작업을 못할 수도 있겠지만, 기획자가 프로그래머에게 뭘 원하는지에 대해 정확하게 설명한다면 프로그래머가 현실적인 대안을 제시해줄수 있다는 점을 항상 생각하자.

그걸 하려면 기획을 위한 기획을 하면 안되는데다가, 자신의 기획에 대해서 항상 왜 필요한지에 대해 설명할수 있도록 고민을 많이 해야할 것이다.

또한 해당 목표위한 기능추가에 프로그래머가 매달린다면 그동안 다른일을 못한다는 기회비용도 항상 고려하는게 좋다. 엉뚱한 기능에 개발력을 소모함으로써 정작 필요한 기능을 추가 못하는 경우도 많다. (욕만 먹지..)

물론 저렇게 대화를 하기 위해서는 평소에 프로그래머와 관계를 좋게 유지할 필요도 있겠고.



이 글을 읽는 프로그래머에게도 몇가지 이야기하고 싶은데, 모든 기획자가 합리적으로 이야기해줄수 있다면 좋겠지만 그렇지 않더라도

무조건 안돼요 라고 대답하지 말고 왜 안되는지에 대해서 설명하고 가급적 기획자가 뭘 원하는지에 대해 물어봐라.

월급받는 만큼은 일해야지.

물론 이렇게 물어본다고 하더라도 여러분이 한번쯤 봤을거라 생각하는 프로젝트 카툰(링크) 을 보면 알수 있듯이 제대로 된 물건이 나오리란 보장은 없다.

그 외 테스트에 대한 리스크를 줄이기 위한 TDD 같은 것을 개발에 적용시켜보는 것도 방법일수 있겠고, 처음부터 기능 추가를 어느정도 고려하면서 작업하는 것도 방법일수 있겠다.
저작자 표시

댓글을 달아 주세요

  1. ghostsbs 2011/07/20 15:43 댓글주소 수정/삭제 댓글쓰기

    공감가는 글입니다. 재밌게 읽고 갑니다.

  2. karazhan 2011/07/20 16:23 댓글주소 수정/삭제 댓글쓰기

    너무 공감가고 적절한 답안이네요. 게임뿐 아니라 SI 업에도 적용되는 진리인듯합니다. (프로그래머의 시각에서 말이죠)

  3. lezard 2011/07/20 17:38 댓글주소 수정/삭제 댓글쓰기

    격하게 공감이 가는 글이네요.

  4. BlueGon 2011/07/20 18:00 댓글주소 수정/삭제 댓글쓰기

    너무나도 와 닿는 글이네요. 잘 읽고 갑니다. (__)

  5. chcjswo 2011/07/20 18:02 댓글주소 수정/삭제 댓글쓰기

    공감이 가는 부분도 있고 한편으론 공감이 안가는 부분도 있네요.
    바보 기획자도 겪어봤고, 바보 개발자도 겪어본지라..

    결론은... 이루고자 하는 최종 목표를 위해 '헌신'하려는 '똑똑한' 사람들이 모여서 일하면 큰 문제가 없습니다. 매우 이상적인 말 같지만 가끔은 그런 dream team이 있더라구요.

  6. 타이가장관 2011/07/21 12:07 댓글주소 수정/삭제 댓글쓰기

    아...일단 밀린 급여부터 받고 나서 얘기합시다...--;

  7. 기획인 2011/07/21 17:54 댓글주소 수정/삭제 댓글쓰기

    딱!! 지금의 제 얘기를 하신 것 같아 움찔했네요..ㅡㅡ;

    기획자의 의도가 어떤건지를 제대로 이해시키는게 가장 중요한 것 같습니다.

  8. 날자고도 2011/07/22 15:28 댓글주소 수정/삭제 댓글쓰기

    "
    D: 이러이러한 문제가 있어서 해결하기 위해서 이러이러한 기획을 했다. 다음 패치때까지
    넣고 싶은데 개발기간이 얼마나 걸릴까요.
    "

    이런 질문은 제가 좀 싫어하는 말중에 하나입니다.
    기획이(추가할 기능이) 완벽하다고 생각하는것이죠.
    어떤 문제가 있으면, 해결할방법을 프로그래머와 같이 의논할필요가 있습니다.
    만약에 기획이 잘못되었으면, 프로그래머가 다시해야 하기때문이죠.

    또한, 업무지시형태이기 때문입니다.



    전, 이렇게 물을때가 좋아요
    "
    D: 이러이러한 문제가 있어서 해결하기 위해서 이러이러한 기획을 했다.
    한번 봐주실래요?
    "

    • nice102 2011/07/30 07:17 댓글주소 수정/삭제

      기획이 문제였는 지, 프로그램이 문제였는 지에 따라 다르게 생각해봐야 할 것 같습니다. 물론 프로그램 문제였다면 프로그래머하고 해결방안을 상의를 해야하는 것이 맞겠지요. 하지만 기획 문제였다면 상의를 바라는 건 안된다고 생각합니다. 기획자/팀은 폼으로 있는 게 아니니깐요.또 업무지시라고 느끼는 것도 안된다고 생각합니다.

  9. blueasa 2011/07/23 10:16 댓글주소 수정/삭제 댓글쓰기

    좋은글 잘 읽고 갑니다. :)

  10. 잭스패로우 2011/07/25 10:53 댓글주소 수정/삭제 댓글쓰기

    "무조건 안돼요 라고 대답하지 말고 왜 안되는지에 대해서 설명하고 가급적 기획자가 뭘 원하는지에 대해 물어봐라.


    월급받는 만큼은 일해야지."

    프로그래머는 월급을 놀면서 받는다는 투로 들리는 군요. 어이없음.

    • 음메 2011/07/29 11:07 댓글주소 수정/삭제

      가끔은 그런 사람도 있는 거 아니겠습니까.

      민감하게 받아들이지 않으셔도 될 듯..

    • nice102 2011/07/30 06:47 댓글주소 수정/삭제

      전 실제로 그런 보기 안좋은 사례를 꽤 봐서요. 어이가 없지 않네요. ㅡ ㅡ 정말 프로그래머가 경계해야할 부분인 것 같습니다.

  11. 용가리 2011/07/26 06:55 댓글주소 수정/삭제 댓글쓰기

    최악의 케이스 :
    "그건 그다지 메리트가 안 느껴짐. 패스."

    그리고 그 기능은 다음달 누군가 어플로 만들어서 올려서 신문에 떳음.

  12. nice102 2011/07/30 06:48 댓글주소 수정/삭제 댓글쓰기

    완전 개념글이네요. 잘 읽고 갑니다. ^^

  13. 라이브 2011/08/01 08:47 댓글주소 수정/삭제 댓글쓰기

    충분히 공감가는 내용이지만,
    라이브팀에서 매출때문에..
    생각할시간도 없이 컨텐츠를 막찍어내고 있네요ㅠ
    이번달매출..빵꾸나서, 담주까이 이거 들어가야해요..?
    넵... ?!네에....

  14. 공감이 2011/10/06 00:33 댓글주소 수정/삭제 댓글쓰기

    안갑니다...... 발생되는 문제 자체도 너무 이상적인 경우만 이야기 하신듯한 느낌?
    개발하다가 기획자에게 '안돼요' 라고 하는 경우 제 경우 가장 많은 부분은
    기획자가 개발한 비지니스 로직을 기획자 스스로 부정하는 후속기획을 들고오는 경우인데... 간단한 예로는 뭐 '우리게임은 경험치 까이는 시스템은 없습니다. + 내 경험치에 따라 자동으로 성장하는 펫. 이라는 기본 룰을 개발하고 '이번에 경험치 까이는 몹 만들꺼에요~' 뭐 이런식? 이런게 반복되다 보면 무한 예외처리 코드가 삽입되고 그러다 보면 지저분해지고 그러다 보면 자꾸 에러나고 그러다 보면 자꾸 개발자만 욕먹는 경우가 생기기 때문인데.....

  15. 공감 2012/04/11 01:01 댓글주소 수정/삭제 댓글쓰기

    윗분 글 공감이요.....