신규 개발팀과 라이브 유지보수 팀에서 프로그래머는 어떻게 일합니까?
게임 프로그래머로 진로를 잡았으면 신규 개발팀에 들어갈 것인가 기존 게임을 유지보수 하는 라이브팀에 들어갈 것인가 고민이 될 것입니다. 저는 신규 개발팀, 라이브팀 모두 경험을 해봤고 지금은 라이브팀에서 게임 서버 유지보수 업무를 맡고 있습니다. 개인적으로는 신규 개발이 훨씬 재밌었고 계속 신규 개발을 하고 싶었지만 사람일이 다 원하는대로 흘러가지는 않더군요. 물론 라이브팀에서도 배울것은 많습니다. 하지만 제 성격은 라이브팀의 업무와는 잘 맞지 않는것 같습니다.
어떤 게임이든 신규 개발 단계가 있습니다. 아무것도 없는 상태에서 게임을 기획하고 프로그래머는 기능을 하나씩 구현하죠. 큰 회사라면 기존에 다른 팀에서 사용하고 있는 라이브러리를 활용하기도 합니다. 이렇게 하면 초기 개발 시간을 단축할 수 있죠. 이걸 극한으로 활용하면 신규 개발이지만 라이브처럼 일하는 상황이 벌어지기도 합니다. 이미 기반 구조는 다 잡혀 있고 앞으로 만들 게임도 비슷한 장르라면 새로운 시스템을 구축할 일은 거의 없기 때문이죠. 기존에 쌓인 기반 위에서 컨텐츠를 올리는 일이 대부분일 수도 있습니다.
하지만 전혀 새로운 장르를 개발한다던가 게임 시스템이 다르다면 밑바닥 부터 새로 작업하는 경험을 해 볼 수 있습니다. 변수명 하나, 클래스 하나 부터 직접 내 손으로 설계하고 점점 살을 붙여나가는 재미를 느낄 수 있죠. 그 과정에서 전체적인 게임 시스템을 어떻게 구성하는지 큰 그림을 볼 수 있습니다.
개발을 진행 하면 할 수록 시스템은 점점 커져가고 초기에 잡았던 설계를 뒤엎는 경우도 발생합니다. 이런 과정을 거치다 보면 클래스 설계 능력과 그것을 구현하고 리팩토링 하는 코딩 능력도 같이 올라갈 수 있습니다. 또 아무것도 없는 맨바닥에 시스템과 컨텐츠를 쌓아 올리는 경험이 큰 재미와 성취감을 주죠.
개발 일정도 어느정도 유연합니다. 간혹 최종 출시일이 딱 잡혀 있는 경우도 있지만 대부분 몇 년 혹은 몇 개월 뒤에 출시한다 정도만 정해놓고 시작하죠. 신규 개발시에는 요원(인원)도 그리 많지 않습니다. 따라서 기존에 안하던 일을 하기도 하고 한 사람이 여러가지 일을 맡는 경우도 있습니다. 기획서도 문서로 확정해 놓고 가는 것 보다는 구두로 커뮤니케이션을 자주 하면서 개발하는게 더 수월합니다. 한 가지 기능을 빨리 만들고 테스트 해 보고 또 추가/수정 하면서 점점 보완해 나가야 하기 때문이죠. 수십장짜리 빈틈없는 기획서보다 최소 기능만 담은 한장 짜리 문서를 놓고 서로 미팅을 자주 하는게 훨씬 효과적입니다.
따라서 개개인의 성격에 따라 신규 개발이 잘 맞는 사람도 있고 안 맞는 사람도 있습니다. 확실히 정해진것에 안정감을 느끼는 사람들은 신규 개발이 잘 안맞을 수 있죠. 반면 도전적인걸 좋아하고 하나 하나 붙여나가면서 만드는걸 선호하는 사람들한테는 천국입니다.
신규 개발은 언제 출시할지 아무도 알 수 없지만 중간 중간 플레이 가능한 빌드는 계속 내야 합니다. 이걸로 투자자한테 프레젠테이션을 하거나 회사에 보고를 해서 진행 상황을 점검해야 하기 때문이죠. 이 때 잘 안되면 개발 도중에 프로젝트가 접히기도 합니다. 그래서 신규 개발은 언제든지 갑자기 프로젝트가 중단될 수 있죠. 작은 회사라면 회사 자체가 위태로워질 수 있고, 큰 회사라면 팀이 깨져서 다른 팀으로 이동하거나 퇴사를 해야 할 상황까지 갈 수 있습니다.
이런 위험성이 있지만 저는 신규 개발을 선호하는 편입니다. 제가 원하는 방식대로 코드를 설계할 수 있어서 좋고, 하나 하나 붙여 나가며 컨텐츠를 만드는게 재밌기 때문입니다.
작은 회사에서 신규 게임을 개발했을 때는 인디게임 만들듯이 재밌게 일했습니다. 빨리 구현해서 보여주고, 논의하고 고치고, 다시 또 만들고 하는 과정이 아주 신속하게 진행됩니다. 작은 조직에서는 시간이 곧 생명이기 때문에 서비스 수준의 퀄리티를 빠르게 만들어내는게 목표입니다. 너무 거창한 기능이나 자잘한 디테일에 신경 쓰기 보다는 이 비즈니스가 사람들한테 선택받을 수 있는지를 빨리 봐야 하는 것이죠. 따라서 다소 완벽하지 않은 채로 시장에 내놓기도 합니다. 버그가 많을 수도 있고, 문제가 생기면 수작업으로 대응해야 하기도 합니다. 하지만 저는 이런 것들이 오히려 도전 정신을 자극하고 새로운 길을 개척한다는 느낌이 들어 작은 조직에서의 신규 개발을 선호합니다.
저는 현재 라이브 게임을 유지보수하는 팀에 속해있습니다. 제 선호와는 다르지만 여기서도 배울것은 많습니다. 신규 개발과 같이 모험적인 부분은 없으나 기존에 존재하는 시스템을 분석하는 스킬은 많이 늘고 있는 것을 느낍니다. 가끔 어떤 의도로 작성했는지 도무지 알 수 없는 코드들도 있습니다. 히스토리도 없고 변수명도 이상하고 방식도 구식입니다. 하지만 현재 원하는 요구사항에 따라 잘 작동하고 실제로 수익을 내고 있기에 무시할 수 없는 부분인건 사실입니다. 가끔 이 코드가 만들어질 당시에 내가 했더라면 이렇게 구현할 수 있었을까 싶은 것들도 있습니다. 남의 코드를 보고 의도를 파악하는 것은 참 힘들고 짜증나는 일이지만 그것과는 별개로 존중해줄 부분들도 많은것 같습니다.
개발 방식은 먼저 회사에서 원하는 컨텐츠와 방향을 설정하고 킥오프 회의를 진행합니다. 이 때 개발 일정은 이미 정해져 있는 경우가 많습니다. 해당 날짜에 맞춰서 마케팅도 진행하고 이벤트도 미리 기획해 놔야 하기 때문이죠. 도저히 그 일정에 맞출 수 없는 경우는 컨텐츠를 좀 줄이던가 일정을 미루던가 합니다.
개발하는데 갖는 부담은 신규 개발 보다 훨씬 큰 것 같습니다. 해당 날짜에 유저들에게 직접 오픈해야 하기 때문에 치명적인 오류가 생기면 뒷수습이 만만치 않기 때문이죠. 또한 엮여있는 팀들이 많아서 큰 문제가 생기면 여기저기서 이슈가 날라오기 때문에 정말 정신 없습니다.
작은 코딩 실수 하나가 수천명 이상의 유저에게 영향을 줄 수 있고 그걸 수습하려고 며칠동안 거기에 매달려 있기도 합니다. 절차도 많아서 프로그래머가 직접 쿼리 돌리고 땡 할 수 없는 것이고요. 원인 분석, 재발 방지 대책등도 작성해야 하고 이곳 저곳에서 이름도 못 들어본 사람들이 이래라 저래라 하는 소리에 스트레스를 받기도 합니다.
또한 워낙 시스템이 오래되고 여러 사람을 거치다 보니 전혀 파악하지 못한 곳에서 에러가 나기도 합니다. 몇넌동안 안쓰던 데이터를 썼더니 이상한 버그가 생기는 경우도 종종 있죠. 의미가 없어 보이는 데이터들도 있는데 물어보면 아무도 그걸 왜 쓰는지 모릅니다. 그냥 예전부터 이렇게 같이 써 왔기 때문에 쓰는 것이고 괜히 안쓰는것 같아서 지웠다가 다른데서 문제 생길 수도 있기 때문에 그냥 놔두는 경우가 많습니다.
코드도 이사람 저사람 거치면서 최초 설계 의도와 다르게 작성되는 경우도 많죠. 오래된 프로젝트라면 마치 유물을 보는 것 같은 느낌도 듭니다. 요즘에는 웬만해서는 다 라이브러리로 제공되는 기능을 사용하는데 예전에는 직접 구현해서 쓰는 경우도 많았기 때문이죠.
한가지 예로 C++에는 STL이라는 라이브러리가 표준으로 제공됩니다. 요즘엔 거의 다 이걸 쓰지만 10년 전에는 직접 맨손으로 다 구현해서 쓰는 사람들도 있었습니다. 당연히 그런 코드들도 아직 서비스 하는 게임에 들어가 있고 작동하는데 아무런 문제도 없습니다. 다만 그 코드를 보고 유지보수해야 하는 프로그래머로서는 정말 고역이 아닐 수 없습니다. 디버깅 시간이 오래 걸리는 것도 있지만 도대체 어떤 의도로 이렇게 코딩 했는지 알 수 없는 경우가 많기 때문이죠. 교과서대로 구현해 놓은 것도 아니고 작성자의 입맛에 따라 변형을 가한 자료구조 라이브러리를 디버깅 하고 있으면 정말 회사 그만 두고 싶은 마음까지도 듭니다.
라이브팀에서는 내 입맛에 맞게 일하는건 거의 불가능하고 이미 구축되어 있는 시스템에 나를 맞춰야 합니다. 내가 새로 작성하는 코드 보다 기존에 쌓여있는 코드가 훨씬 많기 때문이죠. 따라서 거대한 시스템을 분석하는걸 좋아하는 분들이라면 라이브팀이 잘 맞을 겁니다. 수학적인 머리가 뛰어난 분들도 유리하죠. 저는 분석적인 면이 별로 없고 전체적인 모습을 알아야 속이 시원해지는 스타일이라 라이브팀은 사실 재미가 없습니다.
옛날에 고등학교때 정보 올림피아드 경시대회를 나간 적이 있었습니다. 그 때 나름 6개월동안 동아리에서 공부를 했기 때문에 쉽게 붙을줄 알았는데 저는 떨어지고 한달정도 공부한 옆에 친구가 붙은 적이 있었습니다. 그 친구는 프로그래밍은 잘 모르지만 수학은 잘했고 학교 성적도 좋은 아이였습니다. 그 때 충격받고 다시는 경시대회에 나가지 않았었죠. 그 대신 직접 게임을 만들어 출품해서 상을 받았는데 이 때를 계기로 저는 무언가를 창작해서 만드는걸 좋아한다는것을 알게 되었습니다. 이 때의 트라우마 때문인지 아직도 코딩 인터뷰는 두렵습니다. 하지만 직접 게임 하나를 만들라고 하면 아주 신이나서 할 수 있습니다.
아마 게임 회사 뿐만 아니라 다른 업계에서도 신규 개발팀과 라이브팀의 업무 방식은 비슷할 것 같습니다. 그리고 신규팀에서도 개발이 진행될수록 레거시가 쌓이기 때문에 계속 새로운 업무만 할 수 있는것도 아닙니다. 라이브팀 역시 새로운 도전을 하는 경우도 있어서 항상 똑같은 일만 하지는 않습니다. 프로그래머로서 둘 다 갖춰야 하는 능력은 맞습니다. 하지만 제 경험상 신규 또는 라이브 각각 자기 능력을 잘 발휘할 수 있는 환경은 확실히 있는 것 같습니다.