게임 프로그래머

이 문서는 준보호 상태입니다.

이 문서는 잦은 문서 훼손 및 수정 전쟁으로 인해 자동 인증된 사용자만 수정하도록 제한되었습니다.

• 상위 항목 : 비디오 게임 제작자, 프로그래머

1 개요

게임 프로그래머는 게임을 만들때 필요한 핵심 인력중 하나이다. 사실상 게임을 만드는 데 있어 가장 귀중한 인력이라고 봐도 과언이 아니다.

2 유형

수십, 수백명의 개발자들이 필요한 AAA 게임들은 다양한 분야의 전문가들을 필요로 한다. 아직도 수많은 사람들이 게임 프로그래밍의 대해서 착각하는 것 중 하나인데, 같은 게임 프로그래머라고 해도 전문 분야가 다르면 필요한 지식, 경력, 성격, 등등이 완벽하게 달라진다. 예를 들어서 게임플레이 프로그래머는 방향 관련 계산을 하기 위한 선형대수학의 기초만 대충 알면 괜찮지만 물리엔진, 에디터 프로그래머는 사원수, 오일러 각 등의 3D 수학을 기초로 알아야 인턴쉽(!)이 잡힌다. 반대로 물리엔진 프로그래머는 수학 실력이 뛰어나기만 하면 되지만 게임플레이 프로그래머는 "컴퓨터 게임"을 이해를 하고 사랑을 해야만 일이 된다.

게임 프로그래머의 유형을 대강 나눠보자면:

• 게임플레이 프로그래머 (Gameplay Programmer)

이쪽은 만능형 프로그래머 (Generalist Programmer)가 많다. 간단한 설명은 다른 프로그래머들은 게임 엔진 쪽으로 더 가깝고 게임플레이는 말 그대로 "유저들이 게임이라고 느끼는" 부분. 카운터 스트라이크를 예로 들면 플레이어의 움직임, 총기의 작동 원리, 폭탄이 폭파하면 테러리스트가 승리한다는 규칙 등이 다 게임플레이다. 게임을 사랑해서 게임 프로그래머가 됐다면 웬만하면 이쪽으로 간다.

설명만 들어보면 난이도가 다른 분야보다 낮다고 생각할수 있지만, 게임 규모가 커질수록 더 틀린 얘기가 된다. 게임 규모가 크면 접하게 되는 코드의 분야가 더 넓어지고, 전혀 모르는 분야라도 대충 공부해서 대강 이해를 할줄 알아야 한다. AAA 규모쯤 가보면 어느날은 NPC의 비행 능력을 위해서 팔진트리로 3D 최단 경로 찾기 알고리즘을 공부하고, 그 다음날은 두명의 플레이어 캐릭터들의 잡기 공격을 어떻게 코딩해야 렉이 있는 상태에서 두명이 동일한 상황을 보게 만드나 생각하는 자신을 볼수 있다.

결론은 특정 분야에 많은 지식이 필요하지는 않지만, 프로그래머로서의 눈치랑 해석력이 많이 요구된다.

• 물리 엔진 프로그래머 (Physics Programmer)

게임에 필요한 물리 계산을 빠르게, "필요한 만큼 정확하게" 하는 개발을 한다. 프로그래머 항목에 프로그래머들은 거창한 알고리즘 연구를 안한다고 하지만, 이쪽은 그런 짓을 할만한 인간들이 필요하다. 유저들은 매년 상향되는 그래픽, 물리 엔진을 보고 싶어하고, 만족할만한 게임을 만들기 위해서 더 새로운 그래픽 기술들의 효율적인 계산이 필요하다. 그래서 이쪽은 컴공보다 물리학자, 수학자들이 더 많이 보인다.

• 그래픽 / 렌더링 프로그래머 (Graphics / Rendering Programmer)

3D 그래픽이나 애니매이션을 빠르게 계산하고, 효율적으로 유저의 모니터로 출력하는 개발을 한다. 위와 비슷하게 순수한 프로그래밍보다 수학쪽 지식을 더 많이 필요로 한다. 수학이 싫거나 자신이 없다면 가장 멀리해야 하는 분야.

• 개발 도구 프로그래머 (Tools Programmer)

대규모 회사 아니면 절대 못볼 직업으로, 대부분 프로그래머가 아닌 개발자들이 프로그래머들의 도움이 없이 개발에 참여를 하게 해주는 도구들을 개발한다. 게임 디자이너들이 아주 기초적인 코딩 실력으로 게임을 완벽하게 바꿀수 있게 하는게 주 목적이다. 회사 규모가 더 크면 게임이랑 전혀 관련 없는 직원, 빌드 관리 소프트웨어까지 만들게 된다. 어떻게 보면 "게임 개발" 에서 가장 동떨어진 직업.

• 네트워크 프로그래머 (Network Programmer)

온라인 게이밍의 핵심이라고 볼수 있다. 클라이언트와 서버와의 데이터 송수신을 다루고, 렉을 줄이기 위해서 최소한의 정보를 보낼 방법과, 심한 렉, 서버 다운, DDoS 공격 등의 문제를 해결할 방법을 연구한다. 데이터 사용량을 줄이는 동시에 클라이언트의 시점에서 렉이 안보여야 하는데, 잘못된 디자인은 0.1초의 렉으로도 유저와 유저 밖의 세상이 따로 노는 느낌을 줄 수 있다. 한국사람으로서 상상하기 어려울수도 있겠지만 세계의 평균 인터넷 속도는 낮은 편이고, 구형 모뎀 인터넷으로 지구 반대쪽에 있는 서버를 통해서 게임을 해야 할 사람도 있으니, 세계적인 온라임 게임을 만들기 위해서는 1바이트의 추가 데이터도 아까워야 한다. 예로 Integer (정수) 의 송수신이 필요한데 32비트가 아까워서 더 작은 자료형을 만들거나, 가끔 32비트가 다 필요한데 대부분 8비트만 쓴다면 8비트당 데이터 존재 여부를 뜻하는 비트를 추가해서 "0"은 4비트, 8비트를 수신할때 12비트, 32비트를 수신할때만 36비트를 쓰는 방법이 있다.

그 외로 인공지능, UI, 사운드 프로그래머가 있다.

3 기초로 필요한 능력

3.1 프로그래밍

최소한 한가지 이상의 프로그래밍 언어를 알고 있어야한다. 하지만 한가지 언어로만은 게임을 만들기 어렵다

최적화가 중요한 대규모 고사양 게임에선 C++이 아직도 주류로 쓰인다. 엔진 제작 단계에선 어셈블리어까지 쓰인다고(...) 근래에는 엔진을 직접 만들지 않고 유니티 3D, 언리얼 엔진을 위시한 타 사의 상용 엔진을 가져다 쓰는 경우도 많아졌는데, 유니티의 경우엔 C#을 사용하고 언리얼의 경우엔 C++이 사용된다.

프로그래밍 언어외에 그래픽 라이브러리에 대한 이해도 필요하다 DirectX나 OpenGL가 기본이다. 보통 많은 기능을 제공해주고 품질이 높은 DirectX나 OpenGL를 사용해서 만드는데 옛날에는 없이 하기도 하였다.

게임 엔진을 사용해서 만들 수도 있는데 엔진을 사용하더라도 로직을 짜는 실력정도는 갖추고 있어야 한다.

또한 요즘은 2D게임도 3D기반으로 만들기 때문에 3D에 대한 지식이 필수다. 이미지를 합치는 방식이나 라이트맵핑 등.

자료구조와 알고리즘의 로직은 한번씩 구현해보는 것이 좋다. 만들어 본것과 알기만 하는 것의 차이는 크며, STL과 Boost를 쓴다고 해도 예외는 아니다.

온라인게임 쪽에서는 크게 클라이언트와 서버로 나뉜다. 서버나 클라이언트나 괜찮은 실력을 가진 사람은 언제나 구하기 힘들다.

멀티코어 프로세싱은 보통의 게임 프로그래머는 그렇게 선호하지 않는다. 왜냐하면 프로그래머 입장에서 득보다 실이 많기 때문이다. 데드락, 레이스 컨디션, 코드이해의 어려움 등.

어럽게 구현했다 하더라도 렌더링 퍼포먼스는 코어 하나의 퍼포먼스를 넘을 수 없다. 왜냐하면 렌더링은 코어 한놈이 하기 때문이다. 그래서 아무리 화면을 빨리 그린다고해도 코어 하나의 성능 이상은 나올 수 없다. 그래서 제일 많이 택하고 여전히 선호하는 방법은 멀티를 지원하지 않는 것이다. 렌더링을 몇 프레임 덜 하더라도 위에서 발생할 문제들이 대폭 줄기 때문이다. 렌더링 횟수 기준을 보통 1초에 60번을 기준으로 삼는데 컴퓨터 성능에 따라서 더 많이 나온다. 1초에 60번 기준으로 했을 때 1초에 55번, 58번, 49번 사람 눈으로 구분하기도 힘들고 엄청나게 프레임이 끊겨서 게임 못할 정도도 아니고 프레임을 약간 희생하면 많은 장점(위의 문제들 대폭 감소로 인한 수월한 개발- 시간 절약, 인건비 절약, 개발자들 스트레스 감소...)을 얻을 수 있다

렌더링을 여러 잡으로 쪼개 여러 코어 혹은 스레드에서 처리하게 하는 기술은 이미 오래전에 개발되어 있다. 다만 구현이 복잡하고, 이를 잘 다룰 수 있는 프로그래머가 적어 몸값이 비쌀 뿐이다. 게다가 게임루프에는 렌더링만 존재하는 것이 아니다. 사용자 입력 처리, 객체 업데이트, 애니메이션, 물리, 사운드에 AI까지 모두 처리해야한다. 게임에 따라 렌더링이 전체 게임루프에서 1/4이하의 자원만 소모하는 경우도 있다. 렌더링만 다른 스레드에 할당해도 엄청난 성능향상을 이룰 수 있다.

"1번 스레드에서 나머지 모든 것을 처리할동안 2번 스레드에서 이전 루프에서 1번 스레드가 처리한 데이터를 기반으로 렌더링을 진행하고, 모든 스레드에서 작업이 끝나면 버퍼를 교환해 완성된 이미지를 보여준다. 그 뒤로는 계속 반복" 이 가장 간단한 멀티프로세서 게임 루프의 기본이다. 물론 실제 구현은 간단하지가 않다.

게임에서의 멀티코어 프로세싱 기술은 생각보다 많이 진전되어있는데, 다른 거 없이 콘솔 게임기는 7세대부터 대부분이 멀티코어 CPU를 달고 있었고, 엑스박스 원,PS4등의 8세대 게임기는 8코어짜리 CPU를 달고 있다. 중요한 것은 메이저 콘솔게임개발사는 7세대 시절부터 콘솔의 한정된 CPU자원을 거의 백퍼센트 다 쓰도록 프로그래밍을 해오고 있다는 것. 즉 3코어 6스레드 짜리 엑스박스 360이나 1+6코어짜리 PS3시절부터 게임 루프를 많게는 6조각으로 쪼개서 효율적으로 처리하도록 프로그래밍 하는 것이 가능했다는 이야기다. 다만 하드웨어 사양에 소프트웨어 환경까지 천차만별인 PC에 비해 다음 세대 콘솔이 나올 때까지 동일하고 고정되있는 하드웨어에 맞춰 개발한다는 등, 콘솔 개발만의 이점은 분명히 있다.

3.2 컴퓨터 공학

얕은 정도의 공학적 지식이 필요하며, 운영체제에 대한 이해를 포함한다. 기초가 되는 부분이며 가장 중요하다. 이것은 디버깅할 때 많은 도움이 된다.

3.3 수학

고등학교 수준 이상이 필요하다. 3D 그래픽은 선형대수학을 기반으로 하여 정의되고, 통계학과 유한 상태 기계(Finite State Machine)의 개념이 없으면 내부 로직을 짤 때 한없는 애로사항이 꽃피게 된다.

3.4 영어

어느 업계가 안 그러겠냐만은 많은 개발 자료나 지식, 길잡이 등은 영어로 쓰인다. 한국어로 찾아서 안나올 때는 영미권 사이트들을 찾아보면 대부분 나온다. 사전 끼고 궁금한 것들을 찾아보면서 모르는 단어들은 찾아보면 실력이 늘어난다. 영작 능력은 한글판 게임이나 번역가를 고용하면 되지만, 해석은 일일히 번역가를 사용하기 힘들기 때문에 해석 능력은 거의 필수,

4 되는 방법

4.1 대학 진학을 희망하는 경우

게임학과 참조.

항목에도 서술되어 있듯이 국내의 게임학과들은 10년이 넘은 과가 거의 없을 정도로 역사가 짧고, 커리큘럼 역시 제대로 정립되어 있지 않다. 게다가 대학 특유의 비효율적인 교육과정 때문에 실력만 따지자면 2-4년제 게임학과 졸업생보다 오히려 현업 출신 강사에게 알짜배기 교육만 받는 학원 출신이 더 잘하는 경우가 많다.

아이러니하겠지만, 보통 대학교에서 게임학과에 있는 교수들은 게임업계 경력이 거의 없는 사람인 경우가 대부분이다. 심한 경우 컴퓨터공학과 출신 교수가 대신 맡는 경우도 비일비재하다.

이런 상황에는 나름 이유가 있는데, 대학 교수가 되기 위해서는 상당히 까다로운 과정을 거쳐야 하기 때문이다. 그렇기에 대학 교수가 될 정도로 노력한 사람은 현직 게임 프로그래머들에 비해 현업 경력이 상대적으로 적거나 없는 사람일 확률이 높다. 그렇다보니 교수들이 기본적인 OpenGL이나 DirectX의 지식도 별로 없고 게임 제작에 대한 지식도 별로 없다.

이렇게 가르치는 사람이 잘 모르는 채로 가르치는 상황이라 배우는 것 역시 별로 알차지 않다. 그나마 배우는 것도 학원을 다니거나 스스로 독학해가면서 알아가는 경우가 대부분이라서 현업에서 게임을 제작할때 사용하는 기법이나 노하우 같은걸 알 수도 없고 이해도 어렵다.

졸업작품을 보면 그럴듯하게 작품이 나오는 듯 하지만, 대부분의 경우는 날코딩하는 경우가 아니라 엔진을 쓰는 경우가 부지기수다. 얼핏 보면 결과물이 좋아 보여도 그건 엔진이 지원하는 기능이 좋아서 그런거지 학생들의 실력을 크게 반영하지 못한다.

그렇게 대학교에서 커리큘럼대로만 배우다 보면 실상 현업에서 쓰이는 기술은 거의 배우지 못한 상태가 되는데, 이 상태로 회사 들어오면 부족한 실력이 드러나는게 다반사다. 학교에 다닐 것이라면 현업에서 일하고 있는 졸업한 선배나, 동기 친구들과의 스터디를 통해 학교에서 제공하는 커리큘럼 이외의 방법으로도 실력을 쌓을 방법을 모색해야 한다. 별 생각없이 머리를 비우고 주어지는 것만 받아들이면서 몇년을 다니는 것은 학원에 1년 다닌 것보다 못할 수 있다.

결론을 말하자면 본인의 수학능력시험 성적이 중위권 이상이면 그냥 컴퓨터 공학과를 가는게 낫다. 게임 프로그래밍에 필요한 수학적인 지식은 1, 2학년때 배우게 된다. 선형대수학, 미적분학, 통계학을 배우기 때문에 게임학과와는 달리 수학적인 지식에서 훨씬 강세를 보인다. 프로그래밍쪽 학습은 일단 자바 C언어를 기본적으로 습득한 후, 알고리즘 구조, 파일 입출력 같은 시스템 프로그래밍을 게임학과에 비해 훨씬 심화적이고 어려운 레벨까지 접근하기 때문에 배우는 학생들에게는 지옥이지만 오히려 나중에는 그것이 득으로 다가오게 된다.

고학년으로 올라가면 필수과목이건 선택과목으로건 수리 알고리즘 시뮬레이션 같은 선형대수적인 문제에 대해서 프로그래밍으로 구현하는 능력을 배우게 되며 이는 1, 2학년때 단지 수학적인 접근에서만 배웠던 수학을 프로그래밍 적인 시야에서 접근하는 방법을 배우게 된다. 본인이 공부를 그냥 한다면 게임학과 같이 기초를 무시하고 코딩적인 능력만 빨리 습득하는 게임학과는 생각 안하는게 낫다. 공부에는 왕도가 없다. 샛길로 갈려고 궁리를 하지 말라

4.2 대학 진학을 희망하지 않는 경우

독학하는 것은 매우 힘들다. 따라서 게임학원을 다니는 것도 방안이 될 수 있다. 국비 지원하는 학원이 많으니 잘 알아보자. 다만 다중 접속 온라인 게임 서버 개발을 가르치는 학원은 극소수에 불과하니 참고 바란다.

학원도 학원 나름이다. 유행하는 엔진 갖고 잠시 만져보는 수준 정도로 교육해주는 학원이 많은데 이는 실력 향상에 도움이 별로 안된다. 요즘으로 치면 유니티만 가르쳐준다. 유니티만 할 줄 알면? 중규모 이상의 온라인 게임만드는 회사의 팀엔 절대 못간다고 보면된다. 대기업이라도 모바일팀엔 갈 수도 있다. 중규모 이상의 온라인 게임은 안된다. 그런 팀에선 유니티 다룰줄 아는 사람은 뽑지 않는다. 왜냐하면 중규모 이상의 온라인 게임은 100% C++로 만들기 때문이다.

각각의 게임 엔진은 정해 놓은 룰이 있다. 엔진의 규칙(포맷) 이 있는데 이에 맞추어서 게임을 만들어야 한다. 유니티의 경우는 무조건 스테이지 시작전에 미리 로딩을 끝마쳐야 한다. 그런데 중규모 이상의 온라인 게임들은 카메라를 자유 자재로 움직여야 한다거나 시점이 1인칭에서 3인칭으로 변경이 자주 된다거나 스킬 트리가 복잡하고 사용되는 이펙트들도 무거워서 미리미리 로딩을 해야 하다가도 실시간으로 로딩을 해야 하는등 게임 내의 메모리 관리를 캐릭터의 특성에 따라서 맘대로 했다 안했다가 하는 유연성이 필요한데 유니티는 그것이 부족하다.

따라서 유니티로는 중규모, 대규모 MMORPG를 만들지 않는다.위에서 말한대로 메모리 관리를 유연하게 할수 없기에 아예 만들지 않는다. 존이동을 예를 들면 이동할것을 대비하여 지금 보이는존 주위의 존을 메모리에 올려 놓아야 하는데 이걸 실시간으로 할수없다. 유니티 엔진이 지원하지 않는다. 유니티는 무조건 씬단위로만 게임을 구성해야한다. 중규모, 대규모 MMORPG는 씬단위로 구성되지 않는 게임이라서 엔진 특성 자체가 안 맞는 것이다.

그래서 유니티만 배웠다면 모바일 게임회사 밖에 갈 수 없다. 모바일 게임회사는 아주 큰 규모의 회사면 몰라도 중소규모 회사는 망하기도 쉽고 사업철수도 쉽게 하기 때문에 어느 순간 실업자가 되는 경우가 비일비재하다.

중규모 이상의 게임들, 즉 고정 유저를 확보하고 안정적으로 수익을 내는 타이틀을 가진 회사들의 팀에 들어가는 것이 안정적으로 경력도 쌓고 실력도 쌓으며 일 할수 있는 좋은 회사다. 그런 회사는 유니티를 선호하지 않는다. 그런 회사에 모바일 팀이 있더라도마찬가지로 수익이 안난다는 이유로 얼마든지 팀을 해체할 수 있다.

유니티를 배워서 모바일 회사다니다가 회사가 망해서 짤리고 다른회사 갔는데 월급이 밀리고 그래서 다른데 갔더니 거기는 사업을 접고... 여기 저기 모바일 회사만 전전하고 싶지 않는 것이 모두의 바람이라고 생각되는데 그렇다면 유니티는 취미로만 배우길바란다. 안정적인 회사 다니면서 유니티로 아이디어 게임 만들어서 대박나면 나와서 회사를 차리는 케이스가 종종 있긴 하지만 처음부터 유니티로 시작한다면 좀 어렵고 힘든 길을 걷게될 것이다.

4.3 게임 회사에 다니고 싶은 경우

게임 회사의 채용 전형은 상시채용과 공채로 나뉜다. 회사별로 공채 시기는 다르지만, 보통 1년에 1~2회 정해진 기간에 공고가 나간다.

전형 단계는 보통 서류>필기>기술면접>인성면접의 순으로 가게 되는데. 이 부분은 일반적인 회사와 크게 다르지 않다.

상시 채용은 대부분 회사에서 진행하며, 입사지원서를 보내면 검토 후, 회사에 따라 필기, 면접 전형을 보게 하여 채용한다. 다만, 상시채용은 거의 포트폴리오를 요구하는 경우가 대부분으로, 실력적인 부분을 더 많이 요구하는 전형이라고 할 수 있다.

4.4 인디 게임 개발자가 되고 싶은 경우

고난과 역경의 길이다. 실력있는 사람이 이길을 택하길 바란다.
물론 아주 반짝이는 아이디어로 빠르게 만들어서 잘 될 수도 있지만 그런 경우는 아주 없는 것은 아니지만 정말 희박하다.
실력이 있어야만 내가 생각했던 게임을 구현할 수 있다. 아이디어는 있지만 구현할 실력이 안된다면 아예 시작하지 마라
실력이 된다면 해볼 만한 길이다.
정말 잘되면 인생이 달라진다.

그러나 그 길은 가시밭, 지뢰밭이다. 팀을 만들어서 하는 것도 힘들고 혼자서 하는 것은 더더더더 힘들다.
팀을 만들면 의견 조율이 그리고 금전적인 문제가 그리고 이권다툼이 생길 가능성 또한 개발기간이 길어지면 길어질 수록 팀원들의 사정때문에 그만두거나 와해되는 경우가 비일비재하고, 혼자하면 모든 것을 혼자다 감당해야 하는데 기획은 머 그냥 머릿속으로 한다 쳐도 프로그래머는 그래픽이 그래퍼는 프로그램으로 구현이 문제다.

어찌어찌 게임을 만들었다 치자. 결과가 돈을 못벌면? 팀원들이 그런 사정을 감안해서 얼마나 참아 줄것인가? 팀원들도 경제적으로 힘들다고 회사를 다시 가야겠다고 빠진다면 구멍난 인력을 자리를 대신해줄만한 인력을 과연 쉽게 구할 수 있을까?
인디게임을 팀으로 만들었다면 팀원 자체가 몇명 안되고 한자리라도 구멍나면 내가 메꾸지 않는 이상 그 파트 일은 올 스톱!!

인디게임은 만들기도 힘들지만 성공하기란 더 힘들다. 그럼에도 불구하고 잘된 케이스가 있다.
실력이 되고 자신있다면 도전해보라
열매는 달지만 과정은 굉장히 엄청 진짜로 미친듯이 힘들다

4.4.1 홀로 서기

혼자하기는 매우 힘들다. 최근에는 게임 엔진들이 매우 다양한 기능과 시각적 편리함을 제공하기에 프로그래밍은 좀 수월하지만, 그래픽과 사운드의 소양까지 갖추기는 힘들다. 먼치킨급 능력(기획+개발+그래픽+사운드)을 가지지 않았다면 홀로서기 형태의 인디게임 개발은 대부분 그래픽과 사운드 소스를 외주를 통해 진행하게 된다. 먼치킨급 능력을 가졌다 하더라도 시간에 매우 쫓길 것이다.

그러나 그렇다고 아주 불가능하지만은 않다. 당장 옆나라 일본만 해도 혼자 만들었다는 동인 게임이 수두룩하며, 미국이나 유럽 등지에서도 심심찮게 혼자 만든 게임들이 틈틈히 출시되고 있다. 그리고 개중엔 정발도 안 한 한국에서도 유명할만큼 인지도 높은 명작들도 많다. 뱅가드 프린세스, Dust: An Elysian Tail, 언턴드등이 대표적.

다만 주의해야 할 점은 일본계 동인 게임들은 그 배경의 특수성, 그러니까 대부분 기존에 존재하는 창작물들의 아이디어를 그대로 가져다 쓴(냉정히 말해 무단도용한) 2차 창작물들이 대부분인데 어지간하면 원작자들이 그걸로 돈을 벌어도 '동인이니까' 하며 넘어가주는 환경이 조성되어 있어서 가능하다는 점을 유념할 필요가 있다. 즉 기존에 있던 아이디어들을 그냥 그대로 가져다 썼기 때문에 아이디어 구상, 홍보 전략 구상 등 몇몇 면에서 시간과 예산을 절약하는게 가능했기에 혼자서도 충분히 만들 수 있었고 또 코믹 마켓 같은 안정적인 판매처가 존재해서 그걸로 수익을 벌 수 있으니 존속이 가능한 케이스이다.

북미나 유럽의 경우 물론 여긴 저작권에 빡쎄서 일본처럼 남의 아이디어를 갖다 쓰는게 불가능한 문제가 있는 등 여건이 널널하지만은 않지만, 자기 회사 일 하면서 취미로 틈틈이 만드는 겸업 프로그래머도 있을 만큼 생활에 여유가 많은 경우가 대부분이라 나쁘지 않다. 심지어는 그냥 전업으로 게임 개발에 전념하는 개인들도 많다.

다만 한국에서 1인 게임 개발자로 살아가는데 있어선 사회적인 인식과 제도적인 어려움도 뒤따른다는 점을 감안해야 한다. 위에 적은 예시로 든 게임들은 대략 3년여 정도 걸렸는데, 한국에서 3년 씩이나 혼자 게임 개발한다고 하면 곱게 볼 사람은 거의 없을 것이다. 그렇다고 북미처럼 회사를 다니면서 틈틈이 하기엔 월화수목금금금의 압박이... 게다가 어떻게 만들어도 그 다음엔 게등위의 심사를 거쳐야 하는데 심사비의 압박이 덮쳐오고, 그것도 다 통과해 어찌어찌 내놓아도... 아아, 인디개발자의 앞날은 어둡다!

4.4.2 동업하기

뜻과 마음이 맞는 사람끼리 하는 것이 좋다. 인터넷으로 구했다간 마음고생이 심할 것이다. 다만 빠르고 많이 구해서 솎아내기 수월하다. 명확하고 논리적인 메뉴얼을 작성하지 못하는 게임 기획자, 기능 구현할줄 모르고 짜집기하는 코더프로그래머는 경계 대상이다. 그 전에 기확자와 개발자는 항상 충돌한다는게 함정

의외로 이렇게 소규모로 만들어졌어도 유명한 팀이 제법 있다. Sugar Cube : Bittersweet Factory를 만든 터틀 크림이나 송 오브 더 월드를 개발중인 Team D.T.R. 등. 어려워 하지 않고 희망을 갖는 것도 좋다. 물론 위에서 지적한 문제들은 고려해가면서

참고로 동업을 한다는것은 단기적인것이 아니라 장기적인 안목으로 보아야 한다. 되도록이면 동업자는 나이차가 얼마 안나는 또래를 대상으로 구하며 가장 좋은 동업자는 학교 친구 또는 오래 알아온 너무 오래 알아 흑역사도 알것같은사람일것이다. 말이야 쉽겠지만 동업이란것도 사람사이에 만들어지는 작은 사회다. 마음이 맞지않는 사람들로 구성된 팀은 당연히 공중분해가 너무 쉬우며, 오래 알고 지내서 허물이 없는 사이라도 마찰을 빚는일이 생각보다 많다. 그러니 되도록이면 오래 교류해온 사람들과 동업을 하도록 하자.이것의 또다른 나름댜로의 장점은 사람을 걸러낼 필요가 거의 없다는점.

굉장히 힘든 것이 동업인데 나는 프로그램을 하고 동업자1은 기획 동업자2는 그래픽을 하기로 했다고 한다면 의견 조율이 힘들다.여럿이 게임을 만들기 때문에 누군가 리더의 역할을 해야한다. 하지만 동업자이고 파트가 다르지만 거의 동등한 위치이기 때문에 누군가의 말에 의해서 내 의견을 굽히고 남의 의견을 반영해서 일을 해야한다는 것을 불만 없이 받아 들이기란 여간힘들지 않기 때문이다. 사장이고 직원이라면 시키는대로 해야하니까 별 문제가 없는데 동업은 아니다. 내가 만들고 싶은 게임고 동업자1, 동업자2가 만들고 싶은 게임이 얼마나 똑같을까? 누군가 주도해서 팀을 꾸렸지만 누구의 명령을 받고 그대로 해야하는 위치들이 아니라서 처음에 주도했던 사람이 만들고자했던 게임이 나올 확률이 제로에 가깝다.

그럼 처음에 주도했던 사람이 만들고자 했던 게임이 잘될 게임이냐? 고 반문할 수 있겠지만 그럴수도 있고 아닐수도 있다.
처음에 생각했던 반짝하는 아이디어 그대로 게임이 나온 경우와 의견이 분분해서 서로 타협해서 반짝하는 아이디어가 사라진채 만들어진 게임의 경우 어떤 게임이 성공확률이 높을까? 개인적으론 전자라고 본다. 후자의 경우는 유행을 따라가는 경우가 많을수 있고 혹은 너무 개인취향일 가능성도 높다. 유행을 따라가면 이미 철지난 게임이 될 가능성이 높고 개인 취향일 경우 호불호가 너무 극명하게 갈릴 수 있다.
모바일 게임은 물론 짝퉁 게임도 재미있게 만들면 성공하는 경우가 있지만 대부분은 반짝이는 아이디어로 성공한 경우가 많다.
예로 모뉴먼트 밸리, Tiny Wings, INKS, Doodle Jump, 앵그리 버드...
앵그리버드를 처음에 생각해서 만들자고 했는데 동업자들이 너무 재미없다고 해서 그들의 의견을 반영 게임성이 틀려졌다면 성공 못했을 가능성이 더 많다고 보여진다.

5 관련 문서

• 비디오 게임
• 게임 개발자
• 프로그래머
• 프로그래밍