Flaky E2E가 계속 납니다. 먼저 어디를 보나요?

data-testid 등 안정 셀렉터, cy.intercept 뒤엉킴, 타이밍을 억지로 고정(fixed wait)한 부분, 그리고 앱/테스트 둘 다에서 비결정적 API 응답이 있는지부터 봅니다.

CI에서만 실패해요. 로컬은 통과합니다.

뷰포트·타임존·locale, baseUrl, record 비디오/스샷 경로, 병렬 샤딩, 메모리 한도 등 CI 전용 환경 차이를 의심하고, 재현을 위해 seed 데이터와 API 목을 동일하게 맞춥니다.

cy.request와 cy.intercept는 언제 쓰나요?

UI 없이 API만 검증·준비할 때 request, 브라우저가 보내는 네트워크를 가로채 모킹·검증할 때 intercept—테스트가 네트워크에 의존하는지 먼저 정리하세요.

Cypress 10+ 컴포넌트 테스트와 E2E를 같이 쓸까요?

느리고 비싼 E2E는 핵심 유저 흐름에 두고, 반복·격리는 컴포넌트/단위 쪽에 두는 편이 유지보수에 유리합니다.

Cypress 완벽 가이드 | E2E 테스트·자동화·CI/CD·실전 활용

2026년 4월 7일 · 4분 읽기 · 수정 2026년 4월 18일 중급

이 글의 핵심

Cypress로 E2E 테스트를 구현하는 완벽 가이드. Commands, Assertions, Fixtures, Intercept, CI/CD 통합까지 실전 예제로 정리. Cypress·E2E·Testing 중심으로 설명합니다.

이 글의 핵심

Cypress로 E2E 테스트를 구현하는 완벽 가이드입니다. Commands, Assertions, Fixtures, Intercept, CI/CD 통합까지 실전 예제로 정리했습니다.

실무 경험 공유: Selenium에서 Cypress로 전환하면서, 테스트 작성 시간이 60% 단축되고 안정성이 크게 향상된 경험을 공유합니다.

들어가며: “E2E 테스트가 어려워요”

실무 문제 시나리오

시나리오 1: Selenium이 불안정해요

Flaky 테스트가 많습니다. Cypress는 자동 대기로 안정적입니다. 시나리오 2: 디버깅이 어려워요

에러 추적이 복잡합니다. Cypress는 Time Travel로 쉽게 디버깅합니다. 시나리오 3: 설정이 복잡해요

WebDriver 설정이 번거롭습니다. Cypress는 즉시 사용 가능합니다.

1. Cypress란?

핵심 특징

Cypress는 모던 E2E 테스트 프레임워크입니다. 주요 장점:

자동 대기: Flaky 테스트 방지
Time Travel: 디버깅 쉬움
실시간 리로드: 빠른 피드백
스크린샷/비디오: 자동 캡처
API Mocking: 네트워크 제어

2. 설치 및 설정

설치

npm install -D cypress

실행

npx cypress open

cypress.config.ts

import { defineConfig } from 'cypress';
export default defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000',
    setupNodeEvents(on, config) {
      // implement node event listeners here
    },
  },
  viewportWidth: 1280,
  viewportHeight: 720,
  video: true,
  screenshotOnRunFailure: true,
});

3. 기본 테스트

TypeScript/JavaScript 예제 코드입니다.

// cypress/e2e/login.cy.ts
describe('Login', () => {
  beforeEach(() => {
    cy.visit('/login');
  });
  it('로그인 성공', () => {
    cy.get('input[name="email"]').type('[email protected]');
    cy.get('input[name="password"]').type('password123');
    cy.get('button[type="submit"]').click();
    cy.url().should('include', '/dashboard');
    cy.contains('Dashboard').should('be.visible');
  });
  it('로그인 실패 - 잘못된 비밀번호', () => {
    cy.get('input[name="email"]').type('[email protected]');
    cy.get('input[name="password"]').type('wrong');
    cy.get('button[type="submit"]').click();
    cy.contains('Invalid credentials').should('be.visible');
  });
});

4. Commands

기본 Commands

// 방문
cy.visit('/');
// 선택
cy.get('.btn');
cy.contains('Submit');
cy.get('[data-testid="user-list"]');
// 액션
cy.get('input').type('Hello');
cy.get('button').click();
cy.get('select').select('Option 1');
cy.get('input[type="checkbox"]').check();
// Assertions
cy.get('.title').should('have.text', 'Hello');
cy.get('.btn').should('be.visible');
cy.get('.btn').should('be.disabled');
cy.url().should('include', '/dashboard');

5. Intercept (API Mocking)

TypeScript/JavaScript 예제 코드입니다.

describe('Users', () => {
  beforeEach(() => {
    cy.intercept('GET', '/api/users', {
      statusCode: 200,
      body: [
        { id: 1, name: 'John' },
        { id: 2, name: 'Jane' },
      ],
    }).as('getUsers');
    cy.visit('/users');
  });
  it('사용자 목록 표시', () => {
    cy.wait('@getUsers');
    cy.contains('John').should('be.visible');
    cy.contains('Jane').should('be.visible');
  });
});

6. Fixtures

Fixture 파일

// cypress/fixtures/users.json
[
  { "id": 1, "name": "John", "email": "[email protected]" },
  { "id": 2, "name": "Jane", "email": "[email protected]" }
]

사용

describe('Users', () => {
  beforeEach(() => {
    cy.fixture('users').then((users) => {
      cy.intercept('GET', '/api/users', users).as('getUsers');
    });
    cy.visit('/users');
  });
  it('사용자 목록 표시', () => {
    cy.wait('@getUsers');
    cy.contains('John').should('be.visible');
  });
});

7. Custom Commands

Chainable 함수를 다음과 같이 구현합니다.

// cypress/support/commands.ts
declare global {
  namespace Cypress {
    interface Chainable {
      login(email: string, password: string): Chainable<void>;
    }
  }
}
Cypress.Commands.add('login', (email, password) => {
  cy.visit('/login');
  cy.get('input[name="email"]').type(email);
  cy.get('input[name="password"]').type(password);
  cy.get('button[type="submit"]').click();
});
// 사용
cy.login('[email protected]', 'password123');

8. CI/CD 통합

GitHub Actions

# .github/workflows/cypress.yml
name: Cypress Tests
on: [push]
jobs:
  cypress-run:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Cypress run
        uses: cypress-io/github-action@v6
        with:
          build: npm run build
          start: npm start
          wait-on: 'http://localhost:3000'

9. Component Testing

// src/components/Button.cy.tsx
import Button from './Button';
describe('Button', () => {
  it('renders', () => {
    cy.mount(<Button label="Click me" />);
    cy.contains('Click me').should('be.visible');
  });
  it('handles click', () => {
    const onClickSpy = cy.spy().as('onClickSpy');
    cy.mount(<Button label="Click me" onClick={onClickSpy} />);
    cy.contains('Click me').click();
    cy.get('@onClickSpy').should('have.been.calledOnce');
  });
});

정리 및 체크리스트

핵심 요약

Cypress: E2E 테스트 프레임워크
자동 대기: Flaky 테스트 방지
Time Travel: 디버깅 쉬움
Intercept: API Mocking
Fixtures: 테스트 데이터
CI/CD: GitHub Actions 통합

구현 체크리스트

같이 보면 좋은 글

이 글에서 다루는 키워드

Cypress, E2E, Testing, Automation, CI/CD, Frontend, TypeScript

내부 동작과 핵심 메커니즘

이 글의 주제는 「Cypress 완벽 가이드 | E2E 테스트·자동화·CI/CD·실전 활용」입니다. 앞선 튜토리얼을 구현·런타임 관점에서 다시 압축합니다. 구성 요소 간 책임 분리와 관측 가능한 지점을 기준으로 “입력이 어디서 검증되고, 핵심 연산이 어디서 일어나며, 부작용(I/O·네트워크·디스크)·동시성이 어디서 터지는가”를 한 장면으로 그리면 장애 분석이 빨라집니다.

처리 파이프라인(개념도)

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

경계에서의 지연·실패(시퀀스 관점)

sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(프로세스·런타임·게이트웨이)
  participant D as 의존성(외부 API·DB·큐)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)

알고리즘·프로토콜·리소스 관점 체크포인트

불변 조건(Invariant): 각 단계가 만족해야 하는 조건(버퍼 경계, 프로토콜 상태, 트랜잭션 격리, 파일 디스크립터 상한)을 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 동일 입력에 동일 출력이 보장되는 순수 층과, 시간·네트워크·스레드 스케줄에 의해 달라질 수 있는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화/역직렬화, 문자 인코딩, syscall 횟수, 락 경합, GC·할당, 캐시 미스처럼 누적 비용을 의심 목록에 넣습니다.
백프레셔: 생산자가 소비자보다 빠를 때(소켓 버퍼, 큐 깊이, 스트림) 어디서 어떤 신호로 속도를 줄일지 정의합니다.

프로덕션 운영 패턴

실서비스에서는 기능과 함께 관측·배포·보안·비용·규제가 동시에 요구됩니다.

영역	운영 관점 질문
관측성	요청 단위 상관 ID, 에러율/지연 분위수(p95/p99), 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성	입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능	캐시 계층·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리/블루그린, 마이그레이션 호환성·플래그가 문서화되어 있는가
용량	피크 트래픽·디스크·파일 디스크립터·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 가능한 한 프로덕션에 가깝게 맞추는 것이 재현율을 높입니다.

확장 예시: 엔드투엔드 미니 시나리오

「Cypress 완벽 가이드 | E2E 테스트·자동화·CI/CD·실전 활용」을 실제 배포·운영 흐름으로 옮긴 체크리스트형 시나리오입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드 표를 API 또는 이벤트 경계에 둔다.
핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 한 화면(로그+메트릭+트레이스)에서 추적한다.
실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지(또는 피처 플래그) 확인한다.
부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값이 기대 범위인지 본다.

의사코드 스케치(프레임워크 무관)

handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)        // 경계에서 거절
  authorize(validated, ctx)                  // 권한·테넌트
  result = domainCore(validated)             // 순수에 가까운 규칙
  persistOrEmit(result, idempotentKey)       // I/O: 멱등·재시도 정책
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스, 타임아웃, 외부 의존성 불안정, DNS	최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하	N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납	상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패	환경 변수, 권한, 플랫폼 차이, lockfile	CI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정이 로컬과 다름	프로필·시크릿·기본값, 지역 리전	단일 소스(예: 스키마 검증된 설정)와 배포 매트릭스 표준화
데이터 불일치	비멱등 재시도, 부분 쓰기, 캐시 무효화 누락	멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

자주 묻는 질문 (FAQ)

Q. Playwright와 비교하면 어떤가요?

A. Cypress가 더 쉽고 DX가 좋습니다. Playwright는 더 빠르고 다양한 브라우저를 지원합니다.

Q. 실제 브라우저를 사용하나요?

A. 네, Chrome, Edge, Firefox를 지원합니다.

Q. 모바일 테스트도 가능한가요?

A. Viewport를 조정해 모바일 시뮬레이션이 가능합니다.

Q. 프로덕션에서 사용해도 되나요?

A. 네, 수많은 기업에서 안정적으로 사용하고 있습니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.

Keyboard Shortcuts

이 글의 핵심

이 글의 핵심

들어가며: “E2E 테스트가 어려워요”

실무 문제 시나리오

WebDriver 설정이 번거롭습니다. Cypress는 즉시 사용 가능합니다.

1. Cypress란?

핵심 특징

2. 설치 및 설정

설치

실행

cypress.config.ts

3. 기본 테스트

4. Commands

기본 Commands

5. Intercept (API Mocking)

6. Fixtures

Fixture 파일

사용

7. Custom Commands

8. CI/CD 통합

GitHub Actions

9. Component Testing

정리 및 체크리스트

핵심 요약

구현 체크리스트

같이 보면 좋은 글

이 글에서 다루는 키워드

내부 동작과 핵심 메커니즘

처리 파이프라인(개념도)

경계에서의 지연·실패(시퀀스 관점)

알고리즘·프로토콜·리소스 관점 체크포인트

프로덕션 운영 패턴

확장 예시: 엔드투엔드 미니 시나리오

의사코드 스케치(프레임워크 무관)

문제 해결(Troubleshooting)

자주 묻는 질문 (FAQ)

Q. Playwright와 비교하면 어떤가요?

Q. 실제 브라우저를 사용하나요?

Q. 모바일 테스트도 가능한가요?

Q. 프로덕션에서 사용해도 되나요?

이 글이 도움이 되셨나요?