QA에 AI를 구현하는 방법 (2026): 실질적인 프레임워크
요약
QA 프로세스에 AI를 효과적으로 도입하기 위한 실질적인 프레임워크를 제안합니다. AI는 테스트 생성, 셀렉터 복구, 앱 탐색 등의 작업을 수행하되, 최종 결과의 검증은 AI가 수정할 수 없는 고정된 검증(Oracle)이 담당해야 함을 강조합니다.
핵심 포인트
- AI는 작업을 수행하고, 고정된 검증(Fixed Check)이 결과를 결정해야 함
- AI가 자신의 출력물을 스스로 채점하게 해서는 안 됨
- 테스트 작성, 깨진 테스트 수정, 앱 탐색, 실패 로그 분석에 AI 활용 가능
- AI가 영향을 미칠 수 없는 독립적인 '오라클(Oracle)' 유지가 핵심
핵심 요약 (Key takeaways)
QA에 AI를 구현하려면, AI가 작업을 수행하게 하고 고정된 검증(fixed check)이 결과를 결정하게 하세요. AI를 사용하여 테스트를 생성하고, 깨진 셀렉터(selectors)를 복구하며, 앱을 탐색하게 하세요. AI가 자신의 출력물을 스스로 채점하게 해서는 절대 안 됩니다. AI가 변경할 수 없는 독립적인 검증을 추가하고, 반복 가능한 결과인지 테스트하며, 에이전트(agent)가 요청한 작업만 수행했는지 테스트하세요.
"QA에서의 AI"가 실제로 의미하는 것
QA에서의 AI란 소프트웨어 테스트를 돕기 위해 AI 모델을 사용하는 것을 의미합니다. 그것이 핵심 아이디어입니다. 모델은 테스트 케이스(test cases)를 작성하고, 깨진 테스트를 수정하며, 사용자처럼 앱을 클릭하며 탐색하거나, 실패를 읽고 원인을 추측할 수 있습니다.
이것이 AI가 테스트를 대체한다는 의미는 아닙니다. AI가 테스터가 과거에 수동으로 수행하던 작업의 일부를 수행한다는 의미입니다. 판단은 여전히 여러분의 몫입니다.
저는 소프트웨어 테스터로 생업을 이어가고 있습니다. QA에서 AI를 통해 승리하는 팀들은 모두 동일한 선을 긋습니다. AI는 작업을 수행합니다. 인간과 고정된 검증이 그 작업이 훌륭한지 결정합니다.
안전을 유지하는 단 하나의 규칙
이 가이드의 나머지 부분이 의존하는 규칙은 다음과 같습니다.
AI가 작업을 수행하게 하세요. AI가 자신의 작업을 스스로 판단하게 해서는 절대 안 됩니다.
여러분의 로그인을 테스트하는 AI 에이전트(agent)를 상상해 보세요. 에이전트가 여기저기 클릭합니다. 그리고 '통과(green)'라고 보고합니다. 모두가 안심합니다. 하지만 에이전트가 무엇이 "통과"인지를 스스로 결정했습니다. 만약 에이전트가 너무 관대하다면, 깨진 페이지를 통과시켜 버릴 것입니다. 이제 여러분은 상단에 초록색 체크 표시가 붙은 채 버그를 배포하게 된 것입니다.
자신의 작업을 스스로 채점하는 AI는 테스트가 아닙니다. 그것은 의견(opinion)일 뿐입니다.
따라서 AI에게는 탐색할 여지를 주되, AI가 건드릴 수 없는 한 가지를 유지해야 합니다. 바로 고정된 검증(fixed check)입니다. 이미 알고 있는 정답, 즉 실제 결과에 대한 하드 어서트(hard assert, 강력하게 실패를 알리는 검증)입니다. 에이전트는 경로를 찾고, 고정된 검증이 통과 또는 실패를 말합니다.
테스트에서 이 고정된 정답은 다음과 같은 이름으로 불립니다: 오라클 (oracle). 오라클은 테스트 대상 시스템이 영향을 미칠 수 없는 부분입니다. 오라클을 AI의 손이 닿지 않는 곳에 두면, QA에서의 대부분의 AI 관련 리스크는 사라집니다.
QA에서 AI가 도움이 되는 부분 (4가지 유용한 역할)
이 네 가지 역할은 오늘날 AI가 성과를 내는 부분입니다.
- 테스트 작성 (Writing tests). 모델에게 페이지나 사용자 스토리(user story)를 지정합니다. 그러면 지치고 피곤한 사람이 놓칠 수 있는 엣지 케이스(edge cases)를 포함하여 테스트 케이스를 초안으로 작성해 줍니다. 사용자가 검토하고 좋은 것만 남깁니다.
- 깨진 테스트 수정 (Fixing broken tests). 버튼이 이동해서 테스트가 깨졌습니다. AI는 새로운 셀렉터(selector, 테스트가 버튼을 찾는 방법)를 찾아내고 수정을 제안할 수 있습니다. 이것은 대부분의 팀에게 가장 큰 시간 절약 요소입니다.
- 앱 탐색 (Exploring the app). AI 에이전트가 호기심 많은 사용자처럼 앱을 돌아다니며 무엇이 잘못되었는지 보고합니다. 아무도 테스트를 작성하지 않은 버그를 찾는 데 아주 좋습니다.
- 실패 로그 읽기 (Reading failures). 테스트가 실패했을 때, AI는 로그와 트레이스(trace)를 읽고 발생할 가능성이 높은 원인을 제안할 수 있습니다. 빨간색의 벽을 확인해야 할 짧은 목록으로 바꿔줍니다.
네 가지 경우 모두 AI가 제안하고, 사용자가 검토하고 수정된 것을 적용합니다.
QA에서 AI가 위치하는 곳 (4가지 함정)
이 부분은 대부분의 가이드가 건너뛰는 부분입니다. QA에서의 AI는 네 가지 방식으로 실패할 수 있습니다. 각각에 대비해야 합니다.
- 깨진 것을 통과시킴. 너무 관대한 에이전트가 깨진 페이지를 '괜찮다'고 판단합니다. 해결책: 에이전트가 움직일 수 없는 독립적인 오라클(oracle)을 만듭니다.
- 재현성이 없음 (Not repeatable). 같은 입력값이 지금은 통과했다가 10분 뒤에는 실패합니다. 해결책: 동일한 입력을 두 번 실행하고 답변의 형태를 비교합니다.
- 너무 많은 것을 함 (Too much). 한 가지를 요청했는데, 에이전트가 설정값을 변경하거나 메시지를 보내는 등 다른 행동을 합니다. 해결책: 어떤 것에 손댔는지 범위를 확인하는 검사(scope check)입니다.
- 변경될 수 있는 모델에 의존함. 사용 중인 도구의 모델이 업데이트되거나, 심지어 오프라인 상태가 되어 테스트 자체가 변화합니다. 해결책: 모델 버전을 고정하고 폴백(fallback)을 유지합니다.
마지막 것은 이론적인 것이 아닙니다. 2026년 6월에 광범위하게 사용되던 모델이 하룻밤 사이에 서비스에서 제외되었습니다. 모델 버전을 고정한 팀은 한 줄의 코드로 폴백으로 전환했습니다. 그렇지 않은 팀은 빌드가 깨졌을 때야 알게 되었습니다.
작동 예시: 움직일 수 없는 오라클을 가진 AI 에이전트
여기에 코드 패턴이 있습니다. AI 에이전트가 회의실을 예약합니다. 그리고 세 개의 고정된 검사(fixed checks)가 실제로 잘 되었는지 판단합니다. 에이전트는 스스로를 평가하지 않습니다.
import { test, expect } from '@playwright/test';
import { Stagehand } from '@browserbasehq/stagehand';
...
세 가지 검사(checks)를 다시 읽어보십시오. 에이전트 스스로의 "예약했습니다"라는 말은 결코 신뢰하지 않습니다. 데이터베이스가 오라클 (Oracle, 진실의 근원)입니다. 기간 검사(duration check)는 부주의한 예약을 잡아냅니다. 범위 검사(scope check)는 에이전트가 추가적인 작업을 수행하는 것을 잡아냅니다. (getBookingFromDb와 getChangesExcept는 직접 작성한 헬퍼 (helper) 함수입니다. 이들은 에이전트의 말이 아닌 실제 상태를 읽습니다.)
반복 가능한 결과의 함정 (repeatable-result trap)을 피하려면, 동일한 프롬프트 (prompt)를 두 번 실행하고 비교하십시오:
test('same request, same result', async () => {
const a = await runBooking('Book room B for 2pm tomorrow, 30 minutes');
const b = await runBooking('Book room B for 2pm tomorrow, 30 minutes');
...
모델은 매번 답변의 표현을 다르게 하는 것은 허용됩니다. 하지만 다른 방을 예약하는 것은 허용되지 않습니다.
모든 AI 기능에 필요한 3가지 테스트
사용자에게 AI 기능을 출시한다면, 이 세 가지 테스트가 새벽 2시에 당신을 괴롭힐 실패 사례들을 잡아낼 것입니다. 대부분의 팀은 첫 번째로 쉬운 테스트(
이 네 가지를 수행한다면, 당신은 신뢰할 수 있는 QA 내 AI를 보유하게 될 것입니다. AI는 더 많은 작업을 수행하고, 당신은 판단력을 유지합니다. 고정된 체크(fixed checks)는 모두가 정직하게 임하도록 유지해 줍니다.
그것이 업무의 전부입니다: "AI가 통과했다고 말하는 것"과 "올바른 이유로 통과한 것" 사이의 간극을 메우는 일 말입니다.
Anton Gulin은 AI QA Architect(AI QA 아키텍트)로, LinkedIn에서 이 직함을 처음으로 주장한 사람입니다. 그는 AI 에이전트와 인간 엔지니어가 품질을 위해 협업하는 AI 기반 테스트 자동화 시스템을 구축합니다. 전 Apple SDET (Apple.com / Apple Card 출시 전 테스트 담당). anton.qa 또는 LinkedIn에서 그를 찾을 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기