AI가 UI 테스트의 '성배'라고요? 환각(Hallucination)이 만드는 치명적 신뢰의 붕괴

30년 UI 테스트 역사가 증명하는 결정론적 코드의 가치와, Gemini 시대에 우리가 경계해야 할 확률적 추론의 함정

최근 RAG(검색 증강 생성) 시스템만 도입하면 환각 현상이 싹 사라질 거라 믿는 분들이 많더라고요. 하지만 실제 데이터를 보면 이야기가 좀 다릅니다. 도메인 복잡도에 따라 2%에서 최대 25%의 환각률이 나타나고, 심지어 전문 법률 AI 도구들조차 17%에서 33% 확률로 거짓 정보를 만들어내고 있거든요 [4, 5]. 전문적인 영역일수록 ‘그럴듯한 거짓말’의 위험은 더 커진다는 뜻이죠.

여기서 우리가 꼭 짚고 넘어가야 할 핵심이 있습니다. AI 기반 테스트 도구가 생산성을 획기적으로 높여주는 건 맞지만, 테스트의 본질인 ‘결정론적 검증’을 ‘확률적 추측’으로 대체하는 순간, QA의 신뢰성은 완전히 무너진다는 점입니다.

UI 테스트 30년, 우리는 무엇을 자동화하려 했는가

사실 UI 테스트의 본질은 아주 단순해요. 사용자가 앱에서 버튼을 누르고 메뉴를 이동하는 인터랙션을 시뮬레이션해서, “내가 기대한 결과가 실제로 나왔는가”를 비교하는 것이죠 [2].

우리가 오랫동안 써온 Selenium, Cypress, Playwright 같은 도구들의 공통점은 바로 ‘결정론적 실행’에 있습니다. 코드로 “A 버튼을 누르고 B 텍스트가 보이면 Pass”라고 명시해두면, 실행할 때마다 동일한 경로를 통해 일관된 결과를 보장하니까요. 최근의 Playwright 같은 도구들은 auto-wait 기능을 넣어 테스트가 중간에 튀는 ‘Flaky test’ 현상을 줄이는 방향으로 발전해 왔습니다 [2].

물론 고충이 없었던 건 아니에요. UI가 조금만 바뀌어도 셀렉터가 깨져서 테스트 코드를 일일이 수정해야 하는 유지보수 비용, 그리고 그 방대한 테스트 케이스를 짜는 공수는 모든 QA 엔지니어의 고질적인 페인 포인트였죠.

Gemini와 AI 테스트 도구가 약속하는 ‘성배(Holy Grail)’

그래서 등장한 게 AI 테스트 도구들입니다. 어떤 이들은 이를 두고 “Gemini-powered testing promises the Holy Grail”이라고 표현하기도 하죠 [1]. (Gemini 기반 테스트가 UI 테스트의 궁극적인 해결책인 ‘성배’를 약속한다는 의미입니다.)

이제는 복잡한 코드를 짜지 않아도 자연어 프롬프트만으로 테스트 케이스를 만들고 코드를 자동 생성할 수 있게 됐습니다. 특히 Android Studio에 통합된 Gemini는 개발자가 자연어로 질문하면 코드를 생성해주고 관련 리소스를 찾아주는 훌륭한 코딩 어시스턴트 역할을 합니다 [14].

더 나아가 ‘에이전트 기반 테스트(Agentic Testing)’ 개념까지 나오고 있어요. AI 에이전트가 프롬프트를 읽고 E2E 테스트 스위트를 생성한 뒤, 이를 CI 환경에서 결정론적으로 실행할 수 있는 Playwright나 Appium 코드로 출력해주는 방식입니다 [6]. 비기술직 이해관계자들도 읽을 수 있는 키워드 기반 구문으로 테스트를 관리할 수 있다는 점은 정말 매력적이죠.

예를 들어, AI 에이전트에게 “로그인 페이지에서 잘못된 비밀번호를 입력했을 때 에러 메시지가 뜨는지 확인하는 테스트를 짜줘”라고 요청하면 다음과 같은 결정론적 코드를 뱉어내는 식입니다.

// AI 에이전트가 생성한 Playwright 기반 결정론적 테스트 코드 예시
import { test, expect } from '@playwright/test';

test('로그인 실패 시 에러 메시지 검증', async ({ page }) => {
  await page.goto('https://example.com/login'); // 로그인 페이지 접속
  
  await page.fill('#username', 'test_user'); // 사용자 아이디 입력
  await page.fill('#password', 'wrong_password'); // 의도적으로 틀린 비밀번호 입력
  await page.click('#login-button'); // 로그인 버튼 클릭

  // 결정론적 검증: 특정 ID를 가진 요소에 정확한 텍스트가 있는지 확인
  const errorMessage = page.locator('#error-msg');
  await expect(errorMessage).toBeVisible(); // 메시지가 화면에 보여야 함
  await expect(errorMessage).toHaveText('비밀번호가 일치하지 않습니다.'); // 정확한 문구 검증
});

이 설정의 핵심은 AI가 ‘실행’을 직접 하는 게 아니라, 우리가 검증할 수 있는 ‘코드’를 생성했다는 점입니다. 이렇게 생성된 코드는 Git으로 관리되고 CI에서 동일하게 작동하므로 신뢰할 수 있습니다.

확률적 추론의 함정: 테스트 도구가 ‘환각’을 일으킬 때

그런데 여기서 위험한 지점이 생깁니다. LLM의 작동 원리를 생각해보면 쉬워요. LLM은 정답을 찾는 계산기가 아니라, 통계적으로 가장 확률이 높은 다음 토큰을 예측하는 시스템이거든요 [3].

문제는 AI가 ‘그럴듯하지만 완전히 틀린’ 검증 로직을 생성했을 때 발생합니다. “hallucinations are not ‘glitches’ in the traditional sense; they are a byproduct of the way transformer-based architectures predict tokens”라는 말이 정확합니다 [5]. (환각은 전통적인 의미의 일시적 오류(글리치)가 아니라, 트랜스포머 기반 아키텍처가 토큰을 예측하는 방식에서 오는 필연적인 부산물이라는 뜻입니다.)

전통적인 버그는 기능을 막거나 에러를 띄워 우리가 금방 알아챌 수 있게 합니다. 하지만 AI의 환각은 다릅니다. 잘못된 검증 결과를 내놓으면서도 아주 ‘확신에 찬’ 말투로 “테스트 통과했습니다”라고 보고하죠. RAG를 도입해 외부 지식을 주입해도, 이 확률적 추론의 특성상 환각을 완전히 제거하는 것은 불가능에 가깝습니다 [4].

만약 테스트 도구가 환각을 일으켜 잘못된 검증 로직을 짰는데 그걸 그대로 믿었다면 어떻게 될까요? 그 비용은 일반적인 소프트웨어 버그보다 훨씬 큽니다. 브랜드 신뢰도를 즉각적으로 파괴할 수 있는 치명적인 결과로 이어지기 때문이죠 [5].

경계해야 할 안티패턴: AI에게 ‘판단’까지 맡기는 것

제가 현장에서 본 가장 위험한 안티패턴은 AI가 생성한 코드를 리뷰 없이 그대로 CI/CD 파이프라인에 태우는 겁니다. 혹은 결정론적인 코드 없이 AI의 실시간 판단(Probabilistic Judgment)에만 의존해 테스트를 실행하는 경우죠.

특히 ‘LLM-as-a-Judge’, 즉 AI가 생성한 결과를 다른 AI가 체크하게 만드는 루프에 빠지는 경우가 많습니다. 하지만 법률 AI 도구들의 사례에서 보듯, AI가 스스로를 체크하게 하는 방식은 평가 파이프라인에서 인기 있을지 몰라도 매우 위험할 수 있습니다 [4]. 결국 같은 확률적 모델의 한계 속에 갇혀 서로의 오류를 정당화해줄 가능성이 크거든요.

도메인 지식 없이 AI가 제시하는 ‘테스트 커버리지’ 수치에만 매몰되는 것도 경계해야 합니다. 최고의 AI 테스트 도구는 단순히 테스트를 대신 해주는 도구가 아니라, 우리가 소유하고 검증할 수 있는 ‘결정론적인 코드’를 생성해주는 도구여야 합니다 [6].

AI 만능론의 한계

물론 업계에서는 RAG를 통해 환각을 거의 완벽하게 제거할 수 있다고 주장하는 곳들이 있습니다 [4]. 또한 AI 에이전트가 스스로 테스트를 수정하고 유지보수하므로 인간의 리뷰가 더 이상 필요 없다는 관점도 존재하죠 [6].

하지만 이건 너무 낙관적인 생각입니다. AI가 코드를 수정했다면, 그 수정이 비즈니스 요구사항을 정확히 반영했는지 판단하는 것은 결국 도메인 전문가인 인간의 몫입니다. AI는 ‘어떻게(How)’ 짤지는 잘 알지만, ‘무엇을(What)’ 검증해야 하는지에 대한 최종 책임은 질 수 없으니까요.

핵심 요약

• 신뢰의 근거: AI는 작성 속도를 높여주지만, 검증의 신뢰성은 여전히 ‘결정론적 코드’에서 나옵니다.
• 환각의 본질: 환각은 LLM의 구조적 특성입니다. 버그처럼 완전히 제거하는 것은 현재로선 불가능합니다.
• 위험한 안티패턴: AI가 생성한 테스트 결과를 비판 없이 신뢰하고 CI에 그대로 투입하는 행위입니다.
• 도구 선택 기준: ‘우리가 소유할 수 있는 코드를 생성하는가’와 ‘AI 내부 환경에서만 실행하고 결과만 알려주는가’를 반드시 구분하세요.
• 검증 체계의 변화: 전통적인 이진 단언(Pass/Fail)이 어려운 확률적 결과물에 대해서는 허용 오차 기반의 검증 체계를 고민해봐야 합니다 [5].

30년 전 SQA 로봇부터 지금의 Gemini까지, 도구는 계속 변해왔습니다. 하지만 ‘신뢰할 수 있는 검증’이라는 본질은 단 한 번도 변한 적이 없더라고요. AI를 아주 똑똑하고 손 빠른 조수로 부리시되, 최종 승인 도장을 찍는 결정권자는 반드시 여러분 자신이 되어야 합니다.

---

참고 자료 (References)

1. [gillesbaatsen.medium.com] From SQA Robot to Android Studio Journeys: 30 Years of UI Testing (and Why AI Isn’t Ready Yet) — https://gillesbaatsen.medium.com/from-sqa-robot-to-android-studio-journeys-30-years-of-ui-testing-and-why-ai-isnt-ready-yet-14eee2c468ee?source=rss——artificial_intelligence-5 2. [ranorex.com] 9 Best Automated UI Testing Tools: Top Platforms Compared – Ranorex — https://www.ranorex.com/blog/automated-ui-testing-tools 3. [misinforeview.hks.harvard.edu] New sources of inaccuracy? A conceptual framework for studying AI hallucinations — https://misinforeview.hks.harvard.edu/article/new-sources-of-inaccuracy-a-conceptual-framework-for-studying-ai-hallucinations 4. [dho.stanford.edu] Free? Assessing the Reliability of Leading AI Legal Research Tools — https://dho.stanford.edu/wp-content/uploads/Legal_RAG_Hallucinations.pdf 5. [bugraptors.com] LLM Testing & Hallucination Detection: The Complete Guide — https://www.bugraptors.com/blog/llm-output-evaluation-hallucination-detection 6. [qawolf.com] The 12 Best AI Testing Tools in 2026 | QA Wolf — https://www.qawolf.com/blog/the-12-best-ai-testing-tools-in-2026 14. [developers.google.com] Android 스튜디오의 Gemini | Gemini Code Assist | Google for Developers — https://developers.google.com/gemini-code-assist/docs/android-studio-overview?hl=ko

관련 글 추천

• https://infobuza.com/2026/06/05/20260605-anp0cf/
• https://infobuza.com/2026/06/05/20260605-jgvphc/

FAQ

RAG(검색 증강 생성) 시스템을 도입하면 AI의 환각 현상을 완전히 없앨 수 있나요?

아니요, 실제 데이터에 따르면 도메인 복잡도에 따라 2%에서 최대 25%의 환각률이 나타나며, 확률적 추론의 특성상 환각을 완전히 제거하는 것은 불가능에 가깝습니다.

UI 테스트에서 '결정론적 실행'이란 무엇이며 왜 중요한가요?

결정론적 실행은 코드로 명시된 경로를 통해 실행할 때마다 동일하고 일관된 결과를 보장하는 것을 의미합니다. 이는 테스트의 본질인 검증의 신뢰성을 유지하기 위해 필수적입니다.

AI 기반 테스트 도구를 사용할 때 가장 위험한 안티패턴은 무엇인가요?

AI가 생성한 코드를 리뷰 없이 그대로 CI/CD 파이프라인에 적용하거나, 결정론적 코드 없이 AI의 실시간 확률적 판단에만 의존해 테스트를 실행하는 것이 가장 위험합니다.

에이전트 기반 테스트(Agentic Testing)는 어떤 방식으로 작동하나요?

AI 에이전트가 프롬프트를 읽고 E2E 테스트 스위트를 생성한 뒤, 이를 Playwright나 Appium과 같이 CI 환경에서 결정론적으로 실행할 수 있는 코드로 출력하는 방식입니다.

AI 테스트 도구를 선택할 때 어떤 기준을 고려해야 하나요?

단순히 AI 내부 환경에서 실행하고 결과만 알려주는 도구인지, 아니면 사용자가 직접 소유하고 검증할 수 있는 '결정론적인 코드'를 생성해주는 도구인지를 반드시 구분하여 선택해야 합니다.