5년전의 이야기로, 20살을 막 넘었을 시절에 조그만 벤처기업에서 휴대폰 게임을 만드는 일을 주로 하면서 병역의 의무를 대신할 수 있었습니다. 비록 컴퓨터 공학과라는 조그만 명찰이야 달고 있었지만, 학교에서 배운 것이라야 이산수학, 선형대수등의 실제 개발 업무와는 별로 관계가 없는 기초 학문들이었고 (물론 실무 경험은 있을리 없었고) 프로그래밍 경험도 고등학교 시절의 C언어 프로그래밍과 대학 들어와서 혼자 공부한 C++ 정도였다고 할 수 있는, 말 그대로 초짜중의 초짜였지요.
다행스럽게도 회사 전체에 제가 담당하는 파트(C++/BREW)의 인원은 한명. 즉 저 혼자였고, 이는 2년 6개월 동안 일하고 퇴사할때까지 거의 계속되어 스스로 이것저것 마음대로 실험을 해볼 수 있는 좋은 환경을 만들어 주었지요. 무엇을 해도 아는 사람도 없었고, 또 확실하게 이해할 수 있는 사람도 없었으니까 말이죠. 혼자 개발할 수 있는 환경은 커다란 축복이었다고 생각합니다. 물론 그만큼 삽질을 많이 했지만요.
집에서 혼자서 울트라에디트 따위로 끄적대는 상황이 아닌 실제로 일을 시작하자, 가장 커다란 문제는 바로 기획자와의 커뮤니케이션이었습니다. 어떤 순서로 일을 진행해야 하는지, 어떤 말을 해야 내가 책임이 없어지는지, 어떻게 해야 일거리가 줄어드는지에 대한 지식이 없는 상태에서의 첫번째 일은 커다란 시련이었지요. 앞으로의 이야기는 2년 반동안 이 기획자와의 문제를 어떻게 해결하려 했는지에 대한 기록입니다.
처음의 개발 환경은 기획자가 떠오르는 아이디어를 저에게 설명하고 이를 제가 구현하는 방식이었습니다. 이를테면,
“거대 보스가 나타나서 미사일을 쏘는 걸로 해요. 체력은 전 스테이지보다 좀 높게 하죠? 2배정도. 속도도 좀 빠르게 움직여서 난이도를 좀 올릴 필요가 있는 것 같아요”
네, 말그대로 개발자에게는 제앙과 같은 개발 방법입니다. 게다가 이 회사의 커뮤니케이션은 묘하게도 모두 사내 메신져를 통하게 되어 있었습니다. 다들 한 방에서 일하는데 말이죠. (언젠가 상사분께 여쭈어 봤더니, 모든 커뮤니케이션을 기록으로 남겨 책임 소재를 분명하게 하기 위함이라고 설명해주셨습니다.) 따라서 저 말은 직접 귀로 듣는 것도 아닌 띠리링 하는 소리와 함께 화면 오른쪽 구석탱이에서 나타나는 거였죠.
근본적인 문제는 모든 것이 너무 추상적이라는 것이지요. 체력은 2배 남짓 높여야되고, 속도는 어느 정도로 움직여야 난이도가 올라갈까요? 아니 애당초 도대체, 난이도를 얼마나 올려야 되는거죠? 난이도를 2배 올린다는게 무슨 말인지 이해가 안가네요? .. 라고 기획자에게 따지듯이 물었으면 좋았겠습니다만, 메신져로 상대방 기분좋게 묻기 어려운 상황인데다가, 연장자셨으므로, 나름대로 합리적인 수치를 대입해서 만든 것을 열심히 수정합니다.
이런식으로 수정본을 다시 기획자에게 보여주면, 이전의 프로세스가 다시 반복됩니다. 무슨 문제가 있다라는 추상적인 답변이 오고 또 개발자는 수정을 하고 돌려보고, 결국 만족하지는 않지만, 더 일하기는 싫어지는 상황까지 도달하면 상사에게 개발이 완료 되었다고 보고를 합니다. 마치 도량형도 없는 시대에 양팔 저울 위에서 눈 짐작으로 평형을 만드는 것 같은 작업 방식이지요.
몇 개월 후, 이런 식의 무한 반복 작업에 지친 개발자는 기획자에게 수치화 된 기획서를 요구하기 시작했습니다. 그리고 정확한 수치가 나올 때까지는 절대 코딩을 하지 않는다고 선언을 해버린 것이죠. 불만 가득한 개발자의 말도 안되는 투정같은 이야기 이지요. 일의 양은 변하지 않는 것이, 기획자가 문서 상으로 정확한 수치를 준 이후에도 그 문서가 계속 바뀐다는 것입니다. 기획자의 머리 속에서만 돌던것이 실제로 보면 다를테니까요. 당연한 이야기입니다. 그 누가 처음부터 ‘재미‘를 수치로 표현해 낼 수 있겠나요.
시간은 지났지만 첫번째의 무한 반복 개발 방법에서 좀 빠르게, 좀 느리게라고 표현되던 말이 2배, 0.5배가 되었을 뿐 할 일의 양은 서로 더 늘어났습니다. 오히려 기획자가 한번 보고 폐기될 문서만 양산하는데 시간이 오래 걸릴 뿐이었죠. 심지어는 얼마나 요구사항이 자주 바뀌던지 코딩 중에도 수차례 메신져가 띠링띠링하는 바람에 방해되니까 하루동안 바뀐 양을 업무 마감시간이 몰아서 달라고 할 정도였죠.
이런 삽질을 한 일년하고 나니까, 어떻게 하면 더 빠르게 기획자가 요구하는 사항을 프로그램에 반영할 수 있을까? 를 고민하게 되었습니다. 그나마 그 와중에 쌓인 스킬을 바탕으로 전반적인 프로그램의 아키텍쳐를 최대한 테스트를 빠르게 할 수 있고 변화가 쉽도록 구축 하도록 했습니다. 기획자가 원하는 숫자의 변경이라던지, 디자인 변경이라던지, 하는 것들을 점점 매크로화 시키고, 자동화 시켜가면서 기획자가 변화를 요구했을때 변화가 반영되어서 다시 피드백이 되기까지의 시간을 단축시켜 나가기 시작했습니다.
이러한 구조라던지, 보조적인 요소들을 극대화 시키니, 확실히 개발에는 가속도가 붙었습니다. 하지만, 만족할수는 없었습니다. 결국 이 부분은 개인적인 스킬의 발달이지 프로그램 개발 방법 전체를 뜯어고치지는 못했거든요. 여전히 기획서는 하루에도 수도 없이 변경되었고, 단지 예전에는 5시간 걸려서 수정된 기획서를 반영하던 것을 이제 1시간 걸려서 만들어 낸다는 것만 차이가 있었을 뿐입니다. 하지만, 같은 개발 기간에 조금 더 높은 퀄리티의 프로그램을 만들 수는 있었습니다. 테스트를 더 많이 해볼 수 있었거든요.
일년 반쯤의 시간이 지나고 이제 프로그래밍 스킬상의 문제가 거의 사라졌을 무렵, 다른 방법을 찾아보기로 마음 먹었습니다. 바로 기획자가 스스로 모든 것을 다 할 수 있는 환경을 최대한 만들어 주는 것이었죠. 일단 조그만 것 부터 시작했습니다. 게임 상의 모든 수치는 기획자가 스스로 변경해서 테스트 할 수 있도록 간단한 툴을 만들어 준 것입니다. 그러자 더 이상 주인공이 너무 빨리 죽는다거나, 데미지가 너무 약하다던가, 보너스를 더 주어야 한다던가 하는 기획자로부터의 요구사항이 사라졌습니다.
이러한 편리함에 효과를 본 저는 점점 더 많은 부분을 기획자에게 떠 넘기기 시작했습니다. 맵과 아이템을 디자인 할 수 있는 툴과 어플리케이션을 주고 기획자가 스스로 디자인한 스테이지에서 플레이 할 수 있도록 했습니다. 물론, 프로그래머의 간섭 없이 말이죠. 결국에 가서는 메뉴 구성 조차도 기획자가 직접 뜯어 고쳐가면서 플레이 할 수 있도록 만들어 버렸죠. 그러자, 더 이상 자잘한 요구들이 기획자로부터 넘어오는 일이 없었습니다. 기획자가 프로그래머에게 요구하는 일은 정말로 프로그래머가 아니면 안되는 일 뿐이었습니다.
이러한 본인 일거리 떠넘기기에 재미를 붙인 저는 심지어는 이미지를 교체하고 디스플레이 하는 위치를 정하는 것 조차 기획자에게 넘겨버리려고 했습니다만 생각해보니 그러면 “도대체 프로그래머는 하는일이 뭐야?”라는 비평을 들을 것과 몇몇 기술적인 문제 때문에 그 단계까지 가지는 않았습니다.
프로젝트가 시작하면 어서 빨리 이러한 툴들와 어플리케이션의 뼈대를 만든 후 기획자에게 던져버리고 저는 기획자로 부터 받을 수 있는 인풋이 제가 만든 프로그램 위에서 에러없이 플레이 되는 것을 보장하는 일과 프로그램 자체의 버그를 잡는 일에 집중했습니다. 물론 기획자 분은 왠지 일이 더 많아지고 바빠진 것 같다고 불평하셨지만, 그 것은 다름아니라 프로그래머에게 개선을 요구하고 업데이트 버젼이 돌아올 때까지의 기다리던 시간이 사라진 것이었죠.
이러한 일처리가 가능해지면서 프로그램은 훨씬 더 견고해졌고, 게임을 테스트하는 시간은 상대적으로 훨씬 더 증가했습니다. 2년이 되어가던 무렵에 시작했던 3개월짜리 프로젝트는 결국 그 마감시한을 지킬 수 있었고, 버그도 거의 없었지요. 이전까지 버그 투성이에 연장에 연장을 거듭하면 프로젝트들에 비하면 장족의 발전이었다고 할 수 있었습니다.
마지막으로 진행하려 했던 노력은 위의 프로젝트에 사용했던 툴들을 추후의 프로젝트에서 재사용할 수 있도록 가공하고 디자이너도 이 협력 프로젝트에 끌어들이는 것이지요. BREW 자체가 그리 복잡하지 않은 플랫폼인데다가, 늘 만드는 프로그램의 구조가 비슷했으므로, 유저 인터페이스를 모두 기획자가 직접 구성하게 하고, 이미지의 교체와 레이아웃의 변경 역시 디자이너가 직접 할 수 있게 하부의 구조와 툴을 제공하는 것이었죠. 물론 기존에 사용했던 컴포넌트들을 조금만 수정해서 구축이 가능하게 말이지요. 뭐, 간단히 말하면 기획쪽의 변경사항은 다 기획자가 직접하도록, 이미지쪽의 변경사항은 다 디자이너가 직접할 수 있도록 하는 환경을 제공하기만 하는 것이었습니다.
비록 퇴사로 인해서 초기 테스트 단계에서 멈췄지만 그때 생각했던 철학을 완성했으면 훨씬 더 잘 할 수 있었을 텐데라는 확신은 있습니다. 언젠가 다시 그런 쪽의 일을 하게 된다면 제로에서 시작하는 것보다는 잘 할 수 있겠지요. 물론 다른 선진화된 개발 과정을 가지고 있는 회사에서라면 더 나은 노하우로 놀랄만한 스피드로 개발을 하고들 있겠지요. 하지만 저는 누군가의 도움없이 이런 일들을 스스로 했다는 것에 대해서 나름대로 자부심을 가지고 있답니다.
(실은, 소프트웨어 공학 과목의 시험 공부를 하다가 예전 회사에 적용할 수 있는 수많은 학문적인 백그라운드를 보고는 울분에 차서 나도 나름대로 잘 했다고! 마음속으로 외치면서 쓴 글입니다. 이런 과목을 미리 공부 했었더라면 얼마나 좋았을까요. 2년 반의 삽질, 없어도 좋았을텐데;)