본문 바로가기

칼럼

시작하려는 개발자를 위하여 - 엄의 답변

저도 답변을 했지만 엄님에게도 부탁해서 또 다른 관점에서 질문에 대한 답을 얻어보았습니다. :)



 IT밸리에 게임 개발/기획 관련 설문 해도 되겠습니까? 에게 트랙백.

1. 단순히 게임에 관심이 많은 매니아가 혼자 직접 게임을 제작하여 성공할 수 있다고 생각하십니까? 그렇다면, 어떻게 가능합니까? 그렇지 않다면, 왜 그렇다고 생각하십니까? (성공사례를 들어주시면 감사하겠습니다)

단순히 게임에 관심이 많은 매니아라면 불가능합니다. 공부할 것이 많으니까요. 진지하게 게임 제작에 투신해서 게임을 만들기 위해 필요한 스킬을 알아두고 자기가 익힐 것을 정해서 연마해야 합니다. 물론, 단순한 게임 매니아라도 이러한 과정을 거친다면 혼자서 게임을 개발할 수도 있고 성공할 수도 있습니다. 게임을 제작해서 성공하느냐 마느냐는 게임에 관심이 많은가가 아니라, 게임 제작에 관심이 많은가가 좌우하겠죠.
1인 개발팀 성공의 최대 관건은 배포입니다. 자신이 만든 게임을 어떻게 배포할 수 있느냐가 최대 문제죠. 다행히 소프트웨어 업계에는 아주 오래전부터 셰어웨어라는 훌륭한 배포 형식이 존재합니다. 존 카맥이 회고하기를 "셰어웨어로 판 둠의 수익금으로 집과 스포츠카를 장만했죠"라고 쓴 걸 본 적이 있습니다. 인터넷과 웹서비스가 그때보다 1000배쯤은 더 발달한 것을 감안하면 셰어웨어 형태의 배포도 가능성이 있을 것 같네요. 혹은, 프리웨어로 배포한다고 하더라도 명성이 쌓이면 이것이 바로 개발자의 자산이 됩니다. id소프트가 둠을 공짜로 배포했다고 하더라도, 존 카맥의 지금의 명성이 덜해지거나 하진 않았겠죠.

2. 그러한 아마추어 프로그래머들을 제한하는 것이 있다고 생각하나요?

시간. 시간이 가장 제약이 심한 요소입니다. 1인 개발팀이라고 하면, (엄마친구아들이 아닌 이상) 다른 일로 생업활동을 하면서 남는 시간에 게임 개발을 위한 작업과 연구/개발을 해야 할 텐데, 생각만큼 쉽지가 않습니다. 하루종일 일하고 돌아오면 녹초가 되기 십상이죠. 시간 안배가 가장 중요합니다. 시간을 많이 쓸수 없기 때문에 진전이 더디고 진전이 더디면 조급하고 초조해지죠. '어차피 안될거'라는 생각이 들면서 그냥 잊어버리고 살수도 있죠. 작더라도 눈에 띄는 결과를 계속해서 만들어내는 것이 중요합니다. 1인개발은 시간과의 싸움입니다.

3a. 게임 개발/기획 경험이 있으신가요? (없으시면 4로 넘어가주세요)

현업 프로그래머입니다.

3b. 어떻게 하여 게임 개발/기획을 하게 되었나요?

어렸을 때 게임을 하면서 게임을 만들어 보고 싶다고 결심을 했죠. (자세한 내용은 여기로.)


3c. 개인적인 경험이 있으시면 말씀해주실 수 있나요?

말씀해 드릴 수 있지요. (자세한 내용은 여기로)

3d. 게임에 대한 설정 (세계관, 캐릭터 등)은 무엇으로 시작하게 되었나요?

지금은 직업 프로그래머로서, 개인적인 세계관이나 설정으로 작업하고 있지는 않지만, 혼자서 독립게임을 만든다면 감명깊게 읽은 소설이나 재미있게 플레이한 게임, 과거에 흥미롭게 읽었던 논문 등에서 힌트를 얻어 구상을 시작하겠죠.

3e. 게임을 만들기 위해 프로그래밍을 배우셨나요? 아니면, 프로그래밍을 이미 알고 있어서 게임을 만드셨나요?

게임을 만들기 위해서 프로그래밍을 배우기 시작했습니다. (자세한 내용은 여기로)

3f. 게임 개발/기획 과정 중에 어떤 걸 배우셨나요? 혹은, 이 과정에서 어떤 지식을 이미 알고 계셨나요?

의견을 조율하는 것이 중요하다는 점을 배웁니다. 다른 스킬은 혼자서 계발해야 할 몫입니다.

3g. 혹시 게임 기획/제작에 영향을 끼친 다른 게임이라던가, 작품이 있나요?

많습니다. 주로 마이크로프로즈와 오리진, 불프로그의 게임들이 영향을 줬지요.

4. 10년 전 (90년대) 보다 최근에 들어서 이렇게 아마추어 게임 제작이 더 쉬워졌다고 생각하십니까? 그 이유는?

더 어렵습니다. 참고할 자료를 찾는 것도 쉬워지고 체계를 갖춘 개발 툴도 나오긴 했지만 10년 전과 비교하면 공부할 양이 훨씬 더 많습니다. 물론, 90년대에 쓰던 로우레벨 스킬(인터럽트, 메모리 매핑, XMS/EMS관리, 스캔컨버전 등등등)은 알 필요가 없어졌지요. 하지만 하드웨어가 엄청나게 발전했습니다.  그래픽 코어의 발전은 프로그래머가 셰이더를 알 것을 요구하며, CPU코어의 증가는 프로그래머가 병렬프로그래밍을 알 것을 요구합니다. PC/게임콘솔을 막론하고 이런 식의 발전이 프로세서/그래픽/사운드/입력/네트웍 등 전방위적으로 벌어지고 있습니다.
물론, 1인 독립 게임에 이러한 복잡한 스킬을 사용하여 제작할 필요가 있느냐를 묻느냐면 '경우에 따라 다르다'는 게 정답이지만, 프로그래머 스스로가 경쟁력을 갖추려면 반드시 알아야 하는 기초 지식입니다. 고성능의 하드웨어는 프로그래머가 100% 활용할 것을 요구합니다. 그리고 하드웨어와 시스템의 성능을 100%까지 끌어내는 것이 프로그래머의 신성한 의무죠.

5. 게임산업에서 게임 콘솔(Xbox360, PS3, Wii 등)이 창의성을 제한하고, 이익을 더 내려고 한다고 생각하십니까? 예를들어, 한 게임이 성공하면 그 시리즈로 2, 3 등등 계속 만들고 있는데 그러한 것들이 새롭고 참신한 게임 주제들이 못 나오게막고 있다고 생각하시나요?

각 게임 자체는 문제가 아니지만, 그러한 울궈먹기 게임을 골라서 출시하려는 플랫폼 홀더는 1인 독립의 출시는 리스크가 크기 때문에 플랫폼 라이센스를 주지 않으려 하는 경향이 있을 수 있습니다. 게임콘솔 업체들은 아직도 아타리 쇼크를 기억하고 있을 테니까요. 물론, 명망있는 개발사에서 새로운 시도를 한다면 들어줄 지도 모르겠군요.

6. 갓 프로그래밍에 입문하는 뉴비에게 할 조언이 있으신가요?

오래된 지식들이 가장 빛나는 무기가 됩니다.
현재에 와서는 셰이더니, 멀티코어니, 물리/수학이니, 스크립트니 하는 것들이 최신 기술인양 소개되고 있지요. 하지만 이들은 모두 최소한 30년전부터 교과서에서 기술해온 기술들입니다. 하드웨어의 발전으로 이제서야 대중적으로 쓰게 된 것 뿐이지요. 셰이더는 새로운 것 같지만 이를 쓰려면 70년대에 제안된 조명/셰이딩 과정을 알아야 하죠. 멀티코어 프로그래밍은 컴퓨터의 태동기부터 아주 깊이 연구된 주제입니다. 스크립트 언어 역시 컴퓨터의 태동기부터 문제해결을 위해 사용돼 온 도구이구요. 물리/수학이야 말할 것도 없이 수백년의 역사를 가진 학문이죠.
3D렌더링 하나만 보더라도 DOS시절의 소프트웨어 렌더링, 부두와 함께 등장한 서드파티 래스터라이징 API, 지포스와 함께 등장한 하드웨어 T&L, DX8과 함께 등장한 셰이더 어셈블리, DX9과 함께 등장한 셰이더 랭기지를 거쳐 DX10의 통합 셰이더까지 왔습니다. 이러한 변천의 과정에서 3D렌더링을 구현한 껍데기는 계속 바뀌어 왔습니다. 하지만 그 속의 알맹이인 핵심 개념은 30년동안 변치 않고 남아있죠. 개발자가 껍데기에만 집중한다면 문제입니다. 앞으로 기술적 대세가 어디로 갈 지는 아무도 모르기 때문이죠. 껍데기는 항상 변하는 기술이며, 조엘이 말한 "쏘며 달리기" 전략의 구현물입니다. 껍데기에 째빨리 적응하는 것도 중요하지만, 껍데기를 만지작거리면서 알맹이를 파악해야만 합니다.
껍데기가 변하더라도 항상 알맹이는 남아있습니다.
그리고 그 알맹이는 아주 오래된 지식들이죠.

답변자 : 엄

경력 6년차의 게임 프로그래머. geek의 화신이며 포스를 수련한다는 소문도 있습니다.
언제나 후배들에게 포스의 어두운면에 대한 주의를 설파하는 뼛속까지 프로그래머.