Kay on the rails

내가 프로그래밍을 계속 하는 이유

25 Jul 2008

난 기획자이다. 무슨 기획자인지 선뜻 대답하지 못하는 것은 1999년부터 2007년 상반기까지는 게임 기획자였고 2007년 하반기부터는 웹 기획자인데, 지금 내 주 영역은 웹 기획이지만 아직까지는 나를 드러내는 정체성이나 차별성은 게임 기획이기 때문이다. 어쨌든 업계에 본격 나온 때인 1999년부터 실무 직무도 애초 기획이었고, 아마추어 때에도 기획이 멋져보여서 기획으로 일을 시작했다.

내 블로그들에서 드러나는 내 직무는 프로그래밍에 가깝다. 기획 얘기 보다는 개발 얘기를 더 많이 한다. 기획자 치고는 개발 관심도 많은 편이다. 다룰 줄 아는 프로그래밍 언어는 c, c++, php, asp, perl, python, javascript, html, xml, sql 을 들 수 있고 며칠 전부터 ruby 를 익히고(2년 전부터 애써 외면해오다 드디어 손을 대고) 있다. 기술로는 ajax, win32api/mfc, css 를 다룰 줄 안다. 어플리케이션 만들기라면 일기장, 웹 개발이라면 게시판 정도 만드는 걸로 만족하고 있고, 그것 마저도 높은 성능이나 협업을 위한 코딩을 담지 못하고 있긴 하다. 운영체제는 Linux 계열(시작은 Redhat Linux), FreeBSD, Mac OS X, Windows 계열을 다루며, DBMS는 mysql 과 sqlite 정도만 다룬다. 물론, 다룰 줄 알 뿐, 깊은 이해나 활용을 하는 건 아니다. 이쯤 얘기를 하면 나를 개발자라 생각하는 상황이 보통이다.

사실 프로그래밍을 좋아하진 않는다. 아니, 프로그래밍으로 돈을 버는 걸 좋아하지 않는다. 프로그래밍은 어디까지나 취미일 뿐이며, 머리 속에 있는 발상을 가볍게 구현해서 손맛을 알아보거나 장난감을 만드는 쓰임새로 다룬다. c를 공부했던 1997년부터 그랬다. linked list 를 포인터로 구현해 돌아가는 모습을 보며 신기하고 재밌긴 했지만, 이런 암호문으로 밥벌이를 하고 싶은 생각은 눈꼽만치도 들지 않았다. 비록 내 가까운 사람 몇 명을 개발자로 꼬득여 만들긴 했지만 난 개발자가 되고 싶지 않았고, 지금도 마찬가지이다.

그렇다면 어째서 나는 프로그래밍을 여전히 공부하는 것이며 관심을 두고 있는 것일까. 표현과 소통, 균형있는 관점, 그리고 자기 이해 과정 때문이다.

자기 이해 과정을 위한 프로그래밍

기획 일을 10년 가까이 해왔지만 머리가 나쁜 탓인지 머리 속에 있는 생각만으로는 도무지 실체가 잡히지 않을 때가 많다. 추상화한 머리 속 기획은 추상화된 말장난과 어울릴 뿐, 실체화된 결과물과 맞아 떨어지지 않을 때가 흔하다. 이를테면, 상상 속에서 나는 apm(Action per Minute) 1,000으로 자판과 마우스를 조작하며 스타크래프트 프로게이머인 이영호나 송병구, 이제동 같은 고수들을 가뿐하게 누르는 기계 같은 모습이지만, 실제로는 전투를 벌이고 있을 때 나보다 손과 눈이 빠른 상대방이 내 본진에 있는 일꾼들을 학살하고 있어도 전혀 눈치채지 못하는 상황과 같다. 아무리 내 머리 속에서 손맛이 끝내주는 게임을 그렸어도 그 손맛을 어떻게 구현할 것인지 설명을 하려면 막연한 표현들을 사기꾼처럼 떠벌이다 스스로 제 논리 발에 걸려 자빠진다.

벤 커즌이 조사한 바에 따르면, 이용자들에게 좋은 반응을 얻은 게임 중 게임 속 인물이 뛰어오를 때 공중에 떠있는 시간이 0.7초인 경우가 많다고 한다. 0.7초이다. 슈퍼 마리오 브라더스에 나오는 마리오가 땅에서 폴짝 뛰었다가 땅에 닿는 시간이 0.7초이다.
(디벨로퍼 매거진 2002년 8월호 - 라프 코스터의 재미이론 참조)

그 뛰어오르는 시간이 머리 속에 제대로 그려지는가? 그려졌다고 해서 그 느낌이 실제로 개체 하나가 어느 한 지점에서 떨어져 나갔다가 되돌아오는 시간이 0.7초인 실제 화면 속 느낌과 과연 같을까? 설령 뛰어올랐다 땅에 닿는 체공 시간이 0.7초로 구현했다손 치더라도, 뛰어오르는 순간부터 가속을 받았다가 정점에 가까워질수록 감속을 하고 다시 땅으로 내려올 때 가속을 받게 해서 0.7초인지, 아니면 뛰는 순간부터 땅에 닿는 순간까지 동일한 빠르기로 움직인 것인지에 따라 머리 속에 막연하게 그려져있던 “예쁘고 시원스럽게 뛰는 느낌”과 다를 수 있다.

즉, 어지간히 감이 예민하고 학습/훈련된 이가 아니면 대부분은 0.7초라는 객관화 된 느낌을 그리기 보다는 자신의 취향이 반영된 느낌을 그린다. 하물며 자기 자신 조차도 머리 속 생각과 실재를 일치시키기 어려운데, 그 생각을 다른 사람과 공유해서 같은 느낌을 갖는 것은 얼마나 어려울까? 그래서 기획자 스스로 머리 속에 있는 “그 느낌”에 확신과 개념 정립이 안된 상태에서 기획을 공유하는 건 매우 위험한 짓이다. 기획자 스스로도 실제 느낌을 모르면서 말이나 글 문장 몇 개로 상황만 설명하고선 상대방이 갸우뚱거리면 상상력이 부족하다는 둥 기획자 말을 믿고 따르라는 둥 억지를 부리기도 한다.

난 내 감을 안다. 난 감이 뛰어나지 않다. 손으로 만져보고 눈으로 보고 귀로 들어야 그제서야 “아~”하고 머리 속 생각과 맞추어봐서 어긋난 부분을 다듬는다. 그 체험을 위해 내가 택한 수단은 프로그래밍이다. 그림을 그려본 적도 있는데 손이 느려서 포기했다. 어떤 게임 기획자는 Adobe Flash 기술을 쓰기도 하고, 어떤 게임 레벨 디자이너는 레고 블럭이나 구글 스케치업을 쓰기도 한다. 어떤 개발자 출신 기획자는 유명 FPS 게임을 이용해서 MOD 게임을 만들기도 한다.

처음엔 이런 체험판이나 장난감을 만드느라 시간이 많이 걸리므로 차라리 개발자에게 도움을 받는 것이 훨씬 이득이고 효율도 높다. 하지만 감을 훈련하기 위해서 온갖 종류의 상황을 일일이 개발자에게 요청하는 건 서로를 불행하게 한다. 요즘은 쉽고 편한 프로그래밍 언어나 도구가 많고 다양하므로 기획자가 조금만 더 부지럼 떨고 공부하면 이런 문제는 차츰 해결해 나갈 수 있다.

표현과 소통을 위한 프로그래밍

그 풍부하고 입체감 있는 머리 속 생각을 고작 몇 백 몇 천 낱말로 단편화해서 상대방에게 전달하는 건 소통 효율성을 포기하겠다는 말 밖에 안된다. 기획자는 자신의 생각을 다른 직무자에게 최대한 명확하게 전해야 하므로, 말로 떠드는 것은 물론 온갖 수단과 방법을 가리지 않고 효율 높은 전달을 위해 노력해야 한다. 오랜 시간 널리 쓰인 수단은 기획서라는 문서인데, 이는 어디까지나 표현과 소통 방법 중 하나일 뿐이지 종착점이 아니다.

운이 좋게도 다른 직무자와 오래도록 호흡을 맞춰와서 “눈빛만 봐도 알 수 있잖아”라고 콧노래를 부를 수 있는 사람도 있다. 그런 사람은 그런 눈빛도 소통과 표현 수단일 것이다. 어떤 이는 직급을 이용해서 “빠꾸(cancel)!”라고 외치는 것이 소통과 표현 수단일 것이다.

난 뚝딱 뚝딱 스스로 만들어서 실제로 돌아가는 모습을 보이고, 발전 가능성과 느낌(게임이라면 손맛이라든가)을 최대한 공유하는 것이 내 소통과 표현 방법이다. 안타까운 점은 사무실에서 이런 뚝딱거림은 자칫 일 안하고 딴짓하는 걸로 오해를 사기 일쑤란 점이다. 더구나 내 프로그래밍 능력이 떨어져서 내 생각보다 구현 시간이 오래 걸리면 “그까짓것 차라리 나(개발자)한테 얘기하지, 왜 말도 없이 혼자 낑낑대다 다른 사람들 다 놀게 해요?”라는 구박을 받을 수 있다.

사실 이런 경우가 더 많았다. 내가 택한 소통과 표현 방법이 오히려 다른 직무자들을 답답하게 하는 경우가 생겼고, 그래서 사람에 대한 인터페이스(interface)가 안좋다는, 기획자가 들을 수 있는 치욕스런 비판을 들은 적도 있다.

균형있는 관점을 위한 프로그래밍

기획자에게 필요한 덕목 중에는 창의성이나 창발성이 있다. 이것과 반대 개념이라고 할 순 없지만 날뛰는(?) 창의력을 진정시켜줄 보수성도 필요하다고 생각한다. 보수성 정도에 따라서 창조 지향 기획을 하느냐 혁신 지향 기획을 하느냐 갈릴 것이다. 사람 성향이나 기획 직책(Producer, Director, Designer 등), 세부 직무(System designing, Level designing, Balance Designing 등), 혹은 상황에 따라 지향하는 바가 다를 것이다.

자신이 보수성이 강한 사람이라고 일도 언제나 보수성 짙은 기획을 한다면 스스로 양발 신발끈을 서로 묶는 짓이나 마찬가지이다. 무엇을 어떻게 하든 상관없이 보수성을 적절히 조절해야 한다. 그런 조절은 다양한 경험과 관점을 통해 균형을 취할 수 있어야 한다. 저울에 짐이 올라왔다면 다른 한 쪽에 상황에 맞게 추를 올리거나 덜어야 하는데, 이렇게 균형을 조절할 추 역할을 해줄 다양한 생각과 경험, 관점을 갖추기 위해 끊임없이 노력해야 한다.

게임 기획자 상당 수는 다른 게임을 많이 경험해서 창의력에 자극을 받거나 혹은 현실 제약/제한점을 찾는다. 난 프로그래밍으로 대신한다. 다른 게임이나 서비스를 경험하는 행위 자체를 하지 않고 모두 프로그래밍으로 대신하는 것이 아니라, 그런 경험을 하며 분석하고 이해하는 과정 중 일부 요소를 프로그래밍으로 대신한다. 다른 이가 만든 제품을 분석하여 기획서 역작성(기획서를 써서 제품을 만드는게 아니라 만들어진 제품을 보고 기획 의도를 유추하고 상상하며 거꾸로 기획서를 만드는 작업)을 하는 걸 프로그래밍으로 대신한다고 봐도 무방하다.

이런 작업들이 꼭 가치 있는 건 아니지만, 다른 관점을 체험하고 이해할 수 있는, 그러니까 균형추를 다양하게 갖출 수 있는 좋은 방법이라고 생각한다.

사람 마다 다른 개성을 가지고 있기에 다른 기획자한테 프로그래밍을 하라고 권할 생각은 없다. 도움이 되는 건 사실이지만, 더 도움이 되는 방법이 사람에 따라 다를 수 있기 때문이다. 만약 내가 좀 더 빠르거나 똘똘하다면 프로그래밍을 하며 기획에 도움을 주는 방법 말고도 다른 방법도 함께 했을 것이다. 하지만, 난 평범한 머리를 가진, 내 한계를 잘 아는, 가끔 천재를 만나면 기가 죽을 때도 있지만 그들을 인정하고 그들이 가는 길에 돌부리는 되지 말자는 생각을 하는 사람일 뿐이다. 내 끝에 최대한 가까이 갈 수 있는 방법들 중 프로그래밍은 게으른 내게 그나마 잘 맞는 실천력 있는 수단이자 방법이다.

이것이 내가 기획자이면서 프로그래밍에 관심을 갖고 계속 하는 이유이다.

Related Posts