우선 글을 시작하기 전에 QA와 QC를 혼용하거나 잘못 사용하는 사람들이 있어서 그 점을 확실히 짚고 가고 싶다. 본인이 QA 혹은 QC 직무를 한다면. 혹은 하고 싶다면 두 단어의 차이점은 확실히 알고 있는게 좋다. 물론 QA와 QC 각각의 사전적 의미도 중요하겠만 현업에서 직접 체감한 것을 바탕으로 작성했다.
- QA와 QC의 차이점?
보통 소프트웨어나 눈에 보이지 않는 서비스 및 용역은 QA(품질보증,Assurance)이라고 하며, 실재하는 상품 및 재화에는 QC(품질확인,Control) 활동을 한다고 한다. 아마 눈썰미가 좋은 사람이라면 옷이나 물건을 구매했을 때 QC 스티커가 붙어있는 것을 확인해볼 수 있을 것이다. (물론 QC 스티커를 부착하도록 법제화 되어있지는 않지만 몇몇 기업은 QC작업을 했다는 것을 강조하기 위해 스키터를 부착하기도 한다) 즉, 100%는 아니지만 QA는 주로 무형의 상품에, QC는 유형의 상품에 투입되는 조직이라고 생각하면 된다.
- QA 조직의 목표
본격적으로 QA 얘기를 해보려고 한다. QA는 개발이 완료된 후에, 테스트를 함으로써 안전성을 확보하는 조직이다. 보통 테스트 리더(TL)가 전체적인 목표와 구체적인 테스트 방법, 인원, 일정, 사후관리 등 테스트에 필요한 전체적인 구조를 잡는다. 이후 팀원들이 투입되어 전체적인 마일스톤 일정에 맞춰 테스트를 진행한다. QA 조직이 해야 할 일은 정말 산더미처럼 많지만 정말 핵심적인 역할은 ‘안정성 확보를 통한 컨텐츠 고품질화’라고 할 수 있다.
결국 제공하는 서비스의 안정성과 고품질화를 위해 존재하는 조직이니만큼, 그 중요성도 막중한 편이다. 아쉽게도 한국에서는 QA = 테스터로 인식되어 상당히 저평가되어있는 상태인데 이 부분이 상당히 아쉽게 느껴진다. 전문직이라고 하기엔 딱히 취득해야하는 전문 기술도 없을 뿐더러 간단한 QA는 개발자 작업으로 대체할 수 있기 때문이다. 아래에서 내가 직접 현업에서 느껴본 개발자 QA에 대해 좀 더 면밀히 다뤄보도록 하겠다.
- (1) 개발 QA
위는 보험공단에서 발급받은 건강보험 득실확인내역이다. 강남구에 있는 게임사에 입사하였고, 이 곳은 내가 들어오기 전까지 10명 남짓의 개발자들이 QA까지 직접 하는 형태로 QA가 진행되고 있었다. 개발QA는 말그대로 개발자가 QA까지 직접 테스트하는 구조다. 즉 개발이 완료된 모듈 또는 버전을 본인이 테스트하는 방식인데, 파트별로 테스트할 것인지, 아니면 특정 날짜에 테스트할 것인지, 특정 구간별로 테스트할 것인지는 개발자 마음대로 결정할 수 있다.
이 개발QA의 장점으로는 추가적인 QA인원이 필요하지 않다는 것이다. 즉 투입비용을 절약할 수 있으며, 이 자원을 다른 조직이나 프로세스에 투입시켜 나름대로의 집중적인 투자가 가능하다. 그 밖에도 QA를 언제 할 것인지도 본인 스스로 정하기 때문에 유연적인 일정관리가 가능하며, 즉각적인 오류 수정으로 인한 BTS(Bug Tracking System) 불필요, QA조직의 불필요로 인한 업무 조직도도 간결화시킬 수 있다.
위에 나열된 장점만 보면 꽤나 그럴듯해 보이지만, 사실 개발QA는 장점과는 비교도 안될만큼 수많은 단점이 존재한다.
우선 완성된 최종 콘텐츠는 결국 개발자가 사용하는게 아니기 때문에 개발자의 시각보다는 불특정 다수의 고객들의 시선으로 테스트를 해야 한다. 내가 QA를 하고 싶어하는 지원자들이나 후배들에게 늘 하는 말 중 하나가 "최대한 고객의 시선에서 바라보라"인 이유이기도 하다. 즉 개발 QA의 경우 본인이 개발한 콘텐츠에 대한 객관적인 판단이 힘들다.
오류라고 판단되는 동작을 발견했을 경우, 이게 오류인지, 아니면 기획의도인지 판단하기 힘들다는 것이다. 또 업무 특성상 개발자의 경우 오류를 발견했을 때에도 크리티컬하거나 심각한 오류가 아닐경우 그냥 넘어가려고 하는 성향이 강한데, 개발QA의 경우 그런 점을 견제해줄 조직이 아예 없기 때문에 전체적으로 품질이 저품질화될 확률이 높다.
쉽게 말해 QA는 안정성을 최우선으로 하는 집단이기 때문에 “물이 반밖에 안남았네”라고 해석할 수 있지만, 개발일정 등 개발 진척도와 공수 일정을 최우선으로 하는 개발자들은 “물이 반이나 남았네”라고 해석할 공산이 크다는 것이다.
또 개발QA의 경우 오류들의 관리가 소홀해질 수 밖에 없다. 즉각적인 오류 보고와 수정은 개발QA가 더 빠를수도 있지만, 결국 버전별 오류처리 추이, 오류 통계, 오류 영향도, 오류 수정 진행도 등, 오류와 관련된 수많은 인덱스는 결국 한 곳에서 통합하여 진행하는 것이, 오류 누락도 예방할 수 있으며, 각 부서별 전사적 오류 관리에도 용이하다.
가장 큰 이유는 마지막이다. 개발자는 개발만 하는 것이 능률상 가장 좋다. QA가 단순히 부분적인 테스트만 하는 소위 말하는 “아무나 할 수 있는 일”이 아니라는 점을 알아두어야 한다. 간단한 테스트로 보일수도 있지만 나름대로의 경험적/탐색적 테스팅 노하우가 축적되고 그에 따라 오류를 찾아내는 퀄리티도 달라진다. 일 하면서 QA를 잘하는 개발자도 여럿 만나봤는데, 개발자가 아무리 오류를 잘 찾는다고 한들, 밥만 먹고 오류만 찾아다니는 업(業) 자체가 QA Tester인 사람보다 잘하는 사람은 아직 못봤다.
즉 개발자는 본인이 100% 일률을 낼 수 있는 개발에 집중하고 QA도 QA 일률 100%를 낼 수 있는 QA에 집중해주었을 때 최고의 성과를 달성할 수 있다는 말이다. 뒤에 다양한 QA조직 형태를 들어보며 다시 설명하겠지만, 확실히 개발QA는 비용은 아낄 수 있지만 결국 제품의 고품질화에는 한계가 존재하는 조직 형태일 수밖에 없다.
- (2) 조직 내 QA
다음은 조직 내 QA가 있는 형태다. 대기업에서 자주 보이는 조직인데, 즉 하나의 기업 안에 독립된 QA 조직이 있는 형태다. 내가 재직했었던 (주)넥슨XXXX는 (주)넥슨의 경우 자회사로써 넥슨에서 제공하고 있는 게임에 대한 전체적인 QA를 진행한다. 내 생각에는 가장 이상적인 형태의 QA조직같은데, 독립성은 유지해주면서 예기치 못한 오류에 대해서도 즉각적인 처리가 가능하기 때문이다. 보통 개발 - 기획 - QA가 유기적으로 상호 협력하며 고품질화에 저해가 되는 의사결정은 과감히 견제하기도 한다. 실제 QA조직에 힘이 많이 실리는 경우 검토 후 수정해주어야 하는 오류가 많아져 현업 개발자들이 힘들어하기도 한다. 반대로 QA조직이 힘이 없다면 크리티컬한 오류는 수정하지 않은 채 업데이트하기도 한다.
이 경우 유관부서 간의 버그 내역을 반드시 공유해야 하기 때문에 BTS(Bug Tracking System)를 준비해야하며, 개발QA에서는 혼자 수정하고 끝내도 됐을 오류도 QA부서(보고) -> 개발자 -> QA부서(수정 확인) -> 개발자(개발 반영) 스탭으로 진행되기 때문에 개발QA대비 소요되는 기간도 편이다. 개발QA에 익숙했던 개발자는 다소 불편할 수 있는 부분으로써 처음 입사했던 강남의 XX게임즈에서도 JIRA를 통한 BTS를 제안했다가 개발자들의 불편함(?) 호소로 인해 네이트온 쪽지로 버그 트래킹 및 공유을 했던 기억이 난다.
투입 비용도 늘어나고 준비해야 할 것도 많고 유관부서도 늘어났기 때문에 더 복잡해지지 않을까. 라고 생각할 수는 있지만 장기적으로 더 좋은 서비스를 제공하기 위해서는 반드시 필요한 작업이다. 오류(이슈)의 축적을 통해 앞으로 발생할 이슈에 대해서도 예측할 수 있으며, 이후 테스트 시 어느 부분을 집중적으로 봐야할 지에 대한 윤곽도 알 수 있다. 또한 개발조직을 견제해줄 QA조직이 있기 때문에 특정 오류를 무시한 채 업데이트를 진행하는 리스크도 제거할 수 있다.
최근 몇 년전부터 대기업에서도 QA의 중요성에 대해 깨닫고 투자비율을 늘린다는 기사를 본 적이 있다. 결국 자사의 콘텐츠가 그 회사에 대한 이미지로 귀결되기 때문이다. 이런 인식이 널리 퍼져서 QA에 대한 인식 자체가 좋아져야 할텐데, 라는 생각만 벌써 몇 년째인지 모르겠다. 이제 어느 정도 마음을 놓아둔 상태이긴 하지만..
- (3) 조직 외 QA
말 그대로 QA를 다른 회사에 외주를 맡기는 형태인데, 반도체를 포함한 다른 실물상품군에서는 이미 QC 외주화를 통해 이윤을 극대화하고 있다. 한국에서도 QA에 대한 중요성이 부각되면서 많은 SW(소프트웨어) 외주 업체들이 생겨났는데 아직 내가 해당 기업에서는 근무해본 적이 없어 현업에 대한 정확한 이야기는 해줄 수 없을 것 같다.
외주를 맡긴 기업에서는 계약된 특정 금액만 지불하면 내부에서 QA를 배제시킨 후 개발에 집중할 수 있다는 장점이 있고 외주업체에서는 QA에 전문화된 인력을 고용함으로써 고품질의 QA서비스를 제공하는 것이 가능하다. 단점이라면 외주업체의 서비스가 아니기 때문에 책임감 결여와 같은 문제가 있을 수도 있지만, 그럴 경우 결국 영업손해 심지어 계약파기로도 이어질 수 있다. 아무튼 이런 외주 QA업체가 생겼다는 것만으로도 QA에 대한 중요성이 증대되는 것 같아 관련 업계에서 일하는 사람으로써 내심 흐뭇하기도 하다.
- 나는....?
QA조직 형태에 대해 간단하게 적어봤다. 물론 위에 제시한 3가지 말고도 정의되진 않았지만 정말 다양한 형태로 QA조직은 존립되고 있다. 참고로 나는 조직내 QA에 속하지만 팀원은 나 하나뿐이다. 즉 테스트 리더(TL)은 고사하고 팀원이 나밖에 없기 때문에 업무강도가 매우 높은 편이다. 애초에 2명도 되지 않기 때문에 크로스 체크(Cross Check)은 물론이거니와, QA에서 하나라도 놓치는 순간 바로 고객사에게 전달된다고 보면 된다.
정말 QA 할 때마다 살얼음판을 걷는 느낌이랄까... 그래서 나는 가끔 이런 말을 하곤 한다. "정말 한 번 큰 사고 쳐줘야 QA에 대해 경각심을 느끼려나..?" QA팀이 있지만 QA팀원이 한 명이라.. 아무튼 좀 이상한건 사실이다. 이 글을 읽는 사람들이 몇 명이나 있을지 모르지만 QA 종사자님들, 혹은 QA를 꿈꾸는 많은 분들, 그저 모두 잘 되었으면 하는 바람이다.
'QA·QC' 카테고리의 다른 글
| [QA/QC] 벌써 5년차, 과연 비전있는 직종인가? 에 대한 고찰 (20) | 2021.04.30 |
|---|---|
| [ISTQB] STEN 1월 정기 시험접수 완료(feat. 응시료 창렬함) (3) | 2021.01.07 |
| 6년차가 적어보는 국내 QA의 현실 및 처우에 대한 고찰 (8) | 2020.07.03 |
| 첫직장 - 넥슨네트웍스 QA(2) (5) | 2020.06.23 |
| 첫직장 - 넥슨네트웍스 QA(1) (3) | 2020.06.22 |