제 피드에는 두 가지 문구가 계속해서 떠돌고 있습니다:

에이전트 기반 테스트 (Agentic testing) 와 AI 기반 테스트 (AI-powered testing).

이 두 용어는 종종 같은 의미인 것처럼 사용되곤 합니다. 하지만 그렇지 않습니다.

그럼 먼저 이 차이점을 분석해 봅시다.

AI 기반 테스트 (AI-powered testing)란 실제로 무엇을 의미하는가?

“AI 기반 테스트 (AI-powered testing)”는 매우 다양한 의미를 가질 수 있습니다.

Playwright, Selenium, Cypress, 또는 여러분의 QA 팀이 계속해서 언급하기를 거부하는 그 어떤 테스트 프레임워크를 위한 테스트를 생성하는 데 AI를 사용하는 것을 의미할 수도 있습니다.

저희 사무실의 QA 팀은 Selenium을 매우 좋아하며 계속해서 이를 밀어붙이고 있습니다.

내부 소식: 제가 여기 있는 동안에는 그런 일이 일어나지 않도록 할 것입니다.

농담은 제쳐두고, AI가 생성한 테스트 코드는 오늘날 AI 기반 테스트의 가장 일반적인 형태일 것입니다.

Claude, Codex, Cursor 또는 다른 코딩 어시스턴트(coding assistant)에게 기능에 대한 설명을 제공하면, AI가 여러분을 위해 테스트 스크립트를 생성해 줍니다.

그 결과물은 여전히 전통적인 코드 기반 테스트입니다.

AI는 단지 그것을 작성하는 데 도움을 주었을 뿐입니다.

AI 기반 테스트는 기존 테스트 스위트(test suite) 주변에 지능을 추가하는 것을 의미할 수도 있습니다.

예를 들어, 여러분은 이미 Playwright나 Selenium 테스트를 보유하고 있을 수 있습니다. 테스트 중 하나가 실패했을 때, AI는 다음 사항을 판단하는 데 도움을 줄 수 있습니다:

• 애플리케이션이 실제로 고장 났는지
• 테스트가 오래되었는지
• 셀렉터(selector)가 변경되었는지
• 실패 원인이 타이밍 문제나 플래키(flaky)한 동작 때문인지
• 사용자 여정(user journey) 자체가 변경되었는지

AI는 또한 로그, 스크린샷, 브라우저 활동 및 실패 메시지를 분석하여 어떤 일이 발생했을 가능성이 높은지 설명할 수 있습니다.

또 다른 버전은 AI 보조 복구(AI-assisted recovery)입니다.

테스트가 특정 단계에서 실패하지만, 시스템이 즉시 중단하는 대신 페이지를 이해하고 계속 진행할 수 있는 다른 유효한 방법을 찾으려고 시도합니다.

이것은 흔히 자가 치유 테스트 자동화 (self-healing test automation) 라고 불립니다.

몇 년 전에는 이를 안정적으로 수행하는 것이 매우 어려웠습니다. 지금도 “자가 치유(self-healing)”는 과장되는 경우가 많지만, 현대적인 브라우저 에이전트(browser agents)와 언어 모델(language models) 덕분에 제한적인 복구가 훨씬 더 실용적으로 변했습니다.

따라서 AI 기반 테스트는 다음과 같은 의미를 가질 수 있습니다:

• 테스트 코드 생성 (Generating test code)
• 테스트 실패 분석 (Analysing test failures)
• 오래된 테스트 업데이트 (Updating outdated tests)
• 깨진 셀렉터로부터의 복구 (Recovering from broken selectors)
• 실패 원인이 제품인지 테스트인지 설명 (Explaining whether a failure came from the product or the test)

에이전트 기반 테스트 (Agentic testing)는 이와는 약간 다릅니다.

에이전트 기반(Agentic) E2E 테스트란 무엇인가?

에이전트 기반 테스트에서는 반드시 테스트 구현을 직접 작성할 필요가 없습니다.

사용자의 여정 (user journey), 예상 결과, 또는 작업을 자연어 (natural language)로 설명하기만 하면 됩니다.

그러면 에이전트는 자신에게 주어진 도구들을 사용하여 애플리케이션을 이해하고 해당 여정을 실행합니다.

웹 애플리케이션의 경우, 이러한 도구들을 통해 에이전트는 다음과 같은 작업을 수행할 수 있습니다:

• 현재 페이지 검사 (Inspect the current page)
• 상호작용 가능한 요소 찾기 (Find interactive elements)
• 버튼 클릭 (Click buttons)
• 양식 채우기 (Fill forms)
• 화면 간 탐색 (Navigate between screens)
• 보이는 콘텐츠 읽기 (Read visible content)
• 예상된 결과가 나타났는지 확인 (Check whether an expected result appeared)
• 작은 UI 변경으로 인해 원래 경로가 차단되었을 때 복구 (Recover when a small UI change blocks the original path)

Android, iOS, 데스크톱 소프트웨어, 또는 어쩌다 테스트해야 하게 된 다른 특이한 것들의 경우, 사용 가능한 도구는 달라질 것입니다.

핵심 아이디어는 동일합니다:

목표를 설명합니다.

에이전트가 이를 완료할 방법을 결정합니다.

이러한 워크플로 (workflow)는 단위 테스트 (unit testing)에는 큰 의미가 없습니다. 단위 테스트는 정밀한 입력, 출력, 단언 (assertions), 그리고 결정론적 동작 (deterministic behaviour)을 요구하기 때문입니다.

하지만 엔드 투 엔드 (end-to-end) 테스트에는 매우 유용할 수 있습니다.

E2E 테스트는 사용자 여정에 관한 것입니다.

사용자가 로그인할 수 있는가?

계정을 생성할 수 있는가?

장바구니에 제품을 담을 수 있는가?

결제를 완료할 수 있는가?

거래를 생성할 수 있는가?

예상된 확인 화면에 도달할 수 있는가?

이것들이 바로 브라우저 에이전트 (browser agent)가 실제 애플리케이션 내부에서 이해하고 시도할 수 있는 작업의 종류입니다.

전통적인 테스트 자동화에서 겪었던 문제

저는 개발자이지, 전담 테스트 자동화 엔지니어는 아닙니다.

테스트를 작성할 수는 있지만, 첫날부터 본격적인 E2E 테스트 스위트 (testing suite)를 구조화하는 최선의 방법을 항상 알고 있는 것은 아닙니다.

이는 아마도 규모가 작은 회사들에서 흔히 발생하는 일일 것입니다.

완전한 QA 자동화 팀을 갖추고 있지 않을 수도 있습니다. 경영진은 여전히 중요한 워크플로우(workflow)가 커버되기를 원하며, 그 책임은 회의 중에 가장 덜 바빠 보이는 개발자에게 돌아갑니다.

그 개발자가 바로 당신일 수도 있습니다.

확실히 저였던 적도 있습니다.

일반적인 해결책은 간단합니다.

Claude, Codex, Cursor 또는 다른 코딩 어시스턴트(coding assistant)를 열고 Playwright 또는 Selenium 테스트를 생성해 달라고 요청하는 것입니다.

생성된 테스트는 합리적으로 보입니다.

실행도 됩니다.

초록색 체크 표시를 받게 됩니다.

그러면 업무를 마칩니다.

그러다 며칠 후, 누군가 UI 변경 사항을 푸시(push)합니다.

새로운 버튼이 나타납니다.

레이블(label) 이름이 변경됩니다.

페이지 구조가 바뀝니다.

작은 화면에서 테이블(table)이 넘치기 시작합니다.

원래의 여정(journey)이 기술적으로는 작동하고 있기 때문에 메인 테스트는 여전히 통과할 수도 있습니다.

하지만 새로운 버튼은 커버되지 않았습니다.

넘치는 테이블도 감지되지 않았습니다.

또는 셀렉터(selector)가 변경되어 테스트가 실패하고, 이제 당신은 애플리케이션이 고장 난 것인지 아니면 단순히 테스트가 구식이 된 것인지 파악해야 하는 상황에 놓입니다.

버튼에 대한 커버리지를 추가하는 것은 충분히 쉽습니다.

하지만 테이블 넘침 현상은 어떻게 할까요?

정확히 그것을 어떻게 스크립트(script)로 작성해야 할까요?

여러 화면 크기에 걸친 레이아웃(layout) 문제를 어떻게 테스트해야 할까요?

해롭지 않은 DOM 변경과 실제 사용자에게 영향을 미치는 회귀(regression)를 어떻게 구분해야 할까요?

제한된 테스트 지식으로는, 저의 첫 번째 본능은 다시 Claude에게 물어보는 것이 될 것입니다.

그러고 나서 처음 생성된 테스트를 수정해 달라고 요청할 것입니다.

그 다음에는 그 수정 사항을 다시 수정할 것입니다.

그 다음에는 또 다른 헬퍼(helper)를 추가할 것입니다.

그 다음에는 셀렉터 전략을 업데이트할 것입니다.

머지않아 테스트 스위트(test suite)는 기술적으로는 내 것이지만, 더 이상 내가 자신 있게 이해하거나 유지보수하고 싶지 않은 AI 생성 코드의 혼합물(soup)이 되어버립니다.

그것이 제가 계속해서 마주쳤던 문제였습니다.

에이전트 기반(agentic) 테스트에 대한 나의 첫 실험

저는 이 과정을 단순화할 수 있을지 궁금해지기 시작했습니다.

AI에게 테스트 코드를 계속 생성하고 수리하도록 요청하는 대신, AI 에이전트(agent)가 사용자 여정(user journey)을 직접 실행한다면 어떻게 될까?

그 질문이 저를 에이전트 기반(agentic) E2E 테스트로 이끌었습니다.

그 아이디어는 진정으로 흥미로워 보였습니다.

모든 클릭, 셀렉터 (selector), 대기 조건 (wait condition), 그리고 폴백 경로 (fallback path)를 일일이 작성하는 대신, 흐름을 설명하기만 하면 에이전트가 브라우저를 조작하게 할 수 있었습니다.

그래서 저는 이 아이디어를 바탕으로 작은 내부 테스트 스위트 (testing suite)를 구축하기 시작했습니다.

그 후 계속해서 만들어 나갔습니다.

아무도 저를 멈춰 세우고 이렇게 묻지 않았습니다.

정확히 무엇을 하려는 건가요?

솔직히 말해서, 저도 몰랐습니다.

처음에는 그저 제 애플리케이션을 테스트할 더 나은 방법을 원했을 뿐이었습니다.

하지만 초기 버전이 작동하기 시작했을 때, 저는 에이전트가 애플리케이션과 상호작용하는 모습을 실시간으로 지켜볼 수 있었습니다.

에이전트는 브라우저를 열고, 페이지를 검사하고, 사용자 여정 (user journey)을 따라 탐색하며, 양식을 채우고, 결정을 내리고, 발생한 일을 보고했습니다.

터미널을 뚫어지게 쳐다보며 통과(pass) 또는 실패(fail) 메시지를 기다리는 대신, 웹 애플리케이션이 실시간으로 테스트되는 모습을 볼 수 있었습니다.

더 중요한 것은, 최종 결과에 유용한 컨텍스트 (context)가 포함되었다는 점입니다.

단순히 다음과 같은 내용이 아니라 말이죠:

테스트 실패.

대신 에이전트가 어디에서 막혔는지, 무엇을 찾을 것으로 예상했는지, 실제로 무엇을 찾았는지, 그리고 무엇이 문제를 일으켰을 수 있는지에 대한 정보가 포함되었습니다.

그 작은 실험은 서서히 에이전트 기반(agentic) E2E 테스트 플랫폼을 위한 MVP (Minimum Viable Product)로 변모했습니다.

그리고 마침내, 그 결과물로 CueTest가 탄생했습니다.

CueTest가 하는 일

CueTest는 웹 애플리케이션을 위한 에이전트 기반(agentic) 엔드 투 엔드 (end-to-end) 테스트 플랫폼입니다.

사용자는 자연어 (natural language)를 사용하여 사용자 여정을 설명합니다.

CueTest는 실제 호스팅된 브라우저 내부의 에이전트를 사용하여, 스테이징 (staging) 또는 배포된 애플리케이션을 대상으로 해당 여정을 실행합니다.

테스트가 실행되는 동안, 브라우저 세션을 지켜보며 실시간 실행 로그를 따라갈 수 있습니다.

에이전트는 다음과 같은 작업을 수행할 수 있습니다:

• 애플리케이션 탐색
• 양식 및 UI 요소와 상호작용
• 예상된 결과 검증
• 제한적인 UI 변경 사항 처리
• 작업 실패 시 제한된 범위 내의 복구 (recovery) 시도
• 애플리케이션이 실제로 막혔을 경우 중단
• 실패 분석 및 유용한 컨텍스트 제공

중요한 차이점은 테스트가 고정된 셀렉터 (selector)의 시퀀스가 아니라, 의도된 사용자 여정을 기반으로 한다는 것입니다.

예를 들어, 원래의 지침이 다음과 같다고 가정해 봅시다:

로그인하고, 수혜자(beneficiaries) 페이지를 열고, 새로운 수혜자를 생성한 뒤, 목록에 나타나는지 확인합니다.

나중에 UI가 변경됩니다.

버튼의 위치가 바뀝니다.

문구가 “수혜자 추가(Add beneficiary)”에서 “수혜자 생성(Create beneficiary)”으로 변경됩니다.

양식(form) 레이아웃이 업데이트됩니다.

사용자 여정(user journey)은 정확히 동일함에도 불구하고, 구현 방식이 바뀌었기 때문에 전통적인 테스트는 실패할 수 있습니다.

에이전트 기반(agentic) 테스트는 단순히 하나의 정확한 시퀀스를 맹목적으로 재현하는 것이 아니라 목표를 달성하려고 시도하기 때문에 여전히 여정을 완료할 수 있습니다.

그렇다고 해서 에이전트가 모든 디자인 변경(redesign)을 마법처럼 견뎌낼 수 있다는 뜻은 아닙니다.

그렇지는 않을 것입니다.

에이전트 기반 테스트는 마법이 아니며, 결코 완벽하게 결정론적(deterministic)이지도 않습니다.

하지만 여정은 그대로 유지되면서 UI만 약간 변경된 경우, 원래의 자연어(natural-language) 테스트는 다시 작성할 필요 없이 계속 작동하는 경우가 많습니다.

여정 자체가 변경되면, 설명(description)을 업데이트하면 됩니다.

거대한 테스트 스크립트를 리팩터링(refactoring)하는 대신, 새로운 흐름을 설명하기만 하면 됩니다.

에이전트 기반 테스트가 Playwright를 대체하는 것은 아닙니다

저는 에이전트 기반 테스트가 Playwright, Selenium, Cypress 또는 기타 코드 기반 테스트 프레임워크를 완전히 대체할 것이라고 생각하지 않습니다.

코드 기반 테스트는 여전히 더 정밀한 제어를 제공합니다.

다음과 같은 상황에서는 코드 기반 테스트가 더 적합합니다:

• 엄격한 단언(assertions)
• 완전히 결정론적인 실행
• 복잡한 픽스처(fixtures)
• 커스텀 설정(setup) 및 해제(teardown) 로직
• 네트워크 요청에 대한 세밀한 제어
• 엔지니어링 워크플로우와의 깊은 통합
• 극도로 예측 가능한 회귀 테스트(regression) 커버리지

에이전트 기반 테스트는 다른 트레이드오프(trade-off)를 제공합니다.

테스트를 더 빠르게 생성하고, 이해하기 쉽게 만들며, 작은 UI 변경에 더 잘 적응할 수 있게 해줍니다.

또한 대규모 자동화 프레임워크를 구축하고 유지 관리할 리소스가 없는 개발자, 수동 QA 테스터, 제품 관리자(PM), 그리고 소규모 팀이 E2E 테스트에 더 쉽게 접근할 수 있도록 해줍니다.

가장 강력한 접근 방식은 아마도 두 가지를 결합하는 형태가 될 것입니다.

최대한의 예측 가능성이 요구되는 핵심 워크플로우에는 코드 기반 테스트를 사용하십시오.

더 넓은 사용자 여정(user journeys), 빠르게 변화하는 기능, 탐색적 커버리지(exploratory coverage), 그리고 전체 스크립트 기반 테스트를 작성하고 유지 관리하는 비용이 너무 큰 시나리오에는 에이전트 기반 테스트(agentic tests)를 사용하십시오.

더 어려운 문제는 신뢰입니다

AI 에이전트가 버튼을 클릭하게 만드는 것은 가장 어려운 부분이 아닙니다.

더 어려운 부분은 팀이 이해하고 신뢰할 수 있는 테스트 시스템을 구축하는 것입니다.

에이전트에게는 경계(boundaries)가 필요합니다.

에이전트는 영원히 재시도해서는 안 됩니다.

에이전트는 자격 증명(credentials)을 지어내서는 안 됩니다.

에이전트는 관련 없는 페이지를 무작위로 탐색해서는 안 됩니다.

에이전트는 단순히 여러 화면을 클릭하며 지나갔다는 이유만으로 테스트를 통과(passed)로 표시해서는 안 됩니다.

에이전트에게는 명확한 목표, 가시적인 실행, 제한된 복구(recovery), 의미 있는 중단 조건, 그리고 유용한 실패 분석(failure analysis)이 필요합니다.

그것이 제가 CueTest와 함께 계속해서 작업하고 있는 부분입니다.

진정한 질문은 AI 에이전트가 브라우저를 조작할 수 있는지 여부가 아닙니다.

그것은 분명히 가능합니다.

더 흥미로운 질문은 다음과 같습니다:

더 빠른 테스트 생성, 더 넓은 커버리지, 그리고 더 낮은 유지 관리 비용을 대가로 팀은 어느 정도의 불확실성을 기꺼이 수용할 용의가 있는가?

다른 개발자들과 QA 엔지니어들이 이를 어떻게 보는지 진심으로 듣고 싶습니다.

여러분의 E2E 테스트 스위트(test suite) 중 어느 부분을 에이전트에게 맡길 수 있겠습니까?

그리고 어느 부분을 항상 코드 기반으로 유지하시겠습니까?

저는 자연어 사용자 여정(natural-language user journeys)으로부터 브라우저 테스트를 생성하고 실행하는 에이전트 기반 E2E 테스트 플랫폼인 CueTest를 구축하고 있습니다.

**cuetest.dev**에서 확인하실 수 있습니다.

이 기사는 CueTest를 구축한 저의 경험을 바탕으로 작성되었습니다. 글을 정리하고 다듬는 데 AI를 사용했지만, 기술적 결정, 제품 경험, 의견, 그리고 의심스러운 Selenium 농담은 모두 저의 것입니다.