모던한 Web 애플리케이션의 E2E 테스트는 이전보다 훨씬 어려워졌습니다.

단순히 페이지를 열고, 버튼을 클릭하는 것만으로는 부족합니다. 현재의 애플리케이션에는 Feature Flag, Shadow DOM, React의 Hydration, OAuth, MFA, 다중 탭, 다중 테넌트(Multi-tenant), 지역별 설정, AI 에이전트, 멀티모달(Multimodal) 입력 등 테스트를 불안정하게 만드는 요소가 수없이 존재합니다.

게다가 까다로운 점은 테스트가 실패하는 경우뿐만이 아닙니다.

잘못된 이유로 테스트가 성공할 수도 있습니다.

이 기사에서는 현재의 Web 앱과 AI 기능을 테스트할 때 놓치기 쉬운 포인트들을 환경, 프론트엔드, 인증, SaaS, AI의 5가지 관점에서 정리합니다.

Staging에서만 실패하는 테스트는 단순한 Flaky Test가 아닐 수도 있습니다.

Feature Flag에 의해 실행 시점의 UI가 바뀌면, 동일한 URL이라도 실제로는 다른 화면 구조가 표시됩니다. 버튼이 메뉴 안으로 이동하거나, 폼이 여러 단계로 나뉘거나, 특정 사용자에게만 새로운 컴포넌트가 전달되기도 합니다.

이 문제를 조사할 때는 Feature Flag에 의한 Runtime UI의 차이로 인해 Staging에서만 브라우저 테스트가 실패하는 이유를 참고하면 도움이 됩니다.

테스트 결과에는 환경 이름뿐만 아니라 다음 사항들도 남겨야 합니다.

• 활성화된 Feature Flag
• 대상 사용자 또는 테넌트
• 배포된 Commit ID
• 사용된 Seed Data
• API 및 의존 서비스의 버전

Preview Environment도 마찬가지입니다. URL이 구동되고 있다는 것만으로는 테스트 가능한 환경이라고 할 수 없습니다. Ephemeral Preview Environment, Seed Data, 환경 차분을 포함한 테스트 계획과 같이, 실행 전에 환경 자체를 검증하는 단계가 필요합니다.

예를 들어, 메인 E2E 테스트를 시작하기 전에 다음을 확인합니다.

• 올바른 Build가 배포되었는가
• Seed Data가 투입되었는가
• Queue나 Email Service가 동작하고 있는가
• 필요한 Feature Flag가 활성화되어 있는가
• 테스트 사용자에게 올바른 권한이 있는가

이것만으로도 환경 미비로 인한 대량의 허위 실패(False failure)를 줄일 수 있습니다.

API Mock은 편리하지만, 실제 API와의 계약(Contract)이 어긋나면 위험합니다.

운영 API에서는 응답 구조가 변경되었는데 Mock만 옛날 형식을 반환하고 있다면, 테스트는 계속해서 과거의 세계를 검증하게 됩니다. 그 결과, 테스트는 안정적이지만 실제 운영 환경에서는 작동하지 않는 상태가 발생합니다.

이 현상은 API Mock Drift로 인해 브라우저 테스트가 잘못된 이유로 성공하는 문제에서 자세히 설명되어 있습니다.

대책으로는 다음과 같은 방법이 있습니다.

• Mock Response를 Schema Validation 한다
• OpenAPI나 JSON Schema로부터 Fixture를 생성한다
• 일부 테스트는 실제 서비스에 연결한다
• 실제 응답과 Fixture를 정기적으로 비교한다
• 폐기된 필드를 사용하는 Mock을 CI에서 실패하게 만든다

Mock을 줄이는 것이 목적이 아닙니다. Mock이 '존재하지 않는 Backend'를 만들지 않도록 하는 것이 중요합니다.

현대의 프론트엔드에서는 Element가 표시되어 있더라도 아직 조작 가능한 상태가 아닐 수 있습니다.

Server-Side Rendering된 HTML이 먼저 표시되고, 이후 클라이언트 측에서 Hydration이 이루어지는 경우, 버튼은 보이지만 Event Handler가 아직 연결되지 않았을 수 있습니다.

Hydration mismatch, Client-side re-render, Server/Client UI drift 테스트 방법에서는 이 문제를 실전적으로 정리하고 있습니다.

React 19로의 이전 후에 숨겨져 있던 Timing Bug가 표면화되는 케이스도 있습니다. React 19가 브라우저 테스트의 Timing 문제를 드러내는 이유도 확인해 두는 것이 좋습니다.

고정된 Sleep이 아니라, 애플리케이션 고유의 상태를 기다려야 합니다.

나쁜 예:
2초 대기
좋은 예:
...

Shadow DOM이나 Portal도 Element 탐색을 어렵게 만듭니다. Shadow DOM과 Portaled Modal을 깨지지 않게 테스트하는 방법에서 소개된 것처럼, Node의 존재뿐만 아니라 다음을 확인해야 합니다.

• 실제로 클릭 가능한지
• Overlay에 가려져 있지 않은지
• Keyboard Focus (키보드 포커스)가 올바르게 이동하는지
• Escape 키로 닫을 수 있는지
• 닫은 후에 원래 Element (엘리먼트)로 Focus (포커스)가 돌아오는지

Progressive Loading (점진적 로딩)을 채택한 UI에는 Loading (로딩)과 Loaded (로드 완료) 사이에 여러 상태가 있습니다.

• Skeleton (스켈레톤)
• Partial Content (부분 콘텐츠)
• Background Refresh (백그라운드 새로고침)
• Empty State (빈 상태)
• Retry State (재시도 상태)
• Stale Data (오래된 데이터)
• Infinite Scroll (무한 스크롤) 중의 추가 Loading (로딩)

Skeleton Screen (스켈레톤 스크린), Progressive Loading (점진적 로딩), Empty State (빈 상태)를 올바르게 테스트하는 방법처럼, 각각을 별개의 상태로 테스트해야 합니다.

또한, CSS Scroll Snap (CSS 스크롤 스냅), Sticky Header (스티키 헤더), Scroll-linked Animation (스크롤 연동 애니메이션) 등은 DOM 상에 Element (엘리먼트)가 존재하더라도 사용자로부터는 조작할 수 없는 경우가 있습니다.

CSS Scroll Snap (CSS 스크롤 스냅), Sticky Section (스티키 섹션), Scroll-linked UI (스크롤 연동 UI)를 Mobile Bug (모바일 버그)까지 포함하여 테스트하는 방법에서는 Viewport (뷰포트)와 좌표 확인이 중요하다고 설명되어 있습니다.

확인해야 할 예시는 다음과 같습니다.

• Sticky Header (스티키 헤더)가 CTA를 가리고 있지 않은지
• Scroll Snap (스크롤 스냅) 후에 올바른 Card (카드)가 중앙에 위치하는지
• Mobile Browser (모바일 브라우저)의 Address Bar (주소창) 변화 후에도 Layout (레이아웃)이 올바른지
• Orientation (방향) 변경 후에도 Scroll (스크롤) 위치가 깨지지 않는지

Visual Regression (시각적 회귀)도 마찬가지입니다. CSS Grid (CSS 그리드), Flexbox (플렉스박스), Container Query (컨테이너 쿼리)에서는 작은 차이가 큰 Screenshot Diff (스크린샷 차이)를 발생시킬 수 있습니다. CSS Grid (CSS 그리드), Flexbox (플렉스박스), Container Query (컨테이너 쿼리)에서의 Visual Regression Noise (시각적 회귀 노이즈) Benchmark (벤치마크) 방법을 참고하여, False Positive (오탐) 비율을 측정하는 것이 중요합니다.

Cypress (사이프러스)에는 Retry (재시도) 메커니즘이 있지만, 그것만으로 Flaky Test (플래키 테스트)가 사라지는 것은 아닙니다.

재렌더링 직전의 Element (엘리먼트)를 가져오거나, force: true를 사용하여 실제 UI 문제를 숨기거나, Network Request (네트워크 요청) 완료를 최종 상태로 오인하면 테스트는 불안정해집니다.

Cypress Test (사이프러스 테스트)를 안정화하기 위한 실전 가이드에서도, 안정성은 Selector (셀렉터)보다 상태 설계에 좌우된다는 점이 강조되어 있습니다.

중요한 것은 다음과 같은 습관입니다.

• Arbitrary Wait (임의의 대기)를 피할 것
• UI 상의 의미 있는 상태를 기다릴 것
• Test Data (테스트 데이터)를 명시적으로 만들 것
• 하나의 Test (테스트)에 너무 많은 책임을 담지 말 것
• Detached Element (분리된 엘리먼트)를 Runner (러너)의 문제뿐만 아니라 재렌더링의 신호로 취급할 것

OAuth, MFA, Popup (팝업), Cross-tab Login (교차 탭 로그인)은 전형적인 깨지기 쉬운 Flow (플로우)입니다.

사용자는 앱에서 Identity Provider (ID 제공자)로 이동하여 MFA를 완료하고, Callback URL (콜백 URL)로 돌아와 원래의 Tab (탭)에 Session (세션)을 반영합니다.

OAuth Popup (OAuth 팝업), MFA Prompt (MFA 프롬프트), Cross-tab Login Handoff (교차 탭 로그인 핸드오프)를 Endtest (엔드테스트)로 테스트하는 방법에서는 여러 Window (윈도우)나 Session (세션) 인계가 포함된 테스트의 어려움이 정리되어 있습니다.

또한, 외부 QA Partner (QA 파트너)를 이용하는 경우에도 단일 페이지의 Happy Path (해피 패스)만으로는 평가할 수 없습니다. Multi-window (멀티 윈도우), Popup Authentication (팝업 인증), Cross-domain Session Handoff (교차 도메인 세션 핸드오프)를 다룰 수 있는 QA Partner (QA 파트너)를 고르는 방법처럼, 실제 인증 구성에 가까운 환경에서 검증해야 합니다.

Multi-tenant Application (멀티 테넌트 애플리케이션)에서는 자신의 Tenant Data (테넌트 데이터)가 보이는 것만으로는 불충분합니다.

다른 Tenant (테넌트)의 Data (데이터)가 보이지 않는다는 것도 증명해야 합니다.

Multi-tenant App Testing (멀티 테넌트 앱 테스트)과 Tenant Isolation (테넌트 격리)에서 QA Platform (QA 플랫폼)에 필요한 기능을 참고하여, 최소 2개의 Tenant (테넌트)를 준비하고 다음을 확인합니다.

• Direct URL(직접 URL)로 다른 Tenant(테넌트)의 Record(레코드)에 접근할 수 없음
• Search Result(검색 결과)에 다른 Tenant Data(테넌트 데이터)가 나타나지 않음
• Export(내보내기) 시 다른 Tenant Data(테넌트 데이터)가 섞이지 않음
• Recently Viewed(최근 본 항목)에 다른 Tenant(테넌트)의 정보가 남지 않음
• 다른 Tab(탭)에서 Tenant(테넌트)를 전환해도 Session(세션)이 혼선되지 않음

UI에서 Link(링크)를 숨기는 것만으로는 Isolation(격리)이라고 할 수 없습니다. Backend(백엔드) 측의 Authorization(권한 부여)을 포함하여 검증할 필요가 있습니다.

Sign-up Flow(가입 흐름)는 Web Form(웹 양식)만이 아닙니다.

• Identity Service (ID 서비스)
• Email Provider (이메일 제공자)
• Background Job (백그라운드 작업)
• Billing (결제)
• Fraud Check (부정 사용 확인)
• Tenant Provisioning (테넌트 프로비저닝)

등 여러 System(시스템)이 관계합니다.

Multi-step Sign-up(다단계 가입), Email Verification(이메일 인증), Account Recovery(계정 복구)를 테스트할 수 있는 Browser Testing Platform(브라우저 테스트 플랫폼)의 평가 방법에서는 다음과 같은 Edge Case(에지 케이스)가 중요합니다.

• Expired Verification Link (만료된 인증 링크)
• Link(링크)의 이중 사용
• 다른 Browser Session(브라우저 세션)에서의 Verification(인증)
• Email(이메일) 지연
• Sign-up(가입)은 성공했으나 Browser(브라우저)가 Timeout(타임아웃)됨
• Social Login User(소셜 로그인 사용자)의 Password Recovery(비밀번호 복구)
• Invitation(초대) 대상 Tenant(테넌트)의 변경

Verification Token(인증 토큰)을 Hard-code(하드코딩)하면, 중요한 Handoff(핸드오프)를 테스트하지 않는 것이 됩니다. 실제 Email(이메일)을 수신하여 그곳에서 Link(링크)나 OTP를 사용하는 것이 더 현실적입니다.

Multi-region SaaS(멀티 리전 SaaS)에서는 동일한 기능이라도 Region(리전)에 따라 동작이 달라집니다.

• Date Format (날짜 형식)
• Currency (통화)
• Data Residency (데이터 거주성)
• Regional API (지역 API)
• Consent (동의)
• Daylight Saving Time (일광 절약 시간제)
• Feature Availability (기능 가용성)

Multi-region SaaS, Locale Drift(로케일 드리프트), Time-zone Sensitive Flow(시간대 민감 흐름)의 테스트 방법과 같이, 경계값을 의식한 테스트가 필요합니다.

예를 들어,

• 자정 전후의 Subscription Expiration (구독 만료)
• DST(일광 절약 시간제) 전환일의 Report (리포트)
• Locale(로케일) 변경 전후의 Date(날짜) 입력
• Region Migration(리전 마이그레이션) 이후의 Tenant(테넌트)
• UTC Worker(UTC 워커)와 Local Browser(로컬 브라우저)의 시차

등은 일반적인 Happy Path(해피 패스)에서는 발견하기 어려운 문제입니다.

AI 기능 테스트에서는 생성된 문장만을 확인하기 쉽습니다.

하지만 실제로는 다음과 같은 UI도 중요합니다.

• Regenerate (재생성)
• Retry (재시도)
• Stop Generation (생성 중단)
• Copy to Clipboard (클립보드에 복사)
• Edit Prompt (프롬프트 수정)
• Model Switch (모델 전환)
• Continue Response (응답 계속하기)

AI Output UI(AI 출력 UI)의 Regenerate, Retry, Copy 작업에 대한 Endtest와 Playwright의 비교에서는, 생성 내용이 가변적이더라도 UI 자체는 결정적으로 테스트할 수 있음이 보여집니다.

예를 들어, 다음을 확인할 수 있습니다.

• Regenerate(재생성)가 올바른 Message(메시지)에 연결됨
• Retry(재시도) 시 User Message(사용자 메시지)가 중복되지 않음
• Stop(중단) 후에도 Conversation(대화) 복구가 가능함
• Copy(복사) 대상이 Streaming(스트리밍) 도중의 파편이 아님
• 새로운 Message(메시지) 추가 후에도 조작 대상이 어긋나지 않음

출력 전문의 완전 일치가 아니라, 구조, 필수 정보, 금지 내용, UI State(UI 상태)를 검증하는 것이 더 현실적입니다.

AI Product(AI 제품)는 UI나 Copy(문구)가 빈번하게 변합니다.

모든 것을 Exact Match(정확한 일치)로 설정하면 Maintenance Cost(유지보수 비용)가 증가합니다. 반면, 모든 것을 모호하게 설정하면 중대한 Regression(회귀)을 놓치게 됩니다.

UI와 Copy(문구)가 빈번하게 변하는 AI 앱에서의 Endtest와 Autify의 비교를 참고하여, Assertion(어설션)을 다음 두 종류로 나누면 관리가 용이해집니다.

• Prompt(프롬프트)가 1회만 전송되는지

• Response(응답)가 올바른 Conversation(대화)에 속하는지

• Tool Call(도구 호출) 전에 필요한 확인 절차가 들어가는지

• Stop Generation(생성 중단)이 기능하는지

• User Data(사용자 데이터)가 다른 Session(세션)으로 유출되지 않는지

• Helper Text (헬퍼 텍스트)

• Minor Label (사소한 레이블)

• Markdown Formatting (마크다운 포맷팅)

• Response의 말투 (Responseの言い回し)

• 중요하지 않은 Layout 차이 (重要でないLayout差分)

Security Warning(보안 경고)이나 Permission(권한) 표시 등은 Copy(문구) 변경이 중대한 의미를 가질 수 있으므로, Exact Assertion(정확한 단언)이 필요한 경우도 있습니다.

Prompt Injection(프롬프트 인젝션) Test(테스트)를 입력란에 "이전 지시를 무시하고"라고 입력하는 것만으로 끝내서는 안 됩니다.

Browser Agent(브라우저 에이전트)는 Webpage(웹페이지), Email(이메일), PDF, Knowledge Base(지식 베이스), Hidden DOM(숨겨진 DOM), Tool Response(도구 응답) 등으로부터 부정한 지시를 받을 가능성이 있습니다.

AI-powered Browser Workflow(AI 기반 브라우저 워크플로우)에서의 Prompt Injection Defense(프롬프트 인젝션 방어) 테스트 방법에서는, 외부 Content(콘텐츠)를 "명령"이 아닌 "Data(데이터)"로 취급할 수 있는지가 중요합니다.

확인해야 할 점은 다음과 같습니다.

• 금지된 Tool Call(도구 호출)을 시도하지 않았는지
• Secret(비밀 정보)을 Intermediate Step(중간 단계)에서 유출하지 않았는지
• 미승인 Domain(도메인)으로 이동하지 않았는지
• User(사용자)의 원래 목적을 유지했는지
• Sensitive Action(민감한 동작) 전에 확인했는지

최종 답변이 안전하더라도, 도중에 위험한 Action(동작)을 시도했을 가능성이 있습니다.

AI의 실패는 재현하기 어렵기 때문에, Pass/Fail(합격/불합격)만으로는 충분하지 않습니다.

필요한 증거에는 다음이 포함됩니다.

• Conversation(대화) 전체
• System Instruction(시스템 지시문)
• Retrieved Content(검색된 콘텐츠)
• Model(모델) 명칭과 설정
• Tool Call(도구 호출)
• Tool Result(도구 결과)
• Browser State(브라우저 상태)
• Final Output(최종 출력)

Prompt Injection Evidence(프롬프트 인젝션 증거), Conversation Replay(대화 재생), Unsafe Output Triage(안전하지 않은 출력 분류)를 다루는 AI Testing Tool(AI 테스트 도구)의 평가 방법에서는, Replay(재생) 가능성이 중요한 평가 축으로 꼽힙니다.

동일한 Scenario(시나리오)를 여러 번 실행하여 실패율을 확인하는 것도 필요합니다. 10번 중 9번이 안전하더라도 1번 위험한 동작을 한다면, Deterministic(결정론적)한 Pass(합격)로 간주할 수 없습니다.

AI Agent(AI 에이전트)가 올바른 결과를 반환하더라도, 그 과정이 반드시 안전하다는 보장은 없습니다.

예를 들어 Calendar Agent(캘린더 에이전트)가 올바른 Meeting(회의)을 생성했더라도,

• 한 번 Wrong Person(잘못된 인물)을 Invite(초대)했거나
• Duplicate Event(중복 이벤트)를 생성했거나
• Permission(권한)이 없는 Calendar(캘린더)를 읽었거나
• Conflict(충돌)를 무시했을

가능성이 있습니다.

Agentic Workflow(에이전트 워크플로우), Tool Call(도구 호출), Multi-step Recovery(다단계 복구)를 테스트하는 AI Platform(AI 플랫폼)의 평가 포인트에서는 각 Tool Boundary(도구 경계)를 검증해야 합니다.

• 올바른 Tool(도구)을 선택했는가
• Argument(인자)가 올바른가
• 권한이 적절한가
• Result(결과)를 올바르게 해석했는가
• Retry(재시도) 시 Side Effect(부작용)를 중복시키지 않았는가
• 필요한 Confirmation(확인)을 받았는가

Timeout(타임아웃), Partial Result(부분 결과), Rate Limit(속도 제한), Permission Denial(권한 거부) 등도 의도적으로 주입하면 Recovery Path(복구 경로)의 품질을 확인할 수 있습니다.

Text(텍스트), Image(이미지), Audio(오디오), Screen State(화면 상태)를 동시에 다루는 AI Application(AI 애플리케이션)에서는 각 입력이 올바르더라도 이들의 연결이 잘못되어 있을 수 있습니다.

Text, Image, Audio, Screen State를 함께 검증하는 Multimodal App(멀티모달 앱)용 AI Testing Market Report(AI 테스트 시장 보고서)에서는 여러 Modalities(모달리티) 간의 정합성이 중요하다고 강조합니다.

예를 들어,

• Screenshot(스크린샷)이 다른 User(사용자)의 Session(세션)에 연결됨
• Audio(오디오)와 Screen(화면)이 시간적으로 어긋남
• AI가 오래된 Frame(프레임)을 참조함
• Image(이미지) 내의 Prompt Injection(프롬프트 인젝션)을 따름
• 올바른 정보를 다른 Conversation(대화)에서 섞어옴

과 같은 문제들이 있습니다.

Timestamp(타임스탬프), Session ID(세션 ID), Input ID(입력 ID)를 저장하여, AI가 어떤 Input(입력)을 보았는지 추적할 수 있도록 해야 합니다.

Release(릴리스) 직후에 Browser Test(브라우저 테스트)가 여러 번 실패하면, 즉시 Rollback(롤백)하고 싶어질 것입니다.

하지만 Browser Worker, Network, Test Data, Session Start 등이 원인인 경우, Product(제품)는 정상일 수도 있습니다.

Rollback(롤백) 전에 Product Regression(제품 회귀)과 CI Noise(CI 노이즈)를 구분하는 방법으로는, 증거를 다음과 같이 분류하는 것이 권장됩니다.

• Manual(수동)로도 재현됨

• 여러 Runner(러너)에서 동일하게 실패

• 새로운 Server Error(서버 에러)가 발생함

• 변경 사항과 실패 지점이 일치함

• Browser Session(브라우저 세션) 자체가 시작되지 않음

• 무관한 Test(테스트)가 Setup(셋업) 단계에서 실패

• 다른 Worker(워커)에서는 성공

• Screenshot(스크린샷)상으로는 올바른 상태

• Network(네트워크) 또는 Infrastructure(인프라스트럭처) Error(에러)

Retry(재시도)는 편리하지만, 첫 번째 실패를 지우지 말고 Retry 전후의 차이점을 저장해야 합니다.

Development(개발) 환경에서는 이해하기 쉬운 Stack Trace(스택 트레이스)가, Production Build(프로덕션 빌드)에서는 Minification(코드 압축)으로 인해 읽을 수 없게 될 수 있습니다.

게다가 Error Boundary(에러 경계)가 "Something went wrong"과 같은 Generic UI(일반적인 UI)로 대체되면, Test Result(테스트 결과)만으로는 원인을 파악할 수 없습니다.

Source Map(소스 맵), Minification(코드 압축), Error Boundary(에러 경계)가 실제 Stack Trace(스택 트레이스)를 숨기는 문제에 대해서는, Production-like Environment(프로덕션 유사 환경)에서도 Observability(관측 가능성)를 유지해야 한다고 설명되어 있습니다.

최소한 다음 항목들을 저장하면 조사가 용이해집니다.

• Build ID
• Browser Console(브라우저 콘솔)
• Unhandled Exception(처리되지 않은 예외)
• Rejected Promise(거부된 프로미스)
• Source Map 대응 Stack Trace(소스 맵 대응 스택 트레이스)
• Request ID
• Active Feature Flag(활성화된 피처 플래그)

Screenshot(스크린샷)뿐만 아니라 Application Log(애플리케이션 로그)와 결합하는 것이 중요합니다.

Claude 등을 사용하면 Playwright Framework(플레이라이트 프레임워크)를 짧은 시간 안에 대량으로 생성할 수 있습니다.

하지만 초기 구현이 빠르더라도, 다음의 유지보수 과제는 남습니다.

• Test Data(테스트 데이터)
• OAuth Account(OAuth 계정)
• MFA Secret(MFA 비밀값)
• Email Retrieval(이메일 회수)
• Tenant Provisioning(테넌트 프로비저닝)
• Browser Upgrade(브라우저 업그레이드)
• CI Capacity(CI 용량)
• Failure Triage(실패 분류)
• Selector(셀렉터) 변경
• Cleanup(정리)

Claude가 거대한 Playwright Framework(플레이라이트 프레임워크)를 생성한 후에 발생하는 Maintenance Cost(유지보수 비용) 측면에서는, 생성 비용보다 Ownership Cost(소유 비용)가 더 중요하다고 지적됩니다.

AI는 Code(코드)를 작성하는 시간은 줄여줄 수 있지만, 어떤 Workflow(워크플로우)가 중요한지, 어떤 Failure(실패)가 진짜인지, 어떤 Test(테스트)를 삭제해야 하는지까지 자동으로 결정해주지는 않습니다.

현재의 E2E 테스트에서는 Selector(셀렉터)만 개선하는 것으로는 충분하지 않습니다.

확인해야 할 대상은 다음과 같습니다.

• Environment(환경): Build(빌드), Feature Flag(피처 플래그), Seed Data(시드 데이터), Region(리전)
• Frontend State(프론트엔드 상태): Hydration(하이드레이션), Re-render(리렌더링), Progressive Loading(점진적 로딩)
• Geometry(기하학적 구조): Sticky UI(스티키 UI), Scroll(스크롤), Viewport(뷰포트), Overlay(오버레이)
• Identity(인증/식별): OAuth, MFA, Cross-tab(크로스 탭), Email Verification(이메일 인증)
• SaaS Boundary(SaaS 경계): Tenant(테넌트), Locale(로케일), Time Zone(타임존), Data Isolation(데이터 격리)
• AI Behavior(AI 동작): Prompt Injection(프롬프트 인젝션), Tool Call(도구 호출), Replay(리플레이), Multimodal Input(멀티모달 입력)
• Evidence(증거): Screenshot(스크린샷), Video(비디오), Console(콘솔), Network(네트워크), Build ID, Conversation(대화 내용)

안정적인 테스트란 단순히 "실패하지 않는 테스트"가 아닙니다.

왜 성공했는지, 왜 실패했는지를 설명할 수 있는 테스트입니다.

테스트 결과에 충분한 증거가 있다면, Flaky Test(플래키 테스트)를 숨기기 위해 Retry(재시도)를 늘릴 필요도, 원인 불명의 실패로 Release(릴리스)를 중단할 필요도 줄어듭니다.

모던 Web 앱과 AI 기능을 테스트하는 데 있어 가장 중요한 것은 단순히 Test Runner(테스트 러너)를 선택하는 것만이 아닙니다.

어떤 상태를 관측하고, 어떤 경계(boundary)를 검증하며, 어떤 증거를 남길 것인지를 처음에 설계하는 것입니다.