e2e로 AI 웹·모바일 E2E 테스트를 조합합니다

웹·모바일 앱의 UI 변경 때문에 긴 선택자 기반 테스트를 자주 고치는 개발자는 e2e로 자연어 목표와 정확한 결과 검사를 조합해 볼 수 있습니다. 화면에서 목표를 수행하는 과정은 에이전트에 맡기고, 성공 조건은 코드로 남기는 방식입니다. 기존 테스트 전체를 옮기기보다는 화면 구성이 바뀌는 사용자 흐름 하나부터 도입 효과를 살펴보는 데 맞습니다. 아래 내용은 2026년 10월 5일 공식 문서와 e2e@0.17.0 릴리스를 확인한 결과입니다. (프로젝트 저장소)

한눈에 보기

E2E는 사용자가 앱을 열고 가입하거나 결제를 마치는 것처럼 여러 화면을 거치는 흐름을 끝까지 검사하는 방식입니다. 이 글의 기능 설명은 프로젝트 문서에 근거하며, 테스트 유지 시간이나 모델 비용의 절감률을 측정한 결과는 포함하지 않습니다. (README, 릴리스 기록)

어떤 작업에 도움이 됩니까?

예를 들어 체험판 가입 화면에서 입력란의 위치와 중간 안내 화면이 자주 바뀌지만, 사용자의 목표인 ‘이름과 이메일로 가입하고 환영 화면을 본다’는 유지되는 경우를 생각할 수 있습니다. 고정 테스트는 버튼·입력란마다 접근할 선택자를 작성합니다. e2e에서는 가입이라는 목표를 한 번의 agent.act로 표현하고, 에이전트가 그때의 화면에서 동작을 고르게 합니다. 마지막 환영 문구와 계정 상태는 별도로 검사합니다. (Quickstart)

이는 선택자를 모두 없애는 접근보다 변동하는 과정과 고정된 결과를 나눠 표현하는 접근으로 이해하면 쉽습니다. 선택자(locator)는 이름·역할 등으로 화면 요소를 찾는 코드입니다. 환영 문구처럼 의미를 판단할 부분에는 모델 검사를 쓰고, trial 상태처럼 정확한 문자열이 중요한 부분에는 locator assertion을 둡니다. 결제 금액이나 권한 등 사업 규칙도 고정된 기대값을 검사하는 쪽으로 설계할 수 있습니다.

반대로 버튼 이름과 경로가 안정적이고 기존 Playwright 테스트가 이미 간결하다면, 자연어 단계에 모델 설정과 실패 분석 절차를 더할 이유는 작습니다. 화면 변화가 거의 없는 로그인 검사 하나를 운영하는 팀보다, 가입·설정 변경 등 여러 화면의 경로를 계속 유지하는 팀이 비교할 여지가 큽니다. 이 구분은 문서의 기능을 실제 작업 조건에 대입한 도입 판단입니다.

기존 도구와 무엇이 다릅니까?

Codex나 Claude Code에 ‘체험판 가입 테스트를 작성하고 실패를 고쳐 달라’고 요청하는 작업과 e2e의 역할은 서로 이어집니다. 코딩 에이전트는 테스트 파일을 만들고 실행 결과를 읽는 작성 도구로 쓰고, e2e는 작성된 테스트가 실행될 때 앱을 조작하고 결과를 검사하는 러너로 씁니다. 공식 Quickstart도 Codex·Claude Code·Cursor 등의 코딩 에이전트에 설치와 테스트 작성을 맡기는 경로를 안내합니다. (코딩 에이전트 설정 절차)

README는 뒤의 assertion으로 검증된 에이전트 동작을 기록해 다음 실행에서 재생한다고 설명합니다. 다만 ‘재생’은 실제 앱 상태와 기록의 조건이 맞는 경우에 적용됩니다. 모델의 의미 판단을 쓰는 agent.assert까지 포함한 전체 실행이 언제나 모델 호출 없이 끝난다는 보장으로 읽기보다, 반복 동작이 어느 정도 재사용되는지 따로 관찰하는 것이 도입 평가에 도움이 됩니다. (재생 구조 설명)

어떻게 사용합니까?

입력은 테스트 대상 웹 앱의 주소, 가입 목표, 테스트용 이름과 이메일, 기대하는 환영 상태입니다. 공식 문서의 예시는 체험판 가입이며 결제까지 이어지는 체크아웃 전체를 시험한 사례는 아닙니다. 아래 코드는 Quickstart의 웹 예시를 기준으로 합니다. 실제 앱의 상태 요소와 문구에 맞춰 마지막 검사를 조정합니다. (원본 예제)

import { test } from '@e2e-dev/web';
import { expect } from 'e2e';

test('a visitor signs up for a trial', async ({ app, agent, screen }) => {
  await app.open('/');
  await agent.act('sign up for a free trial as {name} with email {email}', {
    params: { name: 'Ada Lovelace', email: 'ada@example.test' },
  });
  await agent.assert('the welcome screen greets Ada by name');
  await expect(screen.getByRole('status')).toContainText('trial');
});

절차는 세 단계로 나뉩니다. 먼저 app.open('/')으로 설정된 앱의 시작 화면을 엽니다. 다음에는 params가 이름과 이메일을 목표 문장의 자리표시자에 넣고, 에이전트가 가입을 진행합니다. 마지막에는 환영 화면의 의미와 상태 문자열을 각각 검사합니다. 기대 결과는 두 검사가 모두 통과한 실행 기록이며, 실패하면 어떤 단계와 조건에서 멈췄는지 보고서로 살펴봅니다. 첫 예제 실행은 .e2e/report.json을 남깁니다.

실제 프로젝트에서는 테스트용 계정과 테스트 데이터를 마련한 뒤 진행합니다. 가입은 앱 데이터를 바꾸는 동작이므로 운영 사용자 계정과 섞지 않는 환경이 적합합니다. 첫 실행 이후 같은 앱 상태에서 다시 실행해 동작이 재생되는지 살펴보고, 실패했을 때는 가입 동작의 실패와 환영 상태 검사의 실패를 나눠 읽습니다. 앱을 고친 뒤에도 목표가 같다면 그대로 시험할 수 있지만, 결과 문구나 상태 규칙이 바뀌면 정확한 값 검사도 함께 조정합니다.

설치와 이용 조건

공식 시작 명령은 앱 프로젝트 디렉터리에서 다음과 같습니다. 이 명령은 버전을 고정하지 않으며, 이 글에서 검토한 기준 버전은 e2e@0.17.0입니다. 생성된 의존성 버전과 잠금 파일을 확인해 팀의 실행 환경을 기록합니다. (Quickstart)

npx e2e init
npx e2e run

첫 명령의 대화형 설정에서 Web (Playwright) 또는 Mobile (iOS/Android), 모델 제공자 또는 None을 고릅니다. 설정 마법사는 config와 예제 테스트를 작성하고 의존성을 추가하며 코딩 에이전트 설정도 제안합니다. 첫 예제는 앱이 열리는지 검사하므로 모델 로그인 없이 시작할 수 있습니다. 실행 과정에서는 브라우저를 내려받거나 시뮬레이터·에뮬레이터를 시작합니다.

자동 설정용 npx e2e init --yes는 다른 영향도 있습니다. 공식 안내에 따르면 웹 config, 예제, e2e 스킬과 MCP 설정을 작성하되 그 시점에는 의존성을 설치하지 않습니다. 이후 코딩 에이전트가 대상 앱과 모델을 정하고 설치를 진행하는 절차입니다. 파일 생성과 패키지 설치, 제공자 로그인 승인을 한 단계로 생각하지 않고 각각 확인하면 자신의 프로젝트에서 무엇이 바뀌는지 파악하기 쉽습니다. (자동 설정 프롬프트)

Node.js 조건은 24.8 이상 또는 Node.js 22 계열의 22.22.3 이상입니다. Windows는 공식 안내에 따라 WSL 안에서 실행합니다. 모바일은 iOS용 Xcode와 시뮬레이터 런타임, 또는 Android SDK와 에뮬레이터를 추가합니다. 문서는 macOS에서 iOS를, 그 밖의 환경에서 Android를 마법사의 기본 선택으로 설명합니다. Windows의 일반 PowerShell에서 iOS 시뮬레이터를 실행하는 경로를 제공한다고 추정하지 않습니다.

자연어 단계를 넣은 뒤에는 선택한 제공자 설정을 연결하고 다음 명령으로 해당 테스트를 실행합니다. --headed는 웹 실행 화면을 보는 옵션이고 --no-cache는 기록된 동작 재생을 건너뛰는 옵션입니다. (실행 명령과 옵션)

npx e2e run tests/agent.e2e.ts

사용하는 계정은 모델 제공자 로그인과 테스트 대상 앱 로그인을 구분합니다. 외부 모델 연결에는 해당 서비스 접근과 네트워크가 필요하며 앱 실행·데이터 변경 권한도 작업 범위에 포함됩니다. 한국어 목표의 성공률과 한국에서 각 구독 로그인 경로를 이용하는 조건은 이번 조사에서 미확인입니다. README는 CLI가 익명 사용 정보를 보낸다고 설명하며, 테스트·앱 내용과 인증 정보는 텔레메트리에 포함하지 않는다고 명시합니다. 끄는 공식 명령은 npx e2e telemetry disable입니다. 모델 입력의 외부 전송 여부와 제공자 정책은 텔레메트리 설정과 별도로 검토합니다. (텔레메트리 안내)

비용과 라이선스

모델 없는 테스트, 기존 구독 연결, API 키 연결, 로컬 모델 연결로 비용 구조가 나뉩니다. 에이전트 단계가 없는 실행은 모델 호출을 하지 않습니다. Quickstart에 적힌 구독 로그인은 ChatGPT Plus·Pro, GitHub Copilot, OpenCode Console, SuperGrok·X Premium+ 네 가지입니다. Claude 구독은 이 목록에 없으므로 Claude 모델을 쓰려면 Anthropic API 키처럼 모델 문서의 제공자 설정을 거칩니다. 로컬 모델은 Ollama나 Responses API를 제공하는 자체 서버를 연결하는 예가 문서에 있습니다. 외부 API를 쓰면 입력·출력과 호출 횟수에 따라 제공자가 과금하고, 구독을 연결하면 그 요금제의 사용 한도와 이용 조건을 따릅니다. 로컬 모델은 제공자 API 호출을 피하는 선택지이며 실행 장비와 모델 서버 관리 비용이 남습니다. (모델 설정, 구독 연결 안내)

자체 설치형 패키지의 별도 사용료는 확인한 공식 자료에서 찾지 못했습니다. README에 소개된 Kernel 호스팅 브라우저와 EAS 호스팅 시뮬레이터의 가격·무료 범위는 미확인입니다. 따라서 팀 비용은 모델 호출, 브라우저·모바일 실행 인프라, 테스트 데이터와 유지 작업을 함께 놓고 비교합니다. 캐시가 재생될 때와 다시 기록할 때의 호출량을 나눠 기록하면 ‘테스트가 통과했다’는 결과와 실제 지출을 연결할 수 있습니다.

저장소 라이선스는 Apache-2.0입니다. 상업적 이용과 수정·재배포를 허용하며, 재배포 시 라이선스 사본, 변경 표시, 관련 권리 고지와 NOTICE의 귀속 표시를 유지하는 조건이 있습니다. 프로젝트 상표 사용 권한과 모델 제공자의 서비스 조건은 이 코드 라이선스와 별개입니다. 저장소의 NOTICE에는 TesterArmy의 저작권·개발 귀속 표시가 있습니다. (LICENSE, NOTICE)

한계와 유지보수

활발한 릴리스는 변경 대응을 볼 수 있는 근거입니다. 2026년 10월 4일의 0.17.0 릴리스는 재생 캐시 검사를 바꾸면서 기존 기록을 업그레이드 후 첫 실행에 다시 기록한다고 설명합니다. web 0.12.0도 Playwright 의존성 방식과 브라우저 설치 명령을 바꿉니다. README는 1.0 이전 개발 중이며 minor 버전 사이에도 API와 config가 바뀔 수 있다고 안내합니다. 버전 업데이트 때 패키지 변경뿐 아니라 테스트 실행 비용과 CI 설정까지 확인하는 작업이 생깁니다. (릴리스 기록, 개발 상태)

web 0.12.0 릴리스의 CI 브라우저 설치 명령은 npx @e2e-dev/web install chromium --with-deps입니다. 엔진이 playwright-core를 정확한 버전으로 고정해 직접 의존하도록 바뀐 데 따른 명령입니다. 릴리스는 playwright 패키지를 의존성에서 지우라고 안내하면서, 앱이 자체 테스트에 Playwright를 쓰는 경우는 예외로 둡니다. @playwright/test를 쓰는 앱은 자기 사본을 유지하며, 두 버전이 같을 때만 브라우저 캐시를 함께 씁니다. 따라서 기존 Playwright 테스트가 있는 프로젝트는 패키지를 일괄 제거하지 말고 어느 테스트가 어떤 패키지를 쓰는지 먼저 확인합니다. (web 0.12.0 변경 내용)

모바일에서는 공개 이슈 #842가 중요한 점검 사례입니다. 보고자는 e2e@0.16.0, @e2e-dev/mobile@0.9.1, iOS 27 시뮬레이터에서 같은 화면의 접근성 트리 표현이 달라져 화면 식별자가 흔들리고, 새 설치 뒤 기록된 동작의 재생이 모두 빗나갔다고 적었습니다. 다시 기록해도 해결되지 않았다고 합니다. 테스트 흐름 자체는 성공했지만 재생 대신 다시 동작을 찾은 사례입니다. 보고자가 적은 비용은 기록 실행이 261,807토큰·227초, 바로 이어진 재생 실행이 169,989토큰·218초였고, 다섯 개의 agent.act가 모두 재생되지 않았습니다. 재생이 빗나가면 두 번째 실행도 첫 실행과 비슷한 시간과 모델 사용량을 쓴다는 뜻입니다. 10월 5일 확인 시점에 이 이슈는 열려 있었고 연결된 수정 PR은 없었습니다. 최신 mobile 0.9.2에서 같은 문제가 남는지는 미확인입니다. (보고 환경과 재생 문제)

따라서 모바일 도입 평가는 성공·실패만 집계하는 것보다 새 설치, 앱 재시작, 화면 재진입 뒤에도 기록을 재사용하는지까지 포함하는 것이 유용합니다. 웹에서도 문구가 바뀌거나 결과 화면이 예상과 달라지면 모델 판단과 정확한 값 검사의 경계가 중요해집니다. 저장소가 설명하는 재생 구조를 자기 앱의 유지보수 성과로 바꾸려면 반복 실행 기록이 다음 근거가 됩니다.

확인한 범위

문서 확인: README, Quickstart, 모델 설정, 릴리스 기록, 공개 이슈 #842와 LICENSE·NOTICE를 대조했습니다. 기준 리비전은 2026년 10월 4일 릴리스에 표시된 09733be이며, 공식 문서 사이트와 라이선스의 main 파일은 2026년 10월 5일 열람 내용을 사용합니다. 저장소 전체 코드를 감사하거나 모든 문서를 그 리비전으로 고정해 확인한 범위는 포함하지 않습니다.

직접 실행: 직접 실행하지 않았습니다. 위 가입 코드는 공식 문서 예시이며, 로컬 설치·앱 조작·모델 연결·한국어 입력 시험 결과를 뜻하지 않습니다. OS 조건과 명령은 공식 안내를 옮겼고, 모델 비용·동작 재생률·유지 시간은 측정 전입니다.

도입 판단

특정 상황에 유용합니다. 사용자 목표는 유지되지만 화면 경로가 자주 바뀌는 팀이 자연어 동작과 정확한 assertion을 함께 설계할 때 비교할 가치가 있습니다. 기존 선택자 테스트가 간단하고 안정적이면 그대로 유지하는 선택도 타당합니다. 모바일 재생과 한국어 목표의 안정성까지 기대하는 팀은 자기 환경의 확인을 도입 결정에 포함합니다.

다음 행동은 웹의 체험판 가입 같은 작은 흐름 하나를 고르는 것입니다. 먼저 모델 없는 예제가 열리는지 확인하고, 그다음 자연어 목표 하나와 핵심 상태 검사를 붙입니다. 같은 입력의 반복 실행, UI 변경 후 실행, 실패 보고서 분석에 걸린 시간을 기존 테스트와 나란히 기록합니다. 재생이 빗나가더라도 테스트는 성공할 수 있다는 점을 반영해 모델 호출량도 함께 봅니다. 이 기록이 쌓이면 테스트 범위를 넓힐지 판단할 근거가 생깁니다.

참고한 자료

확인일은 모두 2026년 10월 5일입니다. 아래는 기능·이용 조건의 공식 자료와 재생 문제의 원보고입니다. 이슈 내용은 보고자의 환경에서 관찰한 결과로 읽습니다.

• tester-army/e2e 저장소와 README: 프레임워크 구조, 패키지 역할, 재생·텔레메트리와 개발 상태를 확인합니다.
• Quickstart: 설치 조건, 설정의 영향, 공식 명령·옵션과 체험판 가입 예제를 확인합니다.
• Models: API·구독·로컬 모델의 연결 선택지를 확인합니다.
• Releases: 기준 리비전과 0.17.0·web 0.12.0의 변경 내용을 확인합니다.
• 모바일 화면 식별과 재생 문제 #842: 보고 버전과 새 설치 뒤 재생이 빗나간 조건을 확인합니다.
• LICENSE와 NOTICE: 이용·재배포 조건과 귀속 고지를 확인합니다.