스모크 테스트

스모크 테스트는 긴 시험을 돌리기 전에 가장 기본적인 것이 돌아가는지부터 짧게 확인합니다. 여기서 막히면 뒤의 시험은 돌려 봐야 헛수고입니다. 성능 테스트에서는 요청을 대량으로 보내기 전에 가짜 사용자 한두 명으로 시험 대본이 끝까지 도는지 먼저 봅니다. 빌드나 배포 직후에 핵심 기능만 빠르게 훑는 확인도 같은 이름을 씁니다.

쉽고 빠른 이해

본 시험에 들어가기 전에 「일단 켜지기는 하나」를 몇 분 안에 확인하는 시험입니다. 한 시간짜리 부하 시험을 걸기 전에 가짜 사용자 한 명으로 사용 흐름을 한 바퀴 돌려 보는 것이 그런 시험입니다.

긴 시험은 준비하고 돌리는 데 시간이 많이 듭니다. 그런데 로그인 한 줄이 틀려 있으면 그 한 시간 내내 실패만 쌓입니다. 짧은 확인을 앞에 두면 이런 헛수고를 몇 분 만에 걸러 냅니다.

어떻게 하나:

1. 가장 기본이 되는 흐름만 골라 아주 작은 규모로 돌립니다
2. 오류 없이 끝까지 가는지, 결과가 제대로 모이는지 봅니다
3. 통과하면 본 시험으로 넘어갑니다. 막히면 고친 뒤 다시 돌립니다

통과해도 시스템이 튼튼하다는 뜻은 아닙니다. 얕게만 훑으므로 알려 주는 것은 「본 시험을 걸어도 된다」까지입니다. 본 시험이 몇십 초면 끝나는 작은 프로젝트라면 따로 둘 까닭이 적습니다.

상세

새로 산 전기난로를 처음 켤 때는 방이 몇 도까지 데워지는지부터 재지 않습니다. 일단 켜 보고 연기나 타는 냄새가 나지 않는지부터 봅니다. 연기가 나면 온도계를 꺼낼 것도 없이 플러그를 뽑습니다.

이 시험의 이름도 비슷한 장면에서 왔다고 흔히 설명합니다. 새로 만든 전자 기판에 처음 전원을 넣고 연기가 피어오르는지부터 보던 확인입니다.

스모크 테스트는 본격적인 시험에 앞서 가장 기본적인 것이 돌아가는지만 짧고 얕게 확인합니다. 예를 들어 로그인하고 첫 화면을 여는 흐름 하나를 한 번만 돌려 봅니다. 오류 없이 끝까지 가면 통과입니다.

이 시험을 따로 두는 까닭은 뒤에 오는 시험이 비싸기 때문입니다. 큰 시험은 준비에 품이 듭니다. 한 번 도는 데 몇십 분에서 몇 시간이 걸리기도 합니다. 그런데 요청 주소 한 줄이 틀렸거나 서버가 아예 안 떠 있으면, 그 시간 내내 실패만 쌓입니다.

스모크 테스트는 이런 실패를 몇 분 안에 걸러 냅니다. 통과하지 못하면 본 시험을 시작하지 않습니다. 기본이 안 되는 상태에서 얻은 결과는 읽어 봐야 남는 것이 없습니다.

이 이름을 쓰는 두 분야

이 소절은 스모크 테스트라는 이름이 어느 분야에서 무슨 뜻으로 쓰이는지를 봅니다. 두 분야의 뜻을 표 하나로 나란히 놓습니다.

시스템에 한꺼번에 걸리는 일감의 양을 부하라고 합니다. 웹 서비스라면 대개 동시에 들어오는 요청 수로 잽니다.

이 부하를 일부러 크게 걸어 시스템의 속도와 버티는 힘을 재는 시험이 성능 테스트입니다. 스모크 테스트의 첫째 뜻은 이 성능 테스트 안에서 쓰입니다.

소스 코드를 실행할 수 있는 프로그램으로 만드는 일을 빌드라고 합니다. 그렇게 만들어진 프로그램 한 벌도 빌드라고 부릅니다. 코드를 고칠 때마다 새로 빌드해야 고친 내용이 프로그램에 들어갑니다.

빌드한 프로그램을 서버에 올려 손님이 쓰게 하는 일은 배포입니다. 스모크 테스트의 둘째 뜻은 이 빌드와 배포 과정에서 쓰입니다.

두 뜻은 「본 일 앞에서 짧게 기본부터 본다」는 생각을 같이 합니다. 다른 것은 무엇을 기본으로 보느냐입니다. 아래 두 소절이 두 뜻을 차례로 풉니다.

성능 테스트 앞에 거는 스모크 테스트

이 소절은 성능 테스트 쪽 뜻을 봅니다. 무엇을 돌리고, 무엇을 확인하고, 본 시험과 어떻게 이어지는지를 차례로 짚습니다.

성능 테스트는 도구가 가짜 사용자를 여럿 띄워 요청을 보내는 식으로 돕니다. 요청을 보내는 가짜 사용자 하나하나를 가상 사용자라고 부릅니다. 가상 사용자를 백 명 띄우면 사람 백 명이 동시에 쓰는 것처럼 요청이 들어갑니다.

가상 사용자가 어떤 순서로 무엇을 요청할지 적어 둔 대본을 시나리오라고 합니다. 로그인하고, 상품을 찾고, 장바구니에 담는 흐름이 시나리오 하나가 됩니다. 성능 테스트는 이 시나리오를 여러 가상 사용자가 동시에 되풀이하게 해서 부하를 만듭니다.

이 분야의 스모크 테스트는 가상 사용자를 한두 명만 띄워 시나리오를 몇 분 동안 돌립니다. 부하를 거는 것이 목적이 아닙니다. 시나리오가 끝까지 도는지 보는 것이 목적입니다. 그래서 거는 부하는 평소 손님 수보다도 훨씬 적습니다.

시험이 끝나면 숫자가 남습니다. 요청을 보내고 답을 받기까지 걸린 시간이 응답 시간입니다. 보낸 요청 가운데 실패한 것의 비율은 오류율입니다. 이 숫자들이 모여야 시험을 돌린 보람이 있습니다.

스모크 테스트는 이 짧은 시험으로 세 가지를 확인합니다. 셋 가운데 하나라도 어긋나면 본 시험에서 나온 숫자를 믿을 수 없습니다.

셋째 줄은 놓치기 쉽습니다. 시험은 끝났는데 결과 파일이 비어 있거나 그래프가 안 그려지는 경우입니다. 스모크 테스트를 돌린 뒤 결과 화면까지 열어 보면 이런 일을 미리 막습니다.

본 시험과 이어지는 순서

스모크 테스트는 성능 테스트의 맨 앞에 섭니다. 그 뒤로 부하를 키운 본 시험이 옵니다. 예상하는 최대 부하를 걸어 보는 부하 테스트가 그런 본 시험입니다. 한계를 넘겨 어디서 무너지는지 보는 스트레스 테스트도 본 시험에 듭니다.

flowchart TD
    A["시나리오를 적는다"] --> B["스모크 테스트 · 가상 사용자 한두 명"]
    B --> C{"끝까지 오류 없이 돌았나"}
    C -->|아니다| D["시나리오나 시스템을 고친다"]
    D --> B
    C -->|그렇다| E["부하 테스트 · 스트레스 테스트"]

그림에서 고치고 다시 돌리는 고리가 스모크 테스트 안에서 닫힙니다. 한 바퀴에 몇 분이면 되므로 이 되풀이는 싸게 끝납니다. 같은 고리가 한 시간짜리 본 시험 안에서 돌았다면 한 바퀴마다 한 시간씩 들었을 것입니다.

실패 원인을 가르는 몫

스모크 테스트가 가장 큰 도움을 주는 때는 오히려 본 시험이 실패했을 때입니다. 큰 부하에서 오류가 쏟아지면 원인은 둘 가운데 하나입니다. 시스템이 부하를 못 견뎠을 수도 있습니다. 시나리오가 처음부터 틀렸을 수도 있습니다.

스모크 테스트를 먼저 통과했다면 둘째 가능성은 거의 지워집니다. 적은 부하에서는 멀쩡했으니, 큰 부하에서 생긴 오류는 부하 탓으로 읽을 수 있습니다. 두 원인이 섞여 있으면 결과를 읽는 데만 한참이 걸립니다.

스모크 테스트에서 나온 응답 시간은 비교의 출발점도 됩니다. 사용자가 한두 명일 때 걸린 시간을 알면, 부하를 올렸을 때 얼마나 느려졌는지 셀 수 있습니다. 이렇게 비교의 기준으로 삼는 값을 성능 기준선이라고 합니다.

빌드와 배포 뒤에 거는 스모크 테스트

이 소절은 둘째 뜻을 봅니다. 새로 만든 프로그램을 다음 단계로 넘겨도 되는지 가르는 시험입니다.

코드를 합칠 때마다 빌드와 시험을 자동으로 돌리는 방식을 지속적 통합이라고 합니다. 영어로 CI(Continuous Integration, 지속적 통합)라고 줄여 부릅니다. 빌드가 끝나면 오래 걸리는 시험을 모두 돌리기 전에 스모크 테스트를 먼저 겁니다.

이때 스모크 테스트는 기능을 넓게, 그러나 얕게 훑습니다. 프로그램이 뜨는지, 첫 화면이 열리는지, 로그인이 되는지, 데이터베이스에 붙는지를 한 번씩만 봅니다. 기능 하나하나가 맞는 값을 내는지는 뒤의 긴 시험이 맡습니다.

시험을 맡은 팀에 새 빌드를 넘기기 전에도 같은 확인을 합니다. 기본도 안 되는 빌드를 받으면 그 팀의 하루가 헛돕니다. 그래서 이 뜻의 스모크 테스트를 빌드 확인 테스트라고도 부릅니다.

배포 직후에도 겁니다. 새 판을 서버에 올린 뒤 핵심 요청 몇 개를 보내 제대로 답하는지 봅니다. 여기서 막히면 이전 판으로 되돌립니다. 이렇게 되돌리는 작업을 롤백이라고 합니다.

서버가 살아 있는지 주기적으로 묻는 헬스 체크와 닮았습니다. 헬스 체크는 서버가 켜져 있는 동안 계속 묻습니다. 스모크 테스트는 새 판을 올린 직후에 한 번 겁니다. 헬스 체크가 대개 「살아 있다」는 대답 하나만 보는 데 비해, 스모크 테스트는 로그인 같은 사용 흐름을 따라갑니다.

이웃한 시험과 가르는 선

스모크 테스트와 자주 섞이는 이름이 둘 있습니다. 회귀 테스트와 새니티 테스트입니다. 셋 다 기능이 동작하는지 보는 시험이라 헷갈립니다. 이 소절은 얼마나 넓게 보는지와 얼마나 깊게 보는지로 셋을 가릅니다.

회귀 테스트는 코드를 고친 뒤 멀쩡하던 기능이 망가지지 않았나 보는 시험입니다. 고친 곳과 멀어 보이는 기능까지 다시 돌려 봅니다.

새니티 테스트는 방금 고친 기능 둘레만 조금 깊게 보는 시험입니다. 작은 수정을 받은 직후에 그 수정이 제대로 들어갔는지 확인합니다.

아래 표는 세 시험을 넓이와 깊이, 거는 때로 나란히 놓습니다.

회귀 테스트는 기존 기능을 넓게 보는 점이 스모크 테스트와 같습니다. 다른 것은 깊이입니다. 결과 값이 맞는지까지 따지므로 훨씬 오래 걸립니다.

새니티 테스트는 팀마다 뜻이 갈립니다. 스모크 테스트와 같은 말로 쓰는 곳도 있습니다. 남의 글에서 두 이름을 만나면 어느 뜻으로 썼는지 먼저 봅니다.

쓰는 때와 드는 비용

스모크 테스트는 본 시험이 길고 비쌀수록 값을 합니다. 한 시간짜리 부하 시험, 수백 개짜리 시험 묶음, 여러 서버에 올리는 배포 앞에 둡니다. 반대로 시험 전체가 몇십 초면 끝나는 작은 프로젝트라면 따로 떼어 둘 까닭이 적습니다.

대가의 첫째는 통과가 주는 믿음이 실제보다 커지기 쉽다는 점입니다. 스모크 테스트는 켜지고 도는지만 봅니다. 그러니 통과는 「본 시험을 걸어도 된다」 이상을 말해 주지 않습니다.

둘째는 돌봐야 할 시험이 하나 는다는 점입니다. 기능이 바뀌면 스모크 테스트가 따라가는 흐름도 같이 고쳐야 합니다. 이걸 미루면 멀쩡한 빌드가 낡은 스모크 테스트에 막힙니다.

관련 항목

스모크 테스트와 목적이 갈리는 성능 시험

성능 테스트 · 부하 테스트 · 스트레스 테스트 · 스파이크 테스트 · 소크 테스트 · 벤치마크

스모크 테스트를 돌리는 부하 도구와 설정값

k6 · Locust · JMeter · Gatling · 부하 생성기 · 가상 사용자 · 시나리오 · 부하

스모크 테스트가 확인하는 지표

응답 시간 · 오류율 · 처리량 · 백분위수 · 성능 기준선

스모크 테스트가 끼어드는 빌드와 배포 단계

빌드 · 지속적 통합 · 지속적 전달 · 지속적 배포 · 배포 · 배포 파이프라인 · 커밋에서 배포까지

스모크 테스트에서 막힌 새 판을 되돌리거나 가리는 장치

롤백 · 헬스 체크 · 카나리 배포 · 블루-그린 배포 · 기능 플래그

스모크 테스트와 범위가 갈리는 기능 시험

새니티 테스트 · 회귀 테스트 · 단위 테스트 · 통합 테스트 · 종단 간 테스트 · 인수 테스트 · QA와 테스트 · 테스트 자동화