모바일 개발에서의 Smoke Test — 정의, 작업 및 적용 방법

저자: IT Sectr 게시일: 2026-04-08 읽는 시간: 9 분

Smoke Test(스모크 테스트)는 모바일 애플리케이션 빌드 후 핵심 기능이 작동하는지 확인하기 위해 수행되는 최소한의 검사 세트입니다. Smoke Test를 통해 전체 회귀 테스트 주기를 실행하지 않고도 불안정한 빌드를 신속하게 거부할 수 있습니다. Google Testing Blog(2024)에 따르면 Smoke Test는 개발자의 피드백 시간을 2~3시간에서 10~15분으로 단축합니다. Smoke Test는 CI/CD 파이프라인의 첫 번째 품질 필터로, 손상된 빌드가 다음 단계에 도달하는 것을 방지합니다.

핵심 사항

  • Smoke Test — 불안정한 빌드를 거부하기 위한 애플리케이션 핵심 기능의 빠른 확인.
  • 작업 — 사용자 중요 경로(로그인, 피드, 프로필)의 작동 확인.
  • Smoke Test는 회귀 테스트 전에 수행되며 일반적으로 5~15분이 소요됩니다.
  • CI/CD에서 Smoke Test 자동화는 현대 모바일 개발 파이프라인의 필수 요소입니다.
  • 회귀 테스트와의 차이 — Smoke Test는 중요 경로만 확인하고, 회귀 테스트는 전체 기능을 포괄합니다.

Smoke Test란?

Smoke Test(스모크 테스트)는 심층 분석 없이 애플리케이션의 핵심 기능을 확인하는 일련의 빠른 테스트입니다. 이 용어는 하드웨어 엔지니어링에서 유래했습니다: 조립 후 장치에서 연기가 나기 시작하면 전체 테스트로 보내지 않습니다. 모바일 개발에서 Smoke Test는 동일한 기능을 수행합니다 — 명백히 작동하지 않는 빌드를 걸러냅니다. Microsoft DevOps(2024)에 따르면 Smoke Test를 도입하면 QA 팀에 도달하는 결함 수가 40% 감소합니다.

Smoke Test는 모든 새 빌드에서 실행됩니다 — Android와 iOS 모두에서. 이상적으로 Smoke Test는 15분을 넘지 않아야 하며 빌드 성공 후 자동으로 시작되어야 합니다. 통과 기준 — Smoke Test 스위트의 테스트 100%가 성공적으로 완료되어야 합니다. 하나라도 실패하면 빌드가 불안정한 것으로 표시되고 추가 테스트로 보내지지 않습니다. Google Testing Blog(2024)에 따르면 이 접근 방식은 사용자에게 기능을 제공하는 시간을 25% 단축합니다.

Smoke Test는 수동(5~10개 항목의 체크리스트) 또는 자동화될 수 있습니다. 현대 모바일 프로젝트에서는 CI/CD에 내장된 자동화된 Smoke Test가 선호됩니다. 수동 Smoke Test는 자동화가 경제적으로 실현 가능하지 않은 프로젝트 초기 단계에서만 정당화됩니다. Bitrise(2025)에 따르면 모바일 개발 팀의 73%가 Smoke Test를 자동화하고 있습니다.

Smoke Test와 회귀 테스트의 차이점

Smoke Test와 회귀 테스트는 종종 혼동되지만, 목표가 다른 별개의 관행입니다. 회귀 테스트는 코드 변경이 기존 기능을 손상시키지 않았는지 확인합니다. 애플리케이션의 모든 모듈과 시나리오를 포괄하며, 드문 경우와 경계 사례를 포함합니다. Smoke Test는 중요 경로만 확인합니다 — 애플리케이션이 쓸모없게 되는 핵심 시나리오입니다. 포괄 깊이가 주요 차이점입니다: Smoke Test는 기능의 5~10%를 포괄하고, 회귀 테스트는 80~100%를 포괄합니다.

두 번째 차이점은 실행 시간입니다. 모바일 애플리케이션의 회귀 테스트 스위트는 프로젝트 규모와 플랫폼 수에 따라 2~12시간이 소요될 수 있습니다. Smoke Test는 5~15분이 소요됩니다. Sauce Labs(2025)에 따르면 iOS 애플리케이션의 회귀 스위트 평균 실행 시간은 4.5시간, Android는 3.2시간입니다. 두 플랫폼에서 Smoke Test는 10~15분 안에 완료됩니다.

세 번째 차이점은 파이프라인 내 위치입니다. Smoke Test는 빌드 직후, 회귀 테스트 전에 실행됩니다. Smoke Test가 실패하면 회귀 테스트가 시작되지 않습니다 — 이는 CI/CD 리소스를 절약합니다. 파이프라인 효율성 — Smoke Test는 회귀 테스트에서 실패했을 빌드의 최대 30%를 걸러내고, 절약된 리소스로 다른 작업을 병렬로 실행할 수 있습니다.

매개변수Smoke Test회귀 테스트
목표중요 경로 빠른 확인전체 기능 확인
범위5~10% 시나리오80~100% 시나리오
시간5~15분2~12시간
빈도모든 빌드릴리스 전 또는 매일
CI/CD빌드 후, 회귀 전Smoke Test 후

모바일 앱 Smoke Test에 포함되는 항목

앱 실행

앱 실행 — 첫 번째이자 가장 중요한 테스트. 애플리케이션은 모든 대상 장치에서 충돌 없이 실행되어야 합니다. Smoke Test는 콜드 스타트를 확인합니다: 설치 → 열기 → 첫 화면 표시. 앱이 실행 시 충돌하면 추가 테스트는 의미가 없습니다. XCUITest와 Espresso를 사용하면 2~3줄의 코드로 실행 확인을 자동화할 수 있습니다. 실행 인수 `-AppleLanguages (ru)`는 시작 시 지역화 확인에 도움이 됩니다.

인증

인증 — 두 번째 중요 시나리오. Smoke Test는 로그인 양식이 표시되는지, 입력 필드가 터치에 반응하는지, 로그인 버튼이 요청을 보내는지, 인증 성공 후 애플리케이션이 메인 화면으로 이동하는지 확인해야 합니다. 인증 오류는 다른 모든 기능에 대한 접근을 차단하므로 최소 세트에 포함됩니다. 토큰 갱신 — OAuth 2.0을 사용하는 애플리케이션의 추가 확인 사항.

콘텐츠 로딩 및 탐색

주 콘텐츠 로딩 — 세 번째 Smoke Test. 애플리케이션의 메인 화면 또는 피드가 로드되어 데이터를 표시해야 합니다. API가 응답하지 않거나 응답 파싱이 손상된 경우 사용자는 빈 화면을 보게 됩니다. Smoke Test의 네트워크 확인에는 기본 엔드포인트에 대한 GET 요청과 응답이 예상 구조를 가지고 있는지 확인하는 것이 포함됩니다. 탐색 — 네 번째 시나리오. Smoke Test는 애플리케이션의 주요 화면을 탐색합니다: 홈 → 검색 → 프로필 → 설정. 탭 바와 사이드 메뉴는 Smoke Test가 초기에 발견하는 일반적인 탐색 문제의 원인입니다.

CI/CD에서 Smoke Test 자동화

Fastlane — 모바일 CI/CD 자동화를 위한 표준 도구. Fastlane에서 Smoke Test는 `scan`(XCUITest용) 또는 `gradle`(Espresso용)을 통해 실행됩니다. Fastlane을 사용하면 여러 장치에서 Smoke Test를 병렬로 실행하도록 구성할 수 있어 전체 시간이 단축됩니다. 구성 Fastfile에는 Smoke Test 스위트 대상 지정과 통과 임계값(100% 테스트 성공)이 포함됩니다.

GitHub Actions(2024)는 내장 Smoke Test가 포함된 모바일 CI/CD 템플릿을 발표했습니다. 템플릿에는 세 단계가 포함됩니다: 빌드 → Smoke Test → 회귀. Smoke Test가 실패하면 템플릿이 자동으로 파이프라인을 종료하고 Slack 또는 Telegram에 알림을 보냅니다. 매트릭스 전략을 통해 세 가지 iOS 버전과 다섯 가지 Android 모델에서 동시에 Smoke Test를 실행할 수 있습니다.

CI/CD에서의 책임 분담: Smoke Test는 빠른 피드백을 제공하고, 회귀 테스트는 완전한 포괄을 제공합니다. Smoke Test는 회귀 테스트를 중복해서는 안 되며 그 반대도 마찬가지입니다. Smoke Test의 세분성 — 중요 시나리오당 하나의 검사. Smoke Test가 15분 이상 소요되면 최적화해야 합니다: 중복 검사를 제거하거나 실행을 병렬화합니다.

ruby
# Smoke Test를 위한 Fastfile 구성
platform :ios do
    lane :smoke do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone SE'],
            testplan: 'SmokeTest',
            output_directory: 'reports/smoke',
            fail_build: true
        )
    end

    lane :regression do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone 14', 'iPhone SE'],
            testplan: 'FullRegression'
        )
    end
end

Smoke Test 도구

XCUITest — iOS 애플리케이션의 UI 테스트를 위한 Apple의 프레임워크. XCUITest는 Smoke Tests 자동화에 사용됩니다: 앱 실행, UI 요소 확인, 사용자 작업 시뮬레이션. Xcode Server 또는 GitHub Actions와 결합하면 XCUITest가 모든 커밋에서 실행됩니다. XCTest — 단위 테스트를 위한 기본 프레임워크로, 로직 확인을 위해 XCUITest를 보완합니다.

Espresso — Android UI 테스트를 위한 Google의 프레임워크. Espresso는 UI 스레드와 동기화되어 확인 시작 전에 모든 애니메이션이 완료되도록 보장합니다. Espresso는 `onView(withId(...)).check(matches(...))`를 통한 확인을 지원합니다. Android Test Orchestrator는 각 Smoke Test를 별도 프로세스에서 실행하여 이전 테스트가 이후 테스트에 영향을 미치는 것을 방지합니다.

Detox — React Native용 프레임워크로 Smoke Test와 그레이박스 테스트를 지원합니다. Detox는 React Native 브리지와 동기화되어 비동기 작업 완료를 자동으로 기다립니다. 그레이박스 테스트를 통해 Detox는 소스 코드에 직접 접근하지 않고도 애플리케이션 상태를 확인할 수 있습니다.

Swift 및 Kotlin의 Smoke Test 예제

XCUITest iOS용은 두 가지 확인을 포함합니다: 애플리케이션 실행 및 메인 화면 표시. 테스트는 `XCUIApplication().launch()`를 통해 앱을 실행하고 키 요소(예: `navigationBar`)가 존재하는지 확인합니다. 앱이 실행 시 충돌하면 XCTest 프레임워크가 오류를 기록하고 테스트는 FAIL로 종료됩니다. Smoke Test는 콘텐츠를 확인하지 않습니다 — 화면이 열렸는지만 확인합니다.

Espresso Android용은 Activity를 시작하기 위해 `ActivityScenario`를, 요소를 확인하기 위해 `onView`를 사용합니다. 플랫폼 간 중요한 차이점: iOS 시뮬레이터는 실제 장치와 다른 동작을 보일 수 있으므로 Android Smoke Tests는 Firebase Test Lab 또는 에뮬레이터에서 실행하는 것이 좋습니다. Firebase Test Lab은 10개 장치에서 Smoke Tests의 병렬 실행을 지원합니다.

swift
import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["로그인"].exists)
    }

    func testLoginFlow() {
        app.textFields["email"].tap()
        app.textFields["email"].typeText("test@test.com")
        app.secureTextFields["password"].tap()
        app.secureTextFields["password"].typeText("password123")
        app.buttons["Log In"].tap()
        XCTAssertTrue(app.staticTexts["Welcome"].waitForExistence(timeout: 5))
    }
}

위 예제는 iOS 로그인 화면에 대한 Smoke Test를 보여줍니다. 첫 번째 테스트는 로그인 버튼이 화면에 존재하는지 확인합니다. 두 번째 테스트는 전체 인증 경로를 실행하고 로그인 성공 후 환영 메시지가 표시되는지 확인합니다. `waitForExistence`의 타임아웃 5초는 Smoke Test의 표준 값입니다: UI 요소가 해당 시간 내에 나타나지 않으면 애플리케이션이 제대로 작동하지 않는 것입니다.

자주 묻는 질문

Smoke Test에 포함되어야 할 테스트 수는?

최적의 수는 모듈당 5~15개 테스트입니다. Smoke Test는 사용자의 중요 경로를 포괄해야 하지만 전체 기능을 포괄하려고 해서는 안 됩니다. 기준 — 모든 Smoke Test가 통과하면 애플리케이션을 QA 환경에서 열어 추가 테스트를 진행할 수 있습니다.

Smoke Test와 sanity check의 차이점은?

Smoke Test는 빌드 안정성을 확인하고 모든 빌드에서 실행됩니다. Sanity check는 특정 변경 후 수행되는 더 좁은 테스트 세트입니다. Sanity check는 "이 변경이 기능 X를 손상시켰습니까?"라는 질문에 답하고, Smoke Test는 "빌드가 기본적으로 작동합니까?"라는 질문에 답합니다.

Smoke Test를 자동화해야 합니까?

예, Smoke Test 자동화는 빈번한 릴리스가 있는 프로젝트의 필수 관행입니다. 자동화는 검사의 일관성과 실행 속도를 보장합니다. 수동 Smoke Test는 빌드 수가 주당 2~3개를 초과하지 않는 프로젝트 초기 단계에서만 정당화됩니다.

Smoke Test가 실패하면 어떻게 해야 합니까?

빌드가 불안정한 것으로 표시되고 추가 테스트로 보내지지 않습니다. 개발자는 Smoke Test 실패 로그와 함께 알림을 받습니다. 문제가 수정된 후 새 빌드가 생성되고 Smoke Test가 다시 실행됩니다. 차단 결함은 추적기에 기록됩니다.

Smoke Test를 얼마나 자주 업데이트해야 합니까?

Smoke Test는 사용자의 중요 경로가 변경될 때마다 업데이트됩니다. 새로운 필수 화면(예: 온보딩)이 추가되면 Smoke Test에 포함되어야 합니다. 검사의 관련성을 유지하기 위해 매 스프린트 Smoke Test 스위트를 검토하는 것이 좋습니다.

요약

  • Smoke Test — 모든 빌드 후 실행되는 애플리케이션 중요 경로의 최소 검사 세트.
  • 주요 검사 — 앱 실행, 인증, 콘텐츠 로딩 및 주요 화면 탐색.
  • 회귀 테스트와의 차이 — Smoke Test는 시나리오의 5~10%를 포괄하고 5~15분 소요(시간 단위 아님).
  • 도구 — iOS용 XCUITest, Android용 Espresso, React Native용 Detox.
  • 자동화 Smoke Test는 Fastlane, GitHub Actions 또는 Bitrise를 통해 CI/CD에 통합됩니다.
  • Smoke Test는 회귀 테스트 전에 실행되며 불안정한 빌드의 최대 30%를 걸러냅니다.
  • 매 스프린트 Smoke Test 구성을 검토하여 관련성을 유지하는 것이 좋습니다.

턴키 방식의 모바일 애플리케이션을 개발해 드립니다

IT Sectr는 2017년부터 스타트업과 기업을 위한 iOS 및 Android 애플리케이션을 만듭니다. 저희가 상담해 드리고 최적의 솔루션을 제안하겠습니다.

프로젝트 논의

더 읽어보기