누가 뛰어난 게임 서버 개발자인가? 어느 팀이 훌륭한 게임 서버 개발팀인가?
현실을 보건대 서버당 최대 동시 접속자 수가 개발자 또는 개발팀의 역량을 재는 잣대로 쓰이는 듯 하다. 서버 한 대가 2천 명을 감당할 수 있다면, 4천 명을 수용할 수 있는 서버보다 기술력이 처진다고 판단하기 쉽다. 게임 관련 기사를 한편 한편 읽어나가다 보면 우리 서버는 최대 동접자 수가 xx명입니다.
라는 인터뷰를 어렵지 않게 찾아볼 수 있다.
논의를 더 진행하기 전에 잠시 라그나로크 2 관련 기사를 읽어보자.
8월 이후 성장이 뚝 그쳤다. 최근 두 달 사이 `라그2`에서 단행된 크고 작은 패치는 손에 꼽을 정도다. 당연히 유저들의 불만은 극에 달해 있다. 아니 이제는 포기한 수준이다. 유저들의 비난으로 라그2 게시판은 만신창이가 됐다. 차마 고개를 돌려야 할 정도의 극단적인 표현도 눈에 띈다. 이대로라면 상용화도 어려워 보인다. 그토록 자신감을 보였던 해외진출의 청사진도 장담할 수 없다.
라그나로크 2 개발팀 관계자의 증언이 없으니 무엇이 문제인지, 왜 이렇게 됐는지 알 도리는 없다. 하지만 어떤 이유에서든지 사용자를 만족시키기엔 버그 패치와 피드백 주기가 지나치게 길었다는 건 분명하다. 그리고 짐작컨대 그 원인은 기술적 빚(Technical Debt)이 누적된 탓일 게다. (물론 다른 분석도 가능하지만 여기선 기술적 관점에 초점을 맞춘다.)
만약 우리가 출시한 게임이 비슷한 상황에 처해 있다면 어떻게 해야 할까? 밤새워 버그 패치에 전념하면 될까? 그렇다면 라그나로크 2 팀은 최선을 다하지 않고 있단 말일까? 철없는 외부인이라면 그런 의심을 품어볼만 하지만, 자기 손으로 공들여 소프트웨어를 만들어 본 사람이라면 상상조차 못할 일이다. 그만큼 자부심 하나로 버티는 인종이 바로 개발자란 존재다.
이런 문제를 사후 대응하기란 불가능할지도 모르겠다. 첫인상이 중요한 게임의 특성상, 한번 대응이 늦어 사용자로부터 버림 받으면 그걸로 끝이다. 베타 테스트 초기에 서버가 다운되거나 아이템 복사가 일어나는 건 바람직하진 않을진 몰라도, 적어도 용납된다. 하지만 똑같은 문제가 한 주 후에, 그리고 두 주 뒤에도 전혀 개선되지 않는다면 게임에 쏟아 부은 투자금을 회수할 생각은 말아야 한다. 기껏해야 쓰디쓴 실패를 교훈 삼아 다음 번을 기약할 수 있을 뿐이다.
결국 게임 서버 개발자라면 동시 접속자 수보다는 게임 자체의 사업적 성과에 따라 평가 받아야 하는 게 아닐까?
말이야 간단하지 실제론 그리 되기 힘들다. 게임 하나를 세상에 선보이려면 기획, 서버 개발, 클라이언트 개발, 테스트, 마케팅 등이 모두 제 역할을 해내야 한다. 모든 부서가 같은 비전을 바라보고 성공에 매진한다면 다행이지만, 이해관계가 얽히면 일이 꼬이기 마련이다.
서로 다른 기능부서는 각기 다른 견해를 갖고 있었으므로, 주간 개발 회의에서는 의견 불일치가 늘상 생겨나곤 했다. …… 나는 이런 분쟁 소에서 사람들이 의사결정의 내용보다는 누가 의사결정을 해야 하는가에 더 집중하는 경우가 더러 있다는 것을 발견했다.
린 소프트웨어 개발의 적용 65쪽.
우리네 프로그래머는 골치 아픈 사내 정치 이야기는 먼 동네 일로 치부하고 싶어 한다. 그보다는 명확하고 정직한 이진 규칙의 세계에 몰두하고 싶어 한다. 그래서 자신의 가치를 보다 나은 성능과 보다 많은 기능으로 평가하고, 전체 가치 흐름을 보지 못할 때가 더러 있다.
다시 말해, 동시 접속자 수에 집착하는 것은 전형적인 부분 최적화 사례라 할 수 있다. 만약 우리가 전체 최적화를 염두에 둔다면 품질을 보다 중시하게 될 것이다. 최대 접속자 수가 4천 명에서 3천 명으로 줄더라도 그 이상의 가치를 거두기란 그리 어렵지 않을 수 있다. 경쟁사가 12개월 주기로 확장팩을 내놓을 때, 우리 팀은 10개월 만에 내놓는다고 생각하면 짜릿하다. 사용자는 보다 새로운 재미를 즐기게 되고, 우리는 그에 따른 보상(심적이든 금전적이든)을 받는다. 잦은 운영 사고와 버그에 질린 사용자가 경쟁사를 떠나 우리가 만든 게임에 들어온다면 이 또한 성공으로 이어진다.
서버 개발자가 자신의 기술을 인정 받는다면 이보다 기쁜 일은 없다. 하지만 기술을 뽐내느라 자칫 큰 그림을 보지 못할 수도 있다. 성능 최적화를 하느라 유지 보수가 어려운 코드를 양산해낸다면 자신이 의도한 바와 달리 실은 스스로의 가치를 떨어뜨리는 행동을 하는 셈이다. 어디까지나 넓은 시야로 바라보고 균형을 맞추는 게 중요하다. 하지만 동접자 수에 대한 믿음이 지나치게 확고한 분위기이니 만큼 나는 오히려 품질에 무게를 싣고 싶다.
미투입니다. ^^
captcha 단어가 제가 좋아하는 ‘recently’네요.
일정을 단축하기 위해 유지보수가 어려운 코드를 양산하는 경우도 있습니다.
그 결과 전체 일정이 더욱 늘어나게 되지만요.
프로젝트를 평가하는 기준 중에 유지보수와 관련된 항목들이 가장 측정하기 어려운 것 같습니다.
수치로 나타나는 것도 아니고, 실제 작업자 이외에는 체감하기도 힘들죠.
그래서 겉으로 잘 드러나는 성능, 일정 등에 더 집착하는 것이겠죠.
사업성으로 평가받기 이전에, 접속자 수 자체가 사업성을 판가름하는 잣대로 사용되고 있습니다. 현재 게임의 사업성을 판단할 수 있는 요소는 그리 많지 않고, 새로운 요소를 발견하려고 노력하지 않는 이유도 있을 겁니다. 외부의 모든 사람들이 ‘최선을 다하지 않고 있다.’라고 생각하기 시작하면 사기에 영향을 주어 실제로 그렇게 만들어 버리는데도 원인이 있을 수 있겠네요.
hey님, 특별히 recently를 좋아하시는 이유라도 있으신가요?
jangyeol님, 공감합니다. 품질은 마지막 순간까지 체감하기 힘들죠. 직접 개발하는 사람이라면 몰라도 다른 일을 하는 사람에겐 이상한 나라의 이야기 같이 들릴 테니 눈에 보이는 것에 집착하게 되죠. 품질이나 위험 신호를 수치로 표현해내려면 상당한 수준의 내공이 필요해서 말이죠. 리더십이 뛰어난 PM도 있어야 하고, 팀 구성원 모두가 협조하는 분위기가 형성되어야 해서….
밀피유님. 접속자 수 자체가 사업성을 판가름하는 잣대로 사용되고 있기 때문에 이 글을 썼습니다. 이상한 일이죠?
전체 동시 접속자 수가 아니라, 동시 접속자를 최대한 많이 받으려는 기술적인 시도가 문제라는 거겠죠. 이른바 대당 동접자 신화죠. ^^
Recently Change 때문에 그런가? 왠지 좋더라고요.
어흑 문자가 아니고 문제.. 그리고 밀피유님께 드리는 말씀이었습니다. ;
hey님, 오타는 제가 고쳐드렸습니다. ^^
아, 그리고 오해의 소지가 있는 듯 해서 한 말씀 더 드리겠습니다. 대당 최대 접속자 수를 늘리면 좋은 점도 있습니다. 보통 게임 서버 간의 정보를 공유 안 하는 구조로 가게 되는데, 이런 경우엔 한 서버가 받아들일 수 있는 접속자 수가 많을수록 좋습니다. 그걸 부정하는 건 아니구요. 단지 동접 수에만 집착하다가 게임성이나 게임 출시 일자, 또는 패치 같은 정작 중요한 이슈를 놓친다면 큰일이겠죠. 그래서 지금보다는 훨씬 더 품질에 중점을 둬야 한다는 취지의 글입니다. ㅎㅎ