게임 출시전 개발자가 갖춰야할 마음가짐
아시는 분들은 아시겠지만 제가 2011년 9월에 스페이스 마린이란 게임을 출시했습니다. 다음은 이 게임을 마무리하는 도중 느꼈던 점을 아주 간단히 길게 정리해 놓은 글입니다. 게임을 마무리 지을 때 가져야할 프로그래머의 마음가짐, 아주 당연한 거라고 생각해왔는데 모르는 분들도 좀 계시더군요.게임 출시전에 가져야 할 마음가짐이란 간단히 말해 조홀라~ 조심하는 겁니다. 아무래도 코드를 수정 할 때마다 새로운 버그를 만들 확률이 높아지거든요. '뭐~ 버그 좀 만드는 거야 어떻다고... 나중에 고치면 되지~' 하시는 분들도 있을텐데요. 이런 마음가짐은 게임 마무리 단계에서는 먹히지 않습니다. 게임 출시 직전에 모든 것을 테스트할 시간이 굉장히 부족하거든요. 특히 몇 년 동안 제대로 작동하던 기능들을 전부 다 테스트할 수 있는 여력은 없지요.저는 주로 Xbox 360 및 PS3용 콘솔 게임을 개발합니다. 콘솔게임이 시중에 나오려면 반드시 콘솔 제작자(마이크로소프트 및 소니)가 정해 놓은 기술 테스트를 통과해야 하죠. 이 테스트를 신청한 시기부터 그 결과를 들을 때까지 걸리는 기간이 대략 1달입니다. 근데 만약 부주의하게 만든 버그 때문에 이 테스트에 실패하면 어떻게 될까요? 뭐, 버그 고쳐서 다시 테스트 신청을 합니다. 또 1달 기다리죠. 여러 번 버그를 만들면 어쩌죠? 뭐, 출시일이 지연되겠죠. 마케팅 하시는 분들 이미 돈 다 퍼다 부었는데....... 근데 이게 전부일까요? 아뇨... 테스트를 신청할 때마다 돈도 내야합니다. 얼마냐고요? 별로 안비쌉니다. 한 번에 몇 천만원 정도... -_- 왠만한 프로그래머 연봉 한 번에 날라가는 건 쉽죠. 자, 이제 문제점을 아셨나요? 출시날짜를 놓쳐서 돈 날리고 테스트 신청 하느라 또 돈 몇 번 날립니다. 이래도 별 문제가 아니라고 생각하신다면 여러분이 만든 버그때문에 테스트 실패할 때마다 봉급에서 몇 천 만원씩 까면......이제, '뭐~ 어떻다고?'하고 생각하시는 분은 없겠죠? -_-그럼 제가 이번에 느꼈던 경험을 바탕으로 게임출시 전에 반드시 해야할 일과 하면 안되는 짓거리(?)를 간단히 설명드리겠습니다.고장난 것만 고친다: 위에서도 말씀드렸듯이 코드를 수정할 때마다 새로운 버그가 생길 확률이 높아집니다. 게임 출시직전에 제대로 작동하고 있는 코드를 괜히 쓸데없이 만져서 프로젝트 전체를 망칠 위험을 감수하는 건 바보같은 짓입니다.타인의 코딩 스타일을 자기 기호에 맞게 바꾸지 않는다: 코드를 이리 저리 옮기는 것, 빈 칸 4개를 탭 하나로 바꾸는 것, 한 줄로 길게 쓰인 코드를 보기 좋게 여러 줄로 나누는 것 등... 뭐 다 좋은 일인데... 이런 짓을 하다가 버그를 만드시는 분들이 꽤 됩니다. 아무리 훌륭한 프로그래머도 인간인지라 실수는 하기 마련입니다. (본인을 절대 실수 안한다고 생각하시는 분들 계시나요? 당신은 무지할 뿐입니다... -_-) 각 프로그래머가 1달에 한 번만 실수해서 버그 만들어도 프로그래머 30명을 가진 팀에서는 하루에 하나씩 버그가 나옵니다. 남의 코딩 스타일, 이딴 게 맘에 걸리시더라도 그걸 굳이 게임 출시전에 고칠 필요는 없습니다. 그냥 노트에 적어놨다가 다음 게임을 만들 때 고치세요. 또 한가지 말씀 드리고 싶은 것은 개인적으로 정말 맘에 안드는 코딩 스타일이 있는데 사내 코드베이스에 그런 스타일이 만연해 있으면 그건 사내 프로그래머들이 동의한 코딩 스탠다드일 가능성이 높습니다. 이거 맘에 안든다고 자기 맘대로 바꾸기 전에 본인이 사회부적응자는 아닌지 한 번 진지하게 고민해주는 센스... ㅇㅇ?게이머(또는 테스터)를 만족시킬 수 있는 것만 고친다. 프로그래머의 자기만족은 무시한다: 수학적으로 옳지 않은 게 보인다고요? 최종 사용자(게이머)가 신경 쓸만한 것이이 아니면 고치지 마세요. 그 흔히 쓰는 포토샵의 레이어 블렌딩조차 수학적으론 틀리다는 거 아시나요? 하지만 포토샵을 사용하는 아티스트들은 별로 신경도 안쓰죠. 마찬가지로 게이머들도 수학공식에는 크게 신경 않씁니다. (오히려 수학공식 매우 싫어할껄요? -_-) 수학적으로 옳아보겠다고 프로그래머 맘대로 뭔가를 수정하면 이로 인해 피해를 보는건 동료 개발자들 뿐입니다. 다음과 같은 상황을 생각해 보죠. "아티스트 아찌들~ 울 게임에서 수학적으로 틀린 게 있었어요. 그래서 제가 이렇게 올바르게 고쳤거든요.. 무핫핫~ 그래서 최종 조명 결과가 좀 달라보일테니... 아트들을 다 고쳐주세요! 지난 2년 동안 만들어 왔던 아트들 다 고칠 시간 있죠?..... 뭐 마감이라서 없다구요?!? 하... 하지만 이게 수학적으로 맞는건데... 좀 해욧!" 이딴 식의 주장을 하는 본인을 발견하신다면... 우선 남들의 업무를 존중하는 법부터 배우세요. 본인 만족을 위해서 수학공식 파는 것도 좋고 제가 상관하고픈 바도 아닌데... 남들에게 불합리한 피해를 끼친다면 그냥 퇴사하고 절에 들어가서 홀로 게임 만드시라고 권해 드리겠습니다.그래도 반드시 고쳐야할 것이 있다면 그로 인해 조금이나마 영향을 받을만한 다른 개발자들 모두의 허락을 받는다: 본인이 고쳐야한다고 생각하는 것과 동료 개발자들이 고쳐야 한다고 생각하는 것에는 차이가 있을 수도 있습니다. 그들이 고쳐야한다고 생각하는 것이 더 중요할 수도 있지요. 만약 그렇다면 다른 개발자들의 업무부담을 늘리는 버그수정은 차라리 안하고 넘어가는게 납니다.이 위에 적은 이야기들... 사실 게임을 하나라도 출시해 본 프로그래머라면 다들 알고 있을 법한 상식이라 생각했습니다. 특히 콘솔게임을 출시해봤다면. 그런데 스페이스 마린을 마무리 하는 도중 이런 믿음이 깨진 일이 있었죠. 자칭 경력많은 콘솔 게임 프로그래머라고 하는 작자가 하루가 멀다하고 무수한 버그를 만들어 냈고, 제가 그걸 디버깅할 특권(?)을 부여받았더라죠. 근데...... 이 모든 버그들이 발생한 이유가 바로 이 몰상식한 놈이 게임 출시전에 갖춰야할 마음가짐을 몰랐기 때문이라지요..... 써글... -_-제발 프로그래머 아찌들 부탁인데... 게임을 출시할 때만큼은 좀 책임감있게 코딩합시다... 네?
