Tag: 게임

도로

나는 운전을 싫어한다. 도로에 나가면 머리가 아프다. 온 신경을 집중하느라 어깨가 아프고 발 끝이 저린다.

도로에는 질서가 없다. 정직하게 줄을 서는 사람과 아닌 사람이 반반이다. 빠르게 달리는 사람과 느리게 달리는 사람이 반반이다. 참는 사람과 못참는 사람이 반반이다. 매순간 사고가 없는 것이 신기하다. 강력한 벌금이 질서를 만들 수 있지 않을까 생각했다. 그런데 그게 아닌 것 같다.

도로에서의 운전이 모든 사람을 완벽하게 통제하는 게임이라면 머리가 덜 아플지도 모르겠다. 하지만 도로는 서로 다른 사람들이 다른 룰을 가지고 다른 게임을 하는 중첩된 공간이다. 따라서 필연적으로 질서가 없다. 어떤 이에게는 생계의 수단이자 밥벌이의 공간이고, 누구에게는 비오는 날 음악을 들으며 낭만을 즐기는 데이트 장소이자, 누구에게는 그저 한시 바삐 어디로 가야하기 위해 이용하는 통로이다. 각자는 도로를 이용하는 목적이 다르고, 지켜야 할 규칙이 다르다. 하나의 ground rule 을 만들기 어렵다. 모두가 다른 게임을 하고 있기 때문에 규칙을 어겼을 때 주는 패널티의 경중마저 사람마다 다르다.

그래서 나름대로 이런 공간에 있을 때 지켜야 할 원칙들을 정했다. 최대한 나의 손해가 없도록 보수적으로 움직일 것, 나의 책임이 없도록 최소한의 규칙은 준수할 것, 그리고 다른 규칙을 따르고 있는 사람을 이해할 것. 무질서에서 질서를 찾으려 하거나, 왜 질서가 없는지 탓하지 말고 그저 한 발짝 물러서 있는 것이 좋겠다.

프로게이머의 특별한 게임 방법

  2004년, 한참 스타크래프트가 인기 있던 시절이었다. 다른 많은 벤처 기업들이 그랬던 것과 같이 내가 다니던 회사에서도 야근을 할라치면 일상처럼 저녁 식사 후에 스타크래프트 한 게임을 즐겼다. 회사에는 프로게이머를 준비하다가 군 문제 때문에 회사에 입사한 친구가 한명 있었는데 연습생 신분으로도 있었고 정식으로 프로게이머 협회에 등록이 되어 있다고 했다.

  그 친구가 게임하는 모습을 옆에서 지켜보면 놀라운 점이 하나 있었다. 그리고 그 놀라운 점이 나와 그 친구의 가장 큰 차이점으로 생각됐다. 그것은 게임을 전지적 시점에서 관찰할 수 있는 능력이다. 마치 자신의 인격을 두 개로 분리 시켜서 하나의 인격은 순간적인 반응과 빠른 손놀림을 위해 게임에 몰입하게 해 놓고, 다른 하나의 인격은 모니터 멀찍이서 게임을 보면서 마치 훈수를 두는 것처럼 게임에 참가하고 있었다.

  어떻게 이 것을 알 수 있냐 하면, 게임 중에 내가 다가가면 나와 마치 TV에 나오는 게임을 함께 관람하는 것처럼 대화를 주고 받으면서 몸으로는 게임을 하고 있는 것이다!

“지금 상대편은 뮤탈리스크 4기가 나왔으니까 저글링은 몇 개 이상 없을 거에요. 여기서 제가 저글링만 계속 뽑아도 흔들어줄 수 있죠.”

  나는 온통 게임에 몰입하고 내 모든 정신은 순간순간 상대의 공격에 반응하기 바쁜데 어떻게 저런 여유를 부릴 수 있는지. 여유라고는 하지만 물론 손놀림은 한치의 느려짐이 없지만 말이다. 그러고는 결국 게임을 자신이 예상했던 시나리오 대로 진행 시켜서 승리를 거둔다. 얼마나 많은 연습이 필요했을까? 얼마나 많은 상상이 필요했을까?

  다른 실시간 커뮤니케이션도 마찬가지다. 다른 사람의 반응에만 대처하기 바쁜 사람은 결국 그 끝에서 원하는 것을 얻을 수 있을까? 대화의 처음과 끝에서 실시간으로 시나리오를 짤 수 있는 사람은 얼마나 손쉬운, 또 여유로운 대화를 이끌어 나갈 수 있을까? 그것이 어떤 형태의 커뮤니케이션 이건 – 협상, 흥정, 유희, 싸움, 논쟁 등 – 나와 남의 관계 속에 빠져들지 말고 커뮤니케이션 자체를 냉정하게 살펴볼 수 있는 능력이 있어야 결국 원하는 것을 얻을 수 있다.

  지난 학기 수강했던 Negotiation 과목에서 가장 인상 깊었던 것은, 흔히 속된말로 “통밥을 굴린다고 하는 협상 과정”에서조차, 주어진 데이터를 얼마나 객관화, 정량화 하느냐 그리고 이 것을 바탕으로 얼마나 연습하고 상대방의 반응에 잘 대처 하느냐가 협상의 성공 여부의 거의 전부를 좌우한다는 것이다. 결국 위의 게임에서와 같은 이야기 이다.

  실시간(Real-time)으로 이루어지는 무엇에서의 성취는 모든 참여자들 보다 더 상황을 객관적으로, 즉 객관적이라는 것은 그들과는 다른 차원으로 볼 수 있는 눈이 있어야 가능하다는 생각이다. 그러기 위해서는 보다 넓게 판 전체를 조망하려는 부단한 연습이 필요하다.

테트리스

  무엇인가 모자란 점을 우연치 않은 기회에 발견하고, 어떻게 하면 모자라지 않을 수 있는지 곰곰히 생각해본 다음에, 무엇인가를 하기로 결심을 한다. 그리고 일주일의 주어진 시간 중 언제쯤 결심한 일을 실행 할 수 있는지 정한다.


  몇 달인가 전에는 TOEFL 시험의 Speaking Section의 성적이 엉망인 것을 깨닫고는 영어로 말하기를 연습해야 할 것 같아서 토요일 오전을 영어회화 스터디라는 블럭으로 채워넣었다. 그 후에는 연구실에 들어와서 하루종일 앉아서 밥만 두끼 축내고 살만 찌는 것이 아닌가하는 생각이 들어서 아침 이른 시간과 토요일 이른 오후를 스포츠 센터에서 운동하는 것으로 채워 넣었다. (월수금은 수영이고 화목토는 웨이트와 조깅이다) 뒤쳐지지 않는 문화생활을 위해서 평일에 운좋게 생긴 공휴일의 아침에는 집근처의 영화관에서 조조영화를 관람하기로 하고, 최소 한달에 한번 정도는 예술의 전당에서 저녁 8시에 시작하는 클래식 콘서트 공연을 보기로 정했다. 친구들도 서로 얼굴을 까먹지 않도록은 만나줘야 하는 것 아닌가 싶어서 평일 중 하루, 또 주말 하루의 저녁때는 평소에 보기 힘든 친구를 만나는 시간으로 할애하기로 했다. 이렇게 살다보니 전공서적에만 파묻혔지 혼자 사색하면서 독서할 수 있는 시간은 전혀 없어서 새로운 책을 읽을 수 있도록 자극이 되고 토론할 수 있는 기회를 얻을 수 있는 모임을 토요일 늦은 오후에 하기로 정하고 참여토록 했다. 일요일의 오후에는 운전연습도 하고 못가본 동네의 지리도 익힐 겸 차를 몰고 돌아다니는 것으로 정했다. 생각해보면 나는 대부분 이런 식이다. 심지어 연애조차도.


  이러한 끝도없이 수많은 계획을 세우고 실천하고 하다보니 마치 테트리스 게임을 하는 듯한 기분이 들었다. 누구나 테트리스라는 게임을 알고 있을 것이다. 주어지는 조그만 블럭들을 시간안에 최대한 빈공간이 없도록 아래쪽의 공간에다가 가지런히 쌓아가는 것. 주어지는, 나를 안달나게 하는 과업들은 시간이 갈수록 하나씩 쌓여만 가고, 나는 서둘러 한정된 시간 공간 안에 최대한 빈틈이 없이 메꾸어 나가고 있는 것이다. 빈공간이 있으면 안되는 것 처럼 쓸데없는 시간의 낭비가 있으면 안된다.


  하나 다른 점이 있다면 테트리스는 하나의 완전무결한 라인이 있으면 그 공간은 사라지지만, 실제 자기의 삶을 하나하나 채워가다보면 꼭 완벽하게 효율적으로 시간을 활용한다고 해도 쉽게 무엇인가 성취되지는 않는다는 것이다. 영어회화를 몇 주 성실하게 참여했다고 해서 네이티브 처럼 영어를 할 수 있게 되는 것도 아니고, 운동을 몇 주 열심히 했다고 해서 평생 운동을 하지 않아도 될 만큼 건강해지는 것도 아니다. 인생에서는 마음먹은 것은 무엇이는 금방 해 낼 수 있는 천재가 아닌이상에야 처리하는 블럭보다는 쌓이는 블럭들이 더 많아지기 마련이고 그러한 블럭들은 점점 위를 향해 한층한층 더 쌓이게 될 것이다.


  테트리스에서도 한정된 공간이 주어지고 그 공간을 넘어서면 Game Over 문구를 보게 되는 것 처럼 인생이라는 것도 한정된 시간이 주어지고 언젠가는 그 종착역에 다다르게 마련이다. 위에서 말했듯이 쏟아지는 과제를 숙명적으로 다 없애는 것은 불가능하다. 어떤 것들은 도저히 없앨 수 없어서 평생을 끌어안고 가야하는 것들도 분명히 있을 것이다.


  테트리스에서 시간에 쫓겨 레버를 아래로 내리거나 블럭을 한번에 아래로 곤두박질 시키는 버튼을 누르거나 하는 것과는 다르게 삶에서는 이 공간을 하나하나 정성껏 꼼꼼하게 메꾸는 여유를 가져도 별로 손해 볼 것은 없을 것 같다는 생각이 문득 들었다. 어짜피 빠르게 쌓았다고 그 시간만큼 보상으로 되돌려 받지 못할 바에는 조금은 여유를 가져도 될 것 같이 보인다. 얼마나 많은 블럭을 쌓고 얼마나 많은 라인을 없앴는지로 평가받는 것이아니라 이 시간공간 안에 얼마나 많은 블럭들을 포용하고 있는지로 평가받는, 게임과는 조금 다른 인생이기 때문이다. 


  테트리스에서 느낀 인생은 그런 느낌이다.


———————————————————————————————————


요건 살짝 픽션이네 -_- 아 갑자기 글이 복잡해져서 수정하기 귀찮다;

개발자와 기획자, 상생의 길

  5년전의 이야기로, 20살을 막 넘었을 시절에 조그만 벤처기업에서 휴대폰 게임을 만드는 일을 주로 하면서 병역의 의무를 대신할 수 있었습니다. 비록 컴퓨터 공학과라는 조그만 명찰이야 달고 있었지만, 학교에서 배운 것이라야 이산수학, 선형대수등의 실제 개발 업무와는 별로 관계가 없는 기초 학문들이었고 (물론 실무 경험은 있을리 없었고) 프로그래밍 경험도 고등학교 시절의 C언어 프로그래밍과 대학 들어와서 혼자 공부한 C++ 정도였다고 할 수 있는, 말 그대로 초짜중의 초짜였지요.  


  다행스럽게도 회사 전체에 제가 담당하는 파트(C++/BREW)의 인원은 한명. 즉 저 혼자였고, 이는 2년 6개월 동안 일하고 퇴사할때까지 거의 계속되어 스스로 이것저것 마음대로 실험을 해볼 수 있는 좋은 환경을 만들어 주었지요. 무엇을 해도 아는 사람도 없었고, 또 확실하게 이해할 수 있는 사람도 없었으니까 말이죠. 혼자 개발할 수 있는 환경은 커다란 축복이었다고 생각합니다. 물론 그만큼 삽질을 많이 했지만요.


  집에서 혼자서 울트라에디트 따위로 끄적대는 상황이 아닌 실제로 일을 시작하자, 가장 커다란 문제는 바로 기획자와의 커뮤니케이션이었습니다. 어떤 순서로 일을 진행해야 하는지, 어떤 말을 해야 내가 책임이 없어지는지, 어떻게 해야 일거리가 줄어드는지에 대한 지식이 없는 상태에서의 첫번째 일은 커다란 시련이었지요. 앞으로의 이야기는 2년 반동안 이 기획자와의 문제를 어떻게 해결하려 했는지에 대한 기록입니다.


  처음의 개발 환경은 기획자가 떠오르는 아이디어를 저에게 설명하고 이를 제가 구현하는 방식이었습니다. 이를테면,


 “거대 보스가 나타나서 미사일을 쏘는 걸로 해요. 체력은 전 스테이지보다 좀 높게 하죠? 2배정도. 속도도 좀 빠르게 움직여서 난이도를 좀 올릴 필요가 있는 것 같아요”


  네, 말그대로 개발자에게는 제앙과 같은 개발 방법입니다. 게다가 이 회사의 커뮤니케이션은 묘하게도 모두 사내 메신져를 통하게 되어 있었습니다. 다들 한 방에서 일하는데 말이죠. (언젠가 상사분께 여쭈어 봤더니, 모든 커뮤니케이션을 기록으로 남겨 책임 소재를 분명하게 하기 위함이라고 설명해주셨습니다.) 따라서 저 말은 직접 귀로 듣는 것도 아닌 띠리링 하는 소리와 함께 화면 오른쪽 구석탱이에서 나타나는 거였죠.


  근본적인 문제는 모든 것이 너무 추상적이라는 것이지요. 체력은 2배 남짓 높여야되고, 속도는 어느 정도로 움직여야 난이도가 올라갈까요? 아니 애당초 도대체, 난이도를 얼마나 올려야 되는거죠? 난이도를 2배 올린다는게 무슨 말인지 이해가 안가네요? .. 라고 기획자에게 따지듯이 물었으면 좋았겠습니다만, 메신져로 상대방 기분좋게 묻기 어려운 상황인데다가, 연장자셨으므로, 나름대로 합리적인 수치를 대입해서 만든 것을 열심히 수정합니다.


  이런식으로 수정본을 다시 기획자에게 보여주면, 이전의 프로세스가 다시 반복됩니다. 무슨 문제가 있다라는 추상적인 답변이 오고 또 개발자는 수정을 하고 돌려보고, 결국 만족하지는 않지만, 더 일하기는 싫어지는 상황까지 도달하면 상사에게 개발이 완료 되었다고 보고를 합니다. 마치 도량형도 없는 시대에 양팔 저울 위에서 눈 짐작으로 평형을 만드는 것 같은 작업 방식이지요.


  몇 개월 후, 이런 식의 무한 반복 작업에 지친 개발자는 기획자에게 수치화 된 기획서를 요구하기 시작했습니다. 그리고 정확한 수치가 나올 때까지는 절대 코딩을 하지 않는다고 선언을 해버린 것이죠. 불만 가득한 개발자의 말도 안되는 투정같은 이야기 이지요. 일의 양은 변하지 않는 것이, 기획자가 문서 상으로 정확한 수치를 준 이후에도 그 문서가 계속 바뀐다는 것입니다. 기획자의 머리 속에서만 돌던것이 실제로 보면 다를테니까요. 당연한 이야기입니다. 그 누가 처음부터 ‘재미‘를 수치로 표현해 낼 수 있겠나요.


  시간은 지났지만 첫번째의 무한 반복 개발 방법에서 좀 빠르게, 좀 느리게라고 표현되던 말이 2배, 0.5배가 되었을 뿐 할 일의 양은 서로 더 늘어났습니다. 오히려 기획자가 한번 보고 폐기될 문서만 양산하는데 시간이 오래 걸릴 뿐이었죠. 심지어는 얼마나 요구사항이 자주 바뀌던지 코딩 중에도 수차례 메신져가 띠링띠링하는 바람에 방해되니까 하루동안 바뀐 양을 업무 마감시간이 몰아서 달라고 할 정도였죠.


  이런 삽질을 한 일년하고 나니까, 어떻게 하면 더 빠르게 기획자가 요구하는 사항을 프로그램에 반영할 수 있을까? 를 고민하게 되었습니다. 그나마 그 와중에 쌓인 스킬을 바탕으로 전반적인 프로그램의 아키텍쳐를 최대한 테스트를 빠르게 할 수 있고 변화가 쉽도록 구축 하도록 했습니다. 기획자가 원하는 숫자의 변경이라던지, 디자인 변경이라던지, 하는 것들을 점점 매크로화 시키고, 자동화 시켜가면서 기획자가 변화를 요구했을때 변화가 반영되어서 다시 피드백이 되기까지의 시간을 단축시켜 나가기 시작했습니다.


  이러한 구조라던지, 보조적인 요소들을 극대화 시키니, 확실히 개발에는 가속도가 붙었습니다. 하지만, 만족할수는 없었습니다. 결국 이 부분은 개인적인 스킬의 발달이지 프로그램 개발 방법 전체를 뜯어고치지는 못했거든요. 여전히 기획서는 하루에도 수도 없이 변경되었고, 단지 예전에는 5시간 걸려서 수정된 기획서를 반영하던 것을 이제 1시간 걸려서 만들어 낸다는 것만 차이가 있었을 뿐입니다. 하지만, 같은 개발 기간에 조금 더 높은 퀄리티의 프로그램을 만들 수는 있었습니다. 테스트를 더 많이 해볼 수 있었거든요.


  일년 반쯤의 시간이 지나고 이제 프로그래밍 스킬상의 문제가 거의 사라졌을 무렵, 다른 방법을 찾아보기로 마음 먹었습니다. 바로 기획자가 스스로 모든 것을 다 할 수 있는 환경을 최대한 만들어 주는 것이었죠. 일단 조그만 것 부터 시작했습니다. 게임 상의 모든 수치는 기획자가 스스로 변경해서 테스트 할 수 있도록 간단한 툴을 만들어 준 것입니다. 그러자 더 이상 주인공이 너무 빨리 죽는다거나, 데미지가 너무 약하다던가, 보너스를 더 주어야 한다던가 하는 기획자로부터의 요구사항이 사라졌습니다.


  이러한 편리함에 효과를 본 저는 점점 더 많은 부분을 기획자에게 떠 넘기기 시작했습니다. 맵과 아이템을 디자인 할 수 있는 툴과 어플리케이션을 주고 기획자가 스스로 디자인한 스테이지에서 플레이 할 수 있도록 했습니다. 물론, 프로그래머의 간섭 없이 말이죠. 결국에 가서는 메뉴 구성 조차도 기획자가 직접 뜯어 고쳐가면서 플레이 할 수 있도록 만들어 버렸죠. 그러자, 더 이상 자잘한 요구들이 기획자로부터 넘어오는 일이 없었습니다. 기획자가 프로그래머에게 요구하는 일은 정말로 프로그래머가 아니면 안되는 일 뿐이었습니다.


  이러한 본인 일거리 떠넘기기에 재미를 붙인 저는 심지어는 이미지를 교체하고 디스플레이 하는 위치를 정하는 것 조차 기획자에게 넘겨버리려고 했습니다만 생각해보니 그러면 “도대체 프로그래머는 하는일이 뭐야?”라는 비평을 들을 것과 몇몇 기술적인 문제 때문에 그 단계까지 가지는 않았습니다.


  프로젝트가 시작하면 어서 빨리 이러한 툴들와 어플리케이션의 뼈대를 만든 후 기획자에게 던져버리고 저는 기획자로 부터 받을 수 있는 인풋이 제가 만든 프로그램 위에서 에러없이 플레이 되는 것을 보장하는 일과 프로그램 자체의 버그를 잡는 일에 집중했습니다. 물론 기획자 분은 왠지 일이 더 많아지고 바빠진 것 같다고 불평하셨지만, 그 것은 다름아니라 프로그래머에게 개선을 요구하고 업데이트 버젼이 돌아올 때까지의 기다리던 시간이 사라진 것이었죠.


  이러한 일처리가 가능해지면서 프로그램은 훨씬 더 견고해졌고, 게임을 테스트하는 시간은 상대적으로 훨씬 더 증가했습니다. 2년이 되어가던 무렵에 시작했던 3개월짜리 프로젝트는 결국 그 마감시한을 지킬 수 있었고, 버그도 거의 없었지요. 이전까지 버그 투성이에 연장에 연장을 거듭하면 프로젝트들에 비하면 장족의 발전이었다고 할 수 있었습니다.


  마지막으로 진행하려 했던 노력은 위의 프로젝트에 사용했던 툴들을 추후의 프로젝트에서 재사용할 수 있도록 가공하고 디자이너도 이 협력 프로젝트에 끌어들이는 것이지요. BREW 자체가 그리 복잡하지 않은 플랫폼인데다가, 늘 만드는 프로그램의 구조가 비슷했으므로, 유저 인터페이스를 모두 기획자가 직접 구성하게 하고, 이미지의 교체와 레이아웃의 변경 역시 디자이너가 직접 할 수 있게 하부의 구조와 툴을 제공하는 것이었죠. 물론 기존에 사용했던 컴포넌트들을 조금만 수정해서 구축이 가능하게 말이지요. 뭐, 간단히 말하면 기획쪽의 변경사항은 다 기획자가 직접하도록, 이미지쪽의 변경사항은 다 디자이너가 직접할 수 있도록 하는 환경을 제공하기만 하는 것이었습니다.


  비록 퇴사로 인해서 초기 테스트 단계에서 멈췄지만 그때 생각했던 철학을 완성했으면 훨씬 더 잘 할 수 있었을 텐데라는 확신은 있습니다. 언젠가 다시 그런 쪽의 일을 하게 된다면 제로에서 시작하는 것보다는 잘 할 수 있겠지요. 물론 다른 선진화된 개발 과정을 가지고 있는 회사에서라면 더 나은 노하우로 놀랄만한 스피드로 개발을 하고들 있겠지요. 하지만 저는 누군가의 도움없이 이런 일들을 스스로 했다는 것에 대해서 나름대로 자부심을 가지고 있답니다.


  (실은, 소프트웨어 공학 과목의 시험 공부를 하다가 예전 회사에 적용할 수 있는 수많은 학문적인 백그라운드를 보고는 울분에 차서 나도 나름대로 잘 했다고! 마음속으로 외치면서 쓴 글입니다. 이런 과목을 미리 공부 했었더라면 얼마나 좋았을까요. 2년 반의 삽질, 없어도 좋았을텐데;)