QA 직군의 대 혼란
나는 대체 뭘 하는 사람인가?
전 세계적으로 대 혼란의 QA
QA란 Quality Assurance의 약자이다. 한국에서는 이를 품질 보증이라고 얘기하는데, 이 말부터 틀렸다고 생각한다. '품질'은 'Product Quality'이다. Quality Assurance는 제품 자체만의 질을 확인하는 일이 아니기 때문에, 나는 Quality를 '품질'이라고 칭하는걸 굉장히 싫어한다. 그냥 '퀄리티'라고 칭하고 싶다. 한국에서 많이들 QA를 단순한 테스터로 받아들이는 경향이 있는 이유의 시작이 여기서 오는 것이 아닐까 생각된다.
Quality Assurance는 어떤 제품이든 매우 중요하며 빠질 수 없는 과정이다. 유독 QA 쪽에 수많은, 그리고 말도 안 되는 직군들이 있으며, 이걸 좀 정리를 해야 어떤 포지션이 어떤 일을 하는지 확실하게 알 수 있을 것이다. 소프트웨어 개발 주기 안에서 아마 아무런 전문 지식 없이 시작할 수 있는 파트가 아마 테스트 일 것이다. 테스트는 누구나 할 수 있다. 중학생도 테스트 케이스를 주고 이대로 따라 하고 검증하라고 하면 할 수 있을 것이다. 다만 복잡하고 어려운 케이스들부터, 전문적 지식이 요구되는 케이스의 경우 전문가 혹은 코칭이 필요한 것이다.
Tester, Test Engineer, Test Automation Engineer, Software Engineer in Test
이 직군들은 테스트를 수행하기 위한 사람들이다. 테스트 케이스를 작성, 업데이트 및 실행을 하고, 이슈를 리포트하는 재검수를 하는 것을 아마도 반복하게 된다. 보안이나 성능 테스트, 자동화 프로그래밍 스킬 등의 전문적인 지식 및 능력이 있는 사람이 이 직군에서 더 경쟁력이 있겠다. 어떠한 제품을 테스트하는 것이기 때문에, 품질관리/확인을 하는 직군이다. 개발팀의 전체적인 프로세스에는 참여를 안 할 수도 있으며 따라서 사내 협업 툴 등의 사용도 그다지 필요가 없게 된다.
QA (Quality Analyst), QA Analyst, QA Engineer
이 직군은 위의 직군보다 조금은 더 한 단계 위의 개발 주기에 포함되어 일을 하는 게 맞다. 개발 주기의 계획이나 개발 단계에 적극적으로 참여하여 제품의 quality에 대해 분석하고, 개선하는 방향을 제시해주는 포지션이다. 하지만 품질에 대해서는 사실 팀 내에서 누구나 다 관여하고 고민하여 개선을 제시할 수 있기 때문에, 이 포지션은 대부분 테스터로 취급되는 케이스가 대부분이다. 그 이유는 아마도 프로그래밍에 대한 지식이 전무하거나, 많지 않아 개발 주기에 대한 이해도는 떨어지기 때문이 가장 큰 이유 같다.
QA Automation Engineer, Quality Engineer
이 직군은 팀 Operation의 엔지니어링에 집중한 QA 포지션이다. 개발 팀 내의 제품을 포함한 전체적인 quality (개발 프로세스, 문서, 등)를 분석하고 보다 빠르고 효율적으로 개발하는 동시에 높은 품질의 제품이 만들어질 수 있도록 하는 일이다. 애자일 방법론이 도입되면서 자동화에 대한 부분이 높아졌다. 테스트 자동화 엔지니어와는 달리, 테스트만 자동화를 하는 것이 아니라 다른 부분도 자동화하기 때문에, CI/CD 등의 여러 분야의 지식이 필요하다. 개발팀의 전체적인 과정에 모두 참여하며 분석해야 한다. 따라서 프로덕트 매니저 (PM)이 하는 일부터 개발자, 테스터가 하는 일까지 잘 알고 있어야 하며, 협업할 수 있어야 한다. 하지만 이 포지션 또한 대부분은 방대하게 일을 하는 Test Automation Engineer가 되어버리기 십상이다.
Agile Quality Coach
이 직군은 테스터와는 가장 멀고, 애자일 코치의 변화 형태이다. 애자일 방법론 안에서 quality가 전체적으로 가장 중요한 부분이고, 또 효율성인 부분에서 해결하기에 가장 어려운 부분이기 때문에 이러한 직군도 생겨났다. 간단하게는 팀 내의 각 포지션들의 업무와 방식들을 파악하고 그에 맞는 quality에 대한 mindset을 팀에게 코칭해주고 디렉팅을 해주는 포지션이라고 생각하면 된다. 다만 테크니컬 한 부분보다는 팀의 프로세스와 operation에 대해 더 집중한다. 한국에서는 아마 찾아보기 힘든 직군이지만, 실리콘밸리에는 꽤나 핫해지고 있다.
그렇다면 문제는? 부족한 재원
대부분의 회사들은 눈에 띄는 효율성을 보고 싶어 하기 때문에 빠른 시일 내에 변화를 가져오길 바란다. 한국의 경우, 비교적 저렴한 노동력으로 인해 단순 테스터 직군을 뽑아서 머릿수로 밀어붙이는 케이스가 있다. 혹은 QA Engineer를 채용해서 자동화도 조금 하고, 매뉴얼 한 테스팅도 하면서 개발 주기에도 참여시켜 두 개의 심장 하이브리드(?)로 이용하고 있다. 이 외의 Quality Engineer나 Agile Quality Coach 직군은 사실 실제로 하는 사람이나 회사에서 채용하는 케이스가 찾기 쉽지 않다.
QA 내의 고질적인 문제라면, 낮은 진입장벽이다. 프로그래밍이나 개발에 대한 지식이 없는 채로 입문하는 사람들도 많고, 개발 관련 테크니컬 한 쪽으로 진로를 진행하기 원하지 않는 사람들이 생각보다 많기 때문인 것 같다. 그 때문에 생기는 또 하나의 문제는 마켓에 능숙한 경력직 QA Automation Engineer나 Quality Engineer, 또는 Agile Quality Coach가 없어, 사내에서 Quality에 대한 변화와 진화를 일으키기가 힘든 것도 사실이다. 그래도 최근 해외 기업들은 QA Automation Engineer를 더 적극적으로 찾기 시작했다는 것이다. 물론 의외로 많은 회사들이 이 포지션을 Test Engineer쯤으로 생각하고 있기도 하지만, 적어도 이 포지션에 대해 제대로 인지하고 찾기 시작한 회사들이 늘어난 것은 사실이다.
예를 들어 AirBnB의 경우, 개발팀의 모두가 테스트를 수행한다. 모든 팀원은 quality에 대한 책임과 의무가 있고, 이미 사내에서 이러한 mindset이 통합되어있기 때문에, 테스트/QA 관련 포지션이 전사를 통틀어서 한 두 명 밖에 없다고 한다.
나는 Test Engineer로서 처음 일을 시작하고서 QA로 넘어오게 되고, 그 사이에 개발자로서도 일을 하고 프로덕트 오너 (PO) 로서의 경험도 생겼다. 덕분에 현재는 Senior QA Automation Engineer로 회사 전체 모든 개발팀들의 프로세스 개선에 힘쓰고 있다. 하지만 테스트 자동화 경험이 풍부하고 할 줄 아는 사람 또한 나뿐이라, 내가 다 하면서 동시에 다른 테스터들을 코칭하며 QA Engineer로 성장하도록 돕는 중이다.
내가 회사의 인식을 바꾸기란 쉽지 않다. 발등에 불이 떨어져 봐야 급하게 끄는 것 밖에 하지 않는 케이스도 많다. 큰 회사들은 실험적으로라도 Agile Quality Coach 등 더 미래지향적인 직군을 늘리고 있지만, 확실히 이 변화는 빠르게 변할 수 없는 부분이다. 환경에 따라서도 다르기 때문에, 한국에서는 변화가 조금 더 더디지 않을까 싶다.
제품을 만들어 내는 곳에서, Quality는 누구 한 명의 몫이나 책임이 절대 아니다. 테스트 결과가 품질 (Product Quality)를 말하진 않는다. 애초에 초기 디자인이 잘못되었다던가, 리서치 결과가 잘못되어 개발 자체가 잘못된 방향으로 갔을 수도 있다. Quality는 팀원 모두의 책임이다. 테스트는 모두가 할 수 있다. 팀이 더 효율적으로 움직일 수 있고, 내가 더 효율적으로 일할수 있다면, 좋지 않은가? 이런 마인드셋을 지향한다면 QA Automation Engineer나 Agile Quality Coach가 어찌 보면 더 효율적인 채용이 아닐까 싶다.
