AI 시대에야말로 QA 엔지니어를 목표로 하고 싶다: 각 사의 노력에서 생각한 QA의 미래

저는 현재 신입으로 QA 엔지니어를 목표로 하고 있습니다.

connpass에서 신청한 이벤트에서, 니시다 야스아키(株式会社TOKIUM) 님의 'QA를 통한 하네스 엔지니어링과 QA 조직의 미래상'이라는 발표를 들었습니다.

테스트 작성이나 실행을 AI에 맡길 수 있게 되었을 때, QA 엔지니어는 어떤 사람이 될까요? QA 지식이 다른 직종이나 AI도 사용할 수 있게 된다면, 조직 내에서의 역할은 어떻게 변할까요?

이 글에서는 발표의 후반부에서 다루어진 'QA 조직의 미래상'을 바탕으로, 각 사의 사례와 제가 목표로 하는 QA 엔지니어상을 생각해보겠습니다.

발표에서는 QA 업무를 QA 외의 사람도 수행할 수 있는 상태로 만들고, QA 엔지니어는 전략 수립이나 시스템 구축, 어려운 테스트에 관여하는 미래상이 제시되었습니다.

발표에서는 QA 업무가 '대체형'과 '강화형'으로 나누어 정리되어 있었습니다.

'대체형'으로 언급된 것은 사양서(仕様書)로부터의 테스트 케이스 작성, 절차에 따른 테스트 실행, 결과 기록, 테스트 코드 작성 등입니다.

반면, '강화형'에는 리스크 기반의 테스트 전략, 탐색적 테스트(Exploratory Testing), UX 평가, 품질 메트릭스 설계, 릴리스 판정/리스크 판단 등이 언급되었습니다. 이는 AI가 사람을 지원하면서도 인간의 판단이 남는 영역으로 정리되어 있습니다.

더 나아가 개발 공정 중에서는 상류 단계의 '무엇을 확인할 것인가'와 하류 단계의 '내보내도 괜찮은가'에 인간의 판단이 남아있다는 설명이 있었습니다.

제가 궁금했던 점은, 작업을 진행하는 것과 그 작업을 무엇을 위해 하는지 결정하는 것이 분리되어 생각되고 있었다는 점입니다.

예를 들어 테스트 케이스를 단시간에 대량으로 만들 수 있다 하더라도, 해당 기능에서 가장 피하고 싶은 문제가 무엇인지 생각해내지 못하면 어떤 테스트를 우선해야 할지 알 수 없습니다.

자동화를 통해 확인할 양이 늘어난다면, 그 확인을 사용자에게 의미 있는 것으로 만드는 것에도 힘을 쓸 수 있을 것이라고 생각합니다.

여기에 QA의 전문성을 발휘할 여지가 있으며, 매우 흥미롭고 보람 있는 영역이라고 느꼈습니다.

장기 인턴십에서 테스트 설계에 임했을 때도, 사양서를 읽는 것만으로는 판단할 수 없는 부분이 있었습니다.

그 과정에서 절차나 기대 결과를 남기는 것뿐만 아니라, QA가 무엇을 근거로 판단하고 있는지, 그것을 어떻게 공유해야 할지가 궁금했습니다.

이번 발표를 듣고, 그 판단 기준을 공유하는 대상은 QA 팀 내에 국한될 필요는 없다고 생각했습니다. 기능을 검토하는 단계에서 개발자나 PdM(Product Manager)과 공유할 수 있다면, 테스트 준비뿐만 아니라 사양을 결정하는 데에도 사용될 것 같습니다.

여기부터는 생각하기 위한 가상의 예시입니다.

근태 관리 서비스에 '직원 소속 부서를 변경하는 기능'이 있다고 가정해 보겠습니다. 화면에서 부서를 선택하고 저장한 후 올바르게 표시되는 것은 하나의 확인 사항일 뿐입니다.

하지만 업무상으로는 그것만으로는 부족할 수 있습니다.

전출 전의 근태는 누가 참조할 수 있을까요? 신청 도중인 건은, 전출 전과 전출 후 중 어느 상사가 승인해야 할까요? 소속 부서를 변경함으로써 승인할 사람이 없어지지는 않을까요?

이것들에 일률적인 정답이 있는 것은 아니며, 서비스의 요구사항이나 이용자의 운영에 따라 결정해야 합니다.

화면상의 변경이 성공했더라도, 그 결과로 승인이 진행되지 않아 월말 마감 처리가 멈춘다면, 사용자에게는 문제입니다.

이때 QA가 할 수 있는 것은 모호한 사양을 독단적으로 보완하여 테스트 케이스를 만드는 것이 아니라고 생각합니다.

어디가 결정되지 않았는지, 그 차이에 따라 누가 어려움을 겪게 되는지를 정리하고, 개발자나 PdM과 확인하는 것. 그 위에서 합의된 내용을 테스트로 확인할 수 있는 형태로 만드는 것입니다.

물론, 이러한 질문을 던지는 것이 QA만의 일은 아닙니다. 그럼에도 불구하고, 이용 상황이나 실패했을 때의 영향을 지속적으로 질문하고, 확인해야 할 것을 구체화하는 역할로서 QA 지식을 활용할 수 있다고 생각합니다.

테스트를 빠르게 만드는 것뿐만 아니라, 만들기 시작하기 전에 무엇을 명확히 하는가.

AI를 활용하는 개발에서도, 이 부분에 관여할 수 있는 QA가 되고 싶습니다.

발표에서는 SmartHR, freee, LayerX, 食べログ(타베로그), Mercari, M3 등 여러 기업의 노력이 소개되었습니다.

아래 6개사는 그 소개 내용의 요약입니다. 각 사의 활동 전체를 나타내는 것이 아니며, AI 도입 성과를 동일한 조건으로 비교한 것도 아닙니다. 여기서는 QA의 관여 방식을 생각하는 재료로 되돌아봅니다.

QA의 동행을 멈추고 개발 멤버만으로 테스트를 진행하는 팀이 있는 반면, 복잡한 기능에서는 QA가 다시 관여하는 사례가 소개되었습니다.

QA가 떠나는 것을 목표로 삼기보다, 팀의 상황이나 기능의 난이도에 맞춰 관여 방식을 변화시키는 점이 인상 깊었습니다. 맡길 수 있는 것은 늘려가면서, 어려운 부분은 상담할 수 있는 관계를 만들어 나가는 것이 이상적이라고 생각했습니다.

제품 QA와 교차(Cross-functional) QA의 이원화된 체제가 소개되었습니다.

현장을 깊이 이해하는 것과, 거기서 얻은 지식을 다른 팀에도 확산시키는 것. 두 가지 역할이 모두 있다면, 하나의 제품에서 얻은 경험을 조직 전체의 개선으로 연결할 수 있을 것 같습니다.

확인형 테스트(Confirmation Test) 252건에서 결함 탐지 0건이었던 사례와, '탐지'에서 '관측 및 가치 검증(Observation & Value Validation)'으로 변화하는 것이 소개되었습니다.

다만, 테스트에서 문제가 발견되지 않는 것과 사용자가 어려움을 겪지 않는 것은 별개입니다. 탐지 건수뿐 아니라, 현재 테스트로 무엇을 포착하고 있는지에 대해 되묻고 싶었습니다.

소개된 사례에서는 테스트 실행 공수를 52% 절감했고, 자동화율이 24%에서 64%로 향상되었습니다.

저 역시 자동화에 임할 때는 줄인 시간뿐만 아니라, 그 여력으로 무엇을 확인하거나 개선할 수 있었는지까지 보고 싶습니다.

수용 조건(Acceptance Criteria) 작성 과정을 AI 도구화하여 PM이나 엔지니어가 사용하는 시도가 소개되었습니다.

QA가 매번 조건을 생각하는 것뿐만 아니라, 다른 직군이 생각하기 위한 도구를 만드는 것도 QA의 기여라고 느꼈습니다. 다만, 생성된 조건의 타당성을 어떻게 확인할지도 함께 고민해 가야 한다고 생각합니다.

'전원 QA(All-QA)'를 진행하며, QA가 테스트 실행자에서 품질 전략가로 이동하는 구상이 소개되었습니다.

테스트를 분담할 뿐만 아니라, 무엇을 우선하여 확인할지, 어떤 기준으로 판단할지를 정립하는 것도 QA가 맡아야 할 역할이라고 생각했습니다.

여기는 발표 내용이 아니라, 제가 주목하고 있는 Cybows의 QA에 대한 보충 설명입니다.

Cybows의 QA는 사양 검토부터 릴리스 후까지 개발자나 PdM과 연계하여, 테스트로 얻은 정보를 팀의 판단 자료로 제공한다고 설명되었습니다.

또한, 공식 블로그에는 AI 활용을 통해 시간이나 스킬 제약으로 손대지 못했던 조사 및 수정에도 착수할 수 있게 된 QA 사례가 있습니다.

제가 매력을 느끼는 부분은 테스트를 효율화하는 것뿐만 아니라, 팀에 대한 기여 범위를 넓히고 있다는 점입니다. AI에게 맡긴 후에 자신이 품질을 위해 할 수 있는 일을 늘리는 것. 이 관계 설정 방식이 제가 목표로 하는 모습과 가깝다고 느꼈습니다.

각 사의 사례를 보고 '앞으로의 QA 조직은 전부 이런 형태가 될 것이다'라고 생각하지는 못했습니다.

오히려, 자신들의 제품이나 개발 체제에 맞춰 QA가 관여하는 장소나 방식을 변화시키고 있다는 점이 참고가 되었습니다.

QA가 모든 것을 확인하는 것도 아니고, QA의 작업을 줄이는 것도 아닌, 팀으로서 필요한 확인과 판단을 할 수 있게 하는 것. 그를 위해 스스로 테스트할 때도 있고, 시스템을 만들 때도 있으며, 다른 사람과 함께 생각할 때도 있습니다.

'내가 무엇을 계속 담당할 것인가'보다, 품질상의 과제에 대해 어떤 관여 방식이 유용한지를 고민하는 QA가 되고 싶습니다.

이러한 역할을 고려하면, QA 성과의 측정 방법도 궁금해집니다.

예를 들어, 사양 검토 단계에서 승인자가 부재할 조건에気づき(발견)하여 구현 전에 사양을 재검토할 수 있었다고 가정해 봅시다. 이 경우, 릴리스 전 테스트에서 발견한 결함으로는 셀 수 없지만, 문제를 막기 위한 활동은 한 것입니다.

또한, 판단 기준이나 테스트 기반을 공유한 결과, 개발자가 변경의 영향을 스스로 확인할 수 있게 되었다면, QA가 직접 실행하는 테스트 건수는 줄어들 수도 있습니다.

그것만 보고 QA의 기여도까지 줄었다고 말할 수는 없을 것입니다.

저는 결함 탐지 건수에 더해, 확인 대기(Confirmation Wait)가 어디서 일어나고 있는지, 같은 문제로 반복적으로 되돌아가지는 않는지, 과거의 판단을 다음 변경에 활용하고 있는지도 보고 싶습니다.

다만, QA 공정이 짧아졌을 뿐인데 개발자의 확인 부담이나 릴리스 후 문제가 늘어나고 있다면, 성공적이라고 판단할 수 없습니다.

누군가 한 사람의 작업 시간이 아니라, 팀 전체적으로 무엇이 개선되었고 사용자의 리스크가 어떻게 변했는지. 그 정도까지 확인하고 싶습니다.

또한, '모두가 품질을 본다'라는 말이 책임 소재를 모호하게 만드는 단어가 되지 않도록 하고 싶습니다.

통상적인 확인은 누가 할 것인가. 판단에 망설임이 생기면 누구에게 상담할 것인가. 남는 리스크를 누구에게 전달하고, 릴리스 의사결정에 어떻게 사용할 것인가.

작업을 분담하는 것과 판단의 흐름을 정립하는 것은 세트로 생각해야 할 필요성을 느꼈습니다.

여기까지 생각해 봐도 '앞으로는 판단이 중요하니까 테스트 구현이나 실행을 배울 필요가 없다'고는 생각하지 않습니다.

판단의 근거를 갖기 위해서라도, 스스로 테스트를 설계하고, 실행하고, 결과를 조사하는 경험을 쌓고 싶습니다.

예를 들어, 앞서 언급된 부서 변경 기능에서 '권한을 확인한다'라고만 한다면 간단합니다.

하지만 구체적으로 어떤 사용자에게, 어떤 데이터에, 어떤 조작을 시도할지. 화면에서 보이지 않는 것을 확인하는 것만으로 충분한지. 실패했을 때, 사양/구현/테스트 중 어디를 조사해야 하는지.

그렇게까지 생각하게 되면, 업무 이해뿐만 아니라 구현이나 시스템의 메커니즘에 관한 지식도 필요합니다.

AI를 사용할 경우에도, 생성된 테스트 케이스를 읽고 어디까지 확인했는지 스스로 추적할 수 있게 되고 싶습니다.

동시에, 테스트 케이스를 남길 때에는 '왜 이것을 확인하는지'도 함께 기록하는 것을 의식하고 싶습니다.

단순히 '이동 후 권한을 확인한다'라고 쓰는 것이 아니라, '부서 변경으로 인해 참조 권한이 바뀌어 필요한 과거 데이터를 볼 수 없게 될 가능성이 있기 때문에'와 같이 이유를 덧붙이는 것입니다.

근거가 되는 사양과 아직 확인이 필요한 점도 분리해 놓으면, 다른 사람이 봤을 때 그 테스트를 어디까지 신뢰할 수 있을지 생각하기 쉬워집니다.

우선 개인 개발이나 학습 과정에서 테스트를 만들고 끝내는 것이 아니라, 다른 사람이 판단에 사용할 수 있는 형태로 남기는 것까지 도전하고 싶습니다.

이번 발표에서는 QA의 중심이 작업(Task)에서 판단(Judgment)으로 이동하여, 전략/메커니즘/어려운 테스트에 관여해 나가는 미래상이 제시되었습니다.

저는 'AI 시대라서 QA가 안전하다'라고 생각하는 것은 아닙니다. QA라는 직종이라는 것만으로 가치가 자동으로 높아진다고도 생각하지 않습니다.

다만, AI를 통해 생성이나 확인을 빠르게 진행할 수 있다면, 그 힘을 무엇에 위해 사용할지, 어디까지 확인해야 진행할 수 있을지를 팀 차원에서 판단하는 것이 중요하다고 생각합니다.

그 판단에 필요한 정보를 모으고, 모호한 점을 명확히 하며, 확인할 수 있는 시스템을 만드는 일. 이러한 업무는 AI가 등장해서 처음 필요해진 것은 아닐 것입니다.

그렇기에 지금까지 QA가 쌓아온 사고방식을, AI와 함께 개발하는 환경에서도 활용할 수 있지 않을까 생각했습니다.

제가 테스트를 많이 할 수 있다는 것 외에도, 제가 관여함으로써 팀이 품질에 대해 판단하기 쉬워지도록 하는 것도 목표로 하고 싶습니다.

AI에게 맡길 수 있는 것을 늘려가면서, 저 자신도 할 수 있는 것을 늘려나가는. 이번 발표와 각 사의 노력들을 통해, 그런 QA 엔지니어로서 일하고 싶다고 다시 한번 느꼈습니다.