(NDC2014) 프로그래머와 기획자가 서로를 이해하는 법

프로그래머와 기획자가 서로를 이해하는 법

1. 가상사례 : 어떤 MMORPG의 이벤트

- 기획자 : 1주일 뒤에 만우절 기념 특별 장비 지급 이벤트를 하기로 했다

              장비는 제작이 완료되었는데, 그냥 지급하려니 허전하다.

              그래서 몬스터가 떨어뜨리는 퀘스트 시작 아이템을 획득해서 이벤트 퀘스트를 시작하게 하자

              이 게임에서 보통 유저들이 퀘스트 아이템을 획득해도 잘 확인하지 않는 경향이 있다.

              그래서 퀘스트 시작 아이템은 획득 순간 퀘스트 수락 창이 자동으로 뜨게 하자

> 프로그래머 : 1주일 뒤는 좀 힘들다.

** 이런 대화는 어떨까?

>기획자 : 혹시 하드코딩해서 자 아이템에 대해서만 특별 처리한다면 일주일 내에 가능할까요?  당분간 저런 아이템은 안 나올 것이다.

> 프로그래머 : 흠 그럼 가능할 거 같습니다. 근데 코드가 지저분....

> 기획자 : 강제로 창이 열리는 기능은 이번 이벤트만 사용하니 5월 지나서 제가 코드 제거할 수 있는 시간을 드리겠다

> 프로그래머 : 그렇게 합시다.

- 기획자가 프로그래머를 이해하면, 프로그래머가 기획자를 이해하면 쉽게 해결되는 문제가 많다.

2. 시간(하드코딩 vs 시스템)

- 프로그래머의 핵심 키워드는 시간이다.

- 프로그래머의 3대 미덕 : 빠른 구현, 버그가 없음, 좋은 성능

  > 그러나 3가지 모두 갖추는 것은 불가능하다.

  > 시간이 있으면 버그 없는 좋은 성능, 완벽한 프로그램은 짤 수 있다.

     (그러나 두 가지를 잡으면 다른 하나가 튀어나온다.)

  > 프로그래머가 '안돼'라고 하는 이유는 진짜로 기술적이 불가능한 것이 아니라면 "시간이 모자르다"라는 것이다.

-  여기에 비밀이 하나 있다 : 프로그래머는 무의식적으로 "시스템"을 구축하고 싶어하는 경향이 있다.

  > 시스템화된 코드를 선호하는 것은 프로그래머의 본능이다. 그러나 시스템을 먼저 구축하는 것이 위험할 수 있다는 것을 알아야 한다.

  > 좋은 시스템을 구축하기 위해서는 "정보"가 필요하다.

  > 특히 "앞으로 어떤 방향으로 이 기획이 발전할 것인지"를 알아내는 것이 중요하다.

  > 프로그래머가 가장 두려워 하는 것은 기획 변경이다. 

  > 기획 변경이란 것은 새로운 기획과 기존 시스템이 충돌한다는 것

  > 따라서 기획 변경을 막기 위해서는 시스템의 크기를 가능한 줄이는 것이 유리하다.

     그렇지 않으면 기획 변경이 되었을 때 엄청난 수정사항이 발생한다.

- 아이템 추가의 가상 사례

  > 기존의 캐릭터별/전체 착용 장비가 정해진 시스템에서 일부 캐릭터만 착용 가능한 장비가 나왔다.

  > 데이터 베이스를 수정할 것인가, 이 아이템만 하드코딩을 할 것인가?

  > 프로그래머는 하드코딩을 배제하는 습관이 있고, 이것은 나쁜 것이 아니지만 빠른 시일내에 재활용되는 코드가 아니라면 "가장 빠르게 구현하는 것"에 중점을 두는 것이 좋다.

  > 프로그래머들은 대부분 큰 시스템+작은 구현을 작은 시스템+큰 구현보다 선호하는 경향이 있다. 

      : 하지만 실무에서는 작은 시스템 쪽이 우월하다 생각, 빠르게 구현한 코드는 기획이 변경되었을 때 버리고 새로 구현하기도 간단하다.

- 프로그래머가 안돼라고 하는 것은 시간때문 > 시간을 더 주기 어려우니 스펙을 축소 > 시스템 규모를 줄이도록 유도하는게 나쁘지 않은 방법이다.

- 프로그래머에가 하드코딩은 미래를 팔아 현재를 사는 것이다. 대단히 거부감이 있다. 그 거부감을 줄이는 것은 

   '이번만', '나중에'이다.(이번만 쓰일 것이다, 나중에 정리할 시간을 주겠다.)

    예 : 이번 몬스터만 죽어서 분열하고 당분간은 없으니 이번만 하드코딩을 하고, 다음에 또 이런 형식의 몬스터가 나오면 그 때 코드를 정리할 시간을 드리겠다.

-. 좋은 하드코딩의 3요소  

ㆍ 빠르게, 읽기 쉽게(한 곳에 몰아놓기), 제거하기 쉽게(언젠가는 제거해야 함) 하는 것

ㆍ 그리고 주석을 잘 적어놓으면 도움이 될 것이다.

4. 기획의 사각지대

- 기획서에 모든 내용을 적을 수 있다면 좋겠지만, 불행히도 그렇지 못한 경우가 더 많다. 특히 기술적인 세부 내용이 들어가면 더 그렇다.

- 예 : 강화 도중 네트워크 문제 발생! > 대기창을 띄우고 재시도? 오류 메시지 띄우나? 네트워크 오류가 난 경우와 잘못된 요청인 경우를 구분해서 보여주나?

> 이런 것은 기획자가 미리 생각해서 넣기 어려운 문제, 그러나 원칙적으로는 기획자가 결정하고 책임을 져야 하는 내용이다.

> 그러나 소소한 것까지 다 물어보는 것은 기획자도, 프로그래머도 귀찮은 일이다.

- 기획자는 여기서 프로그래머가 마음대로 애매한 내용들을 결정하지 못 하게 할 필요가 있다. 어차피 프로그래머가 얘기를 안 한다면 답이 없기 때문에, 프로그래머가 판단을 

   제대로 하도록 도와준다고 생각하는 것이 낫다.

- 방향을 공유하는 가장 쉬운 방법은 레퍼런스를 두는 것이다.

  예 : 가방 시스템에는 이러이러이러한 것이 있는데, 그 외의 것은 이런 게임의 인벤토리 시스템을 참고하면 좋다.

- 프로그래머가 기획적 센스를 기르는 것이 좋다. 게임을 다양하게 하는 것은 기본이고, 기획자가 하는 게임을 하는 것이다. 그럼 이야기가 잘 통한다.

5. 결론

- 사람 사이의 커뮤니케이션은 원래 어렵다.

- 프로그래머는 원래부터 커뮤니케이션이 서툴다.

- 둘이 서로 완벽하게 이해하길 바라는 것은 무리일지도 모른다.

- 하지만 같은 목표를 가지고 있다. 그러니 노력한다면 이해할 수 있다.