프론트엔드 E2E 테스트란 무엇이고, 어떤 사용자 흐름부터 검증해야 할까

빠른 답

E2E 테스트는 브라우저에서 사용자의 주요 흐름이 끝까지 완료되는지 확인하는 마지막 품질 기준선이다.
모든 화면을 자동화하기보다 로그인, 결제, 신청, 권한 확인처럼 실패 비용이 큰 여정부터 잡는 편이 유지 비용이 낮다.
도구 선택보다 더 자주 발목을 잡는 것은 불안정한 셀렉터, 고정 대기, 재현되지 않는 테스트 데이터다.
실패를 빨리 좁히려면 스크린샷만 남기지 말고 trace, 콘솔 로그, 네트워크 기록, 요청 ID를 함께 남겨야 한다.

E2E 테스트는 브라우저를 얼마나 많이 조작했는가를 보는 작업이 아니라, 배포 전후에 사용자가 중요한 일을 실제로 끝낼 수 있는지를 확인하는 작업에 가깝다. 단위 테스트와 통합 테스트가 코드 단위의 정확도를 높여 준다면, E2E 테스트는 라우팅, 인증, 렌더링, 네트워크, 권한이 연결된 최종 경로를 확인한다.

시간 흐름으로 이해하기
흐름으로 보기
왜 이 기준을 기본 품질로 볼까
핵심 흐름 선정
실제로 막히는 지점
테스트 환경 준비
브라우저 시나리오 실행
실패 증거 수집
CI 품질 게이트
무엇을 E2E로 두고 무엇은 단위·통합 테스트에 맡길까

시간 흐름으로 이해하기

설계 시점

실패 비용이 큰 사용자 여정 2~5개를 먼저 고른다.

→

준비 시점

계정, 시드 데이터, 외부 의존성을 반복 가능한 상태로 맞춘다.

→

실행 시점

입력과 클릭보다 최종 화면, 세션 유지, 응답 결과를 기준으로 본다.

→

실패 시점

스크린샷, 콘솔, 네트워크, trace 를 함께 저장해 원인을 좁힌다.

→

배포 시점

PR 스모크, 배포 전 회귀, 스테이징 검증을 분리해 운영 흐름에 붙인다.

시간축으로 보면 E2E는 테스트 코드 한 파일의 문제가 아니라, 설계와 운영을 잇는 품질 장치에 가깝다. 앞단에서 범위를 잘 고르고, 중간에서 증거를 잘 남기고, 뒷단에서 품질 게이트를 분리해야 유지가 쉬워진다.

흐름으로 보기

흐름 다이어그램

이 순서를 거꾸로 잡으면 보통 테스트 코드만 늘고 신뢰도는 잘 오르지 않는다. 특히 환경 준비와 증거 수집이 빠진 상태에서 시나리오를 먼저 늘리면, 제품 결함과 테스트 노이즈를 구분하기 어려워진다.

왜 이 기준을 기본 품질로 볼까

사용자는 함수나 컴포넌트를 따로 경험하지 않는다. 로그인 후 대시보드로 이동하는 흐름, 결제 후 완료 화면으로 이어지는 흐름, 권한 없는 사용자가 차단되는 흐름처럼 전체 여정을 경험한다. 그래서 단위 테스트가 충분해 보여도 배포 직전에는 여전히 불안이 남는 경우가 많다.

이 불안은 대개 경계면에서 생긴다. 인증 API는 성공했는데 브라우저에 쿠키가 저장되지 않거나, 라우터 가드가 잘못 동작해 리다이렉트가 반복되거나, 버튼은 보이지만 로딩 오버레이에 가려 클릭되지 않는 식이다. E2E 테스트는 이런 연결 부위를 실제 브라우저에서 확인한다는 점에서 기본 품질 기준선 역할을 한다.

품질 관점에서 보면 E2E가 다루는 범위는 화면 자동화보다 조금 더 넓다. 접근성 이름이 붙은 요소를 찾는지, 권한이 없는 경로를 차단하는지, 오류가 났을 때 사용자가 복구 가능한 메시지를 보는지, 실패를 추적할 로그와 흔적이 남는지도 함께 포함된다.

핵심 흐름 선정

처음부터 모든 화면을 E2E로 덮을 필요는 없다. 보통은 실패 비용과 운영 부담을 기준으로 2~5개의 여정을 먼저 고른다.

실패 비용: 깨졌을 때 매출, 가입, 상담, 운영 대응 비용이 커지는가
사용 빈도: 많은 사용자가 반복해서 지나는 경로인가
복구 난도: 사용자가 스스로 되돌리기 어려운가
권한 민감도: 인증, 인가, 개인정보, 결제와 연결되는가

이 기준으로 고르면 보통 다음 항목이 앞쪽에 온다. 로그인과 로그아웃, 회원가입 또는 신청서 제출, 주문 및 결제 완료, 파일 업로드, 권한별 접근 제어, 주요 검색 또는 필터 결과 확인이 여기에 해당한다. 반대로 날짜 포맷팅, 할인 계산의 세부 분기, 폼 검증 문구의 모든 조합은 E2E보다 단위·통합 테스트에서 다루는 편이 더 효율적이다.

실제로 막히는 지점

E2E가 불안정하다고 느껴질 때는 도구보다 운영 방식이 원인인 경우가 많다.

셀렉터: CSS 클래스, DOM 순서, nth-child에 의존하면 작은 UI 수정에도 깨진다.
대기 전략: sleep 3000 같은 고정 대기는 로컬에서는 지나가도 느린 CI에서 흔들린다.
테스트 데이터: 여러 테스트가 같은 계정과 주문 데이터를 공유하면 재현성이 떨어진다.
환경 차이: 쿠키 도메인, SameSite, CORS, 기능 플래그 차이로 로컬과 스테이징 결과가 달라진다.
외부 의존성: 결제, 메일, OAuth를 실서버에 직접 물리면 속도와 안정성이 동시에 나빠진다.

이 지점들을 먼저 정리하지 않으면 테스트 수가 늘어도 신뢰도는 잘 올라가지 않는다. 도구가 Playwright이든 Cypress든, 공식 문서에서도 공통적으로 테스트 격리와 사용자 관점의 선택자, 데이터 seeding, CI 실행을 권장하는 이유가 여기에 있다. 참고로 Playwright의 Best Practices와 Trace Viewer, Cypress의 Testing Types와 Testing Your App 문서는 이 공통 기준을 비교적 잘 정리해 둔다.

테스트 환경 준비

재현 가능한 환경이 있어야 실패를 제품 결함으로 읽을 수 있다. 준비 단계에서는 테스트 러너보다 baseURL, 계정, 데이터 초기화, 외부 의존성 분리가 먼저 정해지는 편이 좋다.

도구와 무관하게 최소 기준은 비슷하다. 실패 시 스크린샷과 비디오를 남기고, trace는 재시도 시점에 기록하거나 로컬에서만 강하게 켜고, CI에서는 일정한 포트와 빌드 결과로 앱을 띄운다. 아래 예시는 Playwright 구성 예시지만, 같은 생각을 Cypress나 WebDriver 기반 러너에도 그대로 옮길 수 있다.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './e2e',
  timeout: 30_000,
  retries: process.env.CI ? 2 : 0,
  use: {
    baseURL: process.env.E2E_BASE_URL ?? 'http://127.0.0.1:3000',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: process.env.CI ? 'on-first-retry' : 'retain-on-failure',
  },
  webServer: {
    command: 'npm run start:test',
    port: 3000,
    reuseExistingServer: !process.env.CI,
  },
});

여기에 테스트 데이터 정책을 같이 두면 흔들림이 많이 줄어든다.

전용 계정과 전용 시드 데이터를 사용한다.
테스트마다 필요한 상태를 API나 스크립트로 초기화한다.
외부 결제나 메일처럼 통제하기 어려운 의존성은 계약이 안정적인 더미 환경이나 샌드박스로 분리한다.
권한, 쿠키, 지역화, 기능 플래그는 로컬과 CI에서 같은 값으로 맞춘다.

브라우저 시나리오 실행

E2E 시나리오는 클릭 자체보다 사용자가 보게 되는 결과를 검증하는 쪽이 덜 흔들린다. 예를 들어 로그인 시나리오라면 버튼 클릭 성공이 아니라, 세션이 유지된 상태로 보호된 페이지에 진입하고 사용자 식별 정보가 보이는지까지 확인하는 방식이다.

가장 작은 흐름을 HTTP 관점으로 풀면 이런 식이다.

GET /login: 로그인 폼이 렌더링된다.
POST /api/login: 200 응답과 세션 쿠키가 내려온다.
GET /orders: 인증된 상태에서 주문 내역 화면이 열린다.
브라우저 화면: 제목, 내비게이션, 사용자 정보가 예상대로 보인다.

이 흐름을 브라우저 테스트로 옮기면 다음과 같이 쓸 수 있다. 예시는 Playwright지만, Cypress에서도 visit, type, click, should 흐름은 비슷하다.

import { test, expect } from '@playwright/test';

test('로그인 후 주문 내역 페이지가 열린다', async ({ page }) => {
  await page.goto('/login');

  await page.getByLabel('이메일').fill('e2e-user@example.com');
  await page.getByLabel('비밀번호').fill('Passw0rd!');
  await page.getByRole('button', { name: '로그인' }).click();

  await expect(page).toHaveURL(/\/orders$/);
  await expect(page.getByRole('heading', { name: '주문 내역' })).toBeVisible();
  await expect(page.getByRole('navigation')).toContainText('로그아웃');
});

여기서 label과 role 중심 선택자를 쓰면 테스트 안정성뿐 아니라 접근성 점검에도 도움이 된다. 반대로 CSS 클래스나 DOM 깊이에 기대면 UI 정리만 해도 테스트가 쉽게 깨진다. 고정 시간을 기다리는 방식보다 도구가 제공하는 자동 대기와 재시도 가능한 assertion을 쓰는 편이 보통 더 낫다.

실패를 눈으로 따라가고 싶을 때는 테스트를 다시 돌리기보다 디버그 모드와 trace를 함께 보는 쪽이 빠를 때가 많다.

npx playwright test e2e/login.spec.ts --debug
npx playwright show-trace test-results/login-failure/trace.zip

실패 증거 수집

E2E 실패는 왜 실패했는지가 바로 보이지 않으면 금방 운영 부담으로 바뀐다. 그래서 스크린샷 한 장만 남기는 것보다 브라우저 콘솔, 네트워크 기록, 서버 로그를 같은 요청 ID로 연결하는 구성이 유용하다.

아래는 로그인 시나리오가 실패했을 때 볼 수 있는 출력 예시다.

Running 3 tests using 2 workers

  ✘  1 [chromium] › e2e/login.spec.ts:4:1 › 로그인 후 주문 내역 페이지가 열린다 (8.8s)

  Error: expect(page).toHaveURL(/\/orders$/) failed
  Expected pattern: /\/orders$/
  Received string: "http://127.0.0.1:3000/login?error=server"

  Console:
    [error] POST /api/login 500 Internal Server Error
    [warn] request-id=req_7f4b7c auth retry disabled

  Server log:
    2026-04-08T10:41:51Z ERROR req_7f4b7c auth/login database timeout

  Artifacts:
    screenshot: test-results/login-failure/test-failed-1.png
    trace: test-results/login-failure/trace.zip
    video: test-results/login-failure/video.webm

이런 로그에서는 마지막 assertion보다 POST /api/login 500과 요청 ID가 더 가까운 단서가 된다. 보통은 다음 순서로 읽으면 원인을 빨리 좁힐 수 있다.

응답 코드와 요청 ID를 먼저 본다.
스크린샷으로 에러 배너, 로딩 오버레이, 권한 모달 같은 화면 상태를 확인한다.
trace에서 클릭 직전과 응답 직후 DOM 상태를 비교한다.
같은 요청 ID로 서버 로그를 찾아 프런트엔드 실패와 백엔드 실패를 연결한다.

프론트엔드 E2E라는 이름 때문에 화면만 보면 될 것처럼 느껴질 때가 있지만, 실제 원인은 인증 서버, 캐시, 세션 저장소, 기능 플래그에서 발견되는 경우도 적지 않다. 관측성을 함께 설계해야 유지가 쉬운 이유다.

CI 품질 게이트

E2E를 자동 점검에 붙일 때는 한 번에 모든 시나리오를 모든 커밋에 돌리기보다, 목적별로 나누는 편이 운영하기 쉽다.

PR 스모크: 로그인, 제출, 권한 확인처럼 서비스 기준선이 되는 3~5개 흐름
메인 브랜치 회귀: 검색, 업로드, 예외 복구까지 포함한 더 넓은 세트
배포 후 검증: 스테이징 또는 읽기 전용 운영 검증으로 실제 인프라와 설정 차이 확인

아래는 PR에서 스모크 E2E를 돌리는 최소 예시다. CI 서비스 문법보다 설치, 앱 준비, 브라우저 설치, 스모크 실행이라는 순서를 보는 편이 중요하다.

name: e2e-smoke

on:
  pull_request:

jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run build
      - run: npx playwright install chromium --with-deps
      - run: npm run e2e:smoke

스테이징 검증은 E2E의 연장선으로 보는 편이 자연스럽다. 로컬과 CI에서는 통과했는데, 스테이징에서만 쿠키 도메인이나 CORS, 프록시 헤더 문제로 인증이 깨지는 경우가 흔하기 때문이다. 다만 운영 환경에서는 결제나 데이터 변경이 일어나는 시나리오를 그대로 돌리기보다, 읽기 전용 점검이나 샌드박스 계정 기반 검증으로 범위를 조절하는 편이 부담이 적다.

무엇을 E2E로 두고 무엇은 단위·통합 테스트에 맡길까

경계를 잡을 때는 사용자 여정의 완주 여부를 기준으로 두면 비교적 선명하다.

E2E에 두기 좋은 것: 로그인과 로그아웃, 회원가입, 결제 완료, 파일 업로드, 권한별 화면 접근, 오류 복구 흐름
통합 테스트에 두기 좋은 것: API 응답 파싱, 라우터 가드, 캐시 갱신, 폼 상태 전이, 컴포넌트 간 상호작용
단위 테스트에 두기 좋은 것: 검증 함수, 포맷터, 계산 로직, 에러 메시지 매핑, 경계 조건 분기

이 구분을 해 두면 E2E가 지나치게 길어지는 문제를 줄일 수 있다. 예를 들어 할인 규칙 20개를 모두 브라우저에서 돌리기보다, 대표 흐름 하나만 E2E에 두고 세부 계산 분기는 단위 테스트로 내려보내는 방식이 보통 더 읽기 쉽고 빨리 실패한다. 결국 E2E는 모든 것을 담는 테스트가 아니라, 배포 전후에 가장 비싼 실패를 막는 마지막 확인선에 가깝다.

원문 참고

https://www.maeil-mail.kr/question/52

Chart js와 amchart 비교

Chart js 특징은 위의 그림으로 대체 할 수 있을 듯 하다. 오픈 소스이고, 기본으로 제공하는 차트 종류가 8가지 Canv a s를 이용해서 차트를 그리고, 반응형을 지원한다. amchart amchart는 기본적으로 유료이며, 기본으로 제공하는 차트 종류가 기본적인 차트 + 주식 처럼 보이는 차트 + 지도에 관련된 차트(?) 까지 하면, 기본 제공 하는 종류가 20개 내외 이려나, 일일이 세기에는 양이 좀 많아 보인다. 렌더링은 svg를 통하여 그려지고, 당연 반응형도 지원이 된다. 그러면, 이 둘중에 어떤것이 내 프로젝트에 적합 하냐는 것이 문제이다. 일단, 주식 처럼 보이는 차트나 지도에 관련된 차트(?)가 필요하면, amchart를 선택해야 되는 것은 맞다. 그건 당연한 것이니 빼고 얘기 해보자! 여러 종류의 차트가 필요하다면, 일단은 amchart를 염두해 두는 것이 좋다. 돈 낸 만큼은 하는 듯 하다. 하지만, 기본적인 막대 그래프, 도넛 차트 등, 아주 기본적인 차트들인데, Chart js도 amchart도 그러한 차트가 없을 때가 문제가 된다. 그렇다면, 조금이라도 커스텀이 용이한 것을 찾는 것이 좋을 것이다. 일단 amchart에서 custom이라고 검색 하였을 때, 검색 결과가 61가지가 나온다. 차트의 종류도 많고, 각 차트마다 들어가는 속성이 매우 많기 때문에, 웬만한 내용들은 속성 값을 어떻게 주느냐에 따라서 변경이 가능 하게 된다. 커스텀의 예를 들면, 기본적으로 도넛 파이의 형태를 띄면서, 화살표로 목표를 표시해주는 차트가 필요하다고 생각 해보자. 이것은 amchart로 만든 그래프이고 이것은 chart js로 만든 그래프이다. 모양이 살짝 다르긴 하지만, 완벽하게 똑같이 구현 할 수도 있다. amchart로 만든 그래프의 경우, 저것은 도넛그래프가 아닌 guage 그래프이다. 원래 게이지 그래프는 이와 같...

코드 땜장이

이 블로그 검색