새 결제 화면을 배포하기 전, 팀이 확인해야 할 일은 버튼이 눌리는지만 보는 데 그치지 않습니다. 할인 조건이 유지되는지, 이전 단계에서 입력한 값이 다음 화면에도 이어지는지, 실패 뒤 사용자가 다시 시도할 수 있는지까지 봐야 합니다. 이때 AI QA 에이전트는 사람이 반복하기 어려운 흐름을 넓게 탐색하는 후보가 될 수 있습니다.
그러나 AI QA 에이전트를 기존 자동화 테스트의 대체재로 구매하면 판단이 흐려집니다. 자연어 지시를 해석하고 화면을 조작하는 에이전트는 예상 경로 밖의 UI 변화와 긴 사용자 여정을 다룰 가능성을 보여주지만, 테스트 누락, 결함 판정, 긴 단계의 상호작용 안정성은 아직 별도로 검증해야 할 문제입니다.
도입 질문은 “AI가 테스트를 얼마나 잘하나”가 아니라 다음에 가깝습니다.
우리 제품에서 사람이 반복하기 어려운 탐색은 어디까지 맡기고, 배포를 막는 판정은 어떤 증거와 승인 절차로 통제할 것인가.
맡길 테스트와 남겨둘 테스트를 먼저 나눈다
AI QA 에이전트가 가장 먼저 가치가 날 수 있는 영역은 화면 구조나 표현 방식이 자주 바뀌지만, 사용자가 달성해야 하는 목적은 비교적 분명한 흐름입니다. 예를 들어 회원가입, 상품 검색, 장바구니 진입, 설정 변경처럼 여러 화면을 거치며 사용자가 행동하는 경로가 여기에 들어갑니다.
이 영역에서는 자연어로 흐름을 적고, 에이전트가 실제 브라우저에서 이를 수행하게 할 수 있습니다. 일부 제품은 제품 용어와 기대 동작을 지식 기반으로 입력하거나, 실행 중 바뀐 UI에서 컨트롤을 다시 찾는 기능을 제공합니다. UI 선택자에 강하게 묶인 기존 E2E 테스트가 자주 깨지는 팀이라면 검토할 만한 차이입니다.
반대로 아래 영역은 AI 에이전트에게 단독 판정을 맡기기보다 기존 테스트와 명시적 검증을 유지하는 편이 낫습니다.
- 금액, 세금, 할인, 잔액처럼 계산 결과가 정확히 일치해야 하는 기능
- 권한, 접근 제어, 데이터 삭제처럼 잘못 통과하면 피해가 큰 기능
- API 계약, 데이터 변환, 비동기 처리처럼 화면에 보이지 않는 상태가 중요한 기능
- 법적 고지, 계약 조건, 고객 약속처럼 문구나 시점 자체가 판정 기준인 기능
- 배포 차단 여부를 정하는 핵심 회귀 테스트
이런 기능은 단위 테스트, 통합 테스트, API 테스트처럼 입력과 기대 결과를 명시적으로 비교하는 방식을 중심에 둬야 합니다. AI 에이전트는 그 위에서 실제 사용자 흐름이 끊기지 않는지 추가로 확인하는 역할이 적합합니다.
“로그인 성공”이 아니라 전제와 결과를 적어야 한다
AI 에이전트 테스트에서 가장 흔한 착시는 화면이 다음 페이지로 이동했으니 성공이라고 보는 것입니다. 하지만 사용자 흐름에는 이전 단계의 상태가 남아 있어야 하거나, 특정 조건에서만 다음 행동이 가능해야 하는 경우가 많습니다.
예를 들어 “관리자가 사용자를 초대한다”는 테스트는 다음처럼 쪼개야 합니다.
- 전제 조건: 초대 권한을 가진 관리자가 존재하고, 초대 대상 이메일은 아직 등록되지 않았다.
- 행동: 관리자가 초대 화면에서 이메일과 역할을 입력해 발송한다.
- 기대 결과: 초대 상태가 기록되고, 해당 사용자는 지정된 역할로 가입 경로를 시작할 수 있다.
- 금지 결과: 권한 없는 사용자가 같은 행동을 수행하거나, 이미 등록된 계정에 중복 초대가 생성되면 안 된다.
이렇게 전제 조건과 사후 조건을 적지 않으면 에이전트는 화면상의 그럴듯한 변화를 성공으로 해석할 수 있습니다. 반대로 정상 흐름을 오류로 분류할 가능성도 남습니다. 자연어 요구사항만으로 애매한 판정을 줄이기 어렵다는 점은, 에이전트가 결함을 발견했다고 보고할 때 특히 중요합니다.
CTO나 개발 리드는 테스트 문서에서 다음 두 질문이 답되는지 확인할 수 있습니다.
- 이 테스트가 시작되기 전에 데이터, 권한, 외부 연동 상태는 무엇이어야 하는가
- 테스트가 끝난 뒤 화면뿐 아니라 저장된 상태, 권한, 후속 행동 가능 여부 중 무엇을 확인해야 하는가
이 답이 없는 흐름은 AI에 넘기기 전에 테스트 자체의 판정 기준부터 보강해야 합니다.
자동 복구는 편의 기능이지 무조건 통과 신호가 아니다
AI QA 제품은 UI가 바뀐 뒤에도 버튼이나 입력 항목을 다시 찾아 실행을 계속하거나, 테스트 파일 수정을 제안하는 기능을 내세우기도 합니다. 이는 작은 화면 변경 때문에 테스트 유지 비용이 커지는 팀에 도움이 될 수 있습니다.
다만 복구가 성공했다는 사실과 제품이 올바르게 동작했다는 사실은 다릅니다.
예를 들어 “저장” 버튼의 위치나 이름이 바뀌었을 때 에이전트가 새 버튼을 찾아 흐름을 이어갈 수 있습니다. 그러나 그 버튼이 이전과 같은 데이터를 저장하는지, 저장 뒤 권한이나 상태가 올바르게 유지되는지는 별도 확인이 필요합니다. 화면 변경이 테스트의 의도를 바꿔 버렸다면, 자동 복구는 결함을 숨기는 방향으로 작동할 수도 있습니다.
따라서 공급업체 평가에서는 다음을 분리해 물어야 합니다.
- 실행 중 복구는 어떤 조건에서 발생하는가
- 복구한 행동과 원래 행동의 차이를 사람이 확인할 수 있는가
- 테스트 정의 변경은 자동 반영되는가, 검토 후 승인되는가
- 변경된 테스트가 어느 코드 변경과 연결되는가
- 복구가 발생한 테스트를 배포 차단 기준에서 다르게 처리할 수 있는가
권장할 만한 경계는 명확합니다. 실행을 계속하기 위한 복구는 허용하되, 테스트 정의를 바꾸는 복구는 검토와 승인 뒤 반영한다는 원칙입니다. 그래야 테스트가 제품 변화를 따라가는지, 제품 결함을 놓치도록 스스로 기준을 낮추는지 구분할 수 있습니다.
구매 전에는 정확도보다 실패 기록을 먼저 본다
AI QA 에이전트의 데모는 대체로 성공한 흐름을 보여줍니다. vendor selection 단계에서는 성공 화면보다 실패가 남는 방식을 확인해야 합니다. 에이전트 기반 E2E 테스트는 테스트 완전성, 결함 탐지, 긴 상호작용의 신뢰성을 각각 평가해야 한다는 연구 결과도 나와 있습니다. 한 항목이 좋아도 나머지가 약하면 배포 판단에는 부족합니다.
파일럿에서는 실제 제품의 대표 흐름을 세 부류로 나누어 검증하는 편이 좋습니다.
| 검증 부류 | 확인할 질문 | 통과 기준의 예 |
|---|---|---|
| 안정된 핵심 흐름 | 같은 조건에서 반복 실행해도 같은 결론이 나는가 | 실패 원인이 제품 결함, 테스트 환경, 에이전트 판단 중 어디인지 구분된다 |
| 최근 변경 흐름 | UI와 동작이 바뀐 뒤 의도한 기능을 확인하는가 | 변경 전후 행동 차이와 판정 근거를 검토할 수 있다 |
| 의도적으로 깨뜨린 흐름 | 실제 결함을 놓치지 않고 찾아내는가 | 정상 상황을 결함으로 과도하게 보고하지 않으며, 결함 위치를 재현 가능하게 남긴다 |
여기서 중요한 것은 공급업체가 제시하는 전체 성공률 하나가 아닙니다. 팀의 제품과 데이터, 로그인 방식, 권한 모델, 외부 연동 조건에서 어떤 실패가 반복되는지 봐야 합니다.
특히 다음 신호가 보이면 배포 차단 용도는 보류하는 편이 안전합니다.
- 같은 테스트가 같은 빌드에서 서로 다른 결론을 낸다.
- 실패 보고에 실행 단계, 화면 기록, 추적 정보가 충분히 남지 않는다.
- 에이전트가 무엇을 기대했고 무엇을 실제로 관찰했는지 설명할 수 없다.
- 긴 흐름에서 중간 단계가 누락되거나 이전 상태를 잊는다.
- 테스트가 통과했지만 사람이 재현하면 요구사항과 다른 행동이 나온다.
증거물과 승인 경계가 도입 비용을 결정한다
AI QA 에이전트를 CI에 연결하면 모든 PR에서 실행할 수 있다는 기대가 생깁니다. 하지만 실행 횟수를 늘리는 일과 신뢰할 수 있는 배포 판단을 만드는 일은 별개입니다. PR마다 실행하려면 실패를 빨리 분류하고, 누가 어떤 근거로 재실행 또는 수정을 결정하는지 정해야 합니다.
최소한 아래 증거는 테스트 결과와 함께 남기는 편이 좋습니다.
- 실행한 단계와 각 단계의 기대 조건
- 실패 시점의 화면 캡처 또는 녹화
- 브라우저 동작과 네트워크, 콘솔 등 재현에 필요한 추적 정보
- 사용한 테스트 데이터와 권한 상태
- 자동 복구 또는 테스트 정의 변경이 있었는지에 대한 기록
- 실패 분류와 담당자의 최종 판단
승인 경계도 위험도에 따라 다르게 두면 됩니다. 낮은 위험의 탐색성 테스트는 발견 목록을 생성하고 담당자가 우선순위를 정하는 방식으로 시작할 수 있습니다. 반면 결제, 권한, 고객 데이터처럼 통과 여부가 배포에 직접 영향을 주는 흐름은 사람이 증거를 확인한 뒤에만 차단 또는 통과 결론을 내리도록 두는 편이 맞습니다.
AI QA 에이전트의 구매 결정은 “몇 개의 테스트를 자동화할 수 있는가”보다 “실패한 결과를 팀이 얼마나 빨리 믿거나 기각할 수 있는가”에서 갈립니다. 먼저 현재 회귀 테스트 중 UI 변경 때문에 유지가 어려운 흐름 하나와, 결함이면 즉시 배포를 멈춰야 하는 흐름 하나를 골라 보십시오. 전자에서는 탐색과 복구 능력을, 후자에서는 판정 조건과 증거, 승인 절차를 검증하면 도입 범위가 훨씬 선명해집니다.
