5년전의 이야기로, 20살을 막 넘었을 시절에 조그만 벤처기업에서 휴대폰 게임을 만드는 일을 주로 하면서 병역의 의무를 대신할 수 있었습니다. 비록 컴퓨터 공학과라는 조그만 명찰이야 달고 있었지만, 학교에서 배운 것이라야 이산수학, 선형대수등의 실제 개발 업무와는 별로 관계가 없는 기초 학문들이었고 (물론 실무 경험은 있을리 없었고) 프로그래밍 경험도 고등학교 시절의 C언어 프로그래밍과 대학 들어와서 혼자 공부한 C++ 정도였다고 할 수 있는, 말 그대로 초짜중의 초짜였지요.
다행스럽게도 회사 전체에 제가 담당하는 파트(C++/BREW)의 인원은 한명. 즉 저 혼자였고, 이는 2년 6개월 동안 일하고 퇴사할때까지 거의 계속되어 스스로 이것저것 마음대로 실험을 해볼 수 있는 좋은 환경을 만들어 주었지요. 무엇을 해도 아는 사람도 없었고, 또 확실하게 이해할 수 있는 사람도 없었으니까 말이죠. 혼자 개발할 수 있는 환경은 커다란 축복이었다고 생각합니다. 물론 그만큼 삽질을 많이 했지만요.
집에서 혼자서 울트라에디트 따위로 끄적대는 상황이 아닌 실제로 일을 시작하자, 가장 커다란 문제는 바로 기획자와의 커뮤니케이션이었습니다. 어떤 순서로 일을 진행해야 하는지, 어떤 말을 해야 내가 책임이 없어지는지, 어떻게 해야 일거리가 줄어드는지에 대한 지식이 없는 상태에서의 첫번째 일은 커다란 시련이었지요. 앞으로의 이야기는 2년 반동안 이 기획자와의 문제를 어떻게 해결하려 했는지에 대한 기록입니다.
처음의 개발 환경은 기획자가 떠오르는 아이디어를 저에게 설명하고 이를 제가 구현하는 방식이었습니다. 이를테면,
“거대 보스가 나타나서 미사일을 쏘는 걸로 해요. 체력은 전 스테이지보다 좀 높게 하죠? 2배정도. 속도도 좀 빠르게 움직여서 난이도를 좀 올릴 필요가 있는 것 같아요”
네, 말그대로 개발자에게는 제앙과 같은 개발 방법입니다. 게다가 이 회사의 커뮤니케이션은 묘하게도 모두 사내 메신져를 통하게 되어 있었습니다. 다들 한 방에서 일하는데 말이죠. (언젠가 상사분께 여쭈어 봤더니, 모든 커뮤니케이션을 기록으로 남겨 책임 소재를 분명하게 하기 위함이라고 설명해주셨습니다.) 따라서 저 말은 직접 귀로 듣는 것도 아닌 띠리링 하는 소리와 함께 화면 오른쪽 구석탱이에서 나타나는 거였죠.
근본적인 문제는 모든 것이 너무 추상적이라는 것이지요. 체력은 2배 남짓 높여야되고, 속도는 어느 정도로 움직여야 난이도가 올라갈까요? 아니 애당초 도대체, 난이도를 얼마나 올려야 되는거죠? 난이도를 2배 올린다는게 무슨 말인지 이해가 안가네요? .. 라고 기획자에게 따지듯이 물었으면 좋았겠습니다만, 메신져로 상대방 기분좋게 묻기 어려운 상황인데다가, 연장자셨으므로, 나름대로 합리적인 수치를 대입해서 만든 것을 열심히 수정합니다.
이런식으로 수정본을 다시 기획자에게 보여주면, 이전의 프로세스가 다시 반복됩니다. 무슨 문제가 있다라는 추상적인 답변이 오고 또 개발자는 수정을 하고 돌려보고, 결국 만족하지는 않지만, 더 일하기는 싫어지는 상황까지 도달하면 상사에게 개발이 완료 되었다고 보고를 합니다. 마치 도량형도 없는 시대에 양팔 저울 위에서 눈 짐작으로 평형을 만드는 것 같은 작업 방식이지요.
몇 개월 후, 이런 식의 무한 반복 작업에 지친 개발자는 기획자에게 수치화 된 기획서를 요구하기 시작했습니다. 그리고 정확한 수치가 나올 때까지는 절대 코딩을 하지 않는다고 선언을 해버린 것이죠. 불만 가득한 개발자의 말도 안되는 투정같은 이야기 이지요. 일의 양은 변하지 않는 것이, 기획자가 문서 상으로 정확한 수치를 준 이후에도 그 문서가 계속 바뀐다는 것입니다. 기획자의 머리 속에서만 돌던것이 실제로 보면 다를테니까요. 당연한 이야기입니다. 그 누가 처음부터 ‘재미‘를 수치로 표현해 낼 수 있겠나요.
시간은 지났지만 첫번째의 무한 반복 개발 방법에서 좀 빠르게, 좀 느리게라고 표현되던 말이 2배, 0.5배가 되었을 뿐 할 일의 양은 서로 더 늘어났습니다. 오히려 기획자가 한번 보고 폐기될 문서만 양산하는데 시간이 오래 걸릴 뿐이었죠. 심지어는 얼마나 요구사항이 자주 바뀌던지 코딩 중에도 수차례 메신져가 띠링띠링하는 바람에 방해되니까 하루동안 바뀐 양을 업무 마감시간이 몰아서 달라고 할 정도였죠.
이런 삽질을 한 일년하고 나니까, 어떻게 하면 더 빠르게 기획자가 요구하는 사항을 프로그램에 반영할 수 있을까? 를 고민하게 되었습니다. 그나마 그 와중에 쌓인 스킬을 바탕으로 전반적인 프로그램의 아키텍쳐를 최대한 테스트를 빠르게 할 수 있고 변화가 쉽도록 구축 하도록 했습니다. 기획자가 원하는 숫자의 변경이라던지, 디자인 변경이라던지, 하는 것들을 점점 매크로화 시키고, 자동화 시켜가면서 기획자가 변화를 요구했을때 변화가 반영되어서 다시 피드백이 되기까지의 시간을 단축시켜 나가기 시작했습니다.
이러한 구조라던지, 보조적인 요소들을 극대화 시키니, 확실히 개발에는 가속도가 붙었습니다. 하지만, 만족할수는 없었습니다. 결국 이 부분은 개인적인 스킬의 발달이지 프로그램 개발 방법 전체를 뜯어고치지는 못했거든요. 여전히 기획서는 하루에도 수도 없이 변경되었고, 단지 예전에는 5시간 걸려서 수정된 기획서를 반영하던 것을 이제 1시간 걸려서 만들어 낸다는 것만 차이가 있었을 뿐입니다. 하지만, 같은 개발 기간에 조금 더 높은 퀄리티의 프로그램을 만들 수는 있었습니다. 테스트를 더 많이 해볼 수 있었거든요.
일년 반쯤의 시간이 지나고 이제 프로그래밍 스킬상의 문제가 거의 사라졌을 무렵, 다른 방법을 찾아보기로 마음 먹었습니다. 바로 기획자가 스스로 모든 것을 다 할 수 있는 환경을 최대한 만들어 주는 것이었죠. 일단 조그만 것 부터 시작했습니다. 게임 상의 모든 수치는 기획자가 스스로 변경해서 테스트 할 수 있도록 간단한 툴을 만들어 준 것입니다. 그러자 더 이상 주인공이 너무 빨리 죽는다거나, 데미지가 너무 약하다던가, 보너스를 더 주어야 한다던가 하는 기획자로부터의 요구사항이 사라졌습니다.
이러한 편리함에 효과를 본 저는 점점 더 많은 부분을 기획자에게 떠 넘기기 시작했습니다. 맵과 아이템을 디자인 할 수 있는 툴과 어플리케이션을 주고 기획자가 스스로 디자인한 스테이지에서 플레이 할 수 있도록 했습니다. 물론, 프로그래머의 간섭 없이 말이죠. 결국에 가서는 메뉴 구성 조차도 기획자가 직접 뜯어 고쳐가면서 플레이 할 수 있도록 만들어 버렸죠. 그러자, 더 이상 자잘한 요구들이 기획자로부터 넘어오는 일이 없었습니다. 기획자가 프로그래머에게 요구하는 일은 정말로 프로그래머가 아니면 안되는 일 뿐이었습니다.
이러한 본인 일거리 떠넘기기에 재미를 붙인 저는 심지어는 이미지를 교체하고 디스플레이 하는 위치를 정하는 것 조차 기획자에게 넘겨버리려고 했습니다만 생각해보니 그러면 “도대체 프로그래머는 하는일이 뭐야?”라는 비평을 들을 것과 몇몇 기술적인 문제 때문에 그 단계까지 가지는 않았습니다.
프로젝트가 시작하면 어서 빨리 이러한 툴들와 어플리케이션의 뼈대를 만든 후 기획자에게 던져버리고 저는 기획자로 부터 받을 수 있는 인풋이 제가 만든 프로그램 위에서 에러없이 플레이 되는 것을 보장하는 일과 프로그램 자체의 버그를 잡는 일에 집중했습니다. 물론 기획자 분은 왠지 일이 더 많아지고 바빠진 것 같다고 불평하셨지만, 그 것은 다름아니라 프로그래머에게 개선을 요구하고 업데이트 버젼이 돌아올 때까지의 기다리던 시간이 사라진 것이었죠.
이러한 일처리가 가능해지면서 프로그램은 훨씬 더 견고해졌고, 게임을 테스트하는 시간은 상대적으로 훨씬 더 증가했습니다. 2년이 되어가던 무렵에 시작했던 3개월짜리 프로젝트는 결국 그 마감시한을 지킬 수 있었고, 버그도 거의 없었지요. 이전까지 버그 투성이에 연장에 연장을 거듭하면 프로젝트들에 비하면 장족의 발전이었다고 할 수 있었습니다.
마지막으로 진행하려 했던 노력은 위의 프로젝트에 사용했던 툴들을 추후의 프로젝트에서 재사용할 수 있도록 가공하고 디자이너도 이 협력 프로젝트에 끌어들이는 것이지요. BREW 자체가 그리 복잡하지 않은 플랫폼인데다가, 늘 만드는 프로그램의 구조가 비슷했으므로, 유저 인터페이스를 모두 기획자가 직접 구성하게 하고, 이미지의 교체와 레이아웃의 변경 역시 디자이너가 직접 할 수 있게 하부의 구조와 툴을 제공하는 것이었죠. 물론 기존에 사용했던 컴포넌트들을 조금만 수정해서 구축이 가능하게 말이지요. 뭐, 간단히 말하면 기획쪽의 변경사항은 다 기획자가 직접하도록, 이미지쪽의 변경사항은 다 디자이너가 직접할 수 있도록 하는 환경을 제공하기만 하는 것이었습니다.
비록 퇴사로 인해서 초기 테스트 단계에서 멈췄지만 그때 생각했던 철학을 완성했으면 훨씬 더 잘 할 수 있었을 텐데라는 확신은 있습니다. 언젠가 다시 그런 쪽의 일을 하게 된다면 제로에서 시작하는 것보다는 잘 할 수 있겠지요. 물론 다른 선진화된 개발 과정을 가지고 있는 회사에서라면 더 나은 노하우로 놀랄만한 스피드로 개발을 하고들 있겠지요. 하지만 저는 누군가의 도움없이 이런 일들을 스스로 했다는 것에 대해서 나름대로 자부심을 가지고 있답니다.
(실은, 소프트웨어 공학 과목의 시험 공부를 하다가 예전 회사에 적용할 수 있는 수많은 학문적인 백그라운드를 보고는 울분에 차서 나도 나름대로 잘 했다고! 마음속으로 외치면서 쓴 글입니다. 이런 과목을 미리 공부 했었더라면 얼마나 좋았을까요. 2년 반의 삽질, 없어도 좋았을텐데;)
좋은 글 잘 읽었습니다. 🙂
좋은 글이라는 평가 감사드립니다~!
옛말따나, 백문이 불여일견입니다 ^^
학문적인 배경과 실무적인 지식 양쪽 모두 중요한 것 같습니다!
예전에.. 핸드폰 게임을 만들다가… OOP를 적용해보겠다고 잠시 설쳤었죠..( GVM 이었죠..) ..
OOP는 되었으나..너무나 느린 나머지..다시 날코딩으로 복귀한 아픈 기억이..-0-;;
C도 아닌 GVM으로 OOP는 정말 힘들게 보이네요;
잘 읽었습니다. 🙂
감사합니다~
소프트웨어 개발 방법론의 발전 역사를 ‘몸소’ 체험하셨네요 ^^;; 방법론에 대해 공부할 때에는 조금 불필요하거나 너무 거청하다는 생각을 많이 했습니다. 그런데, 실제 개발 도중에 많은 문제를 겪고 나니까 방법론 혹은 프로세스가 필요하다는 생각이 많이 듭니다. 요구사항 문서화, 프로토 타이핑, 프로그램 구조화, 아키텍처, 나선형 개발 방식, 변경 관리 등.. 이 모든 내용을 2년 동안에 압축적으로 경험하셨네요 ^^
예, 팀원과의 커뮤니케이션, Evolutionary Development 등의 학문적인 배경을 요즘에 와서 배우고서야 그 중요성을 알겠더라구요.
몸소 체험하신 체험으로 ‘상생’의 개발인생 되시길^^
사실 개발자라는 꿈은 살짝 노선변경을 했답니다~
글 잘 읽었습니다. 여러 개발론들을 자신의 업무에 맞게적용시키는것도 쉬운게 아니죠. 또한 함께 일하는 사람들에게 동의를 얻어 추진하는것도 중요한 능력이라고 생각합니다.
예, 저는 그나마 혼자 개발하는 입장이어서 기획자분만 설득하면 되어서 편하게 일을 진행할수 있었거든요.
대단하십니다. 단지, 그 말 밖에는. 그렇게라도 기획자를 설득하셨고, 일거리를 합리적으로 줄이셨다는데에 대한 뭐랄까.. 아무튼 정말 공감가는 글이었습니다.
개발자로서 짧은 시간에 최대의 효율을 내어야, 야근이 줄어든다는 법칙을 알았거든요;
100% 동감
감사합니다~
혼자서 기획하고,개발하고,디자인해야하는 환경에서는 그런 일이 발생하지 않기는 하지만.. 암튼 일을 좀 크게 벌릴려면 표준프로세스가 꼭 필요하다는데 공감합니다. 잘 읽었습니다.
예, 수십년간 학문으로 발전시켜온 밑바탕에는 그 필요성이 기반하고 있기 떄문이라고 생각합니다.
와~ 멋진데요… 웹기획에서도 가능할런지… 저도 수정사항을 개발자에게 넘기고 기다리는 시간이 정말 아깝다는 생각 많이 하거든요.
저는 개인단위로 수행할 수 있는 작은 규모의 프로젝트여서 손쉬웠지만, 더 대규모의 프로젝트라면 그렇게 간단하지만은 않을 것 같습니다.
좋은 글 잘봤습니다.
기획자에게 기획업무 이외에도 제작의 업무까지 주신 상황은.. 뭐랄까요.. 저는 조금 부정적으로 보고 있습니다.
이게 겨우 두번째 참여해보는 게임제작업무 이지만, 간단한 툴지원이야 당연하겠지만, 실질적인 제작까지 기획자가 부담하게되면, 비효율이 상당히 많이 늘어나게 됩니다.
기획 업무 시간이 그만큼 줄기 때문에 발생하는 퀄리티 저하도 피할 수 없는 문제가 되겠지요.
물론 플랫폼이 PC냐 모바일이냐의 차이가 있을수는 있겠지만, PC 온라인 게임을 기획/제작 해본 입장에서는 조금은 부정적인 시각입니다..
좀 더 솔직히 말해보자면, 기획자가 제작업무까지 참여해서 제대로 된 업무 기한을 맞춰본 적이 없었습니다. 기획팀의 인원만 비정상적으로 늘어나는 결과만 초래했지요.
회사의 운용능력 부족도 있었겠지만, 아무래도 기획자의 부담은 더욱 늘어나게 되고, 실제 기획보다는 제작에 더욱 많은 시간을 할애하게 되어, 밤샘 근무만 늘게되었습니다. 결국 기획할 시간에 제작하고, 남는 시간엔 기획한다.. 이런 것이었죠..
차라리 기획자가 좀 더 확실한 기획문서를 제시하도록 요구하는게 맞지 않나 싶네요 ‘-‘
네, 1.대단위의 프로젝트이고 2.참여인원 모두가 프로젝트가 지향하는 바를 정확하게 파악하고 있으며 3.완료 후 변경사항이 적은 프로젝트일 경우에는 Krose님은 접근 방식이 효율적입니다만, 제가 찾은 방식도 위와 같은 과정을 거쳐서 찾아낸 방편임을 이해 해주셨으면 합니다.
개발자 입장과 기획자 입장의 극명히 드러나는 생각의 차이일까요? ^^;
트랙백이 안되는 관계로 URL을 적습니다.
http://lepffm.springnote.com/pages/87123
Linus님의 의도는 기획자에게 부담을 늘리려는 의도였다기 보다는 단순한변경기능의 자동화나 기획에 대한빠른 피드백 장치를 제공한 측면으로 보면 좋을듯 합니다.
트랙백이 블로그 이외에서의 트랙백을 막아놓고 있었네요. 다시 풀었습니다~
잘 읽었습니다.^^
감사합니다~
lepffm :: 제가 글을 잘못 이해했을수도 있겠네요.
프로젝트를 진행하는 방식에는 각 회사마다 다른 방법들이 있겠지만, 적어도 기획자의 입장에서 제가 느껴본 바로는 기획자는 기획업무에서 선을 그어야 한다 였습니다.물론, 변경되는 수치를 기획자가 수정하며 직접 확인해볼 수 있는 툴을 제공해주는 정도라면 더할 나위 없겠지만, 제가 일을 하던 곳에서는 기획팀 인원이 개발팀 인원보다 많을 정도로, 기획팀에 제작에 참여했었던지라, 기획자가 제작을? 이라는 생각만해도 아니다! 라는 걸 알게되었습니다.
더 좋은 게임을 만들기 위해서야 뭔짓을 못하겠습니까만, 그래도 제작업무 때문에 못다한 기획업무를 2년간 밤새면서까지 하는건 아무래도 아닌 듯 싶었습니다 ^^;
네, 사실 어디까지가 기획에 관련된 것이고, 어디까지가 제작에 관련된 것인지는 명확하게 구분하기가 힘드네요.
좋은 경험을 하셨군요. 그런 상황에서 대부분의 사람은 그냥 투덜대지 개선을 할 생각을 하지 않습니다.
그리고 ‘도대체 프로그래머는 하는일이 뭐야?’ 라는 질문에는 이렇게 대답하고 싶군요.
그렇게 되면 프로그램 Core의 성능을 개선해야죠. 아니면 다른 문제를 해결하러 가거나.. ^^
프로그래머도 노력하는 자세로 끊임없이 파고들어가서 결국은 외부적으로 드러나는 단계까지 가서 인정받을수 있도록 자기계발을 꾸준히해야 하는 것이 아닌가 생각합니다.
어떤 문제를 근본적으로 해결하는 과정이라는 측면에서,
비단 개발자에만 국한되는 것이 아니라, 모든 직원에게 적용될 수 있는 부분인 것 같습니다. 우리 직원들한테도 얘기해줘야겠네요. ^^
감사합니다. 사실 먹고살기위한 부담도 없고, 학업의 연장이라는 측면에서 근무한것이 이런저런 시도를 해볼 수 있었던 밑바탕이었지요.
좋은 글 잘 읽었습니다. ^^
감사합니다~!
정말 좋은 글 잘 읽었습니다!!
정말 감사합니다~!
개발자를 꿈꾸는 사람중 하나로 좋은 글 잘 일었습니다.
부디 좋은 개발자가 되시는데에 조그만 도움이라도 되었으면 좋겠네요!
선배님~좋은 글 잘 읽었습니다.
소프트웨어 공학 수강 할 때는 별 생각 없었는데,
교수님들이 중요하다가 하신 이유가 다 있군요…^^
의외로 LG전자등에서 필수과목으로 지정해놨더라구요.
재미있는 경험담 잘 읽었습니다. 기획자도 보통은 개발자에 들어가는데 위 경험 자체가 일반적인 게임회사 풍경은 아니라서 다행이라는 생각이 드네요..^^
잘 읽고 갑니다~
감사합니ㄷ ㅏ~
글 잘 읽었습니다. ^^
도움이 되셨기를~
게임쪽엔 맵 에디터나 유닛등 툴을 먼저 만드는것으로 시작을 하죠. 그것을 몸소 체험하셨네요