[NDC2019] 게임의 품질을 좋게 만들고 싶다고요? 개발하면서 테스트하게 해주세요

게임뉴스 | 윤홍만 기자 | 댓글: 10개 |


▲ 넥슨네트웍스 서정린 본부장

  • 주제: 열정적인 테스트가 우리 게임서비스의 품질을 향상시키지 못하는 이유
  • 강연자 : 서정린 - 넥슨네트웍스 / NEXON NETWORKS
  • 발표분야 : 사업마케팅&경영관리
  • 권장 대상 : 개발, 사업, PM, QA
  • 난이도 : 기본적인 사전지식 필요


  • [강연 주제] 게임 시장 내 경쟁이 치열해지면서, 게임서비스의 품질 관리는 선택이 아닌 당연한 것이 되었습니다. 하지만, 이상하게도 게임서비스의 품질은 테스터의 숫자나 테스트에 할애한 시간에 비례하지 않습니다. 아무리 테스트를 많이 하더라도, 빌드를 릴리즈하고 라이브서비스를 오픈하는 순간, 예상하지 못한 중요한 이슈가 발견되고 서비스는 스탑됩니다. 회사가 테스트에 투입하는 비용에 비해, 그 결과가 기대에 미치지 못하는 이유는 무엇일까요? 그리고 더 좋은 게임서비스를 제공하기 위해, 우리가 품질 보증 혹은 품질 관리에 대해 어떠한 것을 이해해야 할까요? 이하의 세션을 통해, QA에 대한 일반적인 오해와 막연한 기대가 풀리길 바랍니다. 이런 작은 생각의 변화가, 게임을 만들고 서비스하는 우리 모두의 공감대로 이어지길 바라며, 나아가서는 실제 게임서비스의 품질 향상으로 연결되기를 기대합니다.

    원래 상품이란 게 다 그렇다. 흠집만 계속 눈에 띈 달까. 제아무리 잘난 게 많다고 해도 못난 부분이 두드러지기 마련이다. 이는 게임도 마찬가지다. 잘 만든 게임이라고 해도 버그나 결함 등의 이슈가 발생하면 장점은 그냥 묻힌다. 그렇기에 게임사들은 게임을 잘 만드는 것 이상으로 결함이 없도록 테스트에 심혈을 기울인다. 공든 탑이 버그 하나에 무너질 수 있기 때문이다.

    그러나 이런 노력에도 버그나 결함은 사라지지 않았다. 게임에 들어간 비용을 볼 때 분명 만반의 준비를 한 블록버스터급 게임이라도 거짓말처럼 항상 결함이 발생했다. 테스트가 부족했던 걸까? 그렇다면 더 오랜 기간 테스트를 하면 이런 결함을 방지할 수 있다는 걸까? 이러한 의문에 대해 넥슨네트웍스의 서정린 본부장은 그렇지는 않다고 단언했다.

    상식적으로 테스트를 오래 하면 당연히 결함이 발생할 확률이 떨어져야 할 텐데 그렇지 않다는 이유가 뭘까? 그리고 그렇다면 도대체 어떻게 테스트를 해야 효과적일까? 이를 위해 이번 NDC 세션에서는 테스트에 대한 일반적인 오해를 비롯해 효과적인 테스트 방법 등 게임의 품질을 향상시키는 다양한 방법을 알아보는 자리가 마련됐다.



    ■ 테스트의 강도는 품질과 아무 연관이 없다 - 테스트는 결함을 발견하는 것일 뿐

    흔히 게임에 결함이 발생하면 테스트를 덜 해서 그렇다고 생각한다. 테스트를 더 많이, 더 빨리, 더 정확히, 더 오래 했다면 이런 결함을 미연에 방지할 수 있을 거라 생각하는 거다. 하지만 이에 대해 서정린 본부장은 테스트 강도(양)는 실제 제품(게임)의 품질과 아무 연관이 없다고 얘기했다.

    다소 충격적이었다. 저 말이 사실이라면 하나마나 마찬가지일 텐데 왜 테스트를 한단 말인가. 다소 의아했지만 서정린 본부장은 자신 역시 과거에는 이런 식으로 무작정 테스트 강도를 올리는 식으로 일했다고 설명했다. 결함이 발생하면 부족해서 그렇다고 여기며 강도를 더 늘리는 식이었다. 하지만 결과는 신통치 않았다. 강도를 늘리니 항상 시간 부족에 시달렸고 테스트 상황 자체가 개선되지도 않았으며 심지어 품질도 나아지지 않았다.

    왜 그런 걸까? 이에 대해 서정린 본부장은 "테스트는 결함을 줄이는 게 아닌, 이미 존재하는 결함을 확인하는 작업일 뿐"이라고 그 이유를 설명했다. 그러면서 품질관리의 아버지랄 수 있는 에드워드 데밍의 '데밍의 붉은 구슬' 사고 실험을 예로 들었다.





    데밍의 붉은 구슬 사고 실험에 따르면 그릇에 담긴 흰색 구슬과 붉은색 구슬을 숟가락으로 퍼낼 때 붉은 구슬이 몇 개나 나오는지 확인하는 실험이다. 이때 그릇은 제품이랄 수 있고 숟가락은 테스트 방법을 뜻하며, 흰 구슬은 통과, 붉은 구슬은 결함을 의미한다. 이 실험은 제품이 결함을 내포한 상태에서는 문제가 발생할 수밖에 없다는 걸 보여준다. 운 좋게 흰 구슬만 퍼간다고 해도 이는 테스트를 통과한 게 아닌, 그저 운 좋게 결함을 발견하지 못한 거뿐이라는 의미였다.

    이게 사실일까? 실제로 서정린 본부장은 QA를 한 게임들의 사례를 통해 이를 증명했다. 게임 A와 게임 B는 PASS 확률이 0%로 같았음에도 사후 결함 숫자는 각각 6.13개, 1.43개로 큰 차이를 보여줬다. 게임 B와 게임 C를 비교해도 마찬가지다. PASS 확률이 0%, 57.14%로 큰 차이가 났음에도 실질적으로 사후 결함 숫자는 1.43개와 1.71개로 큰 차이가 없었다.




    이건 그가 계속 설명한 것처럼 테스트 자체로는 결함을 줄일 수 없다는 걸 의미했다. 이미 개발 단계에서 결함이 생기기 때문이다. 그렇다면 이런 결함은 놔둘 수밖에 없는 걸까? 이에 대해 서정린 본부장은 "그렇기에 결함을 줄이기 위해선 개발이 완료된 후 테스트를 하고 문제를 찾고 해결해나가는 게 아닌, 개발 단계에서 협업이 이뤄져야 한다"고 강조했다. 사전에 결함을 발견하란 의미였다.



    ■ 테스트 측면에서 품질을 높이는 방법 - 사후 결함이 아닌 사전 결함을 발견하라




    사전 결함을 발견해야 하는 이유는 단순하다. 설명한 것처럼 테스트 자체로는 사후 결함이 줄지 않기 때문이다. 그리고 사후 결함을 발견한 후에는 많은 관리 비용이 들 수밖에 없다. 게임을 예로 들어보자. 개발을 완료하고 출시 전에 테스트해서 결함을 발견한 상황에서 이걸 고치려면 시간과 돈이 든다. 수많은 코드를 찾아가며 문제를 해결해야 하기 때문이다. 문제는 이뿐만이 아니다. 수정한 후에는 해당 결함과 상호 작용을 하는 다른 요소들이 문제없이 동작하는지 확인해야 한다. 고생도 이런 고생이 또 없다. 그리고 이는 출시가 길어지는 걸 의미한다.

    하지만 개발 중에 테스트한다면 어떨까? A라는 기능을 추가한 후 테스트를 한다면? 문제가 있건 없건 A 기능만 확인하면 된다. 상대적으로 복잡도가 낮으며 상호 작용하는 요소들도 적다. 또한, 테스트에 들어가는 리소스도 줄어든다. 일반적으로 개발이 마무리된 상태에서 통합 테스트를 하는 것보다 리소스를 투자하기도 쉽고 결함 발견, 수정에 들어가는 시간도 줄어들기에 전반적인 게임의 품질이 높아진다.




    이 외에도 서정린 본부장은 개발 단계에서 테스트를 진행할 때 얻는 이점이 있다고 덧붙였다. 바로, 결함을 미연에 방지할 수도 있다는 거였다. 게임 개발 공정상의 CCP를 보면 결함의 93%는 개발자의 단순 실수이며, 작업자 간 커뮤니케이션 오해로 인해 발생하는 게 2%, 정해진 규칙을 위반해서 발생하는 게 5%다. 즉, 개발자의 단순 실수를 막을 수만 있다면 93%의 결함을 해결할 수 있다는 것과 마찬가지다.

    이에 대해 서정린 본부장은 "그렇기에 테스트를 수천 번 하는 것보다 개발 중에 잔소리하는 엄마처럼 실수하지 않도록 상기시키는 게 더 효과적"이라고 설명했다.






    ■ 모든 결함은 사람의 실수로부터 나온다 - 실수를 줄여라




    하지만 그러기란 쉽지 않다. 개발 프로세스를 바꿔야 한다고 역설했지만 아이러니하게도 현재의 프로세스는 어떻게 보면 개발에 최적화된 상태랄 수 있기 때문이다. 오래도록 변화한 끝에 굳어진 게 현재의 개발 프로세스라는 의미다. 그렇기에 중간에 테스트한다는 건 개발 프로세스를 변화시켜야 한다는 뜻이기에 리스크를 동반할 수밖에 없다.

    그러나 서정린 본부장은 이를 부정했다. 개발 중에 테스트하는 건 개발자를 귀찮게 하기 위한 게 아닌 최선의 선택이었기 때문이었다. 끝으로 서정린 본부장은 "결함은 결국 사람의 실수로부터 나오는 것과 마찬가지이기에 그 결함을 줄이는 것이야말로 게임의 품질을 올리는 최선의 방법"이라고 말하며 강연을 마무리했다.

    댓글

    새로고침
    새로고침

    기사 목록

    1 2 3 4 5
    검색