/body id =
반응형

우선 QA의 사전적 정의니 의의니 하는 점은 패스하고, 내가 실제 QA 직무를 하면서 느낀 부분을 위주로 작성했다. 참고로 QA경력은 2015년에 시작하여 햇수로는 약 6년차임을 감안해주길 바란다.

 

QA 자격?

엄격히 말하자면 QA는 전문직이 아니기 때문에 특별한 자격이 필요하지 않다. 특정 자격보다는 실제 업무를 하는데 있어서의 성격과 업무를 대하는 태도의 영향이 큰 편. 뭐 물론 공학계열의 컴퓨터공학 전공자라면 업무 프로세스의 대한 이해가 빠를 수는 있을 것 같긴 하지만, 그런 사람이 아니더라도 실제 업무에는 큰 무리가 없다. 만약 덤벙거린다거나 꼼꼼하지 않다거나 급한 성격을 가지고 있다면, QA 직종과는 정말 어울리기 힘들 것.


아마 이런 개인의 성향 및 성격을 무시하고 QA에 직무를 임한다면 당장은 어찌어찌 버텨 볼 수 있어도 장기적으로 봤을 때는 정말 힘들다. 주위에서도 그렇게 퇴사하시는 분들 여럿 봤고. 우선 QA라는 일 자체가 그리 재밌는 일은 아니기에..

 

생각해보면 ‘굳이 대학을 나와야 하나?’ 할 정도로 직무에 있어서 특정 전문성이라든지, 고학력이 필요한 것도 아니다. 물론 특정 소프트웨어 QA는 전문지식(애자일 등)을 가지고 있어야 하지만, 아직까지는 그런 직종이 그렇게 많지는 않은 편이다. 물론 대학 나오면 좋기야 하겠지만, 실제 업무에 있어서 전공 및 학력이 그렇게 중요하지는 않다.

 

단, 현상에 대해 글로 풀어 쓰고, 개발자 및 누가봐도 쉽게 이해할 수 있을 정도로 설명 또는 작성해야 하므로 어느 정도 글을 조리있게 쓸 줄 알아야한다. 예를 들어 중의적인 표현을 자주 사용한다든가, 오류가 발생하는 위치를 정확히 설명하지 못하면 그만큼 유관부서와의 커뮤니케이션이 지체되고 결국 일률의 저하까지 이어지기 때문. 뭐 그렇다고 유명한 작가처럼 화려한 부사나 미사여구를 곁들어 쓸 필요는 없다. 객관적으로 누가 봐도 쉽게 이해할 수 있는 글을 쓰면 된다.


 

그래서 사람인이나 게임잡에 있는 QA 직무 구인광고의 자격요건을 보면 ‘꼼꼼한 사람, ’창의적인 사람’, ‘맡은 임무를 책임질 수 있는 사람’, ‘열정적인 사람’ 등의 애매모호(?)한 인재상만 실려있다. 그만큼 특정 스펙이나 자격요건을 요구하지 않는 것. 실제 업무에서도 어느정도의 융통성만 있다면 업무를 처리하는데 큰 어려움은 없다. 

 

하지만 진입장벽이 낮다는건 반대로 다른 사람들도 쉽게 진입할 수 있다는 말이 된다. 이는 나중에 설명하겠지만, 궁극적으로 QA의 처우와 연관되기도 한다. 요약해보면 'QA 대충 아무나 할 수 있으니 너 나가도 할 사람 많다.' 라는 말로 해석 되기도 한다는 것이다. 물론 정말 능력있는 QA라면 아니겠지만 말이다. 이래서 비전문직은 서러울 뿐이다.


자격증?

가장 많이 받는 질문 중 하나는 ‘ISTQB 필수인가요?’ 인데, 솔직히 도움이 아예 안된다고는 볼 수 없으나, 또 실무에 그렇게 엄청 도움이 되진 않는다. 아무래도 해당 자격증은 실무보다는 이론을 다루기 때문이다. 하지만 취업 또는 이직 시, ‘그래도 없는 것보다는 낫다.’ 라는 인식 때문에 QA를 업(業)으로 삼는다면 취득하는 것도 나쁘지는 않을 듯. 시험비는 십만원 중반이며, 시험 난이도는 낮은 편이다.(커트라인 60점)  보통 한 달 정도 짬내서 공부하면 무난히 합격한다.

 

ISTQB가 국가공인 자격증이라 시험비도 비싸고 일정도 많이 없다보니 테스팅 관련 법인 'STEN'에서 유사ISQTB인 'KSTQB' 자격시험을 만들었다. 국내 전용이다보니 시험비도 더 저렴하고 시험횟수도 더 많다. 토익스피킹이나 오픽처럼 사실 어떤걸 따도 상관없긴 한데 ISTQB가 뭔가 국가공인이라고 하니까 더 선호되고 있긴하다. 


QA 업무?

친구들에게 QA의 업무에 대해 물었을 때 ‘묻고 답하기 상담’, 또는 ‘콜센터’ 라는 대답을 가장 많이 들었다. 취업당시 내 부모님도 그랬고(콜센터 업무인줄 알고 슬퍼하시던 그 표정을 잊을 수 없다.) 이런 오해들은 그만큼 QA라는 직종이 사회적으로 아직도 많이 알려지지 않았기 때문인데, 사실 외국에서는 1900년대 후반부터 꾸준히 이어져 내려오는 직종 중 하나다. 한국에서도 제약, 생산 등에서 QC [quality control] 라는 직종은 오래도록 있어왔지만 비교적 소프트웨어 QA는 종사자 수도 적고 산업규모도 작았던 만큼 인지도도 낮았던 것.  


말이 중간에 좀 샜는데, QA의 업무는 다양하다. 우선 QA ≠ 테스터라는 사실부터 인지하고 있어야 하는데, QA의 업무를 ‘테스트 하는 사람’ 정도로 알고 있는 사람이 많다. 아둔하게도 그건 정말 좁은 의미의 해석이다. 어찌보면 ‘테스트 하는 사람’은 QA보다는 테스터라고 부르는게 맞을 것. 회사입장에서는 굳이 비싼 돈(그렇다고 엄청 많다는건 아니고 테스터 대비) 지불 해가며 QA쓸 일이 없을테니까.


QA는 테스트 외에도 장기적으로 해야하는 업무들이 몇 개 더 있는데 대략적으로 소개하자면 아래의 업무들이다.

① BTS(Bug Tracking System) 관리
② 버그 수정 확인
③ 밸런스 테스트(필요 시)
④업데이트 릴리즈 테스트(버전처리 시)
⑤ 결제 및 청약철회 테스트(해당 서비스 제공 시)
⑥ 유관부서와의 일정 조율 커뮤니케이션(기획 ↔ 사업 ↔ 영업 ↔ 운영 등) 
⑦ 제공중인 서비스의 클라이언트의 유지보수 QA

⑧ 런칭 프로젝트의 경우 출시 여부 최종 판단

⑨접수된 오류 또는 버그에 대한 재현케이스 확보

⑩ 운영중인 서비스, 제품에 대한 잠재적 버그 발견

등이다. 정말 내가 생각나는 것만 당장 적어본거고 실제 업무를 하다보면 안정성 확보 & 고품질화에 기여할 수 있는 것은 거의 다 한다고 보면 된다. 정말 끊임없이 일해도 일이 줄어들지 않는 것처럼 체감 될 정도니까. 

 

조직별로 조금씩 업무가 추가되거나 다를 수는 있지만, 대충 버그 찾는 일 말고도 정말 많은 일을 수행해야한다는 점은 일맥상통하다. 아무튼 단순 테스트 말고도 할게 너무너무 많다는 것. 그리고 일련의 활동은 자사 제품 또는 서비스의 고품질화, 안정화, 개선으로 이어지는 모든 것들을 아우르는 활동이라고 할 수 있다.


QA 비전?

요즘은 QA도 테스트 대상이나 방법에 따라 그 종류가 많이 분화된 상태다. F(Fun)QA, T(Technical)QA, D(date)QA, C(Critical)QA 등 정말 많은 QA가 생겼는데, 아직까지 한국에서 해당 직군을 찾아보기는 정말 힘들다. 그나마 대형 게임사에서 특정 QA를 많이 채용하는 편. 물론 애시당초 QA라는 직군 자체도 없는 회사도 많은 상태다. 이런 경우는 보통 개발 QA, 또는 DQA라고 하여, 개발자가 테스트까지 하게 되는데, 이런 경우 단기간의 버그 확인과 수정까지 홀로 수행하여야 한다. 물론 이슈가 누적될 경우, 일정이 필요한 경우, 재현이 되지 않는 경우 등에는 일정에 차질이 생긴다.


제품, 서비스의 고품질을 목표로 하는 회사 입장에서는 QA를 더욱 강화하려고 하고 있다. 특히 주기적으로 업데이트를 할 수 없는 상태의 경우 출시 이후에 치명적인 버그 또는 오류가 발생했을 경우 전수 리콜까지 해야하는 대규모 참사가 발생할 수 있다. 그 예로 삼성 갤럭시 노트7의 배터리 발화 사고는 수백억원의 적자를 안겨줬다. 

 

업체 입장에서는 QA에 들어가는 돈 아끼려고 (혹은 간과하고) 투자를 아꼈다가 어떻게 보면 더 큰 피해를 입을 수도 있다. 이는 게임, 제약, 생산, 모든 QA 영역에서 마찬가지다. 하지만 반대로 회사 운영이 어려워지면 가장 먼저 해고당하는게 QA직군이기도 하다. 개발자가 많은 부분 커버할 수 있는 영역이기 때문인데, 어차피 이런 경우 서비스의 저품질화로 장기 존속은 불가능하다 


개인적으로 제품 이미지, 고객 충성도의 영향을 많이 받는 대기업 또는 계열사 위주의 기업이 많아질수록 QA시장은 점점 확대될 것으로 보인다. 사용하는 회사 서비스의 품질이 곧 내가 그 회사를 이용하는 하나의 요인으로 작용하기 때문이다.

 

전문적인 QA의 니즈가 많아짐에 따라 요즘은 QA 아웃소싱 업체들도 많아지고 있다. 대기업, 특히 게임사의 경우 QA를 독립하여 구성하거나 아예 자회사로 운영하는 곳도 있다.(ex.넥슨-넥슨네트웍스) 아무튼 향후 비전은 조금 밝아보이긴 하지만, 또 그렇다고 긍정적인 미래를 보고 기대를 하기엔 지금 현실이 너무 냉정하다.


QA 현실?

 

QA의 급여는 타 직무보다 낮은 편이다. QA는 업무 특성상 개발자와 같이 근무하는 경우가 많은데 개발팀과 사업팀, 기획팀, 서버팀, 디자인팀, QA 비교를 했을 때, QA는 그 중에서 가장 낮은 티어에 속한다. 부정하고 싶지만 아마 QA가 있는 회사는 이런 연봉 테이블을 가지고 있을 것이다. 앞에 언급한 특정 전문성이 필요없기 때문에 누구나 쉽게 진입할 수 있다는 이유가 가장 크다. 그래서 나중에는 많은 사람들이 기획팀이나 컨텐츠제작팀으로 이동하기도 한다. 어찌보면 기획이나 QA나 제공중인 상품 또는 서비스를 빠삭하게 잘 알아야한다는 점은 공통점이므로.

 

실제로 중소기업 이하, 소규모 단위의 개발사는 QA가 아예 없는 곳들도 많은데 QA가 할 일을 이미 다른 사람들이 조금씩 나눠 하거나 자체 QA를 하기 때문. 작은 규모라면 이런 주먹구구식의 QA가 단기간동안 가능하기도 하다.


금전적인 얘기를 했으니 이제 업계에서의 대우(treatment)를 알아보도록 하자. 우선 QA라고 무시하거나 깔보는 사람들은 거의 찾아보기 힘들다. 단지 '버그 잡는 팀'으로 비춰질 뿐이다. 그들도 QA팀이 있어야 안정성 높은 컨텐츠나 상품을 소비자에게 전달 또는 제공할 수 있다는걸 알고 있기 때문에 실제 업무를 하다보면 다는 아니지만 많은 사람들이 QA 업무를 이해하고 도와주려고 한다. (물론 개발자와 QA간에는 많은 상극이 존재한다.)

 

개발자와 QA는 갈등이 많은 편이다. 갈등이라니 조금 공격적이긴 한데, 아무래도 안정성을 중심하는 QA와 무(無)에서 유(有)를 창조해야하는 개발자 간의 이해관계가 상충되는 느낌이랄까. 그리고 생각보다 개발자 중에는 제공중인 컨텐츠를 정확히 이해하지 못하는 개발자도 많기 때문에 무조건 자기 말이 맞다고 우기는 개발자들도 가끔 있다. 이럴 때는 기획자까지 소환하여 '이 동작이 맞게 동작하고 있느냐' 등의 확인 작업도 거쳐야 하고.


많은 QA들이 하는 말 중 하나는 '우리는 '을'이다' 라는 말인데, 실제로 QA 업무를 하다보면 이 말이 어떤 일인지 몸소 이해가 된다. 개인적으로 개발자는 QA를 할 수 있지만, QA는 개발을 할 수 없기 때문에 이런 자기비하적 해석이 나온 것 같은데, 실제로 게임회사에 근무했을 때 정말 갑(甲)처럼 행세하는 개발자들이 많았다. 심지어 오류를 찾아도 수정해야 할 영향도가 크면 QA의 의견을 묵살한 채 진행하기도 한다. 내가 기껏 찾은 오류가 영향도가 낮다며 그냥 넘어가버리는 일도 비일비재하다는 것인데, 기획자가 '기획된 의도'라고 말하며 얼렁뚱땅 넘어갈 때마다 정말 이 일을 왜 하는지 의문이 생길 때도 많다. 뭐 수정하기 번거롭겠지만 이런식으로 계속 무시할거면 왜 나를 QA로 채용했지. 

 

물론 그렇게 떼 부리며 수정해주지 않고 무리해서 진행했다가 실제 운영에서 버그 발생하면 그것도 다 QA책임. 


끝맺음.

개인적으로 QA직무를 시작하려는 사람들을 보면 마음 단단히 먹고 시작하라는 말을 건내주고 싶다. 특정 전문성이 없다보니 아무나 다 할 수 있을 것 같은 일 같지만 막상 실제로 업무를 하다보면 그렇게 호락호락하지 않은 일이라는걸 몸소 느낄 수 있다.

 

무엇보다 QA든 QC든 가장 마지막에 확인 또는 검수를 하는 직무다 보니 오류/버그 발생 시, 업무에 대한 책임을 몸소 져야한다는 점, 또한 근무 시 굉장히 스트레스가 되는 부분이다. 정말 완벽하게 테스트했다고 하더라도, 테스트 환경 및 구조, 알고리즘 등에 의해서 버그는 어쩔 수 없이 발생되기 때문에 결국 욕 먹을 수 밖에 없는 직무이기도 하고.

 

그렇다고 '쉽게 들어올 수 있는 낮은 채용장벽' 때문에 연봉이 높지도 않다. 이런 고질적인(?) 문제 때문에 'STEN' 등에서 나서서 QA의 고품질 및 전문화 교육 역시 끊임없이 이루어지고 있는데 아직까지는 먼 미래의 이야기 같다. QA의 인식도 개선되어야하지만 무엇보다 '아무나 할 수 있다'라는 사회 구성원들의 마인드가 우선적으로 바껴야 할듯.


아무튼 본인 직업 쉽다고 말하는 사람 없지만 6년 정도 일한 나에게 QA는 일 많고, 이것저것 모두 알아야하고, 책임져야 할 일 많고, 무엇보다 박봉인 직업이다. 실상 사업팀처럼 매출로 보여줄 수도 없는 팀이라 성과 인정받기도 힘들고. 그나마 야근 없이 집에 일찍 갈 수 있다는게 낙이라면 낙이다. 아무튼 QA 할 생각 있으면 다시 한 번 깊은 고심을 해보자.

 

배운게 도둑질 뿐이라 이 일 계속 하고 있지만 애초부터 다른 도둑질을 좀 배워봤으면 어땠을까..

 

반응형