첫 글을 올리고 QA란 직업이 생소 했을 텐데도 오히려 많은 분들이 동감과 궁금증을 가져주셔서 감사했습니다.
QA란 직업이 생소한 이유는 아마도 QA는 어쌔신처럼 은밀하게 일을 하게끔 만드는 환경이라 인듯합니다.
매년 넥슨에선 NDC라는 게임 개발 컨퍼런스를 진행하고 있습니다.
해당 컨퍼런스에서 QA 관련 세션은 겨우겨우란 느낌으로 껴있습니다. 아마 QA 세션이 없던 해도 몇 번 있던걸로 기억하네요.
그럴만도 합니다. QA 활동은 자사 제품의 결함을 찾아내는 일인데 그걸 컨퍼런스에서 발표한다면 어느 회사가 좋아 할까요.
과거에 블리자드 QA 세션을 들을적이 있는데 결국 주 내용은 우리 게임 개발하는데 이런이런 테스트가 필요했고 개발팀과 협력해서 테스팅툴을 이렇게 만들어서 잘 썼다! 하는 자랑이더군요. 아마 당시 세션 듣던 QA분들 대부분 저 포함해서 부들부들하지 않았을까 싶네요.
여튼 그런 관계로 QA는 정보 공유가 어렵습니다. 게임 QA 관련 커뮤니티도 네이버에 큰 카페 하나가 있는데 지금 이 글 쓰면서 다시 확인해보니 정보글은 정말 왜소합니다. 몇 달 내지 몇 년 간극이라니...
어쩔 수 없죠. 내가 담당하는 게임에 이런 버그가 있는데 어떻게 찾아야 할지 모르겠다. 아니면 이런 시스템이 있는데 어떻게 테스트 시나리오를 짜면 좋을까요? 이런 식의 회사 내부 정보를 공개하며 질문 글을 쓸 QA는 없을 테니까요.
저는 꽤 초창기 온라인 게임 붐 시대에 QA를 시작해서 덕을 본 케이스입니다. 그때는 국내에 QA의 개념도 많이 모르던 시절이고 다같이 알아보자. 하던 시절 이었거든요. 그러면 그렇게 알아보자. 한 걸로 데이터도 쌓고 지식의 피라미드도 쌓아서 지금이면 QA를 지망하는 사람들에게 양분이 되어야 했는데 현재에 그런 분위기는 아닌 것 같습니다.
이유가 뭘까요?
여기서 부터는 평소 생각한 뇌피셜 입니다.
근 10년 사이 한국 온라인 게임이 성장하면서 게임 테스터로의 취업도 많이 권장된 적이 있습니다. 대학교의 취업율과 게임 회사의 게임 테스트는 아무나 할 수 있어. 란 포인트가 맞아 떨어진 덕이죠. 그래서 많은 QA 경력직들이 밀려나기도 했습니다. 이직 하려고 해도 QA의 중요성을 잘 모르는 회사 위 입장에서는 아무나 할 수 있는 거 그냥 싼 대학생들 인턴, 비정규직으로 대체 시키고 그 인턴들만 관리할 1,2명만 둬. 라는 분위기였죠.
그리고 모바일 게임 붐이 옵니다. 이때 진짜 많은 온라인 게임들이 제작되었습니다. 골드러쉬가 이런 분위기였나 싶을 정도로 당시 드래곤 플라이트나 애니팡 같은 게임의 큰 성공으로 많은 모바일 게임 제작사가 생겼다가 서비스 종료와 함께 망하는 분위기 였습니다. 기억나는게 루리웹의 정보 게시판에 모바일 게임 서비스 종료 뉴스만 올리는 이용자가 있었는데 거의 매일 그리고 어떤날은 3,4개씩 서비스 종료 뉴스를 올리는 날도 있었습니다.
외부적으로는 그런 상황에 많은 게임 테스터들이 생겼고 QA에 대한 교육은 없는 상태로 위에서 내려온 테스트케이스만 수행하는 봇이 되고 일은 고되고 보람도 없고 그렇게 이 길이 아니다 싶어서 많은 분들이 다른 일을 찾아 나서는 것을 많이 봤습니다. 안타까운 일 이라기에는 다른 일 시작해서 저보다 잘된 분들도 많이 봐서 오히려 이 일만 계속 잡고 있는 내가 안타까운 건 아닐까.. 라는 생각도 좀 드네요.
위와 같은 일도 있고 국내에서 게임 QA는 언제나 뒷전인 것도 있을 겁니다.
개발 초기부터 서비스까지 QA를 진행하는 회사는 정말 별로 없기도 하고 그 인력비용을 개발인원에 더 쓰고 싶어 하거든요. 그러다보니 모바일 게임 제작사 치고 QA 두는 회사도 거의 없었을 겁니다. 퍼블리셔쪽이 대부분 견인했죠.
QA도 개발자들이 새 언어 나오고 기술 나오고 하면 공부해야 하는 것처럼 새로운 테스트 베드(환경)을 공부해야 하는데 돈 버는 모바일 게임 회사들이 앞서나가야 그 뱀의 꼬리처럼 따라가게 되니 그 과정에서 도태된 부분도 있을 겁니다.
이런 악재들이 겹쳐져서 지금은 QA의 위상이랄 것도 없고 QA가 무슨 일을 하는지 모르는 사람이 많은 은둔자 같은 직업이 되지 않았나 싶습니다.
왠지 이번 이야기는 하소연에 가까운 이야기들이 되었네요.
너무 중구난방으로 이야기 하는 것 같은데
다음은 퍼블리셔와 개발사에서의 QA 경험에 대한 얘기를 풀어보겠습니다.
긴 글 읽어주셔서 감사합니다.
이번은 뇌피셜까지 들어간 글이라 다른 생각을 가지신 분들의 의견을 주시면 저도 다른 방향도 생각해 볼 좋은 기회가 될 것 같습니다. 편하게 의견 주시면 제가 더 감사하겠습니다. ^^
QA라는 일의 특성이 결국은 다 비슷한 모양이네요.
우리나라 QA팀에 외국에 비해서 부족한 부분은 내부적으로는 개발능력(코드를 보고 이해하거나 테스팅툴을 만들어 사용하거나 하는 업무 능력 더 나아가면 테스트서버를 스스로 구축하 고 개발 코드를 수정해서 개발자에게 제안하는 수준의 능력)과 외부적으는 권한(QA팀이 이상태로 안된다고 거부하면 프로젝트가 멈추거나 일정을 수정시킬 수 있는 권한)이라고 봅니다.
이 두가지가 동시에 갖춰지지 않으면 개발팀과 영업팀에게서 양쪽에서 무시아닌 무시를 받게 되죠.
QA팀도 내부적으로 이런 능력을 키울수 있도록 노력해야 합니다.
아마 위쪽에 올라간 QA분들은 지금쯤 QA팀 내부 인원을 저런 실력을 갖추도록 노력하고 있을거라 봅니다.
회사에서는 일정에 개발과 QA일정을 같이 고려해야 하고 완성도를 높이려면 QA에 힘을 실어줘야죠 투자도 하구요.
몇몇 큰 회사들은 이런 노력을 전사적으로 하려고 하는 시도도 꽤 하는 걸로 알고 있습니다.
마지막으로 입사해서 처음 몇년은 그냥 게임 실력과 센스만으로도 지낼 수 있지만 그 이상되면 위에 얘기한 능력들이 갖춰지지 않으면 QA로서 남아 있기가 어렵게 됩니다. 게임 QA에 관심 있는 분들은 게임뿐만 아니라 개발자들만큼 열심히 지속적으로 공부하지 않으면 안됩니다. ㅡㅡ;
저는 QA가 화이트박스 테스팅 한다며 코드리뷰 할 줄 알아야한다는 것에 회의적입니다. 어설프게 코드 볼줄 아는 QA가 코드리뷰를 한다는것도 이상하고 코드리뷰를 할만큼 코딩이 가능한 QA가 QA를 한다는것도 이상하거든요.
예전에 페어 프로그래밍을 하는 그룹을 본적이 있습니다. 코드 업로드전에 자기 짝 프로그래머에게 코드 리뷰를 진행 후 코드를 올리는 업무 형식이었는데 이게 그래도 이상적인 화이트박스 테스팅의 형태가 아닌가 싶었는데 이것도 문제는 코드의 내용만을 확인하고 해당 코드의 테스트 시나리오를 설계하지 못하는 경우도 발생한다는 것이었습니다.
그리고 위와 같은 업무방식으로 개발하면 안정성은 높아질지 몰라도 효율성은 떨어진다는 단점도 있구요.
물론 테스팅 도구를 어느정도 QA가 만들어 낼 수 있으면 좋다는 것은 저도 동감합니다. 코드에 대한 이해도는 이전 글에도 썻지만 모르는 것보다 아는것이 더 좋다는 것 또한 동감하구요.
저도 이에 동감합니다. QA 테스터가 전문 인력이라며 더 고급 인력으로 대우를 해주고 높은 급여를 주면서 일을 맡겨야 한다고 강변하던 상사를 만난 적이 있는데, 그런 QA인력이 현실적으로 어디에 있나 싶습니다.
매크로를 다룰 줄 알고 테스팅을 위한 스크립트를 짤 수 있는 정도만 되어도 테스터로서는 상당히 고급인력으로 대우해줍니다. 사실, 그 정도만 되면 QA팀에 있다가 개발팀으로 이직하는 경우가 흔합니다.
너무 광범위하게 코드 리뷰를 얘기한 모양입니다. 우선 언급한 코드 리뷰는 매 과정이 아닌 일부분에 대한 것, 정확히는 버그가 발생하는 부분에서 의심되는 부분에 대한 것이었습니다. 그것도 한 번 발생하는 버그가 아니고 자꾸 버그를 만들어서 왜 자꾸 버그를 만드나 하고 들여다볼 수밖에 없었던 경우라고 해야겠네요.
하지만 그 한 번으로 인해서 개발팀의 QA에 대한 인식이 확 바뀌긴 했습니다. ^^;
+1
테스트 환경 구축하는 것도 매크로 짤 수 있으면 아주 편하죠
처음에 데이터 10000개를 준비해야 했을 땐 매크로 짜서 돌렸습니다 (사랑해요 자동그것)
GUI 기반이라 몇시간 걸리더라고요
다음에는 sql 스크립트를 짜니 시간 단위 일이 분 단위로 바뀌었습니다ㅋㅋ
퍼포먼스 테스트를 위해 Linux/Unix용 cpu 메모리 로그 스트립트도 짜야하기도 했고요
뭔가 수박 겉만 핥는 느낌이지만 재미는 있습니다ㅠ
@iohc님
거기에 이슈 재현 할 때도 수정 전후 비교하면 찾기 수월해지죠
또한 모바일게임이나 PS, 엑박 같은 것은 인증을 통과하려면 전문적인 QA 환경과 QA하는 사람이 필요하구요.
외국은 PS나 엑박 인증 받아 주는 QA만 하는 회사들이 좀 있는 것으로 알고 있습니다.
다만 개발시 절대 대외비밀을 유지하는 제품을 외주를 줄 수 있느냐의 문제가 있지만 전문 업체 생겨나는 것을 보면 한 번 신뢰를 쌓으면 쭈욱 유지될 것 같습니다.
모바일도 현재 큰 회사들은 다 자체적인 QA조직을 갖춘곳도 많아졌고
국내에도 아웃소싱형태의 게임전문QA 회사들이 있어서 해당 회사를 이용하는 경우도 많다고 합니다.
아무래도 그렇겠죠.
모바일 게임 시장이 무지 커졌고, 다양한 환경이 PC 하드웨어와 소프트웨어와 비슷하니까요.
저를 찾지 말아주세요. 부끄럽습니다. ㅎㅎ
요즘 게임 회사들은 구로쪽에 많이 있나요?
전에는 테헤란로하고 분당에 많이 있었던 것 같은데 말이죠
내용이 익숙하다는건 그만큼 게임QA 조직이나 사람의 생리가 대부분 비슷하다는 뜻일겁니다. 저는 현재 큰회사에 있진 않으니 혹시 생각하시는 그곳의 사람은 아닙니다. ㅎㅎ
저는 오류 외의 개선사항들은 번외로 던집니다. 제 주관에 의한 결과는 되도록 배제 할려고 하거든요.
오래하다보니 느끼는건데 내 의견을 상대방이 듣게 하는 것도 나름의 스킬이더군요. 그리고 매우 어렵고 적용 확률도 매우 낮습니다. ㅎㅎ
초창기에 안철수연구소 인턴으로 시작해서 여기까지 왔는데 참 우여곡절이 많기도 했고,
하는 만큼 보람차기도 하고 그러네요ㅠㅠ
아직 갈길이 멀고 할일도 많은데 몇살까지 일할 수 있을 지 걱정입니다.
수고 많으십니다. ㅎㅎ
앞으로 정년퇴직 할때까지 오래오래 해먹(?)도록 노력해보죠. ^^
그리고 비용절감을 하면 꼭 스텝 조직보다 실무부서부터 감원을 합니다.
별로 일 안하는 것 같은 QA나 네트워크 등등이 해당하죠.
그러면서 품질은 점점 산으로 가고 뭐가 문제인지도 모른채 제대로 안만든다며 개발자를 까고... 결국 총체적 난국이 되더라구요.
물론 대기업도 절대 예외가 아닙니다. 외주화 하는 곳도 상당히 많아졌죠.
쉽게 말해, 방귀낀 놈이 성낸다?는 식으로 일이 진행되서 일 것 같습니다.
게임 개발은 생각보다 돈이 많이 들어가죠. 제 생각에는 큰 회사는 잘 모르겠지만 작은 회사의 경우 알파 프로덕션 부터 팀업을 하는 생태가 잘못된 단추를 끼는 행위가 아닐까 하는 생각도 듭니다.
그러다보니 비용문제가 생기고 그 결과는 비핵심 인력 위주의 감원으로 이어지구요..
10년 지나면 대부분 많이 변경되어서 대략적이라도 공유되어도 괜찮치 않을까 싶은데...개발 비화처럼요.
일반 설계 쪽은 개발 비화가 방송 프로그램화 된 적도 있죠. 일본에서 시작해서 우리나라도 따라간 것으로 알고 있는데...내용보면 우리나라는 부끄럽더군요. 문제나 결함이 생기면 연구원들이 밤새서 해결했다더군요. 특히 전투기 개발 때 CAD 설계에서 중심축 틀린 거 보고 기겁했죠.
아무래도 회사의 프로젝트이고 QA개인의 프로젝트가 아니니 시간이 지난다고 될리는 없을것 같습니다.
그래도 화사 내부적으로는 포스트모텀이라던가로 활용 하겠죠.
QA필요성, 중요도로 보아도 대하는 마인드부터 다른 이유는 그것이 부수업무라 여기기 때문입니다.
생산품이 나오기 위해 필수 프로세스에 정해놓은 것이 아니니 없애고 개발팀이 개밥먹기로 테스트하거나 조직을 조정해도 된다 여기기 때문이겠죠.
우리나라 소프트웨어 시장에선 게임 말고는 대형 소프트웨어를 대규모 조직에서 생산하는 케이스가 너무 적기 때문일지도 모릅니다.
삼성 정도는 어떻게 하는지 그 솔루션이나 절차 등이 궁금해지는군요. 지금은 SI에서 밥벌어 먹고 있어서 QA라는 존재도더 못볼 수 밖에 없겠지만요.
제가 아는 QA의 업무는
1.사전에 약속한 업무 플로우로 일이 잘 진행되고 있는지 확인 (감사, 감리)
2. 불명확한 업무의 재정의 및 재정립
3. 이슈 및 인시던스에 대한 해결책을 모색하고 관련부서에 업무지시
4. 테스트 케이스가 타당한 지 검토
5. 납기 준수 및 목표 품질 달성을 위해 관련부서 압박
6. 사후관리를 위한 창구 역할
(퍼블리셔 혹은 내부 운영/사업팀, 고객지원센터로부터 각종 클레임, 문의 등등을 접수하여 해결; 주로 관련부서에 시정조치 지시)
제가 QA를 보고 떠오르는 이미지는
심판? 교통정리? 감독? 탱커? 동네북? 암행어사? 사우론?
입니다.
말씀하신 테스트베드를 꾸미고 실험하고 버그 찾아내는 역할은 QC가 하고 있습니다.
얘기하신 것도 이미 하고 있는 업무입니다. 짧은 글에 주제만 토막토막 잡아 쓰니 다 쓰진 못하고 있습니다. ㅎㅎ
저희 팀은 인원이 단일 부서로는 회사에서 가장 큰 부서임에도, 노하우는 전래동화처럼 구전으로 이어지는 경우가 빈번합니다...
체계적으로 무언가 하기엔 일이 너무 많고, 이슈가 너무 많이 터져서.....
ISTQB니 뭐니 기법들도 현업과 동떨어져 있기도 하고, 규모가 작으면 개발자가 QA까지 해야 하는등.... 윗분들이 QA에 강력한 의지가 없는 이상 SW QA가 R&R을 제대로 가져가기 힘들죠... 매년 R&R협의 하지만, 개발자들 각 개인에게 전파가 안되는 경우도 빈번하고... 그냥 몸으로 때우는게 국내 SW QA라고 생각합니다.
중요성은 알고 있지만 정상적인 대우를 못받는게 현실인가 봅니다.