트렌드 · 4분 · 06.19

AI가 PR을 분당 쏟아내는 시대, E2E 테스트는 자연어 에이전트가 한다 — YC P26 TesterArmy의 captcha·OTP·timezone 격파법

loopy vibecoder

#draft #E2E테스트 #바이브코딩 #TesterArmy #YC #QA자동화

핵심 요약 (TL;DR)

바이브코딩으로 PR이 분당 쏟아지는 지금, 진짜 병목은 "내가 짠 코드를 어떻게 검증하느냐"입니다. YC P26 배치의 TesterArmy가 그 빈자리를 자연어 E2E 에이전트로 채우며 0에서 30+ daily active teams로 성장했고, 2026년 6월 19일 KST 기준 HN 90점·40댓글을 받았습니다. captcha·OTP·timezone 같은 "Playwright가 끝내 못 풀던 문제"를 vision LLM과 accessibility API의 하이브리드로 격파하는 게 핵심이죠.

코드는 빨라졌는데, 테스트가 못 따라온다

AI 코딩 도구가 PR을 매달 1,700만 개 만들어낸다는 통계가 며칠 전 돌았습니다. 이게 무서운 건 "많이 쓰여졌다"가 아니라 "많이 검증되어야 한다"입니다. 회귀 테스트는 PR 수에 비례해 늘어나는 게 아니라 PR 사이의 상호작용 조합에 비례해 늘어납니다. 즉 PR이 2배가 되면 검증 비용은 4배가 됩니다.

기존 해법인 Playwright나 Cypress 스크립트는 두 가지 한계가 있습니다. 첫째, 사람이 스크립트를 유지보수해야 합니다. UI가 살짝만 바뀌어도 셀렉터가 깨집니다. 둘째, 외부 의존성을 못 다룹니다. captcha, 이메일 OTP, 결제 게이트웨이, 다른 timezone에 있는 사용자 — 이런 "진짜 사용자가 만나는 마찰"을 정적 스크립트가 못 흉내냅니다.

TesterArmy가 푼 방식

폴란드계 3인 파운더 Oskar, Szymon, Piotr가 시작한 TesterArmy는 YC P26 배치고, 모토는 단순합니다. "테스트는 아직 너무 고통스럽다." 작동 방식은 이렇습니다.

자연어로 시나리오를 적습니다. 예를 들어 "신규 사용자가 회원가입하고 이메일 인증 후 결제까지 마치는 흐름". 그러면 에이전트가 실제로 웹·모바일 앱을 굴리며 검증합니다. 이때 네 가지 특수 능력이 결정적입니다.

captcha 해결 — vision 모델이 captcha를 직접 풉니다.
이메일 OTP 자동 검증 — 에이전트마다 전용 인박스를 발급해 코드를 자동 추출합니다.
동적 콘텐츠 대응 — 셀렉터가 아니라 의미로 요소를 찾습니다.
vision + accessibility API 하이브리드 — 시각 모델만 쓰면 느리고 비싸지만, accessibility 트리만 쓰면 모달이나 캔버스를 못 봅니다. 두 채널을 같이 써서 속도와 커버리지를 둘 다 잡았습니다.

트리거는 스케줄 또는 GitHub 이벤트, 알림은 Slack·Discord입니다. 즉 "PR 머지 직전에 자동 회귀 검증 → 실패면 채널에 핑"이 한 줄 설정으로 들어갑니다.

실제로 잡은 버그가 의미 있는 이유

공개된 사례들이 흥미롭습니다. 온보딩 플로우 회귀, 체크아웃 회귀, AI 챗 플로우 실패, 대시보드 timezone 버그, GitHub Actions 트리거 자동 회귀 탐지. 특히 timezone 버그는 "주문 카운트가 잘못 집계되어 매출에 직접 영향"이라는 댓글이 따라붙었습니다. 이건 정적 스크립트로는 거의 못 잡습니다. 사용자 별 시각대를 실제로 흉내내야 하거든요.

HN 댓글에서 파운더가 "harness engineering and trajectory injection"을 강조한 것도 같은 맥락입니다. LLM 호출 위에 결정론적 레이어를 박아 "같은 시나리오면 같은 결과"를 보장하는 게 진짜 엔지니어링이라는 거죠.

바이브코더가 지금 챙길 것

바로 마이그레이션할 필요는 없습니다. Playwright가 잘 굴러가는 곳이면 굳이 갈아탈 이유는 없어요. 다만 다음 세 가지 시점에는 다시 보세요.

GitHub Actions에 AI PR이 들어차기 시작했을 때. 회귀 검증이 사람 손에 안 잡히는 순간이 옵니다.
captcha·OTP·결제 흐름이 테스트에서 빠져 있을 때. 정확히 이 흐름이 가장 자주 깨집니다.
timezone·동적 콘텐츠 버그로 한 번이라도 매출이 영향받았을 때. 그 비용 한 번이 1년치 테스트 SaaS 구독비를 넘기는 경우가 많습니다.

# TesterArmy 시나리오 예시 (개념)
"비회원이 첫 방문 → 회원가입(이메일 인증 포함)
 → 신용카드 결제 1만원 → 영수증 이메일 확인
 → 다음 날 한국시간 자정에 주문 카운트가 +1이어야 함"

위 한 줄이 captcha·OTP·timezone을 동시에 건드립니다. 정적 스크립트로 짜면 며칠, 자연어 에이전트로는 한 줄입니다.

FAQ

Q. 기존 Playwright/Cypress를 다 버려야 하나요?

아닙니다. 결정론적 단위 흐름·로그인 같이 "빠르고 자주 도는 테스트"는 Playwright가 여전히 강합니다. TesterArmy 같은 에이전트형은 "느리지만 진짜 사용자 행동을 흉내내야 하는 회귀 시나리오"에 어울립니다. 두 층을 같이 쓰는 게 현실적 답입니다.

Q. captcha를 LLM이 푸는 게 약관 위반 아닌가요?

자기 서비스 captcha를 자기 테스트 에이전트가 푸는 건 합법입니다. 외부 사이트 captcha를 푸는 데 쓰면 약관 위반이 될 수 있습니다. TesterArmy 같은 도구는 전자만 정상 사용 케이스로 봅니다.

Q. 비용은 얼마나 들까요?

공개된 정량 정보는 "30+ daily active teams"뿐입니다. 다만 vision LLM을 매 시나리오마다 호출하므로 정적 스크립트보다는 분명히 비쌉니다. 핵심은 "잡은 버그 한 건의 가치"가 회당 비용을 압도하느냐인데, 매출에 직접 영향 가는 흐름(결제·온보딩·timezone)에 한정하면 ROI가 빠르게 정당화됩니다.

마무리

AI가 코드를 빠르게 써주는 시대의 진짜 비대칭은 "빠르게 짠 코드의 진짜 사용자 행동을 누가 검증하느냐"입니다. 자연어 시나리오로 captcha·OTP·timezone까지 굴리는 에이전트는 이제 카테고리 자체가 되었습니다. 다음에 회귀 한 건이 매출에 닿는 순간, 우리는 "왜 더 빨리 자연어 테스트를 깔지 않았나"를 묻게 될 가능성이 높죠.