며칠전에 우연찮게 다른 개발사의 H사장님을 만날 기회가 있었다. 회사 근처였길래 일이 끝난 후에 회사로 모셔서 차나 한잔하면서 얘기나 나눌까 하다가 자연스럽게 일 얘기가 나오게 되었다.

H사장님도 나 못지 않게 아토피로 많이 고생을 하고 계신중이었다. 나보다 훨씬 더 상태가 안 좋은 것을 보니 회사 일로 많은 스트레스를 받고 있는 것 같았다. 내가 아는건 없지만 비슷한 일을 해본 사람으로써 몇가지 조언을 드렸었는데 다른 분들께도 참고가 될 내용 같아서 여기에 적어놓고자 한다.


사장이건 사원이건 일을 하면서 가장 정신적으로 힘들 때에는, 앞날이 불확실할 때이다. 지금 개발하고 있는 게임이 성공할 것인가 실패할 것인가? 만약 실패하면 어떡하나? 등의 걱정은 큰 스트레스가 된다. 물론 누구도 성공을 보장받고 일하는 경우는 없다. 성공이 보장된 일은 십중팔구 사기 아니면 너무 단순해서 바보조차도 할 수 있는 일 밖에는 없다.

하지만 어떠한 일이건 인간의 힘에 의해서 성공의 확률을 더 끌어올릴 수는 있다. 그러면 어떻게 해야 하는가?

첫째. 막연한 불안감을 구체적인 불안감으로 전환시켜야 한다.

게임이 잘 안되면 어쩌나? 하는 것은 막연한 불안감이다. 불안감조차 없이 무사태평인 것에 비해서도 크게 나은 점이 없는 것이다.

구체적인 불안감은 무엇인가? 온라인 게임의 예를 들면
'서버에 동시접속자가 머신당 1000명 이상 못 받으면 어떡하나?'
'서버가 24시간 이상 켜놓았는데 못 버티면 어떡하나?'
'아이템 복사가 일어나면 어떡하나?'
'클라이언트가 현재 유저들의 PC 사양에서 잘 안돌아가면 어떡하나?'
'유저들이 만렙이 되고 난 이후에 할일이 없다고 불평을 하게 되면 어떡하나?'
'해외 수출하고 난 후에 로컬라이즈하는데 시간이 많이 걸리고 잘 안되면 어떡하나?'
등등...

최대한 다양하게 여러가지 영역을 커버할 수 있는 구체적인 불안감을 갖는 것이 무엇보다도 중요하다. 사장으로서 구체적인 불안감 없이 걱정만 하고 있는 일보다 어리석은 일도 드물 것이다.


둘째, 각각의 구체적 불안감에 대해 대비책을 마련해야 한다.

대개의 문제점은 사람의 노력에 의해 미연에 방지될 수 있다. 그러한 방지책중 가장 강력하고도 중요한 것은 '사전에 미리 해 보는 것'이다. 즉 테스트를 하는 것이다.

'서버에 동시접속자가 머신당 1000명 이상 못 받으면 어떡하나?'
  <- 사람이 일일이 접속하지 않아도 다수의 동시접속을 발생시킬 수 있는 전용 봇 클라이언트를 제작하여 수시로 접속 테스트를 실시한다. 보통 고사양의 PC 한대면 100 명정도의 접속을 처리할 수 있다. PC를 10대 정도 맞추면 동접 1000 명을 시도해보는 것은 어렵지 않다.

'서버가 24시간 이상 켜놓았는데 못 버티면 어떡하나?'
  <- 위와 마찬가지로 서버에 계속 봇 클라이언트를 이용해서 장시간 접속을 시키고, 상세한 로그를 남기게 해서 중간에 다운이 일어나는 경우 원인을 파악한다

'아이템 복사가 일어나면 어떡하나?'
  <- 서버에서 일어나는 행위들을 트랜잭션화하고, 각각의 트랜잭션에 대한 유닛테스트를 만들어서 항상 주기적으로 자동적으로 테스트될 수 있도록 만든다

'클라이언트가 현재 유저들의 PC 사양에서 잘 안돌아가면 어떡하나?'
  <- OS 별, 사양별, 그래픽카드별, 국어별 PC 들이 갖춰진 QA 테스트실을 만들고 숙달된 테스터가 여러가지 사양에 대해 테스트를 실시한다.

'해외 수출하고 난 후에 로컬라이즈하는데 시간이 많이 걸리고 잘 안되면 어떡하나?'
  <- 다른 언어로의 로컬라이즈를 테스트하고, 중간에 생겨난 문제점, 주의해야 할 점을 체크리스트화 하여 해외 파트너에게 제공한다.

'유저들이 만렙이 되고 난 이후에 할일이 없다고 불평을 하게 되면 어떡하나?'
  <- 기획팀원들이 모여서 머리를 맞대고 유저들이 만렙이 되고 난 이후의 일상을 유저의 입장에서 상상해본다.


위에서 알 수 있는 것 처럼 테스트라는 것이 얼마나 중요한가? 테스트가 잘 갖춰져 있으면 구체적인 불안감에 대한 구체적인 해답을 미리 일부라도 가질 수 있기 때문에, 팀 구성원들에게 안심감을 주는 중요한 요소가 된다. 또한 미리 테스트를 해봄으로써 빗나갈 수 있는 개발의 방향을 바로잡는 데에 큰 도움이 된다.


사실 테스트를 업무의 중요한 한 축으로 삼는 것은 프로그래밍계에서 제안된 '테스트 주도 개발(Test Driven Development)' 로부터 영감을 받은 것이다. 하지만 테스트는 프로그래밍에만 의미가 있는 것이 아니라, 일반 업무에도 아주 큰 의미를 갖는다.

여러분의 조직 내에 테스트라는 것이 얼마나 강조되어 있는가? 만약 여러분의 조직 내에 미래에 대한 불안감, 반복되는 실수, 체계의 부족이 느껴진다면 여러분의 조직을 테스트 중심의 조직으로 변화시켜볼 것을 제안한다. 앞으로 무엇을 하건, 어떤 일을 벌이건, 항상 먼저 이렇게 자문하는 것이다.

'그 일이 잘 될 것이라는 것을 어떻게 테스트할 수 있을까?'
'그 테스트를 어떻게 하면 숙련된 경험자가 아닌 초심자도 수행할 수 있게 만들 것인가?'
'어떻게 하면 그 테스트를 더 자동화해서 일손을 줄일 수 있을 것인가?'

이러한 질문들에 기반해 인력을 재배치 하고, 테스트 절차를 주요 업무절차로 만든다면 어떨까?

필자가 새로운 회사를 세우고 새로운 게임의 개발을 시작한지 2년 반 가까이 시간이 지나오고 있다. 그동안 여러가지 결정의 순간이 있었지만, 그동안 필자가 사장으로서 내린 결정중 가장 훌륭한 결정이었다고 생각한 것은 개발의 중간에 운영팀을 구축한 것이다.

운영팀을 구축함으로써 회사 안에는 개발자들뿐만이 아니라 그 사람들이 개발한 것을 테스트할 사람이 생겨났다. 테스터의 중요성은 이루 말로 다 표현할 수 없을 정도로 중요하다. 자세한 사항은 조엘온소프트웨어를 읽어보기 바란다.


필자와 얘기한 H사장의 경우 회사에 개발팀의 숫자는 적지 않았지만, 운영팀의 숫자는 너무나 적었다. 운영팀을 늘리고 QA 업무를 시켰더라면 개발팀들이 훨씬 더 효율적으로 일할 수 있었을 것임에도 그렇지 못했기 때문에 개발자의 숫자가 적지 않았음에도 만성적인 인력난을 느끼고 있었다. 이러한 인력난은 개발자의 숫자를 늘리는 것으로 잘 해결될 수 있는 것이 아니다.

개발자, 특히 유능한 프로그래머는 구하기 매우 힘들다. 특히 자금력이 풍부한 대기업이 우수한 인력들을 쓸어가고 있는 시점에서는 더욱 그렇다. 그럴 때 상대적으로 채용이 쉽고, 비용도 덜드는 테스터들을 고용하고 팀의 일부로 만듦으로써 개발자가 원래 갖고 있는 능력을 배가할 수 있다. 개발자 인력난에 대해 이것보다 더 현실적인 해답이 있겠는가?

H사장은 필자와의 미팅이 끝난후 새로운 가능성을 감지하고 필자의 권고대로 테스트 중심의 조직으로 체질개선을 시도해보기로 했다. H 사장과 여러분의 앞날에 행운이 있기를..


P.S. 운영팀이 개발이 다 끝난후에 갖춰지는 경우의 문제점들은 경험에 의하면 다음과 같았다
  - 전문적이고 자격을 갖춘 운영자를 선출하게 되기보다는 게시판에서 볼 수 있는 자원봉사자를 우선 뽑게 된다.
  - 게임에 대해 충분한 이해가 없는 상태에서 운영을 하게 되므로 실수를 야기하게 된다.
  - 운영팀이 게임의 문제점에 대해 개발팀에 제안을 하더라도, 개발팀에서는 '어제까지만해도 유저였던 놈이 감히 개발에 이래라 저래라 하는거냐' 라는 식의 좋지 못한 태도로 대하게 되기 쉽다
  - 운영자로써 자질이 부족한 사람에 대해 사전 검증할 기회가 부족하다.

imcgames 의 김학규입니다