E2E(End-to-End) 테스트와 Smoke Test의 차이점과 올바른 활용법

end-to-end smoke test는 배포 직후 또는 변경 직후, 서비스의 핵심 흐름이 최소한 깨지지 않았는지 빠르게 확인하는 통합 점검입니다. 쉽게 말하면, “이 서비스가 아주 기본적인 수준에서 살아 있는가?”를 보는 가장 얇고 빠른 전 구간 테스트입니다.

먼저 용어부터 정리합니다

Smoke Test

원래 의미는 “연기(smoke)가 나는지 본다”는 뜻에서 왔습니다.
예전 하드웨어나 시스템을 켰을 때 불이 나거나 완전히 죽었는지 먼저 확인하는 데서 유래한 표현입니다.

현재 소프트웨어에서의 smoke test는 다음 의미로 쓰입니다.

서비스가 기동되는지
주요 엔드포인트가 응답하는지
핵심 기능이 최소한 동작하는지
배포 후 즉시 치명적 장애가 없는지

즉, 깊이 있는 검증이 아니라 생존 여부 확인입니다.

End-to-End(E2E)

E2E는 사용자 관점에서 처음부터 끝까지 한 흐름을 실제처럼 검증하는 방식입니다.

로그인
목록 조회
상세 조회
저장
결제
알림 발송

중간에 API, DB, 캐시, 외부 연동, 프론트 화면까지 모두 포함될 수 있습니다.

End-to-End Smoke Test

둘을 합치면 이런 의미가 됩니다.

“실제 사용자 흐름을 아주 짧고 핵심적으로만 잡아, 배포 후 서비스 전체가 기본적으로 정상인지 확인하는 테스트”

즉,
E2E의 범위를 쓰되, smoke 수준으로 최소 핵심만 짧게 검사하는 것입니다.

왜 필요한가

배포는 성공했는데 실제 서비스는 깨져 있는 경우가 많습니다.
대표적인 원인은 아래와 같습니다.

환경 변수 누락
DB 연결 실패
마이그레이션 누락
인증 설정 오류
프론트와 백엔드 버전 불일치
외부 API 키 문제
라우팅/Ingress/SSL 설정 오류
권한 문제
비밀값(Secret) 오기입

이런 문제는 단위 테스트만으로는 잘 못 잡습니다.
그래서 배포 직후 최소한의 사용자 흐름을 빠르게 확인하는 smoke test가 중요합니다.

smoke test와 다른 테스트의 차이

1) Unit Test

함수, 메서드, 클래스 단위 검증
빠르고 촘촘함
외부 시스템 의존 적음

2) Integration Test

모듈 간 연동 검증
DB, API, 메시지 큐 등과의 연결 확인

3) E2E Test

사용자 흐름 전체 검증
가장 현실적이지만 느리고 유지비가 큼

4) Smoke Test

전체를 다 보지 않고 핵심만 빠르게 확인
“이 배포가 아예 망가졌는지”를 먼저 판별
실패하면 즉시 배포 중단/롤백 판단에 도움

300x250

정리하면,

Unit: 내부 로직
Integration: 구성 요소 간 연결
E2E: 사용자 전체 여정
Smoke: 전체 여정 중 핵심만 빠르게 살아 있는지 확인

smoke test에서 주로 확인하는 것

서비스마다 다르지만 일반적으로 아래가 핵심입니다.

웹 서비스

메인 페이지 접속 가능
로그인 가능
핵심 API 호출 가능
주요 화면 렌더링 정상
폼 제출 정상
로그아웃 정상

API 서비스

/health
/ready
주요 비즈니스 API 1~3개
인증 토큰 발급
DB 조회/등록 최소 1건

배치/백엔드 서비스

프로세스 기동
설정 파일 로딩
큐 소비 가능
외부 연동 성공
샘플 데이터 처리 가능

Kubernetes / 컨테이너 환경

Pod Running 여부
Readiness/Liveness 정상
Service/Ingress 연결 정상
ConfigMap/Secret 반영 정상
외부 트래픽 진입 가능

좋은 smoke test의 조건

smoke test는 많이 하면 안 됩니다.
너무 무거워지면 smoke가 아니라 일반 E2E가 됩니다.

좋은 smoke test는 다음 조건을 만족해야 합니다.

빠를 것: 몇 초~수 분 내 종료
핵심만 볼 것: 가장 중요한 경로만
신뢰할 것: 실패하면 실제 장애 가능성이 높아야 함
반복 가능할 것: 항상 같은 조건에서 실행 가능
환경 의존을 줄일 것: 외부 불안정성은 최소화
진단 가능할 것: 실패했을 때 원인 파악이 쉬울 것

언제 실행하는가

보통 다음 시점에 실행합니다.

배포 직후

가장 흔합니다.
새 버전이 올라간 직후 기본 기능 점검용입니다.

인프라 변경 후

DB 변경
인증서 교체
Ingress/Nginx 변경
환경변수 변경
네트워크 정책 변경

장애 복구 후

복구가 끝나면 서비스가 실제로 정상인지 확인합니다.

정기 점검

매일/매주 주요 경로가 살아 있는지 자동 점검하기도 합니다.

smoke test의 구성 방식

보통 아래 레이어로 구성합니다.

1) 기동 확인

프로세스가 살아 있는가
컨테이너가 Running인가
포트가 열려 있는가

2) 연결 확인

DB 연결
캐시 연결
메시지 브로커 연결
외부 API 연결

3) 핵심 기능 확인

로그인
조회
저장
전송
알림

4) 결과 검증

응답 코드
화면 요소 존재
DB에 반영됨
메시지 발행됨

실제 운영에서는 어떻게 설계하는가

실무에서는 보통 아래 원칙으로 갑니다.

원칙 1. 가장 중요한 사용자 여정 1~3개만

로그인
주문 생성
결제 완료

원칙 2. 테스트 데이터는 고정

매번 새 데이터를 만들거나 정리해야 하면 실패가 많아집니다.
가능하면 전용 테스트 계정과 전용 테스트 데이터셋을 둡니다.

원칙 3. 외부 의존은 분리

외부 결제, 외부 메일, 외부 SMS까지 모두 실제 호출하면 smoke test가 불안정해집니다.
필요하면 mock 또는 sandbox를 사용합니다.

원칙 4. 실패 시 롤백 판단 기준을 명확히

smoke test가 실패하면

배포 실패로 볼지
일부 기능만 차단할지
롤백할지
수동 확인 후 진행할지

이 기준이 사전에 있어야 합니다.

예시 시나리오

예시 1. 쇼핑몰 서비스

홈 페이지 접속
로그인
상품 검색
장바구니 담기
주문 생성
주문 완료 화면 확인

이 중 smoke test는 보통 2~3개만 잡습니다.

로그인 성공
상품 상세 열림
장바구니 추가 가능

예시 2. 내부 업무 시스템

로그인
대시보드 조회
공지/리포트 화면 열림
신규 등록 기능 실행

여기서는 핵심 업무 흐름만 확인합니다.

예시 3. API 서버

/health 200 OK
/ready 200 OK
인증 토큰 발급 성공
주요 조회 API 200 OK
샘플 등록 API 성공

구현 방법

환경에 따라 구현 방식이 다릅니다.

A. Bash + curl

가장 단순한 방식입니다.

#!/usr/bin/env bash
set -euo pipefail

BASE_URL="https://example.com"

curl -fsS "$BASE_URL/health" >/dev/null
curl -fsS "$BASE_URL/api/version" >/dev/null

echo "smoke test passed"

장점

간단함
CI에 넣기 쉬움

단점

화면 검증이 어려움
복잡한 흐름에는 부족

B. Python + requests

API 중심 smoke test에 좋습니다.

import sys
import requests

base_url = "https://example.com"

def check(url: str) -> None:
    r = requests.get(url, timeout=10)
    r.raise_for_status()

check(f"{base_url}/health")
check(f"{base_url}/api/version")

print("smoke test passed")

C. Playwright

웹 E2E smoke test에 적합합니다.

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

test('smoke: login and dashboard', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveTitle(/Example/);

  await page.click('text=Login');
  await page.fill('#username', process.env.TEST_USER ?? '');
  await page.fill('#password', process.env.TEST_PASS ?? '');
  await page.click('button[type=submit]');

  await expect(page.locator('h1')).toContainText('Dashboard');
});

장점

실제 사용자처럼 확인
화면 요소 검증 가능

단점

유지보수 비용 존재
UI 변경에 민감

D. Cypress

프론트 중심 검증에 많이 씁니다.

describe('smoke', () => {
  it('loads the home page', () => {
    cy.visit('https://example.com')
    cy.contains('Welcome')
  })
})

E. k6 / Locust

보통은 부하 테스트용이지만, 간단한 헬스체크 smoke 용도로도 사용합니다.

CI/CD에 넣는 방식

smoke test는 배포 파이프라인에서 아주 자주 씁니다.

코드 빌드
이미지 생성
스테이징 배포
smoke test 실행
성공하면 다음 단계
실패하면 배포 중단 또는 롤백

smoke_test:
  stage: test
  script:
    - npm ci
    - npx playwright test smoke.spec.ts
  only:
    - main

중요한 점은 smoke test가 배포 성공 판정의 게이트 역할을 한다는 것입니다.

운영 관점에서 꼭 봐야 할 포인트

보안이나 운영 입장에서는 단순 “성공/실패”보다 다음이 중요합니다.

1) 인증 정보 관리

테스트 계정은 최소 권한이어야 함
운영 계정 사용 금지
Secret은 CI 변수 또는 Vault 사용

2) 테스트 데이터 보호

실제 고객 데이터 사용 금지
개인정보가 섞이지 않도록 분리
마스킹 또는 더미 데이터 사용

3) 외부 연동 영향

실메일/실문자 발송 주의
결제 승인 실제 발생 방지
외부 시스템에 테스트 트래픽이 누적되지 않도록 설계

4) 테스트 계정 감사

누가 사용했는지 추적
만료 정책 설정
접근 로그 보관

5) 장애 오탐 방지

네트워크 일시 장애
외부 API 지연
인증서 만료
DNS 오류

smoke test가 실패했을 때 진짜 장애인지, 테스트 자체 문제인지 구분 가능해야 합니다.

자주 하는 실수

1) smoke test를 너무 많이 넣는 경우

그러면 느리고 불안정해집니다.
핵심만 남겨야 합니다.

2) 운영 데이터로 테스트하는 경우

매우 위험합니다.
오염, 누락, 개인정보 문제로 이어질 수 있습니다.

3) UI 변화에 너무 민감한 경우

버튼 문구 하나 바뀌어도 실패하면 운영이 피곤해집니다.
핵심 요소 위주로 안정적으로 잡아야 합니다.

4) 실패 기준이 모호한 경우

어디까지 실패로 볼지 명확하지 않으면 배포 판단이 애매해집니다.

5) 테스트 자체가 길어지는 경우

smoke는 “짧게”가 핵심입니다.
길어지면 정기 점검용 E2E로 분리하는 것이 맞습니다.

실무에서 추천하는 구성 예시

아주 기본형

/health
/ready
로그인
대시보드 진입

서비스형 웹앱

홈 접속
로그인
핵심 목록 조회
핵심 등록 1건
완료 메시지 확인

API 중심 서비스

헬스체크
토큰 발급
주요 조회 API
주요 쓰기 API 1건

Kubernetes 배포 후

Pod 상태 확인
서비스 엔드포인트 확인
내부 헬스체크 API 호출
Ingress 통해 외부 접속 확인

실패했을 때 해석 방법

smoke test 실패는 보통 아래 4가지로 나눠 봅니다.

1) 애플리케이션 자체 문제

코드 오류
설정 오류
마이그레이션 실패

2) 인프라 문제

Pod CrashLoop
DNS 문제
LB/Ingress 오류
인증서 문제

3) 의존성 문제

DB 다운
Redis 장애
외부 API 불가

4) 테스트 문제

테스트 계정 만료
스크립트 오류
셀렉터 변경
환경 변수를 잘못 읽음

운영에서는 이 분류가 매우 중요합니다.
그래야 롤백인지, 재시도인지, 테스트 수정인지 판단할 수 있습니다.

권장 운영 절차

실무적으로는 아래 흐름이 가장 안정적입니다.

배포 수행
기동 로그 확인
/health 확인
핵심 E2E smoke test 실행
결과 저장
실패 시 알림 발송
필요 시 자동 롤백
성공 시 다음 단계 진행

결과 보고 예시

smoke test 결과는 아래처럼 짧고 명확하게 남기는 것이 좋습니다.

[Smoke Test Result]
- Target: staging.example.com
- Time: 2026-05-23 14:30 KST
- Health Check: PASS
- Login Flow: PASS
- Dashboard Load: PASS
- API /orders: PASS
- Overall: PASS

실패 시에는 아래처럼 남깁니다.

[Smoke Test Result]
- Target: production.example.com
- Time: 2026-05-23 14:30 KST
- Health Check: PASS
- Login Flow: FAIL
- Error: 401 Unauthorized
- Suspected Cause: auth config mismatch
- Overall: FAIL

end-to-end smoke test는 “배포나 변경 직후, 실제 사용자 흐름의 핵심만 최소한으로 확인해서 서비스가 정상 상태인지 빠르게 판별하는 테스트”입니다.

728x90

그리드형(광고전용)

저작자표시 비영리 동일조건 (새창열림)

E2E(End-to-End) 테스트와 Smoke Test의 차이점과 올바른 활용법

E2E(End-to-End) 테스트와 Smoke Test의 차이점과 올바른 활용법

먼저 용어부터 정리합니다

Smoke Test

End-to-End(E2E)

End-to-End Smoke Test

왜 필요한가

smoke test와 다른 테스트의 차이

1) Unit Test

2) Integration Test

3) E2E Test

4) Smoke Test

smoke test에서 주로 확인하는 것

웹 서비스

API 서비스

배치/백엔드 서비스

Kubernetes / 컨테이너 환경

좋은 smoke test의 조건

언제 실행하는가

배포 직후

인프라 변경 후

장애 복구 후

정기 점검

smoke test의 구성 방식

1) 기동 확인

2) 연결 확인

3) 핵심 기능 확인

4) 결과 검증

실제 운영에서는 어떻게 설계하는가

원칙 1. 가장 중요한 사용자 여정 1~3개만

원칙 2. 테스트 데이터는 고정

원칙 3. 외부 의존은 분리

원칙 4. 실패 시 롤백 판단 기준을 명확히

예시 시나리오

예시 1. 쇼핑몰 서비스

예시 2. 내부 업무 시스템

예시 3. API 서버

구현 방법

A. Bash + curl

B. Python + requests

C. Playwright

D. Cypress

E. k6 / Locust

CI/CD에 넣는 방식

운영 관점에서 꼭 봐야 할 포인트

1) 인증 정보 관리

2) 테스트 데이터 보호

3) 외부 연동 영향

4) 테스트 계정 감사

5) 장애 오탐 방지

자주 하는 실수

1) smoke test를 너무 많이 넣는 경우

2) 운영 데이터로 테스트하는 경우

3) UI 변화에 너무 민감한 경우

4) 실패 기준이 모호한 경우

5) 테스트 자체가 길어지는 경우

실무에서 추천하는 구성 예시

아주 기본형

서비스형 웹앱

API 중심 서비스

Kubernetes 배포 후

실패했을 때 해석 방법

1) 애플리케이션 자체 문제

2) 인프라 문제

3) 의존성 문제

4) 테스트 문제

권장 운영 절차

결과 보고 예시

관련글

댓글

티스토리툴바