AI 테스트 자동화 솔루션 비교, 에이전트 5종의 한계

3줄 요약

• AI 테스트 에이전트를 붙이면 자동화 커버리지가 오른다는 말은 이번 주 리포트에서도 반복됐습니다.
• 다만 Wopee.io가 에이전트 5종을 비교한 조사에서 커버리지는 과거 상한이던 약 25%에서 51~60%로 올랐는데, 같은 조사의 완전 자율 자동화 만족도는 5점 만점에 2.2점이었고 무감독 운영을 실제로 지원하는 도구는 5종 중 하나도 없었습니다.
• 그러니 에이전트를 검토할 때 볼 값은 "자동화율이 몇 퍼센트까지 오르는가"가 아니라 "사람 검토 게이트가 주당 몇 건을 받아 내는가"입니다.

저는 이 두 숫자가 서로 반대 방향이라고 생각했습니다. 자동화 커버리지가 두 배로 올랐다면 도구가 알아서 잘 돌고 있다는 뜻이고, 그러면 만족도도 같이 올라야 맞으니까요. 그런데 이번 주 리포트에 실린 조사는 두 숫자를 같은 표에 나란히 놓고 있었습니다.

같은 조사에서 커버리지는 51~60%, 완전 자율 만족도는 2.2/5였거든요. 처음에는 조사가 두 개인 줄 알았습니다. 아니었습니다. 두 값 사이에 모순이 없다는 것을 알아차리는 데 한참 걸렸는데요, 알고 나니 이번 주 리포트에서 건질 것이 이 한 줄이었습니다.

이 글은 제가 직접 조사한 것이 아니라 이번 주 QA 동향 리포트를 옮긴 것입니다. 그래서 수치를 쓸 때마다 누가 조사한 값인지를 문장 안에 남겼습니다. 1차 소스로 재확인하지 않았기 때문에, 조사 주체를 지우고 숫자만 남기면 제가 실측한 것처럼 읽히기 때문입니다.

1. 조건이 붙은 수치만 남겼습니다

리포트에는 눈에 띄는 수치가 더 있었습니다. 그중 조사 주체나 기준 시점이 붙지 않은 것은 본문에 싣지 않았습니다. 아래가 남긴 것 전부입니다.

수치	조사·발표 주체	리포트가 밝힌 조건
완전 자율 자동화 만족도 2.2 / 5	Wopee.io 비교 리포트	AI 테스트 에이전트 5종(Wopee.io, Shiplight, Momentic, mabl, Midscene.js) 비교
자동화 커버리지 약 25% → 51~60%	동일	동일. 25%는 "과거 상한선" 표현
AI/ML 테스팅 스킬 급여 프리미엄 20~30%	QASkills.sh 급여 가이드 2026	2026년 기준. 표본 수는 리포트에 없음
자동화 엔지니어 vs 매뉴얼 QA 급여 차 40~60%	동일	동일 경력 기준
Playwright 숙련도 프리미엄 10~15%	동일	Selenium 대비
생성형 AI를 QE 업무에 활용 중인 조직 약 1/3	Sogeti·Capgemini·OpenText 「World Quality Report 2025-26」	조사 대상 조직 기준
GitLab 서베이 응답자 29%	Tricentis 블로그가 인용	AI 오류로 릴리스를 롤백한 경험

들어낸 것

원문에 있던 것	왜 뺐는가
AI 파일럿의 95%가 가드레일 부재로 실패 · 실패의 60%가 컴플라이언스 이슈	리포트 자체가 "독립적 검증 근거는 확인되지 않았습니다"로 표기
특정 고객사 수작업 85% 감소 · 생산성 60% 향상	단일 고객사 사례. 재현 근거 없음
지난 1년간 코드의 40% 이상이 AI 생성, 그중 최소 60%가 결함 포함	인용 서베이의 이름·표본·시점이 리포트에 없음
개발자 88%가 AI 생성 코드를 검증 없이 배포하는 데 자신 없음	조사 주체가 Stack Overflow인지 GitLab인지 리포트가 특정하지 않음
리스크 기반 커버리지의 테스트 시간 절감폭	리포트가 "특정 벤더의 주장"으로 표기

다섯 줄이 빠지고 나니 리포트의 인상이 꽤 달라졌습니다. 남은 수치는 대부분 "사람이 아직 필요하다"는 쪽을 가리키고, 빠진 수치는 대부분 "AI가 얼마나 많이 바꿨는가"를 말하는 쪽이었습니다. 어느 쪽이 맞는지는 저도 모릅니다. 다만 근거가 붙은 것만 놓고 보면 그림이 한쪽으로 기웁니다.

2. 커버리지 51~60%를 만든 것은 자율성이 아니었습니다

Wopee.io의 AI 테스트 에이전트 5종 비교 리포트는 커버리지 상승과 낮은 자율 만족도를 모순으로 다루지 않았습니다. 같은 원인의 두 면으로 설명했습니다.

리포트가 적은 구조는 이렇습니다. AI가 반복적인 취약 구간(리포트 표현으로 brittle layer)을 처리하고, 사람이 전략과 판단을 담당합니다. 자가치유 로케이터와 시각적 회귀는 실용 단계에 도달했다고 평가됐습니다. 다만 리포트는 커버리지 상승의 원인을 특정 기능이 아니라 이 하이브리드 구조 자체로 돌렸습니다.

한 가지 밝혀 둘 것이 있습니다. 이 조사를 발행한 Wopee.io는 비교 대상 5종에 자기 제품을 포함하고 있습니다. 조사 주체와 피조사 대상이 겹치는 구조라는 점은 감안하고 읽었습니다.

역할을 나눠 놓고 보면 두 숫자가 같은 표에 있는 게 이상하지 않습니다.

누가	리포트가 실용 단계로 평가한 것	여전히 사람에게 남은 것
AI 에이전트	자가치유 로케이터, 시각적 회귀 (리포트가 실용 단계로 적은 것은 이 둘)	—
사람	—	전략 수립과 판단, 결과 검토 게이트

왼쪽 열이 늘어나면 커버리지 숫자가 올라갑니다. 오른쪽 열은 줄지 않습니다. 그러니 "자동화율이 두 배가 됐는데 왜 일이 안 줄지" 하는 감각과 커버리지 51~60%라는 발표가 동시에 성립합니다. 만족도 2.2점은 그 간격에 붙은 점수라고 읽었습니다.

무감독 운영을 지원한 도구가 5종 중 0개였습니다

같은 조사에서 "완전한 E2E QA 대체"는 아직 과장(hype)이라고 적혔고, 어떤 도구도 완전 무감독 운영을 실제로 지원하지 않는 것으로 확인됐습니다. 인간 검토 게이트는 5종 전부에서 필수로 유지되고 있었습니다.

그러면 2.2점이라는 숫자의 의미가 달라집니다. 이것은 "도구가 나쁘다"가 아니라 "완전 자율이라는 기대치에 대해 2.2점"입니다. 도구가 실제로 파는 것과 사람들이 기대한 것 사이의 간격이 2.2점으로 찍힌 셈입니다.

커버리지 숫자를 품질로 읽으면 안 되는 이유는 따로 있습니다

여기서 제 경험을 하나 붙입니다. 저는 줄 커버리지 100%인 모듈에 뮤테이션 테스트를 돌렸다가 뮤턴트 99개 중 35개가 살아남는 것을 봤습니다. 커버리지는 "그 줄을 지나갔다"만 보장하지 "그 줄이 틀렸을 때 잡아낸다"는 보장하지 않습니다.

AI 에이전트가 올린 51~60%도 같은 성질의 숫자입니다. 무엇을 지나갔는지는 늘어났지만, 무엇을 잡아내는지는 그 숫자에 들어 있지 않습니다. 리포트가 인간 검토 게이트를 필수로 적은 이유가 이것과 무관하지 않다고 봅니다.

3. 도구 지형은 "에이전트 친화형"으로 갈라졌습니다

리포트는 이번 주 도구 소식을 두 갈래로 정리했습니다. 기존 강자는 에이전트 연동과 프로토콜 표준화로 가고, 신생 도구는 자연어로 진입장벽을 낮추는 쪽입니다.

릴리스 두 건

Selenium 4.49가 2026년 9월 9일 나왔습니다. .NET·Python·JavaScript·Ruby 전반의 BiDi 관련 버그 수정과 필드명 공통 스키마 통일이 중심이고, Grid의 파일명 공백 처리 500 오류 수정, Selenium Manager의 Windows WOW64 아키텍처 감지 개선, Linux arm64 지원 확대가 함께 들어갔습니다. 새 기능보다 인프라 안정성 쪽입니다.

Playwright는 리포트 기준 1.59가 최신이고 "에이전틱 릴리스"로 불립니다. bug0.com 리뷰가 짚은 것은 두 가지입니다.

// 리포트에 실린 Playwright 1.59의 에이전트 연동 API 두 가지입니다.
// 아래 시그니처는 리포트 표기에 await만 붙인 것이며, 제가 실행해 확인한 값이 아닙니다.

// 여러 클라이언트가 브라우저 세션 하나를 공유합니다
await browser.bind();

// LLM에 최적화된 형태로 접근성 스냅샷을 뽑습니다
await page.ariaSnapshot({ mode: 'ai' });

두 API 모두 "사람이 아니라 에이전트가 브라우저를 읽는 상황"을 전제로 만들어졌습니다. 세션 공유는 에이전트와 사람이 같은 브라우저를 번갈아 보는 구도이고, mode: 'ai' 스냅샷은 모델이 화면을 이해하기 좋은 형태로 접근성 트리를 내주는 것입니다.

우리 팀 기준으로 읽은 비교표

리포트가 도입 난이도·유지보수 비용·학습곡선으로 정리한 표에서 비고 열을 빼고 옮겼습니다. QA 4~6명·자동화 초기 단계라는 조건에서 제 판단을 맨 오른쪽에 붙였습니다.

도구	도입 난이도	유지보수 비용	학습곡선	4~6인 팀 기준 판단
Selenium	상 (인프라 직접 구축)	상 (로케이터 취약)	상 (WebDriver 개념·언어별 바인딩)	기존 자산이 있으면 유지. 신규로 고를 이유는 약함
Playwright	중 (auto-wait·내장 트레이스)	중 (UI 변경엔 여전히 취약)	중 (직관적 API)	신규 스위트의 기본값
저코드·AI 에이전트형 (mabl, Momentic 등)	하~중 (SaaS 온보딩)	중~하 (자가치유 로케이터)	하 (비개발 인력도 접근)	소규모 파일럿까지. 락인과 사용량 과금을 먼저 계산
자연어 기반 실험 도구 (Vibium AI 등)	하 (자연어 설명만으로)	중 (실증 데이터 부족)	최하	도입이 아니라 모니터링 대상

Vibium AI는 Selenium 창시자 Jason Huggins가 만든 도구이고 "의도 기반 테스트(Intent-Based Testing)"를 표방합니다. cloudqa.io 비교 분석은 결정론적 리포팅과 엔터프라이즈 인프라가 아직 없는 실험 단계로 평가했습니다. 결정론적 리포팅이 없으면 CI 게이트로 쓰기 어렵다고 봤는데, 이건 리포트의 평가가 아니라 제 판단입니다. 어느 쪽이든 지금 검토할 대상은 아닙니다.

버전 확인은 이 네 줄이면 끝납니다

릴리스가 났다고 당장 올릴 일은 아닙니다. 다만 우리가 지금 몇 버전에 있는지는 알고 있어야 판단이 됩니다.

# 지금 붙어 있는 버전과 최신 배포 버전을 나란히 봅니다
# Selenium (Python) — index 서브커맨드는 pip 버전에 따라 없을 수 있습니다
pip show selenium | grep -i '^Version'
pip index versions selenium

# Playwright (Node) — 설치본과 레지스트리 최신본을 각각 읽습니다
npx playwright --version
npm view @playwright/test version

이 네 줄로 나온 값과 위 릴리스 날짜를 대조해서, 차이가 마이너 한두 단계면 월 1회 정기 패치 사이클에 얹으면 됩니다. 이번 Selenium 4.49는 긴급 대응이 필요한 변경이 아니라고 리포트도 같은 판단을 적었습니다.

4. 같은 주에 함께 나온 나머지

도구 말고도 세 영역이 리포트에 있었습니다. 우리 팀이 이번 주에 움직일 일은 아니지만, 방향은 같은 곳을 가리킵니다.

영역	리포트가 적은 것	출처
자격 체계	ISTQB가 CT-AI v2.0 실라버스를 정식 승인(GA). v1.0은 단계적 폐지 절차	ISTQB
자격 체계	CT-GenAI가 프롬프트 엔지니어링·환각·데이터 프라이버시 리스크 관리를 정규 커리큘럼에 포함	ISTQB 보도자료
급여	AI/ML 테스팅 20~30%, 보안 15~25%, 성능 10~20%, Playwright 10~15% 프리미엄	QASkills.sh 급여 가이드 2026
조직	조직의 절반 가까이가 QA 인력을 애자일 팀에 직접 배치 중	World Quality Report 2025-26
역할	QA가 "실행자"에서 "AI 산출물에 대한 책임 계층"으로 이동	Tricentis

자격증을 지금 따라는 말로 읽지 않았습니다

CT-AI v2.0과 CT-GenAI가 정식화된 것은 사실이고, 커리큘럼에 프롬프트 검증과 환각 확인 절차가 들어간 것도 사실입니다. 그런데 4~6인 팀에서 전원이 자격을 따는 것은 비용이 맞지 않습니다.

저는 실라버스의 목차만 가져다 내부 체크리스트로 쓰는 쪽을 봅니다. AI가 만든 테스트를 리뷰할 때 무엇을 봐야 하는지에 대해 남이 정리한 목록이 있으면, 그것을 우리 리뷰 템플릿에 옮기는 데는 자격 취득이 필요 없습니다.

급여 수치는 채용 협상보다 1:1에 쓰는 편이 낫습니다

QASkills.sh의 급여 가이드는 표본 수가 리포트에 적혀 있지 않고, 통화·지역 기준도 명시되지 않았습니다. 그래서 이 숫자를 "우리 팀 연봉이 얼마여야 한다"의 근거로 쓰기는 어렵습니다.

다만 방향은 참고할 만합니다. 자동화와 매뉴얼의 격차가 벌어지고 AI 검증 역량에 프리미엄이 붙는다는 흐름은, 이번 리포트 안에서는 QASkills.sh 가이드 하나가 말하고 있습니다. 출처가 하나라는 점은 감안해야 합니다. 팀원 개인의 학습 우선순위를 같이 정할 때 배경 자료로 올려 두는 정도가 적당합니다.

5. 파일럿을 스모크 한 칸으로 좁힌 근거

저는 이번 주 리포트를 읽고 도구를 바꾸지 않기로 했습니다. 대신 AI 에이전트를 붙일 자리 한 칸만 정했습니다.

이유는 2절의 숫자입니다. 5종 전부가 인간 검토 게이트를 필수로 두고 있다면, 에이전트를 붙여서 줄어드는 것은 "테스트를 만드는 시간"이지 "결과를 보는 시간"이 아닙니다. 그러면 검토 부하가 가장 낮은 자리부터 붙여야 계산이 맞습니다. 회귀 스모크가 그 자리입니다. 케이스가 정형이고, 실패했을 때 원인이 좁고, 틀려도 릴리스를 막지 않는 구간이거든요.

반대로 볼 여지도 있습니다. 스모크는 이미 안정적이라 에이전트를 붙여도 얻는 게 적다는 반론이 가능합니다. 그래도 저는 여기서 시작하는 쪽을 택합니다. 파일럿의 목적이 시간 절약이 아니라 검토 게이트가 실제로 몇 건을 받아 내는지 세어 보는 것이기 때문입니다. 그 숫자를 모르면 다음 칸으로 넓힐지 말지 판단할 근거가 없습니다.

무엇을 셀 것인가

무엇을 돌릴지 고르는 문제는 에이전트를 붙이기 전에도 있었습니다. 저는 변경분만 골라 돌리는 방식을 직접 붙여 보고 실행이 25.1%로 줄어드는 것과 동시에 놓치는 변경 4종이 생기는 것을 봤습니다. 선택 기준을 바꾸면 반드시 어딘가에 구멍이 생깁니다.

에이전트도 같습니다. 그래서 파일럿에서 셀 값을 미리 정해 뒀습니다.

[ AI 에이전트 파일럿 — 이번 주에 정할 것 ]

□ 붙일 구간 하나만 적는다 (회귀 스모크 / UI 회귀 중 택 1)
□ 그 구간의 현재 케이스 수와 주당 실행 횟수를 센다   ← 비교 기준선
□ 사람 검토 게이트를 누가 언제 보는지 이름과 요일로 적는다
□ 주당 검토 건수 상한을 정한다 (넘으면 파일럿 범위를 줄인다)
□ 에이전트가 만든 케이스의 리뷰 체크 항목 3개를 적는다
     - 무엇을 단언하는 케이스인지 한 문장으로 말할 수 있는가
     - 실패했을 때 원인이 케이스 이름에서 읽히는가
     - 로케이터가 자가치유로 바뀌었을 때 알림이 오는가
□ 종료 조건을 적는다 (4주 뒤 검토 건수가 상한을 넘으면 중단)
□ 벤더 락인 관련: 케이스를 우리 저장소로 내보낼 수 있는지 먼저 확인한다

마지막 줄이 제일 중요하다고 봅니다. SaaS 저코드 도구는 온보딩이 쉬운 대신 만든 자산이 그쪽에 남거든요. 파일럿을 접기로 했을 때 케이스를 들고 나올 수 있는지는 시작 전에 확인해야 합니다.

체크리스트 일곱 줄 중에 도구 이름은 하나도 없습니다. 일부러 그렇게 적었는데요, 이번 주 리포트에서 우리 규모가 실제로 움직일 수 있는 것은 도구 선택이 아니라 범위 설정이었기 때문입니다. 도구는 나중에 바꿔도 늦지 않습니다. 반면 검토 게이트를 누가 언제 보는지를 정하지 않은 채 파일럿을 시작하면, 4주 뒤에 남는 것은 "괜찮았던 것 같다"는 인상뿐이고요.

기준선을 미리 세어 두는 일도 같은 이유입니다. 지금 회귀 스모크가 주당 몇 번 돌고 케이스가 몇 개인지를 적어 두지 않으면, 나중에 늘어난 숫자를 봐도 그게 에이전트 덕인지 그사이 기능이 늘어서인지 가릴 수가 없습니다. 이 두 값은 오늘 30분이면 셉니다.

이 글의 한계

리포트 원문의 수치를 1차 소스로 재확인하지 않았습니다. Wopee.io 조사의 표본 수, QASkills.sh 급여 가이드의 조사 방법과 통화 기준, World Quality Report의 응답 조직 수는 리포트에 적혀 있지 않았고 저도 확인하지 않았습니다. 그래서 본문의 모든 수치는 "누가 발표한 값"까지만 보증합니다.

Playwright 1.59의 릴리스일은 리포트에 2026-04-17로 적혀 있어 그대로 옮겼습니다. 이번 주 소식이 아니라 그 시점 최신 버전을 정리한 항목으로 읽었습니다.

도구를 고르기 전에 파이프라인 시간부터 봐야 하는 이유는 CI 30분 문제를 먼저 다룬 글에 적었습니다. AI 코딩 에이전트의 리팩터링 신뢰도는 벤치마크 통과율을 따져 본 글에서 살펴봤습니다.