버그가 적은 안정적인 게임 제작에 대한 베스트 프랙티스

버그가 없고 안정적인 게임 빌드를 유지하면 장기적으로 다음과 같은 이점이 있습니다.

• 버그가 적은 더 안정적인 게임을 출시할 수 있습니다.
• 적은 버그와 더 깔끔한 코드 기반으로 인해 제작 시간이 줄어듭니다.
• '빌드가 손상될' 가능성이 줄어듭니다.
• 더 쉽게 데모 버전 및 특별 빌드를 제작할 수 있습니다.

모든 AAA 빌드 방식이 인디 개발팀에 적합한 것은 아닙니다. 하지만 비용이 들지 않거나 저렴한 비용으로 팀의 규모와 관계없이 안정적인 클린 빌드를 유지할 수 있는 여러 방법이 있습니다.

혼자서 운영하는 경우라도 이 팁을 활용하면 더 개선되고 안정적인 게임 빌드를 유지하는 데 도움이 됩니다. 

무료 버전 관리 시스템(VCS)을 활용할 수 있는 오늘날에도 협업에 공유 폴더 및 Dropbox를 사용하는 팀이 있습니다. 버전 관리 없이 개발을 진행하는 것은 마치 안전벨트를 매지 않고 운전하는 것과 같습니다. 안전벨트를 매는 것이 불편하고 자유가 제한되는 것처럼 느껴질 수도 있지만, 전속력으로 장애물에 부딪히더라도 안전벨트 덕에 목숨을 건질 수 있습니다.

작업 내용을 잃는 것은 팀의 규모를 막론하고 큰 손실입니다. Dropbox 계정 해킹이나 하드디스크 고장으로 인해 며칠 또는 몇 주간 진행한 작업 내용을 잃어서는 안 됩니다.

시중에는 여러 무료 솔루션이 있습니다. Perforce, Git, SVN은 모두 무료 버전을 제공합니다. 또한 Unity에 Unity 팀즈가 내장되어 있으면 일이 더 수월해집니다.

안전성과 더불어 VCS가 제공하는 또 하나의 이점은 변경 내역에 대한 개요를 확인할 수 있는 변경 내역 목록(Changelist)입니다. 위 이미지는 모든 변경 내역을 표시하는 Perforce 폴더 이력입니다.

대부분의 시스템은 변경 사항에 대한 세부 내용 입력을 강요하지 않지만, 변경 사항을 명확하게 기록하는 것이 좋습니다.

그뿐만 아니라, 변경 사항에 다음과 같은 접두어를 사용하면 '패치노트' 및 이와 유사한 문서를 쉽게 작성할 수 있습니다. 

• !B: 버그 수정
• !V: 시각적인 변경 및 개선 사항
• !G: 게임플레이 변경 사항
• !X: 패치노트에서 무시해도 될 변경 사항

VCS에 변경 사항을 입력하고 여기에 선행 접두사를 지정하면 추후에 각 기록에 대해 스크립트를 실행하여 깔끔한 패치노트 문서로 분류할 수 있습니다.
깔끔한 VCS 입력 예시는 다음과 같습니다.

"!V 폭발 파티클 효과를 키움"

“!B 무기를 집을 때 발생하는 충돌 수정"

“!G 치료 키트를 통한 체력 회복량 증가"

모든 입력 사항을 정돈되고 명료하게 유지하면, 필요에 따라 패치노트 문서를 취합하기가 매우 수월해집니다. 이는 패치노트에 기재해야 할 내용을 식별하기 위해 수동으로 최근 변경 사항을 탐색하는 것보다 훨씬 효율적인 방식입니다.

팀원 전체가 클린 빌드의 기본 사항을 숙지하는 것이 중요합니다. 클린 빌드를 유지하기 위한 5가지 베스트 프랙티스를 소개합니다.

1. 빌드를 손상시키는 코드 금지
   손상된 코드를 입력하지 마세요. 작업 중인 기능이 완성되지 않았지만 입력해야 하는 경우, 이를 비활성화하거나 변경 사항을 따로 보관하여 나머지 팀원의 작업 내용을 손상시키지 않도록 합니다. 작동되지 않는 코드를 입력하여 손상된 빌드로 인해 팀 전체의 작업이 중단되어서는 안 됩니다.
    
2. 하드 코딩된 키보드 단축키 금지
   특정 치트 및 디버깅 기능을 위한 커스텀 단축키를 추가하는 것은 편리할 수 있습니다. "F12 키를 돈 치트 키로 설정해도 괜찮을 거야. 아무도 눌러보지 않겠지?"
   하지만 이런 기능을 하드 코딩하면 잊어버리기 쉽기 때문에 매우 위험합니다. 실수로 그대로 출시될 수도 있고, 테스터가 의도치 않게 기능을 활성화하여 버그 보고서의 내용을 왜곡할 수도 있습니다.
    
3. 잘못된 코드 및 누락된 코드 표시하기
   간혹 해킹이 필요한 경우가 있습니다. 아무리 피하고 싶더라도, 일정 시점이 되면 코드에 일시적인 핵(Hack)이 있어야 합니다. 핵 또는 차선책(Workaround)을 추가할 때, 이를 코드에 반드시 찾기 쉬운 키워드로 표시해야 합니다. 핵을 //HACK으로 표시하거나 누락된 코드를 //TODO로 표시하세요. 이렇게 하면 나중에 전체 코드에서 해당 태그만 찾아 쉽게 변경할 수 있습니다.
    
4. 로그 스팸(Log Spam)
   코드에 내용을 로깅하는 것은 유용하며 문제 추적에 도움을 줄 수 있습니다. 하지만 주기적으로 로그 스팸을 정리해 중요한 경고 및 오류가 파묻히지 않게 하는 것이 중요합니다. 기능에 대한 작업을 진행하고 있지 않다면 콘솔을 최대한 깔끔하고 비어 있는 상태로 유지하여 중요한 메시지가 표시될 경우 바로 확인할 수 있게 해야 합니다.
    
5. 파일명 및 명명 규칙
   빌드는 결국 수백 개 또는 수천 개의 파일로 그 규모가 커집니다. 따라서 명료한 명명 규칙을 따르는 것이 매우 중요합니다.

새 프로젝트를 시작할 때 시간을 들여서 이해하기 편한 명명 규칙을 정하고 이를 반드시 준수하세요. 빌드에 texturetestFinal01.png 또는 backup22.fbx와 같은 파일명이 있는 경우 빌드가 매우 빠르게 지저분해집니다.

정기적으로 검사하여 프로젝트 내의 지저분한 파일명을 정리하는 것이 좋습니다.
이를 위한 몇 가지 팁을 소개합니다.

• 구체적인 이름 사용
  atkBtn.cs 대신 AttackButtonBehavior.cs 사용
• 낙타 표기법(camelCase) 또는 파스칼 표기법(PascalCase) 사용
  notsocleanfilename.cs는 MyCleanFilename.cs보다 가독성이 떨어짐
• 밑줄(Underscore)을 이용해 파일명을 명확하게 하기
  WoodenHouse_Blue, WoodenHouse_Green 등

게임을 개발하는 동안 수시로 디버깅하고 치트를 사용하게 됩니다. 다른 레벨로 넘어가거나, 돈을 추가하거나, 무적 상태가 되거나, 추가적인 적을 생성하는 등 여러 치트가 필요할 수 있습니다.

이런 치트는 필요할 때 추가하고 사용이 끝나면 비활성화할 수 있지만, 이와 같은 치트 기능을 켜고 끌 수 있는 안정적인 방법을 사용하는 것이 좋습니다.

소규모 프로젝트라도 시간을 투자하여 사용하기 쉬운 디버그/치트 메뉴를 구축하는 것이 좋습니다. 개발자가 쉽게 켜고 끌 수 있어야 하며, 일반적인 모든 치트 및 디버그 옵션에 대한 액세스를 제공해야 합니다.

이러한 방법을 사용하면 실수로 치트를 게임에 포함해 출시하는 위험을 최소화할 수 있습니다. 또한 '치트 코드'를 한곳에 모아놓으면 모든 기능을 안정적으로 작동하게 할 수 있고 확장하기도 쉽습니다.

이러한 접근 방식의 또 다른 이점은 개발을 위해 치트를 사용하는 과정을 단축하여 일상적인 제작 과정에서 많은 시간을 절약할 수 있다는 점입니다. 스크립트에서 값을 하드 코딩하는 것보다 편리한 디버그 창에서 버튼을 누르는 것이 훨씬 더 빠릅니다.

게임에는 버그가 발생합니다. 모든 게임에는 버그가 있으며 어느 게임도 예외가 아닙니다. 중요한 것은 버그를 처리하는 방법입니다.

버그를 효율적으로 처리하는 워크플로는 꽤 간단합니다. QA 부서에서 버그를 찾아 이를 버그 트래킹 시스템에 입력하면 됩니다. 그 후 해당 문제를 개발자에게 배정하면 개발자가 문제를 해결하고 해결된 상태로 표시합니다. 최종적으로 QA 팀에서 문제를 확인하여 문제가 처리된 것으로 표시합니다. 이처럼 간단한 3단계 과정으로 이루어집니다. 

그런데 QA 전담 부서가 없나요? 개발자가 테스터의 역할까지 맡고 있나요?

걱정하지 마세요. 버그 관리에는 많은 일이 필요하지 않습니다. 

먼저 버그를 트래킹합니다. 이는 1인 팀이라도 매우 쉽습니다.

시중에 나와 있는 다양한 무료 또는 합리적인 가격의 버그 트래킹 소프트웨어 중 하나를 선택하고 설정합니다. 이조차 부담스럽다면 엑셀이나 책상에 있는 수첩을 활용해도 좋습니다. 중요한 것은 한곳에서 문제를 수집하고 트래킹하는 것입니다. 문제를 트래킹하기 위한 시스템을 구축했다면 이를 준수하는 것이 중요합니다. 버그가 많은 빌드는 제작 속도를 낮추고 새로운 문제를 야기할 수도 있습니다.

버그를 관리하기 위한 몇 가지 팁을 소개합니다.

금요일은 버그 해결의 날

금요일을 버그 해결의 날로 지정하는 것은 버그가 없는 빌드를 유지하기 위한 좋은 방법입니다. 금요일마다 새로운 기능에 대한 작업을 하는 대신 모두가 버그 목록에 기록된 항목에 대한 작업만 진행하는 것입니다. 이 방식을 사용하면 버그가 없는 안정적인 빌드로 새로운 한 주를 시작할 수 있습니다.

버그를 오래 미루지 않기

버그 관리가 되지 않는다면 잠시 새로운 기능에 대한 작업을 멈추고 상황이 정리될 때까지 빌드를 안정화하는 데 중점을 두는 것이 좋습니다. 

문제의 원인 찾기

계속해서 같은 버그가 다시 발생한다면 이에 대한 근본 원인을 파악해야 합니다. 레벨 빌드 파이프라인의 특정 부분이 매번 레벨 손상을 일으키나요? .xml 파일에서 게임플레이 값을 파싱하는 방식이 반복적으로 오류를 일으키나요?

만약 지속적으로 문제를 일으키는 시스템을 찾아낸다면, 이로 인한 문제를 계속 해결하기보다 해당 시스템을 다시 빌드하는 것이 좋습니다.

이 모든 베스트 프랙티스와 팁을 염두에 두면, 나머지는 규정 준수와 빌드 상태에 관심을 두는 정도에 달려 있습니다. 위의 제안을 취사선택하여 인디 제작 환경에 적용해도 됩니다. 빌드를 좋은 상태로 유지하는 데 사용하는 시간은 언제나 투자할 가치가 있습니다.