(스크랩) 개발자가 기피하는 기획자들

개발자가 기피하는 기획자들

이러한 역경(…)을 극복하고 기획자의 의도를 알아채는 것이 개발자의 진정한 의사소통 능력이라 할 수 있겠습니다.

하지만 저는 이 글의 논지를 지지합니다.

그리고 이것은 어딘가에서 퍼 온 글입니다. 어법에 맞지 않거나 의미가 모호한 문장들을 교정했고, 원본 글과 구성이 조금 다를 수 있습니다.

개발자가 싫어하는 기획자들은 어느 팀에나 한두명 정도 있기 마련이다.

추상화의 대가
여기서 말하는 추상화는 프로그래밍의 추상화가 아닌 몬드리안이나 피카소가 할 법한 것들이다. 작성자 본인만 기획서를 해독할 수 있다. 어떤 기획자들의 기획서는 여러 의미로 해석 가능하고 모호한 표현으로 가득 차 있으며, 경우에 따라서는 작성자 이외의 타인은 해석 불가능한 경우도 있다. 개발자는 기획서가 암시하는 모든 가능성을 기획자에게 질문하게 되고, 그 질문을 바탕으로 기획자는 다시 기획서를 만든다. 이를 모호한 표현이 없을때까지 반복한다. 기획자가 구체적인 문서를 만들때까지 개발자는 기획서에 대해 기획자에게 질문하거나 기획자의 ‘게르니카’같은 문서를 읽고 세부사항을 나름대로 추측한 후에 결과물을 만들어낸다. 어떤 식으로 하던 결국 개발자가 기획의 영역까지 겸하게 되는 셈이다.

"다함께 차xx랑 비슷하게요"
개발자가 그 예로 든 게임을 모른다면 개발자는 기획자의 의도를 세세히 파악할 수는 없다. 이런 경우에도 세부사항을 나름대로 추측하게 되기 마련이고. 이것도 결국 개발자에게 기획을 떠넘기는 행동이다.
많은 게임 기획자들이 시중에 나온 게임들을 분석하며 역기획을 하고 토론하고 있다. 프로그래머가 그 역기획들을 추측해야 할 의무는 없다. 자신의 컨텐츠가 다른 게임의 시스템과 비슷하다면 기획자는 그 비슷한 특성들을 명확한 형태로 기획서에 서술할 의무가 있다.

논리교실
게임을 만들기 위해선 기획 단계에서부터 논리적 사고가 필요하다. 물론 기획자에게도 논리적 사고가 필요하다.
자신이 기획한 게임 룰의 모순을 개발자가 지적했을때 절대 그럴리 없다고 잡아떼는 것은 기획자의 가장 치명적인 실수이다. 인간이기 때문에 실수하고, 실수를 통해 배우기 때문에 인간이다.

프로그래머도 논리적 실수를 하기 마련이다. 개발자는 컴파일(편집자 주: 사람이 읽을 수 있는 텍스트로 된 명령들을 기계어로 바꾸는 작업)중 에러가 뜨지 않으면 당황한다. 그리고 프로그램 실행 중 에러가 나오는지 찾아본다. 반면에 어떤 기획자들은 자신이 기획한 룰을 검증하지 않는다. 이는 곧 기획자의 역량이 부족하다는 신호일 확률이 매우 높다. 그 기획자들은 자신이 기획이 완벽하다고 우긴다. 대다수의 프로그래머와 일부 기획자들, 둘의 차이는 극명하다. 전자는 언제나 실수를 염두에 두지만 후자는 무책임하다. 이런 무책임의 원인은 자신의 기획에 대한 근거없는 자신감(aka 근자감) 때문이고 이런 근자감은 논리가 부족하기 때문에 나온다.
결국 개발자는 기획의 오류를 기획자 본인이 이해할때까지 재능 논리교실을 열어야 한다.

인터럽트
그들의 기획서가 바뀌는 순간, 업무의 흐름이 끊긴다. 보통 이런 변경사항들의 내용은 밤에 자다가 꾼 꿈에서 얻은 아이디어, 인터넷 서핑하면서 얻은 아이디어,업무시간에 게임한판 하면서 얻은 아이디어 등 타당성이 검증되지 않은 것이 대부분이다. 이들은 이런 아이디어들을 자신의 머리 속에서 숙성시켜 똥인지 된장인지 구분하지 않는다. 단지 그것들을 개발자에게 던질 뿐.
그들은 프로젝트에 똥칠을 하고 있는 주범이다.
(편집자 주: 요구사항이 바뀌면 프로그래머들은 그 변화를 소스코드에 반영하기 위해 시간을 써야 한다. 변경사항이 생기기 전까지 작업한 것들을 버려야 할 수도 있다. 이 변화를 반영하는 작업도 엄연한 업무의 일부이다.
그리고 일반적으로 잦은 요구사항 변경은 소스코드의 구조를 복잡하게 만든다. 이 복잡도를 조절하는 것이 프로그래머의 역량이다.)

Programmer Wanna be
자신이 프로그래밍을 한다고 주장하는 기획자들이 있다. 옛날엔 게임프로그램의 소스코드를 어느정도 읽고 프로그램의 동작을 이해할 수 있는 기획자가 이 범주에 속했다. 최근에는 비개발자들이 게임안의 요소들을 직접 조작할 수 있는 유사프로그래밍 도구(aka 스크립팅)를 여러 게임 제작 환경(aka 게임엔진)들이 제공하고 있고, 이에 따라 이를 다룰 수 있는 기획자들의 수가 증가하고 있다. 일례로 언리얼 엔진의 kismet은 GUI 기반의 레벨 로직 툴로써 조금만 배우면 프로그래밍 없이 게임을 만들수 있다고 광고하고 있다.

이런 유사프로그래밍 도구는 프로그래밍의 이해하기 어려운 더럽고 복잡한 구석들을 생략하고 단순한 기능만을 할 수 있도록 설계되기 마련이고, 그 기능이 제한적일 수 밖에 없다. 어떤 기획자들은 이런 제한된 도구가 자신에게 전지전능한 힘을 줄 거라고 착각하며, 그것으로 어떻게든 결과물을 만들어내려 하다가, 포기하고 그 일을 프로그래머에게 넘기거나 알아보기 힘든 스파게티 코드를 던져주며 잘 돌아간다고 자랑한다. 프로그래머가 단 세줄로 표현할 수 있는 내용을 화면 가득히 만들어서 가져오는 신기를 볼 수 있다.

기획자들은 자신이 상상한 것을 최대한 많이 결과물로 만들어내기를 바라고, 프로그래머들은 자신이 이해할 수 있을때까지 프로그램을 간단하게 만들고 싶어한다. 이 때문에 프로그래머들은 게임 내 환경의 자유도를 제한하고, 어떤 기획자들은 ‘우리 게임엔진은 언리얼이나 유니티(편집자 주: 범용성과 자유도, 성능이 어느 정도 검증된 게임엔진이다. 둘 다 외국제품.)처럼 여러가지가 안된다’고 불평한다. 물론 그들이 언리얼이나 유니티를 쓴다고 해서 프로젝트에 득이 되는 것은 없다. 제대로 사용을 못하기 때문이다. 오히려 프로젝트를 복잡하게 만들 수도 있다. 반면에 어떤 다른 기획자들은 언리얼 스크립트를 자유자재로 다루고 게임엔진의 전체 구조를 파악하고 있기도 하다. 이들은 상상속의 동물이라고 여겨지고 있으나, 만약 그런 기획자가 존재한다면 그들은 이미 프로그래머의 역할도 맡고 있는것이다.
그러니 대다수의 평범한 기획자들은 자신의 업무에만 집중하자