요즘은 프로그래머의 삶에서 어느정도 벗어나 프로그래머를 바라보는 입장에 서있다. 게임을 개발하는데 있어 프로그래머의 어깨는 상당히 무겁다. 아무리 좋은 기획과 멋진 그래픽으로 무장한 게임이 있더라도 프로그램이 불안정하고 버그가 많다면 그 게임은 곧 망한 게임이 되기 때문이다. 그래서 게임을 만들 때 프로그래머의 스킬, 자세, 경험을 굉장히 큰 한계치로 두고 개발하는 것이 중요하다는 생각이다.
프로그램을 짤 때 있어 가장 중요한 것은 설계와 디버깅 능력이라 생각을 하는데, 둘 다 경험을 수반하지 않은 상태에서는 참 뜬 구름 잡는 이야기가 아닌가 싶다. 해보지 않은 기술을 토대로 개발을 한다는 것도 어렵고, 제대로 된 디버깅 능력을 갖추지 못하면 문제점을 제대로 파악할 수 없어 결국 수 많은 시행착오와 예측 불가능한 일정으로 귀결되어진다.
제대로 된 설계를 위해서는 프로그래머도 능동적 커뮤니케이션의 자세를 갖춰야 하지 않을까라는 생각을 해본다. 대다수의 프로그래머는 경험상 다소 내성적인 경향과 수동적인 커뮤니케이션의 자세를 갖추고 있지 않나 생각이 든다. 주어진 기획서를 받고, 그대로 구현을 하면 된다고 생각하다보면 결국 기획자의 의도와 동떨어진 길을 갈 가능성이 많다. 기획과정에서의 프로그래머의 참여의 창구가 마련되어야 하고, 프로그래머는 이 장소에서 명확한 한계와 가능성을 제시할 수 있어야 한다는 생각이다. 또한 묻는 말에 대답하는 것이 아닌 프로그래머 스스로가 능동적으로 질문하고 의견을 개진할 수 있어야 한다.
초반의 기획 협의 단계, 기획서가 나온 단계에서 설계를 본격적으로 진행을 하게 되는데, UML 같은 모델링 도구를 쓰는 것도 좋은 방안이라 생각한다. 다만, 설계라는 부분에서 설계 그 자체에 너무 집착하는 것도 문제라 생각한다. 게임은 보통 선형적인(sequential) 부분과 비선형적인 부분이 있을텐데 프로그래머 입장에서는 이를 Flow 화 시키는 과정이 우선되어야 한다는 생각이다. 게임의 처음과 끝, 전체적인 흐름을 파악하고 이를 기능적인 부분으로 분화한 후 묶어야 할 부분(객체화)이 산정될 수 있지 않을까란 생각이다.
보통은 기획서를 처음부터 끝까지 제대로 읽지 않고 작업을 스타트하는 경향이 많은 듯 한데, 설계 단계에서 완전하게 기획서의 내용이 머리속에 들어와야만 제대로 된 설계를 할 수 있지 않을까란 생각이다. 설계가 어느 정도 진척되면 세부 구현에 들어가야 하는데 가급적 이 세부 구현 단계에서 작성되어지는 모듈에 대한 테스트를 진행하면서 작업하는 습관을 들이면 좋을 것 같다. 최근 이슈가 되고 있는 TDD(Test Driven Development) 같은 거창한 기법을 사용하는 것은 아니더라도 최소한 단위 단위의 작업 결과물이 제대로 돌아가고 예외에 대한 처리 부분이 들어가 있다면 전체적인 통합(integration)을 했을 때 문제가 최소화 되지 않을까란 생각이다. 이 모듈 테스트시에 DevPartner 의 Bound Cheker 같은 프로그램을 사용하면 유용하지 않을까란 생각을 해본다.
작업 시에 중요하게 생각하는 것 중 또 하나는 소스 자체의 문서화이다. 보통 개발시에 바쁘게 진행을 하다보면 성과 위주로 작업을 하게되고, 구조화 부분보다 빠른 실행 자체에 목적을 두다보니 문서화는 전혀 고려하지 못하게 되는 경우가 많다. 프로토타입을 개발하는 것이 아니라면 이런 부분은 없어져야할 관행이라 생각한다. 각 모듈 모듈에 대해서 최소한 헤더파일에 대해서 만큼은 변수의 사용 용도, 메써드의 사용용도, 파라미터의 의미등에 대한 내용들이 기술되어 있어야 할 것 같다. 또한 구현부의 중요 로직에도 원리를 기술해 주는 것이 좋다고 생각한다. 문서화를 위해 주석을 약속 형태로 적어주면 나중에 별도 매뉴얼 파일로 추출할 수 있는 Doxygen(
http://www.stack.nl/~dimitri/doxygen) 을 활용하는 것을 적극 권장한다. 이를 통해 만들어 두면 차후 유지보수를 위한 기억을 되새김 하는데, 도움이 될 뿐만 아니라 다른 사람에게 소스를 인계할 때도 별도의 작업이 필요없을 만큼 좋은 아웃풋을 만들어 줄 수 있다.
[그림 1] Doxygen 공식 사이트의 모습
이렇게 개발된 산출물에 디버깅을 잘 하는 것은 성공적인 프로젝트로 갈 수 있는 길이라 생각한다. 개발자 레벨에서 스스로 이런 저런 테스트 하면서 완성도를 높여가는 1차 단계 테스트 및 디버깅과 실제 사용자 레벨에서 테스트 해보는 필드 테스트 단계가 있다. 1차 단계에서는 컴파일러에서 제공하는 디버깅 툴을 잘 사용한다면 어느정도 문제점들을 잡아나갈 단계가 될 것이다. 문제는 2차로 필드 테스트를 나가게되면 프로그래머적 사고를 하지 않는 사용자는 여러가지 방법으로 버그를 만들어내게 된다. 이런 문제점들은 어떤 원인으로해서 그러한 결과가 나오게 되었지는 발견하기가 쉽지 않다.
이를 위해 가급적 버그트랙킹 시스템을 활용하길 권장한다. 대표적인 GNU 라이센스의 Mantis (
http://www.mantisbt.org) 같은 프로그램을 추천한다. 필드 테스터들은 우선 테스트를 들어가기 전에 가벼운 교육을 받아 버그 트랙킹 시스템의 사용법과 버그 보고를 위한 요령에 대한 숙지가 필요하다. 어떤 상황에서 문제가 발생했는지, 문제가 발생한 시점의 스크린샷을 잡아내는 방법 따위의 행동들 말이다.
[그림 2] Mantis 공식 사이트의 모습
프로그래머는 각 필드테스트 버전에 대해서 숙지하고 어떤 버전에서 어떠한 버그가 올라오는지 버그 트랙킹 시스템을 통해 추적할 수 있다. 버그들은 누적이 되고 각 버그들은 어떤 원인에 의해서 발생했는지 다수의 사람들에 의해 원인을 어느정도 가늠할 수 있게 된다. 이렇게 보고된 사항들을 하나씩 해결해 나가는 과정을 통해 프로그램은 점점 안정화 단계에 접어들 수 있게 된다.
이러한 일련의 과정은 굉장히 인내를 요구하는 과정이 아닐 수 없다. 많은 사람들과 얘기를 해야하는 부분들이 많기 때문에 소극적인 성향의 사람들은 어려움을 느낄 공산이 크다는 생각이 든다. 훌륭한 프로그래머가 되기위해선 매니아적(오타쿠적) 구현능력의 천재보다는 기본기가 탄탄하고 사람들과 원만하게 대화하고 정보를 수집하고 그것들을 활용하는 능력이 결국 중요하다는 생각이다.
많은 책임을 떠 맡고 있는 많은 프로그래머들이 좀 더 능동적이고 긍정적인 생각을 가졌으면 좋겠고, 각 개발에 참여하는 사람들은 프로그래머의 목소리를 어떤 사람들보다 중요하게 경청할 수 있는 분위기가 될 수 있어야 한다고 생각한다.
이 땅에 많은 프로그래머들이 힘내서 더 좋은, 더 많은 게임들이 나왔으면 하는 바램을 가져본다.
현재위치 :
어렵고 어려운 프로그래머의 길...
