최근 수정 시각 : 2024-11-04 02:16:48

QA


파일:나무위키+유도.png  
은(는) 여기로 연결됩니다.
묻고 답하기에 대한 내용은 Q&A 문서
번 문단을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
참고하십시오.

1. 품질보증2. 소프트웨어 QA
2.1. QA에 지원하기 위해서2.2. 현실2.3. 결국은 해야 하는 일2.4. 관련 문서
3. HBO 드라마 웨스트월드에 등장하는 조직

[clearfix]

1. 품질보증

파일:상세 내용 아이콘.svg   자세한 내용은 품질관리(직무) 문서
3.2번 문단을
부분을
참고하십시오.
품질보증을 뜻하는 Quality Assurance의 약어.

국내에 화공 플랜트계에서 최초로 1980년대 도입되었다. 1980년대 전에는 QC(품질관리)였으며 현대에는 QM으로 품질경영 역사가 발전되고 있다. QA의 본질적인 어원은 과거 영국의 로이드에서 어원이 파생됐으며 현재도 LRQA(로이드인증원)이라는 조직으로 활동하고 있다. 품질관리(QC)와는 다르며 QC는 시야가 작은 범위을 검증한다면 QA는 보다 넓은 범위를 검증한다. 즉 리스크를 예방한다는 것.

일반적으로 제조업에서 '품질 직무에 종사하고 있다'고 하면 십중팔구는 이 QA직무를 말한다. 고객사 컴플레인, ISO9001, IATF16949, SQ 인증 관련 서류작업 관련 업무를 처리하며, 보통 중소기업의 경우 QC직무(측정, 검사성적서 작성업무 등 현장업무)를 몇년간 수행한 인원이 승진하여 맡는 구조를 가지고 있다.

플랜트, 석유화학, 정제산업, 제약, IT, 게임업계에서 주로 사용하는 명칭이라 명칭 자체를 생소하게 받아들이는 경우도 있으며 Q&A와 혼동되기도 한다.[1]

2. 소프트웨어 QA

소프트웨어 QA는 모든 소프트웨어 엔지니어링 프로세스, 개발, 작업 활동 등의 항목을 검수하며 조직 내 품질 규격, 소위 소프트웨어 요구사항 명세[2]를 준수하도록 하는 프로세스이다. 그리고 그러한 프로세스에 따라 품질을 보증 하는 인력을 QA라고 부른다. 소프트웨어 서비스 불량 및 릴리즈 지연은 회사에 막대한 피해를 초래하기에 예산 범위 내에서 QA 인력이 유지되는 것이 중요하다. 국내에선 흔히 해보고 잘 돌아가는지 아닌지 정도만 보는 단순 테스터와 비슷한 의미로 여기는 경향이 없진 않지만 QA는 소프트웨어 엔지니어 중 하나의 직군으로 포함된다.

QA는 프로젝트의 품질에 문제가 될 수 있는 모든 부분을 종합적으로 고려한다. 업무 범위가 테스터에 비해 넓고 필요한 능력도 다양하다. QA는 기본적으로 요구사항 명세를 분석하여 테스트 케이스화 하며 테스트 계획을 만들고 테스트를 진행하며 팀이나 실의 전반적인 품질 개선을 위해 다양한 의견을 낸다. 테스트는 목적에 따라 자동화된 테스트를 진행할 수도 있으며 품질 향상을 위한 프로세스를 개선하거나 개발하며 정적 분석을 통해 사전에 여러가지 결함을 개선할 수 있도록 개발자들을 백업하기도 한다. 최종적으로는 품질을 매니징하며 요구사항 명세 준수를 위한 활동이나 표준을 결정하게 된다. 예를 들어서 릴리즈를 위한 어떠한 정책이 있다면 그 정책들이 모두 포함되고 동작하는지를 검증해야 하며 표준 미달일 경우 개발을 요구해야 한다.

좀 더 구체적으로 예시를 들자면, QA는 실제 소비자가 이 소프트웨어를 사용했을 경우까지 고려한다. 만약 특정 서비스에서 새로운 기능이 추가되거나 개편을 한다면 그게 요구사항 명세대로 온전히 돌아가는지만 보증하는 것이 아니라 요구사항 명세의 허점과 결함을 사전에 발견할 수도 있으며, 이러한 개편이 실질적으로 올바른 개편인지, 유저들에게 부정적 경험을 선사하지는 않는 지 패턴의 유불리와 소위 억까 패턴을 만들지는 않는 지 까지 종합적으로 판단하여 개선점을 제시한다. 소프트웨어 QA는 소프트웨어 개발 특유의 팀웍에 의해 요구되는 직군으로 조직 내 유일한 소프트웨어 QA가 아닐 수도 있으며, 항상 다른 프로그래머 및 기획자, 다른 유관부서의 구성원과 함께 작업하게 된다. QA는 명세 및 고객과 서비스에 대한 높은 이해도를 바탕으로 하면서도 개발자에게는 객관적인 시선을 가지기도 하며, 또한 그들의 개발 산출물 및 요구나 목표등을 이해하고 감사하며 조직 내 소프트웨어의 문제점[3]과 필요한 해결책을 제시, 설명하는 것이다.

당연하겠지만 이를 머릿속으로 대충 생각하여 그렇게 될 것이라고 그려내는 것으로 끝나는 게 아니다. QA는 이를 실질적으로 문서화된 결과물이나 최소한 태스크를 생성해놓고 일련의 과정을 개발자, 유관부서 구성원와 논의 후 진행할 필요가 있다. 예를 들어 위에서 말한 기능 개편 내용을 실질적으로 테스트해보려면 어떻게 랜덤 테스트, 유저 테스트를 진행해야 하는지, 상용 애플리케이션이라면 주 이용 연령대는 어떻게 되는지에 따라 다양한 연령대를 기준으로 올바른 테스트 방식을 설계하고, 실제 유저들의 사용 경험을 최대한 비슷하게 재현할 필요가 있다.

그리고 이를 신속하게 진행해야 한다. 소프트웨어 개발 및 배포 프로세스에서 초기부터 QA가 참여하더라도 릴리즈 막바지에 반드시 최종 QA가 진행되어야 하기 때문에 시간에 항상 쫓기게 마련이다. 처음 프로세스가 잡힐 때에는 QA에도 당연히 넉넉한 시간을 배분해주지만, 업무라는 것이 늘 그렇듯 이런 저런 이유로 지연되기 마련이며 QA에게 약속했던 시간이 온전하게 할당되는 경우는 매우 드물다. 항상 부족한 시간에 주어진 작업을 마무리하여 지연되지 않도록 백업해야 하기 때문에 신속과 정확함이 생명이다.

항상 거론되는 점은 테스트는 누구나 할 수 있으나 누구나 잘할 수는 없다는 점이다. 뭉뚱그려 QA라고 말했지만 개발에도 각각의 직군이 존재하듯이, QA에도 전문적으로 나아가면 분야에 따른 직군이 존재하기 마련이다. 무언가에 대한 품질을 보증한다는건 그만큼 그 분야에 대해 알고 있어야하기 때문에 모든걸 다 잘해내는 QA라는건 찾아보기 어려운 존재다. QA, 소프트웨어 엔지니어를 확장하여 SDET(Software Development Engineer in Test)라는 개념으로 점점 더 확장되고 있다. 단순 테스터만 해도 그에 대한 전문성을 가지기 위해 몇 년을 노력해야 겨우 가닥이 잡히는 데 업무를 확장하면 확장할 수록 더 복잡해지는 그런 직군인 것이다. 물론 그렇다고 어느 한 분야만 전담하진 않고 다 해먹거나 2년 이내에 직군을 포기한다.

때문에 QA는 정말 많은 걸 알아야 한다. 무엇을 테스트하냐에 따라 자신이 알아야 할 것들이 판이하게 달라지는데다[4][5] 기획자가 얼토당토 않는 허점 투성이인 기획을 던져주는 것에 반박하려면 그에 상응하는 지식이 있어야 하니까 말이다. 그래서 QA 입장에선 ' 키약믿'이나 ' 민수 이벤트' 같은 듣도보도 못한 기획이 튀어나오면 심히 골룸해지기도 한다.[6]

2.1. QA에 지원하기 위해서

말은 QA라고 했지만 시작은 보통 테스터, 인스펙터에서 시작하기 마련이다. QA가 되기 위해 소프트웨어 공학을 전공하고 개발 지식과 테스팅 이론을 숙지하고 있어야 하는 것이 일반적이지만 대부분은 테스터에서 시작해서 테스터로 끝나는 운명이며 업계에서도 단순 테스터를 요구하는 경우가 많기 때문에 업계 진출을 위해 별도로 준비해야 하는 것은 없다. 이 말은 허들이 매우 낮은 편이라는 말이다. 따라서 고졸에 별도로 특별히 할 줄 아는 것이 없다고 하더라도 테스터로서의 취직은 매우 쉽다.[7] 테스터로 취직해도 비정규직은 논외로 치고 일단은 QA라고 불리기 때문이다. 그래서 대량의 인력들이 유입되며 짧으면 수개월 내에 퇴사를 반복한다. 업계에 계속 남아있는 경우는 드문데 실력자들이라고 보면 된다.

QA는 품질에 문제가 있다는 것을 알려 상대가 그걸 납득할 수 있게 해야 하는데 어떤 현상에 대해 구체적이고 논리적으로 설명할 수 있어야 한다.[8] 이런 사고방식을 가지지 못할 경우에는 설령 낮은 허들로 입사하게 된다 해도 좀 더 상위 업무를 하거나 더 나은 기업으로 이직하기는 불가능에 가깝다. 테스트를 밑바닥에 깔고가는 만큼 테스트를 얼마나 효과적이면서도 효율적으로 할 수 있는가, 어떻게 하면 프로젝트 품질을 향상시킬 수 있는가에 대한 고민을 늘 해야 한다. 하지만 비정규직 형태로 무방비로 유입되는 인력들에게 이런 많은 걸 기대하긴 현실적으로 어려운 만큼 대기업을 제외하면 테스트에 대한 개념, 업무에 대한 의욕 등 전문성보다는 성실함이나 끈기와 같은, 취직에 있어서 너무나 기본적인 면을 좀 더 보는 편이다.[9] 테스트 관련 자격증은 가산점 정도로 취급할 뿐 입사에 필수적인 건 아니기 때문에 너무 연연할 필요는 없다.

다만 허들이 낮다는 이유로 QA로 지원하지만 인력 중 대부분은 5년 이내에 본인 역량에 한계를 느끼고 중도 포기하는 경우가 많다. 다른 IT분야보다 입문은 쉬워보일지 몰라도 살아남아서 성장하는 게 상당히 어렵다.[10] 꾸준히 자기 계발하여 비정규직으로 시작해도 정규직으로 전환되기도 한다. 물론 업계 현실 상 아주 어렵지만 불가능은 아니다. 앞서 말했지만 테스터로 연차만 쌓다가 포기하는 경우가 대부분이며 개발을 공부한다거나 소프트웨어 공학을 공부한다거나 하는 인력 자체도 매우 적다. 따라서 어떤 기업이냐, 어떤 기술 스택을 가지느냐에 따라 QA의 연봉은 2천만원대부터 억대 이상까지 천차만별이다.

2.1.1. ISTQB

파일:상세 내용 아이콘.svg   자세한 내용은 ISTQB 문서
번 문단을
부분을
참고하십시오.

2.2. 현실

국내에서 QA는 비전은 있지만 전문적으로 발전하려면 개발자 만큼의 노력을 기울여야 하는데 그렇게 하려는 인력이 너무 적은데다가 일단 당면한 환경과 현실이 좋지 않아 쉽사리 성장하기 힘들다. 그냥 허들이 낮고 쉬울 것 같다고 착각하고 덜컥 지원하지 말고 후회하기 싫으면 정말 진지하게 고민해보고 진로를 결정하길 바란다.

소프트웨어 테스팅은 사실 아무나 할 수 있지만, 잘 하려고 하면 개발 만큼이나 골 때리고 어려운 일이다. 테스터 라고 평가 절하하는 사람들도 있지만 테스트는 생각처럼 쉬운 일이 아니다. 모바일 환경이 도래하면서 작고 큰 품질 이슈가 회사를 망하게 하거나 이미지에 상당한 타격을 주는 케이스도 많이 발생하면서, 최근 5년내 그 허들이 점점 높아지고 있는 추세고 이전과 달리 신입 채용시 채용 조건에 서비스에 대한 높은 이해도, 각종 프로그래밍 언어에 대한 이해, 개발 경험을 거는 게 기본이다. 하지만 요구하는 역량은 높아졌지만 대우는 그만큼 높아지지 않았다는게 현직 QA들의 공통된 의견이긴 하다. 극단적으로 조금만 더 역량을 쌓으면 동급의 경력에서 연봉 테이블 자체가 달라지는 프로그래머를 하는 것이 더 낫기 때문이다. 사실상 준 프로그래머급의 역량까지 요구하지만, 대우는 예전 그대로 수준인게 전현직 QA 업무 종사자 및 QA 지망생들의 공통적인 의견이다.

일부를 제외[11]하면 신입으로 들어가는 건 보통 계약직, 파견직 형태를 띤 비정규직인 경우가 많다. 당연히 이런 루트로 입사하는 신입들에 대해 회사의 대우도 그렇게 좋지는 않다. 파견직 > 계약직 > 정규직 테크트리를 거치는 QA 선임들이 상당히 많다. 그리고 비정규직 중 대부분은 정규직을 못 달고 이직을 밥먹듯이 하다가 결국 업계를 떠난다. 상당수의 대형 회사들은 정규직이나 계약직(!)의 선임 및 대리 이상의 직급 한 명 아래에 다수의 계약직이나 파견직, 혹은 아르바이트 QA를 거느리는 형태를 지니고 있다. 그때문에 다른 분야보다 비정규직의 비중이 압도적으로 높은 편, 덕분에 단기간 이직률도 상당히 높다. 이직률이 높아서 요즘은 거의 불가능하지만 옛날에는 기획자 전직하는 경우도 있었다. 이 경우에는 타 분야로 전직하는 만큼, 이전 경력이 덜 인정받거나 신입급으로 새로 시작해야 한다는 불이익은 감수해야 한다. 경력을 인정받으려면 보통 개발팀 내의 QA 파트에 한해서 이런 전직의 기회가 있고, 개발팀 이외에 소속된 QA에게는 요원한 일이다. QA가 타 분야에 비해서 신입으로 진입 장벽이 비교적 낮다는 점을 이용해서, 처음부터 기획쪽으로 전직을 고려하고 QA에 지원하는 케이스도 제법 있다. 프로그래머중에서도 QA로 근무하다가 다시 프로그래머로 복직(?)하는 케이스도 있다. 상당히 귀한 고급 인력인데, 이런 인력은 QA에서 소스를 직접 보고 분석까지 가능한 화이트박스 테스트가 가능하기 때문이다. 국내에서도 이 정도의 역량을 지닌 QA 인력은 상당히 드물다고 한다.

그렇다고 선임급 이상의 QA들의 대우가 좋냐면 다른 직군 대비 썩 좋진 않다. 일부 선진적인 기업들의 경우에는 프로젝트 개발 초, 중반부터 QA가 투입되고 매일 품질 개선을 진행하지만 그렇지 않은 대다수의 기업들의 경우 QA는 프로젝트 일정에서 서비스 직전의 가장 끝에 자리잡는다.[12] 아니면 애초에 회사에 내부 QA팀 자체가 없다. 회사에 따라 다르지만 야근을 상당히 많이 하게 된다. 각 파트의 일정이 하나라도 밀린다면, 전체적인 일정이 늘어나지 않는 이상 보통 업무의 가장 끝에 투입되는 QA는 필연적으로 일정 부족에 시달리고 야근을 할 수밖에 없다. 대중적으로 인지도가 낮아서 그렇지 IT 업계에서는 업무 강도로만 보면 3D업종의 불가촉천민급.

해외와는 다르게 국내에서는 QA가 타 부서에 비해서 개발과정에 대한 영향력을 비롯해서 연봉이나 성과급등도 많이 약한 편이다. 그래서 구조조정 시 구조조정 1순위에 뽑히는 경우가 적지 않다. 경영자 입장에서는, 프로그래머가 없으면 개발 자체가 중단되지만, QA의 존재 이유인 품질 검수와 테스팅은 당장 없어도 개발이 진행 가능하며, 그런 하찮은 일은 개발자들이 각자 자기 업무에 충실하면 발생하지 않는다고 생각하기 마련이다. 모든 개발팀들의 실수를 찾아내서 일러바치고, 수시로 팀 업무에 끼어들어서 잔소리나 늘어놓으며, 심심하면 일정을 잡아늘리고 개발일정을 스톱시키는 것으로 인식되는 QA팀은 경영진을 포함한 회사 내의 거의 모든 다른 팀에게 적으로 인식되어 어느정도 규모를 갖추면서 정치질이 정착된 회사에서는 정치적 입지도 심각하게 좋지 않은 경우가 많다. 그럼에도 불구하고 QA가 필요없다고 단언하여 말하는 것은 또 아니라서 문제다. 왜냐하면 QA가 없는 경우 위태로운 라이브 서비스를 진행할 수밖에 없기 때문이다.

IT가 메인이 아닌 업종에서 QA는 더더욱 비참하다. 애초에 QA가 IT 업계에서 밑바닥인 만큼, 업종의 규모와는 무관한 격무에 시달리게 된다. 의외로 규모가 있는 회사도 전문 QA 조직이나 인원 없이, 업무가 필요할 때 마다 단기직이나 아르바이트를 고용해서 사용하는 정도. 그나마 QA에 대한 인식이 조금 좋아져서 뒤늦게나마 정규직으로 QA 인원을 뽑으려는 움직임을 보이고 있다. 아르바이트로 대충 땜빵치듯 했다가 심각한 버그가 발생해 기업에 타격을 주는 사례가 많이 발생하기 때문이다. 버그로 말아먹은 프로젝트는 무진장 많다.

소프트웨어 QA를 단순한 블랙박스 테스터 정도로 평가하는 중소기업의 악순환의 첫 고리는 QA능력이다. 빠른 개발과 빈약한 검증으로 출시된 게임이나 제품은 더 많은 문제가 발생된다. 여기서부터 개발자와 QA팀의 악순환이 시작된다.

2.3. 결국은 해야 하는 일

위에서 여러가지 좋지 않은 내용이 대부분이지만 QA는 반드시 필요하다. 결론만 말하자면 QA를 거치지 않고 서비스를 하는 것은 리스크가 매우 높다. 애초에 자체 QA 인력을 가지지 못한 회사들은 대규모 프로젝트를 추진할 수가 없다. 품질은 돈과 관련된 일[13]이기 때문에 상용화 서비스는 반드시 QA 과정을 거친다. 따라서 제조나 제약뿐 아니라 최근 게임이나 소프트웨어 업계에서도 전문성을 인정하고 QA를 채용하려는 움직임을 보이고 있고, 현업인들도 티격태격 하기는 해도 자기 본연의 업무에 집중할 수 있는 만큼 QA의 필요성을 인정하고 있다.

문제는 필요성과는 별개로 QA에 대한 대우와 현실이 업계 및 회사마다 다르다. 제약 등 일부 업계 경영진들은 QA의 중요성을 이해하고 있어서 그런 회사라면 나름 챙겨주는 반면[14] 소프트웨어 QA는 이전까지 프로그래머 기획자 운영자 등에서 QA를 부수적으로 담당하는 형태를 보였는데 아직도 별도의 QA 프로세스를 갖추지 못하거나 전문적인 QA 회사에게 외주를 줄 형편이 안되는 소규모 회사는 여전히 개발팀 전원이 QA를 흉내내듯 땜빵 한다.

게임 업계에서는 주로 기획자가 땜빵을 도맡게 되는데 당연히 일정이 밀린다. 프로그래머가 도맡을 경우 개발에 집중할 수 없으니 개발이 지연되며 QA 스킬이 부족하다보니 결론적으로 그런 식의 프로세스로는 품질 보증이 제대로 이루어질 가능성이 없다. 단적으로 소규모 개발 회사의 소프트웨어에서 이슈가 많거나 빠르게 수정되지 않는 이유가 그 때문이다. 이와 관련된 내용은 게임회사 여직원들 77화를 참고. QA 조직이 존재 할 경우 각 직군 업무에만 집중할 수 있게 되고 품질 보증이 고속으로 진행된다. 그래서 QA 조직을 갖추기 힘든 회사는 QA만을 전문으로 하는 아웃소싱 업체가 흥하고 있는 추세다. 대형 게임사들의 경우 자회사를 두고 QA를 담당하게 하기도 한다. 아웃소싱의 경우에는 모바일 시장의 성장으로 스타트업을 하는 중소기업이 늘어났고 이로 인해 품질관리에 대한 수요가 급격히 늘어났지만 자체 QA팀을 굴리기는 경영상 어려운 경우가 많기 때문이고 자회사로 분리시키는 이유는 품질에 대한 객관성 확보, 비용 절감 목적이 있다.

게임 업계 기준 대표적인 외주업체로는 핸디커뮤니케이션즈[15], IGS[16], 엔글[17] 큐로드[18], 오르고소프트[19], 광주 G&C센터[20]가 있다. 게임 QA 외주업체뿐만 아니라, 소프트웨어 QA 전반부를 다루는 외주업체도 상당히 많다. 대표적으로 와이즈와이어즈, 테스트웍스, 티벨 등이 있다. 이쪽이 전반적으로는 게임 업계 QA보다는 연봉이 높지만 일부 대형 게임사 자체 QA들은 처우가 많이 개선되고 있어서 이것도 역시나 회사마다 다르다. 물론 대형 게임사들은 QA여도 들어가기 어렵지만.

일부 경력직 QA를 구하는 곳에서는 아웃소싱 업체의 경력을 원하지 않는 곳도 있기에, QA쪽으로 커리어를 유지하기 위해서는 아웃소싱 업체에만 있으면 안된다는 이야기도 있다. 그도 그럴것이 아웃소싱 업체에서는 배우는 것도 없고 그냥 단순 반복 작업만 하다가 계약 기간이 만료되기 때문이다. 아웃소싱에 쉽게 들어갈 수 있는 이유가 다 있다. 그래서 어느정도 커리어가 쌓이면 자회사 QA로 넘어가는 인원이 있는가 하면, 은퇴할 때까지 아웃소싱 QA 업체에 남는 인원도 있다. 혹은 자회사 QA에서 아웃소싱 QA로 넘어가는 인원도 있다.

사이버펑크 2077(출시 초중기 한정), 트리 오브 세이비어에서 품질 보증이 안 지켜질 경우 어떤 참사가 벌어지는지 제대로 보여주었다. 창작물이지만 게임회사 여직원들에선 QA를 제대로 안해서 고생해서 만든 게임이 제대로 빛을 못 보고 회사가 망하는 일까지 벌어질 정도다. 사실 저 두가지 케이스의 경우에는 QA가 수많은 버그를 리포트했으나 높으신 분들의 사정으로 인해 수정이 되지 않은 상태로 출시한 경우다. 아무리 QA가 있다고 한들 경영주나 리더단에서 찍어 누르면 출시를 강행할 수밖에 없을 것이다.

소프트웨어 QA의 중요성이 높아진 지 10년 이상이 지났지만 아직까지도 종사자 대부분은 계약직 테스터로서, 누군가 만들어 준 프로세스 및 체크리스트 혹은 테스트 케이스에 따라 되는지 안되는지 체크하는 누구나 할 수 있는 간단한 블랙박스 테스트만 진행할 수 있는 인력이 대다수다. 스스로 QA 범위를 결정하고 사업, 기획, 개발과 논의하여 계획을 수립하고 다양한 기법을 통해 일정 내 효율적으로 수행해내는 인력은 비교적 적다는 말이다. 그렇게 할 수 있는 환경이 주어지는 기업도 많지 않다. 파견직, 계약직 등 비정규직으로 아웃소싱을 통해 고졸, 비전공자 포함, 매우 낮은 진입장벽으로 입사하고 대다수가 2~3년 이내로 중도 포기하고 퇴사하기 때문에 해외 시장과 달리 극히 일부 인력을 제외하고 업계 전반적으로 실력이 매우 낮다. 즉 전문성을 가진 인력과 그렇지 않은 인력의 격차가 아주 크다. 또한 일반적인 중소기업의 QA팀장도 기반 지식이 매우 희박하고 팀원을 효율적으로 관리하며 전문 QA엔지니어로 키워나갈 수 없는게 현실이다. 무엇보다 이들도 쓸 수 있는 인력이라곤 알바나 인턴이 다고, 이런 인력들을 전문 QA로 육성하기에는 짧은 기간에다가 본인들이 QA를 직업으로 생각하지 않는 경우가 대부분이라...

그런데 문제는 국내 소프트웨어 QA에서 화이트박스 테스트까지 활용하는 업체가 역시나 정말 적다. 마냥 역량 문제로 치부하기도 어려운 업계 환경도 있다. 과중한 업무를 비롯해서, QA 프로세스가 잘 잡히고 프로젝트에 효과적으로 적용할 수 있는 일부 대기업을 제외하면 아웃소싱이나 계약직 등 비정규직만 채용하고 직원 성장을 도외시하면서 쓰다가 버리는 양상이 대부분이라서, 전문적인 QA 인원이 생기고 그 전문적 QA들이 다시 신입을 교육하는 순환은 요원하다고 보는 주장도 만만치않다. 위기의 게임QA '돌파구는…' <上>전문성 인정하는 업계 풍토 '시급'

2.4. 관련 문서

3. HBO 드라마 웨스트월드에 등장하는 조직

파일:상세 내용 아이콘.svg   자세한 내용은 웨스트월드 경비대 문서
번 문단을
부분을
참고하십시오.


[1] 당장 이 문서만 해도 소프트웨어와 게임QA 위주의 문서이니 설명과 현장 상황이 다를 수 있다. [2] Software Requirement Specification, 소프트웨어 명세란 모든 소프트웨어의 시스템에 의한 입력 및 출력을 포함하여 모든 처리가 묶인 기능 단위, 소프트웨어의 성능 등의 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물(주로 문서)이다. 현업에서는 제안서 또는 기획서라고 부른다. [3] 주로 디자인 및 소프트웨어 기능상의 버그, 개선점이 대부분이다. [4] 소프트웨어도 게임, 미디어, 보안 등 다양하게 존재하고, 게임 내에서도 PC, 모바일, 콘솔 등의 플랫폼 분류와 RPG, 리듬게임, CCG 등 장르별로 분류가 많은만큼 그에 대해 알 수 있는 지식폭이 필요하다. [5] 여기서는 게임 QA가 중심적으로 거론되지만 인공지능이나, 임베디드 시스템, 텔레메틱스나 IOT 같은 분야에도 당연히 QA는 필요하고 각자 알아야 하는 부분도 차이가 나게 된다. [6] 그렇다고 이게 되는 거냐고 물어볼 수도 없는 것이 대부분 기획자가 고객인 경우가 많으므로 최대한 버그를 많이 잡는 수밖에 없다. [7] 물론 대형 업체에 취직하는 것은 다른 직군과 마찬가지로 쉽지는 않다. 다만 다른 직군 대비 허들이 낮은 편에 속한다. 다만 계약직이 아닌 공채 정규직이라면 확실히 어렵다. [8] 물론 설명이란 행위는 누구나가 다 할 수 있지만 잘 설명하는 것은 다른 문제다. 글만으로는 설명이 어려우니 사용 내역을 추적할 수 있는 로그나 재현 사진 및 영상 첨부는 기본이다. 중요한 점은 어떤 액션을 했을 때 이런 결과가 나오는 지를 정확하게 알고 있어야 한다는 것이다. [9] 이직률이 너무 높다는 점도 이런걸 중점으로 보게 하는 이유가 된다. [10] 왜냐하면 연차는 쌓이는데 할 줄 아는 것이 없기 때문이다. 비전공자로 입사해서 살아남고 싶다면 정보처리기사, ISTQB, 영어(대기업입사기준레벨)는 3년차 되기 전까지 필수라 생각하고 따두자. 그래야 기본적인 지식이라도 가지고 있다고 생각이 든다. 사실 QA 업계도 허들이 점점 높아지고 있어서 대기업 신입 공채는 저 정도는 기본으로 가지고 시작한다. 대기업이 아닌 중견 QA 기업이라도 최소한 ISTQB 정도는 획득하는 것은 기본이며, 이건 신입뿐만 아니라 현직에서도 기본 중에 기본이라고 보기 때문이다. [11] 대형 IT회사의 공채. 중소형 회사에서 선임을 낀 형태. 이때는 보통 일정 기간의 수습(신입)을 거친 다음에, 대개 정직원으로 시작한다. [12] 원칙적으로 품질관리는 개발 프로세스 전 과정에 있어야 하나, 국내 실정은 말단에 달려 있다는게 QA에 대한 그릇된 인식을 단적으로 보여준다. [13] 결함 하나 터졌다가는 회사가 휘청거리는 사태를 맞이할 수 있다. [14] 제약 및 의료기기 쪽은 회사 내 전담 QA가 지정이 되어있지 않으면 아무리 사소하고 간단해 보이는 제품도 허가를 받는 것이 불가능하다. 식약처에서 국내 판매 허가를 받으려면 회사가 GMP 등 제조시설 인증을 반드시 받아야 하는데 이 인증을 받고 매년 심사를 통해 유지하는 과정에서 QA가 반드시 있어야 하기 때문. 이쪽 경영진은 QA의 중요성을 정말 제대로 이해한다기 보다는 S/W 업계보다 훨씬 엄격한 규정 때문에 제품을 만들어 팔고 싶으면 울며 겨자먹기로 자격을 갖춘 사람을 뽑는 것. 물론 연구개발, 제조 쪽에는 절차대로 작업했는지 간섭하고 문서 제대로 만들라고 잔소리 하며, 하루 빨리 제품을 내놓고 싶은 경영진에게 일정을 미루라고 어깃장 놓는 것은 것은 QA의 숙명이나 마찬가지인 업무라서 공공의 적 취급받는 것은 비슷한 위치이며, 비슷하게 잔소리꾼 담당이 될 수밖에 없는 RA와 긴밀한 협력관계에 있는 자리이다. [15] 과거에는 회사명이 핸디게임이었으나 현재 정식 법인명은 핸디커뮤니케이션즈이다. 홈페이지는 핸디(https://www.handy.co.kr/)로 되어 있다. 직원이 60명 이상으로 소기업이지만 QA, QC, FGT 등 게임의 전반적인 QA 관련 업무를 하며 최근에 게임 자체개발, 게임 운영사업, 게임 퍼블리싱 사업까지 전반적인 게임일을 하고 있어 게임업에 대한 이해도가 매우 높아 전문성에 대한 평판이 좋은 편이다 [16] 700명 이상이 근무하는 대형업체로 과거 서울 구로디지탈단지 넷마블 바로 옆에 위치하고 있었으며, 현재 영등포 타임스퀘어 옆으로 이동하였다. 여러가지 게임을 담당하지만 의외로 넷마블의 자회사라고 한다. 그러나 넷마블 게임만 담당하지는 않는다.현재는 외부회사 대상 사업을 접고 넷마블 게임만 담당한다. [17] 카카오 자회사로 카카오 서비스 외, 게임, 플랫폼, 블럭체인 등 다양한 라인업으로 품질을 지원하고, 최근 중국에도 법인을 두고 글로벌하게 진출하고 있다고 한다. [18] 서울 여의도에 위치하고 있으며 게임 운영 및 QA전문 업체로 400명 이상의 직원을 두고 있으며 23년 12월 기준 매출 265억으로 게임QA 및 서비스운영 대행 회사 중 가장 규모가 크다. [19] 경기도 안양에 위치하고 있으며 넥스트플로어 외에 다른 회사에서 나온 게임QA를 담당했다.24년 기준 홈페이지 접속불가로 폐업한 것으로 보인다. 디지털하츠 서울로 회사명을 변경하여 현재까지도 QA관련 작업을 진행하고 있다. [20] 와이디온라인 광주지사, 24년 기준 폐업한 것으로 추측된다.