tester-army/e2e 실측: 웹만 쓰면 기다리고, 앱까지 쓰면 시험해 볼 만해요 (2026-10)

tester-army/e2e 실측: 웹만 쓰면 기다리고, 앱까지 쓰면 시험해 볼 만해요 (2026-10)

tester-army/e2e가 뜨는데, 우리 팀 테스트 도구를 바꿔야 하나요?

웹과 앱을 함께 테스트하는 팀이라면 tester-army/e2e를 시험 삼아 돌려 볼 만해요. 웹만 다루면서 Playwright(브라우저를 자동으로 조작해 웹 화면을 검사하는 도구)가 이미 안정적으로 돌아간다면 전면 이행은 미뤄도 됩니다. 이유는 아래에서 숫자로 풀게요.

"스타가 6,194개나 된다는데 그냥 써도 되는 거 아닌가요?" "Playwright 잘 쓰고 있는데 굳이 갈아타야 하나요?" 이런 의문이 드는 건 자연스러워요. 스타는 도구를 알게 된 계기일 뿐이고 도입 근거는 따로 확인해야 하니까요.

E2E 테스트(End-to-End, 사용자가 화면에서 하는 일을 처음부터 끝까지 따라 해 보는 테스트)는 서비스가 깨졌는지 알려 주는 안전망이에요. 화면이 바뀔 때마다 고쳐야 해서 유지보수는 무거운 편이죠. e2e는 그 부담을 AI 에이전트(목표를 받으면 스스로 화면을 읽고 조작하는 AI 프로그램)에게 나누겠다는 도구입니다.

2026-10-01 Hacker News(해외 개발자 커뮤니티)에 올라온 제출 제목은 "Next generation E2E testing framework for web and mobile apps"였어요. 이 소개에는 AI 이야기가 없습니다. 실제 저장소는 AI가 중심이에요. "차세대"는 소개 문구에 쓰인 표현이지 외부가 확인한 평가는 아니에요.

이 글은 2026-10-07 기준으로 GitHub API, npm 레지스트리, 공식 문서 49페이지 중 핵심 10페이지를 직접 확인해 답합니다. 정체와 신뢰도, 웹·모바일 통합의 실체, Playwright·Cypress와의 차이, 조용히 깨지는 지점과 비용, 한국어와 보안 순으로 보고 마지막에 도입 판단표와 PoC(본격 도입 전에 작게 돌려 보는 시험) 측정 항목을 드릴게요.

e2e는 정확히 어떤 도구이고, 스타 6,194개는 믿을 만한가요?

한 줄 정의: 목표를 말로 주면 AI가 앱을 움직이는 도구

공식 README(저장소 첫 화면의 소개 문서)는 이렇게 적습니다.

"Describe a goal in natural language and an agent drives the app to reach it."

자연어로 목표를 서술하면 에이전트가 앱을 조작해 거기에 도달한다는 뜻이에요. 결과는 같은 테스트 안에서 로케이터(화면 요소를 찾는 규칙)와 단정문(결과가 맞는지 확인하는 문장)으로 검증해요. 이렇게 AI가 실행 중에 직접 판단하는 방식이 에이전트형 테스트예요.

공식 문서는 선택권을 강조해요. 로케이터와 단정문만으로 쓰거나 자연어 목표에 전부 맡기거나 한 테스트 안에서 섞는 방식을 모두 고를 수 있습니다. README 예제가 구조를 잘 보여줘요.

// tests/checkout.e2e.ts
import { test, expect } from 'e2e';

test('a member upgrades to Pro', async ({ app, agent, screen }) => {
  await app.open('/settings/billing');

  await agent.act('upgrade the workspace to the Pro plan');
  await agent.assert('the invoice preview shows a prorated amount');

  await expect(screen.getByRole('status')).toContainText('Pro');
});

코드가 하는 일은 단순합니다. agent.act는 "Pro 플랜으로 올려 줘" 같은 목표를 시키는 줄이에요. agent.assert는 화면이 맞는지 AI에게 묻는 줄이고요. 마지막 expect(screen.getByRole(...))는 Playwright와 같은, 정해진 규칙으로 하는 판정이에요. 탐색과 조작은 에이전트에 맡기고 최종 판정은 결정론(같은 입력이면 같은 결과가 나오는 방식)으로 하는 설계로 읽혀요.

공식 문서는 "Tests without agent steps need no model"이라고 적어요. AI를 하나도 쓰지 않고 Playwright 대체재로만 쓰는 방식도 가능합니다.

만든 곳은 YC 배치 스타트업이고 저장소는 유료 서비스의 오픈소스 쪽이에요

TesterArmy는 Y Combinator(스타트업 육성 프로그램)의 P26 배치(2026년 배치) 스타트업입니다. GitHub 조직 API에 따르면 조직은 2026-01-04에 만들어졌고 인증 조직이며 공개 저장소는 7개예요. 공동창업자는 Szymon Rybczak(CEO)과 Oskar Kwaśniewski(CTO)이고 폴란드 React Native 커뮤니티 출신이에요.

순서가 중요해요. 회사가 유료 플랫폼으로 Launch HN(Hacker News의 신제품 소개 글)을 올린 날은 2026-06-18이고 오픈소스 저장소가 생긴 날은 2026-07-22예요. README 마지막 절은 이렇게 밝힙니다.

"e2e is built by TesterArmy, the agentic testing platform that runs natural language tests on web and mobile apps, on every pull request or on a schedule."

같은 조직의 다른 저장소 cli(64), scout(60), unbox-ai(47)는 스타가 두 자릿수예요. 라이선스는 Apache-2.0이라 상업적으로 써도 제약이 없어요. 그래도 유지보수의 동기가 회사 사업과 묶여 있다는 점은 도입 리스크로 계산해야 합니다.

스타는 과열이고 설치량과 코드량은 실체예요

GitHub API(2026-10-07 07:11 KST 조회)에 따르면 스타는 6,194개, 포크는 274개, 오픈 이슈는 74개예요. 2026-07-22 생성 이후 77일로 단순 계산하면 하루 평균 약 80개 꼴이죠. 트렌딩 집계에는 2026-10-04~2026-10-05 이틀 동안 하루 1,430스타급이 잡혔어요. 스타 곡선이 발표 한 번에 몰렸다는 얘기예요.

공동창업자 겸 CTO가 2026-10-01에 올린 X 게시물이 그 불씨로 보여요. 게시물은 좋아요 4,879개, 답글 207개를 받았고 본문은 "The agentic testing framework for any app"으로 시작해요. npm 일간 다운로드는 2026-10-01 2,210건에서 2026-10-02 14,582건으로 6.6배 뛰었고 이 시점이 게시 시각(2026-10-01 15:04 UTC)과 겹칩니다. 같은 저장소의 Hacker News 제출 3건은 최대 3포인트, 댓글 1개(2026-10-03)에 그쳤어요. 기술 커뮤니티의 독립 검증은 아직 거의 쌓이지 않았다는 신호예요.

스타 대신 설치량을 봤어요. npm 레지스트리 자료에서 e2e 패키지는 유휴기(2026-06-01~2026-08-31) 일평균 50.8건이었다가 2026-10-05 하루에 33,498건으로 늘었어요. 유휴기 일평균 대비 약 659배예요. 참고로 npm의 e2e 이름 자체는 2014-12-16에 이전 소유자가 만들었고 TesterArmy의 첫 발행 버전 0.1.0은 2026-07-21이에요.

같은 구간(2026-09-28~2026-10-04) 주간 다운로드는 e2e가 60,933건, 웹 엔진 @e2e-dev/web이 49,162건, 모바일 엔진 @e2e-dev/mobile이 12,837건이에요. 메인 패키지 대비 웹 엔진이 약 81%, 모바일 엔진이 약 21%라서 엔진을 붙여 쓰는 사람이 실제로 있다는 신호로 읽을 수 있어요.

코드도 확인했어요. 커밋 669개, 유닛·통합 테스트 파일 324개, TypeScript 약 7.5MB, 공식 문서 49페이지, CI 워크플로(자동 검사 설정) 7개가 나왔습니다. 에이전트 동작의 회귀(예전에 되던 기능이 깨지는 일)를 재는 benchmark.yml과 모바일용 mobile.yml도 돌아가요. 측정 조건이 붙은 공개 성능 수치는 공식 문서, README, 릴리스 노트에서 찾지 못했습니다. "N배 빠르다" 같은 주장은 옮기지 않아요.

반대편 사실도 적어 둘게요. 공개된 레퍼런스 고객 사례는 0건이고 독립 벤치마크도 장문 기술 리뷰도 확인되지 않았습니다. 3자 요약 계정이 전한 X 게시물 조회수는 449K와 1.1M으로 서로 달라서 이 글은 조회수를 쓰지 않아요.

판단은 이래요. 하루 1,430스타는 X 게시물 한 건이 만든 단기 급등이라 스타를 성숙도 지표로 쓰면 안 돼요. 설치량과 코드량은 실제 개발 결과물이에요. "과대 포장된 빈 저장소"는 아니고 검증이 아직 쌓이지 않은 초기 제품이라는 쪽이 정확합니다.

웹과 모바일을 한 프레임워크로 묶었다는 말, 어디까지 사실인가요?

짧게 답하면 API(프로그램을 부르는 방법)는 하나로 묶였지만 기능까지 똑같다는 뜻은 아니에요. 공식 문서에 따르면 구조는 엔진 플러그인 방식이고 테스트는 대상(target)마다 한 번씩 실행돼요.

시뮬레이터와 에뮬레이터는 컴퓨터 안에서 돌리는 가상 스마트폰이고 실기는 실제 기기예요.

오해하기 쉬운 점이 하나 있어요. 웹 엔진은 Playwright를 대체하면서 속에서는 Playwright를 씁니다. 공식 마이그레이션 문서는 "@e2e-dev/web brings its own pinned playwright-core, so your @playwright/test version is yours to keep. Both runners can stay in one project"라고 적어요. 기존 Playwright 테스트를 그대로 두고 파일 패턴(기본값 tests/**/*.e2e.ts)만 나누면 한 프로젝트에 두 러너를 함께 둘 수 있다는 뜻이에요.

모바일 쪽 범위는 이래요.

• iOS 시뮬레이터와 Android 에뮬레이터가 1차 대상이고 물리 실기를 다루는 절도 있어요.
• 앱은 app.bundleId와 app.appPath(.app 번들 또는 .apk)로 지정하고 app.permissions로 권한을 미리 줘서 시스템 권한 팝업을 피해요.
• 모바일 CI(코드를 올릴 때마다 자동으로 검사를 돌리는 환경)는 GitHub Actions, EAS Workflows, Bitrise, Codemagic 문서가 있어요.
• 예제 4종(with-vite, with-next, with-expo, with-swiftui)이 저장소에 있어요. SwiftUI 예제는 React Native 전용이 아니라 네이티브 앱(iOS·Android용으로 직접 만든 앱)도 대상이라는 뜻이에요.

웹과 기기의 실제 차이는 문서가 표로 공개해요.

문서가 스스로 밝힌 기기 제약도 있어요.

• 기기 노드(화면 요소 하나)가 가진 속성은 placeholder 하나뿐이에요.
• iOS에서 React Native 탭(accessibilityRole="tab")의 role이 other로 잡혀서 테스트 ID나 레이블로 찾아야 해요.
• iOS의 평범한 React Native View는 트리에 자식이 없어서 filter({ has })와 그 하위 조회가 전부 매치되지 않아요.
• display: none으로 숨긴 요소는 트리에서 빠져서 toBeAttached가 실패해요.
• Android device.installApp()은 agent-device 0.21.18이 aapt2로 빌드된 APK 매니페스트를 읽지 못해서 ANDROID_HOME 설정이나 app.bundleId 명시가 필요해요.

이렇게 구체적인 제약 목록을 공개하는 건 문서 품질이 좋다는 신호예요. 동시에 모바일 쪽이 웹보다 덜 다듬어졌다는 직접 증거이기도 합니다.

e2e의 고유 영역은 네이티브 모바일이에요. Playwright 공식 문서(emulation)의 모바일은 브라우저 안에서 기기를 흉내 내는 에뮬레이션이고 네이티브 앱을 구동하는 문서는 확인되지 않았습니다. e2e는 agent-device로 iOS 시뮬레이터, Android 에뮬레이터, 실기를 거쳐 모바일 앱 테스트를 웹 테스트와 같은 파일에서 다뤄요. 웹과 네이티브 앱을 둘 다 가진 팀에게만 성립하는 차별점이에요.

Playwright·Cypress와 진짜 다른 점은 AI가 있느냐인가요?

아니에요. Playwright도 AI 에이전트를 기본으로 줍니다. 공식 문서(2026-10-07 조회)는 이렇게 적어요.

Playwright·Cypress와 진짜 다른 점은 AI가 있느냐인가요?

자료: 본문 데이터 · QJC 재구성

"Playwright comes with three Playwright Test Agents out of the box: planner, generator and healer."

planner는 앱을 탐색해 마크다운 테스트 계획을 만들어요. generator는 그 계획을 테스트 파일로 바꾸고 healer는 실패한 테스트를 고쳐요. 실제 차이는 AI의 유무가 아니라 AI가 개입하는 시점입니다.

이 구분이 커뮤니티에서 가장 크게 갈린 지점이에요. 2026-06-18 Launch HN(132포인트, 댓글 69개)에서 사용자 dbbk는 이렇게 물었어요.

"If I'm already using Opus to write the code, surely it would know best what E2E tests to write to be able to verify its own output?"

창업자는 "static tests are very brittle, you rely on selectors, need wait times and can't really test a lot of dynamic content"라고 답했고 다른 사용자가 다시 반박했어요. 합의는 나오지 않았어요. 이 스레드는 유료 플랫폼 공개 글이라 오픈소스 저장소 자체를 평가한 논의는 아니라는 점도 기억해 두세요.

기능 성숙도: 공식 이행표의 빈칸 55건

e2e 공식 Playwright 이행 문서는 기능 186행에 대응 상태를 붙여 놨어요. 전수 집계한 결과는 missing 55행(29.6%), renamed 50행(26.9%), same 43행(23.1%), web only 20행(10.8%), by design 17행(9.1%), exact 1행(0.5%)입니다. missing은 대응 기능이 없다는 뜻이고 renamed는 이름만 달라요. 도입 판단에 걸리는 빈칸은 이거예요.

공식 문서도 "stable Playwright tests can stay where they are"라고 권해요. 잘 돌아가는 Playwright 테스트는 그 자리에 둬도 된다는 말이에요.

Cypress는 코드를 전부 다시 써야 해요

Cypress 이행 문서의 제목은 "Replace Cypress command chains with async tests and keep your data-cy attributes"예요. 테스트 ID 속성(data-cy)은 그대로 쓰지만 명령 체인을 async/await(순서를 직접 적는 방식)로 바꿔야 해서 코드는 전면 재작성입니다. .type('text')는 내용을 바꿔 넣는 .fill('text')로, .type('{enter}')는 .press('Enter')로 바뀌어요. Cypress를 쓰는 팀의 이행 비용은 Playwright 팀보다 커요. Playwright로 갈지 e2e로 갈지부터 정하는 게 순서예요.

생태계 규모는 기준선을 나눠서 봐야 해요

아래는 모두 2026-09-28~2026-10-04 npm 주간 다운로드예요.

Playwright 기준으로는 e2e 60,933건이 @playwright/test 86,157,551건의 0.07%입니다.

Cypress 기준으로는 같은 60,933건이 cypress 7,369,903건의 0.83%예요.

기준선이 서로 달라서 두 비율을 합쳐 읽으면 안 돼요. 어느 쪽이든 질문 답변, 블로그 해설, 사내 노하우가 쌓인 양은 아직 한참 적다고 보고 일정을 잡는 편이 안전해요.

Playwright 테스트를 그대로 옮기면 왜 조용히 깨지고, 비용은 어떻게 불어나나요?

도입 판단에서 실무 가치가 가장 큰 대목이에요. 빈칸(missing)은 시간이 지나면 메워지지만 의도적 차이(by design) 17건은 그렇지 않아요. 공식 문서가 "These differ from Playwright on purpose and will stay that way"라고 못 박았거든요. 테스트가 조용히 다르게 동작하는 지점이 여기에 모여 있습니다.

Playwright 테스트를 그대로 옮기면 왜 조용히 깨지고, 비용은 어떻게 불어나나요?

이미지 출처: playwright.dev

완전일치 쿼리 때문에 부정 단정문이 거짓 통과해요

Playwright의 getByRole 이름, getByLabel, getByPlaceholder, getByText는 대소문자를 무시한 부분일치예요. e2e는 기본이 완전일치에 대소문자 구분이에요. 공식 문서가 드는 이유는 이래요.

"A substring match on Save also hits Save as draft, and a test that passes on the wrong node is worse than one that fails."

엉뚱한 노드에서 통과하는 테스트가 실패하는 테스트보다 나쁘다는 논리예요.

문제는 옮길 때 생겨요. Playwright 테스트를 그대로 가져오면 상당수 쿼리가 0건 매치가 되는데 문서가 이 부작용을 직접 적어요. "A query that misses matches nothing, so a negated assertion on it passes". 쿼리가 아무것도 못 찾으니 '이게 안 보여야 한다'는 부정 단정문(not.toBeVisible() 같은 것)이 그대로 통과해 버려요. 화면에는 그 요소가 멀쩡히 떠 있어도 마찬가지예요. 부분일치가 필요하면 { exact: false }나 정규식을 직접 적어야 해요.

의도적 차이 중 알아 둘 것이 셋 더 있어요.

• 매치가 여럿이면 LOCATOR_AMBIGUOUS 에러예요. Playwright는 첫 매치를 조용히 써요.
• 텍스트는 렌더된 결과(innerText) 기준으로 읽어요. text-transform: uppercase가 걸린 Draft는 'DRAFT'로 읽혀요(Playwright는 'Draft').
• 테스트에 원시 Page 객체를 내주지 않아요. 문서가 드는 이유는 보안이에요. 비밀 값을 입력한 뒤 page.screenshot()을 찍으면 화면 픽셀이 그대로 샌다는 거예요.

기본값도 달라요.

테스트 타임아웃이 4배(30초 대비 120초) 긴 것은 에이전트 스텝에 모델 왕복 시간이 들어가기 때문으로 읽혀요.

비용은 실시간 호출 수와 캐시 적중률이 정해요

공식 캐시 문서에 따르면 비용 구조는 이래요.

• agent.assert, agent.waitFor, agent.extract는 항상 실시간 모델 호출이에요. 캐시되지 않아요.
• agent.act는 뒤의 검증 스텝이 결과를 확인하면 행동이 기록돼서 다음 실행에서는 모델 호출 없이 재생돼요. 컨트롤이나 기대 상태가 어긋나면 그 지점부터 에이전트가 이어받아요.
• 로케이터와 단정문만 쓴 테스트는 모델 비용이 0이에요.
• 재시도는 "Retries always run live"예요. 항상 실시간으로 돌아가요.

재시도 줄이 핵심이에요. CI 기본 재시도가 1회인데 재시도는 항상 실시간으로 돌아가요. 같은 코드인데 어쩌다 실패하는 불안정한 테스트(플레이크)가 많을수록 모델 비용이 불어납니다. 비용을 어림하려면 agent.assert를 몇 개 쓰는지와 캐시 적중률을 봐야 해요. 문서가 보여주는 실행 요약 형식은 이래요.

           AI  4.1k tokens · 2 model calls · anthropic/claude-sonnet-4.5
        Cache  4 replayed · 1 handed off · 1 missed

캐시에는 함정이 하나 있어요. 캐시 적격성은 뒤에 오는 검증 스텝이 그 행동의 효과를 확인했는지에 달려 있어요. 단정문이 약하면 잘못된 경로가 캐시에 굳을 수 있습니다. 공식 문서도 같은 위험을 스스로 적어요. "an outcome already on screen before the actions that should produce it proves nothing". agent.act 뒤에 붙이는 단정문의 품질이 곧 캐시의 신뢰도예요.

한국어 환경과 데이터 반출은 어디까지 확인된 건가요?

한국어는 공식 근거가 0건이에요

공식 문서 49페이지 중 핵심 10페이지를 단어 경계 기준으로 검색했어요. korean, 한국, 한글은 0건이었어요. IME(한글처럼 글자를 조합해 입력하는 방식을 처리하는 입력기), input method, composition event도 0건이에요. CJK와 non-ascii도 0건이고요. locale은 2건이 나오는데 모두 web({ locale, timezoneId }) 설정 매핑이에요.

확인된 사실은 이래요.

• web({ locale })과 web({ timezoneId })로 브라우저의 언어와 시간대를 정할 수 있어요. Playwright 설정이 이름만 바뀌어 넘어왔어요.
• 키를 하나씩 치는 pressSequentially는 Playwright와 같게 지원돼요. 문서는 "keystrokes through the platform keyboard"라고 적어서 한글 조합 입력 검증에 쓸 가능성이 있어요.
• keyboard.down, keyboard.up, keyboard.insertText는 missing이라 조합 이벤트를 낮은 층에서 다루는 Playwright 패턴은 못 써요.
• fill()은 값을 직접 바꿔 넣는 방식이라 Playwright처럼 IME 조합 과정을 거치지 않아요.

문서로 확인되지 않아 PoC에서 직접 봐야 하는 항목은 네 가지예요.

1. 한글 조합 입력 상태에서 agent.act가 입력 필드를 제대로 다루는지.
2. 에이전트가 받는 접근성 트리(화면을 역할·이름·텍스트로 정리한 목록)에 한글 레이블이 정확히 들어가는지, 모델이 한국어 UI를 영어 UI만큼 안정적으로 판정하는지.
3. 완전일치 규칙이 한국어에서 어떻게 작동하는지. 한국어에는 대소문자가 없어 그 위험은 낮지만 조사와 공백, <br>이 공백으로 바뀌는 규칙의 영향은 실측해야 해요.
4. 모바일에서 iOS·Android 한글 키보드 입력. 기기 노드가 placeholder 속성 하나뿐이라는 제약과 겹쳐 한국어 앱에서 더 불리할 수 있어요.

앱 화면이 외부 모델로 나가요, 막을 방법도 있어요

에이전트 스텝은 앱 화면을 모델에 보내요. 한국 기업 도입에서 1차로 걸리는 지점이에요. 공식 보안 문서가 전송 내용을 표로 공개합니다.

완화 장치도 문서에 있어요.

• 비밀번호는 문자열 값이 없는 Secret 타입이라 모델이 값을 못 봐요. 보안 필드는 value=<secure>로 바뀌어요.
• 세션은 실행 단위로 AES-256-GCM으로 암호화되고 키는 메모리에만 있어요. .auth/user.json 같은 디스크 캐시가 없어요.
• 런타임은 모델 출력을 코드, 셀렉터, 셸 명령으로 평가하지 않아요. file:, data:, javascript: 스킴 이동은 POLICY_DENIED로 막혀요.
• 문서가 "Where redaction stops"(가리기가 통하지 않는 지점) 절을 따로 두고 한계를 스스로 밝혀요.

모델은 BYOM(Bring Your Own Model, 쓸 AI 모델을 직접 골라 연결하는 방식)이에요. models 문서에 따르면 OpenAI, Anthropic, Google, Google Vertex, Amazon Bedrock, Anthropic on AWS, OpenRouter, Ollama를 연결할 수 있고 OpenAI 호환 로컬 엔드포인트도 지원합니다. Bedrock이나 Vertex는 기업 클라우드 계정 안에서 처리할 수 있어요. Ollama나 로컬 엔드포인트를 쓰면 문서상 사내 서버만으로 구성하는 것도 가능해요. 로컬 소형 모델의 판정 품질은 따로 검증해야 해요. 에이전트 스텝을 아예 쓰지 않으면 모델 호출은 0이에요.

하나 더 있어요. CLI(명령어로 쓰는 도구)는 기본으로 익명 사용 통계(텔레메트리)를 보내요. README는 "no test content, app content, or credentials"라고 밝혀요. 사내 정책상 막아야 하면 npx e2e telemetry disable이나 E2E_TELEMETRY_DISABLED=1로 끄면 돼요. 도입 검토 문서에 이 항목을 적어 두길 권해요.

우리 팀은 시험해 볼까요, 기다릴까요?

판단에서 먼저 따질 리스크는 세 가지예요.

• 1.0 이전 단계예요. README는 "e2e is in active development on the way to 1.0. APIs and config can still change between minor releases."라고 적어요. 첫 안정 태그 0.15.0(2026-09-30) 이후 0.18.0(2026-10-06)까지 마이너 3번, 패치 2번이 나왔어요.
• 코드가 한 사람에게 몰려 있어요. 커밋 669개 중 545개(81.5%)를 공동창업자 겸 CTO 1명이 작성했고 기여자는 27명이에요. 버스 팩터(핵심 인물이 빠져도 프로젝트가 굴러가는지 보는 지표) 관점에서 주의할 구조예요.
• 개발이 멈춘 구간이 있어요. 2026-08-02부터 2026-08-29까지 4주 연속 커밋이 0건이었고 사유는 공개 정보로 확인되지 않아요. 2026-08-30 주에 42건으로 재개해 2026-09-27 주에는 176건까지 올랐어요.

이 리스크를 깔고 상황별로 나누면 이래요.

시험 도입(PoC)을 돌린다면 아래 7가지를 숫자로 남기길 권해요. 전부 e2e가 직접 출력하거나 쉽게 관측돼요.

1. 한글 입력 성공률. 한글 입력 필드가 든 플로우 10개를 agent.act와 fill·pressSequentially 양쪽으로 써서 통과율을 비교해요.
2. 한국어 UI 판정 정확도. 같은 플로우를 한국어·영어 로케일로 각 20회 실행해 agent.assert의 거짓 통과와 거짓 실패 건수를 비교해요. 한국 팀에 가장 중요한 숫자예요.
3. 캐시 적중률과 토큰 비용. 실행 요약의 Cache와 AI 줄을 10회 연속 기록해 월 CI 비용을 어림해요.
4. 거짓 통과 시험. 일부러 깨진 앱 상태를 만들어 테스트가 실제로 실패하는지 확인해요. 약한 단정문이 캐시에 경로를 굳히는 위험과 완전일치 쿼리가 부정 단정문을 거짓 통과시키는 위험을 함께 겨냥해요.
5. CI 안정성. 같은 커밋으로 20회 실행해 플레이크 비율을 재요. 재시도가 항상 실시간이라 플레이크가 곧 비용이에요.
6. 모바일 제약 적합성. iOS에서 View 자식 부재, 탭 role other, display: none 요소 제외가 실제 앱 구조에 걸리는지 봐요.
7. 사내·로컬 모델 품질. 외부 전송이 막힌 조직이라면 Ollama나 Bedrock·Vertex 구성으로 2번을 다시 측정해요.

마무리

tester-army/e2e는 스타 소문보다 설치량과 코드량이 더 믿을 만한 초기 제품이에요. 웹과 앱을 한 테스트 파일에서 다루는 점이 가장 분명한 강점이고 Playwright 대응 기능 55행의 빈칸, 조용히 깨지는 의도적 차이 17건, 한국어 근거 0건이 약점입니다. 2026-10-07 기준 근거로는 웹과 앱을 함께 테스트하는 팀은 시험 도입 쪽, 웹만 안정적으로 돌리는 팀은 기존 구성을 유지하는 쪽이 합리적이에요.

우리 팀 상황에 맞는지부터 따져보셔도 충분합니다. 판단에 필요한 기준은 위에 정리해 뒀어요.

자주 묻는 질문

Playwright를 그대로 두고 e2e를 같이 써도 되나요?

네, 가능해요. 공식 마이그레이션 문서에 따르면 @e2e-dev/web이 자체 playwright-core를 번들로 갖고 있어서 @playwright/test 버전은 그대로 둘 수 있습니다. 기본 파일 패턴 tests/**/*.e2e.ts로 두 러너를 한 프로젝트 안에 나눠 두면 돼요.

코딩 에이전트가 테스트를 써 주면 되는데 실행 중에 도는 에이전트가 왜 필요한가요?

커뮤니티가 아직 합의하지 못한 질문이에요. 2026-06-18 Launch HN(132포인트, 댓글 69개)에서 같은 질문이 가장 큰 호응을 얻었고 창업자는 AI 채팅처럼 동적인 화면은 정해진 테스트로 확인하기 어렵다고 답했어요. 우리 앱의 화면이 얼마나 동적인지에 따라 답이 갈리니 PoC로 확인하는 게 낫습니다.

우리 회사 앱 화면이 외부 AI 모델로 나가나요?

에이전트 스텝을 쓰면 접근성 트리와 일부를 가린 URL이 모델로 가요. 스크린샷은 보안 필드가 가려졌다고 엔진이 증명한 경우에만 가고요. 에이전트 스텝을 쓰지 않으면 모델 호출은 0이고 Amazon Bedrock, Google Vertex, Ollama 같은 경로로 사내 계정이나 사내 서버 안에서 처리할 수도 있습니다. 공식 보안 문서와 모델 문서 기준이에요.

참고 자료

• tester-army/e2e 저장소 정보 (GitHub API, 2026-10-07 조회)
• tester-army/e2e README
• e2e 공식 문서 인덱스 (llms.txt)
• e2e 공식 문서: Playwright 이행 가이드
• e2e 공식 문서: Cypress 이행 가이드
• e2e 공식 문서: 모바일
• e2e 공식 문서: 캐시
• e2e 공식 문서: 보안
• e2e 공식 문서: 모델
• npm 레지스트리: e2e 패키지
• npm 다운로드 통계: e2e (2026-09-20~2026-10-06)
• TesterArmy GitHub 조직 정보
• Playwright 공식 문서: Test Agents
• Playwright 공식 문서: Emulation
• Launch HN: TesterArmy (YC P26)
• e2e 공개 발표 X 게시물 (2026-10-01)
• Hacker News 제출: E2E, The open source AI testing framework (2026-10-03)