프로그래머와 대화하는 법

---

게임회사 일상생활은 실무에서 개인적으로 겪은 일을 각색하였습니다.

---

시스템 기획을 오랜 시간 하다 보면 간혹 이런 질문을 받을 때가 많다.

“프로그래머와 대화하려면 프로그램 언어를 배워야 하나요?”

 

나에게 이런 질문을 한다면 내 대답은 한결같다.

“아뇨. 프로그램 언어를 배울 필요는 없습니다. 단지 관점을 조금 바꾸면 됩니다.”

코드를 작성하고 싶으면 기획자가 아닌 프로그래머를 지망해라 .

 

데이터적 관점에서 설명했듯이 프로그래머와 대화하는 것은 매우 쉽다. 그리고 나는 프로그래머와 대화하는 것을 아주 좋아한다. 이유는 그들과 대화할 때는 옳고 그름 단 두 가지만 만족한다면 대화에 아무런 문제가 생기지 않는다는 점이다. (반대로 정답이 없는 쪽인 기획자들과 이야기하면 무척이나 피곤하다.)

 

만약 당신이 프로그래머에게 무언가를 물어보거나 작업을 요청했을 때 “안됩니다.”라는 말을 듣는다면 그 이유는 3가지 중 하나이다.

 

1. 현존하지 않는 기술을 개발 요청했을 때

2. 개발에 충분한 시간(일정)이 부족하다.

3. 프로그래머가 하기 싫다(귀찮다)

 

위 3가지 이유에서 하나라도 해당되지 않는다면 담당 프로그래머의 역량 부족이라 생각해도 좋다. 아니면 당신의 기획서나 피드백이 이해할 수 없는 화성의 언어가 아니라면 말이다. 그러니 당신이 프로그래머와 커뮤니케이션을 하기 위해서 프로그램 언어를 배우기보다는 문장력과 어휘력을 공부하는 것이 더 도움이 된다. 물론 프로그램 언어의 지식은 약간의 도움이 되기는 한다. 다만 기능적인 부분이 아닌 생각하는 방식과 말하는 방법의 차이를 이해하는 정도 수준 정도이다.

 

만약 당신이 내 충고를 무시하고 프로그램 언어를 지금부터 공부하고 그들과 기술적 대화를 나눌 수 있는 수준이라면 이미 기획자가 아닌 프로그래머이다. C++ 또는 C#책을 한 권 다 읽고 적당한 코드를 읽어 낼 수 있다고 그들과 커뮤니케이션하는 것에 큰 도움이 되지 않는다. 오히려 어줍지 않은 지식으로 그들의 자존심만 건드릴뿐이다.

내가 만나온 대부분의 프로그래머는 자신이 납득하지 못하면 개발에 열정을 가지지 못했다.

 

그렇다면 구체적인 관점의 전환을 통해 그들과 쉽게 대화할 수 있는 방법은 어떻게 하면 될까?

1. 규칙과 예외 처리를 설정하라.

-. 규칙을 설정하고 발생하는 예외처리 사항에 대한 정보를 항상 함께 설명해야 한다. 코드는 기본적으로 A의 상황과 그 결과인 B에 대하여 생각하고 A가 B가 되지 않을 경우 또는 A가 성립되지 못하는 상황에 대한 정보를 설정하지 않으면 동작하지 않는다. (또는 비 정상적인 동작으로 우리를 곤란하게 만든다.)

 

2. 프로그래머가 알아야 하는 정보의 위치를 제공한다.

-. 데이터를 제어하는 변수들의 값들이 어느 위치에 있는지 그리고 그 값들이 어떠한 역할을 하는지 설명해 주어야 한다. 그리고 그 값을 이용해 내가 무엇을 어떻게 게임에서 활용할 수 있는지 말할 수 있다면 그들 대부분은 충분히 납득하고 기꺼이 개발에 착수한다.

 

이렇듯 2가지만 지켜진다면 프로그래머와 대화하는데 큰 문제가 생기지 않는다. 이해가 되는가? 그렇다면 해야 할 것이 있다면 당연하게도 그 반대하지 말아야 할 것이 있기 마련이다.

 

1. 규칙을 쉽게 변경하지 말아라

-. 게임 개발이 항상 처음 정해진 그대로 만들어진다면 좋겠지만 상황에 따라 다양한 변화를 수용하고 그에 따라 많은 부분이 변경된다. 하지만 가급적이면 처음 정한 규칙을 변경하지 않도록 해야 한다. 잦은 규칙 변경은 시스템의 전반적인 신뢰도를 낮출 수 있다. 그리고 전체 코드의 알고리즘이 완성된 상태라면 규칙을 수정하는 것이 당신이 생각하는 것보다 더 큰 작업이 될 수 있다.

 

“아~ 건물 완전 마음에 들어요. 완벽합니다. 그런데 1 cmm만 옆으로 이동하죠?”

 

당신의 입장에서는 1 cmm이동이 매우 쉽게 보일 수 있지만 건물을 지은 사람 입장에서는 처음부터 다시 만들라는 이야기와 같다.

현실에서 건물을 들어서 옮기는 것과 같이 상식적으로 이해할 수 없는 상황이다

 

2. 그냥 예외처리 해주세요.

-. 예외 처리라는 것은 시스템이 정상적으로 동작하지 않는 상황에서 프로젝트를 보호하기 위해 방어 코딩을 하하는 것이다. 때문에 당신이 설정한 허점투성이의 논리적이지 못한 규칙을 보안하기 위한 과도한 예외처리 사항을 요구하게 된다면 처음 설정한 규칙에 문제가 없는 지부터 확인해야 한다.

단순한 예외처리 요청은 너무나 무책임한 행동이다.

 

3. 프로그래머처럼 말하지 마라.

시스템 기획을 하다 보면 간혹 자신이 프로그래머인 것 마냥 말하는 사람이 있다. 당신은 기획자이며 코드를 다루는 것에는 비 전문가이다. “이것은 이렇게 코드로 처리하면 되지 않아요?”라는 것은 담당 프로그래머가 생각하고 결론을 도출해야 한다. 상대 작업 영역을 건드리지 말아라 차라리 모르면 하고 싶은 것을 이야기해라 그리고 그들이 스스로 생각할 수 있게 기회를 제공해라.

 

4. 프로그램 순서도

만약 당신의 기획서에 아래와 같은 그림이 있다면 당장 치워 버리라고 말하고 싶다.

당신의 머리속에서 나온 대부분의 논리적 흐름은 그다지 논리적이지도 않고 쓸모도 없다.

 

프로그램 순서도는 코드가 얼마나 논리적으로 동작할 수 있는지 흐름을 알기 위해 작성된다. 그리고 그 근본은 논리 회로도에 근간을 두고 있다. 논리 회로도는 True or False로 구성된다. 초기 회로도 제작 이전에 논리적으로 흐름에 문제가 없는지 완성된 회로가 정상적으로 동작하기 위해 필요했다. 하지만 당신이 만들고 있는 게임 그리고 현대 코드는 단순한 Yes or No만으로 모든 코드의 흐름을 판단하기 매우 어렵다. 1921년에 만들어진 방식이 지금도 유용하다고 생각하는가?

 

가장 큰 문제는 코드는 당신이 생각한 그 순서도와는 전혀 상관없는 형태로 작성된다는 점이 문제이다. 그렇게 만들지도 않을 것을 왜 그렇게 힘들게 만들어야 하는가? (오히려 저런 순서도 개념이 절대적으로 필요한 것은 UI를 기획할 때인데 정작 필요한 부분에는 사용하는 사람을 못 봤다.)

---

정리하자면 프로그래머와 전문가처럼 대화하고 싶은가? 그렇다면 당신은 기획자가 아닌 프로그래머를 지망해야 한다. 프로그래머도 사람이다. 그리고 기획자는 사람의 마음을 움직일 수 있어야 한다. 기획자가 프로그래머와 같은 전문성이 없는 것은 부끄러운 일이 아니다. (내가 코드적으로 설명할 수 있다면 직접 코딩하는 것이 빠르다.) 당신과 우리의 역할은 그들이 프로젝트를 위해 하는 업무가 생산적이며 활용성이 높고 고객(사용자)에게 충분한 만족감을 제공할 수 있는 가치 있는 일이라는 것을 공감하게 만들고 다소 힘들더라도 그만큼의 가치가 있다는 점을 알려주는 것이다. 만약 당신이 논리적으로 이 가치 있는 일을 논리적으로 설명할 수 없다면 차라리 그들에게 하고 싶은 것을 설명해라 충분한 가치가 있다면 내가 지금까지 만나왔던 프로그래머들은 그 가치를 위해 자신의 역량을 누구보다 충분히 아니 넘치도록 기지를 발휘하는 사람들이었다.

 

그러니 그들과 대화하는 것을 두려워하거나 어려워하지 말고 당신이 원하는 것이 그들의 마음을 움직이지 못할까 경계하라.

여러분들의 구독과 공감(♥)은 저에게 큰 힘이 됩니다.

---