NC

〈TECH TRACK〉 시리즈는 엔씨가 개발 중인 게임의 개발자들을 조명합니다. 게임 개발에 필요한 다양한 직무와 하는 일, 그리고 전문가가 되기 위해 쌓아온 커리어패스를 살펴보세요.

이번 편 주인공은 난투형 대전 액션 장르 게임 〈배틀 크러쉬〉의 클라이언트 프로그래머 이윤석 님입니다.

게임 클라이언트 프로그래머는 게임 세계의 캐릭터와 오브젝트들 사이에 작용하는 규칙과 이벤트를 프로그램으로 구현한다. 클라이언트 콘텐츠 개발을 전반적으로 담당하는데, 최근에는 전투 로직과 신규 캐릭터 구현 등을 중점적으로 수행하고 있다.

게임의 재미는 예측을 불허하는 기믹에서 오지 않을까. 실제로 내가 플레이하며 가장 쾌감을 느낀 지점도 허를 찌르는 변수가 어떻게 나의 플레이와 승패에 영향을 미치는가에 있었다. 이제는 게임을 제작하는 프로그래머의 입장에서 플레이어가 놀라거나 즐거워할 수 있는 다양한 장치들을 어떻게 자연스럽게 구현할지 고민하고 있다.

이 직무는 플레이어가 보는 요소를 만드는 만큼 플레이어와 직접적으로 맞닿아 있다. 기획 아이디어를 프로그램으로 구현하며 화면을 채워가는 과정은 마치 새로운 것들을 만들어내는 것처럼 재미있다. 내가 구현한 장치들이 플레이어들을 재밌게 해준다는 상상만으로도 충분히 즐거운 일이다.

나는 엔씨에서 개발자 커리어를 시작했다. 처음부터 지금까지 클라이언트 프로그래밍 외길을 걸으며 12년째 재직 중이다. 캐주얼 슈팅 액션 게임 〈MasterXMaster〉의 툴 프로그래밍을 시작으로 클라이언트 프로그램을 담당했고, 언리얼 엔진 포팅 작업을 수행했다. 〈MasterXMaster〉 서비스 종료 이후 〈배틀 크러쉬〉에 합류하면서 언리얼 엔진을 적극 활용할 기회를 얻었다. 결과적으로 툴 프로그래밍과 엔진 프로그래밍, 콘텐츠 프로그래밍까지 해본 셈인데, 이 경험이 프로그래머로서의 시야를 크게 넓혀주었다. 다양한 경험이 시야가 넓은 프로그래머로 성장하는 자양분이 된다고 생각한다.

프로그래밍은 혼자서 개발하는 일이라고 생각하기 쉽지만, 사실 회사에서의 게임 개발은 끊임없는 협업과 커뮤니케이션의 연속이다. 자신의 속도와 팀의 속도를 맞추고, 협업 부서부터 더 크게는 조직실 단위의 마일스톤과 전체 프로젝트의 청사진에도 발을 맞춰야 한다.

때문에 혼자 일할 때와 협업할 때 사이의 문턱을 낮게 만들어둔다. 내 일감에만 집중해서 중간 공유나 보고 없이 파 내려가다 보면 협업해야 할 시기에 모드 전환이 어려워진다. 그리고 협업 과정에서 손봐야 할 곳이 생길 때 늦게 공유하면 할수록 결국 더 많은 시간과 리소스를 들여야 하기 마련이다. 특히 클라이언트 프로그래머는 서버팀과의 소통이 필수적이다. 때문에 혼자서 열심히 개발하다가도 한번씩 멈춰서, 지금 내가 전체 프로젝트와 같은 방향과 속도로 맞춰가고 있는지 체크한다. 커뮤니케이션을 잘하는 프로그래머가 곧 좋은 프로그래머라고 생각한다.

〈배틀 크러쉬〉는 개성 있는 신화 속 주인공들을 활용한 정통 액션 전투 게임이다. 실시간으로 전투가 일어나고, 소규모 전투의 승리자에게 최후의 전투를 제공하는 배틀로얄 모드가 주력 모드다. 기존 배틀로얄과 달리 〈배틀 크러쉬〉의 배틀로얄 모드는 플레이 중 지형이 랜덤하게 무너져 내리는 것이 특징이다. 우리 게임에 차별성을 부여해주는 핵심 요소다.

난투 형태 전투의 ‘액션성’을 살리는 데는 예측을 불허하는 지형 파괴와 함정 출현이 톡톡한 역할을 한다. 이를테면 지형이 무너지고, 폭파되고, 수영이 가능하거나 점프대가 심어져 있는 등 레벨에 다양한 기믹을 설정하여 다양한 변수를 만드는 것이다. 프로젝트의 특성상 꼭 필요한 부분이기도 했지만, 다이내믹한 변수를 좋아하는 나로서도 가장 흥미롭게 작업한 부분이다.

<배틀 크러쉬>는 랜덤하게 지형을 파괴해 플레이에 변수를 주는 것이 특징인 게임이다. 지형 파괴 시스템을 개발하는 과정에서 서버와 클라이언트 간의 동기화가 가장 중요한 부분이었다. 지형은 캐릭터가 발을 디디고 있는 곳이기에, 지형이 오동작하는 것은 게임 플레이에 치명적인 버그가 된다. 실제로 화면에서는 지형이 살아있는데, 서버에서는 무너진 지형으로 인식돼 화면상에서 캐릭터가 갑자기 떨어져 죽기도 하고, 반대로 지형이 무너진 허공에 캐릭터가 둥둥 떠있기도 했다. 동기화가 제대로 되지 않아 생긴 문제였다.

지형을 동기화 할 때는 지형 조각 하나하나 일일이 서버와 클라이언트간 동기화를 하는 방식은 사용하지 않았다. 불필요한 네트워크 트래픽을 막기 위해서다. 대신 서버에서 미리 무너질 범위와 시간정보를 계산해 놓고, 타이밍과 범위 정보만 클라이언트와 동기화하는 방식을 사용했다. 이렇게 하면 트래픽은 최소화하고 서버와 클라이언트는 동일한 방식으로 지형이 무너질 수 있었다.

또한 서버와 클라이언트에서 처리하는 로직을 구별했다. 예를 들어, 지형이 아래로 무너질 때, 눈에 보이지 않는 서버에서는 굳이 지형이 떨어지는 연출까지 계산할 로직이 필요 없다. 따라서 지형이 떨어지는 순간 실제 충돌 영역(캐릭터가 서 있을 수 있는 영역)은 서버에서 바로 삭제하고, 클라이언트에서만 연출에 관련된 로직을 돌렸다. 지형 파괴가 우리 게임의 차별화 지점이었던 만큼, 가장 공을 들인 부분이 아닐까 싶다.

게임 개발 초기 단계에는 팀의 기동력이 전체 프로젝트의 개발 속도와 성장의 질을 결정한다고 생각한다. 조직간의 밀접한 커뮤니케이션이 바탕되어 거기서 나온 피드백을 빠르게 반영할 수 있는 환경이 갖춰져 있을 때, 그 팀은 새로운 기능이나 콘텐츠를 개발하는 데 막힘이 없어진다.

우리 조직의 민첩도는 굉장히 높다. 직접 소통도 용이하고 일정이나 의견의 조율도 적극적으로 이루어져서 피드백과 반영의 속도 자체가 빠르다. 실제로 매일 오전에 클라이언트팀, 서버팀이 모여서 데일리 미팅을 진행하며 전체적인 업무의 진행 방향을 확인할 뿐만 아니라 각자의 진척도나 방향성에 대해서도 점검하고 있다. 특히 궁금한 점이 있을 때 혼자 앓지 않고 바로 찾아가서 물어볼 수 있는 분위기가 효율적이라고 느낀다. 더구나 직접 대화를 하는 방식은 온라인으로 소통할 때 보다 단시간에 많은 정보를 교환할 수 있고, 자연스럽게 소소한 일상 이야기도 곁들여져 분위기도 한층 밝아지는 부수적인 효과도 있다.

또한 다른 팀에 비해 마일스톤이 평균 1~2달 사이의 길이로 짧은 점도, 팀이 민첩하게 변화를 받아들이고 성장할 수 있는 원동력이다. 리더 그룹에서 이번 마일스톤의 목표를 제시하고, 그에 따라 각 팀장님들께서 팀원들의 일정을 세세하게 작성해주시면, 팀원들이 그 일정을 수행한다. 일단위의 디테일한 일정은 업무의 목표를 명확하게 보여주는 효과가 있다.

팀내 ‘1일 1 테스트’ 기조에 따라 매일 오전 10시 30분경부터 기획팀과 프로그램팀이 함께 BVT (Build Verification Test)를 진행한다. 사실 매일같이 전 개발인원이 꾸준히 테스트를 진행하는 것이 쉽지 않은데, 호흡을 짧게 끊어가며 문제를 찾아내고 개선하고자 하는 우리 조직만의 특성이 잘 반영된 부분이다.

BVT를 통해 전날 구현한 내용이 빌드에 잘 반영되었는지, 버그가 없는지 실제 게임을 플레이 하면서 체크한다. 이 과정 덕분에 빠르게 버그를 찾아내고 고칠 수 있다는 것이 가장 중요한 기능이겠지만, 그만큼 즐거운 시간이기도 하다. 우선 게임 자체가 워낙 재미있다. 그리고 매일 같은 사람들과 플레이를 하다 보면 서로의 닉네임도 다 알게 되고, 심지어는 닉네임을 가려도 플레이 스타일에 따라 누구인지 알게 되는 것도 재미요소가 된다. 다들 독창적인 닉네임을 가지고 있기도 해서, 서로를 닉네임으로 부르면서 일하는 것도 소소한 업무의 재미이다. BVT 진행 공지를 올리면 ‘좋아요’가 금세 여러 개 달리는 걸 보면 나뿐만 아니라 많은 분들이 이 시간을 기다리는 건 사실인 것 같다.