스모크 테스트 — 배포 직후 '불이 켜지긴 하나'만 60초에 확인하는 얕고 빠른 그물

▶ 동영상 개요 — 스모크 테스트 — 배포 직후 '불이 켜지긴 하나'만 60초에 확인하는 얕고 빠른 그물

5분 45초 — 스모크 테스트는 얕고 빠른 관문이다 — 배포 직후 핵심 흐름 몇 개만 60초 안에 훑어 '더 볼 가치가 있는 빌드인가'만 판정한다. 단위 테스트가 목으로 가려… — NotebookLM 동영상 개요로 생성

🎧 오디오 개요 — 스모크 테스트 — 배포 직후 '불이 켜지긴 하나'만 60초에 확인하는 얕고 빠른 그물

24분 31초 — 스모크 테스트는 얕고 빠른 관문이다 — 배포 직후 핵심 흐름 몇 개만 60초 안에 훑어 '더 볼 가치가 있는 빌드인가'만 판정한다. 단위 테스트가 목으로 가려…. 화면은 이 글의 인포그래픽 한 장 고정 — NotebookLM 오디오 개요로 생성

집에 둔 개인 AI 서버에서 서비스를 여럿 돌린다. 코드를 고치고 서비스를 재시작하면 매번 같은 순간이 온다 — 브라우저를 새로고침하며 "떴나?"를 확인하는 몇 초다. 로그인 화면이 뜨고, 챗봇에 한마디 던져 답이 돌아오고, 검색창에 아무거나 쳐서 결과가 나오면 그제야 안심하고 다음 일로 넘어간다.

이 몇 초짜리 확인에는 정식 이름이 있다. 스모크 테스트(smoke test)다. 새로 만든 회로 기판에 전원을 넣고 "연기가 나는지" 지켜보던 데서 온 말이고, 배관공이 새로 깐 파이프에 연기를 불어넣어 새는 곳을 찾던 관행에서 왔다는 설도 있다. 어느 쪽이든 핵심은 같다 — 깊게 파기 전에, 이게 켜지기라도 하는지부터 본다. 소프트웨어에서는 배포된 빌드가 무너지지 않고 핵심 기능이 살아 있는지를 맨 처음 확인하는 절차이고, 그래서 빌드 검증 테스트(build verification testing)라고도 부른다.

스모크 테스트의 목적 — '더 볼 가치가 있는 빌드인가'

스모크 테스트가 답하는 질문은 딱 하나다. "이 빌드가 더 자세히 테스트할 만큼 안정적인가?" 통과하면 그제야 세부 테스트로 들어가고, 실패하면 거기서 멈춰 되돌린다. QA 자료들이 공통으로 강조하는 원칙이 이것이다 — 스모크 테스트의 존재 이유는 빠른 피드백이고, 만약 스모크 테스트가 회귀 테스트만큼 오래 걸린다면 그건 이미 목적을 잃은 것이다.

버스 예매 사이트를 예로 들면, 스모크 테스트는 로그인·좌석 예약·예약 취소·예약 알림 같은 핵심 흐름 몇 개가 되는지만 확인한다. 각 화면의 모든 버튼, 모든 입력값 조합, 경계 조건을 파는 게 아니다. 그건 회귀 테스트의 몫이다. 스모크 테스트는 "예매라는 서비스가 서비스로서 서 있는가"만 본다.

다이어그램 설명. 이 그림이 보여주는 건 스모크 테스트가 파이프라인의 맨 앞 관문이라는 점이다. "새 빌드를 배포했다"에서 출발해 곧바로 "스모크 테스트"를 거치고, 여기서 통과와 실패 두 갈래로 갈린다. 통과하면 "회귀 테스트·상세 검증"이라는 무거운 단계로 넘어가고, 실패하면 그 무거운 단계를 아예 시작하지 않고 되돌린다. 이 배치가 핵심인 이유는 비싼 검증을 값싼 검증 뒤에 두기 때문이다. 무너진 빌드에 30분짜리 회귀 스위트를 돌리는 건 낭비다. 60초짜리 관문이 먼저 걸러 주면 그 30분을 아낀다. 놓치기 쉬운 함정은 이 관문을 촘촘하게 만들고 싶은 유혹이다 — 흐름 하나가 실패할 때마다 검사를 추가하다 보면 스모크 테스트가 회귀 테스트로 부풀고, 그 순간 "빠른 피드백"이라는 존재 이유가 사라진다.

단위 테스트가 통과했는데 왜 또 확인하나 — 목(mock)과 진짜 조건

여기서 자연스러운 의문이 든다. 배포 전에 단위 테스트(unit test — 함수 하나를 격리해서 검증하는 가장 작은 테스트)가 전부 초록불이었는데, 왜 또 확인해야 하나? 답은 단위 테스트가 진짜 조건에서 돌지 않기 때문이다.

단위 테스트는 데이터베이스, 외부 API, 파일 시스템 같은 주변을 대개 목(mock — 진짜 대신 흉내만 내는 가짜 객체)으로 바꿔 놓고 돌린다. 그래야 빠르고 안정적이니까. 그런데 바로 그 대체 때문에, 단위 테스트는 배선이 실제로 연결됐는지는 보지 못한다. 스모크 테스트가 잡아내는 고장은 거의 전부 이 배선 쪽이다.

실제로 내 서버에서 스모크 테스트가 잡아낸 사고는 이런 것들이다. 환경 변수 하나를 오타 내서 데이터베이스 접속 문자열이 틀렸던 것, 서비스가 포트를 물지 못한 채 프로세스만 살아 있던 것, 의존 패키지 버전이 배포 환경에서만 어긋나 임포트가 깨진 것, HTTPS 인증서가 만료돼 브라우저가 접속을 거부한 것까지 있었다. 이 중 어느 것도 단위 테스트로는 잡히지 않는다 — 전부 목으로 가려진 진짜 세계의 문제이기 때문이다. 배포된 산출물을 실제 환경에서 실제로 한 번 밟아 봐야만 드러난다.

얼마나 얇아야 하나 — 핵심 경로 몇 개, 60초

스모크 테스트의 미덕은 얇음이다. 내 서버의 스모크 테스트는 이런 모양이다.

# 배포 직후 60초짜리 스모크 테스트 — 핵심 경로만 훑는다
set -e

# 1. 각 서비스가 살아서 응답하는가 (헬스 엔드포인트)
curl -fsS http://localhost:8080/health   # 대시보드
curl -fsS http://localhost:8082/health   # 챗봇

# 2. 로그인 페이지가 200으로 뜨는가
curl -fsS -o /dev/null -w "%{http_code}" https://내서버/login | grep -q 200

# 3. 챗봇이 한마디에 실제로 답하는가 (배선 전 구간 확인)
answer=$(curl -fsS https://내서버/chat -d '{"q":"핑"}')
echo "$answer" | grep -q '"reply"'   # 응답 형태만 확인, 내용 판정 안 함

코드 설명. 이 스크립트가 보여주는 건 스모크 테스트가 "판정"이 아니라 "생존 확인"이라는 점이다. 첫 단계는 각 서비스의 헬스 엔드포인트를 두드려 프로세스가 요청을 받는지 보고, 둘째 단계는 로그인 페이지가 HTTP 200으로 뜨는지만 확인하며, 셋째 단계는 챗봇에 "핑"을 던져 응답의 형태가 돌아오는지 본다. 눈여겨볼 대목은 셋째 단계가 답변의 내용을 채점하지 않는다는 것이다 — reply 필드가 있는지만 본다. 답이 똑똑한지는 스모크 테스트의 관심사가 아니다. "챗봇이라는 파이프가 입력부터 출력까지 뚫려 있는가"만 확인하면 된다. 맨 위의 set -e 때문에 어느 한 줄이라도 실패하면 즉시 멈추고, 이 스크립트의 실패가 곧 배포 실패 신호가 된다. 내용까지 파고들기 시작하면 60초가 10분이 되고, 그 순간 아무도 배포 때마다 돌리지 않게 된다.

회귀 테스트와 어디서 갈라지나

스모크 테스트와 회귀 테스트(regression test — 최근 변경이 기존 기능을 깨뜨렸는지 확인하는 테스트)는 둘 다 배포 뒤에 돌지만, 답하는 질문이 다르다. 나란히 놓으면 이렇다.

축	스모크 테스트	회귀 테스트
답하는 질문	이 빌드가 서 있나?	무엇이 깨졌나?
깊이	핵심 흐름 몇 개, 얕게	전 기능, 경계 조건까지 깊게
속도	수십 초	수 분~수십 분
실행 시점	모든 빌드·배포 직후 맨 먼저	스모크 통과 후, 또는 정기적으로
실패하면	더 볼 것 없이 롤백	어느 기능이 왜 깨졌는지 조사

둘의 관계는 경쟁이 아니라 순서다. 스모크 테스트가 값싼 관문으로 앞에 서서 무너진 빌드를 걸러 내고, 그 관문을 통과한 빌드에만 비싼 회귀 스위트를 태운다. 이게 사람에게 주는 가치는 명확하다 — 배포 때마다 "일단 켜지긴 했다"는 확신을 몇 초 만에 얻고, 정말 무너졌을 때는 30분을 낭비하기 전에 되돌린다.

정리 — 스모크 테스트는 미리 짠 시나리오가 아니라 진짜 배선을 겨냥한다

스모크 테스트가 잡아내는 것은 화려한 버그가 아니다. 오타 난 환경 변수, 물지 못한 포트, 만료된 인증서처럼 진짜 환경에 배포해야만 드러나는 배선 사고다. 단위 테스트가 목으로 가려 두고 지나간 바로 그 지점이다. 그래서 스모크 테스트는 정교할수록 좋은 게 아니라 얇을수록 좋다 — 핵심 경로 몇 개를 수십 초 안에 훑어, 더 볼 가치가 있는 빌드인지만 판정하면 제 몫을 다한 것이다.

개인 작업에도 그대로 적용된다. 서비스를 재시작한 뒤 새로고침하며 "떴나?"를 확인하는 그 몇 초를, 손이 아니라 예닐곱 줄짜리 스크립트에 맡기는 것 — 그것이 스모크 테스트의 전부다. 깊게 파는 건 그다음이다.

---

참고한 공개 자료:

• Smoke Testing vs Regression Testing — PractiTest
• What is Smoke Testing? — QA Wolf
• Smoke Testing vs Regression Testing: Key Differences — testRigor
• Difference between Smoke Testing and Regression Testing — GeeksforGeeks

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.