프로젝트 난항

텍스트 알피지 개발 팀 프로젝트가 마무리 단계에 들어섰다. 오늘은 새로운 기능을 개발하기보단 기존에 있던 프로그램의 UI통일, 그리고 버그 수정작업에 들어섰다.

생각보다 쉽지 않았는데, 이 자그마한 일주일 짜리 프로젝트에서도 수많은 버그가 튀어나왔다.

본인이 짰던 코드도 며칠 지나서 새로운 기능을 추가하다보면 버그가 발생하는 경우가 많았는데, 심지어 다른 사람이 짰던 코드를 수정하거나 거기서 정보를 끌어다 쓰는 경우에는 정말 많은 버그가 발생했다.

버그 잡기

프로젝트 개발 일정을 맞추기 위해선 어쩔 수 없이 우선 순위를 정해서 게임을 구동하기 위해 필수적인 기능들을 먼저 처리하고 시간이 안되는 것들은 뒤로 밀어두기로 팀 내부에서 결정했다.

내가 주로 봤던 곳은 스테이지 관련된 곳이었는데, 스테이지가 넘어가지지 않는다거나 적이 모두 쓰러졌는데도 전투가 끝나지 않는 문제가 생겼었다. 전자의 경우는 코드를 병합하는 과정에서 함수 호출이 하나 누락된 것이 원인이었고, 후자는 스킬 공격 메커니즘상의 문제가 있는 것으로 판단되어 담당자분께 알렸다.

어떻게 줄일까?

버그가 없는 프로그래밍은 없을 것이다. 당장 일주일도 안되는 기간동안 짠 코드에서도 이렇게 버그가 발생하는데, 수개월~수년간 작성하고 유지보수한 코드에서 모든 빈틈을 막는 것은 불가능하다.

그렇다면 현실적으로 버그를 줄이는 게 옳은 해결법일 것이다. 결국, 답은 소통과 원칙이다. 이번 프로젝트에서는 적을 공격하는 기능이 기본 공격과 스킬 공격 두 가지 방식이 있었는데, 두 코드의 작성자가 서로 달랐다. 그러다보니 얼핏 비슷하게 보이는 코드들도 있지만 핵심적인 부분이 누락되거나 서로 모순되게 짜져있어서 다른 기능들과 상호작용이 제대로 되지 않았던 게 문제였다.

어제 튜터님의 추상클래스와 인터페이스에 대한 강의를 들으면서 나왔던 질문들이 왜 어떨때 이런 기능을 사용하는지 모르겠다는 것이 많았는데, 팀 프로젝트를 두 번만 진행해보니 슬슬 감이 오기 시작했다. 현업에서 일을 할 때 내가 어떤 작업을 혼자서 할 일은 거의 없을 것이다. 퀘스트를 만들더라도 팀이 있을 것이고, 전임자가 나가고 내가 들어가거나 또는 반대의 경우로 다른 사람이 사용하던 코드를 이어서 작성하는 경우도 있을 것이다.

이런 경우에 팀의 원칙을 따르고, 필요한 경우 추상클래스와 인터페이스를 통해 작성될 코드의 기본 포맷을 잡고 확장성도 확보하는데 사용 가능성이 굉장히 높을 것이다.
실제 존속 년수가 길어지는 회사들은 업무마다 자체 메뉴얼을 가지고 있는 경우가 많다. 메뉴얼은 최신화를 하는데 시간과 노력이 많이 들지만, 잘 작성된 메뉴얼은 갑자기 직원이 일을 할 수 없는 경우 다른사람이 바로 투입해도 생산성이 보장될 수 있기 때문에 분명한 장점을 가지고 있는 시스템이다.

따라서 추상클래스와 인터페이스도 잘 작성해놓는다면 팀 프로젝트에서 버그가 불필요하게 많이 발생하는 것을 막을 수 있을 것이라 생각한다.