욕망.
게임을 만들기 위해서 가장 중요한 덕목입니다. 게임을 만들고 싶은 욕망이 없는 사람은 게임을 만들 수가 없죠. 저는 현재 31살의 게임프로그래머로서, (웬만한 게이머들은 이름을 대면 알 거 같은 느낌이 드는 게임의) 프로그램팀장을 하고 있습니다. 저 역시 게임을 만들고 싶은 욕망 때문에 일을 시작했죠.

게임을 접하고 좋아하는 거야 아주 어렸을 때 일이지만, 본격적으로 게임을 만들어야 겠다는 생각이 든 것은 고1때의 일입니다. 중3때 접한 듄2[각주:1]를 보고, 나중에 저런 게임을 만들면 정말 멋진 사람이 될거 같은 느낌이 들었죠. 이리저리 PC통신으로 (93년 당시) 알아본 결과, 요즘 게임은 보통 C로 만든다는 것을 알아냈고, 서점에서 찾아볼 수 있었던 책 중에서 가장 얇은 C언어 입문서를 사들고 왔습니다. 그게 94년, 고1때의 일이죠.

물론, 그 전, 초등학교(저는 국민학교를 다녔습니다만) 때 다들 하듯이 GW-BASIC[각주:2]등으로 기본적인 프로그래밍은 익혔죠. 컴퓨터학원 다니면서 심심풀이로 테트리스나 15-퍼즐이나 오목같은 간단한 게임을 만들면서 지내곤 했습니다. 하지만, 거기까지가 전부였죠. 베이직의 파일입출력을 끝끝내 이해할 수 없었기에 그보다 대규모의 프로그램은 만들 수가 없었습니다. (지금 생각해도 베이직의 파일입출력 라이브러리는 괴악하기 그지없습니다) 베이직으로는 고등학교때 컴퓨터동아리에서 '땡겨[각주:3]'내기 테트리스 짜기나, Dragon Curve[각주:4](쥬라기 공원의 각 장 앞부분에 나온 그 드래곤 커브)를 Q베이직[각주:5]으로 구현하며 논 것이 거의 마지막이었습니다.

베이직의 한계를 느낄 무렵, C라는 언어의 존재를 알게 되면서 C언어 책을 고를 때, 가장 중요한 기준은 (위에서도 썼지만) '얇은 책'이었습니다. 저는 나름 독서광이었고, 새로운 것을 접할 때는 간략하게 개괄적으로 설명한 책이 더 나에게 적합하다는 것을 알고 있었으니까요. 자신에게 무엇이 가장 적합한지를 아는 것이 중요했던 것 같습니다. 만약 C언어의 모든 면을 자세히 설명한 TCPL[각주:6]같은 책을 골랐더라면 인내심이 한없이 0에 가까운 저는 이내 포기하고 말았겠죠.

제 인내심은 욕망을 지지할 정도로 견고하지는 못하다는 점을 알고 있었습니다. 게임 제작을 하고 싶다고 하더라도, 자신의 특성을 파악해야 했던 것이죠.

(다음에 계속)
나는 이렇게 프로그래머가 되었다 -2-



필자 : Uhm

경력 6년차의 게임 프로그래머. geek의 화신이며 포스를 수련한다는 소문도 있습니다.
홈월드나 토탈어나힐레이션, COH 같은 RTS와 FPS를 좋아하지만 요즘은 기묘하게도 와우를 하는 시간이 더 많은 게이머입니다.

언제나 후배들에게  포스의 어두운면에 대한 주의를 설파하는 뼛속까지 프로그래머.

  1. Westwood Studio의 실시간 전략 시뮬레이션 게임. 이후 실시간 전략 시뮬레이션 장르의 효시가 되었다.
    [본문으로]
  2. MS에서 만든 행번호 기반의 BASIC. [본문으로]
  3. 짜먹는 펜슬형 빙과류의 상품명. [본문으로]
  4. 종이 띠를 한 방향으로 절반씩 접은 자국을 90도로 꺾으면 나타나는 형상. 간단한 프랙탈 도형의 예로 자주 소개된다.
    [본문으로]
  5. 통합 IDE를 가진 MS의 BASIC 구현. MS-DOS와 함께 배포되었다. [본문으로]
  6. The C Programming Language. C언어의 창시자인 커니건, 리치가 쓴 C언어의 바이블이라 할 수 있는 책.강컴 링크 [본문으로]
최근에 저희 회사에서는 신입 프로그래머를 뽑았습니다. 자그마하지만, 게임개발팀의 팀장을 맡고 있다보니 신입 프로그래머를 뽑을 때 무엇을 봐야 하나를 고민하게 되죠. 면접을 보면 신입은 누구나 "아직 부족하지만 열심히 하겠습니다"라고 합니다만, 열심히 하고 싶은 것과 열심히 할 수 있는 것을, 회사 입장에서는 구분할 수 있어야 합니다.

그 사람의 의욕과 능력을 구분하기 위해서, 저희는 면접때 오랄 테스트를 보기로 했습니다. 문항을 대략적으로 7~8개의 카테고리로 나누고, 면접자가 자신있는 분야를 선택하라고 했죠. 떨어뜨리기 위한 시험이 아니라 그 사람이 뭘 할 수 있는가를 알아보기 위한 것이므로, 본인이 가장 잘할 수 있는 분야에 대해 물어보는 방향으로 정했습니다.

그 8개의 카테고리는 다음과 같습니다.
  • 시스템
  • 언어
  • 자료구조
  • 디자인패턴
  • 렌더링
  • 수학/물리
  • 게임로직
  • 네트웍

이는 게임을 만들기 위해서 필요한 대략적인 기초지식을 커버하며, 이 모든 것을 잘하는 사람을 요구하는 것이 아닙니다. 한가지라도 잘 알면 회사에서는 그에 해당하는 일을 맡기고 진행하면 되는 것이니까요. 단, 질문은 그 자리에서 당장 대답하거나 실제로 보여줄 수 있도록 명확해야 합니다. 그래야 평가가 가능하죠.

문항의 예를 들어보죠

  • 시스템 : 유니코드 문자열의 인코딩 종류를 알고 있는가?
  • 시스템 : 윈도우 동기화 객체의 종류를 알고 있는가?
  • 시스템 : 기본 메모리 할당 라이브러리의 문제점을 알고 있는가?
  • 언어 : 가상함수 테이블 메커니즘을 알고 있는가?
  • 언어 : 템플릿의 명시적 특수화와 부분 특수화를 알고 있는가?
  • 언어 : STL 펑터와 프리디케잇을 만들 수 있는가?
  • 자료구조 : 링크드 리스트를 슈도코드로 아웃라인을 짤 수 있는가?
  • 자료구조 : 주어진 코드의 시간복잡도를 Big-Oh 표기법으로 계산할 수 있는가?
  • 디자인패턴 : 널리 알려진 패턴(컴포짓,싱글톤 등)을 클래스 다이어그램으로 그릴 수 있는가?
  • 렌더링 : 그림자 렌더링 기법의 종류를 알고 있는가?
  • 렌더링 : 텍스쳐좌표 (0,0)인 스프라잇의 샘플링 오차를 설명할 수 있는가?
  • 수학/물리 : 가속도운동하는 물체의 위치를 시뮬레이션하는 적분 코드를 작성할 수 있는가?
  • 수학/물리 : 간단한 기하도형간의 충돌검출을 슈도코드로 짤 수 있는가?
  • 게임로직 : 간단한 게임의 게임스테이트 전이를 스테이트 다이어그램으로 그릴 수 있는가?
  • 게임로직 : 전형적 캐릭터의 스테이트 전이를 스테이트 다이어그램으로 그릴 수 있는가?
  • 네트웍 : 전형적 상황에서 오가는 간단한 패킷을 설계할 수 있는가?


대충 이정도입니다. 실제 준비한 문항은 위 목록의 약 2배가량입니다. 각 문항은 아무렇게나 뽑은 것처럼 보일지는 몰라도, 각 문항에서 알아보고자 의도하는 바가 있습니다. 그중에서도 "~~할 수 있는가?"로 되어 있는 문항은 화이트보드에 직접 해보라고 시킵니다. 하드해 보일 수도 있지만, 이 문항의 목적은 정답을 맞추는 것이 아닙니다. (물론 올바른 답을 내놓으면 더할나위 없지요) 그 사람이 이 분야에 어느정도 노력해 왔는지를 측정하여 앞으로 얼마나 노력할 수 있는지를 외삽하는 용도로 물어보는 것입니다.
제 입장에서는, 게임프로그래머란 이정도에는 관심을 가지고 있어야 일을 맡길 수 있다고 생각하는 쪽입니다.

'칼럼' 카테고리의 다른 글

이명박정부와 게임업계  (0) 2008.04.17
World Of Goo  (2) 2008.03.21
스톰윈드의 놀라운 비밀  (0) 2008.03.20

+ Recent posts