마흔살 기획자 프로그래머 되다

이 글은 제가 지난 2012년, 무료 전자책으로 출간했던 내용입니다. 글을 쓸 때만해도 42세였는데 이제 47세가 되었네요. 세월이 워낙 빠르다는 것을 실감하게 됩니다. 당시 제가 게임 기획자로 일하다가 프로그래머로 변신하자, 어떤 식으로 공부했는지 물어 보시는 분들이 많았습니다. 이에 대한 대답으로 썼던 글이 바로 이 “마흔살 기획자 프로그래머 되다”입니다. 현재 사정상 앱스토어에서 전자책을 더 이상 보실 수가 없게 되어 이번에 이렇게 블로그에 공개하게 되었습니다. 다소 늦은 나이에 프로그래머로 변신했지만, 그래도 보람이 있어서 현재 저는 독일 베를린에 있는 게임 회사에서 시니어 게임 프로그래머로 일하고 있습니다. 너무 오래된 글이라 현재와는 맞지 않는 부분도 많지만 – 예를 들어 액션스크립트로 시작해 보라는 이야기 등 -, 그래도 큰 줄기에서는 참고하실 만한 내용이 많을 것이라 기대하면서 다시 글을 공개합니다.

마흔 살 기획자의 프로그래머 변신기

프롤로그

제가 1970년 생이니까 올해로 만 42세가 됩니다.(두 달 있으면 만 43세 ㅜㅜ) 저는 대학원에서 철학을 공부하던 중, 컴퓨터 게임의 매력에 빠져 26세라는 다소 늦은 나이로 게임 개발에 뛰어 들었습니다. 제가 처음 입사한 게임 회사는 미리내 소프트웨어라는 곳이었습니다. 제가 입사했을 때 회사의 주요 경력 개발자들의 나이는 대부분 20대 초반이었습니다. 비록 늦게 게임 개발을 시작했지만 그래도 여전히 20 대의 나이였기 때문에 저는 열심히 게임 기획을 공부하면서 경험을 쌓아 나갔습니다.

저는 패키지 게임과 온라인 게임(MMORPG), 그리고 웹 브라우저 기반의 소셜 게임에 이르기까지 다양한 게임 개발 경험을 가지고 있지만 대부분은 기획자와 프로젝트 매니저로서 일했던 경험입니다. 기획자로 일하는 동안 게임 프로그래밍을 어느 정도 할 줄 알면 도움이 될 것이라는 생각을 자주 했습니다. 그래서 20대부터 틈만 나면 C++ 책을 사서 공부할 의지를 불태웠습니다. 그러나 실제로 프로그래밍을 제대로 익히지는 못했습니다. C++책을 여러 권 사서 도전했지만, 한번도 끝까지 제대로 읽어 보지 못했습니다. 매번 포인터에서 막혀서 좌절하곤 했지요. C++이 제가 도전하기에는 너무 어렵다는 생각이 들어 배우기 쉽다는 비주얼 베이직이나 파이썬, 자바 스크립트로 계속 언어를 바꾸기도 했습니다. 하지만 결과는 마찬가지였습니다. 그러다보니 어느 새 30대 후반이 되어 있더군요. 그때 저는 프로그래밍을 익 히는 건 포기하고 기획과 프로젝트 매니저 일에만 전념하고 있었습니다.

프로그래밍 배우는 걸 포기해 버렸던 저에게 큰 변화가 일어난 것은 지난 2007년, 후배와 둘이서 작은 게임 회사를 시작한 것이 계기가 되었습니다. 2006년까지 많은 온라인 게임 회사를 다니면서 다양한 게임을 개발해 왔지만 항상 결과가 좋지 않았습니다. 이에 ‘다시는 온라인 게임을 만들지 않겠다’는 결심을 하고, 제 후배와 둘이서 싱글 게임 회사를 차렸습니다. (당시 후배와 저는 투자자들의 간섭을 받지 않고 우리 마음대로 게임을 만들어 보자는 생각을 했고, 그 결과 시간과 돈이 많이 드는 온라인 게임이 아닌, 작은 싱글 게임을 개발하기로 한 것입니다.) 그런데 저희가 싱글 게임 회사를 차렸던 지난 2007년에는 한국 시장에 이미 싱글 패키지 게임 유통사가 하나도 남아 있지 않았고, 거의 모든 게임업계 관계자들이 ‘게임 = 온라인 게임’이라고 생각하고 있는 상황이었습니다. 하지만 당시의 저는 빅 피쉬 게임즈(Big Fish Games)와 같은, 해외의 다운로드 게임 서비스가 급속히 성장하고 있는 것을 보았기에 한국에서도 싱글 게임이 다시 부활할 수 있을 것이라고 생각했습니다.

그런데 이런 결심을 이행하는 데에도 큰 문제가 있었습니다. 회사에 프로그래머가 없었기 때문입니다. 저는 기획자였고, 제 후배는 그래픽 전담이었습니다. 당시에 누구도 비전을 느끼지 못했던 싱글 게임 프로젝트를 위해 저희와 함께 할 프로그래머는 존재하지 않았고, 사실 저희도 돈이 없어서 프로그래머를 고용할 수가 없었습니다. 다행히 저희와 친분이 깊은 프로그래머가 굉장히 저렴한 인건비로 프로그래밍을 해 주었는데, 그 분은 일주일에 한번 회사를 와서 엔진과 클라이언트 쪽만 만들어 주었기 때문에 누군가가 콘텐츠 관련 코딩을 해야 할 상황이었습니다. 이에 제가 루아(LUA) 스크립팅을 익혀서 게임 스토리 진행과 관련된 부분을 직접 코딩하기로 하였습니다. 10여년 동안 프로그래밍을 배워 보려고 애만 쓰다가 결국 실패한 제가 다시 프로그래밍에 손을 대야 하는 상황이 왔던 것입니다.

제가 루아를 배우기 시작한 것은 회사 설립 다음 해인 2008년부터입니다. 만 38세, 우리 나이로 39세였던 것이죠. 이 때 저는 루아를 약간 배워서 기초적인 스토리 진행 스크립트 정도는 짤 수 있는 정도가 되 었습니다. 하지만 제가 할 수 있는 부분은 극히 제한적이었고, 일주일에 한번 오는 프로그래머분의 도움이 없으면 새로운 어떤 기능도 만들어 넣을 수가 없었습니다. 반쪽 짜리 프로그래머도 안되었던 것이죠.
그리고 우여곡절 끝에 첫번 째 게임이 완성되었고, 그 프로그래머분의 도움도 끝이 났습니다. 다시 회사에는 후배와 저, 두 사람만 남게 된 것입니다.

저희의 첫번 째 게임은 많은 고생에도 불구하고 몇 카피 팔리지 않았습니다. 저희 돈으로 직접 찍어낸 게임 CD 1000장을 사무실 한쪽에 쌓아 둔 채, 저희는 다음 단계에 무엇을 해야 할 지 고민했습니다. 이제 더 이상 저희를 도와 줄 프로그래머도 없었고, 제가 할 줄 아는 것은 가장 기초적인 수준의 루아스크립팅에 불과했습니다. 할 수 없이 먼저 만들었던 게임 클라이언트를 재활용, 그래픽 자원과 스토리 진행 스크 립트만 바꿔서 다른 작품을 두 개나 더 만들었습니다. 하지만 첫번 째 게임의 CD가 먼지 구덩이 속에 처 박혀 있는 상황에서 새로 만든 게임들을 CD로 또 찍어낼 용기는 없었습니다. 그 후 다운로드 판매 서비스 회사와 계약을 맺고 ‘다음 게임’, ‘넷마블’ 같은 포털에 게임을 올려 놓는데 성공했지만, 그래 봐야 한 달 매출이 2~3만원도 안되었습니다. 회사를 처음 시작할 때 싱글 게임 만드는 것은 미친 짓이라고 주변 사람들이 말렸었는데, 그 말처럼 된 것이었죠. CD를 만들어서 오프라인에서 파는 것은 애당초 불가능한 일이었고, 제가 기대했던 다운로드 판매 서비스도 국내 시장은 그 규모가 너무 작았습니다.

다음에는 뭘 해야 하나? 하는 고민을 하고 있던 우리에게 닥친 가장 큰 문제는 역시 프로그래머 부재였습니다. 여전히 제가 할 줄 아는 것은 간단한 스크립트 작성 뿐이었고, 진짜 프로그래머의 도움이 없으면 제가 할 수 있는 일은 거의 없었습니다. 그렇게 허탈한 기분에 빠져서 며칠을 보내던 제게 이 상황을 헤쳐 나갈 놀라운 아이디어가 떠 올랐습니다. 그건 바로 “내가 프로그래머가 되면 되잖아!”라는 생각이었습니다. 그날 이후 저는 프로그래머가 되기 위해 앞으로 설명 드릴 다양한 노력을 하게 됩니다.

마음가짐과 방법

기획자가 프로그래밍을 배울 때 제일 문제가 되는 것은 역시 마음가짐일 것입니다. 아무래도 본업이 기획이다보니 절실함이 부족하게 되죠. 제가 과거 수 차례 프로그래밍에 도전했다가 실패했던 것도 그 때문인 것 같습니다. 그러다가 ‘내가 하지 않으면 안되는 상황’이 되자 그 불가능해 보였던 프로그래밍이 가능해졌는데, 돌이켜 보면 결국 절실함이 문제였던 것 같습니다.

프로그래밍을 처음 공부하는 기획자는 처음의 의욕과 달리 진도가 잘 안 나가는 경험을 하게 됩니다. 분명히 알고 넘어간 것 같은데 조금 지나면 첫 부분에서 공부한 게 생각이 안나곤 하니까요. 그러다보면 점점 프로그래밍 책을 넘기는 속도가 느려지기 시작하다가 끝내는 이런 생각이 듭니다.

“에휴, 내가 지금부터 프로그래밍 배워서 언제 프로그래머처럼 되겠냐. 이거 할 시간에 기획이나 더 열심 히 하는 게 낫겠다”

이건 제가 수 차례 경험한 것이고, 얼마 전 우연히 알게된 기획자 한 분도 비슷한 경험을 했다고 하시더 군요. 게임 프로그래밍을 제대로 하려면 상당한 수준에 도달해야 할 것 같은데, 이제 기초 부분에서 허덕이고 있으니 앞으로 가야할 길이 까마득하게 멀리 느껴지는 것은 당연합니다. 이 때문에 처음의 의욕은 온데간데 없이 사라지고, ‘그냥 내가 더 잘 하는 일에 집중하자’는 생각이 드는 것이죠. 뭐, 이런 생각이 틀린 것은 아닙니다. 프로그래밍을 전혀 못한다고 게임 기획을 못하는 건 아니거든요. 하지만 프로그래밍을 공부하겠다고 결심한 기획자에게 이런 생각이 들면 굉장히 어려운 상황이 시작됩니다. 의지가 꺾여 버리기 때문입니다.

저의 경우도, 이런 상황을 처음에는 극복하지 못했습니다. 그래서 여러 번 중도 포기한 것이죠. 하지만 39세의 나이로 프로그래밍을 다시 공부하기 시작했을 때는 이 상황을 결국 극복해 냈습니다. 그 이유는 다 음의 두 가지 때문이 아니었을까 합니다.

1. 절실함의 수준이 달랐다.
2. 효과적인 방식으로 공부했다.

절실함의 수준이 달랐다.

앞의 프롤로그에서도 쓴 바가 있지만, 제가 프로그래머가 되어야겠다고 결심했을 때는 회사에 프로그래머가 한명도 없었습니다. 따라서 프로그래머로의 변신은 제가 반드시 해 내야만 하는 과제였습니다. 사실상 ‘퇴로가 없는 상황’이었던 것이죠. 과거에는, 하다가 안되면 다시 익숙한 기획자의 길로 되돌아갈 수 있었지만 이 때는 그게 불가능했습니다.

물론 프로그래밍을 배우기 위해 모든 기획자들이 저와 같은 상황에 처해야 하는 것은 아닙니다. 하지만 인간의 의지라는 게 희한해서, 퇴로가 있는 경우와 없는 경우는 의지의 강도가 확실히 달라지더군요. 따라서 저와 같이 극단적인 상황이 아니더라도 각자 자신의 방식으로 퇴로를 차단하고 도전해 보시라 말씀 드리고 싶습니다. 주변 사람들에게 호언장담을 해도 되고, 벌금을 걸어도 되겠죠. 어쨌건 중간에 쉽게 그만 둘 수 없는 객관적 상황을 만들어 두시면 의지가 다소 약해지더라도 마음을 다시 잡을 가능성이 조금 은 높아질 것입니다.

효과적인 방식으로 공부했다.

사실 제 성공(?)의 결정적 이유는 이것입니다. 의지가 아무리 강하다고 해도 진도가 안나가면 프로그래밍을 끝내 익힐 수 없을 것입니다. 어쨌건 진도가 나가야 합니다. 과거, 제가 실패했던 이유는 ‘진도가 안 나가는 방식’으로 공부했기 때문입니다. 진도가 안나가니 번번이 좌절하게 되었고, 조급한 마음이 강해지면서 끝내 포기하게 된 것입니다. 따라서 효과적인 방법으로 공부하는 것이 가장 중요합니다. 그럼 제가 어떤 식으로 공부하였는지 지금부터 차근차근 설명해 보겠습니다.

입문 단계 통과하기

액션스크립트 3.0을 선택한 이유

제가 프로그래머가 되기로 하고 처음 선택한 언어가 액션스크립트3.0이었습니다. 싱글 패키지 게임을 개발했으나 판매를 제대로 못하고 있던 저는 당시 해외에서 웹 브라우저 기반 게임이 급성장하고 있는 것을 발견하고, 돌파구는 웹 브라우저에서 바로 플레이할 수 있는 게임을 만드는 데에 있다고 생각했습니다.

이에 저는 웹 브라우저에서 바로 실행할 수 있는 게임을 만들기 위해 무엇을 공부할까 고민했습니다. 당시에는 플래시의 뒤를 실버라이트가 뒤쫓고 있던 상황이었는데, 실버라이트와 플래시 양자를 놓고 고민 하다가 그래도 훨씬 많은 인스톨 베이스(install base)를 기록하고 있는 플래시를 선택하기로 한 것입니다.

돌이켜보면 제가 플래시 액션 스크립트 3.0을 선택한 것은 대단히 운이 좋았습니다. 이후 페이스북 게임이 폭발적인 인기를 끌면서 액션스크립트의 위상이 높아지기도 했지만, 기본적으로 액션스크립트 3.0에 익숙해지면 다른 언어를 배우는 데에도 상당히 많은 도움이 되기 때문입니다. 저는 나중에 액션스크립트 외에도 자바스크립트, C# (둘 다 유니티 3D의 스크립트 언어로 쓰입니다)를 공부했는데, 자바(JAVA)까지 포함해서 이 네가지 언어들은 일종의 사촌 형제처럼 매우 비슷한 스타일로 되어 있습니다. 따라서 액션 스크립트 하나를 잘 익혀 놓으면 다른 언어를 큰 어려움 없이 배울 수 있습니다.

책 선택과 공부 방법에 대해

지금은 액션스크립트 3.0 에 대한 좋은 책이 많이 나와 있지만, 당시에는 제가 참고할만한 국내 책이 마땅치 않았습니다. 특히 게임 만드는 법과 관련한 액션스크립트 3.0 책은 찾아보기 어려웠지요. 이 때문에 저는 어쩔 수 없이 외국책을 교재로 썼습니다.(지금 같으면 번역된 책을 봤을텐데요 ㅜㅜ)

이 때 제가 선택한 책은 “ActionScript 3.0 Game Programming University” 라는 책이었습니다. 지금은 더 체계적이고 좋은 책이 많이 나와 있지만(번역도 많이 되었죠) 당시에는 이 책만한 게 없었습니다. 저는 이 책을 가지고 제가 과거, 프로그래밍에 도전했다가 실패했을 때와는 완전히 다른 방식으로 공부했는데, 돌이켜 보면 그것이 성공 원인이 아니었나 합니다.

과거, 제가 프로그래밍을 공부하다가 실패했을 때는 다음과 같은 패턴이었습니다.

1. 새 책을 펼쳐 들고 의욕적으로 읽어 나간다.
2. 예제 코드가 나오면 책을 보면서 일일이 타이핑하고 실행해 본다.
3. 실행이 잘 되는 것을 확인하고 나면 다음 부분을 읽어 나간다.
4. 코드가 나오면 다시 타이핑하고 실행한다.
5. 그런데 책을 읽을 수록 점점 어려워지고, 분명히 제대로 보고 타이핑한 것 같은데 에러가 난다.
6. 에러의 원인을 못 찾겠다. 찜찜하지만 진도를 좀 더 나가 본다.
7. 새 코드가 나왔는데 타이핑하다 보니 무슨 내용인지 잘 모르겠다. 코드 양도 많아서 타이핑하다가 오타가 자꾸 난다.
8. 점점 더 모르겠다. 책 보고 그대로 따라 쳐도 자꾸 에러가 난다.
9. “내가 뭐 하고 있는 거지… 프로그래밍은 너무 어려워. 내가 이제부터 프로그래밍 해서 언제 따라가겠어. 그냥 그 시간에 기획이나 더 공부하자” 는 생각이 든다.
10.포기한다.

그런데, 이번에는 방법을 달리 했습니다. 과거 위와 같은 패턴을 여러 번 반복한 지라 본능적으로 방법을 바꾸었던 것인지 모릅니다. 이번에는 이런 식으로 했습니다.

1. 책을 읽는다. 컴퓨터 책상 앞에서는 읽지 않는다. 버스나 지하철, 커피샵 같은 데에서 읽는다.
2. 읽다가 이해가 안되는 부분이 나오면, 잠시 생각해 보다가 그냥 계속 읽는다.
3. 이해가 안 가도 읽는다. 그냥 끝까지 읽는다. 도저히 모르겠으면 그 부분은 대충 눈으로 흝어 보고 그냥 진도 나간다.
4. 책을 끝까지 읽었다. 진도는 나갔는데 아직 잘 모르겠다.
5. 책을 처음부터 다시 읽는다. 이번에도 눈과 머리로만 읽는다.
6. 첫번 째 읽었을 때보다는 이해가 잘 되는 편인데, 그래도 잘 이해가 안되는 부분이 많다. 그래도 읽는다.
7. 끝까지 읽었다. 두 번 읽었다.
8. 책을 처음부터 다시 읽는다. 이번에는 잘 읽힌다. 전에 이해 안 가던 것도 대충은 알 것 같다. 그래도 모르는 부분이 있지만, 어쨌건 끝까지 읽는다.
9. 끝까지 다 읽었다. 전보다 훨씬 빨리 읽었다. 이해 안 가는 부분이 아직도 있지만, 그래도 어떤 내용이 책의 어느 부분에 적혀 있는지는 거의 다 알겠다. 아주 어려운 부분 말고는 대충 다 알 것 같다.

위와 같이 이해가 되건 안되건 무조건 끝까지 3번을 읽었습니다. 처음에는 진도 나가기가 힘듭니다. 하지만 예제 코드를 일일이 다 치다가 진도 못나가는 상황보다는 덜 힘듭니다. 그냥 눈으로만 읽는 거라서 훨씬 덜 지치거든요. 읽다가 모르는 부분은 그냥 넘어갑니다. 대충 눈으로 흝어 보기만 해도 됩니다. 이해를 못하더라도 1단계에서는 “책을 끝까지 읽는 게” 가장 중요합니다. 이해 못해도 상관 없습니다. 한번 더 읽으면 되거든요.

두번 째 읽을 때는 좀 수월합니다. 일단 끝까지 읽은 터라 다시 읽어 보면 전에 이해 안되던 부분도 신기하게 이해되는 경험을 할 수 있습니다. 물론 이건 앞 부분이고 뒤로 가면 여전히 이해가 안됩니다. 그래도 계속 읽습니다. 모르면 한 번 더 읽으면 된다는 생각으로 읽으면 되니까요. 아마 첫번 째 읽을 때보다 절반 이하의 시간이 걸릴 겁니다.

세번 째는 훨씬 쉽습니다. 쭉 읽다 보면 아주 어려운 부분도 ‘전혀 모르겠다’에서 ‘알 듯 모를 듯하다’로 바뀝니다. 이번에는 두 번째 읽을 때보다도 훨씬 진도가 빨리 나갑니다. 읽다 보면 쉬운 부분은 당장이라도 짤 수 있을 것 같은 자신감이 듭니다.

이렇게 세 번을 읽은 다음 네 번, 다섯 번 반복해도 되겠지만, 저는 세 번까지만 읽었습니다. 세번 정도 읽으면 코딩을 직접 해 보고 싶어서 몸이 근질거리거든요. 이렇게 몸이 근질거려서 참을 수 없을 때 코딩을 시작해야 합니다. 이제 컴퓨터 앞에 앉아서 공부를 시작하는 단계에 들어갑니다.

첫 코딩은 상상할 수 있는 간단한 프로그래밍으로 시작합니다. 예를 들어 “화면에 텍스트와 버튼을 하나 그려 놓고, 버튼을 누르면 텍스트의 내용이 바뀌게 해 보자” 와 같은 식으로 목표를 정합니다. 그리고는 자신이 그동안 책으로 익힌 프로그래밍 실력을 이용해서 “순전히 자기 힘으로” 짜 보는 것입니다.

그런데 막상 코딩을 하려고 보면 머리가 하얘집니다. 분명히 책을 읽을 때는 다 아는 것 같았는데, 막상 책 없이 코드를 짜려고 하면 막막해지는 것이죠. 화면에 텍스트를 표시하려면 어떻게 해야 했지? TextField() 함수를 써야 했던가? 버튼은 무엇으로 만들더라? 막 헷갈리기 시작합니다. 그래도 일단 되는대로 짜 봅니다. 아마 잘 안되고 에러가 날 겁니다. 점점 더 방법이 궁금해 집니다. 내 머리가 이렇게 나빴나 하면서 머리도 쥐어 뜯게 됩니다. 이 상태가 되면 머리가 궁금증으로 가득차게 되는 데 이 때 책을 펼쳐 궁금한 부분을 찾아 봅니다. 이미 책을 세 번이 나 읽었기 때문에 내가 궁금해 하는 부분이 어디에 설명되어 있는지 금새 찾을 수 있습니다. 그리고 책을 보면 머릿속이 환해지는 것을 느끼게 됩니다. 에이, 간단한 거였는데…

이런 식으로 간단한 프로그램을 자기 힘으로 짜 보면서 모르는 것을 책에서 뒤져 보고 하다 보면 조금씩 프로그래밍에 익숙해지고 재미도 붙습니다. 이 때 가급적이면 두번 째 프로그램은 첫번 째 프로그램에서 조금 더 발전 시키는 식으로 짜면 좋습니다. 예를 들어 첫번 째 프로그램이 “버튼을 누르면 화면에 텍스트가 바뀌는 기능”을 가지고 있었다면 두 번째 프로그램은 “화면에 랜덤으로 두 개의 숫자가 나오고, 더하기 버튼을 누르면 두 숫자를 더한 값이, 곱하기 버튼을 누르면 두 숫자를 곱한 값이 나오게 해 보자”는 식으로 접근하는 것입니다. 단 첫번 째 프로그램에서 두 번 째 프로그램으로 넘어갈 때는 첫번 째 프로그 램의 코드를 수정, 개선하는 식으로 짜지 말고 처음부터 새로 다시 짜는 게 좋습니다. 그렇게 새로 짜면, 텍스트를 표시하고 버튼을 만드는 기능(첫번 째 프로그램의 핵심 기능) 정도는 완전히 복습되거든요.

앞에서 설명한 방식으로 간단한 프로그램 개발 목표를 정하고, 내 지식과 참고 자료(책이나 인터넷)를 이용해서 목표한 기능을 구현하는 방식으로 프로그램을 짜다 보면 점점 코딩이 재미있어집니다. 공부라기 보다는 코드를 가지고 노는 것에 가깝습니다. 이렇게 해서 코딩에 어느 정도 익숙해지면 조금 복잡한 프로그램에 도전해 봅니다. 이 단계에서 실력이 크게 성장하게 되는데, 저의 경우에는 다음과 같은 프로그램을 목표로 도전해 보았습니다.

“화면에 유명한 화가의 그림 이미지를 띄워 보여 주고, 화가의 이름이나 그림의 제목을 맞추는 프로그램을 만들어 보자. 문제는 총 30개 중에서 랜덤으로 10문제가 나오고, 문제를 다 맞추면 점수를 보여 준다”

이건 앞에서 코드를 가지고 노는 수준이 아니고 나름 하나의 완벽한 퀴즈 게임입니다. 저의 경우 좀 막막해 보이지만 자신이 없는 것은 아니었습니다. 왜냐 하면 제가 읽은 책 안에 퀴즈 게임과 그림 퍼즐 게임 예제가 있었기 때문입니다. 뭐, 짜는 법은 몰랐지만요…

여하튼 이런 식의 도전 과제를 해결해 봅니다. 가지고 있는 지식을 총 동원하고 모르면 책을 뒤져 가면서 어떻게 하든 스스로의 힘으로 짜 봅니다. 처음에는 머리에 쥐가 날 지도 모릅니다. 하지만 신기하게 하나씩 해결됩니다. 버그도 속출할 것인데, 하나씩 찾아내면서 버그 잡는 방법도 몸에 익히게 됩니다. 그리고 아마 어지간한 돌머리가 아니면 결국 다 짜게 될 겁니다.^^ 엄청난 성취감! 가족이나 주변 사람들에게 보여 주고 칭찬도 받습니다.

자 이제 좀 어려운 프로그램도 짰습니다. 다음에는 무엇을 할까요? 좀 더 어려운 프로그램에 도전하는 게 맞을까요? 그런데 절대 그러시면 안됩니다. 이 단계가 중요합니다. 저의 프로그래밍 실력이 일취월장 한 건 이 단계였거든요. 저는 어떻게 했냐구요? 저는 앞의 “그림 퀴즈 프로그램”을 처음부터 다시 새로 짜 보았습니다. 그것도 4번이나 다시요.

첫번 째 짠 프로그램의 코드를 들여다 봅니다. 물론 프로그램은 잘 돌아갑니다. 하지만 코드를 보면 엉망 진창입니다. 그리고 무엇보다 코드의 양이 엄청나게 많을 것입니다. 코드를 짜기 전에 모르는 게 너무 많았고, 코드를 짜는 과정에서 새로운 것을 많이 배워서 적용했기 때문입니다. 이제 앞에서 짠 코드는 무시 하고 새로 “퀴즈 게임”을 처음부터 다시 짭니다. 물론 그림이랑 퀴즈 데이터는 재활용해야겠지요. 자원은 재활용하되 코드를 처음부터 다시 짭니다. 이번에는 첫번 째 짤 때보다 더 수월할 겁니다. 첫번 째로 프로그램을 짜는 과정에서 많은 것을 새로 배웠으니까요. 자, 두 번째 프로그램이 완성되면 첫번 째 코드와 비교해 보세요. 코드가 좀 더 정돈된 것은 물론이고 아마 코드의 양이 많이 줄어 있을 것입니다. 이게 다 경험이고 노하우입니다. 내친 김에 기능 한 두개 더 넣으셔도 되구요 ^^

자 이제 두번 째 “그림 퀴즈” 프로그램을 짰으니 다시 한번 “그림 퀴즈”를 짤 차례입니다. 이번에도 처음 부터 다시 짭니다. 전보다 훨씬 빠르게 짤 수 있고, 코드의 양은 첫번 째에 비해 획기적으로 줄어들어 있을 것입니다. 저는 이런 식으로 네 번을 반복해서 짜면서 정말 많은 것을 배웠습니다. 버그 찾아내는 법. 반복적으로 사용하는 코드를 함수를 이용해서 한번만 타이핑하는 법 등, 코딩에 익숙해질 수록 점점 더 프로그램에 익숙해지는 것을 느낄 수 있었습니다.

코딩은 이런 식으로 익혀 나가면 됩니다. 목표를 정하고, 내가 아는 지식과 참고 서적, 인터넷을 뒤져가며 목표를 달성해 나가는 것입니다. (액션스크립트 3.0의 경우 워낙 많은 프로그래머들이 사용하고 있기 때문에, 문제가 생겼을 때 구글링을 통해 해결 안되는 경우가 거의 없습니다. )

그런데 이 단계에서 병행해야 할 것이 또 있습니다. 컴퓨터 앞에서는 앞에서 말씀 드린 방법으로 계속 실력을 키워가되, 버스, 커피샵, 지하철에서는 책을 다시 읽어야 합니다. 아까 세 번 읽었으니 이제 네번, 다섯 번 읽습니다. 이제 정말로 책이 머리에 쏙쏙 들어옵니다. 왜냐하면 컴퓨터 앞에서 직접 내 힘으로 코딩을 하고 있기 때문에 머릿속에 문제의식이 가득차 있기 때문입니다. 이전에는 책을 그냥 읽었을 뿐이었지만, 이제는 무릎을 탁 치면서 읽게 됩니다. “아! 여기에 이런 내용이 있었구나. 내가 이걸 몰라서 코딩하다가 그 난리를 친 거였군! 다음에는 이런 식으로 짜면 되겠네” 라는 말이 입에서 절로 나오게 되는 것입니다.

자, 이제 입문 단계가 끝났습니다.

성장단계

액션 스크립트 3.0 에 어느 정도 익숙해지자, 저는 함께 회사를 하던 후배에게 이제 간단한 프로그램은 내가 짤 수 있다고 이야기했습니다. 제 실력이 아직까지는 초보 수준이라 복잡한 것은 짜기 힘들었지만 퀴즈나 퍼즐 같은 것은 짤 수 있으니 교육용 소프트웨어를 만들어 보자고 했습니다. 그래서 후배와 함께 세계 지도 퍼즐 맞추기 프로젝트를 시작했습니다. 후배가 세계지도를 국가별로 조각내어 저에게 조각 그림을 주면 그걸 원래의 위치에 맞추는 일종의 직소퍼즐 같은 교육용 앱에 도전한 것이죠. 처음 짜 보는 것이기는 했지만 저에게는 인터넷이라는 든든한 선생님이 있었기 때문에 모르는 것은 구글링을 통해 해결하면서 프로그램을 완성해 갔습니다. 시간은 좀 걸렸지만 노하우가 조금씩 쌓여가는 단계였죠. 분명히 이 단계에서 저는 계속 성장해 갔지만, 급격한 수준 향상이 이루어진 것은 아니었습니다. 저는 여전히 초급 단계였고, 성장은 제 자신의 한계 내에서 조금씩 이루어질 뿐이었습니다. 중급 단계로 올라가기 위해서는 무엇인가 다른 계기가 필요했는데 어느 날 저에게 두 번의 도약 기회가 찾아왔습니다.

5일만에 게임 완성해서 납품하기

야심차게 만든 첫번 째 게임은 안팔리고, 돈은 없고 해서 저희는 정부지원사업이나 용역 프로젝트에 손을 대기 시작했습니다. 그러던 중 교육용 게임을 플래시로 만드는 용역을 하나 맡게 되었는데, 어쩌다 보니 납품 5일전이 되어서야 일을 시작할 수밖에 없는 상황이 되어 버렸습니다. 그래픽 자원들은 이미 나와 있었고, 제가 액션스크립트로 코딩을 해서 완성해야 하는데, 시간이 부족했습니다. 즉, 5일간 정말 초인적인 스피드와 집중력으로 게임을 만들어야 하는 상황을 맞이하게 된 것입니다. 이 5일이라는 기간 동안 저는 잠을 하루에 두 세 시간 정도 자고 나머지 시간은 코딩만 하는 경험을 하게 되었습니다. 다른 프로그래머들은 젊은 나이에 다들 경험해 본다는 크런치 모드를 나이 마흔이 다 되어 제대로 경험해 본 것 입니다. 3일 정도는 어찌 버텼는데 4일 째가 되니 정신이 완전 몽롱하더군요. 작성한 코드의 양도 어마 어마했구요. (사실 당시에는 제가 클래스 사용을 자유자재로 못해서 코드가 지저분하고 엉망이었습니다). 그런데 그 복잡한 코드 속에서도 길이 보이더군요. 분명히 잠이 부족해서 정신은 몽롱한데 막판 되니까 처음 만들어 보는 기능도 한번에 짜지는 것이었습니다. 결국 5일만에 프로그램을 다 완성해서 납품을 무사히 마쳤습니다.

이 크런치 모드가 너무 고통스러워서 앞으로는 어떤 프로젝트에서도 크런치 모드에는 돌입하지 않도록 해야겠다고 결심하게 되었지만, 돌이켜보면 이 때 제 프로그래밍 실력이 한 단계 업그레이드된 것은 분 명했습니다. “어떤 프로그램을 엄청난 집중력으로 단 기간에 짜 보는” 이 경험이 저에게는 의도된 것이 아니었지만, 어쨌건 이 짧은 기간 동안 저의 실력은 크게 향상되었습니다. 이 때문에 저는 초급 단계를 벗어나고 싶다면 이런 경험을 한 번씩 해 보시라고 권하고 싶습니다. 함께 공부하는 사람들과 팀을 짜서 게임이나 대회 형식으로 해도 될 것입니다. 중요한 것은 시간(데드라인)을 정해 놓고 그 시간 내에 목표 한 프로그램을 완수하는 것입니다. 아마도 이런 집중적인 단련의 시간을 거치게 되면 급속히 실력이 향상된 자신을 볼 수 있을 것입니다.

고수의 코드를 들여다 보다

5일간의 크런치 모드를 거치면서 클래스 사용에도 익숙해졌고, 이제 웬만한 프로그램은 짤 수 있겠다는 생각이 들었습니다. 그 후에도 저는 프로그래밍을 계속 했는데, 후배와 함께 하던 회사가 다른 분들에게 인수되어 저는 좀 더 큰 회사 안으로 들어가게 되었습니다.(엄밀히 따지면 회사는 그대로였고 인수 후 회사의 이름이 바뀌고 규모가 커진 것이었죠) 새로운 회사에서는 웹 브라우저 기반 소셜 게임 개발 프로젝트에 투입되었습니다. 그런데 이 프로젝트에서 회사가 저에게 원한 역할은 프로젝트 매니저(PM)였습니 다. 한참 프로그래밍에 재미가 붙은 상황이었기 때문에 저에게는 아쉬운 일이었습니다. 이에 회사에서는 프로젝트 매니저로 일하고 퇴근 후 집에서는 프로그래밍을 계속 하는 식으로 지냈습니다. (저는 이 기간 동안 코로나 SDK라는 상업용 개발툴을 이용하여 아이폰과 안드로이드폰 앱 개발에 도전하기 시작했습 니다. 이에 대해서는 뒤에서 다시 이야기하겠습니다.)

그러던 중 첫번 째 소셜 게임이 나왔습니다. 그리고 소셜 게임 프로젝트가 끝난 뒤 저에게 프로그래머로 일할 기회가 다시 찾아 왔습니다. 게임업계에도 잘 알려진 회사 내의 최고수 프로그래머가 저에게 플래시 MMORPG를 함께 만들지 않겠느냐고 제안한 것이었습니다. 저는 바로 승낙을 했고 이 때부터 두 명 이 골방에서 함께 프로젝트를 시작했습니다. 이 때 제가 맡은 것은 초기 기획과(원래 전 기획자 출신^^) 인터페이스 프로그래밍이었습니다. 이렇게 해서 일년간 이 프로젝트를 진행했는데, 이 과정에서 저는 프로그래머 경력 20년이 넘는(이 분은 고등학교 시절부터 게임 프로그래머로 유명했음) 경험 많은 게임 프로그래머의 코드를 들여다 볼 수 있게 되었습니다. 액션스크립트는 분명히 제가 먼저 공부했음에도 불구하고, 이 분이 작성한 코드에는 제가 이해할 수 없는 부분이 많았습니다. 왜냐하면 이 분은 액션 스크립트 코드를 C++ 게임 코드처럼 짰기 때문입니다. 제가 읽은 어떤 책에도 나오지 않는 방식이라 한편으로는 놀라우면서도 이해하기 어려워 힘들었는데, 어쨌건 저에게는 엄청난 기회가 찾아 온 것이었습니다. 저보다 몇 단계 높은 수준의 코드를 일년 동안 들여다 볼 수 있었기 때문입니다. 이 기간 동안 저는 모르는 것은 물어보기도 하고, 물어보기 애매한 것은 스스로 연구해 가면서 보냈는데, 그 노력 덕분인지 일년 정도 지나자 그 분의 코드가 어떤 원리로 작성된 것인지 대부분 이해할 수 있게 되었습니다.(물론 그대로 처음부터 짜 보라고 하면 못 짭니다) 제가 회사를 그만 둔 뒤에는 액션 스크립트에서 손 떼고 루아와 C#만 만지고 있지만, 그래도 그 때 그 고수의 코드를 들여다 보면서 배운 것은 머리에 남아 저에게 큰 도움 이 되었습니다. 어떤 경우에는 퇴사 후 1년이 지난 지금 유니티 스크립트 프로그래밍을 하는 과정에서 ‘아 이게 그 때 그거였구나!”하고 비로소 깨닫기도 합니다.

만약 이 시기에 나보다 수준 높은 코드를 들여다 볼 기회를 얻지 못했다면, 아마 저의 성장은 많이 정체 되었을 것입니다. 혼자서 책만 보고 배우다보면 점진적인 성장은 가능하겠지만, 제가 경험한 것과 같은 단기간의 도약은 쉽지 않습니다. 왜냐하면 성장을 위해서는 새로운 것에 대한 궁금증과 의문이 있어야 하는데, 혼자 공부하는 가운데 생기는 궁금증은 상당히 제한적이기 때문입니다. 이와 달리 저는, 저보다 훨씬 높은 수준에 있는 프로그래머와 함께 일하는 과정에서 과거에 가져 보지 못한 새로운 궁금증을 갖게 되었고, 그 궁금증을 해결하는 과정에서 전에 없던 급격한 성장이 이루어졌던 것입니다. (개인적으로 저는 이 단계를 거치면서 ‘이제는 나도 어디 가서 프로그래머라고 말해도 되겠다’는 생각을 하게 되었습니다. ^^) 여러분도 어느 순간 성장이 정체되었다는 느낌이 든다면 자기보다 뛰어난 수준의 프로그래머 코드를 들여다 보거나, 그들과 교류하시기 바랍니다. 게임 회사에서 일하고 계시다면 주변에 그런 프로그래머가 널려 있을 테니까요. (안되면 인터넷도 있습니다)

코로나 SDK와 함께 1인 앱 개발을 시작하다

iOS용 게임 개발은 아이폰 앱스토어의 등장 이래 제가 항상 꿈꾸던 것이었습니다. 하지만 아직 액션스크립트도 능숙하게 사용하지 못하던 저는, 더 복잡해 보이는 오브젝티브-C를 공부할 엄두를 내지 못했습니다. 그러던 중 제가 일하던 회사가 인수되고, 좀 안정적인 생활을 하게 되자 저는 퇴근 이후 집에서 iOS 용 게임 개발에 도전해 보기로 하였습니다. 일단 오브젝티브-C 책을 사서 무작정 읽었는데, 생소한 부분이 많아서 막막한 감이 들었습니다. 그러던 중 우연히 인터넷에서 오브젝티브-C를 사용하지 않고 오로지 루아 (LUA)를 이용해서 아이폰과 안드로이드폰용 앱을 개발할 수 있는 방법이 있다는 글을 읽었습니다. 루아 는 제가 익숙하지는 않아도 예전에 싱글 게임을 개발할 때 조금이나마 만져 본 경험이 있었기 때문에 무척 반가운 소식이었지요. 이에 링크를 찾아 들어가서 발견한 것이 바로 코로나 SDK(Corona SDK)였 습니다. 지금 코로나 SDK는 굉장히 많은 발전을 이루어서, 이것으로 만들지 못할 앱이 별로 없다고 할 정도가 되었지만, 제가 코로나 SDK를 처음 접했던 지난 2010년 상반기에는 ‘이거 믿고 사용해도 될까?’하는 의문이 들 정도였습니다. 하지만 꾸준히 지켜본 결과 새로운 기능 추가 속도가 빠르고 비전이 보이는 듯하여, 99불에 베타버전 정식 사용자 등록을 하고 코로나 SDK를 이용한 아이폰 게임 개발에 뛰어 들었습니다.

코로나 SDK를 사용하여 스마트폰 게임을 만들 때 좋았던 것은 iOS 용으로 작성한 코드를 거의 그대로 사용하여 안드로이드용 앱을 만들 수 있다는 것이었습니다. 오브젝트 C나 자바를 새로 공부하지 않아도 된다는 점은 더 좋았습니다. 특히 루아는 많은 게임 프로젝트에서 스크립트 언어로 애용되는 언어이기 때문에 코로나 SDK를 사용하면서 루아에 익숙해지면 나중에 큰 도움이 될 것이라는 생각도 했습니다. (저는 이 때부터 코로나 SDK를 사용, 지금까지도 계속 스마트폰용 앱을 개발해 오고 있습니다.)

코로나 SDK를 처음 시작할 때, 저의 루아 활용 능력은 기초적인 수준이었습니다. 루아에서 가장 중요하다는 table도 제대로 활용 못했고, 클래스를 사용할 줄도 몰랐습니다. 그럼에도 불구하고 적응이 어렵지는 않았는데, 왜냐하면 코로나 SDK의 사용 방식이 액션 스크립트 3.0과 굉장히 유사했기 때문입니다. 코로나 SDK를 만든 주역들이 과거 어도비사에서 액션 스크립트 3.0 개발에 참여한 사람들이라고 하는데, 아마도 그와 관련이 깊을 것입니다. (또한 액션 스크립트 3.0은 비교적 최근에 나온 프로그래밍 언어 입니다. 따라서 다른 프로그래밍 언어들이 이룩한 발전의 결과물들을 대폭 수용하고 있습니다. 이런 이유로 저는 게임 기획자가 프로그래밍을 처음 배우려고 한다면 액션스크립트3.0으로 시작해 보는 것을 권하고 싶습니다. 배우기 쉽고, 다른 최신 버전의 프로그래밍 언어들과 유사한 부분이 많으며, 사용자가 전세계적으로 워낙 많아 어떤 문제든 구글링을 통해 대부분 해결할 수 있습니다. — 2017년 의견: 이 글이 작성된 후 많은 변화가 있었습니다. 현재로서는 액션스크립트가 아닌, 유니티 등의 게임 엔진으로 바로 들어가 보시기를 권하고 싶습니다.)

여하튼 액션 스크립트 3.0에 익숙한 상태였던 저에게 코로나 SDK는 빠른 앱 개발을 가능하게 해 주었습니다. 코로나 SDK를 정식으로 구입한 뒤 제가 처음 만든 앱은 간단한 일본어 표현을 외울 수 있게 도와 주는 앱이었습니다.(이것은 당시 일본 여행을 앞두고 제가 사용하기 위해 만든 개인용 앱이었습니다.) 이렇게 간단한 앱을 만들면서 저는 또 한번 구글링의 위력을 실감했습니다. 당시 코로나 SDK를 사용하는 사람은 적었지만, 루아를 사용하는 사람들은 전세계적으로 꽤 많았기 때문입니다. 저는 개발하다가 모르는 게 있으면 구글에서 즉시 검색해 보았고, 대부분 답을 금방 찾아낼 수 있었습니다. (코로나 SDK 가 나온지 3년이 지난 지금은 워낙 사용자가 많아져서 웬만한 문제는 사용자 커뮤니티나 코로나 공식 사이트의 문답을 통해 해결할 수 있습니다.) 아직까지 한국에서는 코로나 SDK 사용자가 많지 않은 것으로 아는데, 2D 게임을 만들고자 하는 목적이라면 코로나SDK를 먼저 염두에 두는 것도 괜찮을 듯합니다. Box2D 엔진도 내장되어 있어서 물리 시뮬레이션을 이용한 게임도 쉽게 만들 수 있고, 많은 개발자들이 자신들이 만든 모듈을 공개해 놓고 있어서 고수들의 코드를 들여다보거나 그냥 가져다 사용할 수 있기 때문입니다.

유니티3D 프로그래밍을 익히다.

액션 스크립트 3.0을 배울 때는 프로그래밍의 기초도 부족한 생초보 시절이었기 때문에 책을 중심으로 공부했습니다. 그리고 코로나 SDK를 사용할 때는 책은 대충 흝어 보고 바로 실전 프로그래밍을 하면서 구글링에 의존하며 배워 나갔지요. 그런데 유니티3D의 경우는 기존과는 다른 방식으로 공부를 했습니 다. 책과 동영상 강좌를 약 50:50의 비율로 활용했던 것입니다.

유니티3D는 일단 제게 굉장히 생소했습니다. 액션스크립트 3.0이나 코로나 SDK와 달리 유니티3D는 ‘전문적인 게임 엔진’이었습니다. 그리고 클래스를 만들어 상속해 가며 게임을 만드는 것이 아니라(내부 적으로는 그렇게 되어 있지만요) 오브젝트에 컴포넌트를 추가해 가며 만드는 ‘컴포넌트 방식’의 엔진이 었습니다. 물론 가장 저에게 생소했던 것은 3D 라는 점이었습니다.

물론 저도 3D MMORPG 개발 프로젝트를 여러 개 총괄했고, 기획자로서 레벨 에디터를 이용, 레벨 디자인을 해 보았던 경험이 있습니다. 하지만 프로그래머가 만들어 준 레벨 에디터를 사용하는 것과 제가 스스로 3D 기반의 프로그래밍을 짜는 것은 전혀 다른 개념이었습니다. 따라서 이것을 책만 보고 공부했 다면 아마 적응하는데 시간이 많이 걸렸을 것입니다. 그리고 이런 어려움을 초기부터 극복할 수 있게 도 움을 준 것이 동영상 강좌들이었습니다. 그럼 제가 유니티 3D를 빠른 시간 내에 익힐 수 있었던 공부 방 법을 소개해 보겠습니다.

1. 강좌 동영상 보기(한국어)

제가 처음으로 한 것은 unity3dstudy.com이라는 사이트에서 기초와 중급 동영상 강좌를 본 것입니다. 강좌를 보면서 따라하지는 않았고 일단 끝까지 쭉 보았습니다. 제가 액션스크립트 3.0을 익힐 때 책을 처음부터 끝까지 일단 세번 읽었다고 말씀 드렸는데 같은 원리로 동영상 강좌를 일단 끝까지 본 것이죠.

강좌 동영상은 유니티 인터페이스를 익히는 데 큰 도움이 되었습니다. 인터페이스 조작하는 방법에 대해 서는 책으로 읽는 것보다 강좌 동영상을 보는 것이 훨씬 쉽습니다. 그냥 보고 배우면 되니까요. 그리고 강좌 동영상을 끝까지 쭉 보면서 대충 유니티 사용 방법에 대한 감을 잡을 수 있습니다. (그냥 감만 잡는 것입니다. 동영상 한번 봤다고 유니티 3D 실행해서 바로 게임 만들 수는 없습니다)

2. 책 두 번 읽기

강좌 동영상을 처음부터 끝까지 한번 보았기 때문에 대충 감이 잡힌 상태에서 이번에는 책을 한권 구입 해서 읽었습니다. 제가 선택한 책은 이었습니다. 이 책을 가지고 다니면서 처음부터 끝까지 이해가 가건 안 가건 무조건 두 번을 쭉 읽었습니다. 일단 동영상을 한번 본 뒤라 책을 읽는 게 어렵지 않았습니다. 인터페이스를 설명하는 부분도 처음부터 책만 봤다면 감을 잡기 어려웠을 텐데, 동영상을 이미 본 터라 쉽게 이해가 되더군요. 이 책은 자바스크립트와 C# 코드를 동시에 다 설명하고 있는데(유니티에서는 스크립트 언어로 자바스크립트와 C#, 그리고 Boo 를 사용할 수 있습니다), 자바스크립트 예제 코드는 액션 스크립트와 싱크로율이 굉장히 높아서 특히 이해하기 쉬웠습니다. C#의 경우도 약간의 문법 차이를 이해하면 액션스크립트와 비슷해서 마찬가지로 이해가 어렵지 않더군요.

이 단계에서 동영상이 아닌 책으로 공부한 이유는 다음과 같았습니다.

첫째, 동영상보다 책이 더 많은 정보를 세부적으로 설명해 주기 때문입니다. 동영상에서 강사가 오디오를 통해 전달하는 정보는 시간의 제약을 받을 수밖에 없습니다. 하지만 책은 그런 시간적 제약에 얽매이지 않고 필요한 정보를 충실히 전달해 줍니다.

둘째, 책을 처음부터 끝까지 읽으면서 유니티 3D의 주요 기능에 대해 일관해 보는 경험을 갖게 됩니다. 즉, 유니티의 공부 범위가 어디부터 어디까지인지를 전체적으로 조망해 볼 수 있다는 것입니다. 우리가 여행을 가기 전, 인터넷 지도 사이트에서 출발지부터 목적지까지를 한번 흝어 본 뒤에 출발하면 중간에 길을 잃고 헤메어도 막막한 기분에 빠지지는 않습니다. 일단 전체 코스를 조망해 놓았기 때문입니다. 책을 완독하는 것도 비슷합니다. 유니티라는 생소한 영역에 본격적으로 발을 들여 놓기 전, 전체 학습 범위를 조망해 놓음으로써 최소한의 자신감을 갖출 수 있는 것입니다.

여하튼 이렇게 책을 두 번 읽은 다음에 저는 다음 단계의 공부를 시작했습니다.

3. 동영상과 책을 참고해 가면서 간단한 프로그램(하나의 Scene)을 만들기.

이 부분 역시 액션 스크립트 3.0 공부 단계에서 제가 했던 방식을 응용한 것입니다. 동영상도 한번 보았고 책도 두번 읽었으니 이제 간단한 것은 혼자 만들 수 있을 것 같은 기분이 들었습니다. 이에 유니티 3D 를 실행하고 새 프로젝트를 생성한 뒤 간단한 씬(Scene)을 하나 만들어 보았습니다. 일단 GameObject 에서 큐브를 하나 생성한 다음에, 카메라를 배치하고 실행해 보았습니다. 그런데 간단해 보이는 카메라 위치 잡기, 오브젝트 좌표 잡기도 생각처럼 쉽지 않더군요. 3D가 생소한 터라 x,y,z 방향도 헷갈리는 것이었습니다. 이렇게 헷갈리면 동영상이나 책을 다시 보면서 다시 시도해 보고 하니 금방 익숙해졌습니다. 공간에 큐브를 배치하고 First Person Controller라는 것을 배치해서 1인칭 시점으로 게임을 이리 저리 돌아다녀 보면서 유니티를 가지고 놀아 보았습니다.

4. 작은 개발 목표를 정하고 직접 만들어 보기(반복).

역시 액션 스크립트 3.0 배울 때 사용했던 방식입니다. 작은 프로젝트 목표를 세웁니다. “바닥을 만들고 화면에 오브젝트를 하나 생성해 놓은 뒤, 버튼을 누르면 오브젝트를 다른 것으로 바꿔 보자.”와 같은 식으로 작은 목표를 세우고, 동영상과 책을 참고해 가며 목표를 달성해 갔습니다. 이것 저것 많이 만들어 보며 놀았던 것이죠.

5. 책을 한번 더 읽고 좀 더 수준 높은 동영상 강좌 보기.

4번 단계에서 유니티를 가지고 이것 저것 만들어 보다 보면 모르는 게 많다는 사실을 다시 절감합니다. 이 때 다시 책을 한번 더 읽습니다. 컴퓨터 앞에서는 유니티를 가지고 놀고, 지하철이나 커피샵, 도서관 같은 데 가서 책을 다시 읽어 보는 것이죠. 유니티를 가지고 놀면서 자신이 무엇을 모르는지 절감한 상태라서 책을 다시 읽으면 필요한 부분이 머리에 쏙쏙 들어 옵니다.

이 단계에서 저는 부족한 부분을 보강하기 위해 과거와는 다른 방식을 하나 더 사용해 보았습니다. 바로 좀 더 수준 높은 동영상 강좌를 본 것이죠. 기초 동영상도 보았고 책도 세 번 읽었고, 유니티도 어느 정도 가지고 놀아 봤으니 좀 더 심도 있는 공부를 해 보아야겠다는 생각을 했습니다. 이에 해외 동영상 강좌 사이트인 Lynda.com 에 유료 등록을 한 뒤, Unity3d 3.5 Essential Training 이라는 11시간짜리 강의 코스를 들었습니다. 영어로 된 강좌이긴 하지만 겁먹을 필요는 없습니다. 이미 유니티에 어느 정도 익 숙해진 상태에서는 화면과 코드 작성 과정만 보아도 이해하실 수 있으니까요. 저는 2배속으로 동영상을 돌려서 6시간 정도 만에 이 코스를 한번 다 보았고, 두 번째는 주요 부분만 보면서 코딩을 일부 따라해 가며 다시 보았습니다. ( 2017년 주석 – 참고로 현재는 제가 만든 동영상 강좌를 비롯, 한국어로 된 유니티 강좌들이 많이 있습니다. 자세한 것은 제 블로그하단의 링크를 참고하시면 됩니다.)

Unity3d 3.5 Essential Training 강좌 동영상을 보고 난 뒤, 저는 내친 김에 Maya 2011 Essential Training 이라는 강좌도 보았습니다. 제가 마야를 사용 할 일은 없지만 그래도 3D 게임을 만들기 위해서는 그래픽 아티스트가 마야를 이용해서 어떤 식으로 작업하는 지 정도를 봐 두면 도움이 될까 해서였 습니다. 그냥 구경하듯 동영상을 2배속으로 보았는데, 뭔가 감이 잡히는 기분이 들더군요.

Lynda.com 동영상을 보고 난 뒤, 다시 유니티를 가지고 제가 목표한 코딩을 시작했습니다. 캐릭터를 띄운 뒤 제가 작성한 스크립트를 이용하여 마우스 터치한 방향으로 캐릭터가 이동하게도 해 보고, 캐릭터 커스터마이징 씬도 만들어 보았습니다. 그런데 캐릭터 커스터마이징 하는 법에 대해 감이 좀 안잡혀 서 다른 동영상 강좌를 하나 또 보았습니다. 이번에는 Digital-Tutor라는 사이트에 가서 Customizable Characters in Unity 라는 강좌를 따라해 가면서 두 번 보았습니다. 그리고 나서 제 나름대로의 캐릭터 커스터마이징 씬을 완성할 수 있었습니다.

저의 경우, 유니티 3D 입문단계를 막 벗어난 정도가 되는 데 2달 정도 시간이 걸린 것 같습니다. 기존에 액션 스크립트 3.0과 코로나 SDK를 이용해 프로그래밍 경험을 쌓은 것이 도움이 많이 되었지만, 효율적인 학습 방법을 사용한 것도 큰 보탬이 되었던 것 같습니다. 특히 요즘에는 과거와 달리 좋은 강좌 동영상들이 많기 때문에 책만 보기 보다는 책과 동영상을 적절히 활용하면서 배우면 감을 잡는데 도움이 많이 됩니다. 물론 완전히 몸에 익히기 위해서는 자신이 직접 작은 프로그램을 반복적으로 짜 보는 ‘능동적인 과정’이 반드시 필요합니다. 온전히 자신의 힘으로 문제를 해결해 나가는 경험 없이 책과 동영상에만 의존하면, 금새 배운 만큼 금새 잊어 버리기 때문입니다.

글을 마치며

게임 기획자로 10년 넘게 일하다가 어떤 계기를 만나 프로그래머로 변신하게 되기 까지 많은 일들이 있었습니다. 그간 단편적으로 저의 경험을 주변 분들에게 말씀 드린 적은 있지만 이렇게 처음부터 끝까지 정리해 본 적은 처음인 것 같습니다. 제가 공부한 방법이 새로운 프로그래밍 언어를 익히는데 가장 좋은 방법은 아닐 것입니다. 이미 이 분야에 대해서는 전문가들이 제시한 좋은 학습 방법이 많이 소개되어 있는 것을 저도 알고 있습니다. 다만 저의 경우, 제가 몸으로 익힌 방식이 실제로 효과가 있었다는 점을 경 험했기에, 이런 방식도 있다는 것을 알려 드리고 싶었습니다.

게임 기획자가 프로그래밍을 익히는 것이 좋으냐 나쁘냐에 대해서 정답은 없는 것 같습니다. 프로그래밍을 배우는데 시간을 쏟기보다는 기획자로서 더 전문적인 능력을 키우는 데 시간을 투자하는 게 나을 수 도 있습니다. 하지만 저는 기획자가 프로그래밍을 익히는 것이 좋다고 생각하는 입장입니다. 게임 기획자들은 기본적인 꿈이 있기 때문입니다. 그것은 “누구의 간섭도 없이 내 마음대로 기획한 게임을 만들고 싶다”는 꿈입니다. 점점 더 게임 프로젝트의 규모가 커지고, 자본의 힘이 강해지고 있는 지금, 회사에서 기획자 마음대로 게임을 만들기는 어렵습니다. 하지만 1인 개발이라면 이야기가 다릅니다. 저처럼 1인 개발을 생업으로 삼고 있는 경우가 아니라고 하더라도, 회사 다니면서 주말을 이용해 자신이 생각하는 ‘내 맘대로의 게임’을 만드는 것은 가능하기 때문입니다. 만약 프로그래밍을 할 수 있다면, 게임 기획자들도 ‘그저 재미로’ 게임을 마음껏 만들어 볼 수 있을테니까요. 그것이 상업용이든 아니든 말이죠.^^

지금까지 읽어 주셔서 감사합니다. ^^