NDC Replay

게임QA에 리스크 기반 테스팅 이론은 적용가능한가?
황우람
넥슨네트웍스
현재 해외법인(넥슨유럽, 넥슨아메리카)의 게임(공각기동대 온라인, 컴뱃암즈, 카운터스트라이크:넥슨 좀비, 드래곤네스트 등) QA업무를 담당하고 있음.<br/>과거 넥슨의 테일즈위버, 엔씨소프트의 웹보드 게임, 데브캣의 마비노기2:아레나 프로젝트에 QA로 참여하였음. <br/>QA경력은 약 7년이며 2014년 NSC(넥슨네트웍스 서비스 컨퍼런스), NDC14에서 발표자로 참여한 경력이 있고 현재 QA본부 TMMi TF로도 활동하고 있음
본 세션을 통해 청강자들은 TMMi와 리스크 기반 테스팅의 개념을 다시 한번 확인할 수 있을 것이며, 특히 TMMi를 QA본부차원에서 적용한 사례를 확인함으로써 게임QA, 리스크 기반 테스팅, TMMi의 관계를 구체적으로 살펴볼 수 있을 것이다. 특히 본 강연에서는 실무자와 관리자 입장에서 할 수 있는 실수나 시행착오, 성과 등이 구체적으로 언급되어 있기 때문에 QA프로세스를 변경에 어려움을 겪거나, 새로운 시도를 해보려는 QA조직장들의 갈증을 해소해줄 수 있을 것이다. 마지막으로 약 1년간 TMMi를 게임QA에 적용하기 위해 TFT가 고민한 흔적들도 함께 살펴볼 수 있기 때문에 좀 더 성숙한 테스팅 조직을 만들고 싶은 분들께 도움을 줄 수 있을 것이다.
[새 창에서 슬라이드 보기]
네 안녕하세요 반갑습니다. “게임 QA에 리스크 기반 테스팅 이론은 적용 가능한가?”라는 주제로 강연을 진행하게 된 황우람입니다. 먼저 NDC 시간표를 받아들자마자 저는 깜짝 놀라지 않을 수 없었는데요. 동시간에 스타크래프트2 개발자인 David Kim 강연이 있다고... 그래서 저는 좀 좌절을 했었는데 그럼에도 불구하고 이렇게 많은 분들이 찾아와 주셔서 제 강연을 들어주신다는 거에 대해서 정말 깊이 감사를 드리고 강연을 시작하도록 하겠습니다.

먼저 안내 공지 말씀을 드리자면 제목에서 아시다시피 상당히 전문적인 내용을 다루기 때문에 좀 지루하지 않을까? 그런 편견을 가지시는 분들도 계실 것 같은데 최대한 이해하기 쉽도록 재미 요소를 좀 넣었으니까 편안한 마음으로 경청해주시길 부탁드리고요. 또한 본 강연은 저희 팀 동료들의 자발적인 협조로 제작이 되었습니다. 그래서 PT 배경에 다소 가식적인 모습의 팀원들이 등장하더라도 당황하지 마시고 제 딴에는 최선을 다한 것이오니 양해를 부탁드리겠습니다.

프롤로그 진행하겠습니다. 작년부터 사실 쿡방 전성시대 이런 말들을 많이 듣고 2016년도 마찬가지로 요리 관련 방송들이 상당히 많은 인기를 끌고 있습니다. 저도 한 번 도전해봤습니다. 레시피를 보고 마늘 한 숟갈 넣고 고춧가루 크게 두 숟갈을 넣었더니 안 되잖아?! 네. 저는 좌절했고요. 밤 11시 이후 쿡방을 다 없애 버려야겠다는 이경규 씨의 주장에 깊이 공감을 하게 되었습니다. 그 얘기를 들으셨는지 백종원 씨도 방송시간을 옮겼네요. 어쨌든 요리에 대해서 과연 내가 문제일까? 아니면 레시피가 문제일까? 아님 둘 다 문제일까? 

요리뿐만이 아니죠. 여러분들이 맡고 있는 프로젝트도 마찬가지일 겁니다. 뭔가 잘 안 풀리면 과연 사람의 문제인지 아니면 프로세스의 문제인지 이번 시간을 통해서 한 번 같이 고민해봤으면 좋겠습니다. 제 소개를 간단히 해 드릴 텐데요.

10주년 기념이라서 10년 전 리즈 시절 사진, 지금은 좀 역변했네요. 역변. 빨리 치우고 제 경력을 말씀드리자면 2006년에 Jera라는 프로젝트에 운영으로 입사해서 테일즈위버 QA를 진행했었고요. NC SOFT로 이직을 해서는 웹보드게임 그리고 Dragonica 그리고 페이스북 게임들을 주로 QA를 했었습니다. 그리고 다시 넥슨 네트웍스로 돌아와서 마비노기2 아레나 QA를 진행을 했었고요. 넥슨 유럽으로 넘어와서는 Counter-Strike Nexon Zombies 그리고 Combat Arms, War Rock, Navy Field 2 이렇게 QA를 진행했었습니다. 가장 최근에는 공각기동대 온라인 QA를 진행했고 Dragon Nest QA를 진행했습니다.

목차는 세 가지인데요. 먼저 TMMi에 대해서 이해를 하고 저희 이 TMMi TF의 활동들을 리스크 기반 테스팅을 중심으로 소개해 드리고자 합니다. 그리고 결론 이렇게 간단하게 세 가지로 구성이 되어 있습니다.

먼저 TMMi 이해에 대해서 좀 하고 넘어가야 될 것 같은데요. 정말 생소한 단어고 그래서 저도 한 번 검색을 해봤더니 거의 대부분이 영어로 된 자료만 나오고 한글로 된 자료는 하나 정도 이렇게 찾아볼 수 있었습니다. 그만큼 자료가 영어로 되어 있다 보니 좀 어렵고요. 제가 QA 경력이 꽤 된다고 할 순 있겠지만은 경력자들이 보기에도 사실 쉽지 않은 게 TMMi입니다. 관련 강의를 이틀 동안 들어도 하...뭘까? 고민을 좀 많이 하게 되는 그만큼 어려운 내용으로 생각이 됩니다.

그래서 팀원이 한 분 나오셨는데 간단하게 말씀을 드리면 ISTQB는 개인의 성숙도를 평가하는 기준, 아마 여기 계신 분들 중에 자격증 갖고 계신 분들이 많이 있으실 텐데 개인의 테스트 성숙도를 평가하는 기준이고요. TMMi는 조직의 테스트 성숙도를 평가하는 기준이다. 이렇게 간단하게 이해하시면 될 것 같습니다.

TMMi 각 레벨의 필수 요소에 대해서 알아볼 텐데요. 다섯 가지 단계가 있고요. 각 단계는 필수 요소들이 있습니다. 하나씩 살펴보면 1단계가 시작이고요. 2단계가 보시다시피 가장 할 게 많습니다. 여섯 가지 정도, 다섯 가지 정도 되죠. 그리고 LV3 역시도 할 게 많죠? LV4는 국내에 없고 LV5도 국내에 없습니다. 마치 LV5는 정말 닿을 수 없는 존재인 것 같습니다. 멀게만 느껴지는 존재죠. 언뜻 보기에도 뭔가 할게 많아 보이고 되게 어렵고 정확히 잘 모르기 때문에 뭔가 두려움이 앞서게 됩니다. 그럼에도 불구하고 왜 해야 될까? 조사를 해봤더니 TMMi 인증을 받은 게임 업체가 전 세계적으로 없다고 합니다. 그래서 세계 최초라는 업적을 달성하기 위해서 TMMi를 한번 해보는 게 좋지 않을까? 이런 움직임들이 본부 내에서 일게 됩니다.

TMMi TF 비하인드스토리를 말씀을 드릴 텐데요. 볼륨이 안 나오는 것, 볼륨 좀 올려주세요. 잠시 감상하시죠. 네, 이런 비하인드스토리가 있는데 실화라는 점...

어쨌든 이렇게 해서 TMMi TF가 구성이 되고요. 간단하게 소개를 드리자면 본부장님 그리고 실장님 두 분 그리고 테스트 리드 3명 그리고 테스터 이렇게 총 7명이 TF 인원입니다. 뭐 웅성웅성 대실 건 없고요. 좀 눈이 안 좋으신 분이 계신가? 어쨌든 각 조직의 리더들이 중심이 된 이런 TF고 많은 경험과 추진력이 있지만 아시다시피 이들은 항상 바쁩니다. 뭐 하느라 바쁜지 잘 모르겠지만 항상 자리에 잘 없고요. 메신저를 걸어도 말이 잘 없고 항상 바쁜 사람들인 것 같습니다.

그 TMMi를 만들면서 목표가 “2레벨을 달성하는 것이 목표다.”라고 했는데 과연 이렇게 바쁜 사람들을 대리고 잘 할 수 있을까? 그런 걱정이 앞서게 되었습니다. 각자 고유의 업무도 있고 교육 담당자들도 있고 이 중에서는 그리고 메이저 프로젝트를 담당하는 분도 있고 뭐 런칭 준비를 앞둔 담당자들도 있었고요. 과연 할 수 있을까? 현실적으로 어렵지 않을까? 그런 고민에 빠지게 되었는데 이때 이제 제 뇌리를 스친 게 한 편의점의 사례가 있었는데요. 점주가 편의점 직원에게 “월 매출 2500만 원을 달성해봐라.”라고 제시를 합니다. 그랬을 때 편의점 직원은 되게 황당하겠죠. 한 달에 2500만 원은 결코 작은 돈이 아닌 것 같아요 그죠? “2500만 원으로 팔아라”라고 했을 때 그래서 어떻게 할까? 고민을 했더니 목표를 좀 나눴습니다. 기간도 나누고 나누다 보니까 10분에 약 6000원 정도만 팔면 한 달에 2500만 원 매출을 달성할 수 있습니다. 그래서 한 달에 2500만 원, 어 되게 많아 보입니다. 하지만 10분에 6000원, 편의점 아르바이트생이 10분에 6000원 하면 왠지 가능할 것 같거든요. 왜냐하면 담배나 아니면 복권만 팔아도 가능할 것 같아요. 그래서 물론 순수익은 별개지만 어쨌든 순수익도 매출이 많을수록 늘어나는 것은 당연한 거기 때문에 기간을 잘게 잘라서 한 번 생각을 해보자. 언뜻 보기에 거의 불가능해 보이는 목표도 이렇게 기간을 잘라서 좀 더 타이트하게 생각을 해보면은 충분히 가능할 수 있다. 역할도 분배해서 편의점은 혼자 다 하는 게 아니니까요. 교대로 하게 되니까 그런 식으로 역할을 분배해서 하다 보면 그 목표에 도달할 수 있다. 이런 마음가짐을 갖게 되었습니다. 그래서 한번 해보자. 어떻게 하느냐?

TF 내에서도 유닛 활동을 하도록 했습니다. 그래서 리더 유닛 그리고 TF 유닛으로 개별 활동을 진행을 하고요. 기간 또한 충분히 2년이란 기간을 줬고 그 사이에서 알아서 진행을 해봐라. 이렇게 유닛 활동을 진행하게 되었습니다. 사실 돌이켜 생각해보면 TF 활동 초반의 흐름을 잘 이끌어 갈 수 있었던 신의 한 수가 아닌가? 이렇게 생각을 합니다.

그래서 이렇게 리더 유닛은 테스트 정책을 수립하는데 포커스를 두고 업무를 진행을 하고요. 테스트 정책을 설계하고 비즈니스 목표를 수립하고 핵심 가치에 대해서 고민을 하기 시작했습니다. 그리고 TF 유닛은 TMMi 연구 활동에 집중을 하게 됐는데요. TMMi 스터디 그룹을 만들어서 활동도 하고 TMMi 교육도 수료를 하고요. 실무 적용 가능성도 함께 같이 파악을 해 봅니다. 

몇 가지 직접 활동했던 것들 소개해 드리자면 이렇게 실제 저희 회사 회의실에서 칠판에다 대고 테스트 정책이 어떤 게 좋을까? 같이 모여서 브레인스토밍을 한 내용인데요. 글씨가 잘 안 보이겠지만 몇 가지만 말씀을 드리자면 테스트 정책에 들어갈만한 단어들이 무엇이 있을까? 서비스 안정성이라든지 아니면 프로세스 이런 부분들 클레임 케어 이런 부분들을 같이 논의하게 되었습니다.

이걸로 끝난 게 아니라 두세 번 정도 더 정책 수립을 위해서 모였는데 테스트 정책에 들어갈만한 단어를 선택하는데 있어서도 좀 많은 고심을 했습니다. 그래서 테스트를 잘한다. 과연 그거를 어떻게 표현하는 것이 좋을까? 그래서 뭐 꼼꼼한 테스트 또는 빈틈이 없는 이러한 단어들? 정책에 넣을만한 단어들을 선별하는 과정도 거치게 되었습니다.

그래서 테스트 정책 초안이 만들어졌는데요. 초안 중에 일부를 소개해드리도록 하겠습니다. 이렇게 여섯 가지로 되어 있고요. 아무래도 초안이다 보니깐 조금 부끄러워하셔서 일부만 발췌를 하였습니다. 조금 특이한 점은 적절성에서 등급 판정에 위배되는 표현이나 문구 또한 같이 확인을 한다. 이런 점이 좀 특이하다고 할 수 있겠죠?

그리고 TF 유닛 활동을 또 살펴볼 텐데요. TF 유닛은 TMMi에 대해서 자체적으로 연구를 진행합니다. 그래서 실제로 교육도 이틀 동안 가서 들었고요. 그래서 교육과 관련된 서적들 그리고 교제들을 같이 공부를 하게 됩니다. 그리고 TMMi 자가 진단이라고 해서 우리 조직이 TMMi 레벨이 몇인가? 스스로 진단해 볼 수 있는 시트가 있는데요. 그거를 진단을 해봤더니 결과는 뻔하게 1레벨과 2레벨의 과도기 상태인 것을 확인할 수 있었습니다.

그 외에 핵심이 될만한 활동 중에 하나가 리스크 기반 테스팅 가이드를 만드는 작업이었는데요. 아무래도 게임 QA다 보니까 기존에 원래 있는 리스크 기반 테스팅 가이드에서 게임 QA를 같이 응용을 해서 개정을 시켰습니다. 그래서 그 초안 중에 일부를 보여드리도록 하겠습니다. 이렇게 리스크 아이템 명을 게임에 대입해서 캐릭터라든지 인박스, 합성, 강화 이런 식으로 원래 S/W 테스팅에서 사용하던 것들을 예시를 게임 쪽으로 많이 맞춰서 바꿔서 이렇게 개정을 하였습니다. 리스크 요소도 마찬가지로 장애 발생 가능성에서는 복잡도 또 기술의 난이도/최신성 그리고 장애로 인한 영향에는 경제적 피해, 사용빈도 이 네 가지 요소를 필수로 가져가는 것을 TF에서 권장합니다. 뭐 이렇게 개정안을 추가하기도 하고 그 외에 리스크 요소, 리스크 아이템의 명칭들은 각자 프로젝트 특성에 맞게 커스터마이징 할 수 있다. 이런 식으로 가이드라인을 잡게 되었습니다.

이런 활동들을 통해서 무엇을 얻었는지 잠시 정리를 하자면 TMMi는, TMMi 레벨2 저희가 달성하고자 하는 목표는 프로젝트 단위로 이루어집니다. 프로젝트 중심이라는 것을 알 수 있었고요. TMMi 교육 수료를 통해서 어느 정도 자신감을 얻게 되었습니다. 교육 내용을 보시면 아시겠지만 실제로 각 프로젝트마다 커스터마이징 할 수 있는 부분들이 상당히 많이 있었습니다. 그래서 되게 딱딱한 게 아니구나 유연하게 프로젝트에 맞춰서 변형시키면서 적용할 수 있겠구나. 그런 생각에 어느 정도 자신감을 얻게 되었습니다. 그리고 이제 가장 중요한 사실 중에 하나가 TMMi 기본은 리스크 기반 테스팅이라는 것. 그것을 다시 한 번 확인할 수 있었습니다. 그래서 이쯤 되니까 이런 질문이 떠올랐어요. 과연 QA에 리스크 기반 테스팅 이론을 적용할 수 있을까? 본 세션의 제목이기도 한데요. 사실 소수 제한된 프로젝트에서 몇 명 소수의 테스트 리더들이 리스크 기반 테스팅을 적용하긴 했지만 이게 본부 차원에서 검증이 되지 않았기 때문에 본부 전체가 다 리스크 기반 테스팅을 적용할 수 있을까? 그런 의문이 들어서 직접 한 번 해보자. 그런 실험을, 실험을 직접 해 보자 그렇게 결정하게 되었습니다.

그래서 TF의 목적이 좀 변경이 되게 되는데요. 이상이죠. 이상. TMMi 레벨2 달성하는 것은 우선은 현재는 아마 닿을 수 없는 이상과 같은 그런 느낌을 많이 받았고요. 하지만 이 이상을 달성하기 위해서는 현실을 잘 알아야겠죠? 그래서 현실은 게임 QA에 리스크 기반 테스팅을 적용할 수 있는지 우선 실험을 해보자. 이게 가장 기본이 되는 것이기 때문에 기본을 튼튼히 해야지만 이상에 도달할 수 있다. 그런 결론을 얻을 수 있잖아요. 그래서 우선은 현재에 충실해서 리스크 기반 테스팅에 대해서 먼저 검증을 거치고 그 후에 TMMi 레벨2 달성하는데 한 걸음씩 한 걸음씩 다가가보자. 이렇게 목적이 좀 변경이 되게 되었습니다.

목적이 변경되고 마찬가지로 활동도 그러면 조금씩 변경이 되겠죠. 그래서 리더 유닛은 기본 테스트 정책에다가 리스크 기반 테스팅을 이제 포함시키게 됩니다. 리스크 기반 테스팅을 포함한 테스트 정책 수립 작업을 진행을 하고요. TF 유닛도 마찬가지로 게임 QA를 위한 리스크 기반 테스팅 가이드에서 조금 더 게임 QA에 맞게끔 최적화하는 작업을 또 진행을 하게 됩니다. 그리고 목적이 좀 바뀌었으니까 기간도 같이 좀 변경을 시키자. 그래서 2015년 하반기에 시범 프로젝트에 리스크 기반 테스트를 적용하고 그 결과를 도출하자. 이렇게 얘기가 됐고요. 2016년 상반기에 시범 프로젝트의 결과를 확인한 후에 확대 적용할지 여부를 검토하자. 이렇게 논의가 되었습니다. 

리스크 기반 테스팅, 말은 많이 들어봤고 아마 그냥 리스크란 단어 자체는 여러분들이 일상생활에서도 많이 들어본 단어라서 기본적으로 어느 정도는 알고 있다. 그렇게 생각을 하는데요. 상황에 의존적인 내용은 아니고요. 개인에 의존적이지도 않고요. 감각에 의존적이지도 않습니다. 

리스크가 무엇이냐? 리스크 기반 테스팅이 무엇이냐? 간단하게 설명을 드리자면 리스크 기반 테스팅은 테스트 대상에 비해서 테스트 자원이 부족한 경우 우선순위를 나눠서 테스트 자원을 효율적으로 분배하기 위한 전략으로 리스크를 정의하고 정의된 리스크를 분석하고 분석된 리스크에 대하여 회피 전략을 세우고 전략에 따라 테스팅을 수행하는 과정 이게 바로 리스크 기반 테스팅이다. 라고 위키피디아에서 설명을 하고 있고요. 간단하게 말씀을 드리자면 체계적, 전문적 그런 단어들을 생각해 보시고 아 테스팅을 좀 더 체계적이고 전문적으로 하는 방법 중에 하나구나. 그렇게 이해하시면 될 것 같습니다. 이렇게 리스크 기반 테스팅에 대한 이야기들이 본부에서 많이 회자되고 그러다 보니까 QA 본부 목표도 2015년 목표도 고객 중심의 리스크 관리로 결정이 되게 되었습니다. 

이때 리더 유닛에서 긴급 제안을 하게 됩니다. 테스트 정책을 다 완료를 했고 그러다 보니까 정책을 이제 배포를 해야 되는데 배포하기 전에 조직의 공감대가 좀 형성되어 있지 않은 것 같다. 그런 얘기를 했었고요. TF 유닛도 마찬가지로 테스팅 가이드 작업이 완료되었기 때문에 이제 시범 프로젝트가 필요한데 어떤 게 좋을까? 이런 고민에 빠지게 되었습니다.

그래서 리더 유닛이 공감대도 없고 시범 프로젝트의 당위성도 같이 부여할 수 있는 기회가 없을까? 했지만 당시에 성수기 준비도 해야 되고 5월이다 보니까 이미 NDC는 끝났고요. 작년에. 그래서 “우리한텐 그런 게 있을 수 없어.”하고 방심하고 있었죠. 그때 갑자기 인사팀에서 당연히 있습니다. 그런 기획 있어요. 있어요. NSC에 나갑시다. NSC는 이제 저희 네트웍스 자체 컨퍼런스거든요. 그래서 “이왕 하는 거 토론 세션으로 나가죠”라는 제안을 해가지고 울며 겨자 먹기로 토론 세션에 참가하게 되었고요, 제가 진행을 했었던 기억이 나네요.

어쨌든 2015년 NSC를 통해서 리스크 기반 테스팅에 대해서 자연스러운 조직 공감대 형성과 시범 프로젝트의 필요성을 다시 한 번 강조하게 되었습니다.

이 토론 세션을 참가하기 전에 몇 가지 준비한 활동도 있는데요. 설문 조사를 실시했습니다. 실제로 리스크 기반 테스팅을 어떻게 사용하고 있는가? 그래서 조사기관은 저희 TF가 조사를 했고요. 당시 QA 진행 중인 모든 프로젝트를 대상으로 리스크 기반 테스팅에 대해서 설문 조사를 진행했습니다. 그래서 조사 기간은 약 일주일, 그리고 조사 방법은 이제 메일을 통해서 설문을 보내고 답변을 받는 형태로 조사를 했었습니다. 그래서 총 10개의 프로젝트에서 답변을 추출하게 되었는데 몇 가지 소개를 해드리도록 하겠습니다.

실제 설문 조사 내용인데요. “리스크 기반 테스트 설계로 업무 효율이 증가한다고 생각하는가?”라는 질문에 거의 대부분은 긍정적인 답변을 해주었고요. “사실상 전수 테스트라서 큰 의미 없다.”라는 18%를 제외한 나머지 답변들은 대부분 이제 긍정적인 반응들을 보여줬습니다. 즉 업무 효율이 증가한다라고 의견을 모았다라고 보시면 될 것 같고요.

리스크 기반 테스트 설계할 때 그럼 어떤 점이 가장 어려운 점인가? 라고 물어봤을 때 이해관계자와 협의를 진행하는 부분이 가장 어렵다. 이게 제일 많았고요. 그 외에도 여러 가지 어려운 점, 애로 사항들을 얘길 했었는데 정리를 해서 말씀을 드리도록 하겠습니다.

토론 세션 자체가 리스크 기반 테스팅을 도입하는데 있어서 어떤 부분이 어렵고 그걸 현실적으로 해결할 수 있는 방안이 무엇일까? 그 부분에 대해서 얘기를 하는 게 핵심이었는데요. 그래서 결론을 말씀드리자면 리스크 기반 테스팅이 좋은 건 알고 있지만 시간이 너무나 많이 걸려서 시간적인 부담이 상당히 크다. 그래서 이걸 어떡하면 좋을까? 라고 얘기를 했을 때 누가 워크숍을 제안했습니다. 사실 QA 조직도 마찬가지고 개발 조직도 마찬가지로 같이 워크숍을 만약에 간다고 하면 보통 친목 형태로 끝나는 경우가 되게 많은데 그냥 친목 형태도 좋지만 정말 자기 프로젝트에 대한 리스크가 무엇인지 정말 진지하게 모여서 다 같이 한 번 장시간 동안 회의를 통해서 리스크 아이템들을 추출을 해보고 리스크 관련 리스크 기반 테스팅에 대해서 정책을 좀 마련을 해보고 전략을 짜보고 그런 자리들을 한 번 마련해보는 게 좋지 않겠느냐? 이런 의견이 나왔었고요. 그리고 지속적 컨텐츠 유입에 대한 부담감이 있다라고 그런 문제 제기를 했었는데 사실 처음 리스크 기반 테스팅을 위해서 세팅을 하는 과정은 힘들지만 한 번 세팅을 해 놓으면 그다음부터는 아마 그런 부담들이 조금씩 조금씩 줄어들 것이다. 이렇게 의견이 나왔었고요. 리뷰로 충분하다. 그런 의견도 있었는데 사실 리뷰로 충분하진 않고요. 객관적인 리스크 기반 테스트를 통해서 좀 더 신뢰도 높은 테스트 결과를 얻을 수 있다. 이런 쪽으로 토론이 진행됐었고 전수 테스트를 하면 된다. 라는 의견이 있었는데 전수 테스트는 말 그대로 전체 다 그냥 보는 겁니다. 전체 다. 그래서 그것보다는 본부의 목표도 고객 중심의 리스크 관리고 그러다 보니까 정말로 고객들이 원하는 것이 무엇인지 그것에 맞춰서 좀 더 집중적으로 테스트를 해보자. 그게 바로 리스크 기반 테스트의 핵심이거든요. 약간 토론하는 과정에서 오해가 있었던 부분 중에 하나는 리스크 기반 테스팅을 중요한 부분은 많이 보고 중요하지 않은 부분은 보지 않겠다 이런 의미가 아니라 다 보는데 다 보되 중요한 부분들을 좀 더 더 많이 케어를 하겠다. 이런 의미로 받아들여야 된다라는 부분을 토론 세션을 통해서 공표를 했었고요. 마지막으로 장수 게임, 메이저 게임들 이런 경우에는 리스크 아이템을 추출하는 데 너무나 많은 시간이 걸린다. 장수 게임이다 보니까 게임 자체가 15, 10년 된 게임들도 있고요 10년이 넘어가는 게임들이 꽤 있기 때문에 리스크 아이템들을 식별하는데 너무 시간이 많이 걸려서 못할 것 같다. 그런 의견들이 있었습니다. 그래서 그런 것들은 고객 문의 데이터를 활용을 해서 원래 오래된 게임이나 메이저 게임들은 다수의 고객 문의들이 있기 때문에 그 고객 문의 데이터를 좀 가공을 하고 활용을 해서 리스크 아이템을 추출하는데 좀 더 쉽게 추출할 수 있지 않을까? 그런 대안을 제시를 했었고요. 마찬가지로 해외 퍼블리싱 게임도 고객 문의 데이터 자체는 해외이거나 퍼블리싱 게임인 경우에는 법인이 달라서 확인할 수 없겠지만 그 대신에 BTS 자료로 확인할 수 있지 않을까? 그래서 실제 법으로 등록된 그런 요소들을 커스터마이징도 하고 카테고라이징도 해가지고 여러 번 가공을 거쳐서 BTS에서 쓴 데이터를 가지고 리스크 아이템들을 추출할 수 있지 않을까? 이런 얘기들이 주로 나왔었습니다.

그래서 토론 세션 전체를 한 번 정리를 하자면 리스크 기반 테스팅의 공감대를 형성했고요. 시범 프로젝트를 선정할 준비도 되었습니다. 그리고 리스크 기반 테스팅의 현실적 문제를 체감했는가? 이 부분은 조금 약간 애매모호한 실제로 체감을 해보지 않고 토론 세션은 아무래도 대안을 그냥 제시하는 상태에서 끝나버리기 때문에 이게 정말 대안인지 아닐지 실제로 해보면 또 전혀 엉뚱한 결과가 나오지 않을까? 그런 의심? 그런 것들이 같이 있어서 총평을 다시 한 번 정리를 해드리면 대부분의 프로젝트에 적용 가능성을 확인했고 모든 게임에 일괄 적용하는 것에 대한 부담감도 조금 확인이 됐고요. 일부 현실적인 문제들이 비용이나 효과, 만족도 등등에서 좀 현실적인 문제들이 드러나게 됩니다.

그래서 이게 이득인지 손해일지 한 번 직접 확인해 보고 싶은 욕심이 생겼습니다. 그래서 리스크 기반 테스팅의 시범 프로젝트를 선정하기로 결정을 하였는데요. TF의 성과 목적이 아니라 정말 실제로 도입에 필요한가? 현실성이 있는가? 등등을 고려를 했고요. 결과와 과정을 모두 중시하도록 했습니다. 이렇게 해가지고 만약에 실패 하더라도 분명히 소중한 자산으로 남을 것이고 TF 구성원들 자체에 되게 많은 경험이 될 것이다. 뭐 그런 이야기가 있었고요. 모든 가능성을 다 열어놓고 검토를 다시 시작을 했습니다. 만약에 실패하더라도 TPI라고 다른 TMMi 말고 다른 성숙도 평가 체계가 있거든요. 이거 실패하면 다른 그거 하면 되지. 그런 얘기도 했었고요. 농담 삼아. 그리고 우스갯소리로 만약에 정말 실패할 경우에는 리스크 기반 테스팅은 게임 QA와 맞지 않다! 이렇게 결론 내리고 그냥 끝내자. 뭐 이런 얘기들도 있었습니다. 그 정도로 모든 가능성을 다 열어놓고 좀 과감한 결단을 내리게 됩니다. 그래서 각 프로젝트 담당자들에게 한 번 시범 프로젝트 해보지 않을래? 그렇게 제안을 했을 때 다들 참 해맑은 표정을 짓더라고요. 어쨌든 이런 열띤 경쟁을 뚫고 선정된 프로젝트가 있는데요. 바로바로 네 잠시 물먹고 진행하도록 하겠습니다.

마비노기 영웅전입니다. 왜 마비노기 영웅전을 선택했느냐? 우선은 TF에서 메이저 게임을 원했습니다. 좀 마이너 한 게임의 경우 좀 특수한 경우라고 그냥 특수한 사례로 쳐버릴 수도 있기 때문에 좀 메이저 게임, 유명하고 대부분의 사람들이 많이 아는 그런 게임들을 주로 해야 결과도 신빙성 있고 범용적으로 쓰일 수 있겠구나 그런 얘기들이 있어서 메이저 게임 그리고 장르적 특성이 RPG로 하자고 했습니다. 스포츠 게임이나 아케이드 게임 등등 여러 가지 많이 있겠지만 좀 더 사람들이 많이 하는 대중적인 게임 장르가 그래도 RPG니깐 RPG로 하자. 그런 얘기가 있었고요. 또 프로젝트의 성향도 같이 고려했습니다. 마비노기 영웅전 같은 경우는 개발, QA, 조직 그리고 운영 조직 마찬가지로 다 어느 정도 소통이 잘 되는 구조를 갖고 있어서 전혀 소통이 되지 않는 프로젝트일 경우에는 그냥 해보기도 전에 사실 실패할 가능성이 되게 높기 때문에 가능하면 저 세 가지를 다 만족할 수 있는 프로젝트가 무엇일까? 고민을 했을 때 바로 마비노기 영웅전으로 선택이 되었습니다. 그래서 사심이 들어간 건 아니고요.

참고 사항을 잠깐 말씀을 드리면 구체적인 리스크 분석 방법에 대해서는 시간 관계상 좀 생략을 하고요. 상세한 내용은 제가 14년에 NDC에서 발표했던 내용을 한 번 참고해주시면 좋을 것 같습니다.

리스크 기반 테스팅 논의 사항 중에서 핵심이 되는 세 가지만 말씀을 드릴 텐데요. 리스크 아이템 식별에 대한 시간적 기준이 가장 많이 논의가 됐었습니다. 업데이트와 관련된 항목이 기준이 아니라 현재 상태 있는 그대로 기준 그대로를 판단해야 된다. 아무래도 처음으로 리스크 기반 테스팅을 하는 것이기 때문에 디폴트 상태를 원했던 거죠. 그래서 처음 있는 그 상태 그대로를 기준으로 리스크 분석을 진행을 하고 만약에 업데이트 될 내용들이 있다면 그때 다시 리스크 아이템들을 다시 추려내서 다시 정리를 하는 그런 형태로 가야 된다. 그런 내용을 주로 얘기를 했었고요.

그리고 두 번째로는 리스크 아이템 식별된 기준을 계속 이제 리마인드를 했었습니다. 게임 자체의 구성요소인 그래픽, 사운드, UI, 효과 이런 요소들은 리스크 아이템으론 좀 부적합하다. 라는 결론을 내렸는데 약간 오해가 있으실 것 같아서 말씀을 드리자면 그래픽, 사운드, UI, 효과 이런 게 리스크가 없다는 게 아니라 너무나 리스크가 높기 때문에 굳이 리스크 아이템으로 넣을 필요가 없다라는 의미입니다. 그래서 보시다시피 게임 자체 구성요소인 그래픽이나 사운드, UI 이런 게 만약에 안 될 경우에는 당연히 리스크가 높은 쪽으로 배정이 되겠죠. 그렇게 되면 리스크 분석 자체를 하는 변별력이 좀 떨어지고 그러다 보면 정확한 결과가 나오지 않을 것이다. 그래서 저런 게임 자체 구성요소는 배제를 하고 진행을 하자. 이렇게 얘기가 됐었습니다.

세 번째로 최적화를 위한 커스터마이징. 고유한 특징, 게임이나 프로젝트 자체의 고유한 특징이 내재된 리스크 아이템과 리스크 요소는 그대로 그냥 표기를 하거나 아니면 부가 설명을 추가하거나 아니면 아예 새로운 용어로 변경을 하자. 그래서 어느 정도 자유도를 줬습니다. 커스터마이징 할 수 있게끔. 그래서 마비노기 영웅전에 있는 마을 기능이라고 하는 것은 온천, 소각, 마을 이동 스크롤을 다 포함한다. 그렇게 설명을 추가하거나요. 아니면 아예 독립적으로 빼서 온천, 따로 빼도 되고요. 소각도 따로 빼고요. 어쨌든 그런 식으로 예시니까요. 그런 식으로 진행을 하자. 이렇게 했었고요. 리스크 요소인 외부적인 과시성이란 말이 너무 어렵다. 한 번에 바로 이해하기가 어렵다 그래서 저희 게임 쪽에서 많이 쓰이고 있는 단어인 동향으로 교체를 하였습니다. 이런 식으로 커스터마이징을 진행해서 조금 더 수월하게 분석을 할 수가 있었습니다. 

그래서 선정된 결과를 잠시 예시로 보여드릴 텐데요. 총 24가지의 리스크 아이템들이 선정되었고요. 예시니깐요. 그리고 그 리스크 아이템들을 통해서 결과적으로 리스크 분석 분포도, 리스크 분석 매트릭스를 만들게 되었는데 그것도 보여드리도록 하겠습니다.

보시다시피 마비노기 영웅전 전투가 상당히 중요한 시스템으로 자리 잡고 있어서 전투 시스템들이 대부분 리스크가 높은 쪽에 위치해 있겠죠. 그래서 이렇게 리스크 기반 테스팅을 했더니 어떤 의의가 있었나? 한 번씩 살펴보면 네 이 값은 사실 이제 표준이고 즉, 디폴트 데이텁니다. 그래서 이걸 기반으로 새로 업데이트가 있을 때 그 내용들을 여기다 어디다 넣을지 또는 넣을지 뺄지 조차도 다 다시 한 번 검토를 하게 되고 그렇게 진행을 하도록 하자. 이 내용을 디폴트 데이터니까 항상 이걸 참고해서 테스트를 진행하자. 그런 내용들이 좀 큰 의의로 다가왔고요. 그리고 프로젝트의 각 조직장들이 참여해서 만든 결과라는 게 정말 큰 의의인 것 같습니다. 그래서 디렉터를 포함한 개발 조직, 사업 조직, 운영 조직, QA 리더 다 모두 참여해서 저렇게 하나 된 일치된 결과를 얻었다. 라는 점이 리스크 기반 테스팅의 큰 의의라고 할 수 있겠죠. 실제로 이것은 그리고 2016년 3월부터 적용 중이고 2016년 3월에 스크린샷 모드가 추가되었고 기타 전투가 변경되었습니다. 그래서 실제로 스크린샷 모드가 보시다시피 표시되어 있죠? 그리고 기타 전투도 원래 기타 전투가 여기에 위치해 있었으나 지금은 이렇게 더 위에, 리스크가 높은 쪽으로 위치하게 되는 변경, 실제 실무에서도 이렇게 적용을 했다. 그런 부분들. 그런 게 의의로 다가올 수 있고요. 마지막으로 매 업데이트마다 이렇게 리스크 기반 테스팅을 설계해서 각 사분면에 맞는 테스팅 전략을 수립해서 진행을 하고 있다. 그렇게 정리를 할 수 있겠습니다.

리스크 기반 테스팅을 진행을 했는데 뭔가 좀 실제 실무자가 관리자들에 대한 의견, 이런 것을 좀 듣고 싶어서 직접 인터뷰도 진행을 했었는데요. 인터뷰로 나온 결과물을 보여드리도록 하겠습니다. 먼저 테스트 리드가 어떤 의견을 줬냐면 신규 투입 항목들은 항상 리스크가 높다라는 편견이 있었는데 그런 거를 조금 깰 수 있었다. 예를 들자면 신규 투입된 항목들은 보통 QA 관리자분들은 아시겠지만 대부분 이제 리스크가 높다라고 생각을 하게 되는데 사실 그걸 좀 더 쪼개서 조목조목 살펴보면 기존에 사용됐던 그냥 리소스를 조금 가공해서 새로 그냥 업데이트하는 것일 뿐인 경우도 많이 있거든요. 그래서 그렇게 되면은 장애 발생 가능성 자체가 낮아지기 때문에 반드시 리스크가 높은 것은 아니게 됩니다. 그래서 그런 부분들을 좀 더 고려할 수 있었다. 그리고 TL의 관점에서 이런 부분들이 좀 새롭게 다가왔고 그 리스크 분석한 데이터, 그 결과값은 결국 다양한 조직의 의견이 합치된 기준이기 때문에 좀 더 체계적이고 조직적으로 리스크를 관리하고 테스팅도 마찬가지로 관리를 할 수가 있었다. 그래서 긍정적인 평가를 내렸습니다.

그리고 관리자와 실무자 모두 다 신뢰할 수 있는 테스팅이라는 답변을 받았는데요. 중간 관리자죠? 중간 관리자가 리스크를 사전에 파악을 할 수 있어서 테스팅을 하기에도 좀 더 편했고 리스크 기반 테스팅을 만약에 하지 않았더라면 각 중간 관리자들이 생각하는 리스크가 조금씩 다 다르기 때문에 테스트를 했을 때 결국 마지막에 나오는 결과물도 분명히 그런 기준이 다르기 때문에 영향이 있을 수 있지 않냐? 그래서 이런 리스크 기반 테스팅을 했기 때문에 좀 더 신뢰할 수 있는 모두 같이 신뢰할 수 있는 결과물을 얻을 수 있어서 긍정적으로 평가했었습니다. 그리고 마지막으로 좀 정리를 하자면 이렇게 각 리스크 아이템에 대해서 확신이 있고요. 그 표를 보셔서 아시겠지만 그 표는 혼자서 정하는 게 아니기 때문에 테스트 리드가 교체가 되거나 부재 시에도 얼마든지 유용하게 참고 자료로 사용할 수가 있고요. 그래서 앞으로도 계속 진행해볼 의향이 있다라고 긍정적으로 평가를 하였습니다.

그래서 마비노기 영웅전 리스크 기반 테스팅을 진행하면서 무엇을 얻었는지 정리를 하자면 리스크 기반 테스팅을 적용했는가? Pass고요. 앞으로도 진행해볼 용의가 있는가? 역시 Pass입니다. 총평을 하자면 비록 리스크 기반 테스팅을 위한 비용이 많이 들지만 장기적인 안목에서 진행하는 것이 도움이 된다라고 판단을 했습니다. 하나의 또 사례를 말씀을 드리자면 리스크 아이템을 식별하는 그 과정에서 실제로 저희가 따로 얘기를 하진 않았지만 8시간 이상 워크숍을 진행한 적도 있다고 하네요. 그래서 실제적으로 비용은 되게 많이 들었지만 장기적으로 봤을 때는 결국엔 계속하는 것이 도움이 된다라는 긍정적인 답변을 받았습니다. 네 이제 여기까지가 저희가 TF가 현재까지 진행한 활동들이고요.

앞으로의 계획을 말씀드리도록 하겠습니다.

먼저 리스크 기반 테스팅을 좀 더 확대하고 리스크 추적 단계로 진입을 하고자 하는 목적이 있습니다. 현재 리스크 기반 테스팅이 적용된 프로젝트의 경우에는 좀 더 강화를 할 예정이고요. 그리고 점진적으로 다른 프로젝트도 확대해 나갈 예정입니다. 그리고 리스크 기반 테스팅 데이터를 누적하고 관리를 할 텐데요. 사실 이 PT를 준비하면서 혹시나 마비노기 영웅전이 결과가 안 좋게 나오면 어떡하나? 라는 고민에 빠져서 약간 보험 형태로 바람의 나라랑 Combat Arms를 리스크 기반 테스팅을 진행을 하고 있습니다. 다행히 마비노기 영웅전 결과가 좋게 나와서 저 두 가지는 지면 관계상 생략을 했는데요. 어찌 됐건 계속 데이터를 누적하고 관리를 진행을 하고 있고요. 리스크 추적이나 리스크 예방, 리스크 분석을 하는 이유, 리스크 기반 테스팅을 하는 이유는 사실상 그런 리스크를 예방하기 위함이 가장 큰 목적이거든요. 그래서 예방책에 대해서 좀 연구를 진행을 했는데 그 리스크 자체를 버그 리포팅에다가 레이블을 추가해서 등록을 하고 그 버그 리포트 데이터들을 토대로 리스크가 어떻게 변화하는지 월간 또는 주간 아니면 두 달, 세 달, 마일스톤 간격으로 리스크가 어떻게 변화하는지 리스크가 리스크 아이템으로써 자격이 있는지 없는지 그런 것들을 좀 추이를 살펴볼 수 있도록 하는 그런 연구가 진행 중에 있고요. 고객 문의 데이터도 마찬가지로 활용을 해서 좀 가공을 많이 해서 최신화 시키거나 해서 요즘 가장 리스크가 높은 것이 무엇인가? 이런 것들도 좀 더 디테일하게 볼 수 있지 않을까? 그래서 예방책을 연구 중입니다. 그리고 두 번째로 아마 가장 어려운 연구가 되지 않을까 싶은데요. 모바일 QA에 적용하는 방법에 대해서 연구를 하고 있습니다. 여러분들도 아시다시피 수명주기가 상당히 짧은 모바일 게임에 과연 TMMi 또는 리스크 기반 테스팅을 적용할 수 있을지 그거에 대해서 연구를 진행 중이고요. 마찬가지로 모바일 QA 프로세스 최적화에 대한 연구도 같이 진행 중에 있습니다.

세 번째로는 게임에 접목한 리스크 기반 테스팅의 한계점인데요. 그냥 리스크 기반 테스팅의 한계점이라기보다는 게임과 같이 접목을 하다 보니까 발견되는 한계점들이 몇 가지 있었습니다. 그래서 먼저 제일 중요한 게 소통의 부재. 만약에 다른 프로젝트였다면 마비노기 영웅전의 경우는 소통이 잘 되는 프로젝트라서 성공을 위한 견인차 역할을 했다면 만약에 소통이 잘 되지 않는 수직적인 구조의 프로젝트였다면 이게 과연 제대로 적용이 될 수 있을까? 그런 한계점을 좀 파악할 수 있었고요. 스코어링 작업을 할 때 설득력 부족, 피로도 누적이라고 되어 있는데 부연 설명을 드리자면 뭔가 분명히 자기 스스로는 리스크가 높다 또는 낮다라고 판단을 하지만 뭔가 설득할 수 있는 표현력이 부족하거나 그래서 말을 제대로 못 해서 그냥 상대방의 말에 그냥 동의를 해버리는 경우 그렇게 돼버리면 올바르지 않은 결과가 나오겠죠? 그리고 이런 식으로 계속 그런 것들이 누적이 되다 보면은 나중에는 결국엔 막판에는 그냥 TL이 하자는 대로 하자. 또는 팀장이 하자는 대로 하자. 이렇게 돼버리는 그런 경우도 있을 수가 있어서 TF 딴에서 계속 확인을 할 수 있게끔 계속 감시를 한다거나 아니면 중간중간에 계속 가이드를 해준다거나 그런 부분들이 필요하지 않을까? 뭐 이렇게 생각을 하고 있습니다. 또한 장애 발생 가능성, 장애로 인한 영향력 판단 부족 이것은 장애 발생 가능성 같은 경우에는 안 그래도 아까 하나 예시로 드렸는데 코드를 재사용한 경우 이런 부분은 아무래도 QA보다는 개발 쪽에서 좀 더 정확한 답변을 해줄 수 있을 것 같고 개발 쪽에서 조금 더 리스크에 대해서 명확한 판단을 할 수 있을 것이다. 그리고 장애로 인한 영향 이것도 마찬가지로 아까 경제적인 피해라는 부분이 있었는데 리스크 요소에. 그런 부분을 매출 데이터가 공유가 되지 않은 경우에서는 경제적 피해를 QA 조직에서 가늠하기에는 쉽지가 않거든요. 그래서 그러 부분에 있어서 어느 정도 공유가 필요하지 않나. 그래서 실제로 S/W 테스팅 같은 경우에서는 저런 매출 데이터를 그냥 공개를 해서 1억 이상 손실이 났을 경우에는 리스크 9점 이렇게 아니면 5000만 이상일 때는 3점 이런 식으로 배점을 하는 경우도 봐 왔거든요. 그래서 그런 부분들에 있어서는 좀 조직 간에 조금 더 다양한 공유가 필요하지 않을까? 물론 제한적인 선에서 공유를 하는 거겠지만요. 그리고 이제 프로덕트 리스크와 프로젝트 리스크, S/W 테스팅에서도 사실 많이 헷갈리는 부분 중에 하나고 게임은 더더욱 심하게 이 부분에 대해서 좀 혼동이 많이 되는 부분 중에 하난데 제가 드리고 싶은 말씀은 그거에요. 프로덕트 리스크를 아무리 QA 조직에서 잘 짜고 지금 마비노기 영웅전이 되게 잘 된 케이스긴 하지만 그런 식으로 하더라도 프로젝트 리스크에 대해서 전혀 공유가 되지 않는다면 과연 그 프로젝트가 성공을 할 수 있냐? 그런 의문에 빠지게 되었고요. 실제로 제가 QA 업무를 진행을 하면서 그 프로젝트 리스크에 대해서 직접적으로 언급을 받은 적은 거의 없거든요. 손에 꼽을 만큼. 그래서 이제는 모든 조직들이 다 같이 프로젝트 리스크에 대해서 진지하게 고민을 해봐야 되지 않을까? 그런 고민에서 리스크 기반 테스팅의 좀 한계점이라고 짚어봤습니다. 네 그리고 네 번째로 그 외 리스크 기반 테스팅을 제외한 모든 TMMi의 모든 영역들도 슬슬 이제 준비를 해야겠죠. 테스트 정책과 전략을 최신화해야 될 것이고 테스트 성과 지표를 좀 더 검토를 해서 적용을 시켜가야 될 것이고요. 인테이크 테스트는 일반적으로 얘기하는 게 스모크 테스트를 말하는 건데 그 스모크 테스트 절차를 문서화하는 것 등등등 다양한 일들이 앞으로 계획되어 있습니다. 네 저 혼자 하겠다는 뜻이 아니고요. 저 그림이 있다고 너 혼자 다 해. 이렇게 얘기하실 수도 있을 것 같아서. 

네 이제 결론입니다. 결론을 두 가지로 나눠봤는데 리스크 기반 테스팅에 대한 결론과 TMMi TF 활동에 대한 결론 두 가지로 나눠봤습니다. 게임 QA에 리스크 기반 테스팅 이론을 적용 가능하다라는 것이 결론으로 밝혀졌고요. 앞서 살펴본 바와 같이 일부 개선점 그리고 한계점이 있는 것은 사실이지만 적용이 가능한 것은 사실입니다. 그래서 긍정적인 효과가 더 컸다고 보고요. 이에 TMMi 기본이 되는 리스크 기반 테스팅을 순차적으로 적용하는 것을 본부 차원에서 검토해볼 필요가 있다. 라고 생각을 합니다. TMMi TF 활동에 대한 결론은 TMMi 레벨2 2레벨 달성을 위해서 위대한 첫걸음을 내딛었다라고 생각을 하고요. 테스트 정착, 아 정책과 전략도 만들고 게임 QA에 리스크 기반 테스팅도 적용을 하였습니다. 그래서 이제 시작하는 단계기 때문에 앞으로 데이터를 많이 쌓아서 좀 더 분석하고 그래서 최적화된 프로세스를 만드는 것. 그것이 결국 저희 TF의 목적이 아닐까? 그렇게 생각을 합니다. 

생각해볼 문젠데요. 리스크 관리의 주체는 과연 누구일까? 제가 뭐 여러 번 강조하는 것 중에 하나인 것 같은데 리스크 관리는 과연 QA 조직이 전담하는 것일까요? 실제로 리스크 기반 테스팅을 진행을 하다 보면 개발 조직이나 아니면 다른 사업 조직에서 특별한 피드백을 주지 않습니다. 거의. 그래서 그냥 알아서 하시겠죠. 잘 하시니깐요 뭐. 믿고 맡기겠습니다. 이런 식으로 얘기를 되게 많이 하시는데 사실은 그렇게 하시면 안 된다고 보거든요. 왜냐하면 장애 발생 가능성도 마찬가지고 장애로 인한 영향도 마찬가지겠지만 이것을 QA 조직이 100% 판단하는 것이 과연 옳을까요? 라는 그런 고민에 빠지게 되었습니다. 그래서 모든 이해 관계자들이 적극적으로 관여를 해서 전문적이고 체계적인 리스크 관리를 한다면 좀 더 성공할 수 있지 않을까? 프로젝트가 성공하는데 크게 기여를 할 수 있지 않을까? 저는 그렇게 생각합니다. 

네 이제 에필로그로 넘어가도록 하겠습니다.

왜 구글, 애플, 페이스북, 아마존 등과 같은 글로벌 기업들이죠. 글로벌 기업은 왜 TMMi 인증을 받지 않는가? 사실 이 질문은 저희가 TMMi 교육을 갔을 때 한 교육생이 강사분께 질문을 한 내용인데요. 저도 좀 되게 공감이 많이 돼서 가져와봤습니다. 정답은 각각 글로벌 회사들은 자기 회사들에 최적화된 프로세스 이미 갖고 있기 때문에 굳이 TMMi 인증을 받지 않는다. 라고 하시더라고요. 그러면 과연 TMMi 목표는 무엇일까? 좀 고민을 해봤죠. 그랬더니 가장 좋은 프로세스는 바로 당신 팀원들에게 가장 최적화된 프로세스가 아닌가라고 생각을 합니다. 즉, TMMi 인증 그 자체 또는 프로세스 그 자체가 그냥 목적이 되어서는 별로 큰 의미가 없다. 최적화, 최적화가 제일 중요하다. 뭐 그런 이야기겠죠. 그래서 마지막으로 말씀을 드리면 결국엔 프롤로그에서 언급했던 것처럼 사람 그리고 프로세스가 잘 갖춰진 조직이 테스트 성숙도가 높은 조직이 아닌가? 그렇게 생각을 합니다. 

마지막으로 당부의 말씀을 드릴 텐데요. 세계 최초로 TMMi를 인증을 받는 것 반드시 넥슨일 필요가 없습니다. 지금 여러분들 중에서도 TMMi 준비하고 계신 분도 계시겠고 계실 수도 있을 것이고 리스크 기반 테스팅을 진행하는 조직도 분명히 있을 텐데요. 그런 자료들을 지금 저와 같이 공유를 해서 좀 더 보완을 하고 서로 같이 터놓고 얘기하는 그런 자리들이 많이 만들어진다면 게임 QA에서 TMMi 인증을 받는 것, 우리나라에서 할 수 있지 않을까요? 그러기 위해서는 누가 움직여야 될까요? 저희는 본부장님부터 신입사원까지 다 같이 관여해서 움직였다. 라고 말씀을 드릴 수 있습니다. 지금 이 자리에 모든 분들이 그 열쇠를 쥐고 있다라고 생각을 합니다.

이상으로 발표는 마치겠고요.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
