게임 프로그래머의 소양
 예전에도 게임 프로그래머의 역량이나 채용 문제로 글을 썼던 기억이 있는데, 곰곰히 다시 읽어보면 그때랑 비슷비슷하게 생각하는 것들도 있는 반면, 상당히 생각이 달라진 부분도 눈에 띄는 것이 재미있습니다. 그때보다 주변에 있는 프로그래머들이 역량이 올라가고 개발 환경도 아마추어 티는 벗고 그러다보니, 뭐랄까, 팀과 게임을 바닥부터 부트스트래핑하는 단계의 문제는 더 이상 고민하지 않아도 되는 상황이 되어 그런가 싶기도 합니다만….

 이전에는 게임 프로그래머가 가져야 할 정성적인 소양에 대해서 얘기를 했었다면, 오늘은 좀 더 기술적인 소양에 대해서 얘기를 해볼까 합니다. 사실 예전에는 이런 얘기를 할 수 없었던 것이, 생각이 그만큼 가다듬어지지 않았기 때문이 아닐까 싶어요. 비주얼 프로그래밍이나 네트웍 프로그래밍이나 엔진이나… 뭐 이런 것들에 대해서 아는 게 별로 없었기 때문이 아닐까? 싶은 게 솔직한 심정이네요.

이어지는 잡스러운 이야기▼

 사실 게임 프로그래머의 소양이란 걸 제대로 정의할 수 있을까? 그런 의문을 꽤 오래 갖고 있었습니다. 다들 쓰는 엔진이나 미들웨어도 다르고, 비주얼 프로그래밍, 네트웍 프로그래밍, 사운드 프로그래밍, 로직 프로그래밍, … 분야도 다양한데 지식 수준을 갖고 따질 수도 없고. 이런 기술의 습득 순서도 다르고 각 기술 분야마다 깊이도 다르고…. 비교 자체가 불가능하다고 생각을 꽤 오래 했었는데,

 생각이 확 달라진 것은 플래시 게임 제작자들이 약진하기 시작하면서부터였습니다. 왜, 1인 개발자들이나 좀 개념있는 디자이너들이 플래시를 사용해서 작은 게임 하나씩 만들어서 내놓는 것들이 이젠 굉장히 보편적이 되었잖아요? 마치 무거운 비주얼 스튜디오 이전의 퀵 베이직이나 GW-Basic으로 게임 만들던 시절로 돌아간 것 같이 게임 제작에 대한 접근성이 퀀텀 점프를 해버린 셈인데,

 바로 이 지점에서 게임 프로그래머의 소양이란 무엇인지 극명하게 드러내주는 질문을 던져볼 수가 있습니다. 팀에 게임 디자이너와 아티스트들이 있고, 이 사람들이 전부 다 플래시 액션 스크립트를 사용해서 게임을 만들 능력이 있다고 칩시다. 과연 이 팀에 게임 프로그래머는 필요한가요?

 워우, 분노의 목소리가 벌써부터 들리는 듯 합니다. 당연하죠. 아니, 그럼 최적화는 어쩔 것이며 네트웍은 어쩔 거고 플래시에선 3D도 안 되잖아 등등. 네, 맞습니다. 그런 반론을 제기할 수 있는 지점이 게임 프로그래머가 필요한 이유를 설명해주는 것, 맞습니다. 그런데, 거기서 얘기를 끝내버리면 남는 게 없고 발전도 없으니까, 우리 한 번 좀 더 솔직하고 섬세하게 따져보도록 하지요.

 거대한 게임 코드 볼륨 중에서 최적화를 필요로 하는 부분은 몇 군데나 되나요? 데이터 드리븐하고 스크립트 만들어서 기획자들한테 주려고 애쓰는데 최적화 걱정하면 그러질 말아야죠. 네트웍 프로그래밍을 할 줄 아는 프로그래머는 네트웍 프로그래머라고 해서 게임 (로직) 프로그래머와는 약간 다른 직군으로 치는 것 같고, 3D를 할 줄 아는 비주얼 프로그래머도 마찬가지구요. 게임 프로그래머가 꼭 필요하냐, 이 질문에 대한 답이 된다고 보긴 어려워요.

 그렇게 게임 프로그래머가 아니라 다른 전문 프로그래머가 필요한 상황을 솔직하게, 정말로 솔직하게 덜어내고 보면, 최적화를 가능하게 해주는 알고리즘과 컴퓨터 아키텍처에 대한 이해, 거대한 코드 볼륨을 긴 개발 및 서비스 기간 동안 관리할 수 있도록 복잡성을 제어하는 능력, 게임 디자이너나 아티스트에게 손쉽게 재미와 독특한 경험을 만들 수 있는 재료를 던져주는 기술 등, 언뜻 보기에 정성적인 능력들이 소수 남습니다. 하지만 저는 이런 능력이야말로 게임 프로그래머가 갖추고, 또 계속해서 닦아 나가야 할 전문 소양이라고 보는데요,

 네트웍 프로그래머라든가 비주얼 프로그래머, 사운드 프로그래머 같은 전문 역량을 가진 사람은 희소성과 별개로 게임 개발팀에 많은 수가 필요하지 않습니다. 테크놀러지 개발 드라이브가 강한 조직이 아니라면 이 사람들을 근본적으로 미들웨어로 대체할 수 있는 인력으로 간주할 것이고, 개발 드라이브가 강한 조직이라고 해도 다른 파트와 조직 내부의 형평성을 고려하자면 많은 수를 킵하는 것은 부담이 됩니다. 따라서 그쪽으로 성공할 수 있는 게임 프로그래머는 매우 소수일 것이고,

 또 포션 먹으면 HP 회복 같은 게임에 필요한 로직을 즉시즉시 구현하는 능력도 초장기적으로 봤을 때 별로 비전이 없습니다. 개발 도구의 트렌드는 점점 게임의 컨텐츠를 프로그래머 관여를 최소한도로 줄이고 게임 디자이너나 아티스트가 직접 만들 수 있도록 하는 방향으로 가고 있기 때문이죠. 상식적으로도 게임은 게임을 재밌게 할 수 있는 사람이 직접 만들어야 이터레이션이 빨라져서 성공 확률이 높아질텐데, 게임 디자이너가 게임 로직 프로그래머랑 입씨름하느니 언리얼 키스멧으로 버벅대더라도 맘대로 만들고 말죠??

 전문 지식과 즉자적인 게임 로직 구현 능력을 제하고 남는 것은 게임 루프를 만들고, 그 안에 객체를 만들고, 시간에 따라 객체를 업데이트하고, 입력을 받아 객체에 전달하고, 그 객체를 외부에 노출해주고, 객체 간의 관계를 정리하고, 객체 간에 동작의 흐름을 조율하고, 필요에 따라서 이런 객체를 센스있게 보여주는…이런 작업들이예요. 정말로 게임 밖에서는 보이지 않는 게임의 내부 구조를 설계하고 구현하고 관리하는 작업들인데, 이런 걸 잘 해내는 능력이야말로 게임 프로그래머의 전문 소양이란 얘기죠.

 많은 게임 제작 회사에서 이런 부분을 게임은 그냥 돌아가면 되지, 이런 기분으로 소홀히 생각하는데, 솔직히 제가 판단하기에 운영 비용의 대부분은 여기서 빠져나갑니다. 예를 들어 그래픽이 느리다든가 네트웍이 느리다든가, 뭐 이런 건 오히려 잘 해결돼요. 많은 게임에서 처음엔 이렇게 느렸는데 결국 나중엔 이렇게 최적화했다, 뭐 이런 얘긴 많잖아요? 상대적으로 체계화되고 전문화된 분야니 만큼 무용담도 많고 해결책도 많아요.

 그런데 진짜 골치아프고 계속해서 라이브 개발팀과 운영팀을 괴롭히는 버그들은, 어느 모드에서 마을에 돌아왔더니 PVP에서만 쓸 수 있는 스킬을 마을에서 쓸 수 있어서 문제, 라든가 누구한테는 줄 수 없어야 하는 아이템을 이러저러한 경로로 줬더니 줄 수 있게 되어 문제라든가, 이러저러한 기능을 추가했더니 그러저러한 기능이 터진다든가… 게임 내 객체의 관계가 복잡하기 때문에 발생하는, 한 두가지 특성으로 묶을 수 없는 것들이 대부분입니다.

 시각적인 예를 들자면 이런 거예요. 빵판에 칩 꽂아서 컴퓨터를 만들었다고 쳐요. 칩 위치도 대충 꽂고 수백가닥 전선이 막 얽히게 꽂았긴 해도 동작이 되서 기분이 좋았는데, 어느 날 여기에 새 칩(=새 기능)을 끼워야 할 일이 생겼어요. 그런데 칩 꽂을 자리가 마땅치 않아서 칩 몇 개의 위치를 옮기고 그에 따라서 30-40개쯤 선을 뽑다 보니 칩 핀도 몇 개 부러지고, 빠지면 안 될 선도 빠지고, 회로도 동작을 안 하고, 그렇다고 돌려놓자니 원래 칩이랑 선 위치도 까먹고….

 오래된 코드 플랫폼에서 새로운 기능을 만들어 끼워넣는 것이 단순히 새 기능을 만들어 넣는 것보다 훨씬 많은 시간이 필요한 게 바로 이런 일이 일어나기 때문이란 거죠. 여기서 저는 역량있는 게임 프로그래머는 이미 조립할 때부터 새 칩을 끼울 만한 빈 공간을 충분히 남겨 놓았을 거고, 선들도 대충 기능에 따라서 색깔별 케이블 타이로 묶어서 정리해 놨기 때문에, 새로운 칩 자체만 만들어서 선 몇 개만 꽂으면 OK. 이런 상태를 유지할 수 있는 사람이어야 한다는 얘길 하고 싶은 거예요.

 저는 게임 프로그래머로 일하시는 분들이 이런 역량을 익히고 훈련할 수 있는 기회를 얻기 굉장히 힘들다는 게 진심으로 슬픈데, 소프트웨어 엔지니어링을 공부하거나 작은 게임을 만들어보고, 다른 게임의 구조를 역기획 해 보는 게 그나마 좋은 훈련 방법이긴 해요. 하여튼 정말이지 게임 프로그래머 개개인이 이런 역량이 자신의 근본적인 경쟁력이라고 생각해줬으면 하고, 게임 제작 커뮤니티가 섹시한 최신 기술도 중요하지만, 이런 부분에 구조화되고 축적된 지식이 역시 필요하다는 공감대도 가져줬으면 하는 바램이 있네요.
by 매운맛나리 | 2009/02/06 00:30 | 개발 | 트랙백(1) | 핑백(1) | 덧글(34)
트랙백 주소 : http://beforu.egloos.com/tb/4058406
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from 飛烏의 둥지 at 2009/02/07 18:52

제목 : 게임 프로그래머의 소양
http://beforu.egloos.com/4058406 으로 트랙백 그런데 진짜 골치아프고 계속해서 라이브 개발팀과 운영팀을 괴롭히는 버그들은, 어느 모드에서 마을에 돌아왔더니 PVP에서만 쓸 수 있는 스킬을 마을에서 쓸 수 있어서 문제, 라든가 누구한테는 줄 수 없어야 하는 아이템을 이러저러한 경로로 줬더니 줄 수 있게 되어 문제라든가, 이러저러한 기능을 추가했더니 그러저러한 기능이 터진다든가… 게임 내 객체의 관계가 복잡하기 때문에 발생......more

Linked at 묘듈화, 코드 디자인, 프레임.. at 2009/10/05 01:44

... n Patterns C++ Development for OOo_Tricks of the Trade Massive Software Complexity http://beforu.egloos.com/4058406#none http://littles.egloos.com/2190768 jazzcake Written by happyruben October 5, 20 ... more

Commented by 빈틈씨 at 2009/02/06 00:49
길게 리플 달았는데 별 쓸데없는 내용이라 지웠고.

암튼 열심히 공부하셔서 훈늉한 게임프로그래머로 계속 남아계시라능!! ^^
Commented by 매운맛나리 at 2009/02/06 00:53
어우 왜 지우셨대요- 빈틈님의 지혜 주머니 궁금합니다!!!

격려 감사하고 열심히 살겠습니다??
Commented by 이런 at 2009/02/06 03:37
그냥 현대사회의 노가다라고 이해하는 게 구조적으로 제일 적절합니다
Commented by 매운맛나리 at 2009/02/06 12:43
어이쿠;; 그래도 게임 업계는 다른 업계보다는
게임 만드는 게 좋아서 선택하는 경우가 많을 것 같은데
그렇게 생각하면서 일하신다니 안타깝습니다.

상황 상황마다 달라서 뭐라 말씀드리긴 어렵지만
그래도 매일매일 한 걸음씩이라도 나아지다보면 10년이면 꽤 멀리 가 있지 않을까… 그런 생각이네요. ㅎ
Commented at 2009/02/06 04:37
비공개 덧글입니다.
Commented by 매운맛나리 at 2009/02/06 12:44
ㅎㅎ 재밌게 읽어주셨다니 감사합니다. 생각한지 오래되긴 했는데
딱 이거다 싶게 정리가 된 건 근래기도 하고 이런 글 블로그에 쓰는 게 껄쩍지근해서 미루다 보니 ㅎㅎㅎㅎ

리포트는 잘 받아보고 있습니다.
바로바로 답변 드리기 난망한 내용이라 묵묵히 받고는 있는데
도움 많이 받고 있으니 걱정 마시길 ㅎㅎ
Commented by 겜퍼군 at 2009/02/06 09:05
좋은내용 잘 보고 갑니다.^^ 그래도 게임업계에서 그나마 오래 살아남고 버티고 또 나름 머니도 많이 받는 직군이 프로그래머니까.. 나쁘다 혹은 발전이 없다 라고만 하기는 좀 그럴거 같습니다^^;;
Commented by 매운맛나리 at 2009/02/06 12:45
그렇죠 사실- 그만큼 좀 더 다른 직군을 포용하고 판을 크게크게 보면서 일해야할 의무도 있다고 봐요. ㅎ
Commented by 오리대마왕 at 2009/02/06 09:51
결론은 결국 게임 프로그래머와 일반 기업의 정보 시스템 프로그래머와 큰 차이가 없다~ 라고 보여요. 쌕씨한 DirectX 뭐 이런것도 중요하지만, 깔끔한 비즈니스 로직(아, 여기선 게임 로직이라고 해야 하나?) 구현이 더 중요하다로 귀결되는 것 같네요. 맞나효?
Commented by 매운맛나리 at 2009/02/06 12:46
네 그렇습니다. 오히려 일반 기업 정보 시스템 프로그래밍에서는
'비지니스 로직'이라는 단어가 익숙하고 이걸 잘 설계하는 거 쵸낸 쳐 어렵다는 걸
비교적 잘 공감하고 있다고 보는데 게임 쪽은 그에 비해서도 뒤져있다고 봐요.

비지니스 로직이라는 게 눈으로 보이지 않는 만큼 게임 프로그래머한테는
그걸 디렉터나 프로듀서 등, 결정권을 가진 사람들한테 '보여줄 수 있는' 역량도 꼭 필요하겠지요.
Commented by Sikuru at 2009/02/06 10:30
일단은 네트웍 파트인데 게임 로직 구조개선 하자(이라고 쓰고 엎자고 읽...)고 해야 할 판국이라 고뇌입니다. (...)
Commented by 매운맛나리 at 2009/02/06 12:48
어이쿠 -_- 어려운 상황이시네요. 힘내십시요.

그런 상황이 되어서 이러저러 하자고 훈수를 두게 되면 보통 권한 문제 때문에 쌈나고 사이 틀어지기 쉬운데
일단은 인간적으로 서로 친해지고 나서 우리가 정말 같은 배 타고 있잖아,
나 쵸낸 걱정되서 그래- 뭐 이런 식으로 접근하는 게 느릿느릿하지만 안전한 방법이 아닐까 싶습니다.
Commented by Sikuru at 2009/02/06 12:50
다행히 엎자~ 해도 '자, 일단 깃발 꼽자.' 분위기는 아니라 다행입니다. 므하하하;;;
어짜피 해야 할거 라는 인식은 서로 있어서 매우 다행이랄까요 =)
Commented by 매운맛나리 at 2009/02/06 12:51
ㅎㅎ 열심히 달리는 보람이 있는 상황이네요. 다행입니다.
건승하시길 바래요!! ㅎㅎㅎ
Commented by 어이 at 2009/02/06 10:32
아아... 같이 일하고 싶네요.
Commented by 매운맛나리 at 2009/02/06 12:48
ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ 감사합니다 언제든 환영이예요-
Commented by 덴드 at 2009/02/06 10:32
굳이 게임 분야 뿐만 아니라, 개발 전 분야에 해당하는 것 같습니다. 저는 구현하기 전에 요구 사항 분석-구조 분석(WBS 작성)-동적 분석(PBS작성)-클래스 설계-상세 클래스 설계 요런 식으로 하니까 차후 확장이 편하더군요. 'Code Complete'하고 '실용주의 프로그래머'에서 많은 도움을 받았습니다.
Commented by 매운맛나리 at 2009/02/06 12:50
훌륭하십니다. ㅎㅎ PBS란 단어가 좀 낯선 게 아무래도 제가 책을 설렁설렁 읽었나보군요!
두 책 모두 다시 훑어봐야 할 때가 왔나 봅니다. ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ
Commented by 랩하는좀비 at 2009/02/06 12:57
캐공감.

전 로직을 만들 때 우선 test 코드로 접근을 시작합니다.
그 다음에 리팩토링하면서 이렇게 저렇게 배치 해보고 으쌰으쌰 한 다음에 한 번 엎고(...) 다시 생각해 보지요. 낄낄낄

최근의 업무도 하나의 모듈을 만들었는데, 제가 이런 문제에 대해서는 아직 익숙치 않으니 이것저것 한번씩 엎게 되더군요.
책으로만으로는 얻을 수 없는 내용 같아요. 경험이 중요한데 말이죠. 흠흠.
Commented by 매운맛나리 at 2009/02/06 13:02
좋은 습관 나이스-

엎는 거 자체를 두려워하시면 발전이 없습니다.
물론 엎어서 클라이언트나 서버 패치를 한 번 더 하게 만들면 크리스찬 베일한테 욕 얻어먹어도 할 말 없는 거지만,

정답 설계가 나올 때까지 고민하는 것보다 중간까지 가 보고 다시 다른 시도를 해보면서 얻는 게 꽤 많습니다.
Commented by 김성균 at 2009/02/06 13:57
정리하자면 "게임플레이 코드"에도 아키텍쳐가 필요하다는 말이로군요. 100% 맞습니다.
현실에서는 많은 게임플레이 작업자들이 "요구사항이 지나치게 자주 바뀌고, 시간이 없다"라는 이유로 꼴리는대로 만드는 현상이 가끔 보입니다. 다른 관점이지만, 역시나 이 부분도 소수 정예로 제대로 가는게 오히려 생산성이 나아 보일때가 꽤 있습니다. 게임플레이 부분이야말로 XP 관점의 접근이 필요한것 같습니다.

게임 프로그래머에게 국한된 얘기는 아니지만, 프로그래밍 조직 관점에서의 문제에 대해서는 제 글도 참조해 주십시요~
http://littles.egloos.com/2190768
Commented by 매운맛나리 at 2009/02/06 14:33
소수 정예로 게임 플레이를 아키텍팅하는 것이 현실적으로 제일 나은 답인 것에 동의합니다.

사실 저도 전문 분야가 따로 있지만 이번 프로젝트에서는 게임 플레이 구조 하나는
제대로 잡고 가고 싶다는 마음에 신경을 좀 많이 쓰고 있습니다.

링크해주신 글은 이전에 읽었고, 이번 글 쓰기 위한 생각 정리에 도움이 많이 되었었네요.
Commented at 2009/02/06 17:05
비공개 덧글입니다.
Commented by 매운맛나리 at 2009/02/06 19:52
처음부터 목적지 알고 가는 거 아니고 해보면서 배우는 게 있으니까 너무 소심하게 생각하지 말고….

근데 그 쪽은 타임라인 빡빡하니까 많이는 힘들겠지만
소소한 것들부터 사이드 이펙트 없이 고치는 거 연습해보는 게 좋을 거.
Commented by 오리대마왕 at 2009/02/06 19:21
친구놈들끼리 존댓말 하는 걸 보고있자니 손발이 오무라들듯 하네요, 맛나리님.
Commented by 매운맛나리 at 2009/02/06 19:51
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 나름 재밌는데???
Commented by 飛烏 at 2009/02/07 18:22
회사에서 상용화된 오래된 게임 서비스를 맡고 있는데..
정말 공감 100% 글이네요 =_=)
Commented by 매운맛나리 at 2009/02/08 00:12
어우 고생 많으십니다.

사실 상용화해서 오래된 게임이면 회사에서도 수익을 내주기 때문에 중요한 프로젝트인데
그만큼의 관심을 받지는 못하는 경우가 많아서 안타까운 경우가 심심치 않게 있는 것 같습니다.
Commented by 아이리스 at 2009/02/23 18:21
=_= 뭐야; 알비랑 둘이;
Commented by 매운맛나리 at 2009/02/23 20:12
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 이거 재밌어
Commented by 꿀펭 at 2009/03/13 14:19
항상 OCP를 염두에 두고 (좀더)닫아놓는 곳과 (좀더)열어놓는 곳을 분류해 놓고 지금 내가 고치고 있는 부분 외에는 아웃포커싱 시킨다던가
코드 몇라인이라도 좀더 응집되게 기술한다던가
include 횟수를 최소화한다던가
게임코드가 얼마나 잘 짜여져 있는가 하는가를 정량적으로 판단하긴 어렵지만 그나마 가장 근접한 것이 include횟수와 빌드시간, 디버깅시 버그 재현시간인듯 합니다.
Commented by 매운맛나리 at 2009/03/14 19:17
사실 이런 게 중요하구나-하고 의식하게 되면 그 때부터는 관련해서 공부도 하게 되고 개념도 찾아보고 그렇게 되는데,
문제는 중요하다고 인식하지 못하는 상황이 아닐까 싶어요.

말씀하신 것들 매우 유용한 것들인데 본인이 필요하다고 생각하지 않으면 괜히 귀찮은 거 시킨다고 생각할 거란 말이죠. ㅎ
Commented by 뭘 봐? at 2009/05/11 22:40
전에도 말씀드렸지만, 게임 로직 프로그래머라고 하지 말고 SI 프로그래머라고 하면 많은 본질이 드러납니다.

물론 이런 질문은 남겠지만 말입니다. "그래서 좋아?"
Commented by 매운맛나리 at 2009/05/11 23:01
통합은 올해의 유행 단어야

:         :

:

비공개 덧글



< 이전페이지 다음페이지 >