이 블로그는 게임 개발자들이 코딩을 좀 더 잘할 수 있는 방법을 주제로 다루고 있습니다. 객체지향 프로그래밍, 함수형 프로그래밍 등 프로그래밍 언어에 관한 이야기도 있고, 디자인 패턴, 코드 스멜 및 리팩토링, 테스팅 등 소프트웨어 엔지니어링 프랙티스에 관한 이야기도 있습니다.

이런 이야기를 쓰는 이유는 제가 경험한 게임 개발은 다른 분야에 비해서 프로그래밍 실력이나 개발 방법론 등 여러 면에서 상당히 뒤떨어져 있었기 때문입니다. 예를 들어, 게임 개발팀이 코드 리뷰를 전혀 하지 않고 있다는 사실을 알았을 때 충격이었고, 어떤 PD는 코드 리뷰가 안 그래도 바쁜 게임 개발에 마이너스 요인이라고 말하는 것을 듣고 더 충격이었습니다.

개발자들이 해보지도 않고 “저 포도는 시어서 못 먹을거야”라고 말하는 것 아닙니다. 어떤 개발 방법론 등이 좋다는 얘기를 듣고 어설프게 1-2번 시도를 해보다가 초기 시행 착오 단계만 거치고 이 방법이 게임 개발에는 안 맞다고 결론낸 경우가 더 많았습니다. 코드 리뷰만 해도 코드 리뷰를 통해 무엇을 얻을 것인지 많이 고민하고 경험하는 일이 필요한데, 코드 리뷰 경험 없는 개발자들에게 모든 코드는 상호 리뷰해야 한다는 원칙만 가지고 강제하면 리뷰를 위한 리뷰에 그치기 때문입니다.

가장 큰 문제는 게임 개발이라는 특수성을 지나치게 강조하는데 있습니다. 게임 개발은 일반적인 소프트웨어 개발과 다르기 때문에 이미 다른 소프트웨어에서는 당연하게 여기는 기본적인 프랙티스조차 게임 개발과는 맞지 않다고 결론 내리고 비효율적인 방법을 고집하는 경우가 꽤 있습니다. 특히, 게임의 특성상 기획이 자주 바뀌기 때문에 코드를 처음부터 잘 만들 필요가 없다고 말합니다. 하지만 개발 방법론 자체가 변화하는 요구사항에 쉽게 대응하려고 나왔다는 사실을 생각하면 이 말이 설득력이 없다는 사실을 쉽게 알 수 있습니다.

물론 코딩 실력이 게임 개발에 있어서 가장 중요한 요소이면 이런 이야기를 할 필요도 없습니다. 자연스럽게 코딩을 잘 하는 팀이 성공하고, 그렇지 못한 팀은 도태될 것이기 때문입니다. 하지만 게임 개발이라는 게 종합적인 예술이고, 성공/실패의 차이가 워낙 큰 흥행 산업이다 보니 코딩 하나만 가지고 성공/실패의 인과 관계를 따지기가 어렵다는 것이 문제입니다.

사실 게임 개발사 입장에서 코딩을 잘하는 게 중요하지 않을 수 있다고 생각합니다. 어차피 출시도 못 하는 게임이 즐비한 판에 오랜 기간 유지보수를 잘하기 위한 코드를 준비한다는 게 이치에 맞지 않고, 게임이 한 번 성공하면 어느 정도의 비효율성을 상쇄하고도 남을 만큼 큰 레버리지가 나오기 때문입니다. 개발이 200% 정도 비효율적이라고 해도, 게임이 성공하면 그 정도는 개발자 많이 충원해서 해결하면 된다는 결론이 나오는 것이죠.

하지만 개발자 입장에서 코딩을 잘하는 건 중요합니다. 코드의 품질이 곧 삶의 품질이기 때문입니다. 아무 것도 아닌 버그 하나 잡으려고 며칠 밤을 꼬박 새거나, 계속해서 바뀌는 요구사항을 땜질로만 대응해서 기능 하나 만들면 다른 기능 2-3개가 안 되는 상황이 되면 개발자만 괴롭습니다. 어쨌거나 시간은 정해져 있고, 소중한 시간에 뭔가 유의미한 것을 만들지, 땜질만 할 것인지는 개발자의 코딩 실력이 결정하기 때문입니다.

회사나 PD가 대충 돌아가게만 짜라, 코드 리뷰하지 마라, 테스트하지 마라고 이야기하는 건 내 삶의 품질을 희생해서 개발 일정을 맞추라는 말입니다. 근데 이게 역설적으로 게임 개발이 일정을 못 맞추는 가장 큰 이유입니다. 코드 품질을 희생하는 건 은행에서 빚내는 것과 마찬가지라서 언제가는 갚아야 하고, 미룰수록 더 커지기 때문입니다. 빚내는 사람과 갚는 사람이 따로 있는 경우도 많습니다. 엉망으로 짠 코드를 나중에 유지보수하는 사람은 남이 빌린 빚을 대신 갚아주는 노예나 마찬가지인 셈입니다.

정리하면, 개발자에게 복지란 코드의 품질입니다. 그리고 코딩의 잘해야 하는 이유는 그게 개발자에겐 삶의 질이기 때문입니다.