로그인

회원가입 | ID/PW 찾기

NDC

[NDC 19] "테스트는 게임 개발의 만능열쇠가 아니다"

테스트로 오류를 잡는 건 '운빨'의 영역

송주상(무균) 2019-04-26 23:54:54

서정린 넥슨 네트웍스 QA1 본부장은 '성과란 노력과 그 방향성을 벡터의 합연산한 것이다.'​라는 왓스튜디오 이은석 디렉터의 발언을 인용하며 강연을 시작했습니다. 그는 무조건적인 노력보다는 노력의 방향을 고려해야 좋은 성과가 나온다며 게임 개발에서 이뤄지는 테스트도 마찬가지라 말했습니다. 

 

왜 서정린 본부장은 방향이 정해지지 않은 테스트는 아무리 많이 해도 큰 의미가 없다고 했을까요. 테스트를 통해 게임의 결함(버그)을 찾는 일은 '운빨'에 가깝다고 언급했을까요? '게임의 완성도를 위해서는 당연히 테스트를 진행해야지' 또는 '게임은 많은 테스트로 충분히 완성할 수 있어'라고 생각하신다면, 이 강연을 꼭 보시길 바랍니다. /디스이즈게임 송주상 기자

 


 

 

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

 

 

# 놀랍게도! 테스트가 게임의 완성도를 높여주지 않는다

 

 

서정린 본부장은 1950년대 일본 품질 관리 운동을 이끈 '에드워드 데밍'의 품질 경영 14가지 원칙 중 하나를 소개했다.

 

품질 확보를 위한 검사(테스트)의 의존도를 줄여라.

 

언뜻 보면 납득이 잘 되지 않는다. 당시 데밍은 이 원칙을 납득시키기 위해 붉은 구슬을 이용한 사고 실험을 기획했다. 큰 그릇에 하얀 구슬과 붉은 구슬을 넣는다. 그 뒤, 숟가락을 통해 일부 구슬을 그릇에서 꺼낸다. 몇 개의 붉은 구슬이 있든, 몇 번의 숟가락질을 하든 붉은 구슬이 없어지거나 늘어나지 않는다. 산출물(그릇)의 결함(붉은 구슬)을 테스트(숟가락)를 통해 통제가 되지 않는다.

 

다시 말해, 테스트는 이미 존재하는 결함을 확인만 할 수 있으며, 결함의 숫자는 제작 단계에서 이미 결정되어 있다. 결국 테스트를 통해 결함을 발견하는 것은 확률의 영역에 가깝고, 계획이 없는 테스트라면 복권이나 다름없다.

 

 

서정린 본부장은 실제 사례를 소개하며, 레밍의 주장은 이론에서 끝이 아니라고 지적했다. 각 게임 투입 인원이나 업데이트 내용은 상이하지만, 그는 의미있는 결과를 돌출 할 수 있다고 말했다. 여기서 '사인오프'는 출시 전 테스트 개념이며, 'Pass 확률'은 그 테스트를 통과 할 확률로 0이라면 모든 사인오프가 통과하지 못했음을 말한다.

 

◆ 게임 A - 게임 B : 게임 A와 게임 B는 모두 많은 사전 테스트를 받았지만, 사후 결함은 약 4.5배 정도 차이난다. 사전 테스트의 양과 사후 결함 사이 관계성이 보이지 않는다.

 

◆​ 게임 B - 게임 C​ : 게임 B와 게임 C은 같은 수의 사전 테스트를 진행해, 게임 B는 많은 오류를 찾아냈다. 하지만, 사후 결함은 큰 차이가 없다. 출시 전 테스트를 통해 발견한 결함과 사후 결함 역시 상관관계가 보이지 않는다.

 

◆​ 게임 F - 게임 G​ : 게임 F와 게임 G는 모두 사인오프를 통과했다. 하지만 게임 F가 게임 G보다 약 2배 정도 많다. 사전 테스트 통과가 사후 결함에 큰 영향을 주지 않는다.

 

이런 결과가 테스트 자체가 쓸모없음을 말하지 않는다. 테스트는 결함의 식별, 처리와 관련된 서비스를 제공하고, 개발 조직은 오로지 개발에 집중할 수 있다. ​하지만, 출시 전 테스트를 통해 결함을 발견하게 된다면, 결함 관리 비용이 크게 절약된다.

 

 

 

# 테스트보다 먼저 결함을 발견할 수 있다면 더 좋다

 

 

많은 QA팀이 출시(릴리즈) 예정일과 통합 테스트 시작일 사이에 가장 강한 업무 강도(검은색 선)를 유지하고 있다. 통합 테스트에서 발견된 결함 중 심각한 'A급 결함'의 92~97%는 개발자가 수정할 수 있다. 서정린 본부장은 개발자는 '시간이 없는 것이지 실력이 없는 게 아니다'라며, 만약 통합 테스트 전에 'A급 결점'을 줄일 수 있다면, 우선도가 낮은 'B급 결함'도 수정될 것이라는 의견을 밝혔다. 

 

다시 말해, 테스트는 결함을 줄이는 만능 도구가 아니다. 오히려, 리스크 관리 계획과 그에 따른 결과 이르는 프로세스 중 일부이다. 결함의 숫자를 억제하기 위해서는 식품의 품질 관리 기법인 HACCP처럼 개발 공정 전 단계에서 관리하여 통합테스트 전 'A급 결합'을 줄여야 한다. 

 

위험 요소를 미리 파악하여 관리하는 HACCP처럼 개발의 영역에서도 개발 프로세스의 각 단계에서  ​ 자주 일어나는 문제의 원인 파악 ​ 일어날 가능성이 높은 문제 대비 ▲ 각 단계에서 허용 기준선 도입 등의 방법으로 결함을 최소화 할 수 있다.

 

▲ 개발 과정 중 생기는 실수의 대부분은 누구나 하는 작은 실수들이다.



#  지금까지 시간에 쫓기는 테스트를 탈출해야만 한다

 

 

효율적인 테스트의 이점은 분명히 존재하고 크다. 시간에 쫓겨 진행된 테스트에서 큰 결함(버그)가 발견되면, 리스크를 감수하고 예정대로 출시하거나, 심각한 경우 게임 출시나 업데이트가 연기된다. 테스트 항목을 정하고 주기적으로 진행하면 진행 연기와 같은 큰 리스크를 피할 수 있다. 서정린 본부장은 이와 함께 개발 과정에서 결함 예방 활동도 함께 진행하길 주문했다.

 

또, 앞서 밝혔듯이 테스트보다 HACCP처럼 결함의 원인을 찾고, 이 원인을 차단해야 효율적인 테스트가 가능하다. 대부분의 원인은 인간의 실수에서 나오지만, 이런 실수로 생긴 오류는 테스트를 통해서 찾기 쉽지 않다. 출시 전에 겨우 발견되거나, 출시 이후에도 발견되지 않다가 게임에 치명상을 입히기도 한다.

 

마지막으로 '경험 기반 테스트'는 게임의 많은 결함을 찾아내지도 않고, 경제적인 관점에서도 효율이 좋지 않다. 테스트 담당자의 경험을 바탕으로 결함을 찾아내는 방법은 담당자의 실력에 따라 편차가 크고, 실제 게임 내에서도 경험 기반 테스트를 통해 발견된 결함은 전체 5% 내외뿐이었다.

 

왜 지금까지 대부분의 게임사는 체계적인 테스트를 하지 않았을까? 대체로 게임 개발 시간 자체가 부족하다. 설계와 구현을 동시에 하거나, 한 사람이 여러 역할을 수행하기도 한다. 이런 상황에서 업무 프로세스를 '좋은 테스트'를 위해 수정하는 것은 불가능에 가까운 일이다. 이들에겐 테스트가 '어떻게' 수행되느냐보다 테스트를 '언제' 할 수 있는지가 중요한 문제다. 


▲ 일반적으로 테스트에 대한 시각 자체가 다르다.

하지만, 서정린 본부장은 테스트를 포함한 리스크 관리는 QA팀만의 문제가 아님을 명심해야 한다고 강조했다. QA팀부터 개발팀, 서비스팀까지 다 관계가 있는 문제다. 테스트가 잘 진행되지 않으면, 많은 결함으로 서비스팀에 영향이 간다. 이어 결함을 수정하는 개발팀에도 부담은 이어진다. 이 세 팀은 같은 사슬 속 고리들처럼 이어져 있다. 고리가 하나라도 녹슬면 고리가 끊어지듯, 가장 취약한 부분이 게임의 전체 완성도를 결정하고, 나아가 유저가 느끼는 게임을 결정한다.

 

 

 

# 마지막으로 서정린 본부장은 제안했다

 

좋은 테스트를 위해서는 결국 '개발 - QA -서비스'의 체계적인 프로세스가 필요했다. 또, 테스트가 게임을 위한 만능도구가 아님을 인식해야만 한다. 그는 다음과 같은 구체적인 제안을 제시하며 강의를 마쳤다.

 

Ⅰ. 테스트는 리스크 컨설팅 작업이다. 리스크 식별 작업에 기회비용 투입을 높이자. 현재는 실행 과정이 대부분이지만, 리스크 식별 작업을 대부분으로 구성해야한다. 이를 통해 얼만큼 볼 것인가가 아닌, 어디를 어떻게 볼 것인가를 결정하고 접근해야 한다.

 

Ⅱ. 통합테스트 중심으로 개발 전략을 개선하자. 게임을 개발 중 데이터와 논리 구조가 자주 바뀐다. 그렇기 때문에 초기 단계부터 테스트 할 수 있는 방법을 적극적으로 생각해봐야 한다. 또 데이터와 논리 구조도 미리 테스트 할 수 있다면, 통합테스트는 더 효과적일 것이다.

 

Ⅲ. 리스크 관리 비용에 대해 생각을 바꿔야 한다. 일반적으로 협업을 진행할 때, 작업할 시간이 없다며 불만을 갖는다. 하지만, 리뷰, 회의, 피드백을 통해 자신의 재작업 가능성을 크게 낮출 수 있다는 점을 명심해야한다.

 

Ⅳ. 테스트 조직 참여 시기를 최대한 앞으로 보내자. 보통 프로젝트의 설계가 종료 단계에 가까워졌을 때 투입한다. 개발 초기부터 참여한다면, QA를 고려한 설계가 가능할 것이다.

 

 

Ⅴ. 프로세스를 통제해야 한다. 테스트를 아무리 많이 진행해도, 프로세스가 통제가 안 된다면 리스크 관리 자체가 되지 않는다. 예를 들어, 한 명의 개발자가 피드백 없이 혼자 업데이트를 진행하면, 심각한 오류를 야기할 가능성이 크다.

 

Ⅵ. 포스트모템을 정기적으로 진행해야 한다. 일정 수준 이상에서는 실수에서 배우는 점이 많다. 또, 후에 참고 사항이 되어 큰 자산이 되기도 한다. 

 

Ⅶ. 실수를 줄이기 위한 노력은 필수다. 거의 모든 출시 이후의 결함은 사람의 실수에서 시작된다. 이 실수를 줄이기 된다면, 재작업 비용도 줄어든다. 즉, 실수를 줄이기 위한 안전장치를 고안해야 한다.

 

최신목록 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10