버그, 문제, 그리고 과정
문제 해결 방식은 프로그래머마다 다들 자기만의 방식이 있다. 그러나 그 방식들이 때론 try-and-error, 즉 시행착오법일 때가 많고 문제를 겉도는 경우도 많다. 그래서 어떤 기이한 버그(원인이 밝혀지지 않은 아주 가끔씩 발생하는 버그)는 프로그램팀내에서도 논리적으로 문제를 접근해 나아갈 수 있는 팀원에게 업무가 주어지곤 한다. 만약 자신에게 그러한 일이 잘 주어지지 않는다면, 스스로 문제 해결 능력이 부족한지 한번 돌아볼 필요가 있다. (다른 아주 바쁜 일 때문에 안 맡겨질수도 있다 🙂 ).
내가 본 개발자들 중에는 문제가 주어질 경우 재현이 잘 안된다는 근거를 들며 며칠을 소비하거나, 이 코드 저 코드가 이상하다며 근거없는 의심만 해서 주변 개발자들에게 신뢰를 잃는 경우가 있다. 물론 그러한 버그는 며칠을 쓰고도 못찾을 수도 있다. 그렇기 때문에 개발자들은 그러한 문제를 떠맡기를 꺼려한다. 힘들고 시간도 많이 필요하지만 성과도 없을 수 있기 때문이다. (팀내에서도 이러한 성과를 인정해 주는 것이 필요하다)
그래서, 문제를 찾아가는 과정은 체계적으로 가져가는게 중요하다. 그래야 문제를 해결 못 하더라도 그 과정을 통해 어느정도 힌트를 얻을 수 있고, 조직 내에 그 과정을 공유하여 도움을 받을 수가 있기 때문이다.
게임개발은 엔진을 사용하는 경우가 대부분이기 때문에 엔진 버그로 치부해 버리기도 한다. 사실 개발 코드상의 버그일 가능성이 80프로는 될 것이고, 그 외는 엔진 버그일 수 있다 (엔진 버그도 적지 않다). 엔진 버그라면 엔진 커뮤니티 포럼 (유니티포럼, 유니티Q&A, 언리얼포럼, 언리얼Q&A)을 잘 검색해서, 해당 사항을 찾아 근거를 제시하고 이슈를 트레킹 하자. 유니티같은 경우 버그 이슈가 어떻게 진행되는지도 찾아 볼 수 있다. 포럼을 통해 수정된 버젼이 이미 릴리즈되어 있는지 정보도 얻을 수 있다. 엔진 릴리즈 노트(유니티, 언리얼)도 이때는 잘 탐색하여 어떤 버젼에서 반영이 됐는지를 찾아야 한다. 그래야 엔진을 업그레이드 할지에 대해 의사결정을 내릴 수 있기 때문이다. 영어로 된 포럼이라 어려울 수 있지만 개발자라면 구글과 영어는 개발하는 기간동안에는 뗄래야 뗄수 없는 부분이다.
이슈를 포럼에서 찾고, 수정된 릴리즈 노트를 찾은 후 수정된 엔진 버전을 찾아 팀에 각각의 근거를 제시한다면 조직내에서 의사결정을 내리기 쉬워진다. 만약 그러한 이슈가 포럼에 존재하지 않는다면, 개발코드상에 문제일 가능성이 크다. 재현이 잘 된다면 문제를 찾는건 시간문제이다. 만약 재현이 10번에 1번나오더라도 아주 절망적이지는 않다. 그래도 주기적인 빈도로 발생하는 것만으로도 여러가지 테스트를 통해 검증할 수 있는 근거가 될 수 있다. 아주 크리티컬한 문제가 아니라면 크래쉬리포트 툴을 잘 활용하면 좋다. 로깅 기능을 활용하여 의심나는 부분의 흐름에 로그를 잘 추가하여 크래쉬리포팅 콘솔에서 그 흐름을 파악하는 방식도 객관적은 근거를 만들기 좋은 방법이다.
이렇게 재현이 되는데도 문제를 찾지 못한다면, 그리고 크리티컬한 문제라면 소스 관리 시스템(svn, git등)을 거슬러 올라갈 수 밖에 없다. 시간도 오래걸리고 힘든 마지막 방법이라 이전에 문제를 찾는 것이 좋다.
과거에 고객 문의 중에 갑자기 심하게 프레임 드랍이 일어난다는 문의가 드물게 접수 되곤 했는데, 재현을 전혀 할 수가 없어서 고생한 적이 있다. 점점 느려지는 것도 아니고 갑자기 프레임이 떨어져서 고객의 하드웨어 문제로 매번 넘긴적이 있었는데, 실제로 플레이 시간을 함수인자로 넘기는 레거시 코드가 있었고, reinterpret_cast가 되어 값이 잘려나가는 것이 원인일 때가 있었다. 그래서 오래 플레이 한 유저에게만 발생되었었는데, 골수 팬 => 오래 플레이한 유저 => 시간 이라는 작은 단서가 중요한 역할을 하였다.
현상이라는 큰 단서를 놓치지 말고, 기록을 통하여 객관적으로 하나하나씩 짚어가며 분석하자. 버그도 찾을 수 있고, 더 많은 지식도 얻을 수 있다.