3. AI가 테스트를 대신하기 시작할 때

3. AI가 테스트를 대신하기 시작할 때, QA에게 더 중요한 일이 남는다

Manual Test Case가 있습니다.

Step 1. 상품을 검색한다.
Step 2. 상품을 선택한다.
Step 3. 장바구니에 추가한다.
Step 4. 쿠폰을 적용한다.
Step 5. 결제를 진행한다.
Step 6. 주문 완료 화면을 확인한다.

사람이 보면 단순한 시나리오입니다.

그런데 Regression마다 사람이 실행하고 있다면 이야기가 달라집니다.

브라우저를 열고 클릭합니다.

텍스트를 입력합니다.

다시 클릭합니다.

화면을 기다립니다.

Expected Result와 실제 화면을 비교합니다.

그리고 다음 TC.

몇백 번 반복하면 손보다 먼저 집중력이 지칩니다.

그래서 어느 순간 이런 시도를 합니다.

Manual Test Case를 AI에게 넣습니다.

“이 TC를 Playwright 자동화 코드로 만들어줘.”

몇 초 뒤 자동화 스크립트가 만들어집니다.

처음 실행하면 당연히 완벽하지 않습니다.

Selector가 틀립니다.

Loading을 기다리지 않습니다.

Popup 때문에 실패합니다.

테스트 데이터가 맞지 않습니다.

다시 AI에게 설명합니다.

코드를 수정하고 실행합니다.

이번에는 성공합니다.

그 순간 묘한 감정이 들 수 있습니다.

‘그럼 지금까지 내가 하던 일은 뭐였지?’

그리고 조금 더 나아가면 또 다른 현실을 마주하게 됩니다.

스크립트가 실행되는 것은 자동화됐지만 결과를 확인하는 일은 여전히 사람 몫인 경우가 많습니다.

Screenshot이 100장 생성됩니다.

하나씩 엽니다.

상품명이 맞는지 봅니다.

가격이 맞는지 확인합니다.

버튼이 잘리지 않았는지 봅니다.

레이아웃이 깨지지 않았는지 봅니다.

Popup 위치를 확인합니다.

Mobile과 Desktop 결과를 비교합니다.

결국 눈으로 다시 확인합니다.

그러다 보면 자동화를 했는데도 또 다른 형태의 반복 작업이 생긴 것처럼 느껴질 수 있습니다.

하지만 이 변화는 QA의 가치가 줄어드는 과정이 아닙니다.

반대입니다.

QA가 직접 하지 않아도 되는 일을 하나씩 기계에게 넘기는 과정입니다.

전자책에서는 반복 업무 자체를 없애기 어렵다면 업무의 구조를 개선하고, 툴과 템플릿을 만들어 같은 일을 다음에는 더 쉽게 수행할 수 있도록 만들라고 제안합니다.

AI 기반 테스트 자동화는 이 생각을 QA 업무에서 가장 직접적으로 구현할 수 있는 방법 중 하나입니다.

중요한 것은 AI가 코드를 써줬다는 사실이 아닙니다.

그 전에 QA가 해야 하는 일이 있습니다.

무엇을 테스트해야 하는지 알아야 합니다.

어떤 Preconditions가 필요한지 알아야 합니다.

어떤 결과가 정상인지 정의해야 합니다.

어떤 실패는 진짜 버그이고 어떤 실패는 테스트 데이터 문제인지 판단해야 합니다.

어떤 시나리오는 자동화하면 효율적이고 어떤 시나리오는 사람이 보는 편이 나은지도 결정해야 합니다.

AI가 코드를 생성할 수는 있어도 이 판단까지 자동으로 완벽하게 해주지는 않습니다.

예를 들어 AI가 다음 코드를 만들어냈다고 해봅시다.

expect(orderComplete).toBeVisible()

코드는 주문 완료 문구가 화면에 있다는 것을 확인합니다.

하지만 QA는 그보다 많은 것을 봅니다.

정확한 상품이 주문되었는가.

쿠폰 할인액이 맞는가.

배송비가 제대로 계산되었는가.

결제금액이 주문 상세와 일치하는가.

결제는 한 번만 발생했는가.

재고가 정상적으로 차감되었는가.

주문이 실제 Backend에도 생성되었는가.

이것이 QA의 판단입니다.

자동화는 클릭을 대신할 수 있습니다.

AI는 스크립트 작성을 빠르게 할 수 있습니다.

Visual AI는 화면의 차이를 찾아줄 수도 있습니다.

하지만 무엇이 중요한 차이인지 판단하는 일은 여전히 QA의 영역입니다.

그러니 자동화 결과 화면 수백 장을 보면서 지쳐 있는 QA라면 자신이 단순히 이미지를 확인하고 있다고 생각하지 않았으면 합니다.

당신은 자동화가 놓칠 수 있는 ‘의미’를 확인하고 있습니다.

픽셀은 비슷한데 사용성은 이상할 수 있습니다.

버튼은 존재하지만 고객이 찾기 어려울 수 있습니다.

텍스트는 표시되지만 잘못된 금액일 수 있습니다.

자동화 스크립트는 성공했지만 실제 주문 데이터는 잘못 생성되어 있을 수 있습니다.

AI 시대의 QA에게 중요한 능력은 모든 테스트를 직접 실행하는 능력이 아닐 수 있습니다.

무엇을 자동화하고, 무엇을 사람이 확인하며, 어떤 결과를 신뢰할 것인지 설계하는 능력이 더 중요해질 수 있습니다.

그러니 처음부터 거대한 자동화 프로젝트를 만들 필요는 없습니다.

오늘 반복해서 수행한 TC 중 하나만 골라도 됩니다.

AI에게 스크립트 초안을 만들어보게 합니다.

직접 고쳐봅니다.

실행해봅니다.

실패 이유를 분석합니다.

Expected Result를 Assertion으로 바꿔봅니다.

그리고 다음 Regression 때 그 하나를 사람이 직접 실행하지 않아도 된다면 충분합니다.

오늘 자동화한 테스트 하나가 내일의 반복 하나를 없앱니다.

10개가 되면 10번의 반복이 사라집니다.

100개가 되면 QA가 사용할 수 있는 시간이 달라집니다.

그리고 그 시간에는 더 가치 있는 일을 할 수 있습니다.

새로운 Edge Case를 찾고,

Exploratory Testing을 하고,

Risk를 분석하고,

서비스 구조를 이해하고,

고객이 실제로 어떤 방식으로 실패할 수 있는지 생각할 수 있습니다.

AI가 QA의 일을 빼앗는 것이 아니라,

QA가 클릭하는 데 쓰던 시간을 생각하는 데 다시 돌려주는 것.

자동화의 목적은 결국 거기에 있습니다.

---

 

#생성형AI #AI업무자동화 #테스트자동화 #QA자동화 #AI시대 #Playwright #소프트웨어테스트 #업무혁신 #디지털전환 #AI활용 #매뉴얼테스트 #자동화스크립트 #생산성향상 #미래직업 #HumanInTheLoop